|Home » Learning Curve » Developers Workshop
New times need new solutions.
Two days ago Rixstep rolled out the first '10.10' release for the ACP and Xfile packages. This took a lot of work, and we'll discuss that work below. For there's a point to the discussion - otherwise it'd be of little merit.
- Recent builds work fine on Yosemite with but one exception: the screen saver.
- A Yosemite rebuild of one app runs into trouble - thanks to an Apple daemon.
- The technology behind another app, previously deprecated, is now gone for good.
- None of the apps needed modification. They all use the same code as before. No code changes.
The Rorschach screen saver wouldn't run on Yosemite. The code itself didn't need to be modified; all it needed was to be rebuilt.
For an unknown reason, the notification system on Yosemite runs into trouble - but not if a legacy build is used.
They've tried to get rid of the messaging framework for years. They must be totally paranoid that it can be used to spread malware. (We did publish an article series about this.) Now the header files are gone, and what do they recommend instead? Using AppleScript to communicate with Apple Mail? Downright ridiculous.
There are chunks of code out there that attempt to duplicate the functionality, and we need but a small part of that. We would in such case use it for Outbox, but also for Clipothèque and CLIX. Now that the dust has settled and Apple seem to have gone into a stability mode in this regard, we can look at the available code. Then we'll be able to hone some of that and replace what we have now.
No Apps Modified
This is both good and bad. It's good because it means there was less work to transition to a new OS version. On the other hand, there should be little of this anyway - as long as the code played by the rules. (And you know we're known for always 'playing by the rules'.)
Most of the work (and it was considerable work) involved repairing project files from damages they incurred with earlier buggy versions of Xcode. Every project file - and we have 183 (one hundred eighty three) at time of writing - had to individually (and manually) undergo a number of fixes - all related to flaws in several previous versions of Xcode.
But application code itself should work well from one version to the next. And ours does.
Sites pop up to list apps that work with a coming version of an OS; those apps should work by default; that so many do not work by default says something about the developers involved.
At any rate: ours work. And that's a GOOD THING™.
But as stated, there's a bad thing too. Yes a bad thing. And here it is.
Binaries in general bloat by 20% for no reason whatsoever.
We were known for getting faster and slimmer binaries than anyone else out of earlier versions of OS X. Yes, there were some secrets, which seemingly only we knew. We just kept on keeping on. This advantage disappeared in 2007 with 10.6.
Using the same code, with the same LLVM compiler, but getting binaries that bloat by 20% - this is not a good thing. It's a Very Bad Thing™.
We've looked a bit into the compiler itself, its author, and so forth. Suffice it to say for now that LLVM was once an independent project, but Apple bought up the project and its leader, and now that leader builds the project for Apple instead. At which point all bets are off.
This LLVM project leader also designed and created and continues to build Swift, and although we suspect there's bloat in binaries because of this, we have little to go on so far - we need to investigate first.
So why offer a new Yosemite build when it doesn't work any better than the older builds? Precisely. There are, as seen above, a few exceptions. There is even one case where a new build will not work (whilst the older one will). But if the new build is 20% bigger than the previous one - and for no reason - then there is no reason to replace older svelte binaries with new obese ones.
Such is the question going forward. The '10.10' you were given has the new (obese) binaries. They work fine what we can see. But we're likely to offer slimmer ones again in the near future. We'll either revert to the earlier ones, or we'll find a way to trim the bloat out of the new LLVM compiler. We don't like bloat, and we know you don't either.
We found an anomaly in Xstat yesterday. The program performs correctly, but an ill-advised assumption was made in the design (what we see now). We'll study the domain further and get back to you.
Rixstep software products will never use code-signing, and they will never be distributed through the Apple or any other store. The reasons are apparent.
- Only we assume responsibility for our code. Assuming that responsibility means not allowing anyone else to tinker with it or tinker with its distribution.
- This is a not-for-profit enterprise. We're not giving Apple or anyone else 30% of our net revenues.
- Code-signing is a hoax anyway, at least on OS X, and we proved this long ago, and published that proof.
- Cupertino's nod to Redmond is shameful. It's been said many times by insiders that Apple developers never 'got' Unix. We know they had to take crash courses in C, and we've seen some of their older work in P*SC*L (and it's not pretty). But what Redmond needs is not what Cupertino needs. The system itself is safe - as long as the dweebs in Cupertino stop playing around with it.
We have a lot of respect for current Apple management. We've seen good performances in other companies too of course, but Apple management have repeatedly come through - they're a well-honed organisation.
But that's management, not the developers. The managers can't understand what the developers are up to. So whatever fails is the fault of developers, not management. And we feel management, should they fully understand the issues, would object.
We have some new stuff on the board, still being designed. Such as a system for general metadata management.
The '10.10' update should work (as stated) on OS X versions 10.7-10.10. The apps were built on a 10.9 system with Xcode 5 set to target 10.7, but set to run under 10.9 or 10.10. This would appear to be the most prudent path.
Apple have made it difficult to get legacy build environments to make it possible for users to use older computers; we're fighting this as much as we can. Should we be able to get build environments for 10.6, we'll test to see if the ACP runs on 10.6 too. This will wash over onto ACP Portable.
We wish you all a very very happy holiday. See you after the New Year.
Rixstep: The ACP
Xfile: Free Test Drive
CLIX: Learn How to Fish