views:

129

answers:

2

I would like to write an app which can be run on iOS 3.1.3 up to iOS 4.1. I know how to set up the deployment target and the base SDK.

After reading the Apple docs it heavily relies on checking if the class is available and/or if an instance responds to a specific selector.

Now my questions:

  1. What happens if Apple made a class public from 3.1.3 to 4.x ? When just checking for the class name it would be available on iOS 3.1.3, too? So on this version I would be using a private API, which I do not want. How would you check that? Is this really a problem or am I worrying too much?
  2. Would you also use preprocessor symbols, which are defined by the iOS version?
  3. Which architecture should I choose armv6 or armv7? I think armv6 runs on armv7 as well, is that correct?
  4. Do I get any help from the compiler if I am using something in my code that is not available in iOS 3.1.3? Does it get checked?
  5. Are there any prominent pitfalls I should know about?

I already watched session 130 of WWDC10 "Future-proofing your app" so the things said there are known.

Thank you.

+1  A: 

Based on personal experience, may not have all the right answers, but I'll try:

  1. I don't think this is a problem because of the reasoning behind the private API ban. Apple prohibits private APIs (at least in part) because they do not want things to change behind the scenes in future versions of iOS, since it is now public API, it is guaranteed to be supported.

  2. No clue. I've seen them used for code that can run on OSX and iOS.But I don't think I would because iOS version is detected at run time and compiling can really only account for OS X vs iOS, not 3.x vs 4.x.

  3. Go with armv6 so you can support older iOs devices. It will not be a problem with armv7. I believe that you are right that armv7 can run apps built for armv6, but I am not sure.

  4. It depends on your target deployment platform. You do get warnings if you call deprecated code.

  5. Probably. I've had issues with iAd, but I don't remember specifics. Just check for existing classes and remember to do your weak-linking and class-instantiation where necessary.

Moshe
+1  A: 

One thing to note: you can't use preprocessing symbols because those are resolved at compile time. So, if you compile your app against the 3.1.3 frameworks, you can't use the 4.0 frameworks, even on devices running 4.0 (or 4.1, currently). Personally, I solved this by making two targets.

Don
As far as I know, if you want to submit the app to the app store you have to compile against the most recent (non-beta) framework. So one would have all the preprocessing symbols available at compile-time or am I missing something?
GorillaPatch
Yes, you have to compile against the most recent frameworks; sorry. I meant the deployment target. You can't use the preprocessing symbols to determine which version of iOS you are running on because those are resolved at compile time and will always resolve to the deployment target.
Don
I think one has to rely on the dynamic run-time options such as respondsToSelector: or ClassFromString: with which you can check dynamically at run-time if the functionality is available.
GorillaPatch
Right, and weak link the framework, cf. http://blog.gregfiumara.com/?p=68
Don