I've got a quiz app on the Android market right now selling for $1. I would like to offer a free version with limited questions, and include a menu offering the user to upgrade to the full version.
My question is simply what the best practice is here?
The possibilities I can conceive are:
Have a link in the free version that takes the user to the paid
version's url on the android market, whereby they'd just download the full version directly.
Have condition statements in the free version that limit the
number of questions available if VERSION == FREE, enable all
questions upon purchase by setting VERSION = PAID.
Download the additional questions upon the purchase
(would that require my own file server?)
What are your thoughts?
Can't say there is a best practice between these 3 variants, you should just choose the more appropriate approach for you and your application. First variant is the simplest for you as a developer, second offers a better user experience, but you need to implement In-App Billing in your app. And the third approach is the most difficult cause you'll need a server to store your files on. I'd personally choose the first approach, since the second one has a pitfall - you need the locked questions to be inside your demo version's apk and it's just not secure. The much more secure approach is to not put them in your demo version - this is what the first approach gives you. However, it's your choice as a developer. Good luck!
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I'm looking into monetizing my first app with a free and a paid version. It seems that the simplest approach would be to use an in-app purchase to unlock extra features. However, I'd also like the customer to have the option to purchase the full version outright on the Play Store (more visibility that way). I could publish a "pro key" app as an upgrade key, but then they'd have to install 2 packages and it seems like a hassle. On the other hand, I don't want to have to support two independently complete packages (one free, one paid).
So I'm not sure what approach to take. I want to let users upgrade from within the app because that would be simplest, but I also want a the customer to be able to buy and install the paid version straight from the store. Thoughts?
I see three solutions.
Add In-app purchase
Add new app "Your app name pro unlocker"
Add new pro version of you app
I think that the first one is the most reliable and easy to achieve. It is harder to crack by pirates too. Pirates can upload your app to their sited but when user will download it he will get normal free version. Of course anything can be hacked ;-) but... it is better than 3rd option (see below).
Second one - in you main app you need to check if "pro unlocker" is installed, maybe you will need to check if certificates are the same and run, custom implemented, android service in this to check if use is allowed to use pro version. It is quite ok and beacuse you will use a quite lot of custom coding it should be safe.
Third - using Grandle you can simply create second version of your app, during building Grandle will create pro/free version automatically. However pro versions which are using Google Licensing are easy to crack by pirates so...
To sum up - you have 3 three solutions. I think that the first one is good enough and it is not requiring too much code or time for maintaining. I hope that this will help you ;-)
Cheers
No. Free and paid apps are handled completely differently on the market.
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.
Now I've nearly finished my first app and I wanted to have two versions of it, one free (with ads and a little less functionality) and one full/paid version.
I know that you can not completely prevent apps from being cracked/distributed, but anyway, I'm currenlty having some thoughts about what the best method would be to release the app.
1) Both full and light versions in the store with no additional checks
2) Full version with Google Market license check integrated... Does this really bring any "security"? I've read that this protection has been cracked and therefore is pretty useless?
3) Have the light version and convert it via InApp purchase to the full version? Currently I have no idea on how to implement InApp billing and how to check whether a user paid inApp to release the full functionality and... of course there are also ways around that, right?
How would you do it?
Do you try to prevent your app from being illegally shared, or do you think it's not worth the effort, as any protection can be removed (and then it's shared anyway)?
Just gathering some thoughts :)
I have been through the same thought process and settled on option 3 for new apps.
My reasoning is as follows;
With option 1 you have two apps to maintain, users have to do a uninstall of your trial version and you have the problem of migrating data between the two versions.
Option 2 has all the problems of option 1 plus the headache of implementation.
Option 3 you have the benefit of only one codebase to maintain, users can quickly and easily upgrade with all their data intact and you have higher download stats/ratings for the one app rather than two.
Implementing it has got a lot easier with the version 3 of the billing library. I followed the sample from Google here and got a simple remove the ad's with IAB within a couple of hours.
I personally think that an In app purchase is the most secure way to stop people from getting free paid versions of your app, because when someone inevitably (if your app is popular) release an apk file of your app on the internet, it is just the free version.
If I want to deploy to the Android Market it looks like I have two options:
Create my own keystore and upload. When I update my app use that keystore on my APK to ensure that users are given the option to update.
Do step 1, but also implement Application Licensing which will put controls on how the app is used.
Am I correct to assume that step 1 means that anyone could copy my APK once it is purchased from the Android Market and install it anywhere they wish?
How common is it for people to use Application Licensing and is it the defacto approach?
My app will be paid and I want to ensure I am taking the best approach.
Am I correct to assume that step 1 means that anyone could copy my APK once it is purchased from the Android Market and install it anywhere they wish?
Yes you are correct, it would be extremely easy to copy your application.
How common is it for people to use Application Licensing and is it the defacto approach?
I would say it's very common since it's the only way to verify the licence against the Android Market, though I don't have any stats on this. Otherwise you would need to implement your own "Market" and verify purchases in your own.
My app will be paid and I want to ensure I am taking the best approach.
Use LVL, DO NOT use the default implementation. Watch the LVL session from the 2011 IO for a how to.
Often times, people will not simply download an app and copy it anywhere they would like. However, it is possible through some apps and other software for users to copy off APKs from their phones (even though they aren't suppose to). In my opinion, if you app is paid, you should implement Applicant Licensing. It is a very useful tool to help in preventing people from stealing your APKs (in other words, downloading it and then trying to install it some where else) as it checks on start up to ensure that the app is on the phone that purchased it. Otherwise, for free apps, I don't really see the neccessity because it's free and anyone could have downloaded it.
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.