The fictitious situation is the following: I have a mobile application that has been published to the store for about a year now (both for iOS and Android). I’m preparing a new version of the application. Some of the api’s in the back end are obsolete or deprecated.
The problem is that users of the application that would not update the app to the new version will experience problems with the operation of the app because the back end api’s have been replaced or removed.
The question is how to deal with this situation before becoming a problem?
Are there any guidelines from apple or google for obsolete functionality between different versions of the application?
#Dimitris, Here you need to provide force update to the old apps. This can be done using app configuration file. Basically, you will have an app configuration file which contains JSON with following keys:
{
"server":{
"app-server1-base-url":"http://",
"status":{
"is-running":true,
"message":"We are busy upgrading XYZ server with technology and features. We will be back soon. We apologize for the inconvenience and appreciate your patience. Thank you for using XYZ!"
},
"force-update":{
"status":false,
"message":"Please download the latest version of XYZ from App Store to continue using the app. Thank You!"
}
}
}
Here 'app-server1-base-url' key will be base URL for the app. you can put all the service URL in this file.
Case 1:
Your app will check this at the time of launch whether force update available or not to the app.
Case 2:
API versioning can be done if you want to handle it using backend.
Note: Please keep configuration file on services like AWS S3 etc.
As Puneet Sharma said in this post: https://stackoverflow.com/a/18756151/8354952.
Almost all changes to the iOS versions are additive and hence an
application build using lower version still runs on the higher iOS
version. But we also need to notice that APIs are introduced or
deprecated and behaviors of existing APIs may occasionally change.
Basically the old version application may run on the latest system version. But some special api or class may be deprecated, this will cause some weird behavior or crash. So Apple or Google will also recommend user to update old version applications.
For the api from our own server, we can do the application compatibility by ourselves. Upload the current version identifier, the server can transfer different types of data through detecting the identifier.
Related
I have a use case in which we wish to selectively disable an Android and an until the user upgrades to a minimum required version. This question is to get design inputs and best practices for similar cases.
Typically the flow will be as follows:-
Upon starting the app, the main activity thread will check the presence of the current installed version. (I am looking for pointers to a Google API/TPL to achieve this programmatically).
Then the app checks for the minimum required version. (This can be done by maintaining the minimum required version on a rest service). However is it possible to maintain the minimum required version on Play Store?
Force the user to upgrade if current version < min required version. (redirecting user to App store and not letting them back into the app till they upgrade - I am also looking for code pointers for this case)
Note that this is different from the push notifications from the app store for upgrades. Unlike push notifications, this logic will allow my app to stay at some min version across my user base.
You can check current version of your app by using the following code if your using Android Studio.
int versionCode = BuildConfig.VERSION_CODE;
String versionName = BuildConfig.VERSION_NAME;
I don't think maintaining installed version on play store is possible so using a rest api for this will be the option.
To force the user to update app, check current version with version from api, and if conditions are not met show them an alert dialog with two options:- either Exit or Update.
To launch update intent you can do something like this
Intent updateIntent= new Intent(Intent.ACTION_VIEW, Uri.parse("market://details?id=" + your app package name));
UPDATE:
You can also use third party libraries to check for updates. One that I have used is gpversionchecker
Upon starting the app, the main activity thread will check the
presence of the current installed version. (I am looking for pointers
to a Google API/TPL to achieve this programmatically).
YES, we can check the currently installed version of the application.
int versionCode = BuildConfig.VERSION_CODE;
String versionName = BuildConfig.VERSION_NAME;
Then the app checks for the minimum required version. (This can be
done by maintaining the minimum required version on a rest service).
However is it possible to maintain the minimum required version on
Play Store?
Maintaining the versioning with the REST services is a very good idea. Personally I would like to suggest maintaining the paths of REST services like this.
https://www.domainname.com/api/v1/
However, I didn't really understand your intention clearly. I guess you're talking about Android version here. So if you're thinking about the minimum API level of Android your application, then you don't have to be worried about it. Play store will take care of it.
For example, if you've uploaded an apk earlier which you want to upgrade. Play Store will keep both and user will lower Android version will get the old apk you've uploaded. You can remove the old version of your application from Google Play Developer Console too.
Update: You can not keep all versions of the app compatible upto a defined min level of Android version. You can keep different versions only if the minimum SDK level is changed for your application.
Force the user to upgrade if current version < min required version.
(redirecting user to App store and not letting them back into the app
till they upgrade - I am also looking for code pointers for this case)
If some user are using the previous version of your application, you can not force them to update if its not already coded inside the application. Though we can think of an work-around here. The REST API calls may stop serving the old application as you're updating the API version number (e.g. https://www.domainname.com/api/v2/). So you can show them some message as a response of your APIs if response message from server is shown somewhere.
Update: So if you want all users to download the application update as you want them to move to server API version V2, you might have to take the choice of stopping all services for V1 and when a service is called from the old version of your application, you might give it a response like I told earlier.
Hope that helps!
This is more of a feasibility question as I am new to mobile development.
Suppose there are already existing users using a version IOS and Android version of an application. However for some reasons, a total new application(re-wrote) is to be built to replace the existing one.
Is there any way we can update all the existing users with the new application without them having to re-download them?
Update:
I found an answer for android
Pushing an update to Google Play that will replace the existing app
But what about IOS?
Your biggest feasibility challenge on iOS is Apple. From the App Store Review Guidelines
2.7 Apps that download code in any way or form will be rejected
2.8 Apps that install or launch other executable code will be rejected
So that makes it pretty unfeasible. They take this pretty seriously too: you'll probably lose your dev account, and certainly that app, if they notice you at it. So I would very strongly recommend you not attempt an in-place update, simply upload a new release to the App Store and let the user update according to their automatic or manual update settings.
If it's absolutely necessary that the application be updated immediately for continued functionality, the way developers typically handle a forcible update is to check their version on launch against the current version somewhere and pop up a modal that tells the user to go to the store app and update.
When you upload a new version to app engine, let's call it '10', you can send requests to this version directly using this url: http://10.myapp.appspot.com
I find it very useful and I made an habit to release my android app pointing to the corresponding server version. So when I upload version 10 to the play store it points to http://10.myapp.appspot.com, the same goes to version 9: http://9.myapp.appspot.com.
Is this correct usage or this feature? What is the best practices regarding Versioning in App Engine?
I'm doing it because I want to maintain backward compatibility, so that if I'm making a change in the server the old clients won't notice it because they are connected to an older version.
I understand it's problematic because all the versions share the same DB as well as problems that could occur when I configure warmup for the default version that doesn't apply to the other versions. So am I making a mistake by using it this way?
Application versions are useful for things like testing new versions before deploying them "live." I would not use it to ensure backward compatibility with you existing clients. Furthermore you can have only limited number of versions per application.
You can have up to ten versions of each application; once you've reached that limit, you'll need to delete existing versions before you can deploy new ones.
Another thing to consider is that some App Engine services (e.g. Datastore) are independent on a particular version but others (e.g. Cron jobs) are tight to a concrete version (usually default version unless specified otherwise).
However, you can have different versions of your application's public interface (REST/SOAP services or whatever you use) so that new features or changes are available only to the respective clients.
Here is an example of dummy REST API using versions.
https://myapp.com/api/v1/questions/10/answers?max=10
https://myapp.com/api/v2/questions/10/latest-10-answers
I'm creating an android library that will be embedded in to application source which will be used for recording some analytics information on the server. I wanted to find out if the user has upgraded to a new version of the application(not the library) using SDK API. I'm trying to avoid having the application developers change anything in the manifest to indicate the version change. I already have a mechanism to identify each device on the server. In this case is there a way to identify if the .apk is upgraded when the tries to contact the server?
So far I found PackageInfo.lastUpdateTime is changed. I thought PackageInfo.signatures content will change too, but it is not changed even when I change the application code. Appreciate any help.
Why not just send along BuildConfig.VERSION_CODE? If the value is different than the last value received, it's been updated. For an application to be updated, the version code must be at least as large as the previous version. To be published on the Google Play store, the version code must be increased.
I've programmed my app with Eclipse and android 2.2. However I think that my app would work for previous version and so it would allow more users to use my app. The problem is that I'm not sure... for instance I'm using Gestures which I think is a more recent feature... but otherwise I'm just using some Button, ListView, and WebView.
So is there a way to detect automatically the Minimum Sdk Version needed ( by checking which function my app is using) ?
I can't download the SDK of each previous version of android and test it until it doesn't work ...
Thanks
I can't download the SDK of each previous version of android and test it until it doesn't work ..
Why cant you? This is what the rest of us do. Create various different Emulators and test it out. I've released many apps by testing this way.
Take a look at the Compatibility page on Android's developer website.
It has some great information on how to make sure your application will work on different versions of Android and how to stop users from downloading the application if they do not have the right features on their device. In your case that would be the gestures feature.
To manage this, Android defines
feature IDs. Every capability has a
corresponding feature ID defined by
the Android platform. For instance,
the feature ID for compass is
“android.hardware.sensor.compass”,
while the feature ID for Live
Wallpapers is
“android.software.live_wallpapers”.
Each of these IDs also has a
corresponding Java-language constant
on the PackageManager class that you
can use to query whether feature is
supported at runtime.
To be totally sure you have to test your app against every platform version you target. Otherwise users of your app will do it for you (and that might be not good for app rating).
On the https://developer.android.com/about/dashboards/index.html page you can see the latest up-to-date platforms share info. So just decide how many potential users you're going to leave without your app :)