CODEWITHSUNDEEP
iphoneiosapp-storein-app-purchase
rossi
rossi

Reputation: 133

Allowing user to purchase Paid app version from within Free version?

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?

Upvotes: 4

Views: 1255

Answers (2)

rmaddy
rmaddy

Reputation: 318774

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.

Upvotes: 7

JaakL
JaakL

Reputation: 4295

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.

Upvotes: 0

Related Questions