Single User vs Multi-User - how to tell

[sjhershnyc]

I have a biz app that works well for a Single User (ie, this smartPhone/person only). It draws extensively on sqlite3. Folks who have seen it have encouraged me to write a Multi-User version, so that several “related” Users could collate their individual data - and load it into a central online database that an Administrator could see.

The Multi-User version would have 2 User types/modes: Admin and User. Admin sees all objects, Users may see a more limited range of objects.

I have a mySQL db online that I can access.

Given that the code is essentially the same in both respects, I want to sell a Single-User version and a Pro version, which would allow for several related Users sending data to a specified account.

PARAM PASSING TO APP?

When the app is sold, does the installation process [initiated by the Play Store or Apple’s App Store] allow for any passing of parameters to the purchased app, eg, I want to know if the bought the Single User or the Multi-User version. If the latter, I will take different logic paths (sqlite3 vs mySQL queries) in terms of screen development. At this point, I would like both downloads to be the identical set of files.

Finally, is this even a good idea? Or should I break the two entirely apart, leaving me to have to maintain two sets of code?

I don’t have any experience re selling via either Store so I’m not sure what is do-able in this circumstance.

Thanks.

Seth

[Alan_PlantPot]

There are no params passed to the app by the store.

If you want to sell 2 different versions of an app, you need to create 2 store listings and upload 2 separate apk/ipa files. So in your case, you would just build a single-user version, and in the lua code have a boolean “isSingleUser = true” or something like that. Then build a multi-user version and set “isSingleUser = false”. Then create the 2 store listings, and upload the relevant build to each.  

Alternatively, you could have a single free to download app with an in-app purchase to unlock multi-user mode. Once the IAP is successful, set the isSingleUser to false. I would say that using IAP is preferable, as then you just have one app to update/promote/etc in future. It would mean having to implement IAP which is not always easy, but there are plenty of docs and tutorials on the site.

If you do it this way, I would say make sure that your app attempts to restore IAP at some point when it starts up. The reason being that if someone pays to unlock multi-user mode, uninstalls and then reinstalls the app, they will still expect their previous purchase to be live. Also, I would expect something like this to be a non-consumable (or possibly subscription) type of purchase.

[sjhershnyc]

thanks very much, Alan - excellent explanation. the gotcha re IAP you mentioned would never have been anticipated. Double Thanks on that part.

Given this is my first app, I may take the simpler route - and implant the boolean in each build.

[Alan_PlantPot]

There are no params passed to the app by the store.

If you want to sell 2 different versions of an app, you need to create 2 store listings and upload 2 separate apk/ipa files. So in your case, you would just build a single-user version, and in the lua code have a boolean “isSingleUser = true” or something like that. Then build a multi-user version and set “isSingleUser = false”. Then create the 2 store listings, and upload the relevant build to each.  

Alternatively, you could have a single free to download app with an in-app purchase to unlock multi-user mode. Once the IAP is successful, set the isSingleUser to false. I would say that using IAP is preferable, as then you just have one app to update/promote/etc in future. It would mean having to implement IAP which is not always easy, but there are plenty of docs and tutorials on the site.

If you do it this way, I would say make sure that your app attempts to restore IAP at some point when it starts up. The reason being that if someone pays to unlock multi-user mode, uninstalls and then reinstalls the app, they will still expect their previous purchase to be live. Also, I would expect something like this to be a non-consumable (or possibly subscription) type of purchase.

[sjhershnyc]

thanks very much, Alan - excellent explanation. the gotcha re IAP you mentioned would never have been anticipated. Double Thanks on that part.

Given this is my first app, I may take the simpler route - and implant the boolean in each build.