XCode 4 Setup Tips and Tricks for iPad, iPhone, iPod, Mac OS

MacOSX and iOS
1

I’m consolidating some information from another post to give you guys some tips and tricks on how I designed the XCode 4 project for my open source and MIT-licensed project “A Collection of Useful C++ Classes for Digital Signal Processing”. All the sources and project files explained in this post are available in the Google Code SVN repo, or if you are too lazy you can download the entire source tree, plus prebuilt executable installers for Mac OS X and Windows from this one link:

DSP Filters 0.9.71 full sources plus prebuilt executables for Mac OS X and Windows (.zip)

First of all it is possible for a single XCode 4 project to target both Mac and iOS. Just use Add Target and create one Mac OS X target and one iOS target. This shows the two targets in DSPFiltersDemo:

[attachment=2]multiple_targets.jpg[/attachment]

The “Mac” and “iOS” groups (yellow folders) in the DSPFiltersDemo project each have their own set of framework references, icons, and plist. The plist and icons are set independently on the target’s build properties. Control over target membership of frameworks is accomplished through the Utilities panel (the area on the right of the window). The project contains frameworks for both platforms, but each framework is only a member of the appropriate target, as seen in this image:

[attachment=1]framework_references.jpg[/attachment]

A project can also have other projects included as children. The benefit of doing this is that you can add dependencies to child projects so they will build automatically when the main project is built. It also allows you add the outputs of child projects to your Build Phases as dependencies and libraries to link with. To add the dependency, select your project and click the plus sign under Target Dependencies, and you will see choices for your child projects. To link with the static library, select your project and drag the child project’s output library file into the “Link Binary With” portion of Build Phases. This is all demonstrated in this screenshot:

[attachment=0]child_projects.jpg[/attachment]

2

If you have multiple child projects (or multiple source files) and you want to manually control which targets they belong to, it call all be accomplished by selecting the relevant files and checking or unchecking the boxes in “Target Membership” in the Utilities panel, as shown here:

[attachment=1]membership.jpg[/attachment]

For example, the .cpp files that make up the Juce amalgamation are not directly compiled, but rather included by a wrapper file. In my JuceAmalgam project, I included those .cpp files for reference so they could be opened and viewed, but I adjusted the target membership so they are not part of any target and don’t get compiled, like this:

[attachment=0]unused.jpg[/attachment]

I hope this XCode 4 tutorial expands people’s horizons and possibilities of what can be done when setting up projects that use Juce.

3

Thanks. Might actually persuade me to move to xCode 4.

Did you delve into dealing with iOS simulator and device debug and device release (c/w code signing shenanigans) targets? It’s awkward now.

Bruce

4

“As you can see, my young apprentice, your friends have failed. Now witness the firepower of this fully ARMED and OPERATIONAL battle station!” - Emperor Palpatine

Yes Bruce, anything and everything possible include debug and release deployment to iPad, iPod, iPhone, iPhone Simulator, iPad Simulator, archiving, and preparation for submission to the Mac App or iTunes store has been properly configured, double checked, debugged, and tested in the DspFilters XCode 4 projects.

If you will note in the project settings for both DspFilters and the Juce amalgamation, I have lowered the SDK requirements (frameworks are set Relative to SDK so if you change, the frameworks will auto-update) to the oldest possible SDK or target platform that will support Juce, allowing the project to work on the broadest possible set of Mac and iOS devices:

[attachment=2]build_settings.jpg[/attachment]

All of the frameworks are “Relative to SDK”. If you change the SDK setting in the Build Settings of the project, or an individual target, the framework references for the project or target will automatically update their path, as you can see in this screenshot:

[attachment=1]relative_framework.jpg[/attachment]

This is why I prefer to build my project files by hand. Everything I have described in this post is available in the DspFilters SVN repo. Including the ability to deploy to any simulator or device. If you have XCode 4 and you get my project, you can get DSP Filters on to your simulator and on to your device if you have a development provisioning profile (I got fast-tracked through the approval process and went from buying my iMac to being approved for full development and deployment, in 6 days):

Check it out:

[attachment=0]ipod.jpg[/attachment]

I have the latest iPod, iPad, iPhone all attached simultaneously using a powered USB hub, and a shell script which full-builds the entire DspFilters project for all targets, archives Mac and iOS versions, and deploys to all devices.

I hope this helps!

5

This looks great, thanks for posting, I will have to give this a spin when I get a chance. I will post my feedback after I do…

6

I updated the XCode 4 project to use .xcconfig files, which lets the project settings get shared between projects. I also broke out the filters, demo, and amalgamation each into their own project with the shared settings. This lets you easily add the DSPFilters static library to your existing project (as a child).

And, I updated the Visual Studio 2010 builds to include 64-bit targets as well as shared settings (via .props files).

This is in SVN for now, I will add new downloads later this week.

7

I have further upgraded projects for all supported IDEs (XCode 4, Visual Studio 2008, and Visual Studio 2010) to use build settings shared across projects (.xcconfig on XCode, .vsprops on Visual Studio 2008, and .props on Visual Studio 2010). This new system is powerful and well documented in files in the repo.

It is also now possible (instructions in the repo) to use my unmodified project files in your own workspace / solution, and have it use your own customized shared build settings across all your projects. You can adjust the build settings, and when you get updated project files from the DSPFilters repo, it will use your customized settings without any action required on your part.

The new hierarchy and project organization is designed to let you quickly add DSPFilters as a static library, the Juce amalgamation as a static library, or both, to your existing or new project. There are instructions for all platforms on how to make a private copy of the shared build settings and apply them to your own projects (all the projects in dspfilterscpp will inherit them automatically if the directions are followed).

Comments welcome!