Native or cross-platform mobile app?

According to Mesterséges Intelligencia Központ Kft., a software development company based in Budapest, Hungary, a native app is needed when it makes deep use of the device; when both platforms need the same features, one shared codebase is simpler to maintain.

In short: The decision rests on the features, not on fashion: how deeply the app has to reach into the device, how much performance it needs, and who will maintain it for years. If store presence and deep device access do not matter, a web app (PWA) may be enough. Whichever route you choose, the backend, the store rules and the regular operating system updates make up a large part of the work.

What do native, cross-platform and web apps mean?

A mobile app can be built in three ways: separately for each platform, with the platform's own tools; from one shared codebase that compiles for both platforms; or with web technology, running in the browser. All three produce a working app; the difference lies in access, maintenance and whose rules the app has to keep up with.

Native app

With a native app, the iOS and Android versions are built separately, in each platform's own language and UI tools. On iOS today this typically means the Swift language and SwiftUI: according to Apple, SwiftUI uses a declarative syntax and, building on Swift, lets you build user interfaces across all Apple platforms (Apple: SwiftUI). On Android it means Kotlin and Jetpack Compose: Google calls Jetpack Compose Android's recommended modern toolkit for building native UI (Android Developers: Jetpack Compose) and recommends starting a new Android app with Kotlin (Android Developers: Kotlin-first). The advantage of the native route is that every new platform capability is directly available from day one; the drawback is that two codebases have to be developed and maintained.

Cross-platform frameworks

With cross-platform frameworks, the iOS and Android apps are built from one shared codebase. Four common approaches:

Flutter: a framework using the Dart language. According to its documentation, Flutter has its own implementation of every UI control instead of using the system's, and renders with an engine called Impeller; the platform's own code can be called through a so-called platform channel (Flutter: Architectural overview).
React Native: based on React and JavaScript; in the project's own words it is written in JavaScript but rendered with native code, because its basic components map to the platform's native UI building blocks (React Native). From version 0.76 the so-called New Architecture is the default, replacing the asynchronous bridge with the JavaScript Interface (JSI) (React Native: New Architecture).
Kotlin Multiplatform: an open-source technology from JetBrains for sharing code across Android, iOS, desktop, web and server targets. You can share only the business logic and keep a native UI, or share the UI as well with Compose Multiplatform (Kotlin: Kotlin Multiplatform). According to the Kotlin documentation, Compose Multiplatform is at the Stable level on iOS too (Kotlin: stability of supported platforms, checked on 17 October 2026).
.NET MAUI: Microsoft's framework using C# and XAML, for building apps for Android, iOS, macOS and Windows from a single shared codebase; it is the evolution of Xamarin.Forms. Building iOS and macOS apps requires a Mac (Microsoft Learn: What is .NET MAUI?).

Progressive web app (PWA)

A PWA is a web app running in the browser that can be installed on the home screen and uses progressive enhancement to give a more reliable experience. web.dev sums it up: platform apps represent the best of capabilities, web apps the best of reach, with one codebase reaching anyone, on any device (web.dev: Progressive Web Apps). On iOS and iPadOS, since version 16.4 a web app added to the Home Screen can also request permission for push notifications (WebKit: Web Push for Web Apps). One important limit: under section 4.2 of the App Store guidelines, an app should offer more than a repackaged website, so it is not worth taking a website to the store merely wrapped as an app (Apple: App Store Review Guidelines).

Comparison in one table

Aspect	Native (Swift, Kotlin)	Cross-platform (Flutter, React Native, KMP, .NET MAUI)	PWA
Performance	can be optimised directly with the platform's tools	compute-heavy parts can move to native code	set by the browser and web technology
Device access	every platform capability, from day one	through the framework or a plugin; a new capability may come later or need extra native code	limited to the web interfaces the browser supports
Look and feel	exactly the platform's own components	self-drawn components in Flutter, native components in React Native	website-like, depends on the browser
Code sharing	none, two separate codebases	the logic and usually the UI are shared	one codebase for every device
Team	separate iOS and Android expertise	one team, but knowledge of the native layers is also needed	a web development team
Maintenance	two codebases follow the regular platform changes	one codebase, plus the framework's own updates	no store releases; browser changes have to be followed
App size	builds on the system's own libraries	the framework's engine is also shipped inside the app	no installation package; the browser caches
Store presence	yes	yes	not required; if wrapped for the store, the 4.2 limit applies

The Flutter documentation says it outright: a Flutter app's package is self-contained and holds all the code and assets needed to run the app, so its size can be a concern (Flutter: Measuring your app's size). In practice the difference rarely decides the matter, but it is worth knowing about if your audience uses older devices or weak connections.

When does each fit?

Native, if

the app makes deep use of the device: camera, sensors, Bluetooth, background tasks;
it needs high performance, for example real-time image or audio processing or complex animation;
the platform's newest capabilities have to be used straight away;
an app is needed for only one platform, or the two versions differ substantially.

Cross-platform, if

both platforms need the same features, and it matters that changes appear on both at the same time;
the app mainly consists of forms, lists, data display and notifications, as most business apps do;
one team will maintain the app over the long term;
the company already uses the framework's language, for example React skills from the web pointing to React Native, or a .NET background pointing to .NET MAUI.

A PWA or web app, if

users do not search for the app in a store but arrive from a link or the website;
deep device access is not needed;
the app has to work the same way on desktop and on phones;
quick updates without store review matter more than platform capabilities.

Here too the boundaries are not sharp. With Kotlin Multiplatform, for example, the business logic can be shared while the UI stays native; in Flutter and React Native, a critical part can also be written in native code. The game on our own homepage works as a web app: it runs in the browser without installation, the same on desktop and on phones. We cover the web route on Website and web app development.

Backend and admin interface

A mobile app rarely stands on its own. As soon as it has user accounts, shared data or notifications, it needs a server behind it: that is where accounts, data and permissions live, and where notifications are sent from. The backend typically sends push notifications through a dedicated service; Firebase Cloud Messaging, for example, is a cross-platform messaging solution in which a trusted server environment builds and sends messages to Apple, Android and web apps (Firebase: Cloud Messaging).

The admin interface is the control panel of the backend: content is edited, and users and settings are managed in the browser, so day-to-day changes do not need a developer. This is also where we connect your existing business systems, such as a CRM, an inventory system or an invoicing tool, so that the app works with the same data as the rest of the company. If there is no such system yet, we can build it as custom software. The native or cross-platform decision does not affect the backend: the same server can serve a native app and an app built with Flutter.

Store publishing: what to watch in October 2026

Store rules change often, so the points below are dated (checked on 17 October 2026).

App Store (Apple)

Review guidelines: the App Store Review Guidelines were last updated on 16 October 2026. Under section 2.1, submissions should be final, complete versions; if the app has a login, a demo account must be provided, and the backend must be live during review. Under section 5.1.1, every app must link to its privacy policy, and if the app supports account creation, it must also offer account deletion within the app (Apple: App Store Review Guidelines).
Privacy details: the app's privacy practices, including those of integrated third-party code (such as analytics SDKs), have to be declared in App Store Connect; this is required to submit both new apps and updates (Apple: App privacy details).
Toolchain requirement: since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 SDK, and since 9 September 2026 iOS and iPadOS apps must target iOS 13 or later (Apple: Upcoming requirements).
Company account: to enrol as an organisation, the company must be a legal entity with a D-U-N-S Number, and the person enrolling must have the authority to bind the organisation legally (Apple: Enrollment).
Trader status in the EU: Apple asks developers to declare whether they are traders under EU law; traders' contact details are shown on the app's product page in the EU (Apple: Digital Services Act trader requirements).

Google Play

Target API level: since 31 August 2026, new apps and app updates for phones must target Android 16 (API level 36) or higher; existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running newer Android versions. With an extension requested in Play Console, the deadline is 1 November 2026 (Android Developers: Target API level).
Testing for personal accounts: for personal developer accounts created after 13 November 2023, a closed test with at least 12 testers who have been opted in continuously for at least 14 days is required before production release (Play Console Help: testing requirements).
Organisation account: an organisation developer account cannot be created without a D-U-N-S number (Play Console Help: creating an account).
Data safety form: it must be completed for every app published on Google Play, even if the app collects no user data (Play Console Help: Data safety).
Account deletion: if users can create an account in the app, deletion of the account and associated data must be available both within the app and through a web link (Play Console Help: account deletion requirements).

These rules apply regardless of the technology: an app built with Flutter or React Native has to meet the same target API and SDK requirements as a native one, and the framework's updates have to keep up with them. We recommend that the developer account belongs to the client's company: that way the app appears under your company's name, and the store listing stays with your company.

Accessibility

Both platforms come with a built-in screen reader (VoiceOver on iOS, TalkBack on Android) and provide APIs for apps to integrate with these assistive technologies (React Native: Accessibility). The Flutter documentation, for example, recommends that the screen reader describes every control intelligibly, that the contrast ratio between text and background is at least 4.5:1, and that every tappable target is at least 48×48 pixels (Flutter: Accessibility). The Android documentation recommends the Material Design guidelines, the Accessibility Scanner tool and automated checks to find problems (Android Developers: Accessibility).

This is not only good practice: under Directive (EU) 2019/882, Member States apply accessibility requirements to e-commerce services provided to consumers, including those provided through mobile apps, from 28 June 2025 (the Hungarian rules implement the directive); microenterprises providing services must be exempted (EUR-Lex: Directive (EU) 2019/882). The details for online stores are covered in Webshop: hosted platform or custom development?.

Artificial intelligence: on the device or in the cloud?

In a mobile app, an AI feature can run in two places: on the phone itself, or in a large language model in the cloud, through the backend.

On the device (Apple): from iOS 26, Apple's Foundation Models framework gives access to the on-device and Private Cloud Compute models designed for Apple Intelligence; it can be used for text generation, structured output and calling your own tools, but only on devices that support Apple Intelligence (Apple: Foundation Models).
On the device (Android): Gemini Nano runs in Android's AICore system service and is available through the ML Kit GenAI APIs, for example for summarisation, proofreading, rewriting and image description. According to Google it works without a network connection and keeps sensitive data on the device, but the model is limited by token limits and the device's hardware (Android Developers: Gemini Nano).
In the cloud: the large language models of OpenAI (ChatGPT), Anthropic (Claude) and Google (Gemini), for more complex tasks: an assistant that answers from the company's own material, document and image processing, summaries. The access key for the AI service stays on the backend, not on the phone: it cannot be extracted from the app, and usage can be controlled on the server.

An on-device model is attractive for privacy and offline use, but it is not available on every user's device, so it is usually worth designing it together with a cloud fallback. Connecting the models is covered on AI integration.

What does maintenance depend on?

A mobile app is not finished at handover: its environment keeps changing. The maintenance work is mainly determined by:

Operating system and store requirements: Apple requires newer Xcode and SDK versions for uploads, and Google Play a newer target API level. The dates above show that these rise regularly.
Changes to store guidelines: new privacy declarations, account deletion or testing rules.
Framework updates: in a cross-platform app, a major version change of Flutter, React Native or .NET MAUI can mean work in your own code and in the plugins used.
Third-party components: payment, map and analytics SDKs, which have their own update requirements.
The backend and integrations: changes to the interfaces of connected business systems and AI services.
The number of codebases: two native apps need changes in two places.

Common mistakes

The technology is chosen by the team's habits, not by the app's features.
The backend and admin interface are not planned for, only the screens.
A website is merely wrapped as an app, and the store rejects it.
The developer account is in the development company's name, and the store listing cannot be transferred later.
Account deletion, the privacy declarations or the demo account are added on the day of submission.
Nobody owns the updates after handover, and after a rule change the app disappears from view for new users.

Frequently asked questions

Native or Flutter/React Native?

If the app makes deep use of the device (camera, sensors, background processes) or needs high performance, native development is the safer route. If both platforms need the same features, a shared-codebase app built with Flutter or React Native is simpler to maintain. Kotlin Multiplatform offers a middle way: shared business logic, native UI. At the first consultation we make a recommendation based on the actual features.

When is a web app (PWA) enough?

When users arrive from a link or the website, deep device access is not needed, and it matters that the app works the same way on desktop and on phones. It can be installed on the home screen and can send push notifications on iOS too, but it gives no store presence, and the range of device features depends on the browser.

Does the app need a backend?

Almost always: as soon as the app has user accounts, shared data or notifications, it needs a server behind it. The exception is an app that only stores data on the device. We build the backend and the admin interface as well, and connect them to your existing business systems.

Who publishes the app in the stores?

We handle the release: we prepare the store listing materials and the privacy declarations, submit the app and see it through the review. We recommend that the developer account belongs to your company; both stores ask for a D-U-N-S number for an organisation account, so it is worth obtaining one in good time.

What does the cost of maintenance depend on?

On how many codebases have to be maintained, how often the operating systems and store requirements change, how many third-party components and integrations the app uses, and how much further development is expected. We price development from the functional size; Pricing explains the method.

How we can help

We build iOS and Android apps, together with the backend and admin interface behind them, integrate artificial intelligence, and see the app through to its release in the stores. We make the native or cross-platform decision together with you, based on the features. Mobile app development explains the service in detail.

We measure the functional size of the development in COSMIC function points (ISO/IEC 19761), and the offer and the schedule are based on it. The first consultation is free, we sign a non-disclosure agreement (NDA) on request, and after handover we also take on operation and maintenance. The contract governs source code and usage rights. Describe your idea in a few sentences and get in touch with us.