Concept: Trial & Full version in IOS today. (separate Apps, inapp purchases, Applestore rejection)

Concept on howto maintain a trial and purchasable full version of an IOS-app today:

There are lots of dicussions on this topic, but I would like to look at this for my case and how it would be designed TODAY (2015), with actual Apple restrictions.

I have an app which initially loads data from the internet to be displayed. (Trial-Content -> 80MB, 20%, Full-Content -> 400MB, 100%)
I would like to offer the Users to try the app with limited content first.
With limited content: 20% works as like the fullversion. 80% are marked with a question mark. If the users clicks on the question mark I would like to guide the user to the fullversion.
I prefere to have 2 apps (2 builts), because of having 2 separate rankings. Users, which buy an app are rating better, because they are really interrested in the app and will only buy, when they are pleased with the trial app. So an app with inapp purchase has a lower ranking in avarage then a isolated full version (built). But I guess this concept would be rejected by apple, because you have to mention the fullversion in the trialversion and you have to name the trial version as "trial" ? (Sorry for the bad english)

How will this be designed with IOS apps ? Howto guide the User to the fullversion, without beeing rejected by Apple ? (I read popups like "Would you like to purchase the fullversion?" will be rejected. )

In Android I did the following:

I created one app with the full functionality, which is at the same time the trial-version.
I created one purchasable app, which is only an unlocker app.
The trialversion app checks if the unlocker is installed. That way I can differentiate between trial and full and will load the corresponding content.
When clicking on the question mark, I will show a popup saying "Would you like to purchase the full version?".

Solution

This is quite a common pattern, you just can't call your "trial" version "trial". Quite often such versions are called "light".

To send the user to the app store to buy the full version you can use the SKStoreProductViewController to display the app store page for your full version directly in your app. This should be OK with Apple.

Your Android solution with the paid "unlocker" app would be possible too. Your apps need to expose an URL scheme and using that you can check if the other app is available. They also could use an app group to communicate. But this will most likely not pass review as apps must do something useful by themselves. They will probably test your unlocker on a device that doesn't have your other app installed and immediately reject it.

I would strongly suggest to reconsider an IAP for this. That's basically the ideal use case for it. You must not be afraid of bad reviews for offering purchases. Trying to send the user to buy another app will probably give as many bad reviews if not more. The IAP flow is much more user-friendly.