It’s great that Xcode 4.3 packs all the SDKs and essential helper apps into its own app bundle, which makes Mac App Store distribution more practical and elegant, and brings Apple into compliance with its own rules for MAS distribution. Adapting Xcode into this form is also a prerequisite for eventually delivering an iPad version, which I continue to believe is one of those things that may be impossible in the near-term and inevitable in the long-term.
However, this radical realignment means Xcode 4.3 has surely broken something in every Mac and iOS programming book. Lucky for me that mine are still in the works, though very close to being done. I updated the “Getting Started” material in iOS SDK Development this week to handle the changed install process, which along with the new chapter on testing and debugging should be going out to beta readers Real Soon Now.
And then there’s Learning Core Audio, where the situation is a little more involved. For one thing, the Core Audio book is content-complete and copy-edited, and we are now in the layout stage, with dead-tree edition just weeks away. In fact, I have to finish going over the layouts for the last half of the book by Friday, something I’m doing with iAnnotate PDF on the iPad:
So this is the wrong time to be making changes, since we can only fix typos or (maybe) add footnotes. And that’s a problem because while Xcode 4.3 includes Core Audio itself in the OS X and iOS SDKs, it doesn’t include the extras anymore. And that breaks some of our examples.
This doesn’t hit us until chapter 8, where we create an audio pass-through app for OS X. This requires using the
CARingBuffer, a C++ class that was already a problem because many versions of Xcode ship a broken version that needs to be replaced with an optional download.
CARingBuffer lives as part of Core Audio’s “Public Utility” classes in
At least it did, until Xcode 4.3. Now that there’s no installer, there’s not necessarily a
/Developer directory. Well, there is, but it lives inside the app bundle at
Xcode.app/Developer, and includes only some of its previous contents. For the rest, we have to use the “More Developer Tools…” menu item, which takes us to Apple’s site and some optional downloads:
This lets us download the optional Core Audio bits as a
.dmg file, the contents of which look like this:
So there’s our
CoreAudio/PublicUtility folder, along with the AULab and HALLab applications that used to live at
/Developer/Applications/Audio. We use AULab in chapter 12 to create an AUSampler preset that we can play with MIDI, but apps can live anywhere, so this isn’t a real big problem.
PublicUtility does pose an interesting problem, though: where does it go? The code example needs the source file to build, and up to this point, we’ve used an SDK-relative path, which means that the project can’t build anymore, since it won’t find
PublicUtility along that path, since the SDK itself is now inside of Xcode’s code bundle. So where can we put
PublicUtility where projects can find it? A couple options spring to mind:
- Leave the path as-is and move
PublicUtilityinto the Xcode app bundle. Kind of nifty, but I have zero confidence that the MAS’ new incremental upgrade process won’t clobber it. And an old-fashioned download of the full Xcode.app surely would.
- Re-create the old
/Developerdirectory and put
PublicUtilityat its previous path. This requires changing the project to use an absolute path instead of an SDK-relative one, but
/Developeris a reasonable choice for a path on other people’s machines. It suited Apple all these years after all.
- Forget installing
PublicUtilityat a consistent location and just add the needed classes to the project itself. Probably the least fragile choice in terms of builds, but means that readers might miss out on future updates to the Audio Tools download.
In the end, I chose option #2, in part because it also works for those happy souls who have not had to upgrade to Lion and thus are still on Xcode 4.2, still with a
/Developer directory. There is, however, a danger that future Xcode updates will see this as a legacy directory that should be deleted, so maybe this isn’t the right answer. A thread on
coreaudio-api on where to put
PublicUtility hasn’t garnered any followups, so we could be a long way from consensus or best practices on where to put this folder.
For now, that’s how I’m going to handle the problem in the book’s downloadable code. This afternoon, I ran every project on Xcode 4.3, changed the paths to
CARingBuffer in the one example where it’s used, and bundled it all up in a new sample code zip,
learning-core-audio-xcode4-projects-feb-26-2012.zip. That will probably be the version we put up on the book’s official page once Pearson is ready for us.
Now I just have to figure out how to address this mess in a footnote or other change that doesn’t alter the layout too badly.