Allow the user to buy a paid version of the application from the free version?

Question

You have a general question for you about the implementation of a free and paid version of the application. I have the setup now that I have 2 goals in 1 application / project, and I specify with the syntax def for what is in the paid version of lite. It works and launches both targets.

1) How can I buy a custom application directly from the free version? (Several old articles were found saying that the link is good, while others say that they will be rejected and should use the purchase in the application) Can I use the link attached 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 storekit to purchase an in-app?

2) I was going to put a new Tab Bar element at the bottom (for a link to the paid version) - I have not tried it yet, but I would have to set up the tab bar in one way for the free version and another way for the paid version, right? Essentially, hiding an element of the tab bar to buy the paid version after the upgrade.

3) Sending each version of the application (free and paid) to the application store - I assume that I can set a goal and archive the binary file for download for each, right? Two separate apps in itunesconnect?

Answer 1

I have several pairs of Lite / Paid applications in the application store (all of them were created earlier than IAP existed). I’ve made a lot of updates for these apps over the past years, so it seems like Apple is doing a great job with the whole idea if you do it right.

1) You cannot buy a paid application from the free application. The best you can do is send the user to the store for your paid application.

2) That should work. In one of my applications, I have an additional icon on the main toolbar that displays the user on the application store page for a paid application.

3) Yes, you are sending two completely different applications. You set up two apps in iTunes Connect each with its own unique app id.

One project with two goals is an easy and proper way to customize your code. For me, I make two archive builds, configure two applications or application updates in iTunes Connect, and send two applications / updates to iTunes Connect. I always keep both apps in perfect sync. Apple always seems to be looking at them together and always pushing them into the store at about the same time. Only once did two receive approval for more than an hour or two.

The main thing to be careful with is the free version. It can be "Free" or "Lite", but not "Demo". The free version should fully function. DO NOT DESTROY UI elements in the free version that are disabled because they only work in the paid version. He will be rejected. If it does not work in the free version, do not mention it in the free version at all.

Most of my application pairs, the free version, allows me to limit the data compared to the paid version. When a user tries to add data for this point, I exit the warning with a good reminder that the free version is a limit and allows them to upgrade. Other than that, there are no other annoying pop-ups offering a paid version. This is normal if you have a button or something else in the free application so that the user can update, just don’t click on your face or pop-up window of any reminder after using X or time. The free version of the application should fully function independently.

Here I take a couple of free / paid apps compared to IAP:

Against IAP: - There are no promotional codes for IAP - You cannot make IAP free for a certain period of time (sale or something else) - Free applications, as a rule, get lower ratings, because any yahoo can be downloaded. - Optional encoding for IAP

Against a free / paid pair: - Two goals, two application releases, two sets of images, two sets of materials in iTunes Connect - Split downloads and ratings / reviews.

Personally, since I’ve been doing this for several years, the extra effort of sending two applications is trivial.

Edit:

One thing I forgot to mention is that there is still no guarantee that Apple will accept the application this way. But there are many examples of such applications, so it should be good if everything is done correctly.

Answer 2

If you want to have two applications, then you must have two technically independent representations with different application identifiers. It can be difficult to do this from the same project, not sure if you can do it using two goals. Technically, the rules of the AppStore do not allow the paid version to “bounce” from the free one, but if it is not too aggressive, then it will probably be approved. A safe solution would be to use InApp Purchase, this gives you many advantages:

• pretty easy to implement
• no need for two application codes
• you have one download counter and item in appstore

In fact, this solution with two separate applications made sense before shopping in the application, today I do not see much point.