Can anyone please explain the concept of iOS deployment target build setting in iOS project. I have an application which I needed to support from iOS 4.3 up till iOS 6.0. What should be my iOS deployment target?
When I set this to 4.3 it compiles well but if I change it to 6.0 I see lot of compilation warnings for deprecated methods. What is the ideal way of handling this. Shall I remove all the warnings I see on iOS 6.0 keeping in mind that it still supports 4.3 targets?
Deployment target is the earliest version of iOS that can run your application. So if you want to support from iOS 4.3 to 6.0 you should have Deployment target set to 4.3 and Base SDK to iOS 6.0.
Deprecated methods are methods that will no longer be supported in future versions of the SDK. These methods give a warning and could lead to unsafe code, because there is a better approach. Its encouraged not to use them. Sometimes, you need to run one method or other depending on the version of the OS, but this becomes out of the scope of the question ;-)
As a conclusion, the ideal depends on your product, but keep in mind that iOS users adopt new versions of the OS quite early. So I would go from iOS 5.0 to 6.0, but this is my personal opinion ;-)
The deployment target is how you specify the minimum required iOS version for your app. If you need to support iOS 4.3 and above, your deployment target should be iOS 4.3.
A "deprecated method" is one that has been marked for removal from the SDK at some point in the future. Depending on the API in question, you may have no choice but to continue using them as long as you have to target iOS 4.3.
Consider raising your required iOS version as soon as is reasonably possible so that you can take advantage of the newest APIs. This will give the best overall compatibility and performance on the largest number of recent iOS devices.
Related
I was wondering if it's possible to downgrade an app from the app store (ARM binary) to a lower version. For example if the app requires iOS 5.0 or 4.3 or later getting it to run on iOS 4.2 or 4.0.
I understand that the requirements are important as the newer version contains API linked calls only exposed on the newer iOS platform. However, I've many apps that are cabable of running on lower versions are needlessly compiled on newer versions of xcode (just a minor update supports a huge jump on iOS supported version, like iOs 4.0 -> iOs 5.0)
What I would like to do is maybe downgrade an iOS 5.0 app to iOS 4.3 app by verifying that there are no new linked functions apis and thereby adjusting the plist files to the lower vesion? Can otool or class-dump help with this?
Yes, it's possible. Submit a binary with a different "iOS Deployment Target" (in Project > Info and Targets > Deployment Target), even if it is lower than the one you currently have.
You'll need to do extensive testing to make sure your code runs on the various compatible iOS, since a lot has changed with the release of iOS 5 (and subsequently, 6), meaning a lot of functions and methods will not be recognized in those iOS versions.
Regarding finding which API's may not work, here's a small discussion of [Finding unsupported API's with OS version][1]
[1]: finding unsupported apis with os version "Finding unsupported API's with OS version".
I am a beginner Apple developer and I have some issues I would like to resolve.
First of all, I am curently working on Xcode 3.2.6 because I haven't enrolled for the developer program yet. I would like to know if Apple only accepts apps (for the App Strore) compiled on SDK 4.
Secondly, I want my apps to work both on iPhone 3 and 4. What would you advice me to do? I have read in several developer forums that in order to achieve this I have to build my application with 3.1 iOS as a target. Is this correct?
Finally, is there any problem due to the difference in resolution between iPhone 3 and iPhone 4? Which resolution do you think I should use?
Thank you in advance,
Cherry
Set Base SDK to latest (4.3).
Set Target SDK to 3.1.
Avoid features available only in iOS 3.2 or later (e.g., don't use blocks, don't frameworks introduced in iOS 3.2 or later, always check availability of methods). Later, when you get more experience with Objective-C, you may try to combine features of more modern iOS, but still keep compatibility with older iOSes.
Don't worry about resolution. It affects only images – if you want to take full advantage of Retina display, then you will need to create images for both resolutions (std. and hi-res).
P.S. I suggest you to avoid support for iOS 3.2 or earlier. iOS 4 introduces a lot of nice and helpful features. And I pretty sure, Apple will revoke support for iOS 3.x soon after iOS 5 release.
If you are aiming for iOS 3, you will end up not using the features of iOS 4, which is the majority.
This is Apple's statement.
Target the latest iOS release.
Targeting the latest release allows you to take advantage of all the features
available in the latest version of iOS. However, this approach may offer a smaller
set of users capable of installing your application on their devices because your
application cannot run on iOS releases that are earlier than the target release.`
Target an earlier iOS release.
Targeting an earlier release lets you publish your application to a larger set of
users (because your application runs on the target OS release and later releases),
but may limit the iOS features your application can use.`
But I would suggest that you target the iOS 4 as people are now targeting iOS 5, and in another 8 months, I am sure Apple would release iOS 6 (They are very quick with their updates), and I personally feel that targeting iOS 3 is not going to give you great results in the long run.
How does the statement "The project should be compatible with iOS 4.0 and must run on iOS 4.3", effect the coding and judgment of Xcode version?
should be compatible with IOS 4.0
This means that you need to set your deployment target to 4.0 or lower. If you use any post-4.0 frameworks, they must be weak-linked, you cannot rely on them, and you must test for them before using them. Same goes for post-4.0 classes and selectors - you can't rely on them and you must test for them before using them. Simplest solution is simply to not use anything that isn't in 4.0.
must run on IOS 4.3
In general, everything that works on 4.0 will work on 4.3, so there's not much to worry about here.
Xcode version doesn't really matter. What matters is the version of the iOS SDK.
You can really use any version of the iOS SDK. Anything developed with any version of the SDK should be compatible with both 4.0 and 4.3.
If you need to use specific features of iOS 4.0 that are not available with previous versions, then you need to use 4.0 or later of the SDK.
In general, you should always use the latest version of the SDK, but set your target's properties to whatever the earliest version of the iOS is supported by your app.
It affects the earliest version of the OS (4.0) against you must test on an actual device.
Should I be developing my app for 4.2?
Always use the latest SDK. Apple won't approve any apps built against 3.x anymore.
Edit:
There's a difference between the base SDK and the iOS you plan to support. You need to use the latest SDK as I stated before, however you may still create an app that runs on older versions of iOS by not using classes and methods that have been introduced in newer releases and setting the target OS appropriately.
Unless you have the need to support older iOS devices with older iOS versions, you should develop using 4.2 as it has a lot of features that are missing in 3.x. Most importantly: 3.x doesn't support multitasking.
Also, it's important to understand the relationship between Base SDK version and deployment target. In a nutshell: you can (and should) compile against the latest SDK version but if done correctly, you can still run the app on older iOS versions.
The base SDK should always be the latest version available (4.2 as of right now). Then you can use the deployment target to specify the minimum OS that your application will support, so a good rule of the thumb would be to use 3.0 for that.
Personally, I use some of new iOS 4.0 stuff (ie. GCD) a lot in my applications. I've heard that 90% of ios users are on 4.x. That should be a good middle ground.
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.