Incidentally, Dali Clock is back in the app store, for now.
In order to debug my XScreenSaver port, I had to tithe Apple the usual $107 in order to have the "privilege" of debugging software that I wrote on hardware that I own.
If you let your "developer" membership lapse, they lock out all of your old apps. Even if those apps have already been approved, and haven't been modified in years, they stop letting people download them. It would cost them exactly nothing to have just left it there. They had already approved that exact binary, and on my dime. They disabled it purely for extortionary purposes. Fuck you, Apple. You are dicks.
But once I renewed, it came back to life, so if you don't have a copy already, get it while you can because it will presumably vanish again in 12 months when I next find that I have no other reason to pay them.
The iOS XScreenSaver port is basically done, except for the minor detail that it won't run outside of Xcode. If I run it under Xcode targeted at my devices, I can run it perfectly on my iPhone or iPad. But then I hit "stop" in Xcode, and launch that same app manually on the device, and it gets a SEGV as soon as it tries to load one of the bundles inside the app:
strcmp + 0
ImageLoaderMachO::parseLoadCmds() + 54
ImageLoaderMachOCompressed::instantiateFromFile(...) + 296
ImageLoaderMachO::instantiateFromFile(...) + 302
_ZN4dyldL10loadPhase6EiRK4statPKcRKNS_11LoadContextE + 478
_ZN4dyldL14loadPhase5statEPKcRKNS_11LoadContextEP4statPiPbPSt6vectorIS1_SaIS1_EE + 386
_ZN4dyldL10loadPhase5EPKcS1_RKNS_11LoadContextEPSt6vectorIS1_SaIS1_EE + 278
_ZN4dyldL10loadPhase4EPKcS1_RKNS_11LoadContextEPSt6vectorIS1_SaIS1_EE + 218
_ZN4dyldL10loadPhase3EPKcS1_RKNS_11LoadContextEPSt6vectorIS1_SaIS1_EE + 1144
_ZN4dyldL10loadPhase1EPKcS1_RKNS_11LoadContextEPSt6vectorIS1_SaIS1_EE + 108
_ZN4dyldL10loadPhase0EPKcS1_RKNS_11LoadContextEPSt6vectorIS1_SaIS1_EE + 262
dyld::load(char const*, dyld::LoadContext const&) + 224
dlopen + 742
dlopen + 42
_CFBundleDlfcnLoadBundle + 106
_CFBundleLoadExecutableAndReturnError + 370
-[NSBundle loadAndReturnError:] + 904
-[NSBundle load] + 16
-[NSBundle principalClass] + 40
That's my call to [NSBundle principalClass]. The bundle exists; I see the pathname it's loading, and it's the same one it was successfully loading and executing under Xcode, on this same hardware.
I'm pretty stumped on how to solve this one. There's nothing like a Heisenbug that depends on whether the debugger is running.
I've turned on the various malloc environment variables inside Xcode and saw nothing. (Not surprising, though; that trick never works.)