On this page
In short
- Enroll the Apple Developer Program and Google Play Console accounts as your organization, with a D-U-N-S number, and give developers roles rather than the account holder's sign-in.
- Keep signing keys, certificates and store access under company control, and write down who holds each one.
- Make the privacy disclosures match what the app and every SDK in it collect, and let users who can create an account delete it.
- Plan for app review: an app that only wraps your website can be rejected, and reviewers need a demo account to get past sign-in.
- Release in stages, keep a way to pause a rollout, and give someone ownership of the yearly platform and policy updates.
What changes when the app is public
An internal app can be installed through your device management and changed whenever IT likes. A public app lives in two stores you don't control, under rules that change, in front of customers who judge the company by it. Settle these decisions before development starts, because some of them take weeks.
Decisions to make early, and who makes them
Which legal entity publishes the app
- Who decides
- Legal, finance and IT
- Why it needs to be early
- Enrollment needs the entity's D-U-N-S number and someone who can bind it; verification can take time
Who holds the store accounts and signing keys
- Who decides
- IT
- Why it needs to be early
- Moving an app between accounts later is possible but has conditions and paperwork
What data the app collects and why
- Who decides
- The business owner, legal and IT
- Why it needs to be early
- Privacy disclosures and the privacy policy must match it before submission
How customers sign in and delete their accounts
- Who decides
- IT and the business owner
- Why it needs to be early
- Both stores expect a deletion path when users can create accounts
Who owns the app after launch
- Who decides
- IT and the business owner
- Why it needs to be early
- Platform and policy updates arrive each year whether or not features change
| Decision | Who decides | Why it needs to be early |
|---|---|---|
| Which legal entity publishes the app | Legal, finance and IT | Enrollment needs the entity's D-U-N-S number and someone who can bind it; verification can take time |
| Who holds the store accounts and signing keys | IT | Moving an app between accounts later is possible but has conditions and paperwork |
| What data the app collects and why | The business owner, legal and IT | Privacy disclosures and the privacy policy must match it before submission |
| How customers sign in and delete their accounts | IT and the business owner | Both stores expect a deletion path when users can create accounts |
| Who owns the app after launch | IT and the business owner | Platform and policy updates arrive each year whether or not features change |
Developer accounts in the company's name
- Apple Developer Program as an organization. As of 2026, Apple asks organizations to enroll with the legal entity name, a D-U-N-S number, a public website and a person with the legal authority to bind the organization, and charges an annual membership fee. Check Apple's current enrollment page before you start.
- Google Play Console as an organization. As of 2026, Google asks organization accounts for a D-U-N-S number and verifies the organization's details. New personal accounts created after November 13, 2023 must run a closed test with at least 12 testers for 14 days before publishing to production; Google applies that requirement to personal accounts, which is one more reason to enroll as the company.
- A company-controlled sign-in. The account holder's sign-in uses a company email address that IT controls, with multi-factor authentication and recovery options IT can reach if the person leaves.
- Roles, not shared passwords. Developers, testers and agencies are invited to App Store Connect and Play Console with the narrowest role that lets them do their work, and removed when the work ends.
- Not the agency's account. Publishing from a contractor's account puts the listing, reviews and update path in someone else's hands. Both stores support transferring an app between accounts, with conditions, but it's simpler to start in your own.
Privacy disclosures, account deletion and the listing
Both stores ask you to describe what the app collects before it can be published, and they expect the description to be accurate. Treat it as a small review between the developers, the business owner and legal, not a form someone fills in on release day.
What the stores ask for, as of 2026 (check each store's current requirements)
Data collection disclosure
- Apple App Store
- App Privacy details on the product page
- Google Play
- The Data safety section
Privacy policy
- Apple App Store
- A privacy policy link is required
- Google Play
- A privacy policy link is required
Account deletion
- Apple App Store
- Apps that support account creation must let users start account deletion from within the app
- Google Play
- Apps that let users create an account must offer deletion in the app and through a web link
Third-party SDKs
- Apple App Store
- Privacy manifests are required for SDKs on Apple's list of commonly used SDKs
- Google Play
- SDK data collection counts toward the Data safety answers
Age rating
- Apple App Store
- An age rating questionnaire
- Google Play
- A content rating questionnaire
Public contact details
- Apple App Store
- In the EU, trader status under the Digital Services Act, with a trader's address, phone number and email shown on the product page
- Google Play
- A developer email address and phone number shown on the developer profile for organization accounts; check Play Console for any EU-specific requirements
| Item | Apple App Store | Google Play |
|---|---|---|
| Data collection disclosure | App Privacy details on the product page | The Data safety section |
| Privacy policy | A privacy policy link is required | A privacy policy link is required |
| Account deletion | Apps that support account creation must let users start account deletion from within the app | Apps that let users create an account must offer deletion in the app and through a web link |
| Third-party SDKs | Privacy manifests are required for SDKs on Apple's list of commonly used SDKs | SDK data collection counts toward the Data safety answers |
| Age rating | An age rating questionnaire | A content rating questionnaire |
| Public contact details | In the EU, trader status under the Digital Services Act, with a trader's address, phone number and email shown on the product page | A developer email address and phone number shown on the developer profile for organization accounts; check Play Console for any EU-specific requirements |
- Every SDK counts. Analytics, crash reporting and push notification libraries collect data too. List every SDK in the app and what it sends before filling in the disclosures.
- Export compliance questions. App Store Connect asks whether the app uses encryption, for US export rules. Apps that use only standard HTTPS may qualify for an exemption; confirm the answer with whoever handles export compliance at your company.
- Deletion that actually deletes. Account deletion needs a back-end process with a record of what was removed and what is kept for legal reasons, not just a button that signs the user out.
App review: what trips up company apps
Rules that catch out company apps (from Apple's App Review Guidelines and store policies, as of 2026)
A wrapped website
- What the rule says
- Apple's guideline 4.2 expects features, content and interface beyond a repackaged website
- What to do
- Build around jobs that need the phone, such as the camera, notifications, scanning or offline use; otherwise a mobile website may be the better choice
Reviewers can't sign in
- What the rule says
- Apple's guideline 2.1 asks for demo account details for apps with a sign-in; a built-in demo mode is accepted only with Apple's prior approval
- What to do
- Keep a demo account with realistic data in a non-production environment the review build can reach
Social sign-in
- What the rule says
- Apple's guideline 4.8 asks apps that use a third-party social login to also offer an equivalent login option with stated privacy features, such as Sign in with Apple; an app that uses only your company's own account system is exempt
- What to do
- Decide the sign-in options before design
Selling digital content
- What the rule says
- Both stores have in-app payment rules for digital goods and subscriptions
- What to do
- Get advice on current payment rules before planning any sales in the app; physical goods and services follow different rules
Incomplete disclosures
- What the rule says
- Store listings and privacy answers must match the app's behavior
- What to do
- Review the disclosures with each release that adds an SDK or collects new data
| Issue | What the rule says | What to do |
|---|---|---|
| A wrapped website | Apple's guideline 4.2 expects features, content and interface beyond a repackaged website | Build around jobs that need the phone, such as the camera, notifications, scanning or offline use; otherwise a mobile website may be the better choice |
| Reviewers can't sign in | Apple's guideline 2.1 asks for demo account details for apps with a sign-in; a built-in demo mode is accepted only with Apple's prior approval | Keep a demo account with realistic data in a non-production environment the review build can reach |
| Social sign-in | Apple's guideline 4.8 asks apps that use a third-party social login to also offer an equivalent login option with stated privacy features, such as Sign in with Apple; an app that uses only your company's own account system is exempt | Decide the sign-in options before design |
| Selling digital content | Both stores have in-app payment rules for digital goods and subscriptions | Get advice on current payment rules before planning any sales in the app; physical goods and services follow different rules |
| Incomplete disclosures | Store listings and privacy answers must match the app's behavior | Review the disclosures with each release that adds an SDK or collects new data |
Build review time and a possible rejection into the launch plan, and don't announce a launch date before the first approval. TestFlight and Google Play's testing tracks let a group of customers try the app before it is public.
What the app and its back end need
- Jobs that fit a phone. Product registration by scanning a serial label, service requests with photos, manuals and spec sheets that work offline, and notices when a request changes status are good candidates. Order entry and pricing belong in the systems that own them.
- Native or cross-platform. A native iOS app in Swift, or an iPhone and Android app from one React Native codebase, depending on the device features and the team that will maintain it. Our guide to PWA, native or cross-platform for a staff app covers the trade-offs, which apply to customer apps too.
- Customer sign-in. Customers shouldn't sign in through your workforce directory. A customer identity service such as Amazon Cognito, with multi-factor options and a deletion path, keeps them separate. Our guide to customer and dealer portals covers identity for outside users.
- An API you control. The app talks to your own API, which reads from your systems through the access their owners agree to. Business rules live there, so fixing one doesn't wait for a store review.
- Notifications people agree to. iOS asks users for permission before showing notifications, and Android 13 and later do too. Ask at the moment the notice is useful, such as after a service request is raised.
- Security testing before launch. Our guide to security testing a custom web or mobile app before launch covers automated checks and planning an independent penetration test.
Releases, staged rollouts and the yearly cycle
- A build pipeline produces signed builds from the company's repository, so a release doesn't depend on one developer's laptop.
- Testers get the build first through TestFlight or a Google Play testing track.
- The release is submitted with updated notes and any changed privacy answers.
- The rollout is staged. Apple's phased release spreads an update over seven days for users with automatic updates, and Google Play's staged rollout sends it to a percentage of users; both can be paused.
- Crashes and reviews are watched during the rollout, and the rollout is paused if something is wrong while a fix goes through review.
company app / repository to staged releasediagram
The store accounts, keys and repository belong to the company. The developer is a guest with a role.
- Platform updates. Apple sets minimum Xcode and SDK versions for App Store submissions and raises them over time, and Google Play raises the Android API level that new apps and updates must target each year (from August 31, 2026, Android 16, API level 36, for most apps). An app nobody updates can stop being offered to new users on newer Android versions, and can't ship an update until it meets the current requirement.
- Policy updates. Both stores revise their guidelines and disclosure forms. Someone reads the notices sent to the account holder and decides what needs to change.
- A support plan. Our guide to what a proper software handover should include covers access, monitoring and support options.
A mobile website, a template app platform or a custom app
Routes to a customer-facing app (check current features, licensing and whose account publishes the app)
A mobile-friendly website
- Where it fits
- Customers look things up and fill in forms, without needing the camera, offline use or notifications
- What to check
- Whether a store listing adds anything; a website avoids review and store upkeep
A template app platform
- Where it fits
- The app is mostly content, catalogs or forms the platform already supports
- What to check
- Whose account publishes the app, what happens to the listing if you leave the platform, and whether it reaches your systems
A custom native or React Native app
- Where it fits
- Jobs that need device features, your own sign-in, or links to your systems
- What to check
- Ownership of the code, the accounts and the keys, who maintains the API, and yearly update costs
| Route | Where it fits | What to check |
|---|---|---|
| A mobile-friendly website | Customers look things up and fill in forms, without needing the camera, offline use or notifications | Whether a store listing adds anything; a website avoids review and store upkeep |
| A template app platform | The app is mostly content, catalogs or forms the platform already supports | Whose account publishes the app, what happens to the listing if you leave the platform, and whether it reaches your systems |
| A custom native or React Native app | Jobs that need device features, your own sign-in, or links to your systems | Ownership of the code, the accounts and the keys, who maintains the API, and yearly update costs |
Whichever route you take, the groundwork carries over: accounts in the company's name, keys and access that IT controls, disclosures that match the app, and a named owner for updates after launch.
Planning an app your customers will download?
Bring a note on who the app is for, the two or three jobs it has to do, and which systems it needs to read from. On a scoping call we'll talk through the accounts, sign-in, disclosures, releases and what a fixed-price first version would cover.
Questions to settle before you publish
Take this to IT, legal, marketing and the business owner
- Which legal entity publishes the app, does it have a D-U-N-S number, and who can bind it?
- Who is the account holder at Apple and Google, and which company email address do they use?
- Which roles will developers and agencies get, and who removes them when the work ends?
- Where are the signing keys and certificates, and who can use them?
- What data does the app and every SDK in it collect, and who approves the privacy disclosures?
- How do customers sign in, and how do they delete their accounts?
- Which demo account will reviewers use, and what data does it show?
- Who owns platform and policy updates after launch, and how are they paid for?
If the problem isn't written down yet, our project brief builder asks eight short questions and turns the answers into a one-page brief you can share with IT, legal and marketing before a call.
Our experience includes native iOS apps in Swift, SwiftUI and UIKit, cross-platform apps in React Native, push notification systems, OAuth and OIDC sign-in with AWS Cognito, and CI/CD with GitHub Actions. Our experience also includes audio and video streaming apps with 200,000+ active users (experience, not client work). See mobile app development for what we build, and how we work for the fixed-price process.
Sources
- Apple: enrollment, App Review Guidelines, App Privacy details, third-party SDK requirements, age ratings, EU Digital Services Act trader requirements, export compliance, app transfer, phased release, TestFlight and upcoming requirements
- Google Play: account requirements, testing requirements for new personal accounts, developer contact information, Play App Signing, Data safety section, account deletion, content ratings, app transfers, staged rollouts and target API level
- Notification runtime permission (Android Developers)
See it applied
- Illustrative sample. Not client work.See a sample scope for an internal tool →An invented request and approval portal that replaces a spreadsheet and email, on an existing SQL Server database with the company's existing single sign-on.
- Illustrative sample. Not client work.See a sample handover package →The handover index for an invented plant-floor dashboard: repositories, infrastructure as code, the pipeline, runbooks, a data dictionary, the credential handover list, alerts, known limitations and sign-off.
Share this guide
Related services
- Mobile app development Native iOS apps in Swift and iPhone-and-Android apps from one React Native codebase, published under your accounts.
- Web application development The APIs, admin screens and mobile-friendly websites a customer app depends on.
- AWS cloud & DevOps Customer sign-in with Cognito, hosting for the app's API and build pipelines in your own AWS account.