Geek Answers Handbook

Pitfalls in writing an iOS application that supports iOS 3.1.3 and iOS 4.x

I would like to write an application that can run on iOS 3.1.3 to iOS 4.1. I know how to set up a deployment target and a basic SDK.

After reading the documents, Apple is heavily dependent on checking the availability of the class and / or instance response to a particular selector.

Now my questions are:

  • What happens if Apple publishes a class from 3.1.3 to 4.x? When just checking the class name, will it also be available on iOS 3.1.3? Therefore, in this version I would use a private API that I do not want. How would you check this out? Is this really a problem, or am I too worried?
  • Would you also use preprocessor characters that are defined by the iOS version?
  • In which architecture should I choose armv6 or armv7? I think armv6 also works on armv7, is this true?
  • Do I get help from the compiler if I use something in my code that is not available in iOS 3.1.3? Is he being checked?
  • Are there any outstanding errors that I should know about?

I already watched session 130 WWDC10 "The Future-Protecting Your Application", so everything said there is known.

Thanks.

+6
ios backwards-compatibility
source share
3 answers

Based on personal experience, not all of the correct answers may be, but I will try:

  • I do not think this is a problem due to the argument of private API ban. Apple prohibits private APIs (at least in part) because they don’t want things to change behind the scenes in future versions of iOS, since this is now an open API, it will be supported.

  • There is no clue. I saw how they were used for code that can run on OSX and iOS. But I don’t think that I would do it because the iOS version was detected at runtime, and compilation can really only take into account OS X vs iOS, and not 3.x versus 4.x.

  • Go with armv6 to support older iOS devices. This is not a problem with armv7. I believe that you are correct that armv7 can run applications created for armv6, but I'm not sure.

  • It depends on your platform target platform . You get warnings if you call outdated code.

  • Maybe. I had problems with iAd, but I don’t remember the features. Just check existing classes and don't forget to make your loosely coupled and create the class if necessary.

+1
source share

Note: you cannot use preprocessing characters because they are allowed at compile time. So, if you compile your application against 3.1.3 frameworks, you cannot use 4.0 frameworks, even on devices running on 4.0 (or 4.1, currently). Personally, I decided this by doing two goals.

+1
source share

In (3) separately: there is no need to choose, just create bold binary code with ARM6 and ARM7 code, which is still the default behavior. Using thumb directions depends on what your program does in most cases - ARMv6 Thumb does not contain floating point operations, so there are significant costs for floating point math. And vice versa, if you don’t have a lot of floating point math, then it’s much smarter to leave thumb mode and save memory bandwidth and cache size. ARMv7 Thumb contains floating point operations.

In your project: check the "Architecture" settings. It will probably be the "Standard (arm6 arm7)" that will generate fat.

To configure the Thumb mode (or any other settings) for each architecture, select it in the Target Info window, click the small gear in the lower left corner and select the “Add Build Setting Condition”. You can then set the value that applies to this parameter for a specific combination of SDK and architecture. So, if you are differentiating by the target processor family, then you want to do this twice by adding one value for “Any SDK” with “ARMv6” and one for “Any SDK” with “ARMv7”.

+1
source share

More articles:


All Articles