I just released my app but I am only able to make it compatible from 4.3 and up.
When I try to go any lower than 4.3 (xcode), it says I need to add code to make this work.
Does anyone know how to do this or has any suggestions? I would like my app to be compatible with 3.0 and onwards.
Thank you very much
You have to reach the least common code, what I mean by this is that you must find all the methods that are all incompatible within all of these versions of the OS. After that you will have to find each and every of it's functional equivalents. Then you can use conditional statements to check for every version and see what fits better or you can use the respondsToSelector method inherited from the NSObject class. In the end you have to test it on each device you are targeting :P
You can run this checkup list that I have always liked.
Edit:
I think I misunderstood your question though it has already been mentioned, be sure to check your deployment target in your build settings.
Checklist:
In your project's build settings…
Did you set the "iOS Deployment Target" to iOS 3?
Did you include the armv6 architecture in both, the built and the valid architectures?
In general:
Do you link to any framework that is not supported on iOS 3?
Do you use any methods, classes or other features that have been added later?
Related
My application is compiling against Windows Creators Update (15063), but is supposed to run on a minimum version of 10586; however, some colour resources we used seem to be missing on old versions.
The exact whereabouts of failing resources are unknown (as the incompatible resources are), so temporarily, I want to give a global fallback value to eliminate crashes on old SDKs.
Is there any programmatic C# or automatic XAML way I can do it?
You could check whether certain features are available at runtime. There are many ways how to achieve that. You can read more about how to write version adaptive code for example here and here.
I am building my app using iOS 5.0 as base SDK and iOS 3.0 as deployment target.
I know I need to check for existence of methods and classes when I work with features that are not available in the earlier iOS versions, but lately I've lost a few hours on a problem just to discover I was calling a method not available in some iOS versions. I simply did not notice it was a new method and did no check before to call it. The app of course compiled with 0 errors and 0 warnings.
This is a big problem because if I forgot some other check somewhere in the app, I will not know it until I or, worst, some user will activate that specific part of code.
Maybe I am missing something, is there some compiler option I can set to detect the calls I make to methods not available in the iOS deployment target? How do you deal with such a problem?
This link might point you in the right direction. Supporting mutiple ios Versions in your apps. It explains how to deal with taking advantage of the newer ios features while maintaining backwards compatibility. Hope that helps.
The only way to check for compatibility with a prior version of iOS, currently, it to test the app on an old non-updated device running that version of the OS.
If you can't find a device that old, even just to borrow for short time, then there may not be a good buiness reason to set the Deployment target that low.
When you read the Class Reference of every object of iOS, you will find:
Available in iOS 2.0 and later.
There are a program or a way to list all function and the minimum iOS system?
How can I know if the iPhone with iOS 3.0 will run all iOS function? I can check it in runtime with respondToSelector, but can be more easy with source code?
Set your project's base SDK to iOS 3, and see if it builds.
AFAIK there is no way to list all the APIs you use in your app into one list and check that you are building past the minimum for all those APIs. You will just have to check each one, one by one. Highlight the API in Xcode, and then click escape and it will tell you very easily.
But also I have to mention that this won't be extremely necessary since you should test on the minimum OS you are building for and if it crashes at any point then you have your issue for that certain API.
I need to test for the availability of blocks at runtime, so I can handle backwards compatibility with iOS 3. Any tips?
edit:
So far I'm doing if (!NSClassFromString(#"NSBlockOperation")) {...}
Seems to be working...
You will also need to make sure to weak link the libSystem.B.dylib, set your base SDK to 4.0 and deployment target to 3.1.3, as described here.
A good overview on how to deal with iOS versioning issues can also be found in this this Cocoa with Love article: Tips & Tricks for conditional iOS3, iOS3.2 and iOS4 code
I want to update/upgrade the standard Leopard install of Sqlite3 to >3.5 to use the new sqlite_xxx_v2 methods from a Cocoa project.
I can't seem to find any information on how to do this. Does anyone have any tips or a site that outlines the update procedure.
Also is 3.5+ supported on the iPhone. I understand it's embedded so shouldn't be an issue...
What you want to do is grab the amalgamation sources from http://sqlite.org/download.html . Then just compile that into / add it to your project. You don't want to replace the system sqlite- that'll have unintended consequences in other applications. Plus, I'm pretty sure the system sqlite isn't a stock sqlite... Apple has probably made their own modifications to it that core data relies on.
You can read up on the amalgamation stuff here: http://sqlite.org/amalgamation.html , but in short: '''The amalgamation is a single C code file, named "sqlite3.c", that contains all C code for the core SQLite library and the FTS3 and RTREE extensions'''
I'd also suggest not using the sqlite calls directly, they weren't designed to be used that way (says the author of sqlite). Instead, there are a number of cocoa wrappers out there, including fmdb: http://code.google.com/p/flycode/source/browse/trunk/fmdb/ (which I wrote) :)
-gus
You don't really want to upgrade the system version of SQLite on Mac OS X. The reason is that all Mac OS X software is qualified against the versions of the packages that it includes, as built by Apple's build process. Installing a different version of a package, or even building the same version yourself but doing so slightly differently than Apple does, may result in a system that behaves unexpectedly.
Finally, if you embed a newer version of SQLite — or any Open Source library or framework included with Mac OS X — into your own application, you should be sure to integrate the Darwin changes for it from Apple's public source site. That way you can be sure you'll get as close to the same behavior as possible from the library you've built yourself as the version Apple ships, which is especially important when it comes to functionality like file locking in databases.
I don't believe i've updated my version, but it's currently at 3.4.2, and i'm able to use the new methods with the current version.
And i'm running 10.5.5 with the latest (public) iPhone SDK.
It would likely be easier to just drop the library into your project and link it in from there.