What iPhone OS should I test before submitting to app store?

I am currently in the final stages of testing my app before submitting to app store. Testing my app means testing for memory leaks, tuning performance and fixing undesired beh开发者_JAVA技巧aviors.

Are there any guidelines of which iPhone OS should I test all the above? Latest OS is obvious but should I test perior OSs?

Basically you should test your app on the target-os and on the latest one, so if your app's deployment target is set to 3.0 you should test on a 3.0 device and on a 4.0 device.

From my experience I can tell that stuff programmed towards 3.0 usually works well on 4.0 (expeptions are AV related things, and probably other things as well, I had to rewrite my movieplayback controls to work on both os')

Also check for methods that arn't available on os 3.0 (or whichever version you're targeting). I have a lot of respondsToSelector.... calls in my code which make it look very ugly but I guess it's somewhat necessary.

Memory Leaks on the other hand won't be different between OS's as far as I'm concerned...

When I develop for multiple targets I usually test with the weakest/oldest one from beginning on, rather to ensure satisfying performance than stability.

Hope my tips help you out.

Apple doesn't seem to make API changes in bugfix releases, so your app is unlikely behave wildly differently between (say) 3.1.2 and 3.1.3. Aim to test on the latest release of each minor version that you support. That is,

• 2.2.1 (if you haven't dropped it)
• 3.0.1 (I think? Maybe it's 3.0.2)
• 3.1.3
• 3.2.1 (if you support iPad)
• 4.0.1

Also aim to test across a variety of devices, especially if you use functionality which is significantly different between devices. These aren't very well documented:

• AVCapture (the 3G supports "yuvs", the 3GS/4 camera supports "420v")
• armv6 (2G/3G) vs armv7 (3GS/4)
• Graphics capabilities (2G/3G don't support layer masking, rounded corners, or contentStretch very well)
• Video (and possibly audio) decoding (newer devices support more H.264 features)

Of course, testing takes a lot of time. There are important things to test, though:

• Make sure it doesn't crash (run through most/all of the functionality)
• Make sure fallback functionality works (get pictures from gallery if there's no camera)

A good example is image capture, which might be done using the normal UIImagePicker in 3.0, a custom overlay and takePicture in 3.1, and AVCapture in 4.0. You really ought to test on all three in that case.

Test all OS versions your app targets. If you have built your app with 3.1.3 as base target OS, test that one and anything higher.

The Docs say:

Developers are encouraged to use Xcode's new Build > Build and Archive command to create an archive of their application and its associated [.dSYM] file. This archive can then be used with the Validate Application…, Share Application…, and Submit Application to iTunes Connect… sharing options in the new Archived Application source in the Organizer. The Validate Application… and Submit Application to iTunes Connect… sharing options require an iTunes Connect account and metadata prepared for that application; Validate Application… will run all of the validation tests that will be run upon submission to the App Store so that you can fix any problems before submitting your app.

Submit Application to iTunes Connect… runs the same validation tests as Validate Application… and then, if all the tests pass, uploads your application for App Store review.