Sorry your browser is not supported!

Hello everyone,

I try to ask my question as simple as possible. If I had a finished mobile application I wish to sell on popular marketplaces, but would like to hook up customers with a monthly fee, how is this achieved technically?

Let's say I'd let customer to try the application for 14 days and after that he/she is ought to pay a monthly fee for using the application with full features or either use the application with limited features for free. What things are required in the payment process and then permitting the application to function with full features?

If someone has any experience or knowledge about this, please, give a few hints. Any help will be much appreciated!

- CodeTrasher

If you distill these things down into simplest terms, All you need is a mode switch. So the program functions depending upon it's current state.

Eg.



Throughout the program code, all we're doing is checking the state and reacting to it.

Say saving is disabled for free users. Then in the save routine, there would be the obligatory check and reaction. Or alternatively simply not even show the save option when in free mode.



Now there's a few obvious problems, namely since the Free and Retail modes are all self contained within the same binary, users will eventually work out a way to switch on retail mode without paying for it. But ignoring that for the time being.

Further simplification and all we're really talking about here is an old school shareware app, that requires activation every month. Normally the customer orders the program through some 'payment portal' where there's either automated response (server level) or the manual progressing of that order data.

With 3rd party portals the order process is generally transparent to the developer, they handle the money side and send you a notification when successful orders comes in. You then send the customer a 'serial / key ' or the 'private retail build' of the application.

When the program is activated by the user, they're either typing in a serial or directing the app to a local copy of their custom user key (or whatever you want to call it). When a valid Serial/Key is present, the program can either take for granted that it's valid, or request a further match from the external server. You wouldn't send the raw 'serial.key' here, rather some mangled hash of the serial/key data. If successful, the APP flips the Program_State to retail mode.

To make this monthly, external validation feels like a better option. The program could store information locally, but then it's only a matter of time before somebody susses out what the local data files are and works out to extend the retail period. Turning the system date back is the most obvious way.

So an alternative model might be that the user orders a KEY, this key activates retail mode. When in retail mode, the program always verifies it's state by querying the server (at some interval, on startup.. or whatever). The server stores the active state of the key locally, so when a customer has paid for a month then the server is allowed to return positive response, if they haven't, it's negative. The communication here would need to be pretty tight though (ie redirection/spoofing).

Personally, I think monthly is way too frequent for any application. Every 3 months seems a little more comfortable, but not much. All comes down to what you're protecting really. I'd imagine if the software is really useful to somebody, they'd much rather purchase a yearly license.

Note: To be very clear, all of above is very crude simplification of the such mechanics.

Kevin Picone, thank you for your thorough answer!

Yesterday I also realized that monthly fee might be too frequent. Considering it's a mobile app I'm planning to sell, it might be better to just place a price tag that is up to app's value and quality, and forget about any other payment plans.

Your reply and thoughts you shared with me were very helpful. I have now a much clearer view to my project and billing system.

I think you'd be better off selling in-game currency, or play time credits. Like someone using the Apple store could just buy game time using in-app purchases, perhaps for a few bucks the player gets a month play time and some bonus money to spend - but that model is getting old, and people are simply finding way that they prefer to pay. The main one these days is in-app currency, buying coins to buy weapons or whatever - and people will spend money this way hand over fist it seems.

So I would suggest that you make the game free, then sell in-game currency for weapons and upgrades and anything that players might want to spend real money on. I really think this is the only way to make money with indi games these days - the apple store is the domain of big-budget publishers nowadays, very little space (if any) for the little man. Your game has to get big, quick, and the only way to do that these days is to throw it at people for free.

For example, there's a Chinese game app that makes about $2mil per month on in-app currency... the right game could make shedloads of cash this way.

With iOS (assuming you have paid for a developer account and have filled out all of the appropriate tax forms to allow you to make money off of your apps) you use something called In-App Purchases. In-App purchases can either be consumable (used once and then gone, like buying coins in a game), non-consumable (once bought it exists forever), subscription based (what you're looking for) and there's one other one I can't remember right now.

You'll first have to enable In-App purchases for your application in the Provisioning Portal, which can take some time as it's a bit of a confusing process.

After that, regardless of what kind of In-App purchase you want to incorporate, you need to fill out a form on the Apple Developer portal describing what the purchase is, providing screenshots of the purchase in-action, setting the price, etc.

After submitting a request to create an in-app purchase you'll need to setup a secondary (free) Apple ID and register that ID as a tester in your app via iTunes Connect.

With all of that done, you now need to sign in with your test account on your test device, and you can finally start the actual programming of the in-app purchase.

There are several different ways to program the actual purchasing of the item, but I would recommend (from my experience) to use Parse (www.parse.com) if you're going to be doing any other back-end stuff anyways. It's free until you go over a million push notifications or parse queries a month, so its very reasonable.


In terms of how the actual code works for determining what content to show the user, Parse makes it quite easy but the process is similar if you're not using external APIs. You either check if a PFUser has bought a given product using Parse, or check if an Apple ID has bought a given product if you're not using Parse. If they have bought it, allow interaction (pressing a "read magazine" button, for example), otherwise deny it or alert the user that they need to purchase it if they try to interact with the item that hasn't been purchased.