I don't think Apple will approve an app that blocks a user or slows them down unless they install a 3rd party app. What usually happens is an advert pops up during normal app usage, the user has to exit or let the ad go away, then they can continue using. It's a normal advertisement. Its not unlike when the NYTimes does a full site takeover for some Buick commercial and you have to minimize the ad before you can continue reading. But going out and buying a Buick certainly doesn't decrease your access time to NYTimes articles.
I've seen many games that let you "earn" ingame currency by downloading apps or completing surveys. A few of these games _indirectly_ require you to download the incentivized apps by providing very few coins in the actual game, or making the ads the only way to get coins (other than with real money). Apparently that's sneaky enough for Apple.
For iOS apps there's something called "custom url schemes," which is basically a string that every app is self-assigned (if at all) that can be used to open up the app from within another app (or check the app's existence).
I'm not sure if this is how the specific ones being talked about might be working, but a simplified way of doing it would be that when APP A is installed it connects to a server and tells it that it has been installed with UNIQUE DEVICE ID, that way APP B can connect to the server and see if APP A has been installed on UNIQUE DEVICE ID. You can imagine ways to do the same with viewing ads etc.
This won't work - Apple no longer allows access to the unique device ID. You can generate your own random ID and register it with a server, of course, but this ID will not persist between apps.
More commonly this is done by IP tracking.
- Device taps on button/ad in app A to download app B.
- URL is specially encoded to identify app A.
- Server registers some unique information about the device.
- Server redirects to app B's app store page.
- User downloads app B.
- User launches app B, which reports back to Server. Server recognizes device and is able to associate this install event with the original tap from app A. App A's servers are contacted to this effect.
The trick here is that the uniqueness of the device here is pretty limited and temporary. If the user downloads app B, then does not launch it, their IP address will soon change (cellular networks and the such). It's not a foolproof system.
