turing complete with a stack of 0xdeadbeef
SwiftUI’s new @Observable macro is not a drop-in replacement for ObservableObject. I learned of a subtle difference in behavior the hard way. Hopefully, I can save you from the same headache I experienced and save you some time.
While the new Swift Testing framework announced this year at WWDC24 is getting a lot of attention, there are some notable improvements coming to UI testing in XCTest in Xcode 16.
I previously wrote about how the requirements for screenshots on the App Store have become increasingly burdensome over the years. It is truly a nightmare. But today I have good news to share! Our nightmare is coming to an end, as changes to screenshot requirements were announced at WWDC24 this year.
SwiftUI introduced the ScenePhase API in iOS 14 and macOS 11. This was SwiftUI’s answer to handling application lifecycle events. At the same time, SwiftUI introduced UIApplicationDelegateAdaptor for iOS and NSApplicationDelegateAdaptor for macOS, which allow you to provide an AppDelegate on both platforms to receive additional application lifecycle events and other events that were missing from SwiftUI at the time. Unfortunately, many of those application event APIs are still missing and ScenePhase has a number of bugs (or at least, unexpected behavior).
More and more Apple Platform developers are migrating away from CocoaPods in favor the Swift Package Manager, which is Apple’s first-party tool for managing and integrating dependencies. While it is still not quite a complete replacement for CocoaPods, it is getting closer. Unfortunately, SwiftPM’s integration with Xcode still has a number of shortcomings, even though it was introduced with Xcode 11 — 4 years ago. The worst bug is that Xcode frequently and randomly deletes the Package.resolved, which in turn produces dozens or hundreds of 'missing package product' errors. Here’s how I’ve worked around this bug on a team I work on.
I recently setup fastlane for one of my indie apps, Taxatio, to automate uploading builds and metadata to the App Store — by far, one of the most tedious tasks of app development. While I had used fastlane extensively before when working on teams at companies, I had never actually set it up from scratch. In this post, I want to share how to do that, as well as a lightweight configuration that I think works well for solo indie developers — folks on a team of one!
My Mac menu bar apps, Red Eye and Lucifer, are now for sale on my new Gumroad store.
Providing screenshots for the App Store has always been a tedious and time-consuming process. But as the number of differently-sized iOS devices has grown and changed over the years, it has become more difficult to manage. (This is why the developer community built tools like fastlane snapshot.) The screenshot requirements for the App Store have increasingly become a burden for developers, especially indies. With the Mac App Store, there are fewer hurdles and less strict requirements. However, if you are now targeting only the latest OS releases and latest hardware, the screenshot requirements for both App Stores are not only burdensome but they no longer makes any sense!
I’m happy to share that I released an update to Taxatio today, but unfortunately it was not without a lot of friction and hassle with the App Store approval process.
Last week I wrote about setting up a new MacBook Pro — my first Apple Silicon Mac, and thus my first MacBook with a notch. I lamented how poorly macOS interacts with the notch, specifically how menu bar apps and icons simply get hidden if you have too many to display. Lots of folks on Mastodon offered various solutions, and some readers emailed me with options as well. I figured it was worth making a separate post about this specific issue to list all of the workarounds and alternatives. It is clear that this is a widespread problem that users are having.
Foundation’s URL (née NSURL) is a nearly ubiquitous API on Apple platforms. One of its shortcomings is that it is heavily overloaded – an instance of URL could represent a web URL or a file URL. While there are many similarities between accessing resources on a local disk or on a web server, I think there should be explicit types for each, say WebURL and FileURL.
UserDefaults is probably one of the most popular APIs on Apple Platforms. It is a highly-optimized key-value persisted store that is backed by a property list, and it is most commonly used for saving small pieces of data like user preferences. Despite its ease-of-use, there is one common anti-pattern I see developers use often.
Beginning with the introduction of dark mode in iOS 13, colors in iOS are now (optionally) dynamic. You can provide light and dark variants for all colors in your app. However, I was surprised to find that SwiftUI — which also made its first appearance on the platform in iOS 13 — still does not provide any API for creating dynamic colors.
When you display text in your app, you might come across situations where the text layout produces undesirable results under certain layout constraints. The text could wrap on smaller devices or be truncated in certain localizations. At this point, we are well-equipped with adaptive APIs to make our layouts work on all screen sizes — for example, we have Dynamic Type, Auto Layout, and UITraitCollection.
I’m excited to share that I recently released a new app, a tax calculator for freelancers called Taxatio. It is specifically for self-employed sole proprietors based in the United States — freelancers, consultants, independent contractors, and indie developers (like me!). One of the more confusing and difficult aspects of going independent is taxes. And that’s why I made this. It is a multiplatform SwiftUI app for iOS and macOS available as a universal purchase on the App Store.
Large Xcode projects can be difficult to navigate, especially when you are making a large change across a large number of files. Depending on how your project is configured, modified files will be spread across multiple nested directories and multiple targets.
When debugging a large project in Xcode that a large team works on, the console can get quite busy. Logs are everywhere! It can be difficult to sift through the noise, particularly when you have a number of breakpoints configured to log messages, execute debugger commands, and continue after evaluating rather than pause.
Since iOS 15 and and macOS 12, or whenever Apple launched the new “Start Page” for Safari, I’ve had various issues getting tabs to sync across my devices. It seems to be a common problem.
When working on large iOS apps, all the tasks you need to perform before you even get started writing code can begin to consume a lot of time. I’m talking about all the preparation that happens in your terminal — pulling the latest changes, bootstrapping the project, etc. During this wait, I usually take a moment to follow-up on emails or Slack messages. But the problem with that is I inevitably end up getting pulled deeper into those tasks and forget to return to the terminal, open Xcode, and start working.
In my previous post, I explained how to use symbolic breakpoints to discover when view controllers load their views into memory. Often breakpoints are specific to a project. You’ll create one for a specific class that only exists for that particular app. However, what I discussed in that post would be useful in any project. Unlike regular breakpoints, symbolic breakpoints (at least when set on system frameworks) are more or less universal.
I was reminded today of Apple’s ‘Get A Mac’ ad campaign from the early 2000s (thanks to Jeff Johnson’s recent post). Now well over a decade old, those Mac vs PC commercials depicted a “Mac” played by Justin Long and a “PC” played by John Hodgman. They were incredibly popular and entertaining — and successful. I remember getting my very first MacBook around the time this campaign started.
I finally upgraded to macOS Ventura recently — about a month ago. As usual, I waited until the first point release, 13.1 (22C65). Although I have experienced few severe issues with upgrading over the past few years, a couple of bad experiences and others’ reports of bugs leave me skeptical and apprehensive each year. I miss the old days of OS X when I would upgrade on day one without any concerns at all.
The main appeal of building apps in SwiftUI is being able to share UI code across platforms, in particular iOS and macOS. It is not perfect and you often have to do some #if os() checks, but when it works it is truly great. Before SwiftUI was around, you could already share a lot of (non-UI) code between iOS and macOS. Many of the system frameworks are available on both platforms, for example Foundation and Core Data. Occasionally there are API differences, but they rarely impose a significant burden.
I’m happy to share that Nimble 10.0 has been released. It includes a number of fixes, improvements, and new features. It joins the latest release of Quick. For both of these libraries, these are the first releases in almost a year.
If you develop for Apple platforms and use a third-party testing framework, you are very likely using Quick and Nimble. Otherwise, you have probably at least heard of them. I don’t use any third-party testing frameworks in my personal projects, but I have worked on teams that do. And I currently work on a team that uses Quick and Nimble, which is why it was important for me to get a recent critical bug fixed in Quick.
I previously wrote about writing a custom shell command to quickly switch between Xcodes. But recently, I needed to determine the version of Swift that is bundled with Xcode — specifically the version of Swift that is shipping with the current Xcode 13.3 beta. I was pretty sure that it is Swift 5.6, but I wanted to know for certain.
I have been experiencing bizarre kernel panics with my Mac lately. I have a 2020 Intel MacBook Pro, the last Intel model before the M1 debuted. It has generally been working fine. Despite poor software quality and numerous bugs lurking around in macOS, I rarely see kernel panics anymore. In fact, I can’t remember the last time I had a kernel panic before this issue. There have been no major changes on my machine and I’m on the latest version of Monterey.
In Swift there are 13 numeric types. Like most other programming languages, Swift provides signed integers of various sizes, corresponding unsigned integers, and a few floating-point types. But if you’ve been developing apps for Apple platforms for any amount of time, you’ll recognize another numeric type — Decimal (aka NSDecimalNumber). When we build the model layer of an app, it’s important to choose the right type for the task we want to accomplish. For example, if we are counting ticket sales for an event, then Int (or possibly UInt) would be the most appropriate type. But if we are calculating sales tax, then we’ll need to use a floating-point type. You likely know that Double is more precise than Float, but what about Decimal? When should you reach for Decimal instead?
A recent post from Tom Harrington explores the issues with optional and non-optional values in Core Data regarding how the framework interacts with Swift. It’s a good overview. You should read it. The post shares some workarounds to improve the situation, but I want to share how I solve these issues in a more robust way.
Speaking of drunk software and not being in service to our possessions, Screen Time on iOS and macOS has been shockingly buggy for me lately. It reports that I spent over 22 hours on my devices in a single day last week, and nearly 10 hours on another day this week. In both instances, a significant portion of the usage is supposedly occurring after midnight.
Well, it appears my saga of obscure errors with Time Machine continues. The first issue I had was in 2020 with macOS Catalina and “error 45”. That error was fixed (for me) in Big Sur in 2021. As of this week, the error is back, though this time on macOS Monterey.
If you are working on a multiplatform SwiftUI project, you will start accumulating #if os() checks and #if canImport() checks. Overtime, these start to accumulate and — in addition to being unsightly — they make your code much more difficult to read. When possible, I have started to encapsulate these preprocessor directives to improve code organization and readability.
As of iOS 14 and macOS 11, you can define the entry-point and app lifecycle of your app in SwiftUI with the App protocol instead of using the traditional UIApplicationDelegate protocol from UIKit. However, SwiftUI is still missing the majority of APIs from UIKit. For any serious app, you’ll need to provide an app delegate.
I’ve spent this past week diving into SwiftUI, seriously, for the first time. As you know, I’ve been keeping my eye on it since it was released, but I’ve avoided it due to a combination of hesitancy, apprehension, and just being too busy with other projects and work. However, while taking some time off from contracting work, I decided to dive in.
After I wrote and released Foil, my library for implementing a property wrapper for UserDefaults, one of the criticisms on Twitter was that a mechanism for observing such properties should have been included. I disagreed. In the post I argued that this was easy enough for clients to handle on their own, but more importantly that there are too many options for how to do this and I didn’t think Foil should impose any one of them on clients.
I’ve been following what’s going on with SwiftUI since it was released with iOS 13 at WWDC 2019 and have even taken extensive notes, but I have avoided using it. As I wrote before, I mainly wanted to avoid dealing with bugs and workarounds that might make me less productive compared to using UIKit, which I know quite well. I’m very interested in learning and using it, I’m just hesitant given some of Apple’s history, like early years of Swift. I have no doubt that SwiftUI will be the future of Apple platform development, the question is when that future will arrive. This year the framework is debuting its third major release in iOS 15. How far has SwiftUI come, and is it ready for building serious apps?
For the past few weeks I have been debating on whether or not to distribute a new Mac app via the Mac App Store or independently. I have arrived at a crossroads in development where I need to make this decision. I am mostly code-complete for my MVP 1.0 release. The question I am facing is how I want to spend the remainder of my time to cross the finish line.
I upgraded to Big Sur three months ago. I know I’m (fashionably?) late to this party, but here I am. This is the longest I have ever waited to upgrade macOS. It feels weird, considering WWDC is next week where we will see what is next for macOS. Big Sur still feels new to me, and announcing the next major release already feels too soon. I was avoiding Big Sur based on various reports about bugs and instability. There were not any ‘killer’ features I was eager to have, thus the main reason I upgraded was because Xcode 12.5 required it.
Previously, I wrote about Time Machine “error 45”, an obscure bug in macOS Catalina. I still have no idea what was causing backups to fail, nor what “error 45” means. However, I am happy to report that I think this issue has been fixed in Big Sur.
A few months ago, I shared my notes and resources for learning about compilers and LLVM. It turned out to be pretty popular and folks seemed to find it useful. So I decided to do it again, but this time for SwiftUI. However, unlike learning about compilers and LLVM, I am not declaring bankruptcy with learning SwiftUI. While I have still not written a single line of SwiftUI code, I know I eventually will.
UserDefaults is one of the most misused APIs on Apple platforms. Specifically, most developers do not handle default values correctly. In fact, I have never worked on a single production codebase at a company where this was done accurately. Most libraries get it wrong, too.
Lately, it feels like every few days someone is sharing a new Xcode tip on Twitter or on their blog. They range from hidden settings to features I simply never knew about. I started saving links and planned to add a new “Xcode tips” section to my TIL repo on GitHub to reference later. But as I started, I realized that the resulting markdown file would not be easily discoverable or shareable. I thought, wouldn’t it be nice if the iOS and macOS developer community had a single place to find and share Xcode tips?
As I continue to pursue Mac app development more seriously, I can build on and borrow from my many years of iOS experience. While many aspects of writing Mac apps are very similar to iOS, or at least somewhat familiar, other aspects are quite different. One of the big differences is testing, and deciding how many versions of macOS to support.
This post is mostly for posterity, for anyone currently experiencing these bugs on macOS, and to praise Titanium Software’s excellent Mac utility app OnyX.
The Touch Bar on my MacBook started freezing and experiencing UI glitches recently. It was completely unresponsive. At the time, the only way I knew to fix it was to reboot my entire machine, which felt ridiculous. Luckily, there is a better way.
This is a first for me. I returned to my MacBook after leaving it for a couple of hours, and it was shutdown even though I left it powered on. The machine was idle. I didn’t have any specific tasks running. I figured it might have been a macOS kernel panic, but upon rebooting I discovered that the crash was caused by bridgeOS.
I was never a fan of failable initializers in Swift. I do not think this is the correct place to fail and return nil most of the time. Of course, there are exceptions where a failable initializer is appropriate. But there is another behavior of which to be aware. When constructing a class via a failable initializer, init?() — or a throwing initializer, init() throws — the deinitializer, deinit, is not called if initialization fails or throws, respectively.
Out of nowhere today, when I tried to run pod install on my machine, it could not be found. Uh… what?
Xcode 12 was released and it includes a change to how tabs and navigation work. In Xcode 12, the tabs have their own tabs. It makes no sense to me. I know we are supposed to be nice to each other about software, but this new UI/UX is beyond incomprehensible. What made it worse is that this new “tabs within tabs” was the default setting (overriding preferences I had previously set) and I could not figure out how to restore the previous (desired) behavior.
This is a brief follow-up to the post I wrote about Time Machine failing on macOS Catalina.
While debugging some code the other day, I wanted to verify the behavior of global variables and static members in Swift. I vaguely remembered from the early days of Swift, that static let members and global constants were atomic and computed lazily — one of the many improvements over Objective-C.
I try to have only one Xcode installed at a time for simplicity and tidiness. But such a setup is rare as we often must manage stable releases and beta versions simultaneously.
Swift’s strict initialization rules are great. They help prevent an entire category of bugs that were especially common in Objective-C. However, when working with Objective-C frameworks, particularly UIKit, these rules can be frustrating.
When I first upgraded to macOS Catalina, there was a “Relocated Items” folder on the desktop. Well, actually it was an alias to /Users/Shared/Relocated Items/. This was expected, given the new “security features” in Catalina, which includes a new read-only system volume. What I did not expect was to see this folder reappear with every single update.
I’ve been working on two small libraries for building menu bar Mac apps and now they are both open source with initial 1.0 releases.
I recently wrote about using SwiftPM instead of CocoaPods, which included a list of pros and cons. While working on one of my projects that is using SwiftPM, I realized another issue with how SwiftPM currently integrates with Xcode.
Last year Xcode 11 was released with integrated support for the Swift Package Manager. For a couple of small projects of mine, I decided to try using it to manage dependencies instead of CocoaPods. Overall, using SwiftPM was a great user experience, but (as expected) it has clear shortcomings due to its lack of maturity.
I recently discovered that unit tests and UI tests for a macOS Xcode project will fail with obscure error messages if the hardened runtime is enabled. It took me awhile to realize what the actual source of the problem was, because the error messages led me in the wrong direction. Hopefully this will save you some time.
Xcode has a great UI for setting and editing breakpoints. I use breakpoints all the time while working and debugging, but I want to share another, unconventional way that I use them.
I love OmniFocus. It is an indispensable app for me and a great Mac app. For managing and organizing to-do lists and personal projects, there is nothing better. Being a great Mac app means adopting behaviors that users expect, conforming to macOS UI/UX paradigms, and for the truly great mac apps it means being scriptable. I want to share two AppleScripts that I wrote for OmniFocus to automate one of my common workflows.
I recently needed to determine when the user has manually switched between dark mode and light mode on macOS. In my menu bar app, Lucifer, the icon reflects the current appearance setting when you change it from the app — an inverted pentagram for dark mode and an upright pentagram for light mode. But there’s a bug. If the user manually changes the appearance setting from System Preferences, or if they are using the new “auto” setting in macOS Catalina, the icon gets stuck in its previous state.
Unfortunately, iCloud does not have a good reputation for being reliable, especially during beta releases of iOS and macOS. Yet a lot people still use it, often without any problems. I still use it, despite a few bad experiences in the past, because the best alternatives are questionable for other reasons. I’ve had good luck with iCloud Drive for the past few years, but I am terrified and paranoid of getting caught in the middle of an iCloud clusterfuck, so I backup what I have in iCloud periodically using rsync.
I recently released a menu bar Mac app called Red Eye. It’s free and you can download it here. It prevents your Mac from going to sleep. Yes, it is a clone of the beloved Caffeine. And yes, it is the second menu bar app that I’ve made recently. It is notarized by Apple, so you shouldn’t have any problems installing it. I hope you enjoy it!
Continuing from my previous post, there is a bug in NSStatusItem that I forgot to mention. Thanks to Michael Tsai (tweet) for pointing out this workaround.
This isn’t complicated, but I found it confusing. Perhaps I am spoiled by the more modern APIs in UIKit. When writing Lucifer, a menu bar app, I wanted to have different actions for left-clicking and right-clicking on the button in the menu bar. To my surprise, this was much more cumbersome than I expected.
I made my first Mac app — Lucifer. It is a menu bar app that allows you toggle Dark Mode on and off in macOS Mojave. To be honest, it feels like a stretch to actually call this a Mac app. It is less than 100 lines of code in a single AppDelegate.swift file and the meat of the program is an AppleScript that tells System Preferences to enable or disable Dark Mode. As an iOS developer, much of the experience was familiar. The most salient aspect, however, was learning the frustrating and obscure details of app sandboxing, the “hardened runtime”, and app notarization — altogether it was like visiting hell and giving Satan a bubble bath. Appropriate, I suppose.
Over a weekend recently I built a tiny Mac app (more on that later). What I was trying to achieve required executing AppleScript, like so many things on macOS. It seemed simple enough, but of course new app sandboxing restrictions in macOS Mojave got in the way.
When you file a radar for a bug on one of Apple’s platforms, you should (usually) always attach a sysdiagnose. A sysdiagnose provides a lot of helpful information for the person who is trying to understand how the bug happened. Amongst other things, it contains logs from various parts of the OS, and all recent crash logs. Without it, the person on the other end of your report inside Apple may not be of much help. On macOS running sysdiagnose is somewhat common, but what about iOS?
The Swift type-checker remains a performance bottleneck for compile times, though it has improved tremendously over the past two years. You could even say the type-checker has gone from being drunk to sober. To help users debug these issues, awhile back Jordan Rose added a frontend Swift compiler flag that would emit warnings in Xcode for functions that took too long to compile, or rather took too long to type-check. In Xcode 9, there’s a new, similar flag for checking expressions.
Swift is still young and ever-changing. With each release, we have seen dozens of tweaks, additions, and deletions. And there is no reason for us to think that this rapid evolution will decline anytime soon. To remind us of exactly that, the latest post on Apple’s Swift Developer Blog introduces a new feature in Swift 1.1 in Xcode 6.1 — failable initializers.