As for embedding other versions of your games, the license agreements cover that as well. Both Google and Apple are explicit that you are not supposed to do that, you are to put the other products on their store page and direct them to the appropriate segment of the store. Using your own product as a micro-distribution-center is prohibited by both of them.
I had to look through the iOS agreement, but I couldn't find any such point. I didn't read every line though, do you have more details, maybe a qoute?
We havn't had any problems (afaik) in getting it through review.
It's not a distribution center though, its just a single level or similar from an upcoming game, a playable demo, then you have to get the actual game the normal way.
No code is downloaded (that is prohibited) its distributed in a normal update.
You mean like these guidelines?
It is certainly a fine line. They do allow a limited amount of cross-branding and links to other products in the store.
We were told (at EA) that we could not include any type of playable demo for any other product, nor could we include a movie or any other cross-marketing except for single static screens in certain places which could link to cross-branded products.
Here are the ones on the list that immediately come to mind based on the descriptions so far in this conversation:
2.3 Apps that do not perform as advertised by the developer will be rejected [demos are 'not as advertised]
2.4 Apps that include undocumented or hidden features inconsistent with the description of the App will be rejected [demos are not part of the item description]
2.7 Apps that download code in any way or form will be rejected
2.8 Apps that install or launch other executable code will be rejected
2.9 Apps that are "demo", "trial", or "test" versions will be rejected. Beta Apps may only be submitted through TestFlight and must follow the TestFlight guidelines [You describe an app+demo combo package to get around this]
2.26 Apps may display and recommend apps other than your own only if the collection is designed for a specific approved need (e.g. health management, aviation, accessibility, etc.) or provides significant added value for a specific group of customers, or they will be rejected
3.3 Apps with names, descriptions, screenshots, or previews not relevant to the content and functionality of the App will be rejected
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.2 Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a "buy" button that goes to a web site to purchase a digital book, will be rejected
Is it possible you found a way around it and the reviewers find your usage acceptable? Perhaps. It is much more likely they didn't look very deeply at your product.