I have an question regarding app distribution system via app store.
I have an app on app store which interacts with a different client-servers at various locations. It functions like version 1.0 of iphone app will be able to properly interact with version 1.0 of the client-server. Now the problem is few of my clients are late/reluctant in upgrading their server to which the iphone users connect. Once I release an update(say 2.0) for my iphone app there are few client-server which are still running 1.0 version. And if the end users of these clients installs the update (2.0) for his iphone app (unknowingly, the client-server which he is gonna connect to is still on 1.0), he makes his app unusable.
how to deal with these types of scenarios?
Can I develop my new updates to the application which interacts with the server before upgrading themselves OR can I develop something which automatically rolls back the update if server version mismatches?
Kindly suggest how to deal with this problem!
Would extremely grateful for your suggestions.
Many thanks,
Manu
You can't do either things that you mentioned. The app store guidelines forbid removing functionality (aka compatibility with 1.0) from the app, however they are fairly lenient about this. Regardless, it's a bad user experience to not support recent older versions of your client/server software.
Most people will place a big warning at the beginning of their "What's new" text, like "WARNING: This version does not work with server app version 1.0." It's somewhat effective if the person bothers to read that, however it's a bit crude.
In any case, version 2 of the app should not simply crash - you should provide feedback via a UIAlertView if their server version is not compatible with the client.
Furthermore, your server version 2 should continue to send responses that version 1 can parse, or send back an error message that you display to the user via a UIAlertView that tells them that they need to update the app.
Related
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).
We have a browser application and this application is using by different clients. Each client is using separate database and service. Regularly(quarterly) we are releasing the upgrade with enhanced features. But some of the clients may not upgrade to the latest. So different clients are using different versions of our product. There is no issue with this because each clients are using their own Database and service. Recently we build up a iOS app for the same application. In app store we can upload only the latest version of our app, how the clients in lower version can install respective version of their app? Latest version app may not work with lower version of service and Database
Different clients needs to install different versions of same app from app store.
In App Store Connect (where you manage your apps in the App Store), you can choose which versions you want to remain in the App Store after you release a new version. The purpose of this is to allow an older version to be downloaded in case the user have an older device or iOS version that don't support the new app version. - So I guess this feature is not really helping in your case.
I would suggest you make the same version for everyone, and then within the App (I assume your clients have a login) based on their user selects what you want to present them. - Connecting to their old database and deactivating the new features as an example. This will also give you the opportunity to showcase that there is new features which they may want to opt-in on.
You can release a completely new app for each version. Ex. YourApp 1.0, YourApp 2.0 (This is not uncommon, but it's usually more if the same app is radically changed/improved, and you want the old version to remain for some time until you retire it completely).
Hope this clarifies a bit :)
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 want to know how others are managing their back end API's during the time when their iOS app is under review.
We are constantly updating/adding new API endpoints every release. The major problem we're encountering is when we have to make DB schema changes. We don't want to promote our backend changes to our production server until after the app has been approved by Apple (which may take up to 4+ days).
Currently, we set our iOS app to manual release and flip between 2 production servers. So app v1.0 in the app store will point to our prod1 server and app v2.0 in review will point to our prod2 server. When Apple approves v2.0, we copy our prod1 database to prod2, run all the migrations and then release v2.0. Once we've promoted our changes to prod2, we'll update a config setting on prod1 that will send a response back to app v1.0 providing a link to the app store to download app v2.0.
It feels like there are better ways to solve this problem. Interested to see how others have approached this issue.
We've successfully used the iOS app version (passed as part of the headers) in the REST calls to support multiple app versions on the same server(s). Seeing as you often have to support multiple older versions of the iOS client anyway this seems to be the simplest approach.
I want to know if there's any trouble in creating a version control on my iOS app, because I'm going to make some huge upgrades in my webservices code and don't want that any user try to access the old version and the app crashes or don't work properly.
My idea is to create a service that capture the app version and than, if its an old version, the user can't access the app until the new version is installed.
I know that some android apps do this, but I didn't find any iOS app with this control.
Thanks!
Your app has a version, and you're writing the web service, so I don't see why you couldn't have your web service check the version and respond with a message that tells the app to show a message asking the user to upgrade.
That said, it would be much, much nicer for your users if you design the web service so that it detects the app version and then provides appropriate functionality for whichever version the user has. You might not want to continue support for the older version forever, but your users would probably appreciate having some time to upgrade when they choose to rather than when your app forces them to.