January 12, 2010 2:47 am
Even part-time freeware developers look forward to new OSX releases, but our software doesn’t always make the transition very smoothly. My screensaver “The Tube” is a bit of a CPU and RAM hog, so when OSX 10.6 broke it, I kind of bid it adieu and got on with other projects. After some prodding, though, I considered that faster CPUs and plentiful RAM nowadays mean this five-year-old resource hog might have new life yet.
But it wasn’t as simple as just opening the old Xcode project and clicking “Build”. This is probably because the old build designations “Development” and “Deployment” don’t really have a place in Xcode these days. (Now it’s simply “Debug” and “Release”.) Curiosity led me to create a brand new project and then add the resources and classes from my old project, then simply click “Build”. And it worked…sort of.
I also had to adapt the default class files (declaration and implementation) to match the old versions. It might have worked to add a modern build target to the old project, but in a way it was easier to do the rote work of going method by method pasting code into place. Once the resources were included, we were off to the races.
Now I’m reminded of the pleasantly hypnotic movement of the London Underground map and its gently flickering train. If you have OSX 10.6 (Snow Leopard) you can check it out here.
June 3, 2009 12:03 am
As if there aren’t enough other details to worry about, developing for iPhone has been doubly difficult for me because my provisioning certificate kept getting lost by Xcode. Exasperated, I’d delete/revoke/regenerate/reinstall, and it would work. Problem solved.
For a while. Then it would break again.
Even this Apple Developer Q&A article doesn’t mention it, but my friend Todd did: your login keychain must be the default in the Keychain Access utility’s list of keychains. And just now, when my provisioning failed yet again, I checked Keychain Access to discover that 1Password’s keychain is the default.
This is evidently a known issue, even to the application developers. The linked article mentions a new keychain format that solves the problem.
Also, it looks like new users won’t have the same trouble now as they’ll be using the new Agile Keychain format, in a file stored at ~/Library/Application Support/1Password/1Password.agilekeychain. Existing users–especially iPhone developers–should switch to this format; see the “Keychain” tab of 1Password’s preferences window.
For a lot of applications, this kind of crap would earn a one-way ticket to the Trash. But I really like 1Password, and have probably recommended it to people more than any other. I’m glad I’ve found a way for 1Password to peacefully co-exist with Xcode and iPhone provisioning.
