I used to have a full head of hair until I chose to build my own iOS app and got grilled by the Apple App Store gatekeepers.
I must say that I was a bit naive when I decided to deploy my iOS app for the first time. I mean, I've done it before professionally, and there were some issues here and there, but usually it goes through the review without any issues, but oh boy, I was in for a ride.
The magical place called App Store Connect
If you're not familiar with mobile development, this may all sound foreign to you. Unlike app development for the web, with mobile, you're bound to places like the App Store (for iOS) and Google Play (for Android). That also means you have to comply with all their regulations and protocols. However, since I'm only releasing an iOS app for the time being, I'll talk a little about App Store Connect.
When developing an app for iOS, you'll eventually have to make use of their App Store Connect environment. It's basically your "global control center" for anything app and app store related.
They've improved it over the years, but it used to be a maze of links and portals, and you'd need tutorials just to find your way through App Store Connect (I'm also looking at you, developer.apple.com).
Say your app is finished and you want to release it on the app store. The first thing you need to do is create a bunch of certificates, profiles, and identifiers in their developer environment to even be able to push it onto App Store Connect. If you make use of Push Notifications and In-App Purchases, be ready to make an appointment for an anti-hair loss treatment. Anyway, I'm not going to get into that because it's a can of worms I don't want to open right now.
Once you have that sorted, you can use Xcode, which is Apple's own IDE, to compile and archive a binary that you can sign and deploy to App Store Connect. I'm not even going to get into this, to me this feels lik the 10th circle of hell Dante forgot to mention, but I'm glad I'm not alone in this.
But we're going to assume that it all worked out.
TestFlight
Once you're able to deploy your app through Xcode, your app will show up in App Store Connect under a section called "TestFlight." TestFlight is basically your testing environment, and it allows you to publish apps through their TestFlight iOS app to your testers. This can be internal, external, alpha, or beta testers. It's all up to you. You can upload multiple builds per version and add test notes so your test users know what to test and what features are new or updated. This is a feature I love about App Store Connect, and it works seamlessly with their whole release process.
Test users can download or update the app through the TestFlight iOS app, read the test notes, and provide feedback.
When you're happy with a build, you can add it to your version release and submit it for review, and that's where the fun begins.
The App Review (and on getting rejected)
Like I said, I was a naive little boy when I embarked on this journey. Little did I know, I was quickly put in my place, and it took me one too many iterations to make it to the finish line.
When you submit your app for review, the waiting game starts. There's no time indication whatsoever other than, according to Apple, the average waiting time is less than 24 hours. This sounds about right if I think back about the apps I worked on in the past. However, I've read stories of people waiting up to 72 hours for their app to get reviewed, usually for first-time releases, and depending on how busy they are, it can take longer.
The frustrating part of this process is that they can reject your app for even the smallest reason. They are very nitpicky. If it is in any way not according to Apple's guidelines, your app will be rejected. I found out the hard way that it is essential that you carefully read the guidelines before you even start working on your app.
For instance, they have clear guidelines regarding the design of your app and will reject it if things like contrast or font size do not meet their requirements. Obviously, going through their design guidelines it all makes sense, but it would be a shame if you had to redesign your app because you didn't read their specs.
Why I got rejected
Unlike dating, where there is a possibility you will get ghosted, Apple however, will take every opportunity to shit on your face and tell you what you did wrong. Which is, in this case, very useful.
It took me three builds to get something reviewed that was passable according to the reviewers. I feel that's still pretty okay, and I'm being a bit of a drama queen in this post, but hey, it's still annoying and could be easily avoided if I'd just read the guidelines and didn't depend on my previous experiences alone.
However, to give you insight into why Apple rejected my submission:
Rejection #1: A functional link to the Terms of Use (EULA)
When you want to deploy your app to the App Store, you will need to have three sets of documents that you have to include in one of the many fields in App Store Connect.
- Privacy Policy
- Terms and Conditions
- Terms of Use (EULA)
From previous experiences, I knew these documents were required, but what I didn't know is that you had to add them to your app description as links. However, I'm not sure if this is standard practice, but I included auto-renewable subscriptions in the app, and I believe this was the reason why I had to add it to my app description.
Rejection #2: Apps that support account creation must also offer account deletion to give App Store users more control of the data they've shared while using your app.
I have a very simple account creation method in the app using an email and password. Users don't have to confirm their account, and because it was an MVP, I wanted to make it as easy as possible for users to sign up and worry about accounts in the next iteration.
However, what I didn't take into account is that Apple has a strict policy regarding this matter, which states that if you allow users to create accounts, you must also offer account deletion. Slight oversight, but this took the most work to fix.
I had to create an additional endpoint and add functionality in the backend to allow this, along with all the extra UI work that came with it.
Rejection #3: We noticed that several screens of your app were crowded or laid out in a way that made it difficult to use your app.
Another slight oversight... I was so busy working on my landing page that I totally forgot to test the app on the iPhone SE. which has a smaller screen size than the more expensive iPhone models (13, 14, etc.).
So there were a couple views where components overflowed the screen, which made those components unusable. But fortunately, it was just limited to two views and a couple of buttons, so they make it sound worse than it actually is, and they attached screenshots so you don't have to guess where it went wrong.
There's light at the end of the tunnel
After the third rejection, I deployed another build and submitted it for another review. So you can imagine I was really happy to see this bad boy arrive in my inbox the following morning:
It felt like a relief, and I was able to focus on other things rather than getting the app through the review.
How to avoid rejections? (not dating tips)
To be fair, it was all me that was at fault here. I didn't take the time to read the review guidelines and relied too much on my previous experiences. However, if you've never gone through this process, I can give you the following advice to make the whole process less of a pain:
- Actually read the app review guidelines before you start building and designing. I can't stress this enough. You need to have a general idea of what's acceptable and what's not. The worst thing that can happen is that you have to go back to the drawing board when you thought you were at the finish line.
- Your design matters (even the screenshots you want to use in the app store). Apple is very strict when it comes to your interface. If you're applying custom-designed UI to your app, make sure it conforms to Apple's Human Interface Guidelines. If you don't have any design experience, your best bet would be to use standard UI components.
- Get your paperwork sorted. There's a whole section under "Avoiding Common Issues" that explains what documents are required and which fields need to be filled in. There is no simple "click here to agree to all" checkbox you can click on. Especially if you're working with in-app purchases, you will need to get everything under **Agreements, Tax, and Banking** covered.
- Don't mislead your users. Don't be a shithead and trick your users with false promises. Apple will reject you or, worse, ban your app.
- Be as complete as possible. Don't skip any fields in the App Store Connect environment. If you can fill it in, fill it in with valid information. They will check it and reject it if they notice any missing information.
- Be honest about data collection. If you use any analytics tools to measure usage or whatever, be transparent about it. Request permission where it's necessary.
- Test your build thoroughly before submitting it. Xcode includes a simulator where you can test your app in various settings and make sure it works on the latest devices (iPhone SE included). If you use capabilities such as in-app purchases, wallet, Apple Sign In, etc., make sure they are configured properly.
- Provide a way for Apple reviewers to login. If your app has some form of authentication, make sure you make it easy for the reviewer to sign in. Provide a separate Apple test account that reviewers can use to login. There's also a text field where you can describe the steps a user needs to take to sign in. Make use of it, even if it's a simple email or password form of authentication.
We're finally there
With a total of three rejections, I feel I did okay overall. I could have done worse. However, after reflecting about the rejections, I believe that they could have been easily avoided and that less time could have been spent on resolving issues.
To get things setup correctly in App Store Connect, though, takes a lot more time when I'm working alone than when I'm with a team. There is more paperwork involved, and you'll probably spend a weekend or two just putting up your App Store environment with the correct copy and visuals. Or, maybe I'm just slow.
I'm very open to hear what everyone else thinks about it, don't hesitate to give me your 2 cents!
Top comments (0)