DEV Community: hzzhdev

I've never felt more rejected than when I went through the Apple App Review process

hzzhdev — Tue, 24 Jan 2023 11:35:43 +0000

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!

Nobody cares about your stack (and your code quality)

hzzhdev — Mon, 23 Jan 2023 08:44:11 +0000

Every developer who's had side projects once hit that wall of inability to choose their weapon of choice for their next billion-dollar SaaS idea. The always-returning question being: what stack to pick and how should you approach your project in terms of architecture, testing, and avoiding technical debt? Guess what? Nobody gives a shit.

I've had discussions with other developers about what stack is the best one to work with in terms of building your newest product. Especially if you're building it yourself and do not intend to take anyone else on board. Like myself, others have their biases, considering they've worked with a certain stack. However, if you think about it, 9 out of 10 times it doesn't really matter what stack you pick, and you're probably overthinking and overengineering it.

An old tweet that I commonly refer to regarding the stack of RemoteOK:

@levelsio

@levelsio

🛠 People keep asking for the stack, it's:
- @official_php 7 without framework
- JS with @jquery without framework
- normal CSS
- @nginx on @ubuntu
- 1x @linode VPS @ $400/mo
- @stripe for payments
- SQLite for db

14:01 PM - 22 Sep 2020

Yes, we're all familiar with @levelsio, and some dream the life he lives and some hate to love him; I'm right there in the middle. But there is a reason why he's the OG indiehacker.

No fancy frameworks, libraries, transpilers, transformers, or other forms of overhead that most of the time will only cause you more headaches than it will help you. Some will call him a fool for using JQuery and not leveraging the newest of the newest, but if it works, it works, right?

Every user visiting Remote OK has literally no clue what tech is used behind the scenes, and I bet you a hundo that they don't care. All they care is; does the product performs fast, can this product provide them the value they are looking for and does the product provide that value quickly to them?

Code is just a tool

This can't be repeated enough. Early in my career, I was too much concerned about the quality of my code and the technical decisions I made, and I spent a lot of time learning about how I could improve the overall quality of my code. Granted, learning the difference between bad and good code is important, and when you work in an organization with other people and must comply to certain guidelines and protocol, it's important that your code is on par with that of your colleagues.

However, it is also important to realise that code is just a tool. As a developer, you're essentially a problem solver. Code is just one way to arrive at the solution. When you build a wooden chair, it doesn't matter if it was built using a hammer or a rock, as long as you can deliver the value (comfort) to the person using it. It's OK to write ugly code. It's likelier that your product is going to fail than it is going to succeed, and improving code quality should be reserved for products that succeed.

Haven't you read Clean Code?

Ask yourself this: How many side projects have you given up on already? How many products you've built are halfway there, but you're never going to touch them again?

Was it worth writing tests for them? Was it worth getting the architecture just right? Basically, those projects are now essentially giant lumps of technical debt. It only matters if the product you've built makes it to the finish line, does something, provides value, and is worth working on.

I've learned after many failed attempts that when building your own product, you shouldn't worry too much about how the code looks, worry about unit testing, or overthink structure and architecture. I understand that there are many arguments against this, and it's truly up to you how you like to divide your attention and time.

I'm not arguing that code quality, architecture etc. does not matter. It definitely matters, but it only matters if it's worth worrying about. I'm arguing that in the early stages of your product development lifecycle, you're looking to get something in the field for validation, and in that stage, I personally don't care about code quality. "Good enough" is what you're looking for, and once the product is making that sweet MRR, you can start thinking about improving the quality of your codebase and make iterations that actually matters. It may sound like doing twice as much work, but it's better to do twice as much work for a product that succeeds than to always do twice as much work and waste too much of your precious time.

So what stack should I use then?

Whatever gets you the quickest to the finish line, which in this case is getting a minimal viable product online that you can deploy in the field, iterate on, and validate if your product can deliver value to your potential customers.

Too often, I've taken the occasion of building a new product as an opportunity to try out new tech or a new language, only to see myself burn and want to jump off a cliff while figuring out the little nuances of that new hot thing I'm learning. It's too much of a burden to give yourself while you're trying to realise your idea and considering it's one-man show, you're only going to make it yourself more difficult.

However, if the intention is to learn new tech and the side-project is the carrier to your world of new knowledge, then yes! I completely agree! That's a great way to learn a new language or understand a new framework and a great way to retain that knowledge by putting it in practice.

But if the intention is to get something off the ground ASAP, just stick to your guns, make miles and start pounding.

But seriously, what stack?

I can't speak for you or any other developers out there, and there are a myriad of tools and frameworks to pick from. It essentially depends on your experience and what your background is.

If you've worked in tech long enough, you're probably comfortable with a set of tools already. If that toolkit allows you to build a product today, then there you go; you've got your stack.

If you're new to development and indie hacking in general, then it is important to get your basics straight. I understand that it's hard to navigate through the world of development with people around you holding shiny tech in their hands and promising you the path to nirvana. But if you really looking to start indiehacking through programming, I imagine your best bet would be to get your hands dirty with JavaScript. Purely for the following reasons:

There are so many JavaScript resources online to learn from, and the community is huge.
Yes, JavaScript has a lot of little quirks that will give you a pain in the ass. But even so, It's a fine language to start with, especially if your next step is to start learning TypeScript right after that.
JS frameworks and libraries like Vue, React, Svelte, etc. are very beginner-friendly.
2 for the price of 1 if you decide to throw Node and Express in the mix for your back-end server.
3 for the price of 1 if you ever want to build a mobile app using Ionic or React Native.

I don't intend this post to be the beginner's guide to indiehacking or development in general. There already are very good ones on this platform alone, but I do believe JavaScript is a solid gateway drug to the world of development.

People are going to argue that there are better options to choose from over JavaScript, and they are probably right. But it has worked for me and it's likely that it will work for you as well.

What do you use?

Essentially, my toolkit is pretty much as follows:

I use React for building web-based applications. Like all hipster React developers, I commonly use Next.js. However, lately I've been a huge fan of Create T3 for end-to-end typesafety. I've used Nuxt.js in the past but haven't used it in a while, but I'm still a huge fan of Vue, and with their latest V3 iteration, I'm thinking of giving it another shot.
I use Node/Express for building back-ends using TypeScript (with ts-node). I used to work a lot with MongoDB, but recently switched to PostgreSQL using Supabase. Or host it myself—it depends on the situation
I use Flutter for building mobile applications. Used to work a lot with Ionic (for side-projects and professionally), but holy crap, I'm so happy I made the switch to Flutter.
Digital Ocean for all my server stuff. I believe there are cheaper alternatives, but as far as I know, nothing beats the ease of use of Digital Ocean for me.

Don't take this as advice; I'm a student of life and I'm learning new things as I go. But these are the guns I'm sticking to.

I'm very open to hear what everyone else thinks about it, don't hesitate to give me your 2 cents!