|Home » Learning Curve » Developers Workshop
Through a Dark Glass with Tim
The climb up the High Sierra is treacherous.
LONDON (Rixstep) — The road to perfection is treacherous. One must continually be grateful for the crumbs that fall off the table. Not to mix metaphors.
High Sierra was a big question mark, after the stellar performance of almost every version of OS X before that, but APFS lured. Then came the crash-prone Xcode 9.2, and it was time to take a closer look.
That Xcode regularly crashes is neither new nor an encumbrance, as all we want is the underlying LLVM compiler - which, for years, had been horrendous.
But lo and behold - this one actually works! And works better!
One fondly remembers the good old days at Microsoft when the pinheads in Redmond still hadn't realised that less code means better performance. Then Dave got involved, swatted a few heads, and things were soon as right as rain again.
One can't know what went wrong in Cupertino, although many are tempted to draw Swift conclusions.
[For those who don't know, 'Swift' is a new (but incomplete) programming language devised by Apple, best described as 'Objective-C for kids'. Ed.]
A previous article touched on the discovery:
Note how binary sizes skyrocket at the time of the introduction of Apple's darling language.
Note as well how they go down again several years (five point OS versions) later. Cause for celebration?
Good code is always welcome. Therefore a Gibraltar effort at Rixstep to hop on the bandwagon - and, simultaneously, clear out the flotsam and jetsam.
The anomaly described at the above link was finally resolved. No, the app could not be built on 10.13: Apple's new fonts and sundry funky behaviour were too much.
The same holds for any app using NSBrowser cells to accommodate images. Such products have to be built on a much older system. Thanks, Tim, for keeping an eye on things.
But at least they're blazingly fast. Xfile and its friends are no longer 'one bounce launches' - they're instantaneous.
[Don't forget that the ACP is built to minimise access to secondary storage. All image files, for example, aren't even real image files anyway, and loaded once and only once for the entire 100+ app arsenal. Ed.]
Time to look through the rest of the arsenal.
All told, 106 apps in the ACP (AppleCore Project) were updated in a week, with almost perfect results. Opening and re-saving NIBs automatically converts file formats and eliminates outdated files. (Just be sure to have a backup - IB won't do that for you.)
And it's time for legacy 32-bit apps to shape up or hit the road. The ACP lost half a dozen - three Cocoa, three command-line. (They might be back later.)
The increase in efficiency is palatable. Here the listing for Cocoa apps.
The same holds for the command-line tools. Only the command-line version of CatInfo went the other way (by 36 bytes).
It's always nice when the compiler people get their act together. That's not to say the week wasn't an ordeal. Because it was.
[Remember the good old days? The ISVs begged Apple to make the dev tools open source so they could go in and fix the shit? You should. Ed.]
A few versions ago in the legacy of
Project Builder Xcode, it suddenly became impossible to add external frameworks to a project. As if no one anywhere ever needed to do that. So one was forced to 'hack' the system. The hack was simple but lugubrious.
- Copy the framework into the project directory.
- Add the new copy of the framework to the project. (Then exit Xcode just in cases.)
- Create a symlink to the original framework, and have it replace the copy of the framework.
- Open trusty Xcode and build.
That this 'issue' should remain for so long is of course inexcusable, but things like that happen all the time with Apple's dev tools. What's enervating, however, is that when they finally get around to fixing things, each and every one of the 100+ project files has to be reconfigured - manually.
Fortunately, we have tools of our own (eg Xshelf) which can speed things up considerably. But even so.
The full list of updated apps and command-line tools is 106 in number. (107 if you count the ACP Framework.)
Xfile and its friends set some new records. This is one of the nicest.
For those not mathematically inclined (what are you doing here) that means this many cells in 2/3 of a second.
[Xscan can expand the /Library hive, with ~8,600 directories and 32,792 file system items, in about a second and a half. Xfile expands the hive in less than a second. It's not about tricks and shortcuts, it's about just writing it right. Ed.]