When one has developed quite a few iOS applications, one knows that it is not as simple as “develop-publish on App Store-get users to use your app”. The “publish” part might have a few hiccups. It has happened to us recently at Moqod and I couldn’t help but share the story of how it was unfolded and how we fixed it.
Our client, Palladio Groep B.V., is an interim and consulting agency in the field of the management and control of organizations, programs, and large projects in the public domain.
Moqod’s team developed an application designed by Palladio Groep bv named “Maturity Assessment Project control” that enables them to make a quick scan of the manner in which the management and control of their clients is organized and implemented. Based on the results of the assessment, Palladio advises its clients about further improvement in the management of the given project or organization. The case of Palladio’s application was classical for B2B apps: one needs to send a direct link to download the application to the clients without third parties involved, and they would have immediate access to it.
The challenge started when one of Palladio’s clients requested having the application on the official marketplaces due to the internal security requirements of their organization. Google Play accepted the first version right away. The App Store wasn’t so welcoming though.
Uploading the application was a part of my role as the project manager, so I sent the application for review to the App Store. Further, I’ll describe the issues and address how we solved it.
It’s B2B app, babe
The aim of the app was not aimed to be found organically on the AppStore, but to be sent directly. Thus, the first and only image was the screenshot of the login screen. For the rest, the administrator would provide the user with the login and password information.
After a few days of uploading the app, the App Store requested extra information from us to continue with the review of the app. They needed the following answers:
- Who is the target audience of the app?
- How do the users get an account?
- Where will the distribution of the application take place: within our own company, within the company of one target client, or among multiple target client’s companies?
- In which countries will the app be distributed?
- If the application is for internal distribution only, will both internal and external partners have access to it? Or it will be exclusive to internal employees only?
If I wanted them to keep reviewing the application, I had to give them answers, which I did immediately:
- The target audience of the app are parties that are invited by Palladio Groep to use the app.
- A course supervisor creates a unique account for each user. The user then gets a generated password via email.
- The application will be distributed among Palladio Groep’s clients.
- The application distribution is limited to the Netherlands only.
- The application is intended for the use by Palladio Groep and its partners.
Good and clear answers, aren’t they?
The same day, after receiving the answers, the App Store rejected the first version of the app.
The explanation for the rejection was the following:
The business application was designed for a certain business and its clients but not for general distribution on the App Store. According to App Store’s policies, B2B apps on their platform are meant to be used by external customers all over the world. Since our application wasn’t intended for general distribution, it couldn’t be made available on the App Store.
They followed with generics on reviewing how to distribute the application in a different way or to revise the existing one to make it available to external clients around the world. If we did the latter, we were advised to consult the App Store Review Guidelines and the Business App Distribution on Apple’s website.
One of the options in the App Store Review Guidelines was to make the application offer Mobile Device Management (point 5.5. in the guidelines) services. In this case, the app can be offered by companies and institutions, with a clear declaration of what user data will be collected prior to any actions. However, our client rejected this idea because of their policies.
We decided to work on the functionalities.
I carefully read into Other Business Model Issues (point 3.2.) and general guidelines (Introduction and Before You Submit). Right then I decided that we could fit our application into this model.
We would add the possibility to register in Palladio Groep’s application for everybody. They would have access to a demo version of the app as a result, after which they are able to contact Palladio Groep in order to participate in a real quick scan of the management and control of their organization.
Registration and authentication of any user are one of the first features you develop when you build an application for a wide audience. Adding our own requirements to the app after the login part was our way to go around the restrictions.
I suggested this solution to our client and got their approval. We’ve designed a user story and as a result, we added the following to the application:
- Possibility to register in the app
- Password recovery option
- Demo quiz for self-registered users
- Display of preliminary quiz results
- Contact form (after the quiz) with one single field and a note that “The administrator will have access to your email and your name. You can add additional contact information”
- Link to privacy policies
We added the following to the admin panel:
- A separate page with self-registered users (default group)
- Possibility to place the users from the default group to the permanent group if the user will participate in the real course offered by our client
- Default quiz for default users
- Possibility to send the email with the contact for to the administrator via backend
The new version was good to go, and we sent it for review to the App Store.
The first reply I received in three days was very unoriginal. It was just like the first reply — the application is not intended for general distribution.
A human behind the algorithm
Realizing they simply copy-pasted their initial reason for rejection of the first version, I decided to give a more thorough explanation of what has changed since. After all, people who review the applications for the App Store are just as human as us. I decided not to show them that I did the research.
The same day, I wrote to the App Store that according to their recommendations given, we have integrated the following:
- Password recovery
- Demo functionality to represent app purpose
I wrote that these functionalities imply a wide audience of the application and make it available to all the users. I emphasized that I didn’t find a single mismatch in App Store Review Guidelines and particularly in point 3.2. If ever there were more issues in the app, I asked for specific recommendations to follow to comply with the guidelines.
My explanation remained unanswered for several days. In a week I decided to click on “Appeal” and detailed the situation one more time in the appeal. The App Store replied right away and this time I got two messages. The first one confirmed they would continue the review of the Palladio Groep’s application with the new information provided. The second one stated that the appeal had been received and was being evaluated. Oh, good, at least the process was kept rolling.
On my side, I had to wait for the decision. They would notify whether the rejection issue was still valid or not after the improvements. They would also communicate on the new possible issues if there were any.
Two weeks of complete silence have passed, and I decided it was time for a reminder. I politely asked whether the application was still under review or if they needed more information on my side. The very same day they followed up with a very basic answer but… also, I finally got the “happy mail”! Bingo!
It took us almost two months and we got there. Our client, his clients, App Store, and Moqod got the result we had all been looking for.
The moral of the story?
- Policies, guidelines, and “how-to” have not been written to annoy the reader and skip them. They actually come in handy when used!
- “No” is not an acceptable answer when it comes to your business.
- The more you are passionate about getting a “yes”, the more human factor plays a role.
- Show them you did the research, be reasonable.
- Never settle for a copy-pasted reply.
With experience, you will have more and more ideas on how to make something work, as long as you keep doing your research and test your ideas. Rejections have happened to us before and without a doubt, they will happen in the future. What they have taught us is that there is always a way to turn a “no” into a “yes”The target audience of the app are parties that are invited by Palladio Groep to use the app.