Publishing your first app to the App Store and Google Play

The full picture: what publishing an app actually involves

Many founders assume the work is done once the app runs on their own phone. In reality, publishing is its own phase with its own requirements: official accounts, visual assets, marketing copy, privacy declarations, and both automated and human review from Apple and Google. The good news is that the whole phase can be planned, and most of its problems are predictable.

If you build with Fanann, you get real iOS and Android apps from the same conversation, and you own the full code. But the store steps themselves — accounts, declarations and the listing — remain your responsibility as the publisher. This guide walks you through them one by one.

An app that hasn't shipped hasn't been tested by the real world yet.

Developer accounts: start before you finish building

The first bottleneck in publishing isn't technical, it's administrative. Apple requires enrollment in the Apple Developer Program, and Google requires a Google Play Console account. Both involve fees and verification steps, and both update their terms from time to time, so check each store's current requirements rather than relying on someone's old experience.

1. 1
   Decide: individual or organization account

   An individual account shows your personal name as the publisher. An organization account shows your company name and usually requires documents proving the legal entity and business identifiers. For a commercial product, an organization account builds more trust.

2. 2
   Prepare your documents

   Commercial registration, a clear business address, an email on your company domain, and a reachable phone number. Keeping details consistent across every document saves verification rounds.

3. 3
   Create both accounts in parallel

   Don't wait for one to finish. Verification times vary, and starting early keeps it from delaying your launch.

4. 4
   Add team members with scoped roles

   Both stores support different roles. Give your developer upload rights, your marketer access to the listing only, and keep the owner role yourself.

App identity and visual assets

Before uploading any build, lock down the things that are hard to change later. The most important is the bundle identifier (Bundle ID on iOS, Application ID on Android), a unique string like com.yourcompany.app that cannot be changed after publishing. Choose it carefully and don't tie it to a temporary name.

Asset checklist

• App name: short and clear; it can differ between Arabic and English. Make sure it doesn't conflict with registered trademarks.
• Icon: simple and legible at small sizes, no fine text, in the sizes each store requires.
• Screenshots: for the device sizes each store specifies, ideally with separate Arabic and English sets.
• Feature graphic for Google Play.
• Splash screen consistent with your brand colors.
• Privacy policy URL plus a support link or contact email.

An Arabic store listing that converts and gets found

Your store listing is your app's real landing page. A common mistake in the region is writing it only in English, or machine-translating it into awkward Arabic. Arabic-speaking users notice immediately whether an app was made for them or translated in a hurry — something we cover in depth in our Arabic-first UX guide.

A suggested description structure

1. An opening line that sums up the value in one sentence.
2. 3 to 5 key features phrased as benefits, not technical specs.
3. Who the app is for and when they'd use it.
4. Trust details: support, privacy, payment methods.
5. A clear call to download or try it.

Privacy: apple's labels and google's data safety form

Both stores ask you to disclose what data your app collects and how it's used. On the App Store this appears as privacy labels on your app page; on Google Play it's the Data safety form. Both are declarations you make, and inaccurate ones can lead to rejected updates or other action from the store.

1. 1
   Inventory the data for real

   List everything the app collects: phone number for OTP sign-in, name, location, order history, device identifiers.

2. 2
   Don't forget third-party libraries

   Analytics, push notifications and payment SDKs may collect data too, and you're responsible for disclosing it. Check each library's documentation.

3. 3
   State the purpose of each data type

   App functionality, analytics, advertising, fraud prevention… and whether the data is linked to the user's identity.

4. 4
   Offer a way to delete the account

   If users can create an account, both stores generally expect a clear way to delete it. Check each store's current terms.

5. 5
   Publish a privacy policy that matches

   Any contradiction between the policy, the labels and the app's actual behavior is a red flag for reviewers.

Review and the most common rejection reasons

Every build goes through review before it reaches users. Apple's guidelines are known for their detail on performance, design, privacy and content; Google Play's policies focus heavily on data, permissions and misleading content. You don't need to memorize them, but read the current version of each before your first submission, because they change regularly. Learn more about app store review.

If your app is rejected, don't panic; it happens a lot. Read the reason carefully, fix that specific issue, and reply politely in the resolution center. If you believe the rejection is mistaken, you can clarify or appeal through the official channels.

Beta testing: TestFlight and Google Play tracks

Don't release to the public before real people have tried the app on their own devices. Apple offers TestFlight for distributing beta builds to internal and external testers, and Google Play offers a series of release tracks. Before any of that, run through our quality checklist for AI-generated code.

• Pick testers who resemble your audience: people with older phones, Arabic-only users, and non-technical people.
• Give them concrete tasks — "sign up, order, pay, cancel the order" — rather than "try the app".
• Test payments in a sandbox first, then with a small real transaction before launch.
• Collect feedback in one place and sort it by severity.

Launch and updates: publishing isn't a one-time event

Once approved, you can release immediately or release manually when you're ready. Google Play supports staged rollouts to a percentage of users before expanding, and Apple offers phased release for automatic updates. This gives you a chance to catch problems before they reach everyone.

1. 1
   Version consistently

   A user-facing version number (like 1.2.0) plus a build number that increases with every upload. Both stores reject duplicate build numbers.

2. 2
   Write useful release notes

   "Improvements and fixes" says nothing. Write "You can now pay with Apple Pay" — in Arabic and English.

3. 3
   Watch crashes and ratings

   Both stores' consoles show crashes and stability metrics. Respond to negative reviews kindly and fix the underlying issue.

4. 4
   Have a rollback plan

   Stores don't make it easy to go back to an old build, so make sensitive features switchable from the server, and halt a staged rollout when something breaks.

The final checklist before you hit submit

• Both developer accounts are active and in your or your company's name.
• The bundle ID is final and contains no temporary name.
• Icon and screenshots are in the required sizes, with Arabic and English sets.
• The description is written natively in Arabic and matches the app.
• The privacy policy is published and its link works.
• Privacy labels and the Data safety form match the app's and its libraries' behavior.
• Account deletion is available if users can create an account.
• A demo account is ready for the reviewer, with clear instructions.
• No dead buttons and no "coming soon" pages.
• The build was tested via TestFlight or internal testing on real devices.
• Payments were tested in a sandbox and then with a real transaction.
• There's a staged rollout plan and a kill switch for sensitive features.

If you're still at the idea stage, start with our 7-day idea-to-MVP sprint plan, then come back to this checklist as launch gets close.

Frequently asked questions

Terms in this article