We are developing a project with a lot of functionality and module (Call, Chat, Update Feed and so on). It's deployment target is 7.0 to latest. This project has been developing since 2013. So there was a lot of bugs and old code. Recently this project is completed and ready to release in App Store.
But now we are finding some difficulties while testing it by QA. iOS changes many things according to it's version. We are struggling to check these changes in different versions.
For an example from iOS 8.3 the facebook sharing will have to implemented by their own SDK. The old SLComposeViewController is no more good. So we have to take care of it from iOS 8.3.
I just wondering if somehow we can get the list of these iOS versions where apple make changes, it would be easier for us to check the project installing those certain iOS version in iPhone. I think this type of information could be find in their developer site. If so any kind of information would be much helpful for us.
Thanks a lot in advance.
I asked very similar question couple years ago (not saying this is a duplicate!), and all I got then was - "read the documentation carefully". Unfortunately it still remains true even now, but you can get some tools to help you out.
For external libraries, I strongly recommend using either CocoaPods or Carthage. You can specify which versions you want to support and those tools do the job for you to check whether that library you want to include will be compatible with your deployment targets.
For your own code, you have to just write XCTests to verify the most crucial parts of your app or possibly the whole codebase (testing ftw) and stick with version checking. That will be slightly more zen in Swift 2.0 where you'll be able to do API checking as well with #available(iOS 9.0) { ... }.
I'm not sure if this is really what you're asking for, but here's a link to all of Apple's iOS release notes and API diffs on their developer portal. I believe it covers all major versions of the iOS SDK.
But speaking from personal experience, I would also say that the actual impact of minor iOS updates on the functionality of existing apps is usually negligible. I would focus your QA efforts on the major versions you support (7.X and 8.X in your case) and use the latest stable release versions there for testing, as those will be the versions the vast majority of your users will be using.
That said, I think it's also an excellent idea to at least briefly look into the actual distribution and adoption rates of iOS versions in your user base, and agree on sensible cut-off points. If you find, for example, that 87% of your users are running iOS 8.X, 12.5% iOS 7.1.X and only 0.5% iOS 7.0.X, you might conclude that providing explicit testing and/or support for 7.0.X users is not actually worth the effort.
There are many sites that provide you with general numbers about iOS adoption rates to give you a rough idea.
Lastly, if you feel that you've covered the (user-wise) biggest 2-3 versions in your testing, I think it's fair to push for your initial release and trust in your bug handling/update process to take care of any problems that may pop up in the more exotic iOS versions still out there. But that's of course a conscious decision you have to make for yourself.
Related
I recently started trying to develop apps using titanium.
When i ran one basic app containing two table views and some static data, it showed me 80 memory leaks and about 15 warnings - i think coming from the frameworks.
As an iOS developer, i'm used to seeing less than 5 memory leaks in complex apps too.
So, I'd like to know whether applications are getting accepted by apple when developed through titanium.
Also, I'd like to know whether,looking at the state of the titanium frameworks,its worth learning it right now.
Thanks in advance!
Your First Question, Yes! they are being accepted by Apple App Store.
And For your second question, its relative to likings of individual. I started mobile application development with titanium, but soon I realized that there is no better way to create an application then to create it natively. I would say if the applications you are developing are not scaled at enterprise level magnitude (means thousands of lines of code), better develop apps natively.
Titanium is increasing support and improving frameworks rapidly, its also reduces lines of code by third! and the best thing about it is, its cross-platform! but to my personal liking i always prefer native development. The power, the iOS gives you, Titanium wont!
One more thing i would like to add, despite all, you should learn it! :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
NB: This question has been extensively edited to make it more relevant, for completeness the original question maintained at the end.
What version(s) of iOS should my App support?
When building a new iOS app what a strategies should one use to determine what versions of the operating system to support? What practical considerations are there in supporting legacy OS version. Are there any reliable statistics to support the business case of dropping legacy support?
Original Question
If I build a new iOS application, should I support iOS versions prior to 5.0, or is that not necessary anymore? Is there any reliable and up to date data on iOS 5.0 adoption rates?
iOS Support Matrix v3.0.1
This version is updated and includes iOS 7.1 and new iPads.
Link: http://www.iossupportmatrix.com
According to this article: http://thenextweb.com/apple/2012/03/06/why-do-developers-prefer-ios-over-android-try-75-adoption-of-ios-5-while-ics-is-stuck-at-1/
the adoption rate of iOS5 has been very fast, at least when compared to Android ICS. You will always have users that are very slow to upgrade, however they seem to be the minority on iOS. If the numbers from the article are correct, you should be fine using iOS 5 for you app.
Look at statistics and judge for yourself if it is worth the effort.
For example:
http://www.14oranges.com/2012/03/ios-version-statistics-march-14th-2012/
http://pxldot.com/post/18754186750/ios-ebb-and-flow
from which I can read that < 11% are still using iOS 4.3
Or just search for e.g. "ios version stats", and try to find a web site that matches the target audience for your app.
This depends a lot on your app. But I would recommend supporting only iOS 5.0 and later because:
The new Xcode creates iOS 5.1 projects by default.
The new Xcode doesn't include iOS 4.3 simulator by default.
Apple has some iOS 5.0 only apps (like iTunes U).
So I guess, Apple is somehow pushing developers to support only the newer versions of the iOS.
Here is a good article that has some recent stats about iOS 5 adoption rates and good arguments on why to support only iOS 5 for new apps.
Here is another good article that discusses the question. Its conclusion is:
I think that both positions (support old, or support only new) are valid.
So it really depends on your special case. But personally, I'll currently support iOS 5.0 or later, unless there are solid reasons for a particular app.
I asked the same question some time ago and did not get any good answer with respect to a reliable up-to-date source of statistic data. In the end it comes down to your target market.
People who do not update their os recently are not likely to buy apps in high volumes. So even if these devices exist, the fraction of potential customers amongst their owners is most likely much smaller. That makes it hard to justify the extra effort in providing iOS 5.0+ functionaltiy and same functionality for smaller iOS.
On the other hand it may be suitable for you just to omit some functions for older iOS. That of course depends on the nature of the 5.0+ function that you want to use. Testing the curent os version and then deciding wether to call a function/method or not ist not that much of an effort. It needs to be tested though.
On the other hand there may be an interesting part of the user community that does consume apps but did not yet afford a brand new device. There is a number of devices around which cannot be migrated to iOS 5.x. And I personally would be interested in a) how many of these divices exist and b) how many of these are still in use.
If it is a new app then adressing older devices may not be justifyable. Unless of course you address some very special interest group and now for sure that the amount of oder devices is of a significant value.
Just some thoughts. Sorry that I did not have the statistics handy that you were looking for.
In my opinion it depends on which features of iOS 5.0 you need...
As example: in an application I need support for forward geocoding, available only in iOS 5.0 so I decided that the number of unsupported devices "cost" less then the effort to find a non apple library for forward geocoding ..
Inspired by an exchange on a recent question, I wanted to know whether there is any good reason to develop Windows Phone 7 applications that target pre-Mango models, i.e. by creating applications that target the 7.0 APIs rather than the more recent 7.1 APIs.
My impression was that because the Mango update has now been fully rolled-out, there is very little reason why anyone would have a phone with a pre-Mango OS. My guess is anyone with a pre-Mango phone probably never connects it to their computer and probably does not download applications.
Are there any good statistics on OS version demographics that can inform this decision?
I know from the analytics of my apps that there are still people out there using pre-Mango versions of Windows Phone, but as you point out, they are unlikely to be connecting their phone to their PC to perform updates or even update apps they've already downloaded (my wife for example would still be on the original shipped version if I hadn't updated her phone myself!).
With that in mind, personally, I don't see the point in creating applications now that target pre-Mango versions of the operating system. The return is highly unlikely to warrant the effort.
There isn't much of a reason to target pre-Mango as opposed to Mango as the upgrade is available to all models of phone currently, and for free.
It is worth keeping on the latest SDK for no other reason than there is no reason not to... lol, made sense in my head. Things like performance improvements, bug fixes, new features etc are all reasons to keep up with the latest, as you are likely aware.
The only reason I would target an older SDK is if a particular version of the phone OS was not available to a certain piece of hardware for any reason.
Then again, if you can make your app with the lowest common SDK, why not - it will in theory only increase your user base as backwards compatibility is enforced, over choosing a newer and not-completely-rolled-out version. You just personally suffer the older APIs and miss out on new features. However, I see this counter-point as a largely academic argument and adds little weight to the choice of older versions.
Save yourself the headache, go with the new stuff. Anyone actively using their phone enough to also use your app is likely hot on updates.
I don't do 7.0-specific programming any more since the roll out of Mango is now available pretty much everywhere I'm interesting in deploying apps. This question will rear it's head again when vNext is released (with potentially updated hardware requirements / sensors, etc), but for now I can't see much reason to target the old version.
How do you handle a bug in a specific SDK version in a released application? Say for example I've reported and received notification that a bug is known in a specific version of an SDK. Say the SDK engineers fix the problem in the next release. Do I then need to check if the user is running the buggy release and display an error message that they can't use a specific feature with a bug in it because it will crash their hardware? Is there a more graceful way? Do you display an alert and tell them to upgrade to the latest SDK? Do you completely remove the feature? Advice would be appreciated.
This is phrased to be agnostic as possible, but I am asking for the purposes of iPhone application development at this time. General answers for other platforms would be nice as well.
It depends on the nature of the bug and on the nature of the platform. With the iPhone, for example, you cannot just tell the user to upgrade his or her phone. If your goal is to support iPhone version X.Y, then you will need to support the corresponding SDK; whereas, targeting browser X version Y.Z or Java version X.Y, it may sometimes be acceptable to tell users to upgrade.* Giving the impression that your application can do something only to give an error message saying that it cannot support it for that version of the platform does not make for a good user experience. If possible, try to work around the deficiency in the platform (by possibly reimplementing code that supposedly works in the SDK) and provide the feature to the user. If that isn't possible, then disable it when running on the deficient version of the platform, but be sure to remove all traces of that feature from the application (so that users don't click on a button only for it to tell them that the button is completely useless). I should add that conditionally enabling/disabling features is only sensible in the case where the feature is not essential to application; if a feature is a core aspect of the application, then you'd better find a workaround or raise the minimum requirements as it would not be appropriate to ship a deficient application to your users.
*An example where telling users to upgrade is not reasonable would be business applications, since business sys admins tend to be unusually lazy and users have no power to upgrade by themselves.
I am developing a Netflix application for BlackBerry mobile devices. I need to make a decision as to the minimum OS version that I should develop for - depending on which I choose will have some design impacts (such as what browser field classes I can use, etc.)
What it comes down to is..should I support anything lower than OS 5.0?
I would say 4.5 and newer. see also:
OS - What market share do each of the BlackBerry models have?
OS - Which BlackBerry OS version to target for?
OS - What is the best practise in blackberry for reaching the widest range of smart phones?
I think there a few things to consider. First off, you need to have a clear vision of what you are hoping to achieve - features/functionality. Then evaluate the various API revisions, and determine which API level will provide the facilities needed to achieve your goals. Depending on the outcome of this, you may have to revise your goals. Maybe even consider using a lower API version, rolling out with a reduced feature set to help get your foot into the market, then in parallel be working on the full bells and whistles release utilizing a higher API version. But most importantly, you need to evaluate your market. The question becomes: "Does your target API provide you will enough of a potential market for your app?" But sometimes it becomes a difficult juggle, especially if you embrace the concept of "Build it and they will come" and you develop your app for the bleeding edge - waiting for the masses to arrive. You need to be sure to have the coverage in place (ie. financial, and political if you are in a large corporate environment) to survive until the day arrives. If you haven't already, you may want to look into becoming a Blackberry Alliance member. Also, don't be afraid to engage the major carriers in your market and push them a bit. They should be able to give you a bit of visibility into handset/platform penetration. Evaluate all of the variables both technical and business plan, and document it - the answer will come to you. Hope this helps.
RIM have created an official page with statistics that help you figure out the answer to this question: http://us.blackberry.com/developers/choosingtargetos.jsp
For example, as of November 2010, OS 5.0+ made up less than 50% of the market share of all active Blackberry devices, but OS 5.0+ accounts for 75% of free app downloads and 86% of paid app downloads from App World.
ON the basis of API similarities and supports i can divide os range like this
(A).<4.2
(B). 4.2< and <5.0
(c). 5.0
We deploy to 4.3, 4.7, and 5.0 with our app and that covers almost every in-market device being used today. There may be a few people still running 4.2 but not many.