Does setting the Base SDK to the latest version really make sense?

Question

The advice from Apple is to always set the Base SDK for iPhone/iPad projects to the latest installed version of the OS. At the current time this would be iOS 4.0, although 4.0 is only just about to be released so the vast majority of users will still be using 3.X. Obviously there will be features and functions available in 4.0 which don't exist in 3.X, however I would still like to support 3.X users for obvious reasons.

Suppose I am using some 4.0 specific features. If my Base SDK is set to 4.0 and my deployment target is set to 3.1.X, my project will compile just fine. However, unless I've got specific code in there testing to see if certain features can be used, I will experience a crash on 3.1.X.

But what if I don't know that this function doesn't exist in 3.1.X? Will I only find this out by experiencing a crash on that particular screen? What if the function is buried deep within my app, or only appears in very specific situations? Or what if I'm a new developer who starts coding on 4.0, and doesn't really know the ins and outs of 3.X? I suppose the obvious answer would be to set the deployment target for 4.0, but I suspect a lot of end users will be sticking on 3.1.X for a while so that's not ideal.

Am I missing something about how this all works? Of course I need to test my app fully in 3.1.X, but it seems crazy that I don't get any sort of compiler assistance. It's really not that inconceivable that something will slip through at some point. Perhaps I can temporarily set the Base SDK back to 3.1.X every now and again?

Answer 1

But what if I don't know that this function doesn't exist in 3.1.X? Will I only find this out by experiencing a crash on that particular screen?

Yes. As the developer, you are supposed to know this stuff. The documentation contains this info for every method. Also, always read the API diffs and "What's new in iPhone SDK x.x" documents.

Answer 2

Setting the base SDK to iOS 4 allows you to take advantage of the latest features introduced by iOS 4. This does not mean in any way that you are forced to use them. Setting your deployment target to 3.1.x allows you to develop using 3.1.x features on devices running 3.1.x and higher, including iOS 4.

If you want to support both iOS 4 and 3.1.x, then it's up to you to check that every single method you invoke is ok for the device you are running on. This requires using preprocessor macros, some test to verify that a class responds to a selector etc. You need to read thoroughly the documentation to discover deprecated methods, new methods added etc. While I understand that this process may be tedious and error prone, I also note here that really there is no other way of supporting both 3.1.x and 4.0 in a single application: if you want to develop free of hassle, you may always release different versions of your application targeting different OSes, but I strongly advise against this kind of practice. The situation apperas instead to be diffrent in the case of iPad applications: some developers are releasing universal applications, while others, prefer to release a different version targeting specifically the iPad device.

Having said that, given that iOS 4 is a free upgrade for all of the users including iPod touch users, I believe that all of them will upgrade to iOS 4. Unless you have a serious reson to continue supporting 3.1.x you should switch as soon as possible to iOS 4. Since the majority of applications are going to fully support iOS 4, this is another incentive for the user to switch in the next few days to iOS 4.

Answer 3

There are two variables here: there's the base SDK and the deployment target.

You set the base SDK to the lowest version of the SDK that has all the features that you want to use. For example, if you have an iPad application that also runs on an iPhone, you'd set the base SDK to 3.2.

The deployment target is the lowest version that your app will run on. So in the above example you'd set the target to something like 3.0.

To use classes that are in some versions of the SDK but not others there are a bunch of methods/functions, such as NSClassFromString and respondsToSelector:.

And how do you know which methods exist in each version? Well, the documentation tells you when each method was introduced and if/when it was deprecated. Of course you also need to test the code.