Rechnungs Checker 1.14¶
750 words on earthlingsoft
After about two and a half years, another update for
Rechnungs Checker has arrived. Most of the changes in the new version are tiny, so I never bothered to release a new version as the old one kept working just fine, but they do add up: a few UI tweaks here, a new file parser there, a 64bit binary, a new version numbering scheme there (I had to get rid of that idiotic zero in the middle) and an improved icon. Nothing earth shattering, but here it is.
I started Rechnungs Checker about seven years ago to learn Cocoa and simplify the mundane task of splitting up the phone bill because Deutsche Telekom’s website was (and still is) a monstrous mess which makes this task pretty much impossible if you like your sanity. Over time the application grew to support the online billing files created by other phone companies and Mac OS X matured a lot in the time: A lot of the code I had to write back then would be unnecessary for applications written today.
Many new APIs became available as well and Rechnungs Checker tried to keep up with those it could benefit from or be a better OS X ‘citizen’: Integration with the system-wide address book, Spotlight support or, in the latest version, support for ‘Sudden Termination’ and 512px icons. Over time the application has also grown from a PowerPC only application in 2003, to a Universal Binary running natively on PowerPC as well as 32bit and 64bit Intel machines today.
As Rechnungs Checker is a fairly simple application using standard Cocoa techniques only, those seemingly big transitions were not very complicated. In fact, I don’t think that any of them was particularly difficult from a technical point-of-view. However, those weren’t completely pain-free either as Apple’s developer documentation tends to be far less specific and complete than one would like it to be and XCode’s behaviour remains somewhat incomprehensible. If they put some more effort into those details, which are probably ‘completely obvious’ for the people who made up Cocoa and XCode, one’s sanity would benefit. None of these problems are terribly hard. But they may require a lot of fiddling to make the tools to just the right thing.
Just to add some examples to illustrate this: Think about version numbers and Info.plists. I, and, judging from other people’s projects I downloaded, many other people’s projects have severe difficulties in getting XCode to copy a new Info.plist into the compiled application, leading to things like version number confusion all over; Sometimes only a time consuming Clean action will sort that out properly. Then there’s XCode’s habit of linking the wrong libraries (just think about the pain that is Sparkle which requires you to have loads of different versions of it around for different projects, each, possibly, with different set-ups for languages, architectures and garbage-collection) which I still find unpredictable. An interesting bit of documentation-difficulty I ran into for this release was the following: My document class’ -readFromURL:ofType:error: received different type strings in the 64bit and 32bit versions, the UTI in the former and the name of the file type in the latter. Thanks to a helpful hint I learned that this is actually documented - but I would have to read the Mac OS X.5 Cocoa release notes to learn it. Definitely not the first place I’m looking at when making my application ready for X.6. Stronger cross referencing in Cocoa’s documentation or a non-useless search in the XCode documentation browser would help here.
Bonus material: Let me express how much I loathe VersionTracker/cnet or whatever they are called these days. They provided a fine service a decade ago but seemed to focus only on selling their company over and over again since. The result is a messy site with poor results. And a site which does not let me update my software listing unless I agree to them hosting my files. Which I have no intention to agree to. As a consequence I’ll have to hope that they steal the updated listing from iusethis or macupdate (let’s see whether macupdate manage updating the icon…) and I’ll be fairly sure that they’ll manage to only copy incomplete data or fuck things up otherwise when doing so. Because that’s the level of competence at which they operate. The same level of competence that turns ‘ä’s in my application description into ‘Ò¤’ - which looks a bit but not quite like a double UTF-8 fuck-up.
