I\'d like build a game for both the iPhone and iPad. As such, it would make sense to start this project from scratch as a universal app. However, iPhone and iPad currently run
This is a question that is all about managing risk. Risks include:
Only you can determine what level of each risk you're comfortable with, how likely you think each risk is, if you can mitigate each risk, and what the costs would be for any of these problems along the way.
A good post on this subject: http://cocoawithlove.com/2010/07/tips-tricks-for-conditional-ios3-ios32.html
If you're about to build a Universal App, just remember the following two source code snippets:
Using classes only if they are available on the current device
Consider this piece of code:
UILocalNotification* n = [[UILocalNotification alloc] init];
When building a Universal App, this code will lead to a runtime error on any device running an iOS version that does not know about the UILocalNotification class.
You can still support UILocalNotification in your code while maintaining backwards compatibility by using the following code snippet:
Class notificationClass = NSClassFromString(@"UILocalNotification");
if (notificationClass) {
UILocalNotification* n = [[notificationClass alloc] init];
}
This technique allows you to use classes which are unavailable in certain OS versions on devices that do support the classes.
Using methods only if they are available on the current device
Suppose you'd like to do the following:
[[UIApplication sharedApplication] scheduleLocalNotification:n];
Use the following piece of code to conditionally call the method in case it's available on the current device:
if ([UIApplication instancesRespondToSelector:@selector(scheduleLocalNotification:)]) {
[[UIApplication sharedApplication] scheduleLocalNotification:n];
}
These two techniques are probably the only things you need to know to create your Universal App. Conditionally execute your code depending on device capabilities and you should be fine.
Having said that, you still need to consider that the iPad will probably be using a different UI than your iPhone counterpart. And, unfortunately, you won't be able to test your iPad UI with the iOS 4 features until they become available on the iPad. But this shouldn't be too much of a problem: if you use [[UIDevice currentDevice] userInterfaceIdiom]
to check whether you're running on an iPad, you can prevent your Universal App from executing code that has no iPad UI yet. Once Apple releases iOS 4 for iPads, you can implement the UI, remove that check and release an update to the store.
You mainly need to do two things:
To do the first, right-click on your target and select “Get Info.” The frameworks are listed in the inspector (under the “General” tab) with a drop-down box next to them that’ll allow you to select “Weak” linking. This ensures that the app will still run if the framework is not present.
To do the second, you could do something like the following to test for the new block-based animation in iOS 4:
if ([UIView respondsToSelector:@selector(animateWithDuration:animations:)]) {
// Your awesome animation code here
} else {
// Your almost-as-awesome, non-block-based animation code here.
}
By using introspective methods such as -respondsToSelector:
, you can avoid calling something that the currently-running OS doesn’t support.
Note also that if you wanted to support iPhone OS 3.0, these same rules would apply.
Finally, it's also possible—though not advisable—to do this like so:
#ifdef __IPHONE_4_0
// Your iOS 4.0-compatible code here
#elif defined(__IPHONE_3_2)
// Your iPhone OS 3.2-compatible code here
#elif defined(__IPHONE_3_0)
// Your iPhone OS 3.0-compatible code here
#endif
Why is this not advisable? Simple: only the code for the highest-numbered iOS version will be compiled. iPhone apps aren’t compiled separately for separate iOS versions, so to get this to actually work, you would have to release multiple versions of the app.