Softomate Solutions is a mobile app development company based in London helping UK businesses build apps for iOS and Android. One question comes up in almost every initial call: should we build for iPhone first, Android first, or both at once? The answer is not the same for every business, and anyone who tells you it is has not thought carefully about your specific market, budget, or users. This guide gives you the data and the decision framework to make the right call.
In the UK, iOS and Android are almost evenly split. As of mid-2024, Android holds approximately 50 per cent of the smartphone market and iOS holds approximately 49 per cent, with the remaining fraction split across other platforms. This near-parity is unusual by global standards: worldwide, Android commands roughly 72 per cent of the market. The UK split reflects a stronger iPhone presence than most European countries and significantly stronger than emerging markets where Android dominates at 85 to 90 per cent.
Statcounter data for the UK consistently shows iOS edging above Android in web browsing traffic, which suggests iPhone users are more active online than the raw device numbers imply. This matters for businesses whose apps drive users toward a web-based service or whose revenue depends on in-app engagement rather than passive installation counts.
The near-parity means that launching on one platform first leaves roughly half the UK smartphone market unable to use your app at launch. For many businesses, this is an acceptable trade-off during early development. For others, it is not. Understanding which half of the market your actual customers occupy is the most important input to this decision.
UK demographic data consistently shows that iOS users skew toward higher household incomes, urban locations, and younger age groups. A 2023 YouGov survey found that 60 per cent of UK adults in professional or managerial roles primarily use an iPhone, compared with 42 per cent across all adults. London and the South East have the highest iOS penetration in the UK, with some inner-London demographics showing iOS shares above 65 per cent.
Android users span a broader demographic range. Android is particularly strong among adults aged 35 to 54, users in the Midlands and Northern England, and households with incomes below the national median. This is not a universal truth: premium Android devices from Samsung, Google Pixel, and OnePlus attract technically engaged, higher-income users who are distinctly different from the budget-Android demographic.
What this means practically: if your app targets corporate professionals in London, a legal services firm's client portal, a management consultancy's tool, or a financial planning application, your user base is likely majority-iOS. If your app targets a broad consumer audience across all UK regions and income levels, both platforms are essential from launch. If your app targets skilled tradespeople, blue-collar workers, or regional small businesses, Android parity matters more than you might assume.
Platform choice should follow user research, not assumption. Before making the decision, examine the device split in your existing customer data, run a device survey if you have an audience already, or look at your website analytics and filter by operating system. The answer is usually in your data, not in general market statistics.
Developing a native iOS app uses Swift, Apple's modern programming language, with Xcode as the development environment. Developing a native Android app uses Kotlin (the modern choice) or Java (older but still widely used) with Android Studio. Neither is inherently cheaper than the other when priced by development time from a skilled London agency. The day rate for a senior iOS developer in London typically runs from ยฃ550 to ยฃ900. A senior Android developer commands similar rates, ยฃ500 to ยฃ850 per day.
Where costs genuinely diverge is in the complexity of device testing. Apple's iOS ecosystem is relatively contained: a handful of current iPhone models, a predictable range of screen sizes, and strong OS adoption rates. Most iPhone users upgrade to the latest iOS within a few months of release. Android's ecosystem is fragmented: hundreds of different device manufacturers, screen sizes ranging from 4.7 to 7 inches, display ratios that vary considerably, and OS adoption spread across multiple versions simultaneously. In the UK, Android 13 and 14 together account for roughly 70 per cent of active Android devices, but 30 per cent of UK Android users are on older versions that may not support newer APIs.
Device fragmentation makes thorough Android testing more expensive. A proper Android QA process requires testing on a representative sample of devices, either using physical test devices or a service such as BrowserStack or Firebase Test Lab, which add ยฃ300 to ยฃ1,000 per month to running costs. iOS testing on a representative device set is significantly simpler and cheaper.
If you use a cross-platform framework such as React Native or Flutter, a single codebase runs on both platforms. This reduces total development cost by 30 to 50 per cent compared to building two separate native apps, though it does not eliminate the Android testing overhead entirely. We cover this trade-off in detail in our companion post on React Native vs Flutter for UK app development.
For mobile app development projects with defined budgets, a cross-platform first approach often makes sense precisely because it allows simultaneous iOS and Android coverage without doubling the development cost.
Apple App Store and Google Play Store have meaningfully different submission and review processes, policies, and economic models. Understanding these differences affects your launch timeline planning, ongoing maintenance budget, and revenue projections.
Apple's App Store review process is manual and typically takes one to three business days, though it can extend to a week during high-volume periods such as immediately after a major iOS release. Apple's reviewers check apps against their App Store Review Guidelines, which are detailed and regularly updated. Common rejection reasons include: apps that crash or contain obvious bugs, apps that collect data not disclosed in the privacy manifest, apps with confusing or misleading descriptions, and apps that improperly implement in-app purchases. First submissions have a higher rejection rate than updates. Budgeting two to three review cycles into your launch timeline is prudent.
Google Play's review process is largely automated with human review for flagged apps. Initial reviews typically complete within a day, making Google Play faster for initial submission. However, Google Play also conducts ongoing post-publication scans of live apps, and policy violations discovered after an app is live can result in suspension without warning. Google's policies on permissions, data collection, and advertising have tightened significantly since 2022.
Account costs differ: Apple charges ยฃ99 per year for the Apple Developer Programme. Google charges a one-time fee of approximately ยฃ20 for a Google Play Developer account. Both platforms now require developers to provide accurate Data Safety and App Privacy information disclosing exactly what data the app collects and how it is used. This is not optional and is a significant source of rejection or removal for apps that were not designed with data transparency in mind from the start.
UK businesses handling personal data must comply with UK GDPR regardless of platform. Both stores now enforce their own data transparency requirements that align with but do not fully replicate UK GDPR obligations. Having a proper privacy policy, a data deletion mechanism for apps with user accounts, and accurate data collection disclosures is required before either store will publish your app.
Both Apple and Google take a 30 per cent commission on in-app purchases and subscriptions in their respective stores. This applies to digital goods, subscriptions to in-app content, and app downloads themselves. Physical goods, services delivered outside the app, and business-to-business transactions processed through external payment systems are exempt.
Apple reduced its commission to 15 per cent for developers earning less than $1,000,000 per year through the App Store Small Business Programme, which covers the vast majority of UK app businesses. Google has matched this with a similar 15 per cent rate on the first $1,000,000 of annual earnings per developer.
The practical implication for UK businesses: if your app's primary revenue comes from in-app subscriptions, such as fitness apps, productivity tools, or educational content, you need to factor the 15 to 30 per cent platform commission into your unit economics. A subscription priced at ยฃ9.99 per month generates approximately ยฃ8.49 after Apple or Google takes their cut. For apps with thin margins or significant content costs, this commission is a material business consideration, not a footnote.
Businesses that can deliver their core service through a web application and use the mobile app primarily as a client interface can in some cases avoid in-app purchase requirements entirely, routing transactions through their own payment processor. Stripe, for example, charges 1.4 per cent plus 20p for European cards in the UK. This is a legitimate and common approach, though it requires careful implementation to comply with both stores' policies about external payment promotion within the app itself.
Push notifications behave meaningfully differently on iOS and Android, and these differences affect engagement strategies significantly.
On iOS, users must explicitly grant permission for an app to send push notifications. The opt-in prompt appears once and cannot be re-triggered after a user declines. iOS push notification opt-in rates in the UK average around 50 to 60 per cent for consumer apps, depending heavily on how and when the permission request is shown. Apps that request permission immediately on first launch have significantly lower opt-in rates than those that first demonstrate value and then request permission in context.
On Android, push notification permission was historically granted by default. Since Android 13, Google requires explicit user consent before sending notifications, bringing Android closer to iOS in this respect. However, Android's notification system gives users much more granular control and the default opt-in rate on Android remains somewhat higher than on iOS for most app categories.
For apps where push notifications are central to the user experience, such as news apps, delivery tracking, or banking alerts, the notification permission conversation is a material part of the UX design process. A skilled UX team will design the notification permission flow as deliberately as any other screen, which is why UX design investment is rarely separable from technical development investment.
Several sectors consistently find that building for iOS first is the right strategic decision, given the demographic profile of their customers.
B2B enterprise apps are the clearest iOS-first case. Corporate IT procurement in the UK heavily favours Apple devices: iPhone is the default corporate handset for most professional services firms, financial institutions, law firms, and large retailers. If your app is a sales tool, a field service app for professional staff, or a workflow tool for corporate teams, your users are overwhelmingly likely to be on iPhone. Building for iOS first gets your app to the decision-makers fastest.
Financial services and fintech apps serve a London-centric, higher-income demographic that skews strongly iOS. Wealth management, investment, and premium banking apps consistently report iOS shares of 65 to 75 per cent among their UK users.
Premium consumer brands, luxury hospitality, and high-end retail apps similarly skew iOS. If your brand's customer profile matches the higher-income, urban demographic, iOS first is rarely the wrong call.
Healthcare apps used by clinical staff are an interesting exception: NHS trusts are mixed between iOS and Android, and some NHS-deployed devices run Android. Consumer health and wellness apps aimed at the general public need both platforms.
Android-first makes sense when your customer base is explicitly broader. Consumer apps targeting all UK adults, utility apps for tradespeople or delivery drivers, local business apps, and anything aimed at the 35 to 54 demographic outside major cities should give Android parity equal priority.
Building for both platforms simultaneously using a cross-platform framework is the practical answer for most UK businesses that cannot afford to wait. React Native and Flutter allow a single team to maintain a shared codebase that runs on both iOS and Android. The investment is higher than building for one platform alone, but typically 30 to 50 per cent less than two separate native builds. For businesses with a broad audience and a defined budget, this is usually the most sensible path.
The only situation where starting with both simultaneously creates a meaningful risk is when you are uncertain whether the app concept will resonate with users at all. In that scenario, launching an iOS-only MVP to your most likely customer demographic, learning quickly, and then expanding to Android based on validated demand is a defensible risk management approach. The important thing is that the decision is driven by validated user data about your audience, not by a general preference for one platform over the other.
Our mobile app development service includes platform strategy as part of the discovery phase. We look at your audience data, budget, and business objectives before recommending a platform approach, and we build the technical case for whatever path makes most sense for your specific situation.
Cross-platform frameworks, principally React Native maintained by Meta and Flutter maintained by Google, have matured significantly since 2020. Both now deliver performance and user experience that is genuinely close to native for the majority of business app use cases.
React Native translates JavaScript components into native UI elements, meaning the rendered interface uses actual iOS and Android components rather than a web view. Flutter renders its own pixels using the Impeller graphics engine on iOS and Skia on Android, giving it a consistent visual experience across platforms that is independent of native UI changes.
For UK businesses that want to reach both iOS and Android users without committing the budget for two separate native builds, cross-platform development delivers the most pragmatic answer. The caveats are real but manageable: some device-specific hardware integrations require additional native code, performance in graphics-intensive or animation-heavy scenarios may lag slightly behind pure native, and the platform-specific UX conventions require deliberate attention to avoid apps that feel generically cross-platform rather than naturally at home on each device.
For most business applications, productivity tools, e-commerce apps, booking platforms, and customer portals, these caveats are minor compared to the cost and timeline advantages. For high-performance games, augmented reality applications, or apps that push the boundaries of device hardware, native development remains the stronger technical choice.
The full comparison of React Native and Flutter as specific framework choices is covered in our post on React Native vs Flutter for UK app development.
In the UK, iOS and Android have near-equal market share, each holding approximately 49 to 50 per cent of the smartphone market. This is significantly different from the global picture where Android commands around 72 per cent. iOS has slightly stronger representation in London, among higher-income demographics, and in professional roles. Android is stronger in the Midlands and North, among 35 to 54 year olds, and among lower-income demographics. Neither platform dominates in a way that makes a unilateral platform decision straightforward for consumer-facing UK apps.
A native iOS app built by a London agency typically costs ยฃ25,000 to ยฃ120,000 depending on complexity. Simple apps with limited functionality and no custom backend sit at the lower end. Apps with user accounts, payment processing, third-party integrations, and custom UI design sit at the upper end. Development timelines run from three to eight months for most business applications. These costs cover design, development, testing, and App Store submission but not ongoing maintenance, which typically costs an additional 15 to 25 per cent of the build cost annually.
For a UK startup MVP, iOS first is the more common choice for several reasons. iOS has a slightly higher-income, more urban user base that is often the most accessible early adopter market. App Store submission is predictable and review times are consistent. TestFlight provides an excellent closed testing mechanism. Building iOS-only for an MVP also reduces initial development cost, allowing more of the budget to go toward validating the core idea before committing to Android. Once the concept is validated, adding Android via cross-platform development is a well-trodden path.
The Apple App Store uses a manual review process taking one to three business days. It is stricter on privacy disclosures, in-app purchase compliance, and design quality. Developers pay ยฃ99 per year. The Google Play Store uses largely automated review completing within a day but monitors apps post-publication. Both stores now require explicit notification permission since Android 13, data safety declarations, and a data deletion mechanism for apps with user accounts. Apple takes a 15 per cent commission on most sales (30 per cent above $1M revenue); Google matches this structure.
For the majority of UK business applications, yes. React Native and Flutter have closed the quality gap with native development to the point where most users cannot distinguish a well-built cross-platform app from a native one in normal use. The gap remains meaningful for graphics-intensive applications, augmented reality, and apps that need deep hardware integration. For business tools, e-commerce, booking, productivity, and customer-facing applications, a well-built cross-platform app meets user expectations on both iOS and Android without the cost of two separate native builds.
More from the blog
Let us help
Talk to our London-based team about how we can build the AI software, automation, or bespoke development tailored to your needs.
Softomate Solutions Limited
Deen Dayal Yadav
Online
