Cross-platform app development
Cross-platform apps from one codebase: onboarding, payments and self-service, with native modules where the browser cannot reach.
Results from work we have shipped
$lana (Monetech), a regulated multi-country consumer credit platform, needed its compliance and data integrations online inside a tight regulatory window. We owned the integration architecture and delivered.
How we deliver a cross-platform app?
We begin by analysing your business goals and app requirements. This includes defining your target audience, core features and key user journeys. Based on this, we select the most suitable tech stack to achieve your vision.
A clear roadmap is essential. We break delivery into manageable sprints, set timelines and allocate resources to ensure a smooth workflow with transparent progress tracking.
Our designers craft intuitive, visually engaging interfaces. We prioritise user‑centred design to deliver an experience that aligns with your brand and resonates with your audience.
Our team writes robust, clean source code using modern tools and methods. Whether hybrid or fully cross‑platform, we engineer for scalability, performance and security.
Comprehensive testing runs at every stage, including functional, usability, performance and security checks. Issues are identified and resolved early to ensure a reliable app for end users.
When the app is ready, we handle deployment to app stores or your chosen distribution platform. We provide full ownership transfer and support for a smooth handover.
What we build cross-platform?
Full digital banking from one codebase: onboarding, identity checks, everyday payments and self-service, integrated with core banking, identity, cards and notifications. One such app we delivered replaced a bank's basic mobile features with a complete digital experience and now serves more than 700,000 customers, with a foundation for rapid feature releases.
Consumer credit products live or die on onboarding: application, identity verification, scoring and disbursement, often across more than one market and regulator. We build these journeys with the KYC and reporting integrations treated as first-class scope, because in regulated lending the integrations are the product as much as the screens are.
Some products want web content and native capability in one shell: a shared web core for content and account screens, with native modules for the features the browser cannot reach. We build hybrids deliberately - defining which layer owns which journey - rather than as an accident of legacy, so performance stays predictable.
A deliberately narrow first release built on the same architecture the full product will use, so nothing is thrown away when traction arrives. We cut scope by journeys, not by engineering quality: fewer screens, each shipped to production standard. The shared codebase makes this honest - the MVP and the eventual product are the same repository, growing rather than restarting.
One codebase or two - still weighing it?
Tell us the audience and the device features you need and we will scope the framework call.
What shapes the work
The case for cross-platform is economic before it is technical. Two native codebases mean two teams, two backlogs, two review queues and two release trains - every feature paid for twice and shipped at two different speeds. A shared codebase collapses that: one team, one backlog, features landing on iOS and Android in the same week. For products whose value lives in journeys - onboarding, payments, account servicing, content - the trade is almost always worth taking. In fintech the maths is sharpened by compliance: every regulated change is reviewed once, not twice.
The honest counterweight is where shared code struggles. Heavy custom graphics, low-level hardware control, audio processing or platform-specific UI conventions taken to the extreme all push work into native modules until the shared layer stops paying for itself. We model that boundary in discovery: we list every feature that needs platform code, estimate the bridge surface, and only recommend cross-platform when the shared core stays dominant. That analysis is documented, so the decision can be revisited when the product changes.
If the boundary lands on the native side for your product, see when full native Android development wins.
Framework choice is a ten-year decision dressed up as a sprint-zero task. React Native renders through platform views and shares idioms with web teams, which makes it the natural pick when your engineers already live in TypeScript and your product leans on mature payment and analytics SDKs. Flutter draws its own interface, which buys pixel-identical screens on both platforms and strong performance for custom UI, at the price of a separate language and its own ecosystem. The third shape - a web application in a thin native shell - trades some device capability for the fastest path to both stores and the web at once. We weight the decision on four axes:
- Team: the languages your engineers can hire for and maintain
- SDK coverage: whether your KYC, payments and analytics providers ship first-class support
- UI demands: how far the design departs from platform conventions
- Release cadence: how often both platforms must ship the same day
The recommendation arrives with the reasoning attached, so it can be defended internally and revisited as the product grows.
If reach through the browser matters more than store presence, see the installable web variant of one codebase on our PWA page.
The hard part of cross-platform is not the shared code - it is the places where code cannot stay shared. Biometric authentication, secure storage, camera capture for identity checks, push notifications: each crosses into platform territory, and each crossing is real Swift and Kotlin that somebody must write, review and debug. We treat that native work as a planned workstream with its own estimates and reviewers, so the platform side gets the same engineering attention as the shared core.
The second reality is the upgrade treadmill. Frameworks ship breaking releases, Apple and Google raise their minimum targets every year, and the SDKs around payments and identity deprecate on their own schedules. We put framework and dependency upgrades into the sprint plan alongside features, and every upgrade goes through the same device testing as a release before it ships.
Treating the treadmill as scheduled work changes what stakeholders see, too. The cost of staying current appears in the roadmap as a steady, predictable share of each sprint, rather than arriving as a surprise when a store policy or an OS release forces your hand. The team's energy goes into the next feature, not the next scramble.
Cross-platform pricing follows the codebase logic: you fund one delivery team, not two. A typical WislaCode team pairs developers with UX/
What actually moves the price is scope, not the platform count: the number of user journeys, the integrations behind them, how much of the feature list crosses into native modules, and the device range you must support. Compliance-heavy products carry extra weight for identity providers and audit requirements. We size all of this in discovery and give you an estimate tied to a written scope, so the figure means something.
Speed is part of the same economics. Aleksei Malenkin, CTO of $lana (Monetech), credits our engineers with synchronising quickly with the second development team on the project and taking the product from scratch to first users in five months. That delivery landed inside a regulatory window that did not move.
The full story is in the case study: one codebase to first users in five months.
After launch, one codebase still ships into two stores with two review queues, two policy sets and two rejection styles. We run a single release train with both binaries cut from the same commit, so the platforms never drift apart by more than one release. When one store holds a build, feature flags keep behaviour aligned until both are live.
Observation runs as two populations, one product. A shared codebase can still behave differently on a mid-range Android handset than on a current iPhone, so we read the numbers per platform and treat any gap between them as a defect with an owner, not background noise. The same data tells us when a framework or OS upgrade has moved the numbers.
Maintenance follows the same shape as delivery: one backlog, one team, fixes and features landing on both platforms in the same cycle. That is the operational dividend of the one-codebase decision - it keeps paying after the launch sprint is forgotten. Parity is a permanent requirement here, not a launch milestone.
WislaCode specialists quickly synchronised and worked with the second team involved in developing our solution. As a result, having started development from scratch, we came to the expected result quickly. The first users went to the application after 5 months.
What is included in a cross-platform engagement?
Every engagement is scoped as a production delivery, not a prototype: a cross-platform application built, tested and shipped to both stores, with the codebase, pipelines and knowledge your team needs to run it.
A written framework recommendation - React Native, Flutter or a web shell - with the trade-off analysis behind it.
A shared codebase architecture with the native boundary drawn explicitly, so platform-specific code stays a known, contained fraction of the product.
Native modules for the features that need them - biometrics, secure storage, camera capture, push - built and tested on both operating systems.
A device-coverage matrix agreed with you, defining the handsets, OS versions and screen sizes each release is verified against.
CI/CD pipelines that cut signed iOS and Android builds from one branch, with automated tests gating every merge.
Release management for the first production cycles, including store review correspondence and rejection handling with both Apple and Google.
Documentation and knowledge-transfer sessions so your developers can extend the shared codebase and its native modules without us.
At the end of the engagement everything sits in your accounts: repositories, store listings, signing keys, pipelines and documentation. You can run, extend or re-tender the product freely - nothing we deliver creates a dependency on us.
How do you decide between fully cross‑platform and a hybrid or PWA approach?
We assess required device features, performance targets, offline needs and release cadence. If you need near‑native performance with a shared codebase, a modern cross‑platform framework fits well. If rapid web reach and cost control are priorities, a PWA or hybrid can be faster. We model trade‑offs for maintainability, performance and total cost before recommending.
Can you deliver a production‑ready cross‑platform MVP in under three months?
Often yes, provided scope is focused and integrations are clear. We target a first value slice with secure authentication, one or two core journeys and basic analytics. Rich device features or multiple providers can extend timelines, but we still ship in increments to validate early and de‑risk later work.
How do you ensure consistent performance across iOS and Android?
We set performance budgets, profile on target devices and optimise rendering, network calls, caching and asset delivery. Offline‑first patterns reduce latency on poor connections. Continuous monitoring tracks cold starts, frame drops and API latency by OS and device model to catch regressions quickly.
What’s your approach to mobile security and privacy?
Security is embedded: encrypted transport, secure storage, certificate pinning where appropriate and strict session management. We apply least‑privilege access, minimise data collection and document consent and retention policies. Dependencies are scanned in CI/CD, and SDKs are reviewed for risk and data sharing.
Do you handle app store submissions and ongoing updates?
Yes. We prepare listings, meet policy requirements and automate build and release pipelines. Feature flags enable staged rollouts; telemetry informs when to widen distribution. We also support enterprise distribution where relevant and manage update cadences aligned to your release strategy.
How do you integrate payments, maps and other device features in a shared codebase?
We use well‑maintained SDKs with clear contracts. Where native modules are required, we encapsulate them behind stable interfaces so shared code remains clean. Contract tests and test doubles protect against provider changes and OS updates, keeping delivery predictable.
Can you work alongside our internal developers or an existing vendor?
Absolutely. We co‑build with shared backlogs, coding standards and CI pipelines. Clear ownership, documentation and interface contracts keep teams aligned. We run knowledge‑transfer sessions to ensure your developers can operate and extend the app confidently after launch.
What happens after launch if usage grows rapidly?
We scale horizontally, optimise hot paths and apply smart caching. Observability guides capacity planning, while feature toggles allow progressive enhancements. We prioritise improvements that lift activation and retention, and trim underused features to keep the app lean and maintain strong performance.
Do you work fixed price or time and materials?
Both, depending on how settled the scope is. A well-defined first release can run fixed price against the written scope from discovery; products that will evolve sprint by sprint usually fit time and materials with a stable team. Either way you get sprint-level transparency on progress and spend, and the model can change at a natural milestone.
Are we locked into the framework you choose?
Less than you might fear. We keep business logic, API contracts and data models separate from framework-specific code, and the native modules are already isolated from the shared core. If a future requirement demands native development, screens can be rewritten incrementally while the architecture and backend contracts survive. The written framework recommendation also records the exit considerations, so the decision stays reversible by design.
How much of the code is actually shared between iOS and Android?
It depends on the native surface your features need, but in a typical product the business logic, networking, state management and most of the interface are written once. Platform-specific code is confined to thin native modules. During discovery we list which features cross that line, so you know the shared-to-native split before development starts rather than discovering it in invoices.
payabl., an EU-regulated merchant acquirer, had a payment SDK gap holding up merchant onboarding. We designed and shipped it inside a single sprint cycle.
View case
Moving from standard banking with a basic set of functions to a digital bank where everything can be done online.
View case
We turned traditional car leasing into a fully digital service: online search and booking, applications, contracts, invoices and document management, all in one place.
View caseThis was a very task-heavy project, mostly exploration and R&D-driven. However, by the end of WislaCode, we were left with a detailed roadmap consisting of clear milestones - able to be converted into tangible KPIs - and some neat ideas of what actionable are next. Integrating...
We collaborated with WislaCode on a product strategy development project and gave the highest marks for this contractor. The WislaCode team delivered on time and with outstanding quality.
We collaborated with WislaCode on a route-to-market optimisation project. Working with WislaCode was effective, transparent and predictable, which is especially critical for AI and ML projects. We provided them with six months of anonymised data, and within just three weeks...
Ready to build once and ship everywhere?
Describe the product and we will map the cross-platform build, bridges and performance budget included.