Dev Blogs

I recently had someone ask for recommendations for dev blogs to fill out their RSS reader. After going through what I have in my RSS reader, I realized that this would make a good little post—these have all been helpful resources to me, so it seems likely they could be helpful to someone else. (I have also been informed by a friend of mine that I should include myself in this list, but I figure you’re already here. Go ahead and throw this site URL into your RSS reader, the feed is nice and discoverable.)

So, in no particular order, developer blogs:

  • Use Your Loaf posts fun little things, usually regarding iOS development.
  • The Always Right Institute does terrible, terrible things with Swift, and they’re consistently a delight to read.
  • SwiftLee writes very solid articles explaining various Swift language features, iOS API things, and general career tips.
  • Swift with Majid does weekly deep dives into SwiftUI… and may or may not be the inspiration for my recent spate of programming posts.
  • Swift by Sundell is one of the definitive Swift sites; not only does John Sundell write up plenty of great articles (see ‘Swift Fundamentals’ as a great starting point!), he also has a couple podcasts, if listening is more your style.
  • Reda Lemeden does some fun explorations of Swift, as well as more general things with his “This Week I Learned” posts.
  • Gui Rambo does some really neat explorations of what’s possible on iOS when he’s not cracking open the developer betas to see what features Apple forgot to feature-flag out of the build.
  • Povilas Staškus hasn’t posted in a while, but his posts are worth a back-read; the Jekyll-to-Publish migration was a fun one. And, hey, putting an infrequent poster in RSS is what RSS is for!
  • NSHipster is a venerable name in the iOS dev world; not as actively updated as it once was, but the back catalog is extremely solid, and will quite often be one of the first results when Googling various things.
  • Kristaps Grinbergs writes in a similar vein to Swift with Majid, with explanations of various parts of the SwiftUI API.
  • Julia Evans is a break from my very iOS-heavy list so far; she does comics and zines explaining general programming concepts, command line tools, and all sorts of stuff. Seriously good explanations, I recommend checking them out.
  • Brent Simmons blogs about NetNewsWire, life as a developer, and neat bits of history in the Apple world.
  • Steven Troughton-Smith may well be the expert on Catalyst apps; his recent post of various sample apps is a wonderful resource if you’re looking into bringing an iPad app to macOS.
  • Erica Sadun’s blog has recently been a lot of neat macOS automation stuff; she’s also a frequent contributor to Swift itself.
  • On Hacking With Swift, Paul Hudson provides excellent WWDC coverage and an amazing array of tutorials and documentation.1 If you’re just getting started, go through his free 100 Days of Swift and 100 Days of SwiftUI courses.

And, in addition to all those blogs, I also funnel email newsletters into RSS whenever possible. My top picks from that list are:

  • iOS Goodies provides a little commentary with a list of articles.
  • iOS Dev Weekly comes with much more commentary; I’m also a fan of the “and finally…” section, it’s a nice ending every week.
  1. Seriously, it’s so robust that one of my top bangs is !hws

Network Caching With Combine

I’m going to lead in to this post by saying that this isn’t a Definitively Correct way to do this; it works for my use case, but has some definitive issues. Still, in the interest of transparency—and not running out of content for this blog—I’m going to share it anyways.

Last week, I shared a fun little enum-based way of representing API endpoints in a type-safe manner. It’s also pretty easy to expand on to use as the key for an in-memory cache of endpoint results.

(This, by the by, is Caveat 1: it’s a purely in-memory cache, with nothing being persisted to disk. User quits out of your app? Cache is gone. For what I’m working on, though, this is the behavior we want, so it works well.)

Let’s get started with the actual API surface we want:

class ApiClient { func get<T: Decodable>(endpoint: Endpoint, reset: Bool = false) -> T? { ... } }
Code language: Swift (swift)

Now, the funky thing about how I’ve got this implemented is that this get method is idempotent – if you call it 10,000 times for the same Endpoint, it’s only going to spit out one network request, and will just continue returning nil until something is actually present. (Well, unless you’re setting reset to true – that’s really in there for debug purposes more than anything else. Give the API I’m using on this project, it’s almost never necessary.)

And, for use with SwiftUI, we want it to be called again when the network request finishes, so we’ll make it an ObservableObject.

Next, let’s work out how to store things to achieve that. The main thing we need is somewhere to store the network requests, and somewhere to store the results – the aforementioned in-memory cache. And, to get that “call the method again when the cache changes” behavior, we can make it @Published:

class ApiClient: ObservableObject { private var loaders: [Endpoint:AnyCancellable] = [:] @Published private var cache: [Endpoint:Decodable] = [:] }
Code language: Swift (swift)

Now, to make Endpoint we need it to be viable dictionary key, which is pretty easy to accomplish:

extension Endpoint: Hashable { }
Code language: Swift (swift)

Finally, we need to implement the actual method. Without further ado:

class ApiClient: ObservableObject { private var loaders: [Endpoint:AnyCancellable] = [:] @Published private var cache: [Endpoint:Decodable] = [:] func get<T: Decodable>(endpoint: Endpoint, reset: Bool = false) -> T? { if reset { cache[endpoint] = nil loaders[endpoint] = nil // which implicitly calls loaders[endpoint]?.cancel(), via the deinit } if let _item = cache[endpoint], let item = _item as? T { print("\(endpoint): cache hit") return item } if loaders[endpoint] == nil { print("\(endpoint): cache miss; beginning load") loaders[endpoint] = URLSession.shared.dataTaskPublisher(for: endpoint.url) // 1 .map(\.data) .decode(type: T.self, decoder: JSONDecoder()) // 2 .receive(on: DispatchQueue.main) .sink(receiveCompletion: { (completion) in print(completion) }, receiveValue: { (item) in self.cache[endpoint] = item }) } print("\(endpoint): cache miss; loading already in progress") return nil } }
Code language: Swift (swift)

Two notes in there:

  1. You may want to swap out the use of URLSession.shared here for a parameter into the class’ constructor – it’ll make your testing a bit easier.
  2. Even more so than (1), you probably want to swap out JSONDecoder() here for something stored on the class – that decoder isn’t free to initialize!

Now, as I mentioned, this has some limitations. The first one I already went over – it’s a purely in-memory cache. The second is at the call site – since this is generic across Decodable, you have to annotate at the call site what the expected return type is, which isn’t the most ergonomic.

My actual thought on fixing that was very TypeScript-inspired – creating overloads that specify T based on the given endpoint. In Swift, this isn’t too difficult, just adding something like:

extension ApiClient { func getCategory(_ id: Category.ID, reset: Bool = false) -> Category? { get<Category>(endpoint: .category(id), reset: reset) } }
Code language: Swift (swift)

Which, of course, can get a bit repetitive depending on the number of endpoints you have. But hey, it works for my use case, and it may be helpful to someone else, so: blog post!

As a post-credits scene of sort, the TypeScript version is a bit silly, and takes advantage of the absolutely bonkers way method overloads work in TypeScript. I’ll throw out some pseudocode:

class ApiClient{ func get(endpoint: Endpoint.Category, reset: bool): Category? func get<T>(endpoint: Endpoint, reset: bool: T? { ... } }
Code language: TypeScript (typescript)

Yes, method overloads like this are just declaring the method multiple times before the actual body. And yes, you can specify an individual enum case as a type.


Safe API Calls with Enums

I really hate runtime errors. I’m a firm believer in the concept that as many errors as conceivably possible should be caught at compile-time. It makes sense, after all: a compile time error for me means a few minutes of my time spent fixing it; a runtime error for my users means a few seconds of their time staring at an error… multiplied across however many users there may be. And, really, how often are you working on an app where you outnumber the users?

In this vein, I’ve been tinkering with how to handle network requests. The easy first thing to do was to swap out stringly-typed URLs for an enum, and Swift’s associated values make this a breeze:

enum Endpoint { case globalConfiguration case category(Category.ID) case product(Product.ID) ... }
Code language: Swift (swift)

Your definitions may vary – this is, of course, very specific to the actual use case. But look at that – not only do we have clear representations of the various endpoints available, we can even link the variable components of those URLs to being the proper type for the model we expect to get back. How’s that for self-documenting code?

Next, we need a way to convert from this lovely enum to the actual URL we’re going to use to make our requests. I’ve split this up a little bit:

extension Endpoint { var pathComponents: String { switch self { case .globalConfiguration: return "/config.json" case .category(let ID): return "/category/\(ID).json" case .product(let ID): return "/product?id=\(ID)" ... } } var url: URL { #if DEBUG return URL(string: "")!.appendingPathComponent(pathComponents) #else return URL(string: "")!.appendingPathComponent(pathComponents) #endif } }
Code language: Swift (swift)

Et voila, converting to our known URLs, and a nice little “automatically use the dev server in debug mode” check, while we’re at it.

Now, depending on how you’re organizing your networking code, we can tweak the API surface here a little bit to make things clearer. Add those extensions in the same file as the code that makes the network requests, and declare them fileprivate – and now, you’ve got an automatic reminder from the compiler if you start writing some URL-based networking code outside of the network component. No more leaky abstraction!



I’m writing this a bit after WWDC has ended, and publishing it a bit further after that, so pardon the tardiness as I share my thoughts, in no particular order:

  • As a user, I am quite excited by the new functionality in FaceTime, and the new Focus system for managing notifications. The system of tiered notifications looks great, and I’m excited for the, oh, 15 minutes most people will have between ‘installing iOS 15’ and ‘an app first abusing the notification level to send them spam.’1 In iOS 16, can we get a “report notification as spam” button that immediately flags the app for App Review to yell at?
  • As both a developer and user, I was immensely excited to see the ManagedSettings and ManagedSettingsUI frameworks – I really like the concept of Screen Time for externalized self-control, and being able to use custom implementations or build my own seemed like a dream.2 Unfortunately, all those dreams were immediately crushed by the reveal that this all requires FamilyControls, so not only can I not do anything interesting with it as a developer, I can’t even use it myself. Because, as we all know, the only use case for “my phone won’t let me use it to waste time” is “parents managing their children.”
  • Swift’s implementation of async/await looks great, and the stuff Apple’s doing with @MainActor seems to have met the goal of “the language eliminates an entire class of error” that initially gave us optionals, so I’m quite happy about that. I hope Vapor updates to async/await soon, I’d love to untangle some of my flatMap chains.
  • The new Human Interface Guidelines section on Inclusion is very well-written and hits on some important points.
  • I am incredibly excited about the virtual KVM thing coming to macOS and iPadOS – my desk setup features two monitors for macOS, and an iPad perpetually on the side, and the idea of being able to control the iPad without taking my hands off the main keyboard and mouse is very exciting.3
  • Safari on iOS got support for web extensions, which is neat. I also like that they’re pulling things down toward the bottom of the screen, should be more reachable.
  • Safari on macOS might finally do something that Mozilla never managed to do: convince me to switch to Firefox. I sincerely hope this is the peak of “aesthetics over functionality” in Apple’s design, and that it gets better from here, because this is a mess: lower contrast text, the core UI element moves around all the time so you can’t have any muscle memory, and they’ve buried every single button behind a ‘more’ menu.
  • SwiftUI got lots of little updates, but the thing that I may be most excited about is the simple quality of life improvements as a result of SE-299.listStyle(.insetGrouped) is much easier to type than .listStyle(InsetGroupedListStyle()), especially considering that Xcode can actually suggest .insetGrouped.
  1. In my case, it’ll probably be a couple days, and then Apple Music will punch through a Focus mode to notify me that Billie Eilish has a new single or something.
  2. I already have a name for the app I want to build using these API. My first feature would just be “the existing Screen Time system, but it actually knows how time works.” Something like 90% of the time that I hit ‘one more minute’ I’m instead given a couple seconds. Apple, I know that time is hard, but it isn’t that hard.
  3. Why the iPad? Because iPadOS is sandboxed, which limits the sort of bugs that Teams can introduce and evil that Zoom can. Sure, they both have macOS apps – but you shouldn’t install either of them.

FocusedValue on tvOS

Alright, let’s set the scene with a mildly contrived example: you’ve got a list of things, and you want the surrounding View to match them. For a tvOS app, this could be swapping out the background and some title text to match the selected episode; since I don’t feel like coming up with some fake episode titles, however, we’re going to go with colors:

At first thought, you’d probably reach for @State, something akin to:

struct ColorsView: View { @State var selectedColor: Color let colors: [Color] var body: some View { VStack { Text(colorName(selectedColor)) HStack { ForEach(colors) { color in Rectangle().fill(color).focusable() } } } .background(WaveyShape().fill(selectedColor) } }
Code language: Swift (swift)

Not too bad; attach on onFocus to the Rectangle() and it should work!

But… what if there’s more layers in between? Instead of a Rectangle(), you’ve got some other View in there, maybe doing some other logic and stuff.

Oof, now we’re going to need a @Binding, and – oh, what happens if the user swipes out of the rectangles and to our nav bar, can selectedColor be nil?

Happily, SwiftUI has something built out to handle basically this exact scenario: @FocusedValue. There’s some great tutorials out there on how to do this for a macOS app, which allows you to wire up the menu bar to respond to your selection, but it works just as well on tvOS.

Let’s get started:

struct FocusedColorKey: FocusedValueKey { typealias Value = Color } extension FocusedValues { var color: FocusedColorKey.Value? { get { self[FocusedColorKey.self] } set { self[FocusedSeriesKey.self] = newValue } } }
Code language: Swift (swift)

Now we’ve got our new FocusedValue available, so let’s use it:

struct ColorsView: View { @FocusedValue(\.color) var selectedColor: Color? var body: some View { VStack { Text(colorName(selectedColor ?? Color.clear)) HStack { ForEach(colors) { ColorRectangleView(color: $0) } } } .background(WaveyShape().fill(selectedColor ?? Color.clear) } }
Code language: Swift (swift)

The one big change here is that selectedColor can be nil. I’ve gone ahead and defaulted to .clear, but do what fits your use case.

Finally, we need to set the focused item:

struct ColorRectangleView: View { let color: Color var body: some View { Rectangle() .fill(color) .focusable() .focusedValue(\.color, color) } } }
Code language: Swift (swift)

Et voila, it works!

Now, this may not seem like a huge change over doing it via @Binding, but keep in mind: @FocusedValue is a singleton. You can have every view in your app respond to this, without passing @Bindings every which way.


Position vs Offset

I’ve had reason recently to be doing custom position of things in SwiftUI, and figured I’d share something that I found a bit of a tricky distinction at first: position vs offset.

So, let’s set the scene:

struct DemoView: View { var body: some View { HStack { Rectangle().fill(.gray) Rectangle().fill(.blue) Rectangle().fill(.gray) } } }
Code language: Swift (swift)

And now I’ll add some visuals, for ease of reading. (I made these in Sketch, so the graphics aren’t precisely what you’d get by running this code, but hey, artistic liberties.) Here’s our view:

Three squares in a row.

Now let’s tinker!

struct DemoView: View { var body: some View { HStack { Rectangle().fill(.gray) Rectangle().fill(.blue) .offset(x: 150, y:150) Rectangle().fill(.gray) } } }
Code language: Swift (swift)

We’re offsetting the middle square. What does that look like?

Three squares; two are in a row, and there is a space in the middle where the third could fit, but it is below and to the right of that space.

I’ve left in a little ghost image to show where it was, because it’s an important distinction! As far as the HStack is concerned, that space is still occupied. Think of it like throwing your voice – you don’t move, just the perception of where you are.

Let’s try something else, now:

struct DemoView: View { var body: some View { HStack { Rectangle().fill(.gray) Rectangle().fill(.blue) .position(x: 150, y:150) Rectangle().fill(.gray) } } }
Code language: Swift (swift)

Looks pretty similar in code, right? We’ve just swapped out ‘offset’ for ‘position’. What do we get on screen?

Three squares; two are in a row, while the third is out of alignment and slightly overlapping.

Ooh, very different! No more ghost, because now it’s actually in a different place – not holding that spot in the HStack. It’s also in a different spot than the previous one, what gives?

It’s in the name: ‘offset’ offsets the view from where it normally would’ve been. Our starting position was where the ghost stayed:

Three squares; two are in a row, and there is a space in the middle where the third could fit, but it is below and to the right of that space. The distance from the space to the square is labeled, with 150 in the top distance and 150 in the left distance.

‘Position,’ on the other hand, skips the whole question of where it would go and instead just puts it in an exact spot, using the top left corner of the screen as the point (0,0):

Three squares; two are in a row, while the third is out of alignment and slightly overlapping. The distance from the misaligned square to the top and left of the image are labeled with '150' on each.

The other approach that worked for my brain, coming from doing a lot of web dev, is to think about ‘offset’ as being CSS’ ‘position: relative’, while ‘position’ is equivalent to ‘position: absolute’.

Hopefully this helps the whole thing make sense!


Transitions in ZStacks

The other day, I found a fun little SwiftUI edge case: using a .transition() modifier in a ZStack doesn’t work. As a basic demo, let’s do something like this:

struct DemoView: View { @State var showing = true var body: some View { ZStack { Rectangle().fill( .onTap { showing.toggle() } if (showing) { Text("Hello, world!") .transition(.opacity) } } } }
Code language: Swift (swift)

Pretty simple example, yeah? Seems like it’d Just Work(TM) out of the box. It doesn’t, though; instead of a lovely opacity animation, it just pops in and out. Hmm.

Worry not, though, as I have a fix:

struct DemoView: View { @State var showing = true var body: some View { ZStack { Rectangle().fill( .onTap { showing.toggle() } .zIndex(1) if (showing) { Text("Hello, world!") .transition(.opacity) .zIndex(2) } } } }
Code language: Swift (swift)

Et voila, your transition works!

Now, I haven’t exactly done rigorous experimentation to figure out why, exactly, this works, but I do have a theory: when SwiftUI removes the Text, it loses its place in the ZStack, and gets assigned to “behind everything else.” By manually specifying the order, the slot stays reserved, and it can stay there while it fades in and out.


Playing Videos in SwiftUI

As of WWDC 2020, we have a way to play videos in SwiftUI without bailing out to UIKit with UIViewRepresentable. At first glance, it’s pretty simple, as well:

import SwiftUI import AVKit struct VideoPlayerView: View { let videoURL: URL var body: some View { let player = AVPlayer(url: videoURL) VideoPlayer(player: player) } }
Code language: Swift (swift)

Et voila, you’re playing a video! You can overlay content on top of the video player pretty easily:

import SwiftUI import AVKit struct VideoPlayerView: View { let videoURL: URL var body: some View { let player = AVPlayer(url: videoURL) VideoPlayer(player: player) { Text("Watermark") } } }
Code language: Swift (swift)

Seems like we’re good to go, no?

Well, not quite. Let’s talk memory management.

VideoPlayerView is a struct – it’s immutable. SwiftUI allows us to mutate the state of our views with user interaction using things like @State, thanks to some Compiler Magic.

Every time some aspect of the state changes, SwiftUI calls the body getter again.

Spotted the catch yet?

We’re declaring the AVPlayer instance inside the body getter. That means it gets reinitalized every time body gets called. Not the best for something that’s streaming a video file over a network.

But wait, we’ve already mentioned the Compiler Magic we can use to persist state: @State! Let’s try:

import SwiftUI import AVKit struct VideoPlayerView: View { let videoURL: URL @State var player = AVPlayer(url: videoURL) var body: some View { VideoPlayer(player: player) } }
Code language: Swift (swift)

Whoops. We’ve got a problem – self isn’t available during initialization, so we can’t initialize the AVPlayer like that. Alright, we’ll write our own init:

import SwiftUI import AVKit struct VideoPlayerView: View { let videoURL: URL @State var player: AVPlayer init(videoURL: URL) { self.videoURL = videoURL self._player = State(initialValue: AVPlayer(url: videoURL)) } var body: some View { VideoPlayer(player: player) } }
Code language: Swift (swift)

(I suppose we could drop the let videoURL: URL there, since we’re using it immediately instead of needing to store it, but for consistency’s sake I’m leaving it in.)

Okay, sounds good – except, hang on, @State is only intended for use with structs, and if we peek at AVPlayer it’s a class.

Okay, no worries, that’s what @StateObject is for, one more tweak:

import SwiftUI import AVKit struct VideoPlayerView: View { let videoURL: URL @StateObject var player: AVPlayer init(videoURL: URL) { self.videoURL = videoURL self._player = StateObject(wrappedValue: AVPlayer(url: videoURL)) } var body: some View { VideoPlayer(player: player) } }
Code language: Swift (swift)

There, we should be good to go now, right? Right?

Alas, the compiler says no. AVPlayer doesn’t conform to ObservableObject, so we’re out of luck.

Fortunately, ObservableObject is pretty easy to conform to, and we can make our own wrapper.

import SwiftUI import AVKit import Combine class PlayerHolder: ObservableObject { let player: AVPlayer init(videoURL: URL) { player = AVPlayer(url: videoURL) } } struct VideoPlayerView: View { let videoURL: URL @StateObject var playerHolder: PlayerHolder init(videoURL: URL) { self.videoURL = videoURL self._player = StateObject(wrappedValue: PlayerHolder(videoURL: videoURL)) } var body: some View { VideoPlayer(player: playerHolder.player) } }
Code language: Swift (swift)

Phew. At long last, we’ve got a stable way to hold onto a single AVPlayer instance. And, as a bonus, we can do stuff with that reference:

import SwiftUI import AVKit import Combine class PlayerHolder: ObservableObject { let player: AVPlayer init(videoURL: URL) { player = AVPlayer(url: videoURL) } } struct VideoPlayerView: View { let videoURL: URL @StateObject var playerHolder: PlayerHolder init(videoURL: URL) { self.videoURL = videoURL self._player = StateObject(wrappedValue: PlayerHolder(videoURL: videoURL)) } var body: some View { VideoPlayer(player: playerHolder.player) .onAppear { } } }
Code language: Swift (swift)

Will start playing the video as soon as the view opens. Similarly, you could add some Buttons, build your own UI on top of the video player, all sorts of fun.

And, from the other end, you can put more logic in the PlayerHolder, as well. Say you need some additional logic to get from a video ID to the actual URL that the AVPlayer can handle? Try something like this:

class PlayerHolder: ObservableObject { @Published var player: AVPlayer? = nil init(videoID: Video.ID) { NetworkLayer.shared.lookupVideoInformation(videoID) { result in self.player = AVPlayer(url: result.url) } } }
Code language: Swift (swift)

(Now, that’s not the nice, Combine-y way to do it, but I’ll leave that as an exercise for the reader. Or possibly another post.)


tvOS Carousels in SwiftUI

It’s a fairly common pattern in tvOS apps to have a carousel of items that scrolls off screen in either direction – something vaguely like this:

Image a tvOS wireframe, showing two horizontally-scrolling carousels.

Actually implementing this in SwiftUI seems like it’d be easy to do at first:

VStack { Text("Section Title") ScrollView(.horizontal) { HStack { ForEach(items) { ItemCell(item: $0) } } } }
Code language: Swift (swift)

Which gets you… a reasonable amount of the way there, but misses something: ScrollView clips the contents, and you wind up looking like this:

A tvOS wireframe, showing two horizontally-scrolling carousels; both have been clipped to the wrong visual size.

Not ideal. So, what’s the fix? Padding! Padding, and ignoring safe areas.

VStack { Text("Section Title").padding(.horizontal, 64) ScrollView(.horizontal) { HStack { ForEach(items) { ItemCell(item: $0) } } .padding(64) // allows space for 'hover' effect .padding(.horizontal, 128) } .padding(-64) } .edgesIgnoringSafeArea(.horizontal)
Code language: Swift (swift)

The edgesIgnoringSafeArea allows the ScrollView to expand out to the actual edges of the screen, instead of staying within the (generous) safe areas of tvOS.1

That done, we put the horizontal padding back in on the contents themselves, so that land roughly where we want them. (I’m using 128 as a guess; your numbers may vary, based on the design spec; if you want it to look like The Default, you can read pull the safe area insets off UIWindow.)

Finally, we balance padding on the HStack with negative padding on the ScrollView; this provides enough space for the ‘lift’ (and drop shadow, if you’re using it) within the ScrollView, while keeping everything at the same visual size.

  1. tvOS has large safe areas because TVs are a mess in regards to useable screen area.

Custom Queries in Vapor Fluent

While the QueryBuilder interface is pretty neat, it’s still missing some things. Recently, I needed a GROUP BY clause in something, and was rather unsurprised to find that Fluent doesn’t support it.1

Fortunately, it’s still possible to write custom SQL and read in the results. Make yourself a convenience struct to unpack the results:

struct MyQueryResult: Codable { let parentID: Parent.IDValue let sum: Double }
Code language: Swift (swift)

(Strictly speaking, it can be Decodable instead of Codable, but as long as the Parent.IDValue (generated for free by making Parent conform to Model, I believe) is Codable, Swift generates the conformance for us.)

Now, in your controller, import SQLKit, and then get your database instance as an SQL database instance:

guard let sqlDatabase = req.db as? SQLDatabase else { // throw or return something here }
Code language: Swift (swift)

After that, write your request:

let requestString = "SELECT ParentID, SUM(Value) FROM child GROUP BY ParentID"
Code language: Swift (swift)

Note – your syntax may vary; I found that, using Postgres, you need to wrap column names in quotes, so I used a neat Swift feature to make that less painful:

let requestString = #"SELECT "ParentID", SUM("Value") FROM child GROUP BY "ParentID""#
Code language: Swift (swift)

If you want to use string interpolation, swap out \() for \#().

Finally, make the query:

return sqlDatabase.raw(SQLQueryString(requestString)).all(decoding: MyQueryResult.self)
Code language: Swift (swift)
  1. Entity Framework Core, which is an incredibly robust, full-featured ORM, only barely supports GROUP BY, so seeing this rather young ORM not support it isn’t all that shocking.

Forms & Lists

If there’s one area where SwiftUI really shines, it’s forms and lists. I have one area of the app that’s meant as, at most, a fallback option for managing some data, and putting together that management interface took, oh, an hour? It was a breeze. Admittedly, it’s not the prettiest list I’ve ever made, but like I said: fallback option.

Screenshot of a list with a title, two items showing a date and value each, and an 'add' button.
Managing data points in a data set. Unpolished? Sure. Functional? Absolutely.
Screenshot of a Settings screen showing two lists, with an 'edit' button.

I was delighted to find that the automagic ‘edit’ button function handles multiple editable lists within the same View. As this is part of the ‘Settings’ screen, one of the three core screens in the app, it has received a bit more polish.

And I’ve continued to have fun building custom versions of the Picker control, with an expansion on my previous custom picker to support inline management of the above Data Sets and the addition of another one for picking a type of graph:

Screenshot of a picker showing three types of graphs.

At the moment, I’m showing a pretty basic dataset for these, but at some point I think I may create something a bit more visually interesting. The trick being, of course, that I can’t just random-number-generate the data, because I want all three to show the same data points, and since the user can also control the color, I want it to stay consistent if you leave, change the color, and come back.

(The solution here is probably to hard-code a data set, but where’s the fun in that?)


File > New > Project…

I recently started working on a new development project. Or rather, a project I’ve been thinking about for a while, but just recently started developing – the first draft of the design is from almost a year ago, now, something that I worked on as a class project. But, mostly on a whim, I signed up for SwiftUI Jam, and took it as an excuse to start actually building the thing.

Now, normally my approach to projects is very Apple – refuse to admit I’m even working on something new until it’s complete, ready to present to the world. This time, though, the vague rules of the jam meant it had to be done at least somewhat in the open, and I figured I may as well do some proper write-ups as I go. Could be interesting.

I’m starting with… not the first thing I built, but the one that was the most fun so far. I’m doing the whole app in SwiftUI, and it really shines for building forms.

Screenshot of an iOS application showing a form: Title, Color, and Data Set; Comparison? is set to false.
Screenshot of an iOS application showing a form: Title, Color, and Data Set; Comparison? is set to true. The first three questions are repeated.
Screenshot of an iOS application showing a list to choose from, with groupings such as Activity featuring items like Calories Burned and Cycling Distance.

As I said, a fairly simple form – Title, Color, and Data Set, with the option to add a second of the same three items. The Data Set picker is a custom version of a Picker, because I wanted to give the options in a grouped list rather than just alphabetical order.

I suspect I’m going to be building a second custom Picker implementation sometime soon – this time, choosing from more visual options. Should be fun to put together.


Serving ‘files’ in Vapor

In my experience, dynamically generating a file, serving it immediately, and not persisting it on the server is a pretty common use case. In general, this is one of two things – either a PDF download, or a CSV. While my Vapor tinkering hasn’t yet given me an opportunity to generate PDFs on the server, I have had an occasion to create a CSV, and wrote up a little helper for doing so.

import Vapor struct TextFileResponse { enum ResponseType { case inline, attachment(filename: String) } var body: String var type: ResponseType var contentType: String } extension TextFileResponse: ResponseEncodable { public func encodeResponse(for request: Request) -> EventLoopFuture<Response> { var headers = HTTPHeaders() headers.add(name: .contentType, value: contentType) switch type { case .inline: headers.add(name: .contentDisposition, value: "inline") case .attachment(let filename): headers.add(name: .contentDisposition, value: "attachment; filename=\"\(filename)\"") } return request.eventLoop.makeSucceededFuture(.init(status: .ok, headers: headers, body: .init(string: body))) } }
Code language: Swift (swift)

That’ll work for any file you can assemble as text; CSV just struck me as being the most useful example. Use ResponseType.inline for a file you want displayed in a browser tab, and .attachment if it’s for downloading.

And if you’re doing a lot of CSVs, give yourself a nice little helper:

extension TextFileResponse { static func csv(body: String, name: String) -> TextFileResponse { .init(body: body, type: .attachment(filename: name), contentType: "text/csv") } }
Code language: Swift (swift)

Default Values in Vapor Fluent

My recent tinkering has been with Vapor, and while I mostly like their Fluent ORM, it has some rough edges and semi-undocumented behavior. At some point, I’ll feel confident enough in what I’ve learned through trial and error (combined with reading the source code – open source!) to actually make some contributions to the documentation, but for now, I’m going to throw some of the things I struggled with up here.

If you’re using a migration to add a column, and specifically want it to be non-null, you’ll need a default value. My first approach was to do a three-step migration, adding the column as nullable, then filling the default value on all rows, and then setting the column to be non-null, but that didn’t feel right. Eventually, though, I figured out how to express a DEFAULT constraint in Fluent:

let defaultValueConstraint = SQLColumnConstraintAlgorithm.default(/* your default value here */)
Code language: Swift (swift)

Then, in your actual schema builder call:

.field("column_name", /* your type */, .sql(defaultValueConstraint), .required)
Code language: Swift (swift)

Note that SQLColumnConstraintAlgorithm isn’t available from the Fluent module, you’ll need to import SQLKit first.

And here, a full worked example:

import Vapor import Fluent import SQLKit struct DemoMigration: Migration { func prepare(on database: Database) -> EventLoopFuture<Void> { let defaultValueConstraint = SQLColumnConstraintAlgorithm.default(false) return database.schema(DemoModel.schema) .field(DemoModel.FieldKeys.hasBeenTouched, .bool, .sql(defaultValueConstraint), .required) .update() } func revert(on database: Database) -> EventLoopFuture<Void> { database.schema(DemoModel.schema) .deleteField(DemoModel.FieldKeys.hasBeenTouched) .update() } }
Code language: Swift (swift)

(For context, I’m in the habit of having a static var schema: String { "demo_model" } and a struct FieldKeys { static var hasBeenTouched: FieldKey { "has_been_touched" } } within each of my Fluent models – it keeps everything nice and organized, and avoids having stringly-typed issues all over the place.)

Education Portfolio Technology

Swift Student Challenge

A few days ago, Apple announced the winners of their Swift Student Challenge. I had applied and used my “taking a test” tactic, which was to hit ‘submit’ and then promptly erase the whole thing from my brain. (What’s done is done, and I feel silly worrying about something I have no control over.)

So when I got the email that “my status was updated” it was a bit of a surprise.

And when I clicked through the link (because, of course, they can’t just say in the email, you have to sign in) I was in for more of a surprise.

My submission had been accepted. I’m one of 350 students around the world whose work sufficiently impressed the judges at Apple.

Screenshot from Apple Developer website. It reads: Congratulations! Your submission has been selected for a WWDC20 Swift Student Challenge award. You'll receive an exclusive WWDC20 jacket and pin set at the mailing address you provided on your submission form. You'll also be able to download pre-release software, request lab appointments, and connect with Apple engineers over WWDC20 content on the forums. In addition, one year of individual membership in the Apple Developer Program will be assigned free of charge to eligible accounts of recipients who have reached the age of majority in their region. For details, see the WWDC20 Swift Student Challenge Terms and Conditions.

Now, throughout the whole process of applying, I was my usual secretive self. I think two people knew that I was applying at all, much less what I was working on. Since it’s over with, though, it’s time for the unveiling.

What I made

I wanted to bring back a concept I’ve played with before: cellular automata. A few days before the competition was announced, I’d seen a video that really caught my interest.

Well hey, I thought, I’ve got some code for running cellular automata. I want to learn Swift Playgrounds. And I’ve been having fun with SwiftUI. Let’s combine those things, shall we?

The first big change was a visual history; when a cell dies, I don’t want it to just go out, I want it to fade slowly, leaving behind a trail of where the automata have spread.

The second was rewriting all the visuals in SwiftUI, which was a fun project. Animation timings took me a bit to get right, as did figuring out how to do an automated ‘update n times a second’ in Combine. The biggest issue I had, actually, was performance – I had to do some fun little tricks to get it to run smoothly. (Note the .drawingGroup() here – that made a big difference.)

And third, I didn’t want it to just be “here’s some code, look how pretty,” I wanted to actually use the Playground format to show some cool stuff. This turned out to be the most frustrating part of the whole thing – the Swift Playgrounds app doesn’t actually support creating a PlaygroundBook, and the Xcode template wasn’t supported in the then-current version of Xcode.

But the end result? Oh, I’m quite happy with it. PlaygroundBooks are cool once you get past how un-documented they are. You can, to borrow a Jupyter turn of phrase, mix code and prose in a lovely, interactive way.

Screenshot of the 'Grid' page of the playground book.  The full text is at
Don’t worry, the real version (and some videos) are below.

Doing the actual writing was pretty fun. This is a concept I’ve spent a lot of time learning about, just because it captured my interest, and I wanted to share that in a fun way.

Overall, I’m quite happy with the result. If you’d like to see more, I’ve made recordings of the ‘randomized grid’ and ‘Wolfram rule’ pages running, and the actual playground is available on GitHub.