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.
Related
How can I decide the oldest iOS version to support in my app?
Are there any kind of usage / installation statistics to make this decision easier?
Not officially, but a few of the big developers release statistics on their blogs. Instapaper is a good example. I'm sure there are more if you google around, but for me, its once a version hits 5% or less users, its ok to scrap support for it. (I recently stopped supporting iOS 3.x).
You could also check in your app and send it to a server or something to log and check your own statistics.
A tip from the other perspective. A lot of new features were introduced in iOS 3.2, even a lot of stuff that's not whiz-bang, but you might want to make use of, like gesture recognizers. You're probably likely to accidentally use a few minor features that didn't exist prior to 3.2 when coding, and then when you test on an old device you'll discover you need to rewrite that code. So I would say target at least 3.2.
Some developers are constrained by the oldest OS for which they want to keep a running and non-updated iOS test device. You should not set the Deployment target lower than the lowest OS on which you plan on doing actual device testing.
Note that you should not use raw OS user base statistics, as users of devices running older OS versions seem to be far less likely to buy or download new apps than those users who buy new devices and/or update to the latest iOS version.
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.
I have the following problem, in near future I will need to write a few not very complicated apps for iPhone. I do not currently own an iPhone, so I plan to purchase one for testing purposes. In short would iPhone 4 allow me to test apps written for older ios versions? Any pitfalls? Or would I have to purchase older phones/ipad to do the testing properly?
Yes, to perform a proper test you will need to test on the individual devices you are supporting. The documentation will tell you if the framework/API you are using is supported in the older iOS versions. I'm afraid there will be some subjective answers here as I am sure some apps end up running just fine across many versions with simulator testing. There are many factors to consider when looking at backwards compatibility (desired speed, memory usage, APIs, ...). You stated your app is "not very complicated" so you may be fine. I would test your application on as many devices as possible.
I should also make the distinction that there is a difference between "will it compile" and "does it perform as expected". You can use xcode to test whether the application is compatible by targeting and older version. Whether or not the application runs as desired will be discovered when testing on the specific devices.
You can't run iOS 3 on iPhone 4, so you have to buy separate devices.
But if it is a new app I wouldn't consider to make it iOS3 compatible. Most users have upgraded to iOS4 already. And at the time your app is in the store there will be even less users running iOS3.
Sure, this will remove like 0,5% of potential customers. But you don't want to buy another device for 100$ if you can get only 10$ revenue from the 0,5% customers that run iOS3. And you have to test your whole app again, which will take a significant amount of time.
So you should consider to drop support for iOS3.
See this question: Will an application compiled for iOS 3 run on iOS 4?
It will allow you to test apps which are targeted at older iOS versions, yes.
Performance differences to older iDevices like the 1st gen iPhone / iPod touch are quite significant however. So if your apps require expensive calculations or the like, I'd recommend buying an older, used device too to get a feeling for performance on that generation of hardware.
Note that if you need to make sure the apps you are about to develop will run on very old devices / iOS versions, you maybe need to do without some cocoa classes and methods which require more recent versions of iOS
If you bought an iPhone 4 for testing purpose.. You're testing on the latest iPhone available in the market and that doesn't means your app is ready to target low-end device automatically.
Let's take a deep look: If you've designed an App that must look gorgeous and work right out of the box on iPhone 4, then you're probably making your app a Retina display compatible. That is like playing with 960x640 resolution screen.
Now, if you planned to target low-end device for eg, iPhone 3GS, then all you gotta do is to reduce the graphic assets size by half, as iPhone 3GS is 320x480
That's it! Your App is ready for the low-end device as well, in looks and feels perspective.
Now, let's look from deployment perspective. If you base SDK is 4.2.1 and you're targeting to devices which runs 3.3, then all you gotta do is to make sure you don't use latest libraries/classes which are introduced in iOS 4.2.1, as they won't be available to device which are running on iOS 3.3. If you take care of this part, your app is almost ready to ship out.
From Market perspective. I see all the great apps out there had made their deployment target as iOS 4.0 or later. That means, they are targeting to only devices which runs iOS 4.0 or later versions.
I think, you can try your build in low-end iPhone simulator after successful testing cycles ran on iPhone 4 device. :)
The iPhone is generally not backwards compatible. Sometimes methods, properties, classes etc. are added or older ones become deprecated.
For testing, i would recommend that you have several devices with different iOS Versions depending on the target iOS Version you want to release.
Also check the the iOS Reference Library: Under "Availability" for each function etc. is noted since when it is Available
The new OS (3.0+) adds more features which speed up the development (like working with the lists etc). On the other hand there could be (potentially) a lot of users somewhere still running OS 2.2.
Is there any place to look for statistics? Could someone offer an advice on the target OS for a new iPhone app scheduled for Christmas release?
Based on Admob data, adoption rates of the earlier SDK releases have been pretty good in past. It takes a couple of months to reach over 60% adoption. See Admob stats
On the otherhand, I just saw another Admob report, which indicated that iPod Touch users are more likely to buy apps and they are not that likely to upgrade.
However, I'd bet on 3.0 for Christmas market and next year, if you need something from 3.0 SDK.
Given this data, if you're only supporting iPhones there's no reason not to go 3.0 only. If iPod touches are an important part of your audience, it may by a harder decision.
However, I'd wager that the people willing to pay for your app are also willing to pay for the 3.0 upgrade for their iPod touch, so they can get the latest and greatest app.
Finally, in my opinion, if there's a significant draw to 3.0 for development reasons, I'd say go for it. I'm writing a 3.0 iPhone app at the moment, due for release in the next few weeks, and I didn't even consider 2.x - Core Data is too much of a draw for me, even though I can achieve persistence with SQLite.
It depends. If you want to take the advantage of the new features you must use the SDK 3, if you don't need them you can just stick to the old one.
The problem why users stick to old soft has two sources in my opinion:
iPod Touch users needs to pay for the upgrade and not all of them will want to do that
iPhone OS 3.0 is significantly slower then 2.0, it has some nice adds but it's so slow that sometimes I regret upgrading my iPhone 3G (I think it's less noticeable on 3GS)
I am an iPhone newbie just starting to develop a new iPhone app, and I am wondering if it is better to stick with the 2.2.1 SDK right now or should I actively use features of the 3.0 SDK to build the app? Of course it needs to eventually run on both 3.0 and 2.2.1 devices, so I need to test it on both. But the question is whether there are cool new things in the 3.0 SDK (Xcode and Interface Builder features) that makes it worth using even if I am targeting 2.2.1. For example, I would need to avoid using anything that relies on new 3.0 APIs, but maybe there are still cool new widgets or something that work fine with the 2.2.1 APIs. Is that the case or not? I'm just trying to figure out where I put my focus... 3.0 or 2.2.1.
All apps submitted to the AppStore now have to be 3.0 capable. Luckily the iPhone market is pretty cutting edge and will get the updates. If they are downloading apps, they are probably updating their OS.
If you are planning to launch your app immediately I would say go with 2.2.1 but if you are looking out greater than 3-6 months then go with 3.0 stuff. There are lots of great things in 3.0 such as virtual goods, apis to control itunes music and other benefits. If you app requires features of 3.0 just start developing for it now. 1.0-2.0 seemed to take about 3-6 months for people to update.
Start using the new features but you can't release an app yet for 3.0.
In short, do both. There is plenty of power in 2.2.1 to get your app out the door. Then you can add enhanced features that will improve the experience as 3.0 is officially launched.
I would focus on 2.2.1 for now because that is the most important currently. Make sure it works on OS 3.0 though.
You should use 3.0 - it will be released in one week, and practically everyone will upgrade straight away.
iPhone 3G owners get the OS update for free via iTunes and will probably upgrade almost immediately. iPod Touch users have to pay and the improvements aren't very compelling for iPod users. So there is likely to be a split in the audience for your app if you target 3.0 for a while at least. Eventually so many apps will come out needing 3.0 that Touch users will be forced to upgrade and then it's not such an issue.
Of course, if the 3.0 feature makes your app that much more compelling, go for it, but a lot of app concepts don't of course.
Actually apps submitted to the store need to be 3.0 capable, but that doesn't mean they have to use 3.0 features not available in older versions.
I would actually suggest that you stick to features that will add to your application regardless of them being new to 3.0 or not, and not just add the "new 3.0" features because they are cool or new. Add what your application needs to be successful and nothing more. the less requirements your application has, the more potential customers you have.