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.
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.
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.
The other day Slack went down and I tweeted to express my dissatisfaction and sarcastically comment that non-native apps are the future. I should have known it would get as much attention as a tweet about Elon Musk. People argued about the merits of native versus non-native app development, which seems like a never-ending a controversy. However, I really do not care which technologies are used to make an app. I only care about the quality of an app and the user experience it provides — which is the problem with Slack.
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 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.
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!
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.
You have spent countless hours, days, months, or maybe even years perfecting your app. There has been plenty of blood, sweat, and tears. Your relationships and your health have suffered through the development process. You are ready for 1.0 and the time has arrived to prepare all of your content for the App Store — app icon, keywords, description, localizations, and screenshots (and soon app previews).