Universal iPhone/iPad application debug compilation error for iPhone testing

Question

I have written an iPhone and iPad universal app which runs fine in the iPad simulator on Xcode, but I would now like to test the iPhone functionality. I seem unable to run the iPhone simulator with this code as it always defaults to the iPad?

Instead I tried to run on the device and as it begins to run I get the following error:

dyld: Symbol not found: _OBJC_CLASS_$_UISplitViewController
  Referenced from: /var/mobile/Applications/9770ACFA-0B88-41D4-AF56-77B66B324640/Test.app/Test
  Expected in: /System/Library/Frameworks/UIKit.framework/UIKit in /var/mobile/Applications/9770ACFA-0B88-41D4-AF56-77B66B324640/Test.app/TEST

As the App is built programmatically rather than using XIB's, I've split the 2 device logics using the following lines in the main.m method:

if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
{
    retVal = UIApplicationMain(argc, argv, nil, @"AppDelegate_Pad");
}
else
{
    retVal = UIApplicationMain(argc, argv, nil, @"AppDelegate_Phone");
}

From that point forth they use different AppDelegates and I've checked my headers to ensure the UISplitView is never used nor imported via the Phone logic.

How do I avoid this error and is there a better way to split the universal logic paths in this programmatically-created app?

Answer 1

That error is being triggered because you didn't weak-link the UIKit framework. The UIKit framework in iPhone OS 3.2 added the UISplitViewController, and if you link it in as normal your application will assume those symbols exist on 3.0, where they don't.

To weak-link a framework, find your application target in Xcode, inspect it, and go to the General tab. At the bottom of that tab should be a list of frameworks, with a column for Type. Change the Type for UIKit from Required to Weak and rebuild your application. That should take care of the runtime errors.

Your conditional logic is sound, but I tend to share an application delegate and do the interface-specific layout further down the line.

(Update: 12/21/2011) As of iOS 4.2, you should no longer need to weak link frameworks to prevent errors like this. As Marco Arment describes, if you build with iOS 4.2 or later and target down to iPhone OS 3.1+, individual classes are now weak linked and should have their +class method return nil if the class does not exist on the currently running version of the OS.