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).
Related
I have my enterprise application (intranet web application) released long back. I also have an iPhone app on AppStore to provide some essential web application functionalities on mobile.
This iPhone app runs against the webapis exposed by this web application and is strongly dependent on it.
I have recently released a new version of my web application which is substantially different from the previous version (technically) and is a major release.
Although it caters to the same business functionality.
When I say a major release I mean the entities, signalR version etc are totally incompatible with the previous one.
Now I have to release a mobile app similar to the one I already have on AppStore but running against the new webapis exposed by the new version of webapplication.
I have to keep on supporting Clients using both of the versions of my enterprise application and cannot have a single iPhone app catering to both due to the strong incompatibility between the two versions of the webapplication.
But going through the Apple Developer site I found below
App Store Review Guidelines
2.20 Developers "spamming" the App Store with many versions of similar apps will be removed from the iOS Developer Program
I am really confused in releasing the new app which is similar to the previous one but
Differs substantially in code base
Has a different App Icon, AppName and AppID offcourse.
Is not intended for spamming but for business continuity.
Please help me as I am clueless on this.
Note: I have already gone through all the related posts on publishing similar iOS Apps but somehow didn't receive any inputs on this specific case.
While it would be preferable from an OOP point of view - if the UI and UX of both apps are the same - to allow the app's user (or the app itself) to select the correct data provider w.r.t. your web application's version, e.g. have interchangeable implementations that yield the same results depending on the backend, your approach might not be considered 'spamming' the store.
That guideline is intended to hold back developers just changing assets and names of apps (mostly games) and release basically the same codebase 100 times, maximizing efficiency and getting promoted as 'new app' regulary.
Seeing as you already made the conceptually bad decission to develop two different apps, submit both (or seeing as the old one might already be in the store, the new one) and see what review says; there's no harm in trying.
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!
I released an update for my App and it was approved. It was approve despite the fact that it included a serious localization bug where most users are getting the wrong language. Is there any way to quickly revert back to the previous version, suspend current downloads of the current version, or anything else that might help aid this issue?
I did read the following thread from a couple years ago:
Can I revert to my previous version app in iTunes Connect?
I was hoping maybe there is a more painless solution to this now.
Btw, I did thoroughly test the version before it was added as a new version. So, I'm still not entirely sure what's wrong or how to fix it.
It is not possible to revert the app version. You can upload the previous version as new version again to fix this.
One thing you can do is : "Expediting an App Review"
Please check the following link.
https://developer.apple.com/appstore/contact/?topic=expedite
Thanks
Here's a snippet from iTunes Connect Help page :
Question: The new version of my app on the App Store has a bug. Can I use a previous version to replace it?
No. You cannot revert to a previous version on the App Store. You must submit a new version.
Source : iTunes Connect FAQ
Obviously the alternative would be to submit a new build but ask for expedited app review.
But that means that either your app is event-related or you have a critical bug that you need fixed as soon as possible.
I believe that you can prepare for problems by creating a fallback version with a higher version number and submitting it for approval with manual publishing. That should cause it to be quiescent in your store until you choose to fall back, and you publish it.
I am not certain whether you can then submit improved versions with a lower version number than your fallback version.
I had to do this recently. I was able to adjust a previous version archive. I started by copying the archive and opening the copy, then editing the info.plist files, adjusting/incrementing both the version and build numbers at both the archive and app package levels. Then uploaded to iTunes, which recognized it as a new version.
Preface: I agree with the other posts here that you can't perform a rollback through the iTunes Connect itself. Even if you could, you'd suffer the lag time it takes for users to update to the rolled-back-version. But that doesn't mean we can't still rollback apps.
Retroactively, you cannot rollback an app. Proactively, however, you can instrument your app to enable future rollbacks after a build has been released and installed.
High-level steps:
Build each version of your application as a framework
For each release build, include both the current and old framework versions
On app boot, decided which framework to load and execute (include sane defaults)
When you want to rollback, update the cached values across all user devices and wait for the next app open.
This strategy uses similar mechanics to feature flags which are commonly used to enable/disable features without re-releasing. However, in this case, you're "feature-flagging" your entire app version.
Is feature flagging between embedded libraries against App Store Guidelines?
No. Embedding two versions of your app into one release is not against App Store review guidelines:
4.7 HTML5 Games, Bots, etc.
Apps may contain or run code that is not embedded in the binary (e.g.
HTML5-based games, bots, etc.), as long as code distribution isn’t the
main purpose of the app, the code is not offered in a store or
store-like interface, and provided that the software (1) is free or
purchased using in-app purchase; (2) only uses capabilities available
in a standard WebKit view (e.g. it must open and run natively in
Safari without modifications or additional software); your app must
use WebKit and JavaScript Core to run third-party software and should
not attempt to extend or expose native platform APIs to third-party
software;
Similar to feature flags, all code that you plan to run is included in the binary that you submit for review. What's more, as long as you are rolling back to releases that Apple already reviewed and approved, you're not breaking the spirit of the guidelines.
Does this hurt performance?
I've profiled this approach against many of the popular and heavy open-source iOS apps including Wikipedia, Signal, Firefox, etc. You can be smart about deduping assets and shared libraries, resulting in a sandwiched-app-bundle size of about 1.2x the original size (really just depending on how much code you changed). You also incur about a 50ms startup cost when choosing which version of the app to boot.
IMO, both time and size increases are worthwhile in return for the ability to selectively rollback users experiencing issues while you take time implementing a fix.
Do real apps do this?
Major apps feature-flag between dylibs all the time when launching new features and optimizing performance. I have also heard of major tech companies using this app-level pattern for their largest releases. I have a personal app in the App Store using this pattern, and I have helped other developers do the same.
How can someone do this for their app
If you are comfortable going deep on the Xcode build system, you can follow the steps outlined above and with some fiddling, start feature flagging your app version on boot. Note that you'll also need some form of caching and a server endpoint to update the on-device flag.
The implementation described above is also exactly how screenplay.dev implements iOS rollbacks. The tool:
Adds two build targets to your Xcode project, one for building the framework version, and one for bundling the final release build.
Serves as a repository for your old app build versions.
Provides a web UI for toggling live versions.
If you release an app that uses an api that is later deprecated (after the release of your app), then what happens ?
What if you never update your app after it is released on the store ? Will it work with all future versions of iOS ?
Will the app still work when the api goes away in later OS versions? Or will the App Store just prevent your app from being downloaded to future OS versions ?
You asked:
If you release an app that uses an api that is later deprecated (after the release of your app), then what happens?
According to Apple, "A method identified as deprecated has been superseded and may become unsupported in the future."
So, needless to say, if your app is using an API that is deprecated at some future date, it generally will continue to work until such point Apple chooses to no longer support that API. In practice, your app will continue to function well after the API is deprecated, as Apple places a strong emphasis on backward compatibility.
If you use methods that are already flagged as deprecated at the time you release your app (or at least without doing the appropriate runtime checks for the availability of the successor method), you run a greater risk of incompatibility with forthcoming iOS versions. But if you stick with the API that is not deprecated at the time you release your app, you're unlikely to run into problems with API changes within any reasonable time span.
What if you never update your app after it is released on the store? Will it work with all future versions of iOS?
If well designed (e.g. you don't rely upon methods that were deprecated at the time you developed the app), you'll probably be safe for several iOS versions at the very least, but you have no guarantee of such. The burden rests upon the developer to ensure that the app is compatible with new versions of iOS as they're rolled out.
Frankly, apps generally date themselves well before the evolution of the API breaks it, so the level of user interest will diminish well before the API breaks it.
Will the app still work when the api goes away in later OS versions? Or will the App Store just prevent your app from being downloaded to future OS versions?
If the API is eventually retired, then obviously your app will no longer function, except in the unlikely scenario that you anticipated this and gracefully handle that situation. I don't believe that the app is automatically removed, probably only in response to user complaints.
The only automatic removal that I'm aware of is that the developer allows their paid developer's license to lapse. In that scenario, the app is removed from the store immediately.
As an aside, you have focused solely on API differences. Another source of problems are those apps that rely upon some undocumented iOS idiosyncrasy for the successful operation of the app. If you stick to standard, documented API calls, you should be fine. But if you have some feature that you only got to work employing some kludgy work-around discovered experimentally, but not found in the official documentation, then that's a warning sign that your app might not be very "future-proof" and may well break upon future iOS releases.
immediately nothing . the deprecated api is not going to be removed from the OS .. a few years later the app might just crash on then modern OS's if you still use that function BUT AFAIK there has not been that case in IOS's short life.
A different story is when you update the Base SDK of an app and recompile it. it might be you are forced to replace that deprecated call.
It's very difficult to say because some methods/properties which was deprecated still works. For example tableViewCell.textColor was depreciated in iOS 3 or 4 but it works.
Apple tries to maintain backward compatibility with older iOS's and they allow old apps works.
While I've never experienced this issue with my own apps, I have seen apps in the store that have not been updated for 2+ years. A lot of these apps just crash on launch as they try to access APIs that no longer work and have piss-poor error handling built in.
I'm not sure if Apple goes and proactively removes these apps, though they obviously have that power since they own the App Store. I've also read they can do go as far as removing every installed copy on every iOS device of a specific app.
If an app gets enough negative reviews or comments that are reported as highly negative, it may get removed.
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