I've a Free/Donate versions of my opensource application on playstore.The problem currently I'm facing is duplication of work. Because of two different packages, whenever I update my free version, I need to update my donate version. Both versions are exactly the same in functionality perspective and only the packages are different.
I'm thinking of converting the donate application as donate key. But not sure How strategically move all the donate users to free version. Because it's fully functional app.
BTW, the donate user base is around 1000+
Any help would be greatly appreciated ! I'm not sure whether this question can fit in SO. Please feel free to move it to relevant stackexchange.
I would do the reverse.
I'd make the donate version (app B) a free app with in-app purchases for donations (and I'd maintain several donation levels). And I'd mark all the current users as donors. This way, these users (who actually gave you money) don't have to move anywhere (this is what I would expect when I'm a paid user).
And I'd ask the users of the free version (app A) to move to the donate version (app B). I'd just mark the old version (for legacy devices) and I would only give updates to (app B). People who haven't donated anything will understand that they need to migrate to the new app if they want the new features. It's what they'd expect.
The drawback to this is that you'd lose the recorded number of downloads and positive reviews associated with your original free app, which must be pretty significant (although, technically you could keep that app around as an app for legacy devices indefinitely).
Related
I would like to migrate my app from a free/paid scheme to a free app with in-app-purchases.
I will be using the old free app, as the new free app with the in-app purchases, and I am looking for a way to make this transition.
How can I achieve this?
Is it possible with Google Play Licensing to retrieve the licensing information about another app still owned by the same developer account? Or you can only retrieve licensing information about the current app?
Otherwise, which other ways there could be to recognize a user being the owner of the paid app?
This is not possible due to potential ways to exploit the workings of the Google Play store (potentially skewing download counts, and such; a free app is more likely to get downloads, and those will boost its rankings before you make it cost money).
This has been asked before, and the consensus is that it's not possible by design. There are a few solutions in that thread, such as:
Make your app free, last one week, then have the user use in-app purchasing to continue using it. (Not sure if this is exactly what you hoped, but it's a potential way of monetizing regardless.)
Put up a free version, and take it down in a week. Users will have to reinstall the app to get the paid version but this would still have the same desired effect.
Do an update (or have a setting in your app that expires at a certain time) to remove the paid features after a week (this might tick off a lot of users, though).
Sadly, as I said, this is not possible, so you'll just have to work around it best you can.
Even the original question was asked long ago it is up-to-date for me now :)
I think about allowing paid features in the free app in case the (old) paid app is still present in the phone. You can check this using PackageManager.
I'm new to using Google Analytics in applications, and I want to have a clear way of distinguishing free users versus paid users of my app.
So far, I'm considering using three different properties to track this (one for overall, one for free only, and one for paid only), however, I get the feeling there may be a better way to do this.
I've been reading over GA categories, which seems interesting and applicable, but I'm not finding much information on them on the net.
Does anyone here have a recommendation for separating free/paid analytics in a clean and concise manner whilst preferably having a good overview of app usage in general?
Set up a custom dimension on a user level (since presumably users won't usally flip between paid and unpaid versions). That way you can set up filters to have different views for paid/unpaid and still have a rollup view that displays values from both versions (for example to see how users behave that eventually upgrade to the paid version).
I decided to build a paid version of my free Android application.
The paid version has some extra features. How do I manage both versions?
Is it possible to keep them based on the same source code?
If an application requires unique package name, how do I force paid application to replace free version?
What about db, preferences and other privately stored stuff, how to share them without exposing all data to the rest of the world?
Any advice that will help to manage both projects,
but not answers the above questions directly, is appreciated as well.
There are several approaches:
Put the core of your app in a library project, and create two other projects one for the paid, and one for the free version of the app. An upgrade to the paid version means the user has to uninstall the free version, and looses all the data.
This is the "classical" approach.
Let the user make an in-app payment. The user keeps all database and settings, and you have to maintain only one app.
This option requires extra modules to be included in your app, and extra logic.
Make another dummy/empty app, this is a paid app. The existance of this app means the user has a paid version. The user keeps on using the orginal/free app.
You can simply check by using the PackageManager to see if the paid app is downloaded.
The user keeps all database and settings, and you have to maintain only one app. Ok, there are two apps, but the second can be really small and simple.
You don't have to include additional libraries/code to make an in-app payment. You can also have all your apps upgraded to the 'pro' version with one purchase.
I don't know if all users understand this pattern. For the developper, this can be achieved with minimal work, and the users keep all their settings while upgrading.
I think it's possible and recommended to keep them in same source
code. Otherwise you have to support two versions of app instead of
only one.
If you have only one app therefore you have only one package name.
Create a class responsible for app features availability in current license state (free or paid). This class should store information about license state (free, paid, maybe you will deside to add subscription mode in future in which paid version can expire after some period). Features of your app available only in paid verion shoud check current license state. You can also change app GUI depending of license state. For example hide GUI of paid features, show "Buy" button or ads, etc.
And also if you have only one app that can be free or paid you don't have to share any internal app data between paid and free versions.
I sell a game on Google Play called Quantum-X. Not many people have bought it so I want to move to an ad-supported model and make it a free download.
But I want to reward the people who did buy the game by disabling advertising. So existing users see no ads, new users see ads. I can store a flag in some obfuscated, device specific way which makes this determination.
But in order to this I need to tell the difference between paying and non paying users.
So how do I do this? I have a few ideas but I don't know if any of them are viable:
The old app wrote some preferences out. I could look for an old preference and set the flag. But this will not work if someone installs the app on a clean device since they won't have that preference. It is also an exploit since anybody could put the old key in to fool my app into disabling advertising.
My pay app currently uses LVL to validate a person's licence. If I make my app free, what happens when I call LVL? Does it respond LICENCED even if a user downloaded it for nothing? If I could tell paid from non-paying users from the response then I know how to set the flag. But LVL is a pain to test since I would have to upload the app, set it to free and then see what difference there is in the result and there may be none.
I could produce one final update of my pay app which sets the flag and asks users to upgrade. Then I could roll out the app free in a month from now. The same problem exists as with 1. that some users may not update or may install onto clean devices.
I could produce two apps on the store. The pay app could be renamed to "Quantum-X legacy" and a new Quantum-X goes in its place which is free. I would update the legacy version to install the flag, but people would have to switch to the new version for continued support. This would work but it's a lot more effort.
None of these are pretty although 2. would be the least amount of work. Has anyone experience of a working solution, or know a some better way of doing this?
EDIT: My intention is now a hybrid and I've begun to do this:
Rename the old app as Quantum-X Legacy and update the description.
The new free version is called Quantum-X. The only fly in the ointment here is that I must update the app package in the manifest to make the two apps distinct.
I intend to put a test into the free version that calls LVL using the old app's key. If this works the way I think it will, it will tell me when a user has bought the old app (since the licence server is being asked about the old app), and I can write out an obfuscated flag somewhere so I don't have to call LVL any more.
Free users carry on but with ads.
I'm up to 3. and this is my intention. If LVL doesn't work, then I might have to put out an update to the legacy version which writes the flag or puts a code out on screen that someone must use to enable adfree when they install the other version.
I have a simple database driven app. I'm looking to offer a free and paid version. The only limitation in the free version, is that you're limited to adding 10 records per month.
What is the best way to handle upgrading from free to paid, while maintaining the database?
I had planned on using in-app billing to unlock the ability to store unlimited records/month but I think that is probably beyond complicated for my simple app.
Other ideas were to sell an unlocker app... I don't know if people get confused by this concept though or not.
I could always write the free db to an sd card and have the paid app copy it. But a concern is people without sd cards and it just seems like something would go wrong and somebody would lose their data.
Any thoughts on this?
If you don't want to use in-app billing then you need two separate packages, free/paid or free/unlocker. IMHO free/unlocker is far more convenient than the free/paid. In you choose free/paid you will end with two copies of the same app and you are going to have problems like the one you mention with the databases.
Android LVL is a no go in this case, you can use it to check licence and enable/disable the 10 records per month restriction, but you are limited to one package (meaning you will have the paid apk in the android market but for the "free" version you need to distrubute the application by your own).
I think PowerAMP offers a good solution. They have a free app that acts as a trial of their product and when the trial period ends, they show a dialog with a link to the unlocker app in the android market. You can use the same strategy, when a user tries to enter more than 10 records/month show them an alert with a link to the unlocker app. I think this should solve your concern about people getting confused.