Warning: long, technical post; no TL;DR.
As I’ve said a few days ago, and then explained why:
My software development activities are (now, officially and indefinitely) on hiatus.
Most of my software projects already were marked as “legacy”, and RB App Quarantine had insignificant download counts, but RB App Checker Lite continued to be reasonably popular despite the lack of updates and an increasing number of crashes after macOS 10.12 came out.
In the past years, as I was beginning to consider the possibility of making this official, I replied to a few dozen bug/crash report emails mentioning that I might have to do so. (Of course, it never crashes here on my own machines… ?) Almost everybody replied with polite wishes but also mentioned that I should publish it as open source. Unfortunately, that is impossible; see below.
My idea with the RB Utilities (including several that never were published, one of which was the first one!) was to have a common foundation for all sorts of apps that examined, or did things to, files, folders and the file system in general. Some of you old-timers may remember my very well-reviewed XRay utility, which was not only my first Cocoa app, but also brought reasonable financial returns.
I wrote the core of XRay for MacOS 10.1 during an all-nighter session at MacHack 2001, so unsurprisingly XRay proved to contain serious design flaws and did not update well as file system APIs evolved. For some time I worked on a rewrite to be called XRay II, which made heavy use of plugins for most of its functions. But I was distracted by other work and in the end decided to shelve it.
Still, the idea of plugins proved too tempting, especially as Objective-C offered so many neat facilities for it, and in early 2011 I began writing a generic RB Utility app that would be specialised into a specific utility app by incorporating a single plugin, built right into the executable (rather than being a separate code/resources bundle elsewhere). The generic app would have both a Developer ID version and a Mac App Store version. It would do the heavy lifting, such as startup, integrity/signature/receipt checking, copy protection (for the devID version), show the About Box and generally do all the common work of showing windows, scanning folders and whatnot.
My usual work style is to write the basic stuff, run/debug it, then do increasing detail in sort of a fractal way. While writing the app framework I also wrote a very simple plugin that would be the basis of my first utility, RB File Counter. It would just scan a given folder at great speed and report the number of files and subfolders inside that.
As things progressed I was not very pleased with the complex (but interesting!) details of certificates, codesigning, requirements for the Mac App Store, and so forth; and I realised also that many developer buddies were having even more problems than I had. The logical thing was to halt work on replicating the old XRay functions like counting files, changing permissions etc., and first do an app that would help me (and others) to make sure our work was in shape. This became RB App Checker, with the “Lite” added on because I wanted to either do a “Pro” version or a general consumer version; both were to be paid-for, and there had to be some infrastructure built for that.
RB App Checker Lite came out in early 2012 after over a year of work and was well received; many developers sent in suggestions and bug reports, and I was also busy keeping things updated and making sure the app was both small and fast. When I went back to testing the other utilities, some infrastructure changes proved to be not generic enough and I had to review my initial design, of course.
In retrospect my main (and usual) mistake was to heavily over-engineer parts of the code in a matter that wasn’t future-proof. The “interesting” parts were heavily optimised, obfuscated, compressed and otherwise squeezed into hyperspace, while also trying to use all available CPU cores; and some extremely paranoid parts of the code were checking other parts of the code. In fact, I showed some of the source to a very senior Apple engineer at my last WWDC; he blinked and gabbled something like “ahem, well, this is most unexpected and I’ll be interested to know if it passes the App Store code review” while backing away slowly.
So, to come back to my original point, this means that the code as such isn’t fit to be published as open source. I may disinfect and publish a few of the saner parts later in a very controlled manner. If all goes well for my eyes this year,and now that Swift is nearing ABI stability, I’ll restart the app entirely in Swift — a good opportunity to relearn how to use GitHub and (ahem) unit testing.
Stay tuned for more news…
