I'm developing an app that has its deployment target set to iOS 5.0. I've read several posts regarding the compiler complaining about using dispatch_release when the deployment target is set to iOS 6 or above, so it is not complaining for me, but I'm not sure if I need to handle this anyway. I've been testing on iOS 6 and 7 devices and I haven't seen anything weird... Could this be a problem, to not use dispatch_release or not depending on the system version running the app? Could it even be a reason for rejection when submitting the app to the Store?
Thanks!
The availability of dispatch_retain & dispatch_release depends on whether you are building with ARC and on the deployment target used, but not on the OS release the code is running on (aside from needing to be larger or equal to the deployment target obviously):
If building Objective-C code with ARC and with a deployment target of iOS 6 or greater, dispatch_retain & dispatch_release are equivalent to the -[retain] & -[release] methods and are thus unavailable in the same way as those methods are unavailable and cause compiler errors under ARC.
If those conditions are not met (e.g. you are building pure C code, not building with ARC or use an iOS 5 deployment target), dispatch_retain & dispatch_release are available and can be used unchanged (and indeed must be used to avoid leaks) and the resulting code will run fine on iOS 6 or later.
See the headerdoc in <os/object.h> for more details, or watch the WWDC2012 session on Asynchronous Design Patterns with Blocks, GCD, and XPC.
Related
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.
So there´s quite a few versions of iOS up and running on devices now, and I´ve some questions on supporting the different kinds.
If I were to release an application know, wanting to use some features in iOS 6, but don´t want to lose the iOS 5 users, is it possible to target both versions within the same application that would be available on the App Store?
What is the other option here? To skip the iOS 6 features and just target iOS 5? Will the application have full support for iOS 6 in this case?
Thank you.
iOS users upgrade faster than just about any other group. Unless you have a special user base, I do not recommend spending significant time supporting a version of iOS older than about 6 months. For many kinds of apps, even that is too long. Matt Gemmell wrote an excellent discussion of this when iOS 5 came out.
During your transition period, before you switch to the latest version, my recommendation is to build against the old SDK. Don't just set "Deployment Target." Set "Base SDK". This means you need to keep around the old SDKs and link them into your copy of Xcode because Apple will keep deleting them. Google around for how to build against old SDKs. There are lots of discussions. I'm sure there are tons on SO. There are several reasons I strongly recommend this (regardless of how long you wait to upgrade):
It is somewhat rare that you can actually provide a feature in the newest version that you don't in the old version. Most of the time you wind up having to provide it in the older version in some form. That means you now have two versions of the code doing basically the same thing. Most of the time the older way is harder, but still works. Once you've written the hard method, what's the point of also writing the easy method, and then writing the extra code to choose between them?
The testing required to swap features in and out is incredibly high. It's hard enough to test features in the first place. Now test that and test not having the feature.
The compiler gives you no help when you use "Development Target." If you call a method from iOS 6 without checking that it exists, then you will get no warning. You'll just crash on iOS 5. If you use Base SDK, then the compiler will tell you when it's not available. I spoke with the Xcode team at WWDC about this. They noted that Apple recommends using Deployment Target, but admitted it's insanely fragile to use in practice.
So basically, I say stay on the iOS 5 SDK until you're ready to go to iOS 6. Then go to the iOS 6 SDK and never look back.
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.
I can't find anywhere definitively, if you build an app against the iOS 4 SDK, to thus support multitasking, does that mean the app won't work in iOS 3? If not, how can you support iOS features like multitasking but still support iOS 3? I'm sorry if there are Apple docs on this, I'm happy to read them, I just can't find them. Thank you
You can build against a 4.x Base SDK, and set the Deployment Target to 3.x.
But you have to make sure not use any of the new 4.x APIs without checking for their availability first (or you will start to run, then crash as soon as you call one of those APIs on a device running 3.x). And you will need to test thoroughly on an actual device running iPhone OS 3.x since there is no simulator support for this kind of OS portability testing.
In some cases, converting a 3.x app to also allow what is called "multitasking" under 4.x is as easy as rebuilding the app using a new 4.x Base SDK, but leaving the deployment target where it was at 3.x, and adding an applicationWillResignActive: delegate to handle both suspend and potential termination.
No it does not. iOS 3 just ignores the delegate methods that get called.
However, if you try and launch a background task, you'll have to check for the API first, otherwise yeah, you'll not run on 3.
The latest Xcode IDE requires you to target iPhone SDK 4 while dynamically handling deprecated and new functionality if you set the application to deploy to earlier releases.
So can I use new features like Blocks and still have it work on a device running iPhone OS 3.0 or 3.1 or 3.1.3?
I have not found documentation on how to do backward compatibility for previous iPhone OS versions. If you could point me to official docs which cover how this should be done I'd appreciate it.
As far as I know, blocks won't work pre-3.2 because the Blocks runtime is not included (classes like __NSStackBlock__ or whatever). Other than that, my understanding is that you can compile code with blocks if you use a new enough compiler. A solution would be to include a custom blocks runtime conditionally with your project.
While the easiest thing to do is try it, I think that they wont cause harm if present but not used (eg. you use a runtime if statement to circumvent the blocks using code on pre-4.0 devices), but they will certainly not run on pre-4.0 devices, and all of the APIs Apple provides that use blocks will be unavailable anyway. All in all, if you have a way to do something without blocks, there is no reason to have a different way to do it with blocks -- this just increases redundancies and duplicated code -- therefore if you wish to target pre-4.0 devices, you should not use blocks, but if you want/need to use blocks, don't target OSes below 4.0
Use preprocessor directives (http://developer.apple.com/iphone/library/documentation/xcode/conceptual/iphone_development/115-Configuring_Applications/configuring_applications.html) such as TARGET_OS_IPHONE to use code for different iOS versions.
No, blocks won't work on iPhone pre-3.2 without PLBlocks — and even then, whatever method is taking the block might not exist.