Is there an elegant way to handle end-of-life scenarios for an app on Google Play?
Suppose I have an app ("A"), and this app is being superseded by a suite ("S") that has all the functionality of that old app. In other words, S will absorb A. I think it makes sense, from a business point of view, to:
Prevent new sales of A, directing all new sales to S.
Keep supporting A with updates and fixes.
I want to know if it's technically possible. Please disregard SDK requirements and user experience and other OT issues, as I'm not considering with that yet (besides, with this I can always gift old customers in case I want to).
Right now, the only way I see to achieve this is to set the price of A so high that users won't buy it. That way I can keep providing updates without increasing its user base (and thus time spent on support etc.).
One very simple approach would be to simply upgrade your old app to have the new functionality of your suite app, and then rename and re-price the "old" app (which is now your suite) to reflect its new status (e.g., add the word "suite" onto the name). So far as Google Play is concerned, it will still be the same app, only "better." You will keep all the credibility gained from installs of the old app (by essentially upgrading the old app). Your old users will be happy because (as you've described it) they will have all of the old app's functionality, plus some additional functionality.
When I say "upgrade," that doesn't mean that you have to start with the old app's code base; you can just create an entirely new project and APK, so long as you use the same package name and upload it to the old app's location on the Google Play store, and so long as functionally it covers all of the bases expected by your existing user base.
Based on your description, I really can't see the down side of this. It may be that by conceiving of this feature superset as a new product rather than as an update you've created a problem that need not exist.
Currently, Google provides no such functionality. Your best route would be to add functionality to app A that allows it to update using your own private servers, then unpublish the app from the market. It really is quite that Google provides extremely limited functionality in the Dev Console. Instead of taxes, they should've added app coupons and private app listings. Oh Google, "driving sales" as always.
Related
Now my company wants to update app with significant changes.
In new app version will change absolutely whole design and internal logic (code).
Will the market allow such an application to be released? Wouldn't that be an intellectual property infringement?
I would like to see official links with information about it.
Updating an app and completely replacing everything about it is fine. Sometimes you rewrite apps, that's ok. The only requirement is that the signing key remain the same, and the version code increase.
As for UP infringement- if your company owned the original app, how would that even remotely be IP infringement? You own the rights to the IP, that includes the right to no longer offer it for download, or for you to reuse the name for a new app.
Some background: over 10 years ago, I published a few apps to the Play Store (or, Android Store as IIRC it was called at the time). They were used to help navigate the London Underground. These were live for about a year or two until their functionality was superceded by modern alternatives (basically, when Google added its transit layer to Maps). I unpublished them at that time (circa 2012) and basically forgot about them completely.
Fast forward 10 years, Google are now asking me to fill out a bunch of data safety and privacy forms. I have done so in the hope that they stop nagging me, however one of the sections I have to fill out relates to "Sensitive permissions / APIs" - specifically, fine location access. At the time, one of the apps requested the user's location (possibly in the background; I don't recall) and used it to locally render a dot on a Map activity to show where they were, and also to work out where their nearest station was. This data was never sent off-device. This was obviously targeting a very old version of Android (latest it ran on was probably ICS or Jelly Bean).
It appears that I can just state in the form that the app targets a version older than Pie and doesn't meet the location requirements, but would that then trigger a requirement that I need to provide a new APK with a fix? I'm not even sure if I still have the original source code.
Does any of this even matter if I never intend to make the apps available again (or, based on this experience, ever publish anything else to the Play Store)?
Ideally, I'd like to delete both apps entirely, but from what I gather Google have intentionally made this impossible.
You probably can ignore these, as long as they don't state that it will suspend your account. Choose the option that you need to declare those data collection, and simply declare everything.
I want to create a new release of Android product (an updated version, actually) but I want this version to be available for ALL fresh installs and not for updates.
Especially because the updated version has important improvements mostly for first-time users and I don't want to bother existing users too early.
Neither open/closed tracks nor staged rollout meet this criterion.
I have enough fresh daily installs to estimate the effect of the updated code, then release further updates to extend the userbase.
As an option, it would be acceptable if "staged rollout" would provide a checkbox like "make available for all new installs".
Any more ideas? Many thanks!
The whole Android/Play model is designed around the same software being available for new users and for existing users. So there is no easy way of doing this. There is also a negative cost you may not have considered. New users will often reach out to existing users to help them when they get stuck. If you make the experience different, then this help method (whether via online forums or face to face) breaks.
If I absolutely had to do this, there are two options I would consider.
Option 1: Use a product like Firebase Remote Config to dynamically change the code for different users. That way you could do the configurations on the firebase servers, and still only ship one version of your app
Option 2: Release a new package name (Application id). That way new users would by definition get a new product. You could even give them different descriptions, store listings and screenshots
Each of these has various difficulties, but many of the same difficulties would apply if Google Play tried to launch a service which gave different apps to new users.
I currently have an Android app which is distributed as two applications an Ad supported version and an ad-free version. The Ad-Supported version has over 10,000 users and the Ad-Free version has a couple of hundred. Currently both projects are completely independent making updates a fairly tedious task.
Ideally I would like to just updated one project and build be able to build both versions.
After looking online it seems I have two options:
Make a library containing most of the class files and then just extend this for the two versions (changing only the files that are different). As the project is fairly big this may be a large task and may cause some serious headaches.
Just release one version and use in-app purchases to remove the ads. This seems the easiest route but how do I allow my existing ad-free users to remove the ads via in-app purchase without paying?
Hopefully someone has been in a similar predicament before and can point me in the right direction.
Where I used to work we had the 2nd option. It helped us a lot since you just need to maintain 1 code/app/apk. In your case, I suggest you to do the same thing.
In order to migrate all your users to a single App, you can give a random code (generated with the email they are using and an algorithm to create it) via your "Ad-Free version" app. Then, in your All-in-one app you can ask for that code or activate the "In-App-workflow" in order to remove all Ads.
Edit:
Check this link:
How to get the Android device's primary e-mail address
I am always recommend SO user to used android inapp purchase.
Benefits:
1) Easily track manage your playstore user.
2) If updation require then update code on one place.
3) Secure payment with google policy.
4) many more feature.
#bencallis as per your question i recommend to you option 2 is better.
if you require any inapp information then put comment.
You're in a similar boat with me, though I've taken one step already.
I made an app for a small group of people that are close to me, free and ad-free, and released it. I then created another app for a wider group of people, free but with ads. The two applications were almost the same, except a few things that had to be app-specific (like strings, resources, and a few variables). After getting frustrated with updating both of them, I decided to go with the library approach. It might give you headaches in the beginning, but it will truly cut down on your updating. You'll only have to update the library file, then just compile and check the actual application.
Because of how you describe your situation, I think you'll have an easier time than me. Turn one of your applications (probably the ad-free one) into a library, then in the ad-supported version simply overwrite the layouts that show the ads.
I can't suggest your second option, only because, as far as I know, there is no way to do what you want.
No previous questions about it, so here I ask.
Background:
I have an old app, in free and paid versions, in the Play Market. I created a new version, radically changed and with a different payment system (free app + in app purchases only, no more a paid version: reduce maintenance costs). minSdkVersion also changed from 1.5 to 2.1.
Because of all those differences, I decided to upload a new app, not just update the current one (i.e., not selectively provide a new apk for API 7+ --- multiple APKs). This is especially important because of the new payment system, as I don't want to force old, paid customers, to buy everything again. I want to leave them alone and happy as they are (4.4/4.7 rating). In short, I don't want to "force" people into anything. In this case, into buying again the same thing through in-app-purchases, besides other things the new app offers.
Questions:
Having explained to you my background, it raises the obvious questions:
1. How do I hide the old apps from the API 7+ audience while still keeping them visible to all the current API 7+ customers, i.e., those that already bought it?
My biggest concern here is the paid app. I'm thinking about pushing a new version with maxSdkVersion set to 6 (SDK 2.0.1), effectively blocking new API 7+ customers to the old apps. But I'm worried that the current API 7+ customers will suddenly lose access to the app. That raises two questions:
2. Will they be able to keep updating the app? is it reasonable to guess "yes"?
3. Even if the answer to the previous question is "yes", it's still unclear to me what will happen if the user uninstalls the app, and then go find it again in the Market (not just updating). Will it disappear or will it still appear under his "bought" apps list, considering that meanwhile the app filter requirements changed?
Remark: I would upload a test app to see that, but AFAIK the author is not allowed to buy his own app (even the license behaves differently), so I couldn't test the uninstall-filter-install scenario.
# # # # # # # Reply to answers: # # # # # # #
#Sparky:
I think you got it wrong. I know my way around multiple APKs, and, of course, the documentation. The problematic here is way beyond that.
Note also that maxSdkVersion is deprecated, so this throws a little bit of a wrench into your proposal to cap the old APK when you issue the new APK.
Thank you. I missed that.
Multiple APKs offers a simpler user story.
If you say so (besides the other things I didn't quote), I think you probably didn't wrap your head around this issue. Please follow me:
I have n paid customers that bought my current Pro app version.
They are using the feature set X that they've got with the Pro version.
I decide now to implement in-app-purchases to offer feature set X, Y and so on...
Unfortunately, these changes made by app API 7+.
Thus, as you so suggest, I decide to offer multiple APKs.
Now, the API 7+ crowd suddenly gets updated to this new version of my app.
Because they update to the new APK, they LOSE their feature set X. They now need to buy X again (from the in-app-purchase menu). I took from them something they already had, albeit in a "less shiny" way. It's like me saying:
You either pay me again or you lose what you already have.
Do you see the problem now? Do you see why I'm forced to provide a new app? Or am I still not getting what you said (I think not)?
Here is an untried idea for your consideration:
Upgrade your present, pre-in-app-payments app to include a ContentProvider that provides a cryptographic hash that only it knows how to generate in response to a random seed (to prevent replay attacks).
Release your new app that uses in-app payments as a separate APK, and have it check for the existence of the earlier app on the user's system by attempting to access the ContentProvider just described, passing it a random value and confirming that the response is correct. If such a response is received, then the user owns the old app, and you can enable the corresponding features of the old app in the new app without requiring any in-app payments to do so.
Now, if some of your users skip the upgrade to the old app that gives them the new ContentProvider, and go straight to your new app, they'll be dinged for the payments. But they can then upgrade if they like and run the new app again to get validated.
This does address your issue. However, it has issues of its own. So, put it in your tool kit and see if it comes in handy, as is or in combination with something else you may later devise!
You will do yourself a disservice issuing a new app instead of an update without at least considering multiple APKs, because it complicates upgrading your existing paid users.
Suppose you simply update your paid app to API level 7, cut its price to 0 and add In-App Payments. Devices with API level >=7 will be offered an upgrade, while devices with API level <=6 will not be notified, won't see it in Play (Market), and won't be able to reinstall if they uninstall. That would be 'no' to your questions 2 and 3.
But now it is possible to implement multiple APKs:
http://developer.android.com/guide/market/publishing/multiple-apks.html
http://developer.android.com/training/multiple-apks/
Specific to your issue, you can offer multiple APKs based on API level:
http://developer.android.com/training/multiple-apks/api.html
This lets you maintain two versions of the same app, separated by API level. So the answer to your question 1 is, implement multiple APKs per the cited articles.
By publishing a whole new app, your answer to question 2 is 'yes'. By implementing multiple APKs, the answer to question 2 is also 'yes', and your application lineage/upgrade story is a lot simpler from the user's perspective (a bit harder for you technically, easier in the customer service department). Note also that maxSdkVersion is deprecated, so this throws a little bit of a wrench into your proposal to cap the old APK when you issue the new APK.
Likewise with question 3. Either by publishing a new app or implementing multiple APKs, you can keep offering an APK for the legacy API levels that your users can find and install.
Multiple APKs offers a simpler user story. Publishing a new app makes it easier for you to differentiate the apps, if for example you want to say, "Look! Now EXTRA shiny!"