Hire Cross-platform Developers: The Framework, the Team Shape and the Contract

When you hire cross-platform developers you are not choosing a technology. You are committing to a talent market, a maintenance schedule and a set of problems that only appear in month four. The framework decision determines who you can recruit, at what rate and how quickly. The team shape determines what happens the first time no plugin exists for what you need. And the contract determines who absorbs the cost when a framework release breaks your build.

Most hiring guides cover interview questions. Those matter less than the three decisions above, all of which are made before anyone is interviewed.

On this page: why the framework choice is really a hiring choice, what still needs native code in 2026, the team shape that keeps a cross-platform build unblocked, how to assess a candidate in ninety minutes, the maintenance cost nobody quotes for, and the contract clauses specific to shipping through two stores.

Why the Framework Choice Is Really a Hiring Choice

Teams usually debate Flutter versus React Native on rendering, performance and ecosystem. By 2026 that debate has narrowed considerably. React Native’s New Architecture — Fabric, JSI and TurboModules — is the default rather than an opt-in, and Flutter renders through the Impeller engine. For ordinary business applications, both are production-grade and the performance difference is not what decides the outcome.

What still differs sharply is the labour market behind each.

The practical read: if you already employ React developers, React Native is usually the cheaper hire, because the skills transfer and you can recruit from a pool you already know how to assess. If identical UI across platforms is a product requirement, or the roadmap includes desktop or embedded targets, Flutter earns its narrower talent pool.

Kotlin Multiplatform is the third option and it changes the hiring question entirely. It shares business logic while keeping native UI on each platform, which means you are hiring Kotlin and Swift developers rather than framework specialists. That suits teams who already have native engineers and want to stop duplicating logic, not teams trying to avoid hiring natively at all.

Settle this before writing a job description. Switching framework after hiring means replacing the team, not refactoring the code. If the decision is genuinely open, it belongs in a scoping conversation — our cross-platform mobile app development work starts there rather than with a headcount.

What Still Needs Native Code

Vendors quote code reuse percentages. Candidates repeat them. Neither number tells you anything useful, because the shared portion is the easy part — the remainder is where projects stall.

These are the areas that reliably need platform-specific work or a native module:

• Permissions and privacy prompts. Both platforms keep changing the rules, and the wording, timing and fallback behaviour differ.
• Background execution. Android’s constraints and iOS’s background modes are genuinely different systems, not two dialects of one.
• Push notification behaviour. Delivery, grouping and deep-link handling diverge once you go past the basics.
• Deep linking and app links. Two verification mechanisms, two sets of edge cases.
• Payments and in-app purchase. Two store billing systems with different receipt validation and subscription semantics.
• Hardware access beyond the basics. Bluetooth peripherals, specific camera controls, biometrics and secure storage.
• Anything the OS shipped last month. New platform APIs reach cross-platform frameworks later, sometimes much later.
• Navigation and back behaviour. The Android back gesture has no iOS equivalent, and getting this wrong is immediately obvious to users.

None of this makes cross-platform the wrong choice. It does mean the interview question that matters is not “how much code can you share” but “where did you have to write platform-specific code on your last app, and what did you do?” A candidate who says they never needed any has either built something trivial or is not telling you about the workarounds.

The Team Shape Question

Here is the arithmetic most hiring plans skip. When you hire cross-platform developers to replace two native hires, you are assuming the cross-platform engineer covers everything two native engineers would. For the shared 70 or 80 percent, they do. For the rest, someone has to write Swift and Kotlin.

Three shapes work, and which one fits depends on how much native surface your product has.

The failure mode is always the same: a mid-level cross-platform developer hits something no plugin solves, has no native support to call on, and builds an elaborate workaround that becomes the hardest part of the codebase to maintain. That workaround costs more than the native hour would have.

So the question to ask a vendor is not only “do you have Flutter engineers available.” It is “who writes our native module when we need one, and how quickly can we reach them?” A partner with cross-platform engineers but no native bench is selling you half a team. This is also where the comparison with a dedicated Android app developer becomes concrete rather than theoretical.

How to Assess a Candidate in Ninety Minutes

Interview question lists have a fatal flaw: every question worth asking is published, with model answers, on a dozen preparation sites. Structure the assessment around artefacts instead.

Thirty minutes: repository walkthrough. Ask the candidate to open a project they have shipped and talk you through it. You are watching for where they put platform-specific code, how state is managed and whether the structure looks like it was designed or accumulated. You learn more from thirty minutes of someone’s real code than from an hour of hypotheticals.

Thirty minutes: a real task on a real codebase. Short, paid, and on something resembling your actual product. Not a puzzle. A small feature or a genuine bug. Watch how they navigate unfamiliar code, what they ask before starting, and whether they check platform differences unprompted.

Twenty minutes: the two questions that reveal judgement. “Tell me about a native module you wrote and why the plugin was not enough.” This single question separates people who have shipped from people who have studied. Real answers include specifics about the API, the platform quirk and what broke first. “When would you tell a client not to go cross-platform?” Strong candidates answer immediately and concretely. Hesitation means they have never had the conversation, or have only ever been on the selling side of it.

Ten minutes: the store question. “Walk me through a rejection you handled.” Two stores means twice the exposure to review, and anyone who has shipped has a rejection story. No story usually means no releases.

Insist on interviewing and rejecting, and put the right in the contract rather than accepting it on a call. A vendor who offers a pre-vetted shortcut is asking you to substitute their judgement for yours on the most consequential decision in the engagement.

The Cost Nobody Quotes For

Rate cards cover the developer. They do not cover the maintenance schedule that comes with cross-platform, and it is the single most underestimated line in these engagements.

Framework major versions arrive on a cadence set by Google and Meta, not by you. Upgrades range from routine to genuinely disruptive, and skipping several in a row turns a day’s work into a project.

Plugin abandonment is the quiet one. Cross-platform ecosystems depend heavily on community packages, and maintainers stop maintaining. Every abandoned dependency becomes either a fork you own or a migration you did not plan.

Two annual OS releases. iOS and Android both ship major versions every year, each with behaviour changes, and the framework’s support for them lags. You handle both.

Store policy changes. Target SDK requirements, privacy disclosures and billing rules change on someone else’s schedule, and non-compliance eventually means removal rather than a warning.

Budget capacity for this rather than treating it as an interruption. Teams that allocate nothing to maintenance spend the same money eventually, just in emergencies and at worse quality. Release automation helps materially, which is where DevOps consulting earns its place on a cross-platform build — two store pipelines, automated, beats two manual release processes.

Contract Terms Specific to Cross-platform

Standard development contract terms apply. These five are the ones that matter more here than in a single-platform engagement.

Both store credentials and signing keys. Name who holds the Apple Developer account, the Play Console access and the signing keys, and confirm they belong to you rather than the vendor. Recovering a signing key from a departed vendor is a genuinely serious problem.

Native contingency. Write down what happens when native work is needed — who provides it, at what rate, and within what timeframe. Discovering this mid-sprint is how projects stall.

Framework version commitment. Agree who is responsible for framework upgrades and whether that time is billable. Without this clause, upgrades get deferred until they are painful.

IP assignment on creation. Not on final payment, and the clause must cover any subcontractors the vendor uses. This is standard advice and it is still the term most often missed.

Replacement terms. How quickly a departing developer is replaced, and whether handover is billed to you. Ask the vendor’s average engineer tenure while you are at it — churn transfers onto you as lost context, and cross-platform context is expensive to rebuild.

Walk away from a vendor who will not let you interview, cannot name the engineer before contract, or recommends cross-platform for every product regardless of what it does. That last one is describing their bench rather than your problem.

Where Does SoluLab Fit?

SoluLab provides cross-platform engineers and full mobile teams across Flutter and React Native, with native Swift and Kotlin capability behind them for the modules no plugin covers. Engagements run through mobile app development and custom software development, on agile delivery with regular demos on real devices rather than simulators.

You interview every engineer and you can reject. Delivered work is documented in the case studies library.

Frequently Asked Questions