My company is working on a dynamic mobile app that updates the look and appearance based on webcalls and we would like to be able to test that it would be able to get into the store okay. For the time being we have used the code to create an interal company app where the initial screen is a logon screen where the users log in with their company usernames and passwords. There are only about 20 people in the company that will be using this app for the beta release and the app logon is only available to members of the company.
We want to have this test release to first ensure that the app gets into the appstore and secondly to get a feel for the app review process. Would this type of app be allowed into the store? Or due to its limited user group, would they reject it? Also would apple need to be given a test username/pass to login to the company website itself to check how the app runs?
Any information regarding this issue would be very helpful!!
From the App Store Review Guidelines (developer account required):
If your App looks like it was cobbled together in a few days, or
you're trying to get your first practice App into the store to impress
your friends, please brace yourself for rejection. We have lots of
serious developers who don't want their quality Apps to be surrounded
by amateur hour.
and
2.9 Apps that are "beta", "demo", "trial", or "test" versions will be rejected
Finally, yes, you are required to provide a "demo account" if a login is required to use the entirety of your application.
Regarding your small user base, your application may not be accepted if it will only be used by 20 or so people (as stated in the comments). The iOS Enterprise Program is intended for in-house distribution (a small and limited user base).
2.22 Apps that arbitrarily restrict which users may use the app ... may be rejected
I have worked for a company that did release apps that were secured by a login screen. All you need to do to get it into the app store is provide Apple with a proper login so that they may test the functionality of the app themselves. When updating the metadata for your app in iTunes Connect, there is a section for testing notes, simply put your test username/password in there for apple to use.
One way they can reject an app is guideline 2.12: "We found that the features and/or content of your app were not useful or entertaining enough, or your app did not appeal to a broad enough audience, to be in compliance with the App Store Review Guidelines." If you're concerned about whether or not your app can get to the store, then there is no real problem in just submitting it. Just don't call it a beta test version because they will reject it. If you want, you can always change the release date of the app to a future date once it passes, and then the app will still not be available to all until that future date is reached. And yes you should provide them with a user name
Related
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.
I would like to create an iOS App for a limited set of people.
It should be possible to download the app for free from App Store, but in order to use it
the idea is that you are required to be a member of the organization, which in this case is a local sports organization.
To solve the problem I thought of giving away activation keys to members that can be entered when they create an account, and therefore only members will be using the app.
Will the app be rejected by App Store? If so, is it possible to go around this in some away?
Thanks.
No you will not be rejected by the App Store.
During the review you will only need to give the access to demo account.
Your app will be available to anyone but you are free to give the credential to any person you want.
edit
Fyi I have such apps. The AppStore only block 'discriminating' app based on carrier or location (you can choose the countries anyway), but you are perfectly in the rules if you give access only to your clients...
edit edit
2.22 like I said is against arbitrary criterias, not linked to the login mechanism
for 11.1 and so on, I understand the point, but in my case (and I think yours) there is no problem if
you sell your service before, the app is just complimentary
you dont sell anything within the app
you dont charge for the app itself or anything within the app, you charge only the use of the server/back office/whatsoever
I guess that Apple dont care, they just don't want to bypass the applestore but I dont think that it is your case.
You should try Enterprise distribution for such purpose.
Yes your app may be rejected. Check the App Store Review Guidelines. In 2.2 it says
Apps that arbitrarily restrict which users may use the App, such as by location or carrier, may be rejected
There are different alternatives.
You can opt in for the Apple Developer Enterprise Program, this'll cost you 300$ a year and requires you to be a legal entity.
If you want to test it with a limited number of people (<1000) try looking into Testflight it was bought by Apple and is deeply integrated in the development process.
No, there will not. You need to to give some demo account info as test data to review while submitting to app store in the iTunes Connect portal.
Demo use case(worked for me): Implementation is like, there need some userid/unique pin to the registered account holders to start the application. At the time they input this pin, authenticate the user with our server and give the permission to let in to the app.
Otherwise you need to go for enterprise distribution. Find more about enterprise distribution here.
We're a small company and have developed an iPad app we would like to give to our customers. I've read through the B2B option but don't like our customers having to register their DUN info with Apple.
Should I just load it in the App store and put in the description that it's a private App? It requires a login so it doesn't matter if other folks download it.
Currently, we're using it in house via the internal tester scenario.
No one but Apple can say for certain what Apple will do in any specific case, but your description suggests it will be rejected.
From Apple's App Review Guidelines (https://developer.apple.com/app-store/review/guidelines/):
17.2: Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
If you don't have a base functionality that applies to the general public, you will, in all likelihood, need to go Enterprise delivery.
Distributing publicly might be the best option, but I don't think you would get an approval if you describe it as a private app in your description.
Without knowing too much about your business or the nature of your app, it's hard to suggest, but possibly you could add some public usefulness on the front-end of your app, even if that's business info, contact information, a news feed, etc... with the real intent of the app being tucked behind a login portal. (all total speculation).
Distributing the app outside of the app store has a lot of limitations as well: http://mobiledan.net/2012/03/02/5-options-for-distributing-ios-apps-to-a-limited-audience-legally/
I would just submit to the app store and see what happens. Apple may reject it, but that is true in any case. I have an app of this nature, submitted with a couple of test accounts, no problem getting it approved. When the app launches, it pops a logon screen, and has a short message about where to get an account (which won't make much sense to people not in the intended audience).
I have an app in the iTunes store that has full functionality. I attempted to release a Free version which contains half of the functionality, and contains a link to the full version if the user tries to use the other functions.
Apple rejected the app on the basis that rather than having two apps, I ought to have the main app released for free and have the extra functions unlockable using in-app purchasing.
That's fine; I can do this. The only problem is that since I released the full version initially, some people have already paid for and downloaded the full version. When I update this app so that it is free, it will be restricted by default. Those users that have paid for the full version will have lost the functionality they've paid for.
I don't really want to release a second version of the app since I intend on continuing to update the app and managing two release streams would be unwieldy.
Is it possible to somehow offer for free the in-app purchase to those users that have already bought the full version of my app when I update the app to the new (free, in-app supported) version?
Edit: An (unpreferred) alternative would be a way of refunding the purchases to the original buyers, along with a note explaining why. Any ideas how?
What I'd do is add a already paid option within the application itself, and then allow users to enter a license code, or email address depending what you prefer, Which you can automatically issue from their contact details if you have them or ask them to contact you if you don't, which most will as they have paid.
Now as far as the licensing and the verification of these codes you could setup a cheap VPS which verify s the code and only activates with codes that you have entered on the server, meaning you won't fall victim of Keygeners.
Just my 2 cents.
If your app doesn't currently have a username/password registration, I would suggest releasing an update to the paid app that explains to your users on an initial popup view something like:
Thank you for supporting our app. Due to changes in Apple's policies, we will be converting this app into a free app with in-app upgrades. Since you already purchased the full app, you will be awarded all features! Please input an [email_address or username] so that we can provide a painless transition.
If your app has a user login mechanism already in place (username/password), then just store those details and have the user log in later in the "free" app to unlock all of the features.
Obviously, both of these suggestions require a backend for validation, but shouldn't be too difficult to create that.
This is tricky due to section 3.3.3 of the license agreement and Attachment 2. I'm not a lawyer so I'll save my interpretation but, read them.
Another option would be to make the free version a new, different app and leave the original one in the store but unavailable. Then you can still publish updates to it but new users won't see it. Apple would probably allow this considering you are still only presenting one app to new users. The downsides are (1) you have to maintain two versions and (2) you have to start over in terms of reviews etc.
For these 2 rules:
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.
Is the applicability of these rules reduced/removed if the enablement/disablement of the features/functionality (11.1) or the content purchase (11.2) does not actually occur within the app on the device.
For example, you write an app that requires free registration but if you visit a website outside of the app (and not linked to from the app) to "upgrade" your registration (by paying money) the app gains some more functionality or content next time you use it.
Thoughts?
My thoughts: you'd be violating the guidelines, but your app could get approved, of course. The payment does indeed not occur inside the app, but the application "utilizes" such a system (which is very broad) thus is in violation.
This reminds me of the Newsstand/subscriptions discussions going on before. Basically, if you offer something outside an app, you have to make the same (or better) offer inside the app (via IAP subscriptions). Perhaps this is applicable in your case, too. Although, according to 11.3, you may not offer services outside your app if purchased via IAP (so you may not unlock features on e.g. a website too.)
You'd also try and offer a free app. Once users (somewhere, somehow) upgrade their account, they can access the members only app, a new, separate app. But approval is still questionable, which brings me to my last part:
"We will reject Apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, "I'll know it when I see it". And we think that you will also know it when you cross it."
— https://developer.apple.com/app-store/review/guidelines/
In short: submit, pray and find out.
What you describe sounds similar to the situation that resulted in apps that used Dropbox being rejected (Link). Apple determined that since the apps that used Dropbox functionality required the user to visit the Dropbox site to sign up those apps were in violation of those rules and were thus rejected.