Create Free/Paid Versions of Application from Same Code

Create Free/Paid versions of Application from same code

Possibly a duplicate of Bulk Publishing of Android Apps.

Android Library projects will do this for you nicely. You'll end up with 1 library project and then a project for each edition (free/full) with those really just containing different resources like app icons and different manifests, which is where the package name will be varied.

Hope that helps. It has worked well for me.

Best way to have paid and free version of an Android app

The Android SDK formally addresses the issue of a shared or common codebase with something called a library project.

http://developer.android.com/tools/projects/index.html

Basically, the shared code is defined as a library project, then a paid and a free version are simply two different projects in your eclipse workbench, both referencing aforementioned library project.

At build-time, the library project gets merged with either of your releases, which is what you want.

The Android SDK example source code contains a project called TicTacToe that will help you get started with library projects usage.

Good luck.

Daniel

How to manage free and paid versions of an Android project?

There are several approaches:

1. 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.
2. 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.
3. 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.

Making a free and premium version of the same app is it better to make one app or 2?

first of all,
if you are going to develop apps for appstore, you can't create 2 apps have the same basic features but one has pro features
that's according to app-store review guidelines 4.3 spam
says....

4.3 Spam

Don’t create multiple Bundle IDs of the same app. If your app has
different versions for specific locations, sports teams, universities,
etc., consider submitting a single app and provide the variations
using in-app purchase. Also avoid piling on to a category that is
already saturated; the App Store has enough fart, burp, flashlight,
fortune telling, dating, and Kama Sutra apps, etc. already. We will
reject these apps unless they provide a unique, high-quality
experience. Spamming the store may lead to your removal from the
Developer Program.
Blockquote

if not.

then second.

both will work fine,
there are games like limbo have free and paid versions on google play

that's your decision anyway,

if there is a lot of difference between free and paid,

if it's just about unlocking some features and remove ads,

it's a simple answer. if both of options will give the same functionality,
choose the easiest way

and "separate listing for the paid app" not a good idea, why?
@KiloKw2 mention to that

How to maintain a paid and free version of an app

I think the first approach I'd try is using 3 projects in Eclipse: one for either version of the game, and a library project with all of the shared code. The library project would be where all the code for your core gameplay goes, and the version specific projects manage loading different layouts, putting ads in the free version, and adding levels/features/hats to the paid version.

You might be able to accomplish your goal of a single code base with a compiler flag using an ant task, but that's beyond me.

Using a library to maintain free/paid for app versions

I would not suggest you to maintain only a single APK project. Instead, I would suggest you create three projects total; one is the Library itself, one is the free APK, and the other is the paid APK. Using this plan, your "free APK" project would do little on its own; it would effectively be a carrier for the library (though you can of course add its own code if appropriate). The "paid APK" would provide the additional functionality, and a means of telling the library to use it (through callbacks, reflection, whatever makes sense to you). This solves your concern of carrying code that you don't plan to use in that version and it doesn't require anything special of Eclipse or any other build environment.

Maintaining paid and free version of single react native app

I'm not familiar with react native, but in general. There are a few ways to handle this.

One code base with flag

If you want to maintain one code base you can create some kind of paidVersion flag in your code. If the flag is false, certain buttons that allow the user to use paid features are simply hidden. If the flag is true, the buttons that allow the user to use paid features are visible.

This is probably the easiest thing to do.

Two branches

Software companies oftentimes find themselves in a position where they maintain a free open source version of their software, and a paid closed source version of the same software with some extra features. To minimize the effort of maintaining the two products which are basically the same, they do the following.

• The free version is maintained on branch A.
• The paid version is forked from branch A and is maintained in branch B

Now there are three cases to consider when you change the product.

• Changes that are used by both the free and paid version: These changes are merged into branch A, then branch B is rebased onto branch A.
• Changes that only go to the paid version: These changes only get pushed to branch B
• Changes that only go into the free version: This is a bad case and don't do it, because then you start going down the path of maintaining two different products.

Plugin Framework

Make the free version of you product support plugins. The paid version of the product is simply the free version with a plugin bundled with it.

Conclusion

The right method to use primarily depends on what the nature of what you are building. If the product you are building is very complicated (like an IDE) and may have multiple optional paid features, then you may want to use some kind of plugin framework.

If the product is simple and you have no intention of sharing the source code of either the free or paid version, then using a paidVersion flag is the best route.

If you want to share the source code of the free product, then you should probably use the two branches strategy.

---

Related Topics