What you actually get when one app runs on web, mobile and desktop

What native code actually does for a business app

Native code means writing an app in the specific programming language favoured by each device maker. For Apple devices, that means Swift. For Android, it means Kotlin. For Windows, it often means C#.

When a software agency tells you that you must build a native app, they usually mean they want to write your app two or three times. They write the screens once for the iPhone. Then they write the same screens again for Android. Then, if your office staff need to run it on desktop computers, they write a web version from scratch. You pay for three separate development teams, three rounds of bug fixes and three ongoing maintenance contracts.

For almost every business app, this approach makes no financial sense. If you are building a field inspection checklist, an inventory tracker, an internal booking system or a customer portal, native code does not make the business logic work any better. Your staff need a form that saves reliably, works when signal drops out and talks to the camera to take a photo of a receipt. None of that requires two separate teams writing low-level system code.

Writing native code only becomes mandatory when software pushes hardware to its absolute limits. If you are developing a mobile video editor with frame-by-frame rendering, a 3D game engine or a custom audio synthesiser, you need direct access to the graphics card and processor memory. For handling customer records, scheduling jobs and dispatching invoices, a well-built cross-platform app gives you the exact same result for a fraction of the cost.

How one project turns into six different builds

One appgnt app starts as a standard web project built with React, TypeScript and Vite. Because it runs on modern web standards, that same codebase can be wrapped in thin native shells to run as an independent application on Android, iOS, Windows, macOS and Linux.

The packaging works through two specific technologies:

• Capacitor wraps the web build for mobile devices. It creates real Android Studio and Xcode projects that package your web application inside a native container. The mobile operating system treats it as an installed application, giving it a home screen icon, its own process and access to device hardware.
• Tauri 2 wraps the web build for desktop machines. Instead of bundling a heavy web browser like older tools used to do, Tauri uses the native web rendering engine already installed on Windows, Mac and Linux. The resulting desktop installers are tiny, usually taking up only a few megabytes.

Alongside the mobile and desktop packages, the web build includes a progressive web app manifest and a background service worker. That means anyone can visit the app's web address in Chrome, Safari or Edge and install it straight to their home screen or desktop without visiting an app store at all. If you want to bypass store approvals entirely, you can install from the browser and hand the URL straight to your staff.

How device features work across phones, laptops and browsers

A cross-platform app uses the best available tool on each operating system to access hardware features. The app does not pretend every computer is identical. Instead, it checks where it is running and calls the right API.

When a member of staff taps a button to photograph stock, the app runs a platform check. On an Android phone or an iPhone, Capacitor calls the phone's native camera interface directly. The camera opens instantly, lets the user snap a picture and hands the image back to the app. On a laptop running the web build, the app falls back to the browser's standard file picker or webcam dialogue.

The same rule applies to location, local files, share sheets and device notifications:

• Location uses the phone's GPS hardware when running on mobile, returning precise coordinates for field workers. In a desktop browser, it requests location via the browser's standard location prompt.
• File handling uses native mobile share sheets on Android and iOS, desktop file dialogues on Windows and Mac, and standard file downloads in the browser.
• Notifications trigger local system alerts on Android and desktop, while web browsers ask for standard push permissions.

Your business logic stays identical across every platform. You write the rule for how an invoice is calculated or how a shift is assigned once. The platform shells handle the small differences in how each operating system talks to its hardware.

What the studio builds and what needs a Mac

Every time you ask the studio to change something, an agent running on a warm cloud machine updates the source files, runs a type check and builds the web app. It immediately loads that build in a headless browser at phone, tablet and desktop screen sizes to make sure the interface renders properly without errors.

When you are ready to ship, the studio's Publish pane can trigger exports on dedicated AWS Fargate workers. The build pipelines run in the cloud without you needing to install developer tools on your own computer.

Android builds take around three minutes. The studio produces a debug APK you can test immediately, a release APK for direct distribution and an Android App Bundle (AAB) signed with a dedicated key kept safely in AWS Secrets Manager. Linux and Windows builds run even faster, finishing in under a minute.

Apple platforms are the only exception. Apple legally requires software for iOS and macOS to be compiled and signed on an actual Mac running Xcode. Because cloud servers cannot run Xcode without violating Apple's licensing or running expensive dedicated Mac hardware, the studio gives you a complete, pre-configured project zip. You unpack it on a Mac, open Xcode and click build.

Where the real trade-offs and limits sit

Cross-platform development saves months of work, but you should understand its practical limits before starting.

First, background execution has strict rules. A web app open in a browser tab cannot run background tasks when the user locks their phone or switches tabs. The mobile wrappers allow background work, but modern versions of Android and iOS aggressively close apps to save battery. If your business requires continuous background tasks, like minute-by-minute location tracking of delivery drivers across an eight-hour shift, an operating system will eventually pause a wrapped app unless you configure specialised background modes.

Second, notifications require external accounts. You cannot send push notifications to a customer's phone out of thin air. You must set up an account with Google Firebase for Android alerts and an Apple Developer account for Apple Push Notification service. The studio wires the code to receive the messages, but the underlying push credentials belong to your business.

Third, system permissions on modern phones require user cooperation. On Android 12 and newer, an app cannot schedule exact alarms or automated reminders without the user granting a specific permission toggle in their device settings. The app can take them to the right screen, but it cannot flip the switch for them.

Finally, you do not get hand-tuned native controls. A native iOS date picker has a slightly different physics feel to an Android date picker. A single cross-platform app uses consistent, styled interface components across both platforms. For a business running operational tools, that consistency is usually an advantage: training documentation, screenshots and user procedures look the same regardless of which phone a worker pulls out of their pocket.