How a cross-platform app is structured
A cross-platform app has three layers. The first is business logic: server communication, calculations, form validation, and data storage. It's written once and works the same way on both platforms.
The second is the user interface. In most projects, the screens are shared too, although individual elements can be shown differently on iOS and Android. The third is a thin layer of native code for anything the framework can't do on its own. Simple apps may not need it at all; in complex ones, it accounts for a noticeable share of the work.
The biggest savings aren't in writing the code but in everything that comes after: one team, one set of logic tests, one backlog, and new features shipped to all users at the same time.
Benefits of the approach
- Two platforms for less than the cost of two builds. Most of the work is done once, so the budget is noticeably lower than for two separate native apps.
- The same features on every phone. No more cases where a new feature is already on iOS while Android users wait several more releases for it.
- One team. Easier planning, easier handoff to other developers, and less risk of product knowledge getting scattered.
- Faster changes. A bug fix in the shared logic goes into both versions at once.
Drawbacks and risks
- Framework dependency. When Apple or Google adds a new capability, the cross-platform tool needs time to support it. Sometimes you have to write your own native module.
- Larger app size. The framework itself is bundled into the build along with your code. For most products this isn't critical, but the difference is there.
- Not always a fully "native" feel. An experienced iOS user may notice that scrolling or menus behave slightly differently than in system apps. More careful design solves this.
- Native expertise is still required. Code signing, publishing, system permissions, and custom features all require an understanding of iOS and Android.
- Framework upgrades. Every few releases, the tool changes enough that upgrading the project becomes a task of its own.
Flutter or React Native
Both tools are mature and suit most business apps. The difference is in the details:
- Flutter renders every UI element itself, so the app looks the same on all devices and complex custom branding is reproduced precisely. Code is written in Dart.
- React Native uses native iOS and Android components and is written in JavaScript or TypeScript. It's a good fit if you already have a website or service built on React and a team that knows it.
We're not tied to a single tool: we choose the one your product will be easiest to live with long term, not the one that's most convenient for us.
When native development is better
Cross-platform is a trade-off, and sometimes it isn't justified. We'll recommend separate native apps if:
- the product relies heavily on the camera, augmented reality, or real-time audio or video processing;
- you need the newest system features as soon as they're released;
- your audience is almost entirely on one platform, in which case it's simpler to build, for example, just a native iOS app;
- you already have strong separate teams for each platform.
And if the app is only meant to be a convenient wrapper for your website, a progressive web app without store publishing may be enough.
Which apps work well on a single codebase
Cross-platform delivers the most value where the core is data-driven screens and standard actions:
- catalogs, ordering and delivery, loyalty programs;
- customer accounts for banks, insurers, and service companies;
- appointment booking, reservations, and tickets;
- internal employee apps: requests, reports, schedules;
- mobile versions of online services and subscription platforms.
Games, complex graphics, and apps that constantly work with the phone's hardware are a different story.
Testing and publishing two versions
Shared code doesn't change the fact that the app runs on two different systems. Camera and location permissions, background behavior, notifications, the keyboard, and system gestures differ between iOS and Android, so we test every feature on each platform separately.
Publishing is doubled too: two developer accounts, two store listings, and two reviews, one from Apple and one from Google. We prepare materials for both and plan releases so each new version appears on the App Store and Google Play at roughly the same time.
New app or moving to a single codebase
For a new app, we start with a short technical prototype of the riskiest features. If something doesn't work as needed, we find out before main development begins, not a few steps before release.
If you have two separate native versions that have drifted apart in features and are expensive to maintain, they can be gradually migrated to shared code. We first assess what can be kept from the existing code and backend, and only then propose a migration plan.
What affects the cost
- Number and complexity of screens: standard forms and lists, or custom animations and non-standard elements.
- Amount of native code: how many features the framework doesn't cover and have to be written separately for each platform.
- Backend: we use your existing API or build a new one along with an admin panel for your team.
- Platform-specific design: one interface for everyone, or adapted to iOS and Android conventions.
- Integrations: payments, CRM, accounting systems, shipping carriers, analytics.
We provide an estimate after reviewing the features and break it down by stage, so you can see exactly what makes up the budget.
Frequently asked questions
Will users notice the app is cross-platform? For most business apps, no. The difference may only be noticeable in highly dynamic interfaces or on old, low-end phones.
Can we switch to native development later? Yes, and the backend and design will carry over. In practice, though, a well-built cross-platform app rarely needs that switch.
Can we add a web version from the same code? Technically yes, especially with Flutter. It works for internal tools, but a public website that depends on SEO is better served by separate web development.
What if we need a feature the framework doesn't support? We write a native module for it in Swift and Kotlin and connect it to the shared code.
Why Promodex
Since 2015, Promodex has built a portfolio of 750+ projects. Mobile apps we showcase include Rate Trading, Zoomerang, and Transit. Our apps are designed and built by our full-time in-house designers and developers, with no outsourcing. We explain the reasoning behind every technology choice, and after launch we stay with you to update the app for new iOS and Android versions.
