I have an application with banking domain (UPI) the very first step or screen the user is presented with a button titled "SEND SMS" to login/register when user clicks on it, a SMS is send from the device using the MFMessageComposeViewController, and based on the mobile number the server respond with weather the user already exists or its a new registration.
Since this is obvious that a valid phone number is required to send SMS or use the application, I am unable to provide a demo account to them.
This is second release of the version, for the first release we have submitted the video of production application and it was live on Appstore, not only this app but I have submitted few other without a demo account but using a video, this time too I have submitted the video, still they ask for the demo account, I have tried to explain them whole process using telephone conversation but no luck. Also did asked them to use there own mobile number on their testing device but they refused to do so.
How can I move forward with this release?
I went through some similar question but didn't find any help.
Apple rejects app because test account not given (as App login via OTP only)
Is demo account mandatory for apple submission?
App meta data rejected , requires demo account.
Note: I don't have OTP functionality in my application, the only way to register is by sending the SMS.
In this annoying situation.
The fact is, generally you have to:
change your app, so that it does have a demo mode, which Apple can use.
It's a total pain in the ass but that's how it is.
Some points,
For example, you could have a "special" number (666-777-8888) which is entered. When that one is entered, the app unlocks and you can see how it works.
It is really bad luck when this happens. It's just one of the reviewers being an idiot. Sometimes if you just submit again it will sail through.
Note that you CAN IN FACT email them and explain the situation, they will give you special handling and they will "actually test it" with a phone number. However, of course this can take time, it takes a long time to get special handling. (Unless your app is already popular / well-known, then they will help you instantly. It's not fair but that's life.)
An important point is this: for the demo mode, note that you do not have to go overboard showing every feature. Apple's review process is a joke anyway. In 99.9% of cases they just glance at your app. If you do have to make an 'Apple demo mode', it's normal that the demo mode only has a few of your features. They are really just checking that it does not crash-upon-launch and that it generally works ok.
{Regarding the last point - indeed they only carefully review your app for policy problems etc once it is popular. This leads to the infuriating situation where controversial apps are approved at first, but then once they "actually look at it" they say you're not allowed to collect donations or use that payment model or whatever the case may be.}
Regarding having a "special demo" mode. It's a nuisance but sometimes you have to do this:
Have a URL like "yourCompany.com/DemoCheck.txt".
When the app launches, see if that exists.
If it does, allow "pain in the ass Apple demo mode"
Now, after apple approves it, in fact remove the URL from your web server, so your app now knows to run in normal consumer mode.
(Note that if you are using any sort of backend, which you probably are, you can do the same thing just using your back end. So just have a value in Firebase or whatever that indicates "Apple demo mode". Once the app goes to production, turn it off.)
Once again, if you're truly doing something important like "a banking app" you, obviously can't have a security hole like an idiotic "apple test version". In that case you can actually contact them and carefully explain the situation and they will, in fact, test it "properly" using a phone etc. But that takes a really long time and is just not practical - consider, you'd have to do that every single time. In practice you need a "apple demo mode".
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 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!
Concept on howto maintain a trial and purchasable full version of an IOS-app today:
There are lots of dicussions on this topic, but I would like to look at this for my case and how it would be designed TODAY (2015), with actual Apple restrictions.
I have an app which initially loads data from the internet to be displayed. (Trial-Content -> 80MB, 20%, Full-Content -> 400MB, 100%)
I would like to offer the Users to try the app with limited content first.
With limited content: 20% works as like the fullversion. 80% are marked with a question mark. If the users clicks on the question mark I would like to guide the user to the fullversion.
I prefere to have 2 apps (2 builts), because of having 2 separate rankings. Users, which buy an app are rating better, because they are really interrested in the app and will only buy, when they are pleased with the trial app. So an app with inapp purchase has a lower ranking in avarage then a isolated full version (built). But I guess this concept would be rejected by apple, because you have to mention the fullversion in the trialversion and you have to name the trial version as "trial" ? (Sorry for the bad english)
How will this be designed with IOS apps ? Howto guide the User to the fullversion, without beeing rejected by Apple ? (I read popups like "Would you like to purchase the fullversion?" will be rejected. )
In Android I did the following:
I created one app with the full functionality, which is at the same time the trial-version.
I created one purchasable app, which is only an unlocker app.
The trialversion app checks if the unlocker is installed. That way I can differentiate between trial and full and will load the corresponding content.
When clicking on the question mark, I will show a popup saying "Would you like to purchase the full version?".
This is quite a common pattern, you just can't call your "trial" version "trial". Quite often such versions are called "light".
To send the user to the app store to buy the full version you can use the SKStoreProductViewController to display the app store page for your full version directly in your app. This should be OK with Apple.
Your Android solution with the paid "unlocker" app would be possible too. Your apps need to expose an URL scheme and using that you can check if the other app is available. They also could use an app group to communicate. But this will most likely not pass review as apps must do something useful by themselves. They will probably test your unlocker on a device that doesn't have your other app installed and immediately reject it.
I would strongly suggest to reconsider an IAP for this. That's basically the ideal use case for it. You must not be afraid of bad reviews for offering purchases. Trying to send the user to buy another app will probably give as many bad reviews if not more. The IAP flow is much more user-friendly.
As #Sven suggested IAP is recommended in your case.
If you want to maintain two different apps for trial and full version, you can give your trial app name as "APP NAME FREE", I think Apple will not reject the app with name "Free" in App name (I successfully uploaded free and paid versions of same app with this trick).
I have been reading The Business of iPhone and iPad App Development: Making and Marketing Apps that Succeed (http://www.amazon.com/Business-iPhone-iPad-Development-ebook/dp/B004TMNSJK/ref=sr_1_2?ie=UTF8&qid=1340317546&sr=8-2&keywords=marketing+iphone+apps). The book is a little old (about a year at this point, which is a long time considering how long the app store has been around).
The book claims the Apple's iPhone development guidelines/rules state that an app must be fully functional. The book says that because of this rule, a "free" or "lite" version of an app cannot display buttons that appear to be functional but, when clicked on, prompt the user to purchase the full version of the app. For example, imagine a GPS app that has a button labeled "Give me turn-by-turn directions as I drive". If you click on the button, it just pops up a dialogue that says "Buy the full version to unlock this feature". According to this book, that app would be rejected by the Apple review team.
I have an app that allows users to download extra content with an in-app purchase. I would like to display the content as "grayed out". If the user clicks on the locked content, I want to display a popup that tells them how they can get the additional content. According to the book, this behavior will be rejected.
However, since this design is so important to my app, I've spent some time reading through all of the iPhone app guidelines, including the In-App Purchases guidelines, and I have found NOTHING that leads me to the conclusion that this sort of behavior is not allowed.
Since the app review process is currently sitting at about a week, I don't want to lose a full week of app purchases because of a rejection for this. Has anyone ever heard of this rule, and if so, can you please point me to it?
Thank you.
I had a "Free" or "Lite" app recently submitted (and accepted) to the App Store, where some UITextFields were greyed out and when touched, a UIAlertView was displayed . I don't know if this would be acceptable with buttons but it seems like more or less the same thing.
I think the book is probably right. Please check this link or read below.
The two most common reasons for application rejection are issues with core functionality and crashing. Core functionality encompasses the belief that customers rightfully expect all the features described in the marketing text and release notes to work as described, and likewise that all the buttons and menu items within the application will be fully functional (i.e., no grayed out buttons or notifications that a feature will be implemented later). Before you submit your app for approval, make sure that every aspect of your application is fully functional and that the marketing text and release notes correspond to the end user experience.
I have a website which offers (FREE) account based services. Iam working on a iphone app for the site. Can somebody help me with these questions?
1) Registration: In my case, the app is meaningless without an account/registration (all free). There is a lot of chatter in the internet that apps that do not offer a "registration-free" experience will be rejected. (example : http://readitlaterlist.com/blog/2010/08/version-2-2-rejected-new-rejection-reason-from-apple-may-have-major-implications/) Thoughts?
2) Email Verification: On my website, a user has to "Verify his email" before he can login.
Basically, can I do this one time only thing in my app: (a) ask email -> register (b) ask user to copy verification token in email & paste in the app (c) Hit verify & let them inside the app upon success. Is this alright?
3) Is it against Apple's rules if the iphone app only supports existing users(who already signed up via website & have a user name password)? This way I need not worry about 1 & 2 for now & still have a full fledged app.
Please note that I have read the guidelines but still cannot come to a conclusion.
I am aware that "will Apple reject my app" - is a question nobody can answer
All I am looking for is your opinion based on your prior experiance & your interpretation of guidelines. Thanks much.
UPDATE: To all users who land here: Apple approved my app few weeks ago. All I did is explain(in review notes) that my app is truly account based & would be meaningless without an email. On my home screen, I have 2 buttons, "I have an account" & "Create an account". There is no registration free experience other than a series of graphics focused on "what is " & indirectly emphasizes that it is an account based appln. Apple seem to be convinced & approved the app the first go. Hope it helps.
I made an app that sounds very similar to yours. I host some websites that are basically forums (they require registration). So my app is an app that allows the user (once they have logged in) to read, post, edit profile etc. Without logging in they get nothing, they see a login screen/Signup button. Which takes them to a form to sign up, it then sends out an email and they approve it via the link it then allows them to login. So as you pointed out No one can really tell you if your app will be rejected or by apple, but my app was very similar to yours and made it through just fine. Also think about a service like Spotify, gmail, or facebook. They require the user to login/register before the app works at all. I believe these rejections dont come from the fact that they are requiring users to login, but they are making it difficult for them to login in or they did not have a website that this was tied to, they just want the user to login to use the app. Its a very fine line, and again apple will be the judge of this in the end.
*Apple very well could have changed this since I submitted my app, but this is just my experience.
In general this sounds fine. The most important piece of advice I can give you is to make sure that you create an account for the reviewers to use - use the 'review notes' box to give them a login and password so they can type it straight into the app. You'll probably get rejected if you don't do this (reviewers dont' have time to check out your site, sign up, wait for the email, click .. etc).
EDIT: Also you should ensure there's a link to the registration page on the web from the front-page of your app (or at least somewhere very obvious).
If your submitted iOS app requires email verification from within the app for the app to function, this sounds it could very likely be a strong reason for a rejection by Apple (apps are not allowed to require personal identifying information.)
If your app requires a pre-existing login/password, and you give Apple a pre-existing fully functional working login for review purposes, what any user has to do to get this login outside and before running your app may be outside Apple's purview (for instance, joining some club or professional organization, opening a bank account, etc.).
But the only way to know for sure is to submit an app for review by Apple.
Our empirical knowledge is that we had submitted a fully featured app with more then one reasen to get rejected. One of them was, of course, that we enclose a way to get balnce in the app without using the IAP (https://developer.apple.com/in-app-purchase/) from apple. That thing was a killer. I think, because of this feature, the reviewers told us even more reasons to get rejected. One was the signup button in the login screen. After we disabled the topup and the signup feature, the review was fine and we're happy and online. Since that rejection, over a year ago, we had never tried to enable signup and upload it again. Now, we'll do that and I will report here what is happaning...
Update #Ravi Jul 31 at 16:18
It's like what I said! We're now online with a singup button at the start screen of the app. Apple does not disallow it. FYI