Latest update: July 10, 2021
Updated information regarding macOS Catalina 10.15 and beyond to include some sad, though not entirely unexpected news about my SuperCard-based apps on the Mac App Store.
Added some post-WWDC 2021 info as it relates to iKeeper Status.
Updated info in the Finance status section. Nothing major to announce yet, but slowly making progress.
My current macOS apps (Archive, Finance, and iKeeper) were created using an amazing third-party developer tool called SuperCard. Unfortunately SuperCard is a 32-bit app that creates 32-bit apps and with macOS Catalina, macOS Big Sur, and going forward, Apple now requires applications to be 64-bit in order to run. While the makers of SuperCard have expressed interest in developing a 64-bit version eventually, it remains unclear at this time if, or when, that will happen. It is certainly no easy task to rewrite any app, and especially one with the complexity of SuperCard which, as a developer tool, needs to be many things to many different people. While my current apps WILL NOT RUN in macOS Catalina or macOS Big Sur, they continue to work exceptionally well with macOS Mojave 10.14.6 and earlier. If you rely on Archive, Finance or iKeeper, I can only recommend holding off on upgrading to macOS Catalina or macOS Big Sur at this time until I can bring my apps to 64-bit. I woke up to some sad, though not entirely unexpected, news today. Apple has removed my current macOS apps from sale on the Mac App Store. While I am disappointed, I can fully understand where Apple is coming from on this. I can only press forward in my efforts with SwiftUI and hope to have updates to release at some point.
When Apple first unveiled their new Swift programming language, out of curiosity, I took a look at it and was pleasantly surprised at how approachable and, at least for basic programming concepts, similar to SuperCard it was. I decided to explore this further. At the time, SuperCard was going through another update to fix a bunch of things that Apple had broken with a macOS update (something that was becoming a more frequent occurrence) and I figured reading some iBooks about Swift and trying out Xcode would be a cool way to pass some time as I waited. I soon realized that while there was some overlap of basic programming concepts, there were also a lot of new concepts that were unfamiliar and it would take me some time to fully wrap my head around them, but I also recognized that there was some merit in learning Swift and Xcode as a long-term goal. And then the SuperCard update became available and I was able to get back to work and release some upgrades for my apps. So a dual strategy took shape: I would continue to update my apps with SuperCard as I gradually learned Xcode and Swift as an eventual replacement. And then the aforementioned 64-bit requirement came along.
With macOS Catalina the plan changed. I stepped up the pace. I read more iBooks about Swift and Xcode. I conducted more involved experiments using Xcode and Swift. I found myself in a race to understand Xcode and Swift enough to completely write updates to all of my macOS apps from scratch. This was all still very new to me and so I decided to do a bit of triage. The plan was to forego some of the more advanced and secondary features in my current apps and create versions that focus on the core features starting with the app with the simplest code and working my way through to the app with the most complex code. As a result, the first project I selected was iKeeper 6 (with the plan being to follow with Finance 9 and then Archive 9).
The plan was good, but there was a disconnect between creating a user interface in Xcode (using Interface Builder, and later Storyboards) and connecting it up with Swift, and while I did have some early success (which you can see mentioned below at the start of the section on "iKeeper status"), in the end it all came crashing down. The user interface needed code that was very un-Swift-like and after months of struggle I wasn’t having much luck at reconciling those differences. It was very discouraging and I even started to consider giving up entirely.
Then came SwiftUI It was like Apple was reading my mind and I watched in amazement as SwiftUI seemlessly blended the user interface and Swift together. There was, and continues to be, some good news and some bad news. SwiftUI was something new and with that came some missing features that were not implemented yet (and some still haven’t been). SwiftUI is still evolving and so some ways of doing things have changed rather drastically. There was not really a lot of comprehensive learning materials out there, and while this has greatly improved for iOS and iPadOS, macOS is still sadly lagging behind.
One day while looking for macOS-specific SwiftUI tutorials, I came across a short video by Paul Hudson at Hacking With Swift. It covered a little bit of SwiftUI for macOS, but also mentioned a full, free, comprehensive SwiftUI course he had just released… for iOS. The video was very good, but it was also clear that I really needed something that covered things in a lot more detail to learn SwiftUI. I emailed Paul and he kindly wrote back and assured me that, while there are differences between macOS, and iOS and iPadOS, the core elements of SwiftUI are the same so I would not be wasting my time learning something specifically tailored to iOS and iPadOS. And with that, I started 100 Days of SwiftUI. I have to say, for anyone reading this that is looking to learn SwiftUI, this is a really great course and I highly recommend it.
I finished 100 Days of SwiftUI at the end of February 2021. For a few days after that I watched through some other SwiftUI videos that Paul and others had created. They now made a lot more sense. Unfortunately there is still a surprising lack information specific to macOS, but Paul mentioned to me that he is working on a macOS SwiftUI book that he hopes to release soon.
In March 2021, I altered my plan slightly. While waiting for more macOS-specific SwiftUI materials to become available, I would use what I learned in Paul's course to work on a project for iOS and iPadOS. It would be fun to see just how far I could get with iOS and iPadOS and, in theory, it would give me some working SwiftUI code that could be adapted to macOS so I’m not just sitting around waiting to start entirely from scratch. I decided to start with iKeeper and then move on to Finance as they would both make sense on iOS and iPadOS and I still like the idea of starting with the easier pieces and then building up to the more complex parts. How is the new plan going? Check out the “iKeeper status” section below…
If you must upgrade to macOS 10.15 or later, I STRONGLY RECOMMEND turning OFF password protection in my Finance and iKeeper apps (if you are using that feature) BEFORE you upgrade (you WILL NOT be able to do this after installing Catalina or Big Sur because my current apps WILL NOT RUN). There are two reasons for turning off the password protection: First, it will ensure that you can, at the very least, use any 64-bit SQLite database app to read the data you have entered into my apps (although it won’t be as organized or useful as a dedicated app, it will at least give you a way to access your information). Second, it will help you to move to a newer version of my apps built with Xcode and SwiftUI. Right now it seems highly unlikely that the first new versions of my apps will have a password protection feature at all or, even if they do, that it would work in a way that is backward compatible to what I did in my SuperCard-based apps.
I was making some progress with the plan of writing a completely new macOS app from scratch to cover the essential basic features of iKeeper in Xcode (with Storyboards for the user interface) and Swift. There were complicated things that were surprisingly easy to do, and simple things that were surprisingly complicated. But every time I started to think that things were going really well and maybe I was getting the hang of it, there consistently was something unexpected that came up and completely derailed that momentum. There were some victories, such as reading in an existing iKeeper 5 SQLite database file (without password protection), and that Swift code might end up being very useful and well worth the time it took to figure out. There were also a lot of failures and eventually the whole thing just came crashing down around me.
I’m sure if you have read all the updated information in the sections above the suspense is killing you and you're dying to hear where things stand right now with iKeeper and the new plan. I can’t contain my excitement any longer, so here it is: iKeeper for iOS and iPadOS is done!
That’s right, approximately two-and-a-half months and my first post-“100 Days of SwiftUI” project is complete. I have to admit, I was really worried and didn't say anything here as I was working on it because it was going really well and the last time I was that optimistic and included some news in this section, everything ended in complete disaster. SwiftUI constantly exceeded my expectations and I was amazed as I overcame every single obstacle that had doomed my previous efforts. Apple really got this right. That isn’t to say there were not challenges along the way. I’m still very new to all of this and couldn’t have done it without Paul Hudson’s excellent course and his SwiftUI By Example reference guide and other materials, Mark Moeykens at Big Mountain Studio with his SwiftUI Visual Reference Guide, my good friends Tomas Franzén and Chilton Webb, and others.
I even got a bit carried away with all the fun. Not only does iKeeper for iOS and iPadOS cover all the basic features of iKeeper 5, it also goes beyond to add some improvements I’ve been wanting to make and some really cool new features. Check out the little sneak peek I posted here.
Where does that leave iKeeper? I’m not planning on releasing the iOS / iPadOS version until there is a new macOS version to go along with it so existing users can import their data. As I write this, Paul Hudson has not yet released his SwiftUI for macOS book and I have not come across any other in-depth materials that fully answer my multitude of macOS-specific questions. WWDC 2021 introduced some changes for SwiftUI which I’m still evaluating but for the moment I’m sticking with the prior version to maintain support with iOS / iPadOS 14. I was also able to schedule in a couple of labs with Apple and as a result of that some improvements were made to the project. It is great to have actual functioning SwiftUI code for iKeeper that I can work with when the time comes and some of what I’ve learned in the process of writing this code and at WWDC is, at the very least, applicable to Finance for iOS and iPadOS and hopefully to macOS as well. I may still make further refinements and improvements to this code as I continue to learn about SwiftUI even as my focus right now is on Finance.
With the SwiftUI version of iKeeper for iOS / iPadOS done, I am hard at work on the SwiftUI version of Finance for iOS / iPadOS. Things are progressing rather well, though a bit slowly as I carefully consider the new interface options available to me in SwiftUI. As I mentioned in the previous section, what I’ve learned in the process of working on iKeeper has been extremely useful and applicable. When it comes to picking a date, creating some labels, adding new data, deleting data, updating data, syncing data with iCloud, displaying an overview list (including in a multi-column format on larger screens), searching or filtering that list, adding a popup a menu, managing preference options, and more, I’ve already been down this path once before (even more in some cases when including the tutorials of “100 Days of SwiftUI”). The point here is that, where there is commonality, I’ve learned things in SwiftUI that is making the process a bit easier.
That doesn’t mean that it has been entirely smooth sailing. There are features that do not overlap. iKeeper doesn’t have anything to do with formatting currency values (which I just figured out how to handle in SwiftUI after a few rather frustrating days), or managing different bank accounts or a budget for example. Things like that, and more, are challenges I am facing now and there is still a LOT for me to learn (and likely more frustration and delays ahead), but at least I didn’t have to start entirely from square one on everything.
I get it. I am an Archive user too and I would love to be able to upgrade to macOS Big Sur. I’m frustrated that work hasn’t even started on the new version of this app, or any macOS app, or has it? With the SwiftUI version of iKeeper for iOS / iPadOS complete and the SwiftUI version of Finance for iOS / iPadOS currently underway I am continuing to learn about core features of SwiftUI and gaining valuable experience every day that should be relevant regardless of platform. That said, Archive doesn’t really make sense on iOS / iPadOS and it is clear that there are unique areas of macOS that will likely require some time for me to learn when the moment comes. I wish I could say for certain that I know how this all works for macOS, but that is unfortunately still something of a mystery and, as I mentioned in previous sections above, the answers will have to wait until there are more materials available that explain this in detail for me to delve into.