Releasing to the App Store and Google Play

The app is finished, tested, you breathe out and figure you’ve made it. Except between your phone and your customers’ phones stand two gatekeepers: the App Store and Google Play. And both have their own rules, their own fees, and their own mood. This lesson is about getting past them on the first try, not on the third one after two weeks of waiting.

Register the developer account under your name, not your vendor’s

Before you upload anything, you need accounts in both stores. And the same thing applies here as with a domain and hosting on the web: they have to be yours, under your company, on your email.

• Apple Developer Program. An annual subscription you pay every single year, or the app disappears from the store. Registering as a company also requires a D-U-N-S number, which takes a few days, so factor that in.
• Google Play Developer. A one-time fee you pay once and you’re done. Identity verification takes a moment here too.

That account is your most valuable asset in the whole project. It holds the payments, the certificates, the reviews, and the app’s name itself. If an agency or a “developer friend” sets it up under their own name, you only own the app on paper. When you part ways, they walk off with it and with all the ratings you spent years collecting.

Invite your vendor into the account as a team member with the permissions they need. You stay the owner. It’s five minutes of work, and one day it’ll save you a serious headache.

Apple reviews every app, Google is faster but still watching

This is the biggest difference from the web, where you publish whenever you want. In the stores, someone approves every version, and they can send it back to you.

Apple is stricter, and its review usually takes a day or two. The most common reasons it doesn’t pass:

• The app crashes or won’t launch. The reviewer actually opens it. If it crashes on startup, you’re rejected. Test the exact version you’re uploading.
• Privacy details are missing. Without filled-in data disclosures, they won’t even let you through (more on that below).
• A “website in a box.” An app that just wraps your website and adds nothing on top is a classic rejection reason at Apple. It has to make sense as an app, not as a bookmark.
• Bypassing payments. For digital content inside the app, Apple wants its own payment gateway and its own cut. Send users to pay somewhere outside the store and you’ll hit a wall.

Google reviews apps too, but it tends to be faster and looser, and it handles a lot of it automatically. That doesn’t mean anarchy. The same rules on privacy and payments apply here, and a violation can get your account blocked outright.

Before you upload, read your submission through a reviewer’s eyes: the app opens, it does what it promises, the data disclosures match reality, and paid items can be paid for the way the store wants. Three quarters of rejections are these little things.

Privacy and consent: whatever you collect, you have to disclose

Both stores now require you to state what data the app collects and what you do with it. It’s not a formality you click through. It’s publicly visible, and it has to be true.

• App Store “nutrition labels.” The app shows a summary like the one on a food package: what you collect (location, contacts, payments) and whether you tie it to a specific person. You fill it out in App Store Connect.
• Google Play “Data safety” form. The same thing on Google’s side, its own form with similar logic.
• Tracking consent. On iPhone you have to ask the user for permission before you start tracking them across other apps and websites. Most people say no, so plan for that up front, not after launch.

Fill it out honestly, and above all make it match reality. If you state you collect nothing while the app calls three ad libraries, that’s a lie both the store and the regulator will catch. In the EU, GDPR weighs in on top of that, so dishonesty here isn’t just a rejection risk, it’s a fine.

Getting found in the store is its own discipline (ASO)

Your store page is your shop window. Most people won’t discover your app through an ad, but by finding it in the store’s search. Optimizing for that is called ASO, App Store Optimization, and it’s a cousin of SEO.

• Icon. The first thing a person sees. Simple, legible even when small, distinct from the competition. No text in the icon.
• Screenshots. The single most important element on the page. Don’t show bare screens, show them with a short caption of the problem you solve. The first two decide whether someone keeps scrolling.
• Title and keywords. The title should carry the main thing people search for, not just your brand. Apple has a separate keyword field, Google pulls them from the description.
• Description. The first two lines have to sell before someone taps “read more.” Write for a human, not a robot.
• Ratings and reviews. A huge chunk of the decision lives here, and so does your search ranking. Ask for a rating politely at the right moment, not right after install, but once the app has genuinely helped the person.

ASO isn’t finished at launch. It pays to tune the screenshots and description over time and watch what lifts your download count.

Test on real people and roll out in waves

The last safety net before the app reaches everyone. Both stores have channels where you give it to a select group before the world sees it.

• TestFlight (Apple) and internal testing (Google). Send builds to colleagues, the client, or a handful of customers. You’ll catch bugs that never showed up on your own phone, because you know where not to tap.
• Phased (staged) rollout. Google does this directly: you release a new version to, say, one percent of users first and raise the percentage gradually. If a bug shows up, you stop it before it hits everyone.

This is the difference from the web, where you overwrite a bad version in a minute. An app update goes through review again, and it takes days before people download it. A bad build that hits everyone at once is slow and painful to fix. Wave by wave is a cheaper insurance policy than an apology email to a thousand angry users.

In the next and final lesson, we’ll look at what kicks in right after launch: how to measure the app, update it, and above all keep it so people don’t delete it within a week.