Suppose I have my project using Base SDK = 4 but set the Target OS to 3.
Now suppose that I may have used some functionality that belongs to 4, on a framework that already exists on 3.0. So, it is not a matter of using a framework that doesn't exist on 3, it is a matter of using a method that exists on 4 but not on the same framework on 3.
Is there a way to check which lines of my code are illegal on the target OS?
I ask this because when I set Base SDK to 4, Xcode will allow me to use instructions that belong to 4.0, even if the target OS is 3. This will simply make iPhone 3GS crash and will not be detected during compilation.
thanks
As far as I know there's no way of doing this from the newest Xcode.
You can install a previous version with the iPhone 3.0 SDK, build the project and check the compiler warnings. This method is not foolproof as it doesn't cover all possible cases.
And I highly recommend that you test your app in a iPhone 3.X device anyway. Some APIs behave differently, even if their signature hasn't changed.
Cocoa with Love has a good roundup of working with older OSes. I think this might answer your question:
http://cocoawithlove.com/2010/07/tips-tricks-for-conditional-ios3-ios32.html
Related
I have an iPhone app which was developed with 4.0 as the base SDK and a deployment target of 3.0. Everything was working fine.
Last week I upgraded to Xcode 4.2. Now when I open the existing project, I can't compile with a deployment target of 3.0. It compiles successfully and runs only when the deployment target is 4.0.
I get the following error when I set the target to 3.0:
Unsupported compiler 'GCC 4.2' selected for architecture 'armv7'
The compiler which I use is LLVM 3.0. I am not using ARC.
Should I go back to the 3.x SDK? Is there a way that I can support 3.x using Xcode 4.2?
Uhhh, don't?
That might sound flip but iOS 4 has achieved pretty good penetration. Looking at Intstapaper's data says it really isn't worth it. And the "accepted" answer at this stackover flow answer even suggests just supporting 4.2!
Now, of course, you may have really good reasons for wanting to support 3, perhaps you are working with an Enterprise client who needs 3. In which case, just completely disregard what I've said.
I'm building an iOS app using Xcode 3.2.5 with the Base SDK set to iOS 4.2
I know I've used some api's from 4.0 and 4.1 but not sure about whether I actually require 4.2.
According to the iOS Development Guide, "Xcode displays build warnings when it detects that your application is using a feature that’s not available in the target OS release".
So I was hoping to use the compiler warnings to derive my minimum OS requirement.
However, even when I set my iOS Deployment Target to iOS 3.0, I still don't get any compiler warnings.
I must be doing something wrong, but not sure what? Can anyone confirm that they get compiler warnings when the iOS deployment target is less than the base SDK and the code uses base SDK functions? Or do the compiler warnings only show if you link a framework that didn't exist in the iOS deployment target version?
It's behaving as expected: changing the deployment target only affects the minimum OS version you app will run on, not the maximum.
If you use the 4.3 SDK and set the deployment target to 4.0, it just means your app will hard-link any pre-4.0 APIs and weak-link any APIs introduced between 4.0 and 4.3. You have to check at runtime either for the existence of the API (e.g. null pointer for C functions) or the OS version.
The deployment target does generate Xcode warnings but for deprecated APIs: for example if you use an API deprecated in 4.1 and later and the deployment target is 4.1 or later, you get a warning, but if it's 4.0 or earlier, you don't.
It looks like what you really need in your case is the equivalent of MAC_OS_X_VERSION_MAX_ALLOWED (it's not part of the default build settings, but you can custom define it and it should override the value set by the SDK) but for iOS SDK. I'm not sure it officially exists actually: I was able to find a __IPHONE_OS_VERSION_MAX_ALLOWED but considering it starts with __, I'm not sure it's really supported.
The right solution appears to simply build against previous versions of the SDK (you can always do that in the Simulator) and you will get Xcode errors if using missing APIs.
For more info, read this technote: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html
temporarily change your base sdk to see them
Edited: for detecting new APIs that are only available in new versions of iOS, I don't think Xcode can do it automatically for us. We need to put them in our mind by ourselves. My suggested reading source:
Login into your dev account and search API diffs. These official API diffs documents should be thorough and helpful.
Check this great post on how to wrap up your code to make it compatible on lower versions of iOS:
===
Try clean your project's build folder. After that you should see warnings on deprecated APIs that your code used.
I'm wondering if I will have compatibility issues with OS4.0 if my app is built with the 4.1 SDK, or is this a non-issue?
The short answer to your question is: Use a Base SDK Version of at least 4.0 for your application and a Deployment Target Version of exactly 4.0.
I've downvoted both answers because they are wrong or at least incomplete.
When building applications there are two settings that you should be aware of:
There is the Base SDK Version which defines against which version of the SDK your application will be compiled.
There is also the Deployment Target Version which defines the lowest version of the iOS that your application requires. You can set this to as low as 2.2.1 in Xcode but the App Store will not accept versions lower then 3.1.3 at the moment.
The Base SDK Version can be higher then the Deployment Target Version. This simply means that your application is backward compatible with older version of the iOS. This also means that your app needs to make decisions at runtime to be sure not to use newer functionality when running on an older version.
For example, the MFMessageComposeViewController was introduced in 4.0 so if your app has been configured to also run on 3.1.3 then you should use NSClassFromString() to find if that specific class is actually available before you use it.
There are many questions here on Stack Overflow on how to discover available functionality so I will not repeat those techniques here.
And a somewhat important note:
Behaviour does change across OS releases. There were a pile of changes in 3.0 (we had issues with UITableView/UITableViewCell):
Some changes happened on old apps (e.g. compiled for 2.2.1). I forget what these were.
Some of them were in the toolchain (I think they changed how nibs were compiled with ibtool; it was something like setting both an image and a custom view for a UITableViewCell). This happened when we upgraded the SDK on the build server, even if we didn't touch "Base SDK"
Some of them happen only when you compiled with a Base SDK of 3.0 (UIKit automagically detects which version you've linked against and has backwards-compatability modes for some things)
Additionally, there were some runtime/C++ changes in GCC 4.2, which meant a GCC 4.2 app running on OS 2.2.1 crashed when casting unsigned int/long to float/double or using std::ostringstream. I've since added a check for GCC version.
So no, compiling with a newer SDK can result in issues — you might not want to risk it if there are time constraints (you don't have time to implement multitasking support, or you don't have time to do a complete re-test and fix all the bugs, or so). Or maybe you still want to support 2.2.1 for some strange reason (4.0 dropped 2.x "device support", which effectively made it impossible to debug apps on 2.x devices).
Usually nothing breaks across minor OS releases (discounting 3.1/3.2). I'd recommend upgrading SDKs as soon as you have the time; don't shy away from new features just because old OSes don't have them.
Depending on the APIs you will be using. Let's say you want to implemented in-app texting (MFMessageComposeViewController) and want ALL of your end-users (will be defined as EUs) to access that feature then you'll have to compile against iOS 4.0. But let's say you want the in-app texting to be optional and a "plus" for your EUs, you'll just compile your app against iOS 3.0 (let's say).
Hope I answered your question :-)
I was just wondering if anyone knows of any articles relating to upgrading an iPhone application from 3.0 to iOS4. (Thanks for this iWasRobbed).
While the application still runs on iOS4, it will not run on the iPhone 4, but does on my iPhone 3G.
When I deploy the app on the iPhone 4, the Default screen loads and it will sit there hanging. The only inclination towards a problem I get is this warning:
warning: UUID mismatch detected with the loaded library - on disk is:
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.0.sdk/System/Library/Frameworks/UIKit.framework/UIKit
warning: UUID mismatch detected with the loaded library - on disk is:
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.0.sdk/System/Library/PrivateFrameworks/DataAccessExpress.framework/DataAccessExpress
Thanks
James
James,
Apple has provided this checklist: http://developer.apple.com/iphone/checklist/
It generally should not be that big of an issue. Typically, you just set the baseline SDK as 4.0 and the deployment target as either 4.0 or something 3.0+.
If it is not running on an iPhone 4, you may wish to explain further what specifically it is doing or not doing when you attempt to run it on that device. Keep in mind that all apps (for the most part) that were designed to run on 3.0 and above will typically run well on an iPhone 4.
There might be some issues with deprecated methods, so make sure you resolve those prior to installing and running the app. You should get a compiler warning for any of those, if not check your target settings and there should be a checkbox for it.
Other than that, I'm not sure what else would prevent you without understanding further details of your project.
As additional information, you should really look into the WWDC 2010 video called "Future Proofing Your Applications" (watching it now :)
That is most likely a mismatch between what iOS your iPhone 4 is running and what SDK you're using in Xcode. The UUIDs are mismatched because the iPhone 4 is using a different version SDK to what you've coded in.
Solution, install the latest SDK and make sure your iPhone matches this. The latest out is 4.1
I had the same problem and think I have solved it because the problem has gone away.
Firstly I deleted the build folder. Then I Installed the latest version of ios (4.1 in this case) onto my iphone through itunes. Afterwards i installed the latest xcode and iphone sdk package from the apple devlopers site.
This in itself probably fixed the problem but just to be sure I added a new provisioning profile for the phone on my computer and everything worked great afterwards.
Hope that helps
Problem
I'm currently stuck trying to figure out what "iPhone OS Deployment Target" setting to use. I do not want to write conditional code right now, so I'd like the lowest version that runs my application fine.
At first I thought it would be 2.0 as I wasn't using any 3.0 features, but then i realized that AVAudioRecorder is a 3.0 API. I don't want to be manually checking EVERY function I use in the documentation.
Question
Is there a tool that will check the OS availability of each functions you call in your code to figure out what the Deployment Target should be? That tool could be a good old compiler, but the latest version of the iPhone SDK does not come with the PRE-3.0 SDKs.
There is a way for checking desired older iOS. For example: I have installed the sdk 4.1 and tested the compiling for the 3.1 target.
http://0xced.blogspot.com/2010/07/using-sdk-313-with-iphone-sdk-4.html
There is no tool to do that, testing on dedicated devices is the way forward.
Depending on what you want to do, conditional code based on the SDK version is probably a common task on iOS development. Not only because new APIs come along, but because Apple does change the behaviour of given APIs on new iterations of the SDK unfortunately. So I wouldn't be scare of branching the code when needed.
There isn't such a tool. Your best bet is to check the docs, and test on devices with different versions of the OS installed.