App Development
Native iOS and Android app development
Native development builds your app in each platform’s own language, Swift for iOS and Kotlin for Android, giving maximum performance, full hardware access and the feel users expect. It is the right call when the app is the product.
Who it is for: Products that need heavy graphics, deep hardware integration or the smoothest possible experience, where cross-platform compromises would show.
Everything in this service
- iOS development in Swift, Android in Kotlin
- UI built to each platform’s design conventions
- Device integration: camera, location, notifications, sensors
- App Store and Google Play submission handled
- Crash reporting and analytics from launch
What to expect
- An app with the speed and feel users expect from the platform
- Full access to device capabilities, nothing blocked by a framework
- A clean store launch, not a rejection loop
How native app development actually works
When native is genuinely worth the extra cost
Native means building separately for each platform, in the language and tools that platform provides. It costs more than a shared codebase, and for a large share of business apps that extra cost buys very little. Being clear about where it does pay off is more useful than defending it in general.
Native earns its cost when performance is the product. Games and anything with continuous rendering. Camera and video applications doing real-time processing. Audio tools where latency is the whole point. Augmented reality. Apps handling large volumes of data on the device with heavy computation. In these cases a shared framework adds a layer between your code and the hardware, and that layer shows up as dropped frames or delay in exactly the moments users judge you on.
It also earns its cost when you need platform capabilities early. New system features arrive in native tools first, and cross-platform frameworks follow at their own pace. If your product depends on a capability announced this year, native is often the only way to ship this year. The same applies to deep system integration: widgets, watch apps, background processing, complex notification behaviour, health and payment frameworks. Some of these are reachable from cross-platform code through custom bridging, but once a project needs several of those bridges written and maintained, the saving that justified the shared codebase has been spent.
- Continuous rendering, real-time media and low-latency audio favour native
- Deep system integration and early access to new features favour native
- Typical forms, lists, content and commerce apps rarely need it
- If several native bridges are required, the shared-codebase saving is gone
- Decide from the feature list, not from a general preference
Platform differences that are more than skin deep
iOS and Android differ in ways that go well beyond visual style, and a team that treats one as a repaint of the other produces an app that feels wrong on at least one platform.
Movement between screens is the clearest example. Android has a system back gesture and, historically, a back button, with an expectation that it retraces steps consistently across the whole system. iOS relies on a back control within the screen and an edge swipe. Designing one model and forcing it onto both leaves one set of users doing something that feels unnatural. Permissions differ too: the timing of prompts, how they are worded, what happens on refusal, and whether the user can be asked again. Notification behaviour, background execution limits and battery management rules also differ substantially, and Android adds manufacturer-specific behaviour on top.
Then there is device variety. iOS covers a manageable set of screen sizes and a population that updates quickly. Android spans thousands of device models, a wide range of screen shapes and processor speeds, and a much longer tail of older versions still in active use. That changes testing, and it changes what performance target is realistic. Design conventions differ as well, from typography and control styles to where primary actions sit, and users notice the mismatch even when they cannot name it. An app should feel like it belongs on the device it is running on.
- Respect each platform model for moving between screens
- Handle permission prompts, refusals and re-requests per platform
- Expect different notification and background execution rules
- Plan Android testing across a wide range of devices and versions
- Follow each platform design conventions rather than one shared look
Hardware and operating system integration
The reason many products are apps rather than websites is access to the device itself. That access is the advantage, and it comes with rules.
The common integrations are camera and photo library, location including the difference between while-in-use and background access, biometric authentication, secure storage for credentials, push notifications, contacts and calendar, Bluetooth and other device connectivity, motion sensors, and platform payment systems. Each has a permission model, each requires a clear explanation to the user, and each behaves differently when permission is refused. That refusal path is the one teams skip. An app that becomes unusable because someone declined a permission it did not truly need is a poor app, and the fix is to ask only when the feature is used and to explain why in the moment.
Battery and background behaviour deserve particular care. Both platforms restrict what an app can do when it is not in the foreground, and those restrictions have tightened over the years. Continuous location tracking, frequent background updates and long-running tasks are constrained by design, and an app that fights those constraints drains batteries, gets throttled by the system, and attracts complaints. Design around the platform intent rather than trying to defeat it. On privacy, both stores require disclosure of what data is collected and why, and those declarations are checked at review and must stay accurate as the app changes.
- Request permissions at the moment of use, with a plain reason
- Design a working experience for every permission that is refused
- Keep credentials in platform secure storage, never in plain preferences
- Respect background execution limits instead of working around them
- Keep privacy declarations accurate as the app evolves
Store review: what it checks and how to avoid a loop
Both stores review submissions before they go live, and the review is a real gate rather than a formality. Apple review is generally the stricter and slower of the two, though both can reject. Planning for review from the first design meeting is far cheaper than discovering a problem after the app is built.
The recurring rejection reasons are predictable. An app that offers too little function to justify existing as an app, which most often affects apps that are really a wrapper around a website. Broken features or crashes found during review, usually because testing was done on the newest device only. Missing or incorrect privacy disclosures. Account requirements without a way for the reviewer to sign in. Digital goods sold outside the platform payment system, which is a common and expensive surprise. Permission requests without a clear explanation. Placeholder content or unfinished screens left in the build. Metadata problems, including screenshots that do not reflect the current app.
Practical steps help. Read the current guidelines for anything unusual in your app before building it, since a design that cannot be approved is worth knowing about in week one. Provide a working demo account and clear reviewer notes. Test the app fresh from install, as a reviewer will, rather than on a development device carrying existing state. Expect the first submission to take longer than later ones. If rejected, read the reason carefully and respond to it specifically, because guessing produces the rejection loop that costs weeks.
- Check the guidelines for anything unusual before building it
- Supply a working demo account and reviewer notes
- Test from a clean install on more than the newest device
- Sell digital goods through platform payments unless an exception applies
- Answer a rejection specifically, do not resubmit and hope
Release cadence and the fact that users stay on old versions
Web releases are simple: publish and everyone has it. Apps are not. A release has to be built, submitted, reviewed and then downloaded by each user, and a meaningful share of users will be running an old version for a long time.
That has design consequences. Any server your app talks to has to keep working for older versions, so interfaces need to be versioned and changed additively rather than replaced. A bug in a released version stays in the field until users update, so a hotfix is a submission plus a review plus adoption time. Both stores allow phased rollout, releasing to a percentage of users first, and it is worth using, because a serious problem caught at a small percentage is a very different event from one that reached everyone.
Cadence itself is a judgement. A steady rhythm of small releases is usually better than rare large ones: less risk per release, faster feedback, and stores tend to favour actively maintained apps. But every release costs review time and asks users to update, so weekly releases for a small app are usually more disruption than value. Monthly is a reasonable default for most products, with the ability to ship an urgent fix outside that rhythm. Whatever the cadence, use remote configuration for anything you might need to switch off quickly, since a setting you can change server-side avoids a submission entirely, and monitor adoption so you know how much of your user base a given fix has actually reached.
- Version your server interfaces and change them additively
- Use phased rollout so a bad release reaches few users
- A steady monthly rhythm suits most products better than rare big releases
- Keep risky features behind remote switches you control server-side
- Track version adoption, it tells you who still has the old bug
Launching on one platform first
Building both platforms natively means two codebases, two testing efforts and two ongoing maintenance commitments. Launching on one first is often the better commercial decision, and it is rarely offered as an option.
The case for it is straightforward. You halve the cost and time to get something real in front of users, and almost everything you learn from that first release, about what people use, what confuses them and what was never needed, applies to the second platform. Building both at once means paying twice for assumptions that have not been tested yet.
The choice of platform should come from your own data rather than general market share. Look at what devices your web visitors and existing customers use, since that is your audience rather than the population. Consider where your customers are, because the platform split varies substantially by country. Consider revenue behaviour if the app monetises directly. Then be honest about the cost of the second platform. If it is definitely coming, some architectural choices are worth making now, particularly on the server side, so the second build is not starting from nothing. And if the answer to that analysis is that you need both immediately with a modest budget, that is usually the point where cross-platform becomes the sensible recommendation instead.
- Use your own audience data, not general market share
- Platform split varies by country, check the markets you sell in
- Learning from the first platform reduces waste on the second
- Design the server side for both even if only one ships first
- Needing both at once on a modest budget usually points to cross-platform
A clear path, step by step
- 01
Define version one
The smallest app that proves the product, scoped tightly so it actually ships.
- 02
Design for the platform
Screens that follow Apple and Google conventions, so the app feels native, not ported.
- 03
Build and test
Short cycles with builds on your own device throughout, tested on real hardware.
- 04
Ship and support
Store submission managed, then monitoring and a release rhythm after launch.
Why choose us for this
We say honestly when cross-platform would serve you better and cheaper
Store guidelines considered from the first design, not at submission
You see working builds throughout, never a black box
Common questions
When is native worth the extra cost over cross-platform?
When performance, graphics or deep hardware use define the product: games, camera-heavy apps, real-time tools. For typical business apps, cross-platform delivers 95 percent of the experience at well under the cost of two native builds.
Do I need both iOS and Android at launch?
Often not. Launching on the platform where most of your audience lives lets you learn cheaply before doubling the surface area. We help you read your audience data and decide.
Explore related work
Want this for your business?
Book a free visibility call and I will tell you honestly whether I can help.
How this is delivered
One person leads every project. Where a job genuinely needs a specialist, I bring in people I have worked with before and manage them, so you get one point of contact and one invoice rather than three suppliers blaming each other.
- You talk to the person responsible for the work, not an account manager
- Specialists are briefed and managed by me, and their work is checked before it reaches you
- One contract, one invoice, one place to chase