What It Actually Takes to Get a New App Onto the App Store in 2026

Most founders plan for the build. The launch date usually slips somewhere else: an enrollment waiting on a D-U-N-S number, a closed test that cannot be shortened, a rejection over a missing account deletion flow, or a payment button that is allowed in one country and grounds for rejection in another.

This guide is for founders and product owners who assume that once the app is built, it ships. Building it is real work: design, a backend, an API, mobile clients, QA, and a lot of iteration. But that is the part teams budget for. Below is the work that sits between a finished build and a live listing on the App Store and Google Play, verified against Apple and Google documentation as of October 2026.

1. Developer Accounts: Start Before You Write Code

Account setup is the most predictable delay and the easiest to avoid. Start it the week you decide to build.

Apple Developer Program

You can enroll as an individual or an organization. If you enroll as an individual, your personal legal name appears as the seller on the App Store. Most companies want the company name there, which means enrolling as an organization. Organization enrollment requires:

• A legal entity, such as a corporation or LLC. Apple does not accept DBAs, trade names, branches, or sole proprietorships.
• A D-U-N-S number for that entity. Getting one is free, but Apple says to allow up to five business days for Dun & Bradstreet to issue it and up to two more business days for Apple to receive it.
• A person with legal authority to bind the company, using a work email on the company's domain.
• A public, working website on that same domain. Social media pages do not count.
• The $99 annual membership fee.

If the company's legal name or address does not match its D&B record, fix the record first. That mismatch is a common reason enrollment stalls.

Google Play Console

Google charges a one-time $25 registration fee and verifies every developer's identity. Organization accounts need a D-U-N-S number, a government ID, an official organization document, and a website. Google warns that getting a D-U-N-S number can take up to 30 days, so do not assume Apple's one-week estimate applies here. Google also publishes developer contact details on your store listing. Organizations show their legal name, address, email, and phone number, so decide which address and phone number you want public.

The Google Play closed testing requirement

This one catches teams that set up a personal account to move fast. Personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in continuously for 14 days before they can apply for production access. Google then reviews that application, which it says usually takes seven days or less. Organization accounts are not subject to this rule.

Put plainly: a new personal Play account cannot ship to the public in less than about three weeks, however finished the app is. If you are a company, register as one.

2. App Review and Play Policy: The Rejections That Catch New Apps

Apple and Google review every new app. Most first-submission rejections are not about code quality. They come from a short list of avoidable problems.

Incomplete apps and broken review access

Apple's App Review Guidelines (2.1(a)) expect a final build with "fully functional URLs" and no placeholder text or temporary content. Apple also asks you to "include demo account info (and turn on your back-end service!)." In practice:

• Give reviewers a working demo account that does not expire, with realistic data already loaded.
• Keep the production backend live and stable for the whole review window. A review that hits a down API or an empty account is a rejection.
• If your app has two-factor authentication or one-time passcodes, give credentials that bypass them. Google Play asks for the same thing and requires access details that stay valid, are reusable, work from any location, and are in English.
• Check every link in the app and the listing, including the privacy policy, terms, and support pages.
• Explain new or non-obvious features in the Notes for Review. Apple's guideline 2.3.1(a) says generic descriptions will be rejected.
• Make in-app purchases visible and functional to the reviewer. Guideline 2.1(b) requires them to be complete and testable.

"It's just a website"

Guideline 4.2 (Minimum Functionality) rejects apps that are "a repackaged website" or are not "particularly useful, unique, or 'app-like.'" A thin web view around your existing product is the most common way to hit this. Google Play's spam policy covers the same ground with its "Webviews and Affiliate Spam" rules. If the mobile app is a wrapper today, add something native that matters: offline access, push notifications tied to real events, device features, or a workflow that is clearly better on a phone.

Spam, copycats, and saturated categories

Guideline 4.3 rejects multiple Bundle IDs of the same app and apps that are not meaningfully different from what is already widely available. Apple names dating, flashlight, sound effect, wallpaper, simple timer, and fortune-telling apps as categories it will not accept without a unique experience. This also catches agencies and white-label products that ship near-identical apps for each client. Plan for a single app with per-customer configuration, or be ready to show real differences.

Apple updated its guidelines on October 16, 2026, adding guideline 2.5.19 aimed at bait-and-switch apps and hidden or undocumented features. Whatever the reviewer sees should be what users get.

How long review takes

Apple says it reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours. Expedited review is available for critical bug fixes and apps tied to a time-sensitive event, but it is not a launch-planning tool. Google says review for some accounts can take up to seven days or longer in exceptional cases. The real time cost is the rejection loop: fix, resubmit, and wait again. Budget for at least one round trip on each platform.

3. Privacy Disclosures You Have to Get Right

Both stores ask you to disclose what data your app collects. Both treat inaccurate disclosures as a policy violation, not a paperwork error.

• Privacy policy. Both Apple and Google require a privacy policy link in the store listing and inside the app. Google requires this even if your app accesses no personal data. The URL has to be public and working.
• App Store privacy details. App Store Connect asks what data you collect, whether it is linked to the user, and whether it is used for tracking. This covers data collected by third-party SDKs too: analytics, crash reporting, attribution, ads, and support chat.
• Google Play Data safety. Every app must complete a Data safety form. It should match your App Store answers and your privacy policy, because reviewers and users compare them.
• Privacy manifests and required-reason APIs. iOS apps must declare why they use certain system APIs in a privacy manifest file (PrivacyInfo.xcprivacy). Apple automatically rejects uploads that use these APIs without a declared reason. Apple also keeps a list of commonly used third-party SDKs that must ship their own privacy manifest and signature. The list includes Firebase, the Facebook SDK, Google Sign-In, Flutter, Capacitor, Cordova, React Native's Hermes engine, and OneSignal. An outdated SDK version is enough to block an upload.
• Account deletion. Under guideline 5.1.1(v), "If your app supports account creation, you must also offer account deletion within the app." Google Play goes further: it requires an in-app path and a web page where users can request deletion without reinstalling the app. Deletion has to actually remove the account and its data, so this is backend work, not just a button.

4. Sign-In Rules

If your app's primary account option is a third-party or social login such as Google, Facebook, or LinkedIn, Apple's guideline 4.8 requires you to also offer an equivalent login option. That option has to limit data collection to the user's name and email, let users keep their email address private, and not collect app interactions for advertising without consent. Sign in with Apple meets all three, and that is what most teams add.

The rule does not apply if you only use your own email and password accounts. It also does not apply to education or enterprise accounts, government-backed ID systems, or apps that are clients for a specific third-party service. If you do add Sign in with Apple, plan for users who hide their email. Apple will give you a relay address, so support and billing flows cannot rely on matching a real email.

5. Payments: Where Most Business Models Get Rejected

Payment rules are the area most likely to force a product change late in the process. What you sell determines which rules apply.

Digital goods vs. physical goods and services

• Digital goods and features (subscriptions, premium content, unlocking features, in-app currency) must use Apple's In-App Purchase under guideline 3.1.1. On Android they must use Google Play Billing unless you enroll in an alternative program.
• Physical goods and services consumed outside the app (marketplaces, rides, food delivery, appointments, retail) must not use In-App Purchase under guideline 3.1.3(e). Use Stripe, Apple Pay, or another processor. Google Play Billing is likewise not required for physical goods or services.
• Exceptions exist for reader apps (content bought elsewhere and consumed in the app), multiplatform services, enterprise sales, and real-time one-to-one services between two people, such as tutoring or consultations. One-to-many live classes still need In-App Purchase on iOS.

External payment links depend on the storefront

The rules for linking users to your website to pay are different in each market, and they changed again in 2026:

Market	Apple App Store	Google Play
United States	Buttons and links to external purchases are allowed without an entitlement or commission. The courts have said Apple may eventually charge a cost-based fee, and the Supreme Court agreed in June 2026 to hear part of the case.	External links and alternative billing are allowed, but you must enroll in Google's program. Service fees on those transactions began October 1, 2026.
European Union	Since October 1, 2026, a single set of EU terms allows link-outs and alternative in-app payment. Commission applies: 15% on link-out sales within 7 days of the tap (10% for small businesses), versus 26% (15%) for In-App Purchase.	Alternative billing options are available, with enrollment.
Most other countries	In-App Purchase is required for digital goods, and steering users to outside payment is prohibited. Japan and South Korea have their own alternative rules.	Google Play Billing is required unless you enroll in an available program.

The practical risk is one codebase that shows a "Subscribe on our website" button everywhere. That is fine on the US storefront, allowed under specific terms in the EU, and grounds for rejection in most other countries. If your pricing model depends on web checkout, build the purchase flow to be storefront-aware from the start, and treat US fees as subject to change while the litigation continues. Sources: Apple's EU terms, Google's Payments policy, and Google's US program changes.

6. Platform and SDK Minimums

Both stores set minimum build requirements, and both raise them every year. An older toolchain, or a cross-platform framework that has not caught up, can block an upload outright.

• Apple: since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK (or the matching iPadOS, tvOS, visionOS, or watchOS SDK). Apple typically raises the minimum each spring.
• Google: since August 31, 2026, new apps and updates must target Android 16 (API level 36). Extensions were available to November 1, 2026. Wear OS, Android TV, and Automotive have lower targets.
• Android App Bundles: new Play apps must be published as App Bundles, which means Google holds the app signing key through Play App Signing. Back up your upload key and know who controls the Play Console.
• 16 KB page size: if your Android app includes native code, including from libraries or game engines, it must support 16 KB memory page sizes. Google says updates that do not will be blocked starting February 1, 2027.

7. Age Ratings and Age-Verification Laws

Age requirements went from a quick questionnaire to a real engineering item in the last year.

• Apple's new age ratings. Apple's ratings are now 4+, 9+, 13+, 16+, and 18+, replacing the old 12+ and 17+ tiers. The questionnaire asks about in-app controls, capabilities, medical and wellness topics, and violent themes. Since September 2026 it also asks about social media features, meaning feeds or other ways of amplifying user-generated content. Apps with those features get a Social Media descriptor on their product page. Answers are required for new apps and every update.
• Google Play content rating. Play requires a completed content rating questionnaire before an app can be published.
• Texas. The Texas App Store Accountability Act applies to new Apple accounts in Texas as of June 4, 2026. It requires age assurance and parental consent for minors' downloads, purchases, and significant app changes. Apple expects developers to use its Declared Age Range API, report significant changes through PermissionKit, and handle consent withdrawals. Google offers the Play Age Signals API for the same purpose. Court challenges are ongoing, but the law is in effect now.
• Other states. Utah and Louisiana have passed similar laws, which have since been pushed back to 2027. California's Digital Age Assurance Act takes effect January 1, 2027 and requires operating systems to pass apps an age bracket. If your app serves a general audience in the US, expect age signals to become a standard part of onboarding.

8. Compliance Odds and Ends

• Export compliance. Every iOS submission asks about encryption. Most apps that only use standard HTTPS through the operating system qualify for an exemption. Set the ITSAppUsesNonExemptEncryption key in your Info.plist so you are not answering the question on every build. If you use proprietary or non-standard encryption, Apple requires documentation, and France has its own declaration requirements. See Apple's export compliance guide.
• EU trader status. Under the EU Digital Services Act, Apple requires every developer to declare whether they are a trader. Since February 2025, apps without a declaration have been removed from EU storefronts. Traders must publish an address, phone number, and email on the product page, so have a business address and support line you are comfortable showing.
• Content rights. If the app uses third-party trademarks, licensed content, music, sports data, celebrity images, or another company's brand, be ready to show you have the rights. Both stores remove or reject apps over intellectual property complaints, and reviewers can ask for proof.

9. Store Listing Assets

Listing assets look like marketing work, but missing or wrong-sized assets block submission just as reliably as a crash.

• Apple screenshots. App Store Connect now requires iPhone screenshots at the medium Dynamic Island size (for example 1179 × 2556), plus 13-inch iPad screenshots if the app runs on iPad. You can upload 1 to 10 per size. Apple has also announced that starting in April 2027, apps built with the iOS 27.1 SDK or later must include iPhone Duo screenshots captured on the device or simulator.
• Apple text. The app name and subtitle are limited to 30 characters each and the keyword field to 100 bytes. The description can run to 4,000 characters. A support URL with real contact information is required.
• Google Play. You need a 512 × 512 icon, a 1024 × 500 feature graphic, and two to eight screenshots per device type. The title is limited to 30 characters, the short description to 80, and the full description to 4,000. See Google's asset requirements.
• Consistency. The listing has to describe the app the reviewer sees. Screenshots of features that are not in the build, or claims you cannot back up, are a metadata rejection under guideline 2.3.

A Realistic Launch Timeline

Assuming the app is finished and works, here is the time the non-code work adds:

Item	Typical lead time	Start
D-U-N-S number and Apple organization enrollment	1–2 weeks	At project kickoff
Google Play organization verification	Days to several weeks (D-U-N-S can take up to 30 days)	At project kickoff
Google Play closed test (personal accounts only)	14 days plus up to 7 days for the production access review	As soon as a testable build exists
Privacy policy, Data safety, privacy details, account deletion	1–2 weeks including legal review	Mid-build
Store listing assets and copy	1 week	Once the UI is stable
App Review and Play review	1–7 days per submission	Final build
One rejection and resubmission	2–7 days	Plan for it

None of these is hard on its own. They delay launch when they are discovered in the last week, one after another.

Pre-Submission Checklist

• Apple and Google accounts are enrolled under the company's legal entity, with D-U-N-S numbers matching the legal name and address
• The Google Play closed test is complete, if you are on a personal account
• The build uses Xcode 26 and the iOS 26 SDK, targets Android API 36, and supports 16 KB pages if it has native code
• Every third-party SDK is on a version that includes the required privacy manifest
• App Store privacy details, the Play Data safety form, and the privacy policy describe the same data practices
• The privacy policy, terms, and support URLs are public and working, and linked in the app and the listings
• Users can delete their account from inside the app, and Android users can also request deletion from a web page
• Sign in with Apple or an equivalent option is offered if social login is the primary option
• Purchase flows follow the rules for each storefront: In-App Purchase or Play Billing for digital goods, your own processor for physical goods and services
• In-app purchases and subscriptions are configured, submitted, and visible to reviewers
• Age rating questionnaires are complete, including Apple's social media questions, and age-assurance APIs are in place if you serve Texas users
• Export compliance is declared in Info.plist and EU trader status is set in App Store Connect
• You hold the rights to all third-party content and branding in the app
• Screenshots, icons, feature graphic, and copy meet each store's current specs and show the actual app
• A non-expiring demo account with realistic data, plus Notes for Review explaining key features and how to test them
• The production backend is live, monitored, and not scheduled for changes during review

Ship the App, Not Just the Build

Launch delays rarely come from the code. They come from accounts, disclosures, payment design, and store requirements that nobody owned until the final week. Teams that start those items at kickoff ship on the date they planned.

Cavanex builds products for startups and growing companies, from the cloud infrastructure and backend to the platform and the launch itself. We handle store accounts, review readiness, privacy and payment requirements, and the rejection loop alongside the engineering, so launch day is the day you planned. If you have an app close to the finish line, or one about to start, tell us what you're building.