Having Multiple Similar Apps

If I had to guess as to why other developers are allowed to do this, based solely on what you posted, I would offer 2 possibilities: the other developers lead more wholesome lives or, more likely, the other developers use different icons for their similar apps.

I'm hoping it's the icons too. But they are not aksing me to change the icons, they say I have to combine the apps. Maybe I can try to appeal. Also the threat is not to have the apps removed, it's to have my whole developer account removed.

"Specifically....." usually points to a key issue. "Please...", in English, means 'optional'; albeit in Japanese it means 'required'. I'd go with the icon and add in the app review notes something like "this app is very similar to *** but because it has different content it appeals to a different set of users who do keyword searching using very different key words".

I submitted an appeal proposing to change the icons with examples. Waiting to hear back.

That would certainly be the correct approach if app review was engaged in your problem. But if they were in their more comfortable position of reacting to your lead you would be better positioned by just resubmitting, as you propose, with a note stating what you did to address their earlier concerns.

I changed the icons and the apps are now approved.

@tomkincaid, I just received a similar note from Apple for many of our apps, although they were not in review. They just wrote me out of the blue to say I must create one "container" app within 30 days or they will remove all my apps from sale.

We are writing to let you know about new information regarding your app currently live on the App Store.

Upon re-evaluation, we found that your app is not in compliance with the App Store Review Guidelines. Specifically, we found:

Design - 4.3

Your app provides the same feature set as other apps you've submitted to the App Store; it simply varies in content or language.

Next Steps

To resolve this issue, please combine apps with a common features set into a single "container" app that uses the in-app purchase API to deliver different content.

To ensure there is no interruption of the availability of your app on the App Store, please submit an update within 30 days of the date of this message. If we do not receive an update

within 30 days, your app may be removed from sale.What's ironic is that their request is contradictory. Their suggested approach will necessarily result in removal (whether by me or them) of the app (each of them), since I can't convert them into a single app.

In our case, all our icons are already different. They have the style of our brand, but there is a unique image on each app icon.

Is there any additional detail you can provide about your experience? Did you get any pushback on your appeal, or did they just drop the whole "container" app idea?

>combine apps with a common features set into a single "container" app that uses the in-app purchase API to deliver different content.

What's to prohibit you from delivering a single mega app, with all those others mergerd into a bundle, and selling it for one price, vs. IAP pick/choose?

Your note may be 'similar' but it is, in fact, quite different. The OP's note from App Review - as I indicated in my response above - has a 'specific' requirement relating to the icons and a 'please' request relating to other matters. Your note has a 'specific' requirement relating to 'same feature set ... only varies in content or language." Your 'please' request is contained in their suggestion as to how you might resolve their 'specific' requirement; in that sense it is clearly a 'Japanese style' please. (Boy my note above was precient if I must say so myself because the OP failed to mark it as correct.)

You can delete all but one of your apps and that will resolve the problem. Alternatively you can follow what they are suggesting - combine the apps into one app that offers each set of 'content or language' differentiation through multiple IAPs. If you want to convert your current users you can:

1) create a single app that combines the features through the purchase of an IAP

2) create updates for each of your current apps telling the user that they should switch to the single app

3) in each update you need to:

a) tell App Review that you are doing the update to convert current users and tell App REview about b, c and d

b) remove the update from sale within a month or two of its launch

c) add to each update some mechanism to communicate 'purchased' to the single app - you could use shared space in the user's iCloud key-value file or the keychain or various other techniques

d) in the single app search for the 'communication' from the update apps and if appropriate grant the user certain IAP rights.

Good luck!

I'm sorry about what happened in your case, but it's good to see Apple is starting to clean up some existing problems on the App Store.

Guideline 4.3 - Design

We noticed that your app provides the same feature set as other apps you've submitted to the App Store; it simply varies in content or language.

Next Steps

To resolve this issue, please combine apps with similar feature sets into a single "container" app. You may want to consider using the in-app purchase API to deliver the different content to your users.

Best regards,

App Store Review

hi my apps rejected this issue are you help me

Hello,

I have around 400 Apps (since 2012) that based on white label code and recently I start publish new feature for the first 10 apps with version 3.4.0. Resolution Center got rejected all my apps with next note:

From Apple

4. 3 Design: Spam

4.3 - Consolidate

We noticed that your app provides the same feature set as many of the other apps you've submitted to the App Store; it simply varies in content or language.

Apps that simply duplicate content or functionality create clutter, diminish the overall experience for the end user, and reduce the ability of developers to market their apps.

Next Steps

To resolve this issue, please combine apps with similar feature sets into a single "container" app (using the in-app purchase API to deliver different content if appropriate).

We encourage you to review your app concept and incorporate different content and features that are in compliance with the App Store Review Guidelines.

Best regards,

App Store Review

I submit appeal to the App Review Board and after open case number I reply back with next notes:

Per case # 1164552840 - Not a Spam and cannot be Consolidated. App is branded for specific dealership and cannot be combine into a single "container" app

1. App is Branded for a specific Dealership (Bundle ID is specific to dealership) and use branded dealership assets and cannot be consolidated

2. App is completely stand alone and serve only one dealership with specific car inventory, servicing appointments, loyalty rewards, special offers within dealership

3. App has unique keywords that targeted only to one dealership

4. App have setup with Keywords that have great care to set these keywords up in such a way as to prevent multiple Apps been return on a single search within iTunes, which preventing spamming of the search results

Resolution Team still rejected our apps.

Any help?

Did this get resolved? If you have any suggestions please share. I am having a similar issue with the same business model and am currently being rejected.

We have a similar case, we have different events app. Each one with a client brand and event name (image, icon, etc). And we can't submit any new app without Apple rejection.

And we see our competitors doing the same, but with a different treatment by App Review Board, they accept their submissions.

It's frustrating and unfair...

Hello, we've got same troubles of yours: different customers (beauty saloon) for different app ids.

I did follow this way because each saloon has got it's own template (colors, button, fonts) sharing some common features like booking or promo. I can't create a container app, since I need different store icons for each saloon (content is also totally different).

Anyone has got some news? Anyway we used to release apps like that since 2 years ago and we never had troubles .

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?