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.
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”).
One of the most important parts of software development is tracking changes. Documenting what is going into a release is necessary not only to simply know what changed and inform your users by writing good release notes, but also to track down issues when something goes wrong. If there’s a new bug or a new crash in your latest release, you need to be able to quickly find the change that introduced the problem.
This is a follow-up to my previous post regarding my website getting de-indexed by Bing, and thus DuckDuckGo. (Sorry for the delay, I’ve been away.) It turns out that a number of sites were experiencing this issue, including my friend Jeff Johnson. While I do not have concrete data on how widespread the issue was, anecdotally it appears to have been a significant problem.
I have been mostly offline for about two months. Or, at least I have not been writing here like usual, nor posting on Twitter. I have been very disconnected, particularly from work but also the internet in general, starting right before WWDC this year. I still have not watched a single WWDC video, not even the keynote. I have hundreds of unread posts in my RSS reader. And, I am a month behind on reading iOS Dev Weekly.
I wrote an essay in 2018 reflecting on the 15-year anniversary of my sister’s death. I still think it’s one of the most beautiful pieces I’ve written. Today is her birthday. Amy would have turned 35.
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.
When I first wrote about DocC, I lamented the fact that it was incompatible with static hosting on GitHub Pages. Much has changed since my last post, so let’s take a fresh look. While there have been many welcome improvements to the tool, there are a few remaining issues that prevent me from adopting it for my open source projects.