Many companies rely on white labeled apps to provide their services in a more personal way to their customers.
With a few adjustments we can set a logo and a splash screen and even pre-configure our app to our customer needs which has a great impact in their end user experience. Without this my users would need to use the app skipping a lot of configuration steps that in a generic app wouldn't be possible to skip.
According to apple: "Apps created from a commercialized template or app generation service will be rejected"
Now what can we do to to work around this?
Today I saw 4 apps being rejected and others are waiting for revision and I can anticipate that they will have the same ending.
Here's the revision result:
"4. 3 Design: Spam"
Guideline 4.3 - Design
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, which is considered a form of spam.
The next submission of this app may require a longer review time.
Next Steps
When creating multiple apps where content is the only varying element,
you should offer a single app to deliver differing content to
customers. Alternatively, you may consider creating a web app, which
looks and behaves similar to a native app when the customer adds it to
their Home screen. Refer to the Configuring Web Applications section
of the Safari Web Content Guide for more information.
Review the Design section of the App Store Review Guidelines.
Ensure your app is compliant with all sections of the App Store Review Guidelines and the Terms & Conditions of the Apple Developer
Program.
Once your app is fully compliant, resubmit your app for review.
Submitting apps designed to mislead or harm customers or evade the
review process may result in the termination of your Apple Developer
Program account. Review the Terms & Conditions of the Apple Developer
Program to learn more about our policies regarding termination.
If you believe your app is compliant with the App Store Review
Guidelines, you may submit an appeal. Alternatively, you may provide
additional details about your app by replying directly to this
message.
For app design information, check out the following videos: "Best
Practices for Great iOS UI Design" and "Designing Intuitive User
Experiences," available on the Apple Developer website.
You may also want to review the iOS Human Interface Guidelines for
more information on how to create a great user experience in your app.
Of course we can develop web apps, but apple can't forget that many features are only available in native or hybrid apps.
What should we do?
References:
https://blog.summitsync.com/did-apple-just-crush-white-label-apps-4aee14d00b78
https://developer.apple.com/app-store/review/guidelines/
The current answer is out of date. Apple revised their guidelines in which the customer must have their own Apple account now, paying the $99 a year. You can then submit a white labeled app under that account. We have been doing that the past three months with no problem. They wouldnt allow this approach before but now they do.
The Apple developer account can not be an individual account, but a company, educational or government type.
If you have a few apps under the same company account you can submit the apps if they can be proven to belong to the current company. We have three apps submitted under the same company account because the apps shared similar names to the company however I wouldn't do this for different companies.
We where having the same issue. We have talked to Apple, which where very kind and understanding.
Our app is one used mainly bij employees of a company and there for Apple suggested to use B2B app distribution via Volume Purchase Program.
If your app is just white labeled app that business can use for their customers then you are out of luck. Apple will not allow any white label apps in the app store any more.
Your option is to make one app which can switch between the different customers.
If you app is like web store this can be difficult, but as per Apple's example of the fan app of a football club switch per club should be in one app.
4.3 is a complete mess. With its active enforcement, Apple has indeed opened a Pandora's box. The biggest problem is that this policy is applied randomly.
My experience suggests that there are very few App Store reviewers who are paying attention to it during the review process. However, if you stumble upon such a reviewer, they will put some flag on your file, and all other reviewers will start to evaluate your apps for spam going forward. It seems like nothing is wrong with this approach, but it can lead to a distorted market.
In our case, we are waiting for years now to see Apple apply the same rules to our competition as it did to us. And the most ironic part is that throughout these years we've been ringing all the possible bells. Emails to Apple representatives, release notes, responses in resolution centre – nothing works.
For more details about our story check my Medium post. I have also written a second part which contains the timeline of my discussions with Apple representatives in which I highlighted competitors who violate 4.3, and Apple did nothing :(
So, the first problem with 4.3 is that it distorts the competition given how selective Apple is at implementing it.
The second problem is that the policy itself is too vague. Take our company, Theory Test Revolution, as an example. We build apps which help people pass their UK Driving Test.
Although we focus on theory tests, the reality is that our apps could be used as a platform to prepare for any multiple-choice test. Imagine if we wanted to release a couple of other MCQs apps. For example, to prepare for PADI diving exam and also to prepare for some pilot's licence exam.
How would 4.3 apply in this case? Would Apple demand that we bundle all of them in one app? How would we call it? :) "Any test you can imagine"? :)
There must be some limits. There are cases when marketing needs justify releasing separate apps even if their foundation is the same, as doing otherwise would simply confuse the users. Unfortunately, Apple doesn't care about fair competition enough. I guess their goal is to reduce the number of apps using this policy, with little regard to how fair this process is.
We are waiting for almost three years now to see our competitors being treated in the same way. And who knows – how much longer do we need to wait?
Had a call with Apple on July 13, 2020, 5 PM (GMT)
I had a conversation with the app review team regarding this matter today and I have concluded the following.
You can have the same codebase, same color, and same design for multiple apps but, a big BUT, is that you need to have some unique functionality in the app which provides a different experience to users.
They clearly said it's a difficult thing to do for developers and should take a longer time.
Only a way to know if some unique feature will work out is to send it for a review. It doesn't matter how long you have spent on developing that new feature. They also said they cannot help and is not permitted to insight anything beforehand.
They cleared that this is not a technical or logical issue to be resolved. For example, they are not going to check if the app icon or color is going to match with other app and decide it a spam or not spam but they care how users will be experiencing this app with the "WOW" factor or the app usefulness.
In short, the app must give another perspective to the user and the app should insist the user to use it because it has something new to give.
According to section 4.2.6 of: https://developer.apple.com/app-store/review/guidelines/#design
Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences. Another acceptable option for template providers is to create a single binary to host all client content in an aggregated or “picker” model, for example as a restaurant finder app with separate customized entries or pages for each client restaurant, or as an event app with separate entries for each client event.
So, rejoice! your apps can in fact be white labeled! they just must be:
submitted directly by the provider of the app’s content
There is nothing you can do to make Apple approve a copy of your app with only images and labels changed, it was their politics since iOS 3.
The only sure way you can do it is by creating a new developer account for the company you are selling the personalized version.
And B2B is also a viable option that also saves your client the 99$ yearly Apple bill.
Related
I am building out a iOS & Android app. My app may not fully scale to support users and have some limited functionality out the gates. I wanted to put an invite list on the front of registration like Mailbox did a few years ago.
I was trying to read the Apple app store guidelines to creating a "waiting list / invite list" and couldn't get a clear picture. I assume Android is more flexible on this, so I figured I could start with Apple's guidelines first.
Here is what I can find.
In Apple's docs, it says under 3.2.2 "UnAcceptable"
(v) Arbitrarily restricting who may use the app, such as by location or carrier.
In this specific case, I am not blocking by location or carrier. I am just putting up a wall to use the app since some of my users can use it in a limited form, but I can't open it up to everyone on Day 1.
I understand I can run a "testflight" release, but I wanted to make our app available in the App Store for anyone to download since it will be publicly available, just not fully ready for a million people to hit it. My understanding is that the testflight release requires a bit more work based on their docs and isn't as simple as just putting it in the public app store so anyone can get to it.
Apple has the ultimate authority for approving and rejecting apps in their app store so nothing on SO can really be perfect advice. If you are really concerned about approval, you can try to contact apple developers support. Here are a few things I would advise:
Make sure in the developer notes for Apple when you submit to them you include a free account.
In the notes for the app store let the users know that it may take up to __ hours for their registration to get activated.
My understanding is you are doing this to handle the volume of users as you are launching the app. Be advised though that if you start restricting users too much you will possibly get poor reviews. Only restrict usage if absolutely required. If you run into issues make sure you are communicating with the users so they understand.
Good luck with you new app!
I'm trying to develop an app that can be used to generate multiple apps. Let's say for now I'm doing an app for fruits, but tomorrow the client will want to create an app for vegetables, and the day after tomorrow for meats, and so on.
So what I'm doing right now is creating an app with same codebase and generating different Targets for each topic (fruits, vegetables, etc.) with its own settings.
That is working really good for now, but I want to make sure that my apps all passes the AppStore review guidelines. The one that concerns me is this one:
4.3 Spam
Don’t create multiple Bundle IDs of the same app. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and provide the variations using in-app purchase. Also avoid piling on to a category that is already saturated; the App Store has enough fart, burp, flashlight, and Kama Sutra apps already. Spamming the store may lead to your removal from the Developer Program.
So I've read some posts that talks about the best way to accomplish doing multiple apps with same codebase, but hadn't seen anyone lately talking about the Apple restriction to this stuff.
If using different targets it's not a solution for Apple to approve, and you know one, I'll be glad to hear it! What I wanna avoid is making one app and make the user select the type of food he wants (following my example scenario). So my goal is having multiple apps for all different topics, and make Apple approve it.
Thanks in advance!
This is great question. I hope someone from apple team can answer this correctly.
My personal experience
Creation of separate app is perfectly fine as long as end app provides something unique compare to other bundleId. In my case We have 100+laws apps having each law app created using same code base but different data and from User perspective they need it in separate app compared to grouped app.
The visual schema should be different in each application. Please try to make different colors, logos, URL's / data for each flavor.
Each app name-should be unique ( Apple doesn't allow you sell app with same name). Adding hypen, or cosmetic name changes will be definitely candidate for app rejection.
Having said that there is no gurantee to get your app approved each time. In appeal also if you try to tell them that similar app is approved, you are at their mercy to get it approved.
I know, that this question is not directly related to any coding but there are several other question on SO about the App Store and its Guidelines. So I assume, this question is OK.
There are other questions about (more or less) the same issue. However they where asked / answered several years ago and the Guidelines have been updated since then. Additionally the circumstances are always a little bit different.
I am well aware, that nobody can give me any kind of guarantee on which interpretation of the Guidelines is correct. Not even Apple could do this, since everything depends on the review staff an its current mood. However It would help a lot get to know your opinion on what is allowed and what is not. Maybe you already encountered the same problem and have some useful recommendations.
The set of facts:
A Shopping List app is offered in iOS App Store. The app offers functions to create and manage any kind of shopping list. These functions do NOT depend on any external purchase. The fee version limits the number of lists. This limit can be unlocked using an In App Purchase.
There is also a WebApp version that offers the same functions (and a little more) as the iOS version. The WebApp has a one month free trial and can then be extended using a subscription model. Subscriptions can only be ordered within the WepApp, not from within the iOS app.
Both version can be used completely independent from each other.
Additionally the apps can be connected (REST API) to sync lists between them.
Obviously there are pages/controls within the iOS App, that allows to setup the connection (enter username, password, etc.).
Obviously the WebApp has to be described in some way to the user within the iOS App.
Once the free trial ended or a subscription has expired, the sync will no longer work. In this case the user needs some kind of hint why sync is no longer available ==> There has to be information about the subscription model of the WebApp and a discription on how to renew the subscription.
The "Problem":
The current App Store Guidelines are pretty vague on wether this kind of business model is allowed or not:
3.1.1 In-App Purchase: If you want to unlock features or functionality within your app, (by way of example: subscriptions,
in-game currencies, game levels, access to premium content, or
unlocking a full version), you must use in-app purchase. Apps may not
include buttons, external links, or other calls to action that direct
customers to purchasing mechanisms other than IAP.
This paragraph is not as clear as it my appear on first sight. Unlocking functionality within your app is only allowed by using IAP. Fine, so unlocking a app feature (e.g. creation of more than 2 shopping lists) would be not allowed. But is the sync functionality I described before also covered by this? Of course there has to be functionality within the app to connect to the WebApp, but the complete sync logic is implemented on the server, not in the iOS app.
The functionality the iOS app offers is "Establish a connection to the WebApp". This functionality works independently from wether the WebApp subscription is active or not. Only the functionality of the WebApp changes depending on the subscription status (accept or deny sync requests).
So: Is it allowed to add some text like "There is a WebApp, too. Use this link to got to the WebApp. Follow this link to renew your subscription" to the WebApp or not?
Or is the part "Follow this link to renew your subscription" forbidden?
What makes the whole thing even more confusing is the following paragraph form the Guidelines:
3.1.5 Physical Goods and Services Outside of the App: If your app enables people to purchase goods or services that will be consumed
outside of the app, you must use purchase methods other than IAP to
collect those payments, such as Apple Pay or traditional credit card
entry. Apps may facilitate transmission of approved virtual currencies
(e.g. Bitcoin, DogeCoin) provided that they do so in compliance with
all state and federal laws for the territories in which the app
functions.
Does this read as "Physical Goods and physical Services" (e.g. postal delivery in contrast to digital Services) or this include all Services?
So, is the "WebApp Sync Service" covered by this paragraph and thus the usage of external payments not only allowed but necessary?
Of course I could ask these question directly to Apple. But I would never get an answer. Even if I would, this would still be no guarantee, that the review stuff shares the same interpretation of the rules. So your experience and opinion will be the best "guarantee" I will ever get.
Thank you very much!
I am working on a mobile iOS app that is customized to each client, with their own app icon, startup screen, and a few other changes. Each is then submitted to the app store as an individual app.
This is working just fine so far, but what will happen if there's 1000 clients instead of around a dozen? Does Apple have any rules on quantity, submission rate or uniqueness? Any reviewer would clearly see that the apps are basically the same outside of the branding.
Don't do it. You will get kicked out of the appstore.
Read 2.20 of Apple iOS Guidelines which says that developers that spam appstore with similar apps will be kicked out completely!
Notably developers like AppGratis got kicked for this and many others reasons.
Sorry can't disclose, if you have a developers account though you can check the requirements
from https://developer.apple.com/appstore/resources/approval/guidelines.html
I know this is an old thread but somehow it popped up and the answer selected is not entirely correct. The requester needs the custom B2B program here:
https://developer.apple.com/programs/volume/b2b/
That is specifically made for the purpose she/he asked about: to distribute customized apps to a business without cluttering the app store. There is no cost but your customers will need to join the Apple Volume Purchase Program for Business though that doesn't cost them anything.
The reason I say the accepted answer is partially correct is because obviously one should not spam up the app store with similar apps intended for one business, which is entirely correct. But that does not answer the underlying why they wanted to do this and how they could achieve the result they need which is to use the B2B program.
for a client, I have been developing an app which has been tailored to make their employees every day lives easier. Think of it as a calendar designed to fit the needs of their special business.
Now it turns out that other companies in the business are interested in the very same solution too. My client suggested we could sell the app on the appstore.
Since the app is equally useful for companies with hundreds of employees as it is for a team of five, I wonder what would be the best way to sell it.
It is my understanding that a company, once they purchased one copy of the app, may install it on as many devices as they want, as long as they use the devices with the same iTunes account. This is especially true if the company would equip their employees with new devices for the purpose, like my client did. Right?
This is obviously not what I want, I'd rather like to charge a small price per device. Usually, this would cry for a volume license, which is not part of the appstore concept, except for educational institutions.
Now I am looking for a convenient way to achieve something with the same effect.
I was thinking about checking the UDID of the device against a whitelist on my server to allow each purchased license to run on just one device, while allowing migration of course.
To enable a company to purchase a "volume license", I would offer packs of additional licenses via In-App-Purchases, as well as individual licenses. The app itself would be free while featuring only demo capabilities, full functionality would be available after assigning the device to one of the purchased licenses. Means to manage licenses would be included within the app.
What do you guys think? Any technical reasons why this concept could fail?
Do you know of examples that actually implement something similar?
Any other ideas how to sell apps in volume? Maybe there are even some examples on how to implement something like this?
Do you think apple would approve this kind of use of in-app-purchases? (I know this last question is not of a kind that can be answered here without uncertainty, but let me hear what your gut feeling tells you..)
This question has been flagged as being off-topic twice, so I think I should back up the fact that I am mainly interested in a technical solution (and emphasized the important sub-questions accordingly). Of course I am interested in whether apple allows the proposed use of their appstore, however before I contemplate that further I need to know if there are technical caveats to my approach. I would love to offer code snippets to support the technical nature of my inquiry, however I'm just planning things so there is no code yet...
While the core question is still business-related here, and thus off topic, I'll bite.
The standard App Store end user license agreement has this wording:
a. Scope of License: This license
granted to You for the Licensed
Application by Application Provider is
limited to a non-transferable license
to use the Licensed Application on any
iPhone or iPod touch that You own or
control and as permitted by the Usage
Rules set forth in Section 9.b. of the
App Store Terms and Conditions (the
“Usage Rules”). This license does not
allow You to use the Licensed
Application on any iPod touch or
iPhone that You do not own or control,
and You may not distribute or make the
Licensed Application available over a
network where it could be used by
multiple devices at the same time. You
may not rent, lease, lend, sell,
redistribute or sublicense the
Licensed Application.
Therefore, if you consult the "App Store Product Usage Rules" section of the iTunes Store Terms and Conditions, you see this wording:
(i) You may download and sync an App
Store Product for personal,
noncommercial use on any iOS Device
you own or control.
(ii) If you are a commercial
enterprise or educational institution,
you may download and sync an App Store
Product for use by either (a) a single
individual on one or more iOS Devices
you own or control or (b) multiple
individuals, on a single shared iOS
Device you own or control. For
example, a single employee may use the
Product on both the employee's iPhone
and iPad, or multiple students may
serially use the Product on a single
iPad located at a resource center or
library.
(iii) You shall be able to store App
Store Products from up to five
different Accounts at a time on
compatible iOS Devices.
(iv) You shall be able to manually
sync App Store Products from at least
one iTunes-authorized device to iOS
Devices that have manual sync mode,
provided that the App Store Product is
associated with an Account on the
primary iTunes-authorized device,
where the primary iTunes-authorized
device is the one that was first
synced with the iOS Device or the one
that you subsequently designate as
primary using the iTunes application.
The rules are quite explicit about commercial enterprises not being allowed to just purchase one copy and install it on all devices at that company.
It is for this reason that Apple offers volume discounts for applications purchased in bulk (where the developer has checked the box in iTunes Connect allowing for this). I can't find the business equivalent, but here's Apple's page on the educational bulk discount program.
While I could see how you could use in-app purchase to activate functionality in an application and make sure that it was properly licensed, I've heard complaints about the practical difficulties of deploying applications using this in educational and business settings. Many applications use this approach for free Lite versions that upsell into the full paid application, so Apple has no problem with this.
One thing I do recommend is that you not abuse the ad hoc distribution system to do any licensing workarounds. The last time some geniuses did this caused Apple to clamp down on everyone's ad hoc licenses and make our lives more difficult.
The correct answer here is for the companies you sell to to purchase an Enterprise program from Apple, then for you to license the application to them. You can use over-the-air distribution to get the application onto their devices, and charge them a per-user or per-device fee.
Let anyone download the app for free in the app store, but charge for licenses/subscriptions outside of the app store. You can then require them to register each device they want to use and you charge accordingly.
Can I bypass Apple's in app purchase mechanism by outside billing?
Thq question was asked long before, but still I feel that the answer might help someone having the issue. All you need is Apple's Volume Purchase Program. It provides the option for custom B2B apps developed by third-party developers, that too can be seen and downloaded only by the authorized client. Cool, isnt it? :-)
For clarifications, see the FAQ
The client can do a bulk purchase, on which they will receive a bunch of URLs. By opening the URL in iOS device is enough to install the app. Of course, you need a Apple Developer account for download and install, I think.