I have an application whose minimum version has been set to iOS 7.0. This application also uses NSUserDefaults dictionary. This application is using UIAlertView and UIActionSheet extensively (not sure how much Apple non-disclosure covers). Now, with iOS 8.0, these two views have been deprecated and have been replaced by controller UIAlertController. Now, there are two ways that I can see which can help me in updating the app for iOS 8.
Raise the minimum version to iOS 8.0 for the update. This way, the users running iOS 7.0 won't be able to see the update. However, it leads to the following situation :-
However, there is one problematic case, and that comes from upgrades
performed from within iTunes or on a device with a higher version
number that is then synced to iTunes. When the user syncs the older
device with iTunes, iTunes will actually delete the application from
the device because it cannot run the new version currently within
iTunes. I had a couple of users with original iPod touches report this
when I upgraded one of my applications to only support 4.0.
The above comment is present under the accepted answer at the following url :-
Raising minimum iOS Deployment Target Version for App Update
Since, the application is using NSUserDefaults dictionary, the relevant entries in the dictionary would get erased when the application is deleted.
The other option is for me to detect in the code which version is being used and code accordingly using if-else statements. This would enable me to keep the iOS 7.0 as the minimum version and might also help me in deploying the update for iOS 8.0. However, this seems like a lot of work which can potentially lead to bugs.
So, I was wondering which option is better between the above 2 ways ? (This application would only be using Objective-C for now due to some constraints).
The best thing to do from the user's perspective is probably to code using UIAlertView and UIActionSheet even though they're deprecated. Keep your iOS 7 target the same as it's been. Xcode shouldn't give you warnings since you're using the older version as your base target. You won't need to change anything about your code and it should still work well enough.
Once you're ready to switch (perhaps when iOS 9 comes out), I would switch your base target to iOS 8 and update your code to use UIAlertController everywhere. To me, it doesn't make sense to spend time trying to support two different versions if it's just an API deprecation that still allows your code to work how you've written it for years. Saves resources and energy to just update it later.
But it's really up to you and how much you want to support iOS 7. I think it doesn't make sense to drop support until the next version comes out. I always try to support the current and last versions so there are no annoyed customers, but it depends on your own needs.
If you have analytics integrated, check out percentage of iOS 8 adoption once it's been released for the public. If not, it's a great opportunity to add it to find out how up to date your customers are!
Related
Is it possible to maintain 2 application versions of the same application at the same time?
When a device gets too old and won't receive any updates from apple, you will stay stuck on the last version supported by your device. When downloading apps from the app store that require a higher version of iOS, it will automatically download the last compatible version from the app store. this is default behavior as stated: https://apple.stackexchange.com/questions/160089/how-does-ios-appstore-handle-multiple-version-targeting-different-version-of-ios/336985#336985
While we will mostly update our latest version, can we still update the 'legacy' versions of the app for older devices? can we still add features to the old versions (eg iOS <11) while adding the same features in our new app?
You can maintain two apps simply by giving them two different bundle ids.
But you probably cannot update the "old" app without recompiling it against the current iOS or prevent a modern user from seeing and downloading the "old" app.
To give an example, if your old app was 32 bit only, a 64 bit user cannot download it. But if you update it, you have to make it 64 bit.
Im developing an SDK and its deployment target is set to 9.0. Im using some API's that are deprecated in iOS 10 and above and others that are deprecated at iOS 13 and above.
My question is what will happen to an app that is consuming my SDK and its deployment target is set to iOS 14? will my SDK be affected? will my methods get properly invoked? will it crash the hosting app? is the behaviour under these circumstances is unclear? or maybe all will run perfectly?
Any light on this would be appreciated, thanks.
First things first, deprecation is the first step in the process of ending the life of an API and Apple is warning the developers that these APIs will be removed in one of the future iOS releases. Nobody knows when except Apple. There is certainly a wisdom in that (e.g security concerns, better API design, etc).
Developing an SDK which uses deprecated APIs is generally considered a dead end. I am sure you have your own reasons, however, anyone who uses your SDK will be asking themselves whether there will be any value or will there be a maintenance overhead.
There are certain issues during the development stage that you should be aware of. If the app developer of an app who uses your SDK sets the deployment target to iOS14, most probably Xcode will flag this up as a warning. It depends on other things such as the development language that you are using, whether it is already compiled etc.
Assuming there is a good reason for you to move forward, there are several scenarios on what could happen.
In Production, the very short answer to your question is, the application will crash if the API is removed in the next OS upgrade by Apple (if the app developer doesn't take any action before it is released). However, long answer is a little bit more complicated than this.
The best case scenario is Apple doesn't remove the API for a very long time e.g UIWebView. I think it has been at least 5 years now since Apple deprecated the framework, and technical you can still build an app with the UIWebView. That means you do not have to do anything (in theory).
However, if the API is removed by the new OS update, there are several scenarios:
The device is eligible for an OS upgrade, THEN the app will most likely keep crashing when the API is called by the app/sdk.
If the device is NOT eligible for an OS upgrade (e.g stuck on iOS 10), the app will still live for a while on these devices until the owner buys a new device (whether the app developers takes action or not). That particular app version should also be available through iCloud purchases/downloads. So customers can re-download that version even if they delete it etc.
For an active app developer, the first scenario shouldn't happen. I would expect them to test the app on the next beta of the OS version and take action if there is an issue e.g ask you to provide an update, or replace your SDK with another one.
The API removal process can be a little bit more informed and Apple might force your hand, but be still gentle. Apple may make it explicit and warn developers that any new apps, or app updates which contain the API will not be accepted to App Store. This ties the app developers hands. They need to make a choice. This warning would be months in advanced and you would put this work into your backlog and plan for it.
The scenario in bullet point 2, on the other hand, may not be obvious at first, and Apple is doing a pretty good job of convincing the customers to buy the latest devices. There is a relative 2 year cycle, so you may not find many customer using older phones which are stuck on older OSs. This may be ignored depending on your significance level.
The app developers may or may not be able to keep the min target of the app. If they are so adamant then most likely their app will not be compatible with the latest devices or Apple may refuse their updates (as above). Then that means it is pretty much the end of life of the app, only used by a handful of customers.
There is also scenario where Apple may also remove the applications from App Store and iCloud download which are not maintained for a certain period of time (this has happened).
If a user was using my app on iOS 8 and my latest release supports iOS 9 only. The user update OS to iOS9.
Does he get al alert to update app when he opens my app?
Can the user still use my app without updating it?
What happens for the deprecated code? Will the app crash while trying to access such APIs?
No alerts. If user will not update iOS your application will not be updated. Your project should be updated that now it requires iOS 9, see deployment target in your project settings. If you don't change this setting than it will get updated and you can have a crash if new API is used on old iOS.
If you didn't change server side in such way that it breaks compatibility than old version should still work.
This should be investigated by you. It depends on many factors. If you have setup project "deployment target" properly than update will not be performed on older iOS versions. This may be tricky if your application should support older versions of iOS. Not updated application will continue to work on new iOS even if deprecated API is used. Apple will simply reject updates witch are using deprecated API but still maintains that API. Once I had a problem since UIAlertView was deprecated and old application had new bug where UIAlertView was not respecting application orientation. I had to do a tricky code which detected if UIAlertController (I prefer this approach instead detecting iOS version) is available than use it and if not than fallback to UIAlertView was used.
During application update the biggest problem you can create is setting compatibility or database comp compatibility. So you should be careful with that.
I've got an application (not free) on the Appstore, it was one of my first app. I'd like to update it with a lot of new stuff, graphics etc. Most of these new feature such as collection views are available only from iOS 6, the app targets iOSes >=3.1. I prefer to not mess around with runtime checking.
Since is a paid application I'd like at least that all people with iOS6 could upgrade it for free, and I don't want to screw older versions.
What happens if I submit an upgrade that target only iOS=>6, would older iOSes be notified about the upgrade? could they do the upgrade? will be shown something such as "The upgrade will be available only for iOS>=6"? or it will be notified only with matching devices?
I've read that question (little bit old) and there is a Use Case not clear to me here
Thanks,
Andrea
I want to create a map based app but apple will no longer user google maps in ios 6.I dont want to upgrade to the developer beta yet as I am waiting for the final release. But I also want to get started as soon as possible. If I start my project now will it change or the code will differ when the ios 6 is available? In other words if I make a successful built in ios 5 will it be unsuccessful when i upgrade to ios6? Will I have to rewrite the entire thing or everything will be compatible resulting to an also successful built? thank you in advance..
Your code will work fine.
Almost nothing changes with iOS 6 and MKMapKit in terms of code.
The only thing which works different in iOS 6 is the way you call the native Map App from inside you app. (if you are using this functionality)
You don't need to wait to use beta versions of XCode, you place them in different locations on your hard drive and leave the current XCode in place.
Then you can test in the iOS 6 simulator just to make sure it works as well as on iOS 5.