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.
Related
I am going to develop an Iphone application in IOS8.But I have no idea whether it will work on IOS7 and IOS6.Can anyone clarify my doubts with clear explanation?
Thanks & Regards
Sam.P
It would only support the older OSes if you didn't use any features exclusive to the newer OSes, and if you targeted the old OS when building the application. There is nothing stopping you from doing so, except that you will miss out on a lot of the new technologies (and adoption of recent iOS versions is very high traditionally among Apple's customers, so it isn't a huge issue generally to only support the latest version).
You must make this decision before you publish your app, the earlier the better. You can support all OSes starting from 6 and only use APIs and features available in 6. Or use all the new features of the 8 and make the app incompatible with the earlier versions.
Each published app has a target OS version. If you specify 8 then users with earlier OSes simply won't see your app in the app store. However it's not sufficient to set your target to 6 to support earlier system. You must be careful in using the APIs: each has a documented version where it became available. And you must test, at least in simulators with different OS versions. iOS 6 simulator is still available as a separate download for Xcode 5. I'm not sure about Xcode 6.
iOS 7 adoption wasn't as overwhelming as with earlier updates because Apple made big changes in the UI. So the iOS 6 user base is still significant. I think it still makes sense to support iOS 6 for a new commercial application.
The skinny: my app works excellently in iOS 5.x. However, certain features do not work so well in 4.x. All is resolved with an update to 5.x.
Option 1 - Good programmer: find out what was done in my app with these particular features and why they don't work in 4.x.
Option 2 - Lazy programmer: detect the version of iOS the user is running (I'm already aware that this is not advised) and suggest they upgrade if it's older. Even further, lead them to Settings/Software Update through the use of iPhone URL (eg: iossettings://).
Your advise is greatly appreciated.
This question may not suit StackOverflow very well, but I'll provide my thoughts. Support the platform or don't support the platform. If you don't support iOS 4, then don't support it and compile the app to require iOS5. If you do support it, then fix the bugs. Don't support it but nag the user. That's just lazy as you say.
Many apps have already moved to iOS5-only. Unless your market is unusual and is particularly likely to have iOS4, then I would drop iOS4 support and move on. The time you waste supporting it won't translate into enough sales to cover it for most apps IMO. And the bad reviews you get on iOS4 will outweigh the few extra sales you might get there. Pick an audience and delight them.
Most people are running iOS 4 because their devices don't support iOS 5. Option 1 makes a lot more sense. Or just don't support iOS 4 at all.
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 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.
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.