iOS, where the review process is part of the project
iOS development builds apps for iPhone and iPad. The hardware range is narrow and predictable, which simplifies engineering. What is not simple is App Store review: Apple enforces policies on privacy, account handling and payments that reject apps which would ship without comment elsewhere.
iOS reverses Android's difficulty. Devices are few and consistent, so performance is predictable and testing is tractable. The cost moves to the gate: every release passes through human review against guidelines that are enforced, and the rejections that surprise teams are almost always about policy rather than quality.
Teams treat submission as the last administrative step and discover it is a requirements document they never read. Apps that let users create accounts must offer account deletion within the app. Digital goods and subscriptions generally have to use Apple's in-app purchase, with its commission, rather than your own payment provider. Privacy declarations must accurately describe what is collected, including by third-party SDKs the team did not audit. And tracking users across apps requires permission most people decline.
When this work makes sense
Questions worth asking any supplier
Do you sell digital goods or subscriptions? If so, Apple's in-app purchase and commission likely apply.
Do users create accounts? Then in-app account deletion is required, not optional.
What do your third-party SDKs collect? Your privacy declaration must cover them, and most teams have not checked.
Do you need cross-app tracking? Permission is required and most users decline it.
Is a progressive web app sufficient? It avoids review entirely, at the cost of store presence.
Deliverables
The app, native in Swift or cross-platform, chosen against your requirements
App Store review requirements addressed during development rather than at submission
Privacy manifest and nutrition label accurately covering your SDKs
In-app account deletion where accounts exist
Payment approach determined correctly, in-app purchase or external, per Apple's rules
TestFlight distribution for stakeholder and beta testing
Submission handling including responses to review queries
Crash reporting and analytics
Built with
Process
Review requirements are treated as a specification at the start of the project, not a checklist at the end. We work through the guidelines that apply to your category, account deletion, payment handling, privacy declarations, permission usage descriptions, and build to them. Rejections are expensive not because appeals are hard but because they arrive when the launch date is already set, and most are avoidable weeks earlier.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Native Swift, cross-platform, or web
Native Swift
Fits: Performance-critical apps and deep Apple ecosystem integration
Limits: iOS only; Android is a separate build and skill set
Cross-platform
Fits: Standard interfaces needing both platforms from one codebase
Limits: Platform-specific work remains; some Apple features need native bridging
Progressive web app
Fits: Content and tools where store presence is not required
Limits: No App Store listing; some capabilities, notably around notifications, are more constrained
Case studies
No published iOS case study.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Why do App Store submissions get rejected?
Most commonly for incomplete functionality at review, missing account deletion, privacy declarations that do not match actual behaviour, using an external payment method where in-app purchase is required, or permission usage descriptions that do not explain why access is needed. Nearly all are avoidable by treating the guidelines as requirements.
Do we have to use Apple's payment system?
For digital goods and subscriptions consumed in the app, generally yes, with the commission that implies. Physical goods and services delivered outside the app are different. The rules have shifted with regulatory pressure in several regions, so it is worth checking current guidance for your category rather than relying on what was true last year.
Swift or React Native?
Cross-platform if you need both stores and the interface is conventional. Native Swift for performance-critical work or deep platform integration. Native also tends to track new iOS features sooner, which matters if you rely on them.
How long does review take?
Usually short, often within a day or two, and it is not guaranteed and not always predictable. Plan for a rejection cycle rather than assuming first-time approval, particularly on a first submission where unfamiliar requirements surface.
What is App Tracking Transparency?
Apple requires explicit permission before tracking users across other companies' apps and websites. Most users decline. If your acquisition model depends on that tracking, the practical effect is significant and worth understanding before you build around it.
Do we need to support older iPhones?
Less far back than on Android. Apple's adoption of new versions is fast and the device range is narrow, so supporting the current and previous major version covers most users. Check your analytics rather than assuming.
Can we distribute without the App Store?
For internal enterprise apps, yes through Apple's enterprise programme. For consumer distribution the store is the route in most regions, though regulatory changes in some markets have begun opening alternatives. It is not a general-purpose escape from review.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.