What I Learned Preparing Asele for the App Store and Google Play

I’ve been getting Asele, a women’s health app, ready for the App Store and Google Play, and the process taught me more than I expected. Not the coding part. The submission part: the admin, the declarations, the privacy paperwork, and the small requirements that quietly block you right when you think you’re done.

Here’s everything I wish I’d known before I started, laid out as a checklist you can actually work through.

Prep these before you submit

Some things are the same across both stores. Get these ready first and you’ll save yourself a lot of back-and-forth:

1. Working app build. Stable, functional, and ready to demo.
2. Privacy policy. A public HTTPS link that matches what your app actually does.
3. Store listing assets. Icon, screenshots, title, description.
4. Support contact. A support URL, email, or help page.
5. Data mapping. Know what data you collect, why, and with which SDKs.
6. Content declarations. Age rating, audience, app content, permissions.
7. Review access. A demo account, OTP steps, and test credentials.
8. Deletion path. In-app deletion, plus a public web option if accounts exist.

Doing this prep first saves a lot of time. Almost every store-specific step below leans on one of these.

Google Play: what to prepare

Play Console can feel easier at first, until the testing requirement kicks in. What surprised me most:

1. Developer fee. $25, one-time.
2. Health Apps declaration. You have to declare the health features your app provides directly in Play Console.
3. Identity verification. Set up and verify your developer account.
4. Testing gate. New personal accounts need closed testing before they can go to production.
5. Beta testers. At least 12 testers opted in for 14 continuous days.
6. Exact tester emails. Testers must join using the exact Google account on your tester list.
7. Data safety plus deletion. Complete the Data safety form and the account deletion answers.
8. Release assets plus build. Use testing tracks, upload a signed .aab, and add a 1024 × 500 feature graphic.

That testing gate is the one that catches people. Twelve testers for fourteen continuous days isn’t something you can rush at the end, so plan for it early.

Apple App Store: stricter review

Apple felt more stringent, mostly because the review is deeper and your documentation has to be solid. More review-heavy, more admin, more detail:

1. Developer fee. $99 per year.
2. D-U-N-S number. Needed when enrolling as an organisation. You apply online through Dun & Bradstreet, and it takes a few days to get approved.
3. Business proof. Legal entity, work email, and a public website.
4. Manual review. Apple reviews every app before approval.
5. App Privacy. Declare data types and third parties in App Store Connect.
6. Metadata. Screenshots, support URL, age rating, review notes.
7. Reviewer access. Provide demo credentials and keep your backend services live.
8. TestFlight nuance. The first external beta build may itself go through review.

Login, onboarding, and access gotchas

These were the ones I nearly missed, and any one of them can become an Apple submission problem.

On Apple specifically:

• Third-party login rule. If you offer Google or social login, Apple expects an equivalent privacy-focused option.
• What that means in practice. Add Sign in with Apple.
• The exception. If you only use your own email-plus-password system, that extra login option usually isn’t required.
• Don’t require login unnecessarily. If key features don’t need an account, Apple expects them to be accessible without one.

General prep for both stores:

• Account deletion. If users can create accounts, give them an in-app deletion path.
• Reviewer access. Share OTP instructions, demo logins, and keep flows working during review.
• Live backend. Make sure backend services and emails are actually available while your app is being reviewed.

The short version: Google-only sign-in can quietly become an Apple submission problem.

Health app plus AI extras

This part is especially relevant for apps like Asele, which handle sensitive health data and use AI. If you’re building in this space, my notes on AI for femtech and AI in mental healthcare go deeper on the responsibility side. Health apps need tighter privacy thinking, cleaner documentation, and fewer assumptions:

1. Map your health data. Symptoms, cycle data, mood, medication, notes, and more.
2. Match your disclosures. Your privacy policy, Apple’s labels, and Google’s form all have to tell the same story.
3. Describe your health data precisely. Be clear about what users enter, what you store, and what your app derives.
4. Medical claims. Don’t overclaim diagnosis, treatment, or outcomes.
5. Ads plus profiling. Say clearly that health data is not used for ads or profiling.
6. Permission clarity. Explain why you need notifications, camera, location, or any other access.
7. AI consent. If a third-party AI receives user data, ask for explicit in-app consent.
8. AI citations. AI-generated health information should show visible citations inline.

The unglamorous part

Finally, the bits that quietly block submission. None of it is unreasonable. It just hurts when you learn it in the order it blocks you:

1. Screenshots. Prepare the required device-size screenshots for both stores.
2. Google assets. A 512px icon and a 1024 × 500 feature graphic.
3. Android build. Upload a signed .aab, not an .apk.
4. Apple build. Upload an IPA through Xcode or Transporter.
5. TestFlight. Use beta builds to test and collect feedback before release.
6. Final consistency check. Make sure privacy, listings, permissions, and flows all match.

If you’re shipping your first app, especially a health app, the code is rarely the hard part. It’s the paperwork, the declarations, and the order they hit you in. Work through the checklist above before you submit and you’ll skip most of the surprises I ran into.

This post started as a LinkedIn carousel. If you’re shipping in public too, my founder podcast checklist is a companion piece, and if you’d rather hand the launch content off, that’s what I do through my writing services.

I build Asele and write about AI across marketing and women’s health, shipping in public. If that’s your kind of thing, follow along.