Publishing a React Native App to the App Store and Play Store: What It Was Actually Like

Building the Damsyn e-commerce app took months. Getting it onto the App Store and Google Play took another one to three weeks, and those weeks taught me more about the stores than any tutorial did.

This isn't a step-by-step guide to clicking through App Store Connect. It's what the process was actually like: what went wrong, why, and what I'd tell any developer, especially one here in Ghana, before they submit their first app.

The setup

The app is built with React Native and Expo, and I used Expo's EAS Build to build and sign it for both platforms. One codebase, two stores.

We published under a company account on both stores, not a personal one. That means a bit more paperwork up front. Apple requires a D-U-N-S number (a free business identifier) to enrol as an organisation, and your legal company details have to match exactly. The fees are $99 per year for Apple and a one-time $25 for Google.

A company account is worth it for a business app: the listing shows your company's name instead of a person's, and the app doesn't depend on one developer's personal account.

Building and signing: EAS helps, but it doesn't make it painless

If you've never shipped a mobile app, "signing" is the part nobody warns you about. Every build you upload has to be cryptographically signed to prove it came from you:

iOS needs a distribution certificate and a provisioning profile tied to your Apple team and your app's bundle ID.
Android needs a keystore (a signing key). If you lose it, updating your app gets painful.

EAS takes most of this off your hands. It can create and store the certificates and keystore for you, and building for production is one command:

eas build --platform ios --profile production
eas build --platform android --profile production

Even so, signing was one of the parts that cost me the most time. What I learned:

Let one system own your credentials. Mixing certificates created by hand in the Apple Developer portal with ones EAS generated is how you end up with confusing errors. Pick EAS (or manual) and stick with it.
Back up your Android keystore. EAS stores it, but download a copy with eas credentials and keep it somewhere safe outside EAS too.
Let EAS handle build numbers. Both stores reject uploads that reuse a build number. Turning on autoIncrement in your eas.json production profile means you never have to remember to bump it.
Use eas submit to send builds straight to App Store Connect and the Play Console instead of downloading and uploading files by hand.

Apple review: rejected, fixed, rejected again

Apple's review is where most of the time went. The app was rejected several times, for four different reasons. Each one is common, and each one is avoidable if you know about it in advance.

1. Reviewers couldn't fully use the app (Guideline 2.1)

Apple's reviewers have to be able to test every feature. If your app needs a login, you must give them a working demo account in the App Review Information section of App Store Connect, and the account needs real content in it: products, orders, whatever makes the app make sense.

For an app built for Ghana, there's an extra trap: the reviewer is not in Ghana. If your catalogue, delivery options, or payment methods (like mobile money) only work for Ghanaian users, the reviewer may see empty screens or failing payments and reject the app as broken. Make sure the demo account shows a complete, working experience from outside the country, and explain anything region-specific in the review notes.

2. No way to delete your account (Guideline 5.1.1(v))

This one surprises a lot of developers. If your app lets people create an account, it must also let them delete it, from inside the app. Not just log out. Not "email us to delete your account." A clear option, usually in settings, that actually deletes the account and its data.

That meant adding a proper "Delete account" flow on both the app and the backend. If you're building a new app, put this in from day one. It's much easier than adding it after a rejection.

3. Privacy and permissions

Apple checks two privacy-related things closely:

Permission messages. When your app asks for the camera, photos, or location, iOS shows a message explaining why. Apple rejects vague ones like "This app needs access to your photos." The message has to say what the permission is used for. In Expo you set these in app.json, for example:

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSPhotoLibraryUsageDescription": "Allow access to your photos so you can upload a profile picture."
      }
    }
  }
}

App Privacy details. The privacy "nutrition label" you fill in on App Store Connect must match what your app and every SDK inside it (analytics, crash reporting, payments) actually collect. If they don't match, expect a rejection.

4. Screenshots and metadata (Guideline 2.3)

Your listing has to accurately represent the app. The things that trip people up:

Screenshots must show the real app in use, not just marketing images or a splash screen.
You need screenshots for the required iPhone sizes, and for iPad if your app supports iPad. If your app isn't designed for tablets, set "supportsTablet": false under ios in your Expo config so you're not asked for iPad screenshots.
Don't mention other platforms. No "also on Android" or Google Play badges in your iOS listing or screenshots.

Google Play: more forms, fewer surprises

Compared to Apple, the Play Store side was smoother. Google's process is mostly about filling in the right forms in the Play Console before you can publish:

Data safety: Google's version of the privacy label, declaring what data you collect and why.
Content rating: a questionnaire that sets your age rating.
App access: demo login details for reviewers, just like Apple.
Privacy policy: a public URL is required.

One thing a company account spares you: new personal developer accounts on Google Play must run a closed test with at least 12 testers for 14 days before they can publish to production. Organisation accounts don't have that requirement.

My checklist before submitting to Apple

If I were publishing a new app tomorrow, this is what I'd check first:

A demo account with real content, filled in under App Review Information, that works from outside Ghana.
In-app account deletion that actually deletes the account.
Specific, honest permission messages for every permission the app requests.
App Privacy details that match the app and every SDK in it.
Real screenshots at the required sizes, with iPad support turned off if you don't need it.
No mention of Android or Google Play anywhere in the iOS listing.
Credentials managed in one place, the Android keystore backed up, and build numbers auto-incremented.

Was it worth it?

Yes. Every rejection felt like a setback at the time, but each one pushed the app to be more honest with users about their data, easier to leave, and clearer about what it does. The next submission, whether an update or a new app, goes much faster because I now know what the reviewers are looking for.

If you're a developer in Ghana getting ready to publish your first app, expect the first submission to be rejected, and don't take it personally. Read the rejection carefully, fix exactly what it says, and resubmit. That's the process.