Cross platform is the right call more often than purists admit, and the wrong call more often than vendors admit. We tell you which side your product sits on before you pay for the build.
Running separate iPhone and Android teams means every feature is specified twice, built twice, tested twice and released out of step. The Android version trails by a few sprints. The bug fixed on iPhone is still open on the other side. Product decisions get made twice by two sets of people who then disagree about them. For a lot of business apps that expense buys very little, because the product is mostly lists, forms and network calls.
Shared codebases do well on products dominated by lists, forms, content and API calls, which describes most internal tools and a fair number of customer apps. They do badly where the interaction is the product: heavy custom animation, sustained camera or sensor work, deep ties to platform specific hardware. So we build the riskiest screen first, on a real handset, and let the result decide. That takes days and settles an argument that otherwise runs for months.
The way hybrid goes wrong is a codebase so full of platform conditionals that it is two apps sharing a directory with extra steps in between. Business logic stays genuinely shared. Platform differences sit behind small interfaces. Native modules get written in Swift or Kotlin at the exact point the shared layer runs out. Navigation and gestures follow each platform rather than splitting the difference, since that is the first thing a user notices. On release, changes that do not touch native code can go out over the air inside the store rules, and we are clear from the start about which changes qualify and which still need a submission.
The question every board asks about cross-platform is what happens if the framework falls out of favour, and it is aimed at the wrong target. Frameworks do change, but the cost of moving is not decided by which one you picked. It is decided by where your business rules ended up. Rules written in plain, framework-agnostic code, with the shared layer confined to presentation and platform access, mean a future migration is a rewrite of the outer shell while the part that encodes how your company actually works stays put. Rules threaded through framework-specific idioms mean you have married it, and the divorce is the whole product. This costs almost nothing to get right at the start and is close to unaffordable to correct later, which is why it is a structural decision made in week one rather than a refactor promised for later.
Shared frameworks move faster than the platforms beneath them, because they have to absorb both platforms' annual changes and their own. That makes upgrades a rhythm rather than an event, and the failure mode is entirely predictable: a team busy shipping features defers one upgrade, which makes the next one bigger, which makes it easier to defer again. Two years later the app is several major versions behind, some dependencies have no supported path forward, and a small feature request turns out to require a migration nobody budgeted for. Kept current, these are routine afternoons. Left alone, they compound into the single most common reason a cross-platform app gets declared unmaintainable and rebuilt: which is then blamed on the technology rather than on the deferral.
One codebase, one backlog, one team covering iPhone and Android. The screens, the business rules and the API layer are written once, which is the bulk of the work.
Where the product is screens over an API, a browser version comes largely free and needs no install. Where it depends on device hardware, it is a different product and we say so.
Your riskiest screen built first on a real handset. Days of work to settle a decision that otherwise gets argued in the abstract for months.
Swift or Kotlin written at the precise point the shared layer runs out, kept small and well-bounded so the hiring requirement stays narrow.
Kept on a schedule while they are still small. This is the maintenance that decides whether year three is a routine afternoon or a rebuild.
Codebases that became two apps in one folder, or that fell several major versions behind. Untangling the conditionals is usually cheaper than starting again.
Every product has one part that is the real test: the camera flow, the map with hundreds of pins, the offline sync, the animation somebody is attached to.
On a real device, before the full build is agreed. If it performs, the rest is lists and forms. If it does not, you learned it for the cost of days.
Business rules in plain framework-agnostic code, platform differences behind small interfaces. Costs nothing now, close to unaffordable to retrofit.
Navigation, gestures and pickers follow each platform rather than splitting the difference. This is what users notice, not rendering performance.
Two store processes, tested on both platforms, with a clear line drawn from day one between changes that can go over the air and changes that need a submission.
Every feature specified twice, built twice, released out of step. For an app that is mostly lists, forms and network calls, that expense buys very little.
The classic symptom of split teams. Bugs fixed on one platform sit open on the other, and product decisions get made twice by people who then disagree.
Both stores and possibly the web, sooner rather than perfectly. Coverage matters more to you right now than the last ten per cent of platform polish.
Buried in platform conditionals, or several framework versions behind. Usually a deferral problem rather than a technology problem, and usually recoverable.
For most business apps, no, and users cannot tell. The gap shows in specific places: heavy animation, sustained camera or sensor work, tight integration with platform hardware, and the first weeks after a major OS release when the framework is catching up. If your product lives in those places we will say so and recommend native rather than sell you the thing that is cheaper to build.
Less than the marketing claims and more than nothing. The screens, the business rules and the API layer are written once, which is the bulk of the work. What is not shared is the platform plumbing at the edges, the store release process, and the testing, which still has to happen on both platforms. The saving is real, it is mostly in the middle of the app, and it compounds over the years of changes that follow launch.
Often, and it is worth deciding up front rather than discovering later. Where the product is screens over an API, the web build comes largely free and gives you a version that needs no install at all. Where the app depends on device hardware, the web version is a different product wearing the same name, and pretending otherwise produces something that disappoints on every platform.
It gets planned for rather than deferred. Shared frameworks move faster than the platforms underneath them, and an app two major versions behind is an app that is expensive to touch. We keep upgrades on a schedule while they are small, which is the difference between a routine afternoon and a project.
The choice follows the product rather than a house preference, and the honest framing is that every option here is a commitment you will live with for years. What actually reduces lock-in is not the framework, it is where you put your business rules. Keep them in plain, framework-agnostic code with the shared layer handling presentation and platform access, and a future migration is a rewrite of the outer shell rather than of the product. Scatter framework-specific idioms through your domain logic and you have married it. We structure for the first outcome and tell you plainly what would be involved in leaving.
We build the riskiest screen first, on a real handset, and let it decide. Every product has one part that is the actual test: the camera flow, the map with hundreds of pins, the animation somebody is attached to, the offline sync. Arguing about it in the abstract can run for months and produces a decision based on whoever is most confident. Building it takes days and produces a decision based on a thing you can hold. If it performs, the rest of the app is lists and forms and shared code will be comfortable. If it does not, you have learned that before committing a budget rather than after.
Not if the platform conventions are respected, and immediately if they are not. What gives a cross-platform app away is almost never rendering performance on a modern phone. It is behaviour: a back gesture that does not work the way the rest of the phone works, a date picker that is neither platform's, a keyboard that covers the field being typed into, transitions that split the difference between two design languages and belong to neither. Those are choices, not limitations, and we make them per platform rather than picking one compromise and shipping it to both audiences.
That is a fair thing to ask before committing, and it is a genuine argument in favour of the mainstream frameworks over the interesting ones. A shared codebase in a widely-adopted framework has a real hiring market, and one developer can cover both platforms rather than needing two specialists. The risk is narrower than people fear but it is not zero: you will still occasionally need someone who can write a native module in Swift or Kotlin when the shared layer runs out. We keep those modules small, well-bounded and documented for exactly that reason.
We are happy to answer any questions you have and help you work out which of our services fit your needs.
