Short answer: publish under developer accounts owned by your business, not your vendor; offer in-app account deletion, which both stores now require for apps with account creation; take booking payments through normal payment methods, since travel is a real-world service and does not use in-app purchase; keep listings, prices and availability truthful; and plan for review time in every release. Most travel-app rejections trace to identity, deletion, payments or misleading content.
Developer accounts: owned by the business
Before a line of code, decide who owns the store presence. The correct answer is always your business, never your development vendor. Apps published under an agency's or freelancer's account are hostage to that relationship: if it sours, you can lose your listing, your reviews and your users' installed update path at once. Enrol your own accounts and grant the vendor team-member access instead.
The practical facts, per the official developer sites at the time of writing: the Apple Developer Program costs 99 US dollars per year, and organisations enrolling as a company need verifiable legal-entity details including a D-U-N-S number. Google Play charges a one-time 25 US dollar registration fee for a developer account, and organisation accounts likewise go through identity and business verification, with the verified developer name and contact details shown publicly on your listings. Budget days to weeks for verification, not hours, and use a company email and payment method, not a founder's personal ones, so the accounts survive staff changes. Both stores publish current fees and enrolment requirements on their developer sites; check them before you plan, as details change.
This ownership rule is one we insist on in our own flight booking app development work: the client owns the accounts, the signing keys and the listing, and we operate inside them.
What Apple's App Review Guidelines expect
Apple's App Review Guidelines are a single public document, and every submitted build is reviewed by Apple against it. For a travel booking app, the themes that matter most are:
- Accuracy and honesty. Your listing, screenshots and in-app content must describe what the app actually does. Fares shown must be obtainable; hidden fees discovered at checkout are treated as deceptive.
- Business identity. An independent agency's app must present itself as that agency. Implying you are an airline, or using carrier branding as your own, invites both rejection and trademark complaints, the same stance we describe for ad landing pages.
- Minimum functionality. An app that is just a website wrapped in a shell, offering nothing beyond the browser experience, is a known rejection theme. The app must feel like an app.
- Privacy. A privacy policy is required, data collection must be declared in the privacy "nutrition label" section of the listing, and permission requests, location, notifications, camera, must explain their purpose.
- Account deletion and payments. Covered in their own sections below.
Read the current guidelines on Apple's developer site before each major release rather than relying on summaries like this one; Apple revises the document regularly and announces changes in its developer news feed.
What Google Play's policies expect
Google Play's rules live in the Play policy centre as a family of policies rather than one document, and enforcement mixes automated checks with human review. For travel apps the load-bearing areas are:
- User Data policy and the Data safety form. You must declare what data the app collects and shares, keep that declaration accurate, and link a privacy policy. Mismatches between declared and observed behaviour are an enforcement trigger.
- Misleading claims and impersonation. Listings must not imply an official airline relationship that does not exist, and prices or offers in the listing must match the app.
- Permissions. Request only the permissions the features need; broad location or storage access without visible purpose attracts review friction.
- Target API level requirements. Play requires apps to target recent Android versions on a published schedule, so an untouched app will eventually be blocked from updates or hidden from new users even if nothing else changed.
- Payments policy and account deletion. Again, see below.
Google publishes policy changes with effective dates in the policy centre; someone on your side, or your vendor under contract, should be subscribed to both stores' announcement feeds.
Account deletion: mandatory on both stores
If your app lets travellers create an account, both stores now require you to let them delete it. Apple's App Review Guidelines (guideline 5.1.1(v)) have required in-app account deletion since mid-2022: users must be able to initiate deletion of the account and its data from within the app, and merely offering deactivation is not enough. Google Play's User Data policy imposes the equivalent requirement, in force since 2024, and adds that you must also provide a web link where users can request account deletion without reinstalling the app, declared in the Data safety form.
For a booking app this needs design work, not just a button: decide how deletion interacts with live bookings, what you retain for legal, tax or fraud-prevention reasons (both stores acknowledge legitimate retention, which your privacy policy should explain), and how deletion propagates to your CRM and back office. Plan this before the first release; it is far easier than retrofitting under a compliance deadline.
Payments scope: bookings are not in-app purchases
The store commission rules that dominate headlines mostly do not apply to travel bookings. Both stores draw the same line: their billing systems (Apple's in-app purchase, Google Play's billing) are for digital goods and services consumed within the app, while physical goods and real-world services, which is what flights, hotels and holidays are, are paid for with ordinary payment methods such as cards, wallets and UPI through your own payment gateway. Apple's App Review Guidelines state this in their payments section, and Google Play's Payments policy makes the same distinction.
| Item in a travel app | Payment route |
|---|---|
| Flights, hotels, packages, transfers, visas | Your own payment gateway: cards, wallets, UPI, bank transfer. Store billing is not used for real-world services. |
| Booking service fees tied to a real-world booking | Your own gateway, alongside the booking payment, disclosed before payment. |
| Digital subscriptions inside the app, e.g. a premium membership unlocking app-only digital features | Store billing rules apply; scope this carefully before promising it. |
| Loyalty points redeemable only against real-world travel | Generally your own systems, but read the current policy text for your exact mechanics. |
The practical consequence is pleasant: your booking flow can use the same gateway and fraud tooling as your website. The trap is edge cases, anything digital-only you sell inside the app changes the analysis, so scope such features against the current policy text rather than assumption.
Common rejection causes for travel apps
- Webview-only apps with no app-grade functionality, the minimum-functionality theme above.
- Missing or fake account deletion, or a deletion flow that only emails support.
- Privacy declaration mismatches: the app sends analytics or location data the store form did not declare.
- Broken demo access. Reviewers must be able to reach every feature; if login requires an OTP to an Indian number, provide working demo credentials in the review notes.
- Placeholder or inaccurate content: lorem ipsum screens, dead menu items, screenshots showing features the build lacks, or fares the reviewer cannot reproduce.
- Trademark complaints from carriers or brands whose names appear in your app name, icon or listing keywords.
- Crashes and unfinished flows on the reviewer's device, still among the most common rejection reasons on both stores.
Almost all of these are avoidable with an internal pre-submission checklist and one honest test pass on a clean device.
Release cadence and staying compliant
Because every iOS release and many Play releases pass through review, release timing is not fully yours. A sustainable pattern for a booking app is a regular update rhythm, monthly or thereabouts, so the app never drifts far from current OS and policy requirements, plus a rehearsed hotfix path: both stores offer mechanisms for expedited or staged releases, and phased rollouts let you catch a bad build at partial exposure. Keep fares, inventory and content server-driven through your API layer so routine business changes never wait on store review at all; that architecture, standard in our white-label travel app builds, is the single biggest reducer of review-queue pain.
Finally, assign ownership. Store compliance is not a launch task but a standing chore: someone must read the policy announcements, keep the privacy forms truthful as features change, and renew the Apple membership before it lapses, because a lapsed membership can remove your app from sale.
This article is general information about travel technology and online marketing. It is not legal, tax or financial advice, and advertising platform policies change often. Check the current policy documents and take professional advice for your own situation.