turing complete with a stack of 0xdeadbeef
I mostly write about Swift, Objective-C, iOS, open source, and other software development topics. Sometimes I write about the ethics of tech, labor, and politics. I also write satire pieces, personal essays, and notes on what I'm currently reading.
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.
Welcome to the third part of my going indie series! In the previous post, I discussed building a foundation, getting started, and finding clients. In this post, I am going to discuss many of the decidedly un-fun administrative aspects of being freelance and contracting like saving for retirement and — everyone’s favorite — taxes. Most folks consider these topics to be boring and tedious, but understanding them is critical to your success. The best approach is one of curiosity. As a software developer, you might find the task of optimizing (and minimizing!) your tax burden to be an interesting problem to solve — I definitely do!
In UIKit, UITableViewCell has a customizable accessory view. You can use one of the few accessory options that is provided by iOS by setting the accessoryType property, or you can provide a custom view using accessoryView, which can be any UIView. The equivalent of constructing a UITableViewCell with a chevron accessory in SwiftUI is using a NavigationLink. Unfortunately, however, SwiftUI does not provide an API to customize the accessory view for a NavigationLink — you are stuck with the default chevron.
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.
Xcode 15 introduces a new “bookmarks” feature, which lets you bookmark lines or entire files. It is a welcome change that has sherlocked my hack for using breakpoints as bookmarks.
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.
Welcome to my next post on going indie! In the previous one, I provided a high-level overview and introduction, and answered some of the most common questions I get from folks. In this post I’m going to dive deeper into how you can prepare to go independent, how to find clients, and other tips.
I recently asked on Mastodon for tips on estimating your total number of RSS subscribers. It turns out it is rather easy to do. While I do have (privacy-aware) analytics for my site, this only tracks page views.
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.
A number of folks have reached out to me recently (and over the years) asking me about my experience going indie. I originally wanted to write this reflection after my first year, but I could not find the time nor motivation. The early days of the pandemic really drained me. However, I hope these past three years of experience will only make this post more valuable to those seeking to do the same thing I did. I am writing this for anyone who is interested in trying to go independent — either with your own app development business, solo contracting and freelancing, or both.
Whether you are starting a new job or joining a new project, getting oriented in a new iOS codebase can be difficult and overwhelming. It is particularly hard if the codebase is very large, and especially challenging if you are early in your career and do not yet have much experience to draw from.
I grew up in the 90s and early 2000s. I was a skater kid and when I wasn’t skateboarding I was playing Tony Hawk’s Pro Skater on my Playstation. That scene introduced me to punk music, which eventually led me to hardcore music. By my early teens I was going to shows nearly every week with my friends.
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.
While working on a very large iOS client project, I was investigating the causes for our slow app launch time. We had a hypothesis that part of the problem was that too many view controllers were getting loaded in memory, in particular, ones that were not even being presented to the user during app startup. What could cause view controllers to load too early? How might you discover this happening? And how do you fix it? Let’s find out.
When I wrote about joining Mastodon, I said I would stay on Twitter for the moment and see what happens. Well, unsurprisingly, the service has continued to erode. It really is a shame, because I’ve found the software developer community there very helpful over the years. I met a lot of friends on Twitter, and later met them for the very first time in person at WWDC.
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.
After upgrading to macOS Ventura, I decided to upgrade my Ruby version and ran into issues trying to build my site locally.
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.
If you have ever worked on an iOS app, you have definitely used UINavigationController. It has been around since iOS 2 and is a fundamental component in UIKit. Yet, there is one very powerful API that you might not know about.
If you follow me on Twitter, you’ve likely noticed that my blog posts are automatically tweeted for me. There are multiple services you can use to do this, like Zapier and IFTTT. I use both services for various automations. Each has built-in actions for listening to an RSS feed and then tweeting new items as they appear. Sadly, neither service has a built-in action for Mastodon. However, we can achieve the same results with a generic webhook action on both platforms.
I finally decided to create an account on Mastodon. You can follow me at @jsq@mastodon.social. I put this off for so long because I was skeptical and I did not want to manage another social account, but it has turned out to be pretty fucking awesome.
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.
On iOS the operating system employs a watchdog that monitors for and terminates unresponsive apps. If your app is blocking the main thread for too long, the system will kill it. In crash reports, you can identify watchdog terminations via the termination reason code 0x8badf00d (“ate bad food”).