I'm trying to help my company develop a strategy on when we should require customers to upgrade their installed mobile app prior to interacting with our back end services.
Right now, our apps have been on the market for 20 months and we've done numerous revisions to the app and the backend services. Only one of those has 'broken' anything so that customers using older versions of the app were no longer able to use the app without upgrading to a new version. We have apps for iOS, Android and Kindle Fire, all of which use the same backend services. We currently have the ability to require customers to upgrade, we're just not using it.
So the two questions:
1) Do you require users to upgrade, and if so
2) How many older versions of the app do you support.
(Additional info, this is an eCommerce app, so if you could say what type of app you're using as well, that would be helpful.)
Thank you!
You should probably look at a strategy of versioning your APIs. So that users with older/un-upgraded apps would have problems. And when they upgrade to your new builds, they would switch to the new API version and everything would work.
Coming to how many versions you support. That really depends on you. If you want to force the users to update, then make your servers deny requests to the old APIs. That way, if the user is interested to use the app further, he has to upgrade.
E*Commerce app. We control the endpoint the app connects to. In every upstream HTTP header, the app puts its version number. The web and optionally add a tag in the downstream header of "yellow", "red", "disable".
If the app gets a yellow key, it tells the user at some good point "This app is out of date - you should update to the latest version soon"
if the app sees a red key, it tells the user to update soon or the app will stop working.
If the disable header is seen. the app stops sending upstream messages and tells the user that the app no longer works, if they would like to continue using the service then update the app.
Related
I saw few posts about it but most of them seem to be outdated.
I have an app published in the Play Store and it has already published version codes 1 to 6.
I have found in those releases some serious bug and I published a new release with version code 7.
The new version has an in-app update to make sure in the next times that the users will update to the latest release but right now it won't make any effect on the previous releases since they didn't have this code in them. Is there a way I can make version codes 1 to 6 to download the latest version?
As long as users keep using versions 1 to 6 I can add some critical features and I need them to make this update.
Also, I use Firebase firestore/realtime database/fcm/storage/authentication. Is there a way I can do it from there? The only thing I can think of is to send cloud message for the users to update the app.
Thank you
Is there a way I can make version codes 1 to 6 to download the latest version?
No, sorry. Let your users know by whatever other communications channel(s) you established (site announcement, blog post, Twitter/Facebook/etc., email newsletter, ...).
Unfortunately, for the users who are using version codes 1 to 6, there is not much you can do. I don't know what's the logic behind your existing "in-app update" option, but if the users can skip that step, you end up having the same problem.
To solve this kind of scenario, we usually add the version of the app to the database, and each time we open the app, we check that value against the one in the app's code. If there is a match, it means that no update is required, otherwise, we "force" the user to update the app to the latest version by opening the app's page from Google Play.
Another solution might also be Android In-app updates:
When your users keep your app up to date on their devices, they can try new features, as well as benefit from performance improvements and bug fixes. Although some users enable background updates when their device is connected to an unmetered connection, other users might need to be reminded to install updates. In-app updates is a Play Core library feature that prompts active users to update your app.
We are going to do a major update to an mobile app (both iOS and Android). When we do this update, we need to prevent the existing user using the older version anymore (in case if the new version is not auto updated) as some features might not work with the server update.
Is there any options in iOS and Andorid developer centers (for that app info) to mark that older version as cannot be used any more or to atleaset notify the users that they have to install the latest version when they try to use that app(incase they have switched off auto updates)
I have seen there are options to do it from the code by comparing it with the existing version and to notify the user. But since we have not implemented any such mechanism in our apps which is currently in the App stores, I don't think we can do the code based option for this version. That's why we are looking for other options like doing it though App store confugration etc..
Unfortunately, there is no solid solution for this issue.
One workaround if your app make any API calls, you can modify the response to let user know whey need to update the app. Or else, perhaps you can send a push notification to let existing user know they need to update the app.
Futhermore, you might need to implement force update mechanism, which is basically check user's current version with your latest app version, so you will know which version they are currently using. There are a few ways to do this:
Server side: You need to send app version to server and if it is not latest version, stop user and force user to go to AppStore/Playstore to update.
If you are using Firebase, you can take a look at Firebase Remote Config. I have not used it but I believe it would work.
I'm about to publish my first app on google play and I'm a little bit lost on how to manage my app version. I have my frontend app written with react native and I have a backend server built with spring boot.
In my backend I have my version number which is incremented on each build release.
My problem is that I don't know how to manage versioning in the react-native part: there's a version tag in package.json and I read here that I should increment versionCode in AndroidManifest file.
To summarize here are my questions:
1/ Should version in my backend, in package.json and in manifest file be always the same ?
2/ Is there a way to force user to update the app when I publish a new update on google play?
3/ When I publish a new version of the app, does users need to download full app size or there's a way to allow them to just download a partial size?
4/ If there's a mismatch between frontend and backend versions, users can perform actions or call some apis that aren't available anymore in my server, how can I prevent this to happen?
I know I asked many questions in one but as I said that's the first time I publish to google play and I wanted to separate my question on 4 parts to be more clear.
1/ Should version in my backend, in package.json and in manifest file
be always the same ?
No, they can be but practically it doesn't make sense. Your app might need a hot fix or you can implement features which don't require backend changes. The app version can then be changed independently.
2/ Is there a way to force user to update the app when I publish a new update on google play?
There is. You can either do this manually by sending a request to some endpoint at your backend and check if the apps version number is smaller than the version that your API returns. If it is, act accordingly in your app, e.g. show a message or prevent the user from using the app until they update.
Alternatively, you can uses In-app updates from the play-core library.
3/ When I publish a new version of the app, does users need to download full app size or there's a way to allow them to just download a partial size?
The Play store handles this automatically. Allthough I don't know for sure if it's a full redownload or a partial one.
4/ If there's a mismatch between frontend and backend versions, users can perform actions or call some apis that aren't available anymore in my server, how can I prevent this to happen?
To prevent such issues, you should familiarize yourself with the concept of API versioning. In short: If your API update introduces breaking changes, you should create a new version of it at a different endpoint in order to support backwards compatibility.
E.g.:
http://api.example.com/v1
http://api.example.com/v2
...
I launched a mobile app last week, both for iOS and Android (it's build with ionic framework if this could make any difference). Actually, it was much more like a beta version.
Now, there are people that have installed the app. Not that huge amount, but anyway.
I have now developed a new version. Thing is that the app relies on a server. And the server has changed a lot of things.
So the client app on the store is not really in sync with the server code.
When I release this updated version of the app, chances are huge that those people that use the "old" app will get really unpredictable results.
Is there a standard way to face with this? I cannot inform users that the app is out of date but only rely on OS telling the user there is a new version available.
This is really a general programming issue that has nothing to do with any specific platform.
Version 1 of your app requires version 1 of your server API and then you need to update the server to version 2 of its API for version 2 of your app.
Upon release of version 2 of your app, your user base will be a mix of both version 1 and version 2 of your app.
This means that your server needs to be able to respond to both versions of its API. There are a few possible ways to support this.
Have two completely different URLs for each version. Example: http://version1.server.com/... and http://version2.server.com/... Just use the proper URL in each app.
Pass a version number as part of the URL. Example: http://server.com?ver=2&other=whatever. You could have your server assume version 1 if there is no ver parameter in the URL.
The key point is that version 1 of the app is out there. The server needs to keep supporting that version of its API for a while. The server needs a way to support both. So version 2 of the app can be fixed now, before it is released, to work with whatever changes are made on the server to support both its old API and the new API.
Perhaps a little late now, but with planning:
1) Have your server "store" the latest version number of the app (I use Firebase for this). When your app runs, have it check its version number against the version number stored on the server. Thus, if the app is out of date, you can immediately display a message informing the user to update. (perhaps even with a custom message also retrieved from the server, informing them of the relative importance of this particular update)
2) If feasible, you can ensure your server maintains working code for the older versions and the newer versions simultaneously. On your Analytics, once you see everybody is on the new version, you can remove the old supporting code.
As an app developer, this needs to be at the top of your mind ALL the time. This will happen, and quite frequently too.
What you should do is every request to your server, you should supply the app version. Your backend should then use this app version to interpret the parameters of your request and service the mobile app accordingly.
On Android, you can get your app version using the following:
String vName, vCode;
try {
PackageInfo pInfo = getPackageManager().getPackageInfo(getPackageName(), 0);
vName = pInfo.versionName;
vCode = Integer.toString(pInfo.versionCode);
} catch (Exception) {
Log.d("App","Error!");
}
If you used push notification you can use it, or you can cut API service to this app to enforce people to reinstall your app.
Suppose an old version of your app tries to communicate with your server, you could detect this easily on your server and have it tell the user that the app needs updating (like how Whatsapp/other messaging clients).
About half a year ago we released a huge update to the app, and with this introduced new permissions to the app (GPS / Bluetooth related, etc)
Half a year is plenty of time for users to update, however in Google dev console we still shows a large percentage, about 30% of the user base still using the old version.
I'm assuming this is due to
New Permissions require Manual updates, users must to hit 'Accept' before installing the
update, and new update is being bypassed by Auto-Update
Some users have disabled Auto-Update and never update at all
Probably some percentage of old / abandoned devices
We're looking to address #1 as we experienced that making changes to app's permissions creates fragmentation pockets within the user base.
A potential solution would be to show a periodic "in-app" notification prompting users to update. But the problem is how to release an app update only reaching those old version users without impacting current users, as we cannot remove new permissions.
A hypothetical approach would be an in-between update, but the dev console does not allow lower app versions.
Are there any solutions available for reaching stuck users on old versions, or any work arounds that could be recommended?
New Permissions require Manual updates, users must to hit 'Accept'
before installing the update, and new update is being bypassed by
Auto-Update
I don't think you can bypass the prompt for the manual acknowledgment.
My best practices for using adding new permissions are:
Always adding creative release notes to explain why I need these permissions, so the user will download the update.
Luckily with Android M your users won't experience this
Are there any solutions available for reaching stuck users on old
versions, or any work arounds that could be recommended? Thanks!
Once a user is lost, it is very hard to get them back.
You can use your analytics to determine which popular devices are using your old app version.
Depending on the time/resources you have, multiple apks and segmentation based on devices can help you in this situation.
http://developer.android.com/google/play/publishing/multiple-apks.html
A potential solution would be to show a periodic "in-app" notification
prompting users to update.
This logic can live client side and if done right users running your current version do not see that.
Hope this helps or leads you in the you are hoping for.
In the past I managed this sort of situation by having the app periodically check-in with my backend server to report the app version number. The server would check the app version number against what the server supports and if an upgrade was required the server would return a message that the app would then prompt to the user asking them to update. Obviously that doesn't help you with your existing 30% of users but it might help in the future.
I would also think it would help to release an update that targets Marshmallow and then you could use the newer permission model and prompt users for what permissions you need. I would think that would then allow the 30% on the older version of your app to auto-update or update without having to confirm permission changes in the play store. Those users would then be prompted in the app for whatever permissions you require.