0

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.).

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
davidcesarino
  • 16,160
  • 16
  • 68
  • 109
  • Just updating the question: I'm satisfied with Carl's answer, but I'd like to confirm what happens *exactly* when you change API requirements. 1) on the latest Play app, users with unsupported APIs won't even see the app in the list of installed apps; 2) on the same scenario, they will see it instead in the full list (swipe left, the list that includes previous apps), as "installed". Opening it will see the usual warning about it not being compatible (no actions, not even unistall). Thus, I still think that the best way is to set the price so high nobody will buy, while still allowing updates. – davidcesarino Dec 11 '12 at 18:49

2 Answers2

0

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.

Zaid Daghestani
  • 8,555
  • 3
  • 34
  • 44
  • Thanks for the answer. I was fairly aware of that already, so I'll left this open for some time at least, just in case someone comes here with other opinions. If not or same, I'll be glad to accept and close this answer. I also asked this to draw attention to this matter. – davidcesarino Jun 10 '12 at 23:11
  • Yes, I'd rather you did leave this open. I'd like to see if anyone has found a way. – Zaid Daghestani Jun 10 '12 at 23:13
0

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.

Carl
  • 15,445
  • 5
  • 55
  • 53
  • Thank you, I ended doing *exactly* this in October, following your idea in [this question](http://stackoverflow.com/q/10005182/489607), that you also answered :). While I had a free and a paid application before, I united them both under the free app package name, only with in app purchases (which covers paid functionality). However, since the new app requires API 8+, both the old and free app are still available (continues...). – davidcesarino Dec 09 '12 at 19:51
  • The old free app is available through the multiple APKs feature (3-7 and 8+ APIs), and the old paid is still available to everyone (3+) in order to not change anything others already paid for. That way I obey the following requirements that I've set: 1) old paid users can migrate to the new app only when they want, without being forced to anything; 2) the new app gains all the *credibility* (as you said, too) of the old free app (more installs caused more IAP conversions indeed); 3) anyone still using 2.1- can still access both the free app (multiple APK) as well as the old paid app. – davidcesarino Dec 09 '12 at 20:01
  • About *end of life* exactly, I've updated the description to reflect commercial availability and support periods of the old apps. Ideally, the old paid app would not be available anymore ("This app is not available etc.") but still listed in order to keep supporting existing users with updates. I have some ideas in mind and will report back if I collect some answers. – davidcesarino Dec 09 '12 at 20:10
  • 2
    This is a great example of how complicated an upgrade process, or adding a new product, can become, and also of how much creative effort is required, even with options like in-app payments, to patch together a solution that works for both new and legacy users. – Carl Dec 10 '12 at 14:06