Looking at my schedule, I’m going to have at least a couple months of availability for freelance iOS/macOS/Ruby work starting immediately. I’m a former Apple engineer (2018-2021); experienced with all of the current app frameworks and technologies. Capable of working on any size project, new or existing.
If you’re working on getting your iOS/macOS 26 updates over the line, now is a great time to bring me on. Get in touch via my Hire Me page and I’ll get back to you right away.
Unlike some of my friends, I’m not the biggest fan of the kind of AI code completion that tries to write blocks of code for you as you type, but I was still kind of excited to see what Apple’s version of that in Xcode would look like and wanted to give it a try.
On paper, it could be great. Xcode indexes all your code and knows everything about your project. Apple controls the entire experience, so the integration between the editor and LLM could be deep and relevant to your project’s code. As soon as you try it, you realize that’s not true. Wherever it’s pulling suggestions from, it doesn’t appear to have any kind of meaningful understanding of your project. Bummer.
The suggestions not being that good isn’t why I had to turn it off — sometimes they’re all right. Not close to as good as Copilot, but okay sometimes. The reason I had to turn it off, and the thing that is absolutely mind-boggling about the feature, is that it makes basic syntactic mistakes all the time. Things like putting the end quote in the wrong place or leaving off parentheses. Every time it made a mistake like this, I had to spend one or two minutes staring at the line, trying to find the error.
That’s not just bad; that’s worse than nothing. The good news is that engineers inside Apple use Xcode too, so I’m certain the team knows how much love predictive code completion needs. Hopefully, they’re spending the time and energy so that this year or next it can go from what it is now to what I was hoping it could be.
At this point, I am primarily working in SwiftUI. At work right now, we are doing macOS and iOS, and we’re not using AppKit or UIKit at all. Where I’m at right now in my thinking is that while I do like SwiftUI, I kind of miss the old way of doing things.
UIKit and SwiftUI represent two different approaches to writing user interfaces — imperative versus declarative. I would define imperative as kind of inside out and declarative as inside out. With imperative code, you call a function or method to say “do this thing,” while with declarative UI, you say “render it this way based on the current state.”
Declarative systems like SwiftUI are great because they make a lot of things very simple. Try setting up an AppKit NSTableView versus a SwiftUI Table. It’s way less code the declarative way.
The thing is that I still miss the imperative approach a lot of the time. Being able to say expand this row when I click this button is extremely convenient. With a declarative system, if they don’t give you a way to declare it, you’re just out of luck. When you can declare it, that becomes something like set the variable of expanded row IDs to X so that my view can update and read that variable to show the expansion. It’s pretty circuitous.
I do wonder how much of SwiftUI works the way it does to be more familiar or natural to people coming from web development. Or maybe it was just inspired by those systems?
Here’s where I’m landing. It’s not that I want to go back to the old way — I don’t. I like writing less code. What I’m saying is that both systems have a lot of value, but that treating the SwiftUI approach as inherently better is wrong. Neither approach is better or worse, they’re different. I will probably continue to pine for the other whenever I work in one for the rest of my career.
On macOS, Apple has the concept of a “Smart Folder” that is found in all kinds of places. Sometimes they’re called something else, but it’s the same concept. Just off the top of my head, they exist in Mail, Contacts, Finder, Music, and Photos.
The only apps I know about that have added them for both macOS and iOS are Reminders and Notes, although I’ve found the implementation of them to be a bit weird. In both of those, you can’t add sub-conditions, so you can say all or any of a list of conditions, but you can’t say “all of these conditions and any of these conditions.” It might sound like a small thing, but it’s not.
Anyway, back to the topic. I want this, and I want Apple to add it. Part of me wonders if it’s just a matter of there not being an equivalent to NSRuleEditor in UIKit or SwiftUI, and so every app would have to implement the control on their own1.
Apple Photos is the one where I really miss this because Photos libraries tend to be so big, and there are so many ways to slice them. For example, “I want to only see photos taken with this or that camera in the last six months.”
I know this whole thing probably sounds very specific and nerdy to anyone who doesn’t use this feature, but I do, and I think Apple should add it. It’s been fifteen years, Apple. I believe in you. You can do it.
Collin Donnell 