While gathering information about application compatibility with Leopard, I notice one developer, Snerdware, is struggling to keep up with the situation. They report two major problems that affect their current applications, and, with some evident frustration, blame both of them on Apple. [Note: I’ve substantially rewritten my commentary on the first issue, since I’ve learned additional information and since my main point applies to the second issue.]
The first issue affects both their products; the report here is for AddressX:
AddressX won’t startup on 10.5.0/Leopard running on an Intel-powered Mac (a log indicates “… Reason: no suitable image found. Did find: /usr/lib/libcrypto.0.9.dylib: mach-o, but wrong architecture. …”).
When we looked at the 10.5 pre-release, we encountered an OS X library issue — it installs a non-universal/PPC-only version of a library that’s critical to our applications (and, of course, all our developer systems are Intel-powered). ‘Though we filed a bug report early in October (original Problem ID: 5520955 and have now re-filed it), believe it or not, it’s still a problem with the released/commercial version of 10.5.0 (even without the bug report, you’d think that a check to ensure all binaries are universal would actually be a basic QA step — it’s one that’s easily automated!).
After corresponding with someone named Bryan D. at Snerdware and doing a little more research, I’ve learned the following things which make me more sympathetic to their problem than I originally was:
- Apple includes two versions of
libcrypto: one calledlibcrypto.0.9.dylib, and one calledlibcrypto.0.9.7.dylib, and a symbolic linklibcrypto.dylibthat points to the newer library. - In Leopard, the newer library is indeed a four-way universal binary, but the older library is PowerPC only. I originally assumed this was because only pre-Intel applications would require it, since
libcrypto.0.9.7.dylibhas been available in Mac OS X at least as far back as 10.3.9; and so Snerdware was making a mistake by linking to the older library and then complaining that it wasn’t universal. - But it turns out that Snerdware relies on features that are present in the older library (which corresponds to
libcryptoversion 0.9.6l), but have been removed for some reason from the newer library. - More strangely, Apple did include a universal binary of
libcrypto.0.9.dylibin the Intel versions of Tiger, but strangely left it PowerPC-only in Leopard. Huh? - Snerdware originally considered compiling the older library into their program, but since it’s crypto there are all kind of export regulations that come into play (and believe me, I know about this; I had to research exactly this topic at a previous job).
Hopefully this was indeed an oversight that can be fixed in a future update; otherwise, Snerdware has a problem with no easy solution, and some portion of the blame lies with Apple.
The second issue is a more fundamental problem, and one that affects nearly all Mac developers — Apple has a history of making significant changes to core system services between OS versions. I presume that Apple doesn’t do this maliciously, but there are plenty of developers who will tell you they’ve been burned by Apple changing or dropping technologies. Apparently Snerdware is once burned and twice shy:
Since we’ve previously been seriously “bitten” by Apple’s last-minute major changes to developer pre-releases, we can’t afford to take pre-releases seriously until they are near release. […]
With the imminent release of 10.5.0, we […] discovered that, even ‘though OS X’s Sync Services has the same interfaces and we’ve seen no documentation/release notes that document subtle but significant changes in behavior, we see that the behavior has changed in a way that will cause us to make very major changes to Groupcal … Given that Groupcal was working very well with 10.4, this is more than annoying for us, as well. Be angry with Apple, not with us.
[…] It’s things like this that make it much more difficult for an OS X product to be a viable business proposition.
Here I have a harder time finding sympathy. By their own admission they waited until the last minute to check whether the behavior of Sync Services had changed, and now they report to their users that their flagship product won’t be compatible until the first quarter of 2008, and point the finger at Apple?
(Luckily their target market appears to be corporate workgroups running Exchange servers, and those folks are less likely to be rushing out and upgrading to Leopard, so Snerdware may have some time there.)
If my livelihood depended on my product operating correctly with Sync Services, I wouldn’t rely on Apple keeping its behavior unchanged from release to release; I’d be booting up each Leopard seed on a non-critical system and checking things out. Perhaps I’d muster up the resources to send a developer to WWDC, where Apple encourages you to bring your code, try it out on the current seed, and discuss problems with the Apple engineers who have come up from Cupertino for the week for just this reason.
(To be fair, I don’t know that Snerdware didn’t do this; but with the “can’t afford to take pre-releases seriously” comment above, I somehow doubt it.)
And then — well, maybe Sync Services does change in the September seed and I still have a lot of work to do — but wouldn’t I’d be five weeks further along?
If you choose to dance with an elephant, you can approach it one of two ways — you can wait for the dust to settle, and then see what the lay of the land is; or you can try to be more nimble and maneuver around the elephant. We independent developers are supposed to be more nimble… aren’t we?
[But sometimes, even if you’re nimble, you can get still stepped on…]