Having Multiple Similar Apps

Has anyone got a solution?

I have the same problem. I have applications for different companies and have no way to put them in the same applications because they use icons, colors, webservices and different configurations.

Same reply from the AppStore guys, which in our case is somehow impossible as we develop personalized radio station apps.

A single container app in our case, as well as others, is simply unmeaningful.

There must be a way to differentiate applications which are similar in concept (radios and others) but different in presentation.

I mean, a radio app MUST have a volume, icons to change station (if more than one), buttons to chat, messaging and so on.

We are experiencing the same as the rest of you, with another hiccup. Since all 14 of our apps (differentiated by state/province) are paid apps, consolidating 13 of them into the one with the most current users will lead to those users losing the money they spent on the original app. If the container app remains a paid app, then there is no way to transfer the othher 13 to that paid app withhout them buying it again. If the we change the container app to be free app with an in-app for each set of content, then we are forced to create this container app as a completely new app - losing 5 years worth of positive ratings and reputation (4.6 star rating over 5 years). Plus, a free app that immediately asks for $6 in-app purchase will get WAY more negative reviews than a $6 paid app.

It is amazing to me that Apple is not providing any means to help support a transition such as this. Provide promo codes for the 25000 paid users that are about to lose access to their app, or provide a means to transfer purchases from one app to another. Without one of those two options, customers are going to get a very raw deal.

Anyone get around the above issues or have a plan to do so?

For transferring in-app purchases, we will probably settle on using the Ubiquitous Key Value Store (https://developer.apple.com/library/content/documentation/General/Conceptual/iCloudDesignGuide/Chapters/iCloudFundametals.html#//apple_ref/doc/uid/TP40012094-CH6-SW26 ) to store some info about what in-apps had been purchased in the other apps, so that we can at least apply those to users that do re-purchase the new app. Unfortunately, as per above, that does not help with transferring purchases, but might help someone with a solution for transferring in-apps.

You will need to issue a revision to your current apps that allows them to communicate with your 'new' container app. I suspect that if you indicate to App Review that the update is meant to accomplish this communication link then they will let you do that.

The revised app can use one of these methods to communicate to the container app that it exists and that it does or does not contain various IAPs:

1) shared space on the user's iCloud Account

2) shared space on the device's keychain

3) look into "canOpenURL" and create a special scheme that does nothing - here one app (the new container app) asks the device if there is an app on the device that can open a new scheme that might be called "dummySchemeForApp3". The new revision for, for example, App 3 tells the device that it is prepared to handle a URL with the scheme "dummySchemeForApp3". It isn't actually prepared to handle such a scheme but it says it is in the plist. The container app will do a canOpenURL, discover that its companion 'app 3' must exist on the device and upgrade accordingly.

Also:

>a free app that immediately asks for $6 in-app purchase will get WAY more negative reviews than a $6 paid app.

It won't if it does something a little interesting and leads the user to purchase the IAPs. It also will get downloaded by many more users; albeit, most of them 12 year olds.

Thanks for the list of alternate approaches. Those can all work for in-app purchase communication. They can also potentially work if you want to create a new and free container app, and use IAP to purchase the content.

However, I have no desire at all to have a free app, that just frustrates users when they open it and realise that they can't do much without paying inside the app. We are still evaluating our options and considerin both approaches.

So far, the leading approach will be to enable app to app comunication via the iCloud key/value store to allow for enabling in-app features. Then, re-publish our most used app as the container app, still at a full $6 purchase price. Within the other apps, notify users that we are moving to the new container app and collect their emails for us to notify them when the new app is available. When we email the users, drop the price to $.99 for a set period of time to make the pill easier to swallow. We will miss some users, and they will be mad. Users will be mad no matter which approach we take to be honest.

Thanks for the reply, looks like many people are in the same boat, with very few paddles or life jackets.

>However, I have no desire at all to have a free app, that just frustrates users when they open it and realise that they can't do much without paying inside the app.

Why would they get frustrated if they get a free app and it does just a little, promising to do more if they buy the IAP? Especially if your description of the app includes this fact. And this gives you a chance to 'market' to the users who might be interested but $6 is a lot for an app.

Why do users get frustrated with this? Because of psychology I guess. It happens all the time. People don't read product descriptions at all, and get the hopes up with a free app, and then are disappointed. I prefer paid apps because the "pain" of purchase is upfront and forgettable.

Regardess, we will be going that route (free with 14 in-app purchases, trials for each one). By using iCloud ubiquitous key/value store we can get information on which inapps and standalone apps the user had installed. For the the one app that we are converting to the container app, there is the chance that due to a re-download or auto-update, we won't get the iCloud properties to tell us that they had purchased that app prior to us switching to free. For that case, we will use receipt validation to check what version of the app was originally purchased, and what date the original purchased happened. This way, we can activate that in-app "product" as well. I think with the combination of iCloud shared prefs and the receipt validation, we should be able to transition users over "seemlessly". Users might still be a bit upset, but hopefully keep their pitchforks at home.

Thanks PBK for the feedback. If anyone needs any assistance with adopting the processes outlined above, let me know.

Is there any real resolution regarding this design 4.3 rejection?

Our account belongs to a parent company which owns many subsidiary companies. Each has its own mobile app and shares some general app architecture and functions and of course provides certain company-specific functions. This app rejection design 4.3 seriously affects all our mobile app submission. We can no longer arrange app submission for new app or app upgrade. This really impacts our business. Seems this rule is tightened starting from end of June 2017 but poorly explained to public and affects many parent companies' strategies and app management. Any idea?

Hope Apple can seriously review this design 4.3 rule which should stop real spam app but allows white label apps for different entities under parent company or any similar scenario like "University" app. It does not make sense to offer a single container "unversity" app for "*** University aliance" which actually offers services for many individual universities under the same aliance. Where is the uniqueness and differentiation? Apple, please give us a good answer.

No resolution that I have heard of. Apple approved our last round of updates and gave us a 2 month grace period to transition the 14 apps to a single app. I tried filing an appear, but they never even responded to it, as the app updates had been approved, so the appeal process doesn't even get entered.

From the person I talked to, they made it very clear that although you can appeal, the appeal with not amount to a change in direction. They are enforcing the policy, and are not making exceptions.

I have a question about the technology used. My applications are hybrids, I'm not sure if this problem could have been caused by this or if it has nothing to do. Has anyone had this same problem with native app?

We're having the same problem and it's a real blocker. The impact seems big on a lot of companies.

Do you think that adding extra features (new sections, new forms...) per app would work?

Or creating a new developer account per client?

@AndreVicente Our apps are native.

Thanks for the answer.

I have already tested to publish the app in the account of the client and the result was the same, they still said that if it continued to send apps with the same problem would be blocked

So I have additional information : I talked with the Review Team, they confirmed that we cannot upload similar apps with different branding anymore.i

The only way is to add specific and independant features for each app to make it unique. Hope this helps.

I specifically asked "what number of unique features must we add to each app to make it unique enough to prevernt rejection under this clause?". They told me that it would have to be substnatially different, and a single feature here or there would nto make a difference. And yes, we are also building native apps, so its not a questions of native or non-native.

All the negativity around this had us pretty down, but I have spent a solid week on this, and getting to a place where I am still ****** about the change, but accepting it. Only because I am making progress on the development and have solved all the major hurdles (remote resource loading, region specific settings, etc). It is a huge undertaking, so try to get some grace period from your reviewer. We got 2 months, which is not ideal, but a lot better than not being able to do intermediate releases.

It's a shame what they're doing. They are putting an end to my business ...