Got a general question(s) for you on implementing a free and paid version of an app.
I have it setup now where I have 2 targets within the 1 app/project and I specify with the def syntax for what is in the lite vs paid version.
It works and runs both targets.
1) How do I have the user purchase the paid app directly from the free version? (Found multiple older articles saying linking is fine and others saying that will get rejected and must use in-app purchase)
Can I use a link tied to a tab bar item or button like this,
NSString *iTunesLink = #"http://itunes.apple.com/gb/app/wired-news-uk/id435728870?mt=8";
[[UIApplication sharedApplication]
openURL:[NSURL URLWithString:iTunesLink]];
OR do I need to implement the storekit for an In-App purchase?
2) I was going to put a new Tab Bar item at the bottom (to link to paid version) - haven't tried yet but I should be able to setup the tab bar one way for the free version and another way for the paid version, correct? Essentially, hiding the tab bar item to purchase the paid version once upgraded.
3) Submitting each app (free and paid) version to the app store - I'm assuming I will be able to set the target and archive the binary for upload for each, right? Two separate app submissions in itunesconnect?
I have several Lite/Paid app pairs in the app store (all were originally created before IAP existed). I've made many updates to these apps over the years so it seems Apple is fine with the idea in general, if you do it right.
1) You can't actually purchase the paid app from inside the free app. The best you can do is send the user to the store for your paid app.
2) That should work. In one of my apps, I have an extra icon in the main toolbar that brings the user to the app store page for the paid app.
3) Yes, you submit two completely separate apps. You setup two apps in iTunes Connect each with their own unique app id.
A single project with two targets is the easy and proper way to setup your code. For me, I do two archive builds, setup two apps or app updates in iTunes Connect, and submit the two apps/updates to iTunes Connect. I always keep both apps in perfect sync. Apple always seems to review them together and always pushes them out to the store at roughly the same time. Only once did the two get approved more than an hour or two apart.
The main thing you must be careful with is the free version. It can be "Free" or "Lite" but not "Demo". The free version must fully function. DO NOT have any UI elements in the free version that are disabled because they only work in the paid version. It will get rejected. If it doesn't work in the free version, make no mention of it at all in the free version.
Most of my app pairs, the free version allows for limited data compared to the paid version. When the user attempts to add data beyond this point, I popup an alert with a nice reminder that the free version a limit and offer them the chance to upgrade. Other than this, there is no other annoying popups offering the paid version. It's OK to have a button or whatever in the free app to let the user upgrade, just don't shove it their face or popup any sort of reminder after X uses or time. A free version of an app must fully function in its own right.
Here's my take on free/paid app pairs versus IAP:
Cons of IAP:
- No promo codes for IAP
- You can't make IAP free for some period of time (sale or whatever)
- Free apps tend to get lower ratings because any yahoo can download.
- Extra coding for IAP
Cons of free/paid pair:
- Two targets, two app releases, two sets of images, two sets of stuff in iTunes Connect
- Split downloads and ratings/reviews.
Personally, since I've been doing this for several years now, the extra effort of submitting two apps is trivial.
Edit:
One thing I forgot to mention - there is still no guarantee that Apple will accept the apps this way. But there are plenty of examples of such apps so it should be OK if done correctly.
If you want to have two apps, then you must have two technically independent submissions with different app id-s. It may be tricky to have it from the same project, not sure if you can do it using two targets. Technically AppStore rules do not allow "upselling" paid version from free one, but if it is not too aggressive, then maybe it will be approved. Safe solution would be to use InApp Purchase, this gives you many benefits:
quite is easy to implement
no need for two application codebases
you have single download count and item in appstore
Actually this solution with two separate apps made sense before in-app purchases, I do not see much point of that today.
Related
For marketing (as opposed to technical) reasons I'm about to submit a financial services iPad app that comes in two flavors, "regular" for individual users working on their own behalf, and "professional" for financial planners working on behalf of clients.
The "Pro" version functionality includes everything in the regular version and also provides the ability to save and switch between client datasets. Most of the code is identical, only a tiny sliver of code is added to the Pro version build (although more features may be added in the future that might widen the gap in functionality).
Here's the question: Is it better to maintain two separate apps in the store (with separate application IDs?), or as a single app with an InApp purchase to upgrade?
I'd rather avoid the infrastructure of InApp purchase, but I want to "color between the lines" of Apple policy and keep it reasonable for users and for future development.
Most "regular" users will never upgrade. But many (most?) "Pro" users will probably want to start out with the cheaper single user configuration before spending significantly more dollars on the "Pro" version. Advice on how to package?
It seems like the best bet is to create a second target, setup the project to archive both, and then load them as separate apps to the App store.
I base this mostly on reading between the lines in the various answers about provisioning (at least there seems to be some evidence others have taken this route). I'd still welcome comments or other input from those who have gone down this road (or taken the other one). Thanks.
This is a conceptual workflow problem. I'm converting an app with an existing user base from Paid to Free with an in-app purchase (FWIAP) to remove ads. The problem I'm trying to avoid is having the existing paid customers updating the app and now suddenly seeing ads and being insulted/assaulted with the "option" to pay again to remove the ads they never bought in the first place.
Luckily, I do have some breadcrumbs in the form of persistent data (pData) that will indicate whether the app was already installed. So my thought is to have the new version check for existing installs before deciding whether to proceed with displaying the ads.
One problem I foresee is later updates then considering all those first-generation users as now eligible for ads again, so I'd have to then add another persistent flag (pFlag) to identify the two groups of users and then hope to remember for even later updates (i.e. third-gen., etc.) to check against the pFlag instead of the pData, as the pData values would have long changed by then.
Does this seem like a sound approach or is there another good known solution to this?
The problem with breadcrumb schemes is with users who upgrade, or have to get a replacement device, and don't have backups to restore from. When they re-download your app, there will be no breadcrumb.
I don't think you'll ever be able to support cases where someone has bought the paid version and installs it directly from the app store on a new device or a device where the app has been deleted.
We recently had this problem in the opposite direction. We have a FWIAP app that customers wanted to be able to purchase through the volume purchase program, which doesn't apply to IAP. So we built a paid version and sell it as a separate app, and it generates as many sales as the FWIAP version, basically doubling revenues (so far).
I think the simplest approach is to just release a separate app. If you convert the existing app, the biggest risk is negative reviews, which could drive down your star ratings and thus downloads. So if you do take that route, I'd have as generous a customer support policy as possible--give anyone who claims to have purchased the paid version a code that lets them unlock the FWIAP version.
But that's likely to be a headache in the future, and from my limited experience, you may make more money by just having both versions in the store.
The paid to free-with-inapp-purchase workflow is supported; it’s referred to as paid-to-fremium and is discussed in the 2013 WWDC video:
Using Receipts to Protect Your Digital Sales https://developer.apple.com/videos/play/wwdc2013/308/
I have almost finished my iPhone app and would like to send it in for approval. However, I would like to make this available as a free app, as well as a paid app. In the free version, advertisements will show up, and in the paid version, advertisements will not show up.
My question is, to create a free app and a paid app, do I need to create two similar projects in Xcode, and for one, add the code for advertisements to appear?
You could use an in-app purchase to buy the full version and remove the ads. This way users won't have to download your app again.
See the in-app purchase programming guide for more info.
Yes. You need to have two seperate versions, one with space for ads, and one without. In many cases, the paid version will have extra features, in addition to the lack of ads. In your case, it doesn't sound like you have extra features, so the two versions should be very similar.
The easiest way will be to copy the target, get a second appID, probably with a "Free" or a "Pro" tacked on the end, then try to make one a very finely different, IE. including a header that defines a single value kFreeVersion, or something. then use that to define your logic.
so you don't end up having to maintain 2 branches.
Yes, you'll need to create two separate products. If you spend a little time looking around in the app store, you'll notice that many apps have free and paid versions; sometimes the free versions have the word "Free" in their title; sometimes the paid versions have "Pro" or something like that.
I have created an application and I have purchased an account in AppStore.
I wish to configure the app such that it will run for free twice and after that the user will have to purchase the full version. I want to implement the purchase of the full version inside the trial version (using in-app purchases).
Apple does not allow trial software in the App Store. You can have 'lite' versions of your applications, but Apple requires that they are fully functional applications that do not expire and are not simply advertisements for your for-pay app.
Once you figure out what type of features you want to offer in a 'lite' version, one thing you could do to offer an in-place upgrade for customers in to use the in-app purchase mechanism. Apple now allows free applications to sell in-app purchases. So you could have an app call 'Foo' and inside 'Foo' you could have a menu option to unlock additional features, which would bring them to the in-app purchases dialogs where they could pay you to unlock more content of the app.
Check out Apple's tips & tricks for App Store submission: http://developer.apple.com/iphone/news/appstoretips/
There (listed on Sept. 18th, 2009) you will find a tip titled Just Right "Lite" that reads:
Using a "Lite" version to show how it
feels to use what you make and what
kinds of things your app can do is
definitely a good way to find
customers who will pay for the full
version of your application. But store
shoppers tell us it only works if you
follow a few simple rules:
Make sure the functionality you decide to include is complete. Battles
that require weapons only available in
the full version, for instance, are
annoying and irritating instead of
enticing.
Don't set time limits on your "Lite" version, either for run times
or life times. Applications that will
only run for a set number of minutes
per session, or that expire altogether
after some period of time, don't
recruit customers so much as leave a
bad taste in their mouths.
Only display the UI for what your "Lite" version will do. Grayed out
menu commands, "more track/car
choices" you can see but not select,
etc. makes your "Lite" version feel
more like a commercial than a product,
and an annoying and ineffective one at
that.
Do include information about your full application, including an option
to buy, in either your application's
About section or on the splash screen.
Just make sure the option to continue
using the "Lite" version is there as
well. A good impression lasts forever.
It's important to follow these simple
rules not only to create a better user
experience, but also because your app
will be returned to you by the App
Review Team for modification if it is
found to have time limits, incomplete
functionality, or disabled
functionality.
The most relevent part of that text for yourself and your proposed App design is the last sentence that contains "... your app will be returned to you by the App Review Team for modification if it is found to have time limits..."
Here's a good walkthrough on adding in-app features to your app.
http://blog.mugunthkumar.com/coding/iphone-tutorial-%E2%80%93-in-app-purchases/
I have an app that I was going to release as a free (lite) version with some of the total functionality and a paid full version with advanced functionality. Now, with in app purchase for free apps I am thinking of going that route with the ability to unlock features as needed. I'm not talking about a trial version that expires.I want people to be able to try out the app and get an idea of the interface and functionality before deciding to purchase the full functionality of each major section of the app, basically.
Here's an analogy of what my app would be like. Let's say you have a cooking app that teaches you to cook in different styles. There could be major section for French, Italian, and Chinese. Each section could have some rudiments unlocked in the free app so users can see the UI and basics of the functionality. Then, the user could decide to purchase each major section (or not) individually with in app purchase or buy the full versioned app (with the free/paid model).
One concern I have with offering a free app with in app purchase would be with feedback. I would be very clear in my description in the app store that there is in app purchase for full features but I'm worried that less serious users could/would leave negative feedback. I suppose that's always a risk but curious about any experience with this.
It also seems that it could be a whole lot more complicated keeping track of what portions of the app are locked and unlocked with in app purchase. I know I'd have to have all the code for the full functionality and "lock" the portions that haven't been purchased. How do people usually lock portions of their code? I'm not talking about the process of purchasing (I've read the In App Purchase Programming Guide) but after the purchase has been made. Would I just keep track of what the user has purchased and put conditionals on the sections that are initially locked? Or is there another way to do this as well?
My instinct is for the in app purchase (particularly since users could purchase the major sections that they want individually).
I would highly recommend using the in-app purchasing over having different versions available.
If you have different versions, users need to re-download the whole thing if they want to upgrade. This means they need to have twice the storage space and use up twice the network bandwidth to upgrade.
I don't think your review concerns are founded. If your application is well made and users like it, you'll get positive reviews. To avoid having users be confused, make sure the application clearly states what can be purchased. Also, some people just dislike everything and will give you one star. These users are unavoidable, but if your app is good, there should be enough good reviews to balance them out.
You're correct in your assumption that you would have to have conditionals for locked/unlocked content. However, this shouldn't be an enormous issue. Just persist what the user's purchased in a plist (suggested by Apple) or other persistent storage and make a class that you can query to find out if a particular feature has been purchased.
I suppose it makes sense to have lite app (with unlockable content via IAP) and full paid app. I'm saying this basing on own experience of selling apps on the AppStore. If interested you may want to look at my post in our company blog about IAP vs paid app.
http://bees4honey.com/blog/marketing/in-app-purchase-vs-paid-app/
In two words - having lite version with IAP and paid version will increase a total revenue in comparison with having only lite with IAP or lite+paid.