I wanted to write a quick blog post to comment on some upcoming updates to Start Usage Meter. Before I get into these changes, I wanted to circle back to my reasoning for splitting Start Usage Meter into two branches (perpetual 2.5.8.x, and 2.6 and beyond).
Why the change?
When I first started writing Start Usage Meter: I wrote it as a native Mac app and it was built from the ground up using Apple technologies. It was built to support as many older releases of OS X as possible from its birth. This meant that the app launched with OS X Lion support, even though it was released a couple of years prior to the apps development. I chose this for two reasons: (1) I felt it was important to support users on older operating systems, especially for a utility app where some users may not be able to progress past a certain OS and (2) I wanted to challenge myself to support OS X 10.7 Lion as long as possible, while still supporting the newest releases of the Mac operating system.
This was relatively easy to do for a long time. If an API didn’t exist in an older version of macOS, then I created workarounds to create the same outcome wherever possible. The only downsides were that it took some extra work and maintenance with potentially a little less polish (e.g. base localization couldn’t be supported since I cannot target OS X 10.7 and build with base localization, which meant that I needed to create separate XIB’s for each language and maintain them all separately. This meant that each language may not be pixel perfect). Where critical API’s didn’t exist, I just didn’t display it to the user (e.g. Notification Center wasn’t available in OS X 10.7 Lion, so I don’t support it and didn’t display any options relating to it).
I continuously announced my commitment to support OS X 10.7 for as long as possible and was able to keep it up for a while. I was able to work around the lack of new API’s in some cases. As long as my tools allowed me to continue, then I would.
Then Xcode 12 was released. This new version of Xcode included the new macOS Big Sur SDK’s and offered some pretty cool enhancements. The downside? You could only target OS X 10.9 or later. I had to make a decision. Do I keep the app on an old toolset, convert to a different environment, or drop OS X 10.7 and 10.8? I ultimately settled on dropping OS X 10.7 and OS X 10.8 so I can continue to build for macOS using native tools and SDK’s; however, I decided to create a second branch of Start Usage Meter: Start Usage Meter 2.5.8, which I plan to back port critical fixes and improvements from the later versions. I will always distribute 2.5.8.x as a signed and notarized app and will do this for as long as possible. This lets me finally modernize the app.
So what’s coming?
I plan to release Start Usage Meter updates shortly for the Mac App Store version. 2.6 already has some improvements that were held back due to old OS support, such as base localization and new UI improvements.
The upcoming releases will take this much further. I plan to transition Start Usage Meter entirely to Swift and modernize the codebase. There will be big UI improvements to help it feel even more like a new modern native Mac app (it is and always has been a native app, but older OS support meant holding back on some UI improvements).
The immediate upcoming changes will have some pretty impactful UI interaction improvements, which should greatly improve the user experience.
I just wanted to provide a bit of a heads up about what to expect from updates, and provide some additional clarity as to why the OS changes were made in the first place. I can’t wait to share the updates with you, and I hope it improves the experience as intended.