Publishing an app means three things beyond finishing the code: a verified developer account on each platform, a complete store listing with legally required disclosures, and passing each store's review. Apple's App Store review is a human review against a written rulebook and typically takes a day or two once your submission is complete; Google Play uses a mix of automated and human review with a similar or slightly longer window for a first release. The engineering is usually the easy part — what catches teams out is the paperwork, the assets, and the rejections.

The Stage Nobody Budgets For

Founders plan development time and forget submission time. Realistically, allow two to four weeks between "the app works" and "the app is live" for a first launch: account verification alone can take days, screenshots and copy need writing, a privacy policy needs to exist at a public URL, and the first rejection is close to a rite of passage. Plan it as a project phase, not an afternoon.

What Has to Be Ready Before You Submit

Developer Accounts

Apple's developer program charges an annual fee; Google Play charges a one-time registration fee. Both distinguish individual from organization accounts. If you publish as a company — which you should, so the app is a company asset and not a personal one — expect to verify the legal entity, which for Apple means obtaining a D-U-N-S number for your business, and for Google means providing organization details and, in many cases, a verified contact address and phone number that appear publicly. Start account setup on day one of development, not at the end.

Privacy Policy and Data Disclosures

Both stores require a publicly reachable privacy policy URL, and both require a structured declaration of what data you collect and why — Apple's privacy questions and nutrition-label display, and Google's Data safety form. Apple additionally requires privacy manifests for your app and third-party SDKs, and consent for tracking identifiers. These must match what your code actually does; inconsistencies between your declaration and observed network behavior are a common rejection reason. Analytics SDKs, crash reporters, and ad libraries all count as data collection.

Store Assets and Copy

You will need an app icon at the required resolution, screenshots for each supported device class, an optional preview video, a short and long description, keywords, a support URL, and a marketing URL. Screenshots are the single most influential asset on conversion — treat them as advertising, not documentation.

Age Rating and Content Declaration

Both stores ask a content questionnaire that produces an age rating. Answer accurately; misdeclared ratings get apps pulled after launch, which is far worse than a rejection before it.

Payments

If you sell digital goods or subscriptions inside the app, you generally must use the platform's in-app purchase system and pay its commission, with narrow and shifting exceptions. Physical goods and services consumed outside the app are treated differently. Get this right architecturally before you build a checkout flow, because retrofitting it is expensive.

The Rejections That Happen Most

  • No way for the reviewer to get in. If your app requires a login, you must supply working demo credentials. This is the most common avoidable rejection.
  • Hardware apps with nothing to see. If the app controls a physical device the reviewer does not have, provide a demo mode, a simulator build, a video of it working, or ship them a unit. Bluetooth-dependent apps that show an empty screen get rejected as non-functional.
  • Missing or lazy permission strings. Every permission prompt needs a specific, honest explanation of why you need location, camera, microphone, or Bluetooth. "Required for app functionality" is not enough.
  • Broken or incomplete metadata. Placeholder text, dead support links, screenshots showing features that do not exist.
  • Crashes on launch on the reviewer's device or OS version, often because you only tested current hardware.
  • Health or medical claims. Language implying diagnosis or treatment invites both rejection and regulatory attention — read software as a medical device and whether your product is a medical device before you write that description.
  • Thin apps. A wrapper around a website, or an app with minimal functionality, is explicitly rejected by Apple's guidelines.

A rejection is not a verdict. You get a written reason, you fix it, and you resubmit — often the same day.

Use the Testing Tracks First

Both platforms give you a staging path, and skipping it is a mistake. Apple's TestFlight distributes builds to internal and external testers, with external groups going through a lighter review. Google Play offers internal, closed, and open testing tracks, and requires a period of closed testing before production for some account types. Beyond catching bugs, these tracks let you validate the whole submission pipeline — signing, provisioning, entitlements — well before launch day.

When you do release, both stores support phased or staged rollout to a percentage of users. Use it. A crash discovered at five percent of installs is a bad afternoon; the same crash at a hundred percent is a bad review score you keep.

Your Store Page Is a Sales Page

Ranking and conversion depend on the listing itself: a title and subtitle carrying the terms people actually search, a first screenshot that communicates the value in one glance, a first line of description that survives the "more" truncation, and a steady flow of ratings. Prompt for reviews at a moment of success in the app, never on first launch, and respond to negative reviews — both stores show your replies publicly.

After Publication

Publishing starts an ongoing obligation. Both platforms periodically raise the minimum SDK level or toolchain version required for new submissions, so an app that ships and is never touched again eventually cannot be updated at all. Add to that OS releases that break behavior, deprecated APIs, and privacy rule changes. Budget maintenance as a recurring line item.

For hardware-connected apps there is an extra layer: the app version and the device firmware version have to stay compatible, because users update on their own schedule. Design a version-negotiation scheme and an OTA firmware update path from the start, and see what a BLE app costs to develop for the connected-product specifics.

If you are still earlier than this — choosing a stack or sizing the budget — start with native vs cross-platform development and mobile app development cost. Connected products also need a backend decision; see MQTT vs HTTP for IoT. More guides live in our app development hub.

Have an app that is finished but not published, or a device app you want reviewed successfully the first time? Contact Projects House and we will take it through submission and launch.