What holds an app back at launch is usually not a hard engineering problem. It is a clause that has been published in the store rules for years and nobody read until changing course became expensive: an account-deletion web page that was never built, a permission that needs a declaration form and an approval before release, a revenue model that collides with the store's own billing system.
The decision to build a mobile app starts with these rules in practice, not with the choice of framework. None of them are secret, and most of them change the shape of the product itself rather than the way you upload it. Below are eight decisions those published texts force on you, ordered by the moment each one has to be settled, with what it costs to settle it late. Every clause was read on Apple's or Google's own page on 21 September 2026.
What you will not find here: cost ranges, delivery timelines and technology choice. Each has its own page, linked where it belongs. The upload mechanics themselves (opening accounts, preparing assets, code signing) are in the guide to publishing on the App Store and Google Play.
1. Which legal entity opens the developer account
This is the first decision and the most neglected, because it looks administrative. For Apple it is an explicit review clause: the App Review Guidelines state in 5.1.1(ix) that apps providing services in highly regulated fields, among them banking and financial services, healthcare, air travel and crypto exchanges, should be submitted by the legal entity that provides the service and not by an individual developer. A clinic, an insurer or a wallet app registered under the developer's own name enters review through the wrong door.
Correcting it later is not free. Apple's page on signing and updating agreements says a change of legal entity name and address may require supporting business documentation, and that approved changes can take up to two weeks to appear in App Store Connect. Two more lines on the same page stop work without warning: the Paid Apps Agreement is signed by the Account Holder alone, and you cannot create a new app or a new in-app purchase until the most recent version of that agreement has been accepted.
In practice: settle the entity and the account roles before anyone opens anything. If the Account Holder is an employee or a contractor, you depend on their signature every time the agreement changes.
2. Does your app need accounts at all
Whether a first release needs logins is a scoping question we covered in deciding what goes into the first version. What matters here is what follows from a yes. Apple's 5.1.1(v) ties the two together directly: an app that supports account creation must also offer account deletion within the app.
Google's requirement is wider. The Google Play User Data policy asks for a deletion route people can find without hunting, both inside the app and outside it, through a web resource whose link goes into a dedicated field in Play Console. Deleting an account has to take the data attached to it along with it, and suspending or freezing an account does not count.
This is where the real effect on your database begins, and no requirements checklist shows it. A store or a booking app in Egypt or Saudi Arabia cannot erase the tax invoices tied to a user who asked to be deleted, because keeping those records is an obligation of its own, described in connecting your system to Egyptian e-invoicing and in phase two of Saudi e-invoicing. Google addresses the case explicitly: where records have to be kept for a legitimate reason such as fraud prevention or a regulatory obligation, users must be told about that retention in plain terms, and the privacy policy is the place to say it.
So "delete my account" in your design is two operations: separating the user's identity from the records you are required to keep, then deleting everything else. Anyone who models the tables assuming every row hangs off the user record discovers the problem on the day the first deletion path is written, long after the data has accumulated. On the obligations themselves, see protecting customer data in Egypt and Saudi Arabia.
3. How people sign in
Once the app needs accounts, the sign-in method carries a published Apple condition that is often discovered late. Guideline 4.8 covers any app that leans on a third-party or social sign-in service, Google Sign-In and Facebook Login among them, to create or verify the account a person uses to identify themselves inside it. Such an app has to place an equivalent option beside that service: a sign-in method that takes nothing beyond a name and an email address, lets the person keep that address private, and does not harvest their activity in the app for advertising without consent.
That clause also lists cases where no second service is required, and three of them matter here: the app uses only the company's own account and sign-in systems; it is an education, enterprise or business app where the user signs in with an existing organisational account; or it authenticates people through a citizen identification scheme run by a government, or an industry-backed electronic ID. That third case is what makes signing in with Nafath in Saudi Arabia a different path from social login, and we covered when it is actually required in verifying user identity in Saudi apps.
There is also a regional trap worth stopping on. Many apps want to read the verification code out of the SMS automatically so the user does not have to type it. The Google Play policy on sensitive permissions makes that close to impossible for an ordinary business app: the SMS permission group is limited to the app actively registered as the device's default SMS, Phone or Assistant handler, and apps without that capability may not declare those permissions in the manifest at all, including as placeholder text. The alternative Google names on the same page is the SMS Retriever API. A small line in a requirements sheet, and it decides both your verification screen and the way your server composes the message.
4. Which permissions open a second review
Some permissions in Play Console are not simply requested and forgotten; asking for them opens a declaration form and a review before release. From the same policy page:
- Photos and video: apps targeting Android 13 or later may only request
READ_MEDIA_IMAGESandREAD_MEDIA_VIDEOif system pickers such as the Android Photo Picker are not sufficient for core functionality, and those that still request them must submit a Play Console declaration explaining why the picker would not do. - Background location: Google states plainly that it may reject apps requesting background location without compelling justification, and that the request needs its own Console declaration.
- All files access:
MANAGE_EXTERNAL_STORAGErequires passing an access review prior to publishing, not merely declaring it in the manifest.
Apple pushes the same way from the design side. Guideline 5.1.1(iii) asks you to request only the data your core functionality needs, and to reach first for the system picker that runs outside your process, or for a share sheet, rather than full access to protected resources such as Photos or Contacts.
One condition concerns the order of your screens rather than the code. Google requires a prominent in-app disclosure before the permission request, explaining what is collected and how it is used. It must appear in normal use of the app rather than behind a menu or settings screen, and it cannot live only in the privacy policy or the terms. Consent has to be an affirmative action: navigating away or pressing back is not consent, and auto-dismissing messages do not count.
One rule sums up the section: every feature that touches sensitive data adds a form, a review and a disclosure screen, not just a line of code. Decide the permission list while you are deciding the features of the first release, not after building them.
Snaabble provides a tailored technical assessment to define the right stack & exact budget.
5. Notifications are not a guaranteed channel
Plenty of plans assume the notification will arrive. Android's notification runtime permission documentation says otherwise: from Android 13 (API level 33), posting notifications requires the POST_NOTIFICATIONS runtime permission, and when someone installs your app on a device running that version or later, your notifications are disabled by default until the app asks and the user grants it.
Apple adds two limits on what you can build on top of that channel. Guideline 4.5.4 rules out an app that only works when push is switched on, and it treats promotional and direct-marketing pushes as something a customer opts into explicitly, through consent wording shown in your own interface, with a way to opt back out from inside the app. Guideline 5.1.2(i) goes further: access to a feature, to content, to the app itself, or to any reward including gift cards and codes, cannot be made conditional on someone switching on push, location or tracking.
In design terms: every message that must not be lost needs a second channel, whether an in-app inbox or an SMS or WhatsApp order confirmation, and you need a screen that explains the permission before you ask for it instead of firing the prompt on first launch.
6. Arabic and layout direction are build decisions, not a finishing touch
Teams serving Egypt and the Gulf tend to treat "Arabic support" as a translation task near the end. Direction is not translation.
On Android, the android:supportsRtl attribute defaults to false, and the right-to-left APIs are only activated when it is set to true and targetSdkVersion is 17 or higher. While it stays false, layouts behave the same regardless of the language the user picked.
On Apple's side, the right-to-left interface guidelines note that system frameworks flip their own components automatically, so an interface built from standard elements may need little change. Three points on that page work as a checklist for any Arabic interface:
- Do not reverse the order of digits inside a specific number. Phone numbers and card numbers keep the same order whatever the interface language.
- A paragraph, defined as three lines or more, is aligned according to its own language rather than the direction of the interface, because right-aligning an English paragraph hides the start of every line.
- Arabic text looks small beside Latin text set in capitals, since Arabic has no capitals; increasing it by about two points restores the balance.
One more point for anyone serving several Arab countries: Apple notes that Arabic may use Western or Eastern Arabic numerals, and that this varies between countries and regions and even within the same country. Numeral style is a per-market decision, not one switch for the whole app.
Small details are what actually break a layout. Android's documentation on supporting languages gives examples of text that renders incorrectly once it is inserted into a translated message, among them text starting with a number such as an address or a phone number, and text starting with punctuation such as an international dialling code. Those are exactly the fields that fill any orders or bookings app in this region.
7. The payment channel decides the whole revenue model
The rule itself is simple and its effect on the business case is not. Apple's 3.1.1 requires in-app purchase for unlocking features or content inside the app, and rules out your own mechanisms for doing it, such as licence keys or QR codes. Guideline 3.1.3(e) says the opposite for anyone selling physical goods or services consumed outside the app: those must be collected through a payment method other than in-app purchase.
Subscription businesses are usually caught out by the Google Play payments policy. The prohibition is not limited to an obvious payment button. Among the routes it rules out, the policy names one in particular:
in-app user interface flows, including account creation or sign-up flows, that lead users from an app to a payment method other than Google Play's billing system
The familiar "sign up here, then finish the subscription on our website" path is written into the text itself. Alternative billing and leading users out of the app are available only in eligible countries and only for developers enrolled in the applicable programme.
Separate the two cases before you build the checkout screen, because each implies a different system for invoices, refunds and support. The rates themselves and their effect on pricing are in the guide to mobile app cost in Egypt and the guide for Saudi Arabia.
8. Age rating and target audience
This is the most recent change, and it affects anyone submitting an update this month. Apple revised its age rating system, adding 13+, 16+ and 18+ to the existing 4+ and 9+, along with new questionnaire items covering in-app controls, capabilities, medical or wellness topics and violent themes. In a July 2026 update Apple added questions about an app's social media capabilities and confirmed that responses have been required since September 2026 when submitting new apps or updates.
On Google's side, the age rating requirements impose a questionnaire on new apps, on existing apps without a rating, and on every update that changes content or features in a way that affects the answers. The ratings themselves are issued by independent bodies through the IARC coalition, and Google states that misrepresenting an app's content can lead to removal or suspension. Your target-audience choice pulls in further policies: if it includes children, the Google Play Families policy applies, including the requirement to use self-certified ad SDKs.
The practical conclusion for anyone building an app with user-generated content, chat or an AI assistant: rating is a design question settled early, because the answer can force reporting tools, in-app controls and a minimum age into the product.
The order of the decisions and the cost of deferring each
| Decision | What forces it | When to settle it | Cost of deferring |
|---|---|---|---|
| Legal entity and Account Holder | Apple 5.1.1(ix) and the Paid Apps Agreement | Before any account is opened | Entity changes take up to two weeks after approval, and a standing dependency on one person's signature |
| Whether accounts exist, and deletion | Apple 5.1.1(v) and Play's User Data policy | With the data model | Rebuilding tables and a deletion path that separates identity from mandatory records |
| Sign-in method | Apple 4.8 and Play's SMS permission policy | With the sign-in screens | Adding a second login provider after launch, or rebuilding the verification screen |
| Permissions and sensitive data | Play's sensitive permissions policy and Apple 5.1.1(iii) | While scoping the first release | Declaration forms and reviews before release, plus disclosure screens that were never designed |
| Notifications | Android 13+ and Apple 4.5.4, 5.1.2(i) | With the user journey | Messages that never arrive, and a fallback channel built in a hurry |
| Arabic and layout direction | supportsRtl and Apple's RTL guidelines | With the first screen built | Reviewing every screen after it is finished |
| Payment channel | Apple 3.1.1 and 3.1.3(e), Play payments policy | Before the business case | Changing the revenue model after billing and refunds are built |
| Age rating and audience | Apple's and IARC's questionnaires | Before building open-content features | Blocked update submissions, and controls added later |
What remains for submission day: a live privacy policy link that matches what the app actually does, reviewer credentials with the backend switched on (or a built-in demo mode with Apple's prior approval, per guideline 2.1(a)), the privacy declarations on both stores, and the account-deletion URL in Play Console. Google requires the privacy policy to sit on an active, publicly accessible, non-geofenced URL, not a PDF and not an editable page, and to name the entity shown on the store listing. That stage is covered in the publishing guide, and the annual obligations that follow it in mobile app maintenance costs.
Read these pages yourself before you sign off on a scope. Their text changes, and the verification date above belongs to one particular day. If you are about to build a mobile app and want these decisions reviewed against your own case, put the idea in front of the Snaabble team on the mobile app development page, and within 24 hours you will have an initial view of the scope with an estimate of time and cost, at no charge and with nothing owed.
Sources
- App Review Guidelines, Apple, sections 2.1, 3.1.1, 3.1.3(e), 4.5.4, 4.8, 5.1.1 and 5.1.2.
- Sign and update agreements, App Store Connect Help.
- Right to left, Human Interface Guidelines.
- Updated age ratings in App Store Connect and Age rating questionnaire now includes social media questions, Apple Developer News.
- User Data, Permissions and APIs that Access Sensitive Information, Payments and age rating requirements, Google Play policies.
- Notification runtime permission, the
<application>element and supporting different languages and cultures, Android Developers.
