I have an application that I would ideally like to run on all iOS versions, however I think Apple accepts apps only from a version and above (3.0 I think, but not sure). So my question would be, what's the minimum iOS target version you can send in review (and get accepted). If anyone with greater iOS publishing experience would answer my question it would be great and maybe point out some places where I can read about it.
Many thanks!
Sometime last year, an Apple DTS employee posted (and later clarified) on the iOS Developer Forums that the App store would no longer be accepting apps with a Deployment Target lower than 3.0. That might indicate that a lower Deployment Target has or will become grounds for an app to be rejected.
I would never set the Deployment Target lower than that of the lowest OS version among the devices I plan to use to test the app before submitting it to the App Store.
Also, the installed based of devices which haven't been upgraded to 3.0 or above might be too microscopic to be worth a developer's time or effort (unless you happen to still have and use one for some reason).
ADDED in 2013: App store submission now requires that the app support the 4" display, which requires iOS 6.0 or later, which allows a minimum deployment target no lower than iOS 4.3
To back up what hotpaw2 indicated, this is from the News and Announcements for iOS Developers on June 29, 2010:
Make sure that your applications are
compatible with iOS 4. All new
applications and updates to existing
applications must be built with iPhone
SDK 4. In addition, the App Store will
no longer support applications that
target iOS 2.x.
ok... strangely Im having a hard time verifying this... but it's my belief that you must build your app with the latest base SDK (4.0), but you can target an IOS version all the way back to 2.0. Ill continue to try to verify that.
You can only build your apps with the SDKs you have installed.
Since XCode will nuke your old SDKs whenever you upgrade (unless you install XCode elsewhere), it is assumed that you will always be building using the latest stable SDK version. This is in contrast to, say, Android, which will always retain SDKs whenever you upgrade.
Your deployment target can go back as far as you want, right back to 2.0 - but you may find it difficult to actually test it on that platform! Most people would just target 3.x upwards, which gives you as close to 100% coverage as makes no difference.
Related
I have released an App in the App Store with target platform 5.1. The app also was developed using SDK 5.1. My customer phoned me and said this is crap because als the jailbroken phones aren't able to download the app yet - because there is currently no jailbroken version for 5.1.
What do I have to do? I'm coming from Android - therefore I want to be really sure what I am doing when applying an App update to ensure that it is also available for 5.0 users.
I also use a Library Project - which also uses SDK 5.1 as shown in the screenshot below.
I would be really glad about some instructions how to reduce the required version for the app and if there are some compatibility troubles/problems occurring to my code when I do this.
You should change the deployment target, in the summary tab of the target, as shown in the image:
And call your customer and tell him there is already Jailbreak for 5.1 ;)
Release App version 1.1 with deployment Target OS as 5.0 or what ever else version you want to include ...
Just found this now while researching another question, so I'm sure this has already been handled, but here's my $0.02, eight years later....
You provided a working app to the App Store. All apps on the App Store are guaranteed to work on compatible iPhones that have not been jailbroken.
If your user is doing non-sanctioned things with his iPhone, it's not really your concern. There were plenty of big-name apps which had the same problem as yours: people couldn't use the latest version because a jailbreak wasn't yet available. They had to wait until such a jailbreak was out. That's the risk you take with using a jailbreak.
The difference here is that if FaceBook or WhatsApp or whatever big-name app changed its target SDK to an iOS version that did not yet have a jailbreak, users couldn't call Zuckerberg on the phone to complain or threaten. You, as an independent developer, got the phone call.
It's a balancing act. You want to use the latest, greatest features of the iOS version, but existing users might not have the latest, greatest OS. So you have to decide what's more important: new features or supporting existing users.
I currently have an app in the app store that works for iPhone users running iOS version 3.0 or newer. My next version of the app is going to use ARC, so it will only work for users running iOS version 4.0 or newer.
According to this answer, the users will be able to download the newer version, but it just won't run when they try to run it.
Is there any way to prevent users who can't run the app from even downloading it from the AppStore?
I haven't tested this recently, but in February 2011, and iOS 4.x, I had users who couldn't download my app as there device wasn't running the required version of iOS.
They received a nice explanation message on their device, courtesy of the App Store app, when trying to download the app directly to their device.
I'd be very surprised if this wasn't still the case.
So, set the deployment target in your target build settings, and let the App Store / iTunes take care of who can install it.
That was for new installs, and it be different for updates (rather than new installs) but again I'd be surprised if this wasn't handled by Apple for the sake of a better user experience.
UPDATE
I dug out my old iPhone 3 which reached the end of the road at 4.2.1 and resynced it with iTunes - the latest apps that require 4.3 etc are ignored, and are not overwritten with incompatible versions, as I would expect.
I also tried to update my own app (I'm a developer), requiring 4.3 and above, from the store via the device itself, and got a polite pop-up alert saying the app requires iOS 4.3 and above, again just as I'd expect.
The app was previously compatible with < 4.3, and somewhere along the line I bumped up the minimum iOS version requirement, so it is definitely possible.
So, you should just set your updated app's 'deployment target' version appropriately, and it will only be updated on compatible devices.
No. A new higher minimum Deployment target will prevent a user from installing an app on a device with a lower OS version, but will not prevent them from downloading the app using iTunes on their Mac or PC, even though they can't install the update once downloaded.
I am a little curious what happens in the following situation. You have an existing app on the iTunes store (with customers) that uses iOS4, you then release an update to the app that uses a newer iOS.
folks that have upgraded to the "newer iOS" will get the update.
What will happen to those that have not updated, will they still be able to use their old iOS4 version?
Your "deployment target" is what matters. Setting the deployment target allows your app to set it's minimum required OS version. Many developers like to set that as far back as possible, unless your app depends on a features only available in a new iOS version.
Lets say you have an app compiled with the iOS 4 SDK and set 3.0 as the deployment target.
Users with iOS 3 or iOS 4 (and iOS 5) can download your app and use it.
Now you release an update compiled with the iOS 5 SDK and set 4.0 as your deployment target.
Users with iOS 4 or iOS 5 can download or upgrade your app and use it.
Users with iOS 3 that have purchased your app already cannot upgrade, but they can continue to use their existing installed version.
Users with iOS 3 that have not purchased your app yet will now have no way to do so.
Apple will only keep exactly one version of your app on the app store.
Unless they download the newer version, they will of course still be able to use the old one. It's possible however that they download the update unintentionally via iTunes on the desktop. The App Store on the device itself would check if the device's OS version is compatible with the app being downloaded, but iTunes does not, so it would replace the old version in the iTunes library, leading to the app being removed from the device when the user syncs it (because the downloaded version cannot be installed).
So, for existing apps, you should keep your deployment target as low as possible and decide at runtime which additional features of a new OS version you can use. This way, you can keep compatibility with older OS versions, but still provide additional features to those who have upgraded.
Usually (although not always), new OSes are the same as the previous ones but with new features. Older versions of apps often work with the latest OS but don't take advantage of the new features. The only problem users usually have is crash problems but it all depends on which APIs you use in your app.
Additionally, updates are never 'forced' upon a user - they are always optional. When it is a case that the app only works on a version of iOS which is higher than what the user has, then the update will not be offered to the user at all. They will still be able to use the older version that they have installed on their device. Apps have no expiry date.
If you want to retain compatibility for as many iOS versions as possible, you can set your iOS deployment target to the minimum OS you want your app to be compatible on. The SDK version number should not matter, but to support the latest iOS features, you would need the latest iOS SDK.
You will still have to check your APIs compatibility with the version you are targeting as a minimum OS. Look here and search for "API Diffs". Each document lists changes to the API for that iOS version. This will lists new and removed APIs as of that version. For example, UIPrintPaper, which is listed in the iOS 4.1 to 4.2 API diffs document, is a new API to iOS 4.2. So, when running on iOS 4.1 or earlier, the app will crash when calling that API. Using #if __IPHONE_OS_VERSION_MAX_ALLOWED <= __IPHONE_4_1 around your UIPrintPaper snipper will fix that problem.
I am getting a fat binary when I go to upload, and I want to make sure that my application can run across 3.0, well even 2.0. Is there a specific way to make sure that this will show when I go to upload. I am not using any specific iOS 4 features, and I only have iOS 4 in my xCode. How can I test different iOS version?
The only way as I could think of is test your app on real old OS version devices. Since Apple prefers its users to upgrade to new OS version as soon as possible, they don't actually provide an official way for developers to test such backward compatibility.
Another relevant questions would be, "can I downgrade my device OS version to an old one, so that I can test my app on them?" I once did a research on SO and other Apple forums, and the result I got was NO, we developers don't have a way to "officially" downgrade our device OS version. Yes there are exceptions, you can try jail-breaking and then downgrading.
For jail-breaking / downgrading your OS version, check this post, A TimeMachine taking my iDevice back to 3.1.2? .
Edited: It's actually pretty easy to make sure that users with old OS versions can downloaded and install your app. All you need to do is set the Deployment Target in Xcode to the lowest OS version you want (iOS 3.0 would be the lowest in Xcode 3.2.5).
However, you need to bear in mind that such Deployment Target only ensures that your app can be downloaded and installed on such old version OS devices. They don't ensure compatibility during runtime. You still need to test your app on real old OS devices to ensure compatibility.
I dont think u need to worry about app version 3.0 below because it is not supported anymore. but how to test on different version, make sure change the iOS deployment target as Thomas refered.
There is no currently supported way to do this.
No current Simulator or Xcode tool will ensure that an app is completely compatible with an OS version older than the SDK used. The 2.0 SDK is not compatible with the current development tools. There is no officially supported way to downgrade a device.
Furthermore, Apple no longer even accepts app submissions that have a deployment target lower than 3.0.
Even most old 1st gen devices, if you can find one on eBay, have been upgraded to iOS 3.1.3. But if you have access to an old device running iOS 3.1.3, you can use that for testing. Many developers keep an old used iPod Touch around for just his purpose.
People with devices running something older than 3.1.3 are not only a really tiny percentage of the installed base, but are very unlikely to be still buying apps for that device. Even large developers with staff and legacy hardware available for this testing rarely waste the time on this market.
Look into Project -> Edit Project Settings -> iOS Deployment Target: 3.13. And then build?
Edit according to comment: You still need to ENSURE your code is within the runtime scope, i.e. do checks like 'respondstoselector' before calling methods in question.
Now that iPhone SDK 4.0 is available for download, and iOS 4.0 will be available for consumers shortly, does it make sense to start using the new features available in the 4.0 OS?
My primary concern is that using the 4.0 features mandates that end users also update their phones/ipods to 4.0. While this process is pretty painless, is it a reasonable expect most users to update? The application itself doesn't really need anything introduced in the new OS but some of the traditional animation techniques are now "discouraged" in favor of their block-based counterparts. This is fine for me, I'd prefer to use block methods, but I'm concerned that this is a hassle for end users.
So what's the general experience on this? Do you plunge ahead with the latest and greatest or stick with the current version?
p.s. This assumes GM installs of the OS on end users when it is available - not beta.
It depends. You have at least 3 options and the best way to go depends on your app's requirements:
Your app doesn't require any iOS 4.0 APIs - you should build with BaseSDK 4.0, but set Target Deployment to the minimum version you must have (ie: 3.0).
Advantages: (1) Your app to run on any device that has at least that Target Deployment version and (2) it will support fast App switching on devices that have iOS 4.0.
Disadvantages: You can't use any APIs from after your Target Deployment version.
Your app would be better with 4.0 APIs but it would still be usable without them - if you can conditionally use 4.0 APIs either by providing reduced functionality when on pre iOS 4.0 devices or by providing similar functionality while using different APIs when on pre 4.0 devices, then you can build with BaseSDK 4.0, set Target Deployment to to the minimum version you must have (ie: 3.0) and conditionally use the iOS 4.0 API calls.
Advantages: you can run on all devices that have at least your minimum iOS version. Disadvantages: all those conditional calls can get complicated.
Your app requires some iOS 4.0 APIs in order to function - Here you have no choice. Build with BaseSDK 4.0, set Target Deployment 4.0 and use those 4.0 APIs.
Advantage: code is simpler, no conditionals for iOS version
Disadvantages: Your app won't run on iPads yet (they get 4.0 in "Fall 2010"), your app will never run on iPhones earlier than 3G (they don't get 4.0) and some iOS 4.0 features won't work on iPhone 3G.
In all cases, your Base SDK will be 4.0, your Target Deployment will the minimum that you require, and if you need a newer API you can conditionally use it if the device has it.
Just by compiling with BaseSDK 4.0 you will get fast app switching on 4.0 devices even if you don't use any 4.0 features. All apps should at least do that even if they target iOS 2.0. Don't use the 4.0 features if you don't need them and you can target a broader range of older devices and devices that haven't upgraded.
This recent answer on SO summarizes how to do this setup for BaseSDK and Target Deployment and how to conditionally use APIs to target multiple firmware versions.
The recommended configuration is to set Base SDK to highest (i.e. 4.0) and Deployment Target to appropriate version (depends what framework feature is used in your app).
Of course, the app can always check OS version and skip calls to un-supported frameworks. It is a common technique to build iPad and iPhone universal apps.
I personally usually target one major release behind (i.e., target 3.1 instead of 4.0), that usually gives me a window of "Have you updated your phone in the last year?" But depending on your application, you may be able to make use of multitasking or other features that are only in 4.0. Then, it's a matter of what you think your users will want right away. If you think they can wait a bit, see how things go; if you find a lot of users are moving to 4.0 quickly, then push out your changes.
In my opinion, if you can wait a few months to allow for people to transition into 4.0, then hold off a bit, otherwise just go ahead with the 4.0 features.
Based on my previous years stats, it took over a year for 2.0->3.0 upgrades to happen, but it was mainly the iPod touch users since Apple was charging $10 for it.
I would expect that the 4.0 adoption rate will be much quicker around, but keep in mind that the first gen iPhones/IPods aren't getting a 4.0 upgrade.
I have found that looking at the numbers of iphones/macs etc with a old vs new OSes installed does not tell you much about the spending habits of their owners.
The people that spend money at the app store are much more likely to have updated OS software.
If your app has any level of complexity, it will take some time to ship, and you will have a pretty small window where the iPad is still running 3.x.
Developing for multiple OS levels is a pain. Besides needing to run your app on iPad/iPhone/iPod, now you have to do it also with 2 operating systems. Miss checking one place where you make a 4.0 only call in rarely executed code and you get crashes.
For the long term stability of your code base, building for 4.0 only on a new app is also good. Simple is better.
I think it's safe to expect that the majority of users will upgrade as this is a free upgrade from 3.0.
It is fairly obvious that Apple are keen on getting users up on 4.0, which is why it's free.
As with a normal update, iTunes will nag about upgrading, and if you need to reinstall the phone will usually redirect to the latest version.
As you're selling an app, you can be fairly confident that your buyers have internet access, and will at least occasionally dock their phones and get the free update request. People who have updated their phones before are very likely to similarly upgrade to iOS4.
Currently, as I see it, the main motivation to stay on 3.x would be for iPad compatibility.
You should also consider how your sales are expected to look like during the coming 6 months. What is the cost of not using the latest features? Will you be able to shave down on development time or add cutting edge features by going 4.0? Can competing app leverage 4.0 features to get an advantage? Advertising it as 4.0-only might have a positive effect on the perception of the app.
There will be a certain percentage of people who won't be able to run your application because you use 4.0. The trick is to figure out if that loss in sales is bigger or smaller than the gains you get by leaving them behind.
The more buyers you expect, the more worthwhile it is to let all of them run your application. Also, are the buyers likely to be people with computer know-how? If so then they might be even less likely to stay on 3.x.
Also, keep in mind that pre-iPhone 3G phones does not support iOS4.
One more addition:
Apple is already beginning to exclude 2.0 apps from the AppStore, see https://developer.apple.com/iphone/checklist/
Yes, IMO it absolutely makes sense to make use of the new features in OS 4.0. User who have 4.0 installed will have little tolerance for apps that don't support fast app switching (and the higher resolution display of the iPhone 4, too) at the very least.
My primary concern is that using the 4.0 features mandates that end users also update their phones/ipods to 4.0.
That's not true. Supporting the new features does not require you to drop support for older OS versions. Just set the Base SDK to 4.0 and the Deployment Target to 3.x. And make sure your code doesn't call 4.0-specific methods without checking if they exist (respondsToSelector:).
progmr has already given a very good answer; one thing worth adding is some hard data:
http://www.appleinsider.com/articles/10/07/22/chitika_ios_4_already_powering_50_of_iphone_traffic.html
ie. 50% of the iphone users (that are installing and using apps with ads in them as of a July 2010) are still running versions prior to 4.0.