Etiquette

If people use it, it seems less than considerate to keep them from using it. You could (should) say that it's no longer supported.

You could also share the source code, perhaps someone will pick it up and continue developing it

I think it kind of depends on why you are dropping something.  I'd probably have the first line of the description state it's no longer supported, and maybe include a link to something comparable.

If it simply doesn't work well, that can often be seen by way of download count and bad reviews.  And by looking at the stats, if it's only been downloaded once in the last 6 months, just removing it may be easiest solution, but then again, that probably means you're not getting bad reviews or contact developer messages, so why bother?  Even if it's only being used by 5 people in the world, no reason to remove it if it has no impact to you.

But I think this gets really tricky if you have paid apps.  If someone buys an unlock key, I'm not sure you can really just remove the app or stop supporting it, and the laws may vary based on where the user is located.  If nothing else, dropping support for a paid app may leave a bad impression for users to all of your apps.

In 5+ years, I've removed exactly two (free) apps, where the data provider no longer provided the data, so the apps became useless, even if a user had them installed.  In that case, evenm if removing them in the app store resulted in the apps getting removed from a user's device, that was a good thing.

In other words, this is not a simple question.  Put yourself in the position of a user that downloaded your app and finds it OK.  What would you expect?

jim_m_58 said:

I think it kind of depends on why you are dropping something.  I'd probably have the first line of the description state it's no longer supported, and maybe include a link to something comparable.

Exactly.

There is a newer, better, more complete replacement for the thing in question. I was in two minds when I released the new one as to whether it was an update or a standalone. In hindsight, it was probably an update, but at the time I thought new as there were some non-trivial changes to settings functionality. The optimal solution would, of course, be to merge them! But that's only possible in an alternate reality.

jim_m_58 said:

But I think this gets really tricky if you have paid apps.

A trickiness that is only complicated by the potential for people to rightly expect updates if they are going to part with their hard-earned.

Is it better to reallocate old sales to new products, and gracefully retire the old, or to leave the old standing along with a notification? (A notification that absolutely nobody reads. In some of my experiments with paid apps I have included significant [up to 100%] discount codes in the first line that were never used despite sales of the product in question.)

You created a new app that does the same thing because you changed how the settings work?

There wasn't a way to change how the settings work without maintaining how the existing settings work?

It seems you wouldn't have had these problems if you just enhanced the existing app (and you would have retained the download count and name recognition).

If the two apps are not paid, you could modify the old app to display a notification about the new app. People probably won't care too much to have to move to a new version if it did the same thing.

If either (or both) are paid, things are more complicated. If it's cheap enough, some people might not have a problem buying the new version again. But that might create the expectation that you'll do it again in the future.

The details of the situation are needed to figure out an appropriate response (but the details haven't been provided).

dpawlyk said:

You created a new app that does the same thing because you changed how the settings work?

Some fairly fundamental changes at a programmatic level, and significant changes at a user level. But we are agreed I would do it differently this time around.

dpawlyk said:

some people might not have a problem buying the new version again

Obviously, existing / paying users need to be catered for and treated fairly, whether it be by swapping licenses or offering discount codes or whatever. That's another discussion, I guess! For all my other faults (and they are legion) it is more common for people to praise than to criticise my customer service. Either way, it is an easier issue to manage than the much bigger change I made a while back to move from a "pay what you want" to "pay to use this". 

The first thing

dpawlyk said:

The details of the situation are needed to figure out an appropriate response

You've probably guessed, it's intentionally vague! This is still theoretical. I still haven't made any decision as to whether or not to retire anything - this is blue-sky thinking for the longer term.

However, you can assume;

1. Both products have free mode and paid mode (because nearly everything I build does)

2. A vanishingly small proportion choose to upgrade but (based on download spikes when I release updates) a respectable number of users find them useful, even in free mode  

3. Whatever I do, or do not do, there is a potential customer issue that I will consider more fully if I need to do anything

4. I have a means to contact and assist paid users if I need to

5. But free users are an unknown quantity... I don't want to hack anybody off, but there is a finite number of products that any single developer can maintain

In the past, instead of doing a new app. I just did an update to the old one.  In one case the api I was using has changed 100% as had the APIKEY.  That way, I didn't lose anything like download count, reviews, initial release date, etc, which can help in keeping an app "visible".  If the initial release was years back, and the download count is high, and the reviews are good, it will probably be more attractive to a new user than something that was first released last week, has one review, and was downloaded 25 times.

It also makes it easier for current users. They really don't need to do anything to get the new version by way of GE or the CIQ app.  I'd almost consider deleting the new app, and using it to replace the old app in this case.

jim_m_58 said:

I'd almost consider deleting the new app, and using it to replace the old app in this case.

Ah... the clarity of hindsight. *sigh*

;)

jim_m_58 said:

the new app, and using it to replace the old app in this case.

However, this may well be the optimal solution.

A full upgrade of the older version might be the way forward.

It would still leave me with some similarities across the range, but would give me a more coherent and updated product using, as you say, the familiarity, download count and so on of the previous one.

Thanks,

9635560 said:

Obviously, existing / paying users need to be catered for and treated fairly, whether it be by swapping licenses or offering discount codes or whatever.

Clearly, you want to do the "right" thing. What I'm saying, is that, while one would not want to have people pay again, that might be the best overall option.

9635560 said:

4. I have a means to contact and assist paid users if I need to

5. But free users are an unknown quantity... I don't want to hack anybody off, but there is a finite number of products that any single developer can maintain

If by "contacting them" , you mean you can let them have the paid version of the new app free, you have another option.

• Keep the old version around (for a while).
• Give the paid customers the paid version of the new app free.
• Tell everybody the plan is to phase out the older version and that they should move to the new version.
• Maybe, explain the situation a bit (be honest).

This might not be perfect or quick, but it should work reasonably well. No one is out anything (except a little bit of inconvenience).

Or, you could abandon the new version and get people to migrate to the old (updated) app. That might be the better option if there aren't many users of the new version.

Yet another option is to make the two apps the same. That would mean one thing to support and test (with a little bit of extra work in building and distributing two apps).

That's what I do with my app and widget.