Microsoft ended Xamarin support on May 1, 2024, and it still turns up on lists of open source mobile tools. Xcode turns up too. Apple ships it free, for Mac only, and closed. Both mistakes come from treating “free to download” as if it meant the same thing as a license the Open Source Initiative has approved.
The frameworks, SDKs and toolchains that build iOS and Android apps from source code under an approved license are what this article means by open source mobile app development software. Nothing else gets in.
Reach decides how much a tool has to cover. Statcounter Global Stats put Android at 69.17% and iOS at 30.81% of worldwide mobile page views in September 2026.
An Android-only tool therefore leaves out nearly a third of those page views, and an iOS-only tool leaves out more than two thirds.
What counts as open source mobile app development software?
Public code on GitHub doesn’t make a project open source. The license has to let anyone read, modify and redistribute the source.
The Open Source Initiative sets the bar. Its Open Source Definition lists ten criteria a license must meet, and both permissive and copyleft licenses can pass.
The category spans frameworks, UI toolkits, runtimes, test tools, build tools and backends used across mobile application development.
Every framework ranked here needs an approved license, and it has to be free in a production app. It also needs signs of life, meaning dated releases or a maintainer statement that development is active.
How rendering and runtime models differ between native, cross-platform and hybrid tools
It starts with who draws the interface. Native apps use the platform’s own toolkit. Cross-platform frameworks either paint their own pixels or drive native views, and hybrid tools run web code in a webview.
That choice sets the language, the app size and how quickly new OS features show up. It is also why cross-platform app development gives up some platform fit in return for shared code.
Native development
Native means Swift on iOS and Kotlin on Android, each with its own UI toolkit.
Apple announced SwiftUI and Google announced Jetpack Compose in 2019, and both use a declarative style. A peer-reviewed review in Informatics (2025) names the cost: two codebases in exchange for the best performance and platform fit.
Cross-platform with its own rendering engine
Flutter skips the platform’s UI widgets and paints every pixel itself.
Dart code compiles to native code, and since Flutter 3.27 the Flutter documentation lists Impeller as the default renderer on Android API 29 and higher. On iOS it is the only option.
The upside is the same interface on every platform, with engine fixes shipping inside the app instead of waiting for an OS update. The downside is that platform widgets don’t come along automatically, so a new system control only appears once Flutter or a plugin redraws it.
Cross-platform with native components
React Native 0.76 (October 23, 2024) made the New Architecture the default, and 0.82 (October 8, 2025) made it the only option, per the React Native blog.
The older design passed messages over an asynchronous bridge. The New Architecture replaced it with direct JavaScript Interface (JSI) calls, so JavaScript can call a native function and get the result back synchronously.
Roundups that still describe a “JavaScript bridge” are describing the legacy architecture.
React Native renders real platform views from JavaScript or TypeScript. NativeScript does something similar with the platform’s native engine and no WebView, reaching native APIs directly from JavaScript. Kotlin Multiplatform sits a little apart, since it shares code between platforms and lets each keep its native UI.
Hybrid with a webview
Hybrid tools run HTML, CSS and JavaScript inside a webview wrapped in a native shell.
Cordova generates the native platform code at build time, while Capacitor treats the native projects as source files that live in your repository (InfoQ, 2019; Capacitor README).
Earlier performance studies, summarized in the Informatics review, found that webview rendering struggled in graphically intensive apps.
For a side-by-side view of cost and speed, a separate guide weighs native, hybrid and cross-platform apps against each other.
Best open source frameworks for cross-platform apps
Flutter and React Native lead the open source cross-platform field, with Kotlin Multiplatform, .NET MAUI and NativeScript covering narrower cases.
The order below follows adoption data first and maintenance activity second. A separate breakdown of how Flutter and React Native compare goes deeper on that one pairing.
| Framework | Language | How the UI is drawn | License |
|---|---|---|---|
| Flutter | Dart | Own engine (Impeller) | BSD 3-Clause |
| React Native | JavaScript, TypeScript | Native views, New Architecture | MIT |
| Kotlin Multiplatform | Kotlin | Native UI or Compose Multiplatform | Apache 2.0 |
| .NET MAUI | C# | Native controls | MIT |
| NativeScript | JavaScript, TypeScript | Native views, no WebView | Apache 2.0 |
The surveys don’t agree on which of the two leaders is ahead, and that disagreement is the useful part.
- JetBrains’ 2023 Developer Ecosystem Survey reported 46% for Flutter and 35% for React Native on usage
- Stack Overflow survey data from 2019 to 2024 shows no statistically significant gap between them in popularity
- Flutter’s median admired score over those years was 68.1%, against 57.2% for React Native
- LinkedIn listed 2,037 React Native postings, 1,835 for Flutter and 615 for MAUI on February 23, 2025, which is the hiring picture
Jošt and Taneski of the University of Maribor pulled all of this together in their 2025 Informatics review. They tabulated the JetBrains and Stack Overflow surveys and counted the LinkedIn postings themselves.
Read together, Flutter leads on usage share and satisfaction, React Native leads on hiring, and popularity is a statistical tie. The Pragmatic Engineer’s reading of Stack Overflow’s 2024 data adds geography: Germany and India lean Flutter, the US and UK lean React Native.
Team skills settle the choice faster than any survey does.
Flutter and Dart
Google’s SDK for building mobile, web and desktop apps from one codebase, Flutter, is released under the BSD 3-Clause license.
You get an identical interface on every platform and a single toolkit for mobile, web and desktop, and Stack Overflow data shows higher satisfaction than for React Native or MAUI. The costs are learning Dart and a smaller pool of job postings than React Native has.
Judge Flutter’s maintenance from its docs, not GitHub’s Releases tab. The Informatics snapshot lists October 2023 as the latest GitHub release, yet the Flutter documentation describes behavior introduced in version 3.27.
React Native and Expo
React Native keeps one JavaScript or TypeScript codebase and renders real platform views. It is MIT licensed and developed by Meta with community contributors.
Expo sits on top as a toolchain, and its versions track React Native: SDK 54 was the last to allow the legacy architecture, and SDK 55 uses React Native 0.83 (Expo documentation).
Expo Go supports only the New Architecture.
| Pros | Cons |
|---|---|
| JavaScript and React skills carry over | Older libraries can lag the New Architecture |
| Strongest hiring demand of the three leaders | Lower long-term satisfaction in survey data |
| Real platform views | Upgrades drop legacy code, as in 0.82 |
Kotlin Multiplatform
Google lists Cash App, Duolingo and Google Docs among apps built with Kotlin Multiplatform, and it officially supports the approach for sharing business logic between Android and iOS (Android Developers).
JetBrains develops Kotlin Multiplatform under the Apache 2.0 license. The Kotlin documentation rates its core as stable on Android, iOS and desktop JVM, with web through Kotlin/Wasm still in Beta as of October 2026.
Compose Multiplatform adds shared UI on top. Version 1.8.0 made iOS support stable in May 2025, and JetBrains measured about 9 MB added to an iOS app compared with the same UI built in SwiftUI.
Native UI stays an option on both platforms, and having Google and JetBrains behind it helps. Teams do need Kotlin skills, usually Swift as well when the UI stays native, and the web target is still in Beta.
.NET MAUI
Microsoft built .NET MAUI as the evolution of Xamarin.Forms, and it points existing Xamarin apps to MAUI with an upgrade assistant.
One C# and XAML project builds native apps for Android, iOS, macOS and Windows under the MIT license.
It fits teams already on C# and .NET, and it reaches desktop as well as mobile. The community and hiring pool are smaller than Flutter’s or React Native’s, and MAUI only appeared in Stack Overflow’s survey from 2023.
NativeScript
NativeScript gives JavaScript direct access to native iOS and Android APIs and renders with the platform’s own engine, no WebView involved.
It is Apache 2.0 licensed and works with Angular, Vue, Svelte, React and other front-end frameworks, according to its repository. Check the latest release there before committing.
Native UI from plain JavaScript or TypeScript is the draw. The catch is that it sits outside the predominant frameworks in the Informatics survey review, so expect to write more platform glue yourself.
Open source tools for hybrid and web-based mobile apps
Capacitor is the default pick for new projects that run web code inside a native app. Ionic Framework and Apache Cordova are the other open source options.
Web teams get the most from them, since an existing web codebase becomes a store-ready app without a rewrite. That trade is the core appeal of hybrid apps.
Ionic Framework
Ionic announced Ionic Framework 9 on August 19, 2026, and release 9.0.6 followed on September 30, 2026, so the project is still shipping.
The framework is MIT licensed, built on Web Components, and works with Angular, React and Vue (Ionic documentation). Version 9 supports Angular 18 through 22 and requires React 18 or later for its React output target (Ionic blog). The same code also ships as progressive web apps in the browser.
You get prebuilt mobile UI components, a choice of Angular, React or Vue, and web skills that transfer directly. Webview rendering limits graphics-heavy apps, though, and the components are web-styled, not platform widgets.
Capacitor
Capacitor is Ionic’s native runtime for web apps, released under the MIT license.
Ionic announced Capacitor 8 on December 8, 2025, making Swift Package Manager the default dependency manager for new iOS projects in place of CocoaPods. Existing CocoaPods projects keep working.
The native projects stay in your repository as source, not regenerated at build time, and most Cordova plugins work unchanged. Ionic Framework is optional, though without it you build the native UI yourself.
| Strengths | Limits |
|---|---|
| Native projects stay under your control | Still renders in a webview |
| Reuses most Cordova plugins | Native UI needs Ionic Framework or your own code |
Apache Cordova
Cordova was the original webview wrapper, and it is still maintained: the Apache release catalog lists cordova-android 15.0.0 on March 6, 2026 and 15.1.0 on July 22, 2026.
The Apache Software Foundation hosts it under the Apache 2.0 license. In August 2020, as Adobe wound down PhoneGap, the Cordova team stated that the project remained active and maintained.
It’s free, Apache-hosted, and has a deep plugin catalog that Capacitor also reuses. The weak spot is the plugin system. Swift arrived in 2014, but Cordova’s own plugin system supported it only in 2019, according to InfoQ. Access to native projects is limited too, because platform code is generated at build time.
For a new web-based app, pick Capacitor. Existing plugin-heavy projects can stay on Cordova. If you want ready-made mobile UI components on top, add Ionic Framework.
Which native development tools are actually open source?
Swift, the Android Open Source Project and Jetpack Compose are open source. Xcode is free but closed.
Swift and Xcode
Apple open-sourced Swift on December 3, 2015, under the Apache 2.0 license with a Runtime Library Exception. It runs on Linux and Windows as well as Apple platforms.
Xcode is free and macOS only, but it isn’t open source, and App Store submission requires an Apple Developer Program membership.
The language is open, but iOS builds still run through Xcode.
Android Studio and the Android Open Source Project
Android Studio is Google’s official Android IDE, built on JetBrains’ IntelliJ IDEA. A walkthrough of what Android Studio includes covers the tooling itself.
Two different things share the Android name here, and their licenses differ. Android Studio’s source is Apache licensed, but the downloadable build and its SDK components fall under Google’s own terms. The Android Open Source Project is the platform code itself, with Apache 2.0 as the preferred license and Linux kernel patches under GPLv2.
Jetpack Compose
Google announced Jetpack Compose in May 2019 as Android’s declarative UI toolkit.
It is written in Kotlin, and Google publishes Compose and its samples under the Apache License 2.0, the same license that covers most of the Android Open Source Project.
When native is the better choice
Native makes sense when the app depends on the platform more than it shares with the other one. Needing new iOS or Android features on release day is one sign, and separate iOS and Android teams already being in place is another. Graphics-heavy screens push the same way.
Teams building native apps pay for it in two codebases, which the Informatics review names as the main cost of the approach.
Which open source license fits a mobile app?
For a closed-source or commercial app, a permissive license is the safe default. The MIT License, BSD 3-Clause and Apache License 2.0 all allow commercial use with notice requirements only, while the GNU General Public License is the one that causes trouble on Apple’s store.
| License | Patent grant | Copyleft | Closed-source app |
|---|---|---|---|
| MIT License | None in the text | None | Fine |
| BSD 3-Clause | None in the text | None | Fine |
| Apache License 2.0 | Yes, Section 3 | None | Fine |
| Mozilla Public License 2.0 | Yes | Per file | Workable |
| GNU General Public License | Depends on version | Whole work | Contested on the App Store |
Permissive licenses
The MIT License is a short text. It asks you to keep the copyright and license notice and says nothing about patents. BSD 3-Clause has the same notice duty, plus a clause that bars using the project’s name to endorse your product.
The Apache License 2.0 adds what the other two lack. Under Section 3, each contributor grants every user a perpetual, worldwide, royalty-free patent license, and that license ends for anyone who sues claiming the work infringes a patent.
You can ship Apache-licensed code inside a proprietary app if you keep the license text, carry any NOTICE file and mark significant changes (University of Pittsburgh licensing guide).
Copyleft licenses
Apple removed the VLC iOS app from the App Store on January 7, 2011, after one of VLC’s developers complained that Apple’s store terms breached the GNU General Public License (InformationWeek).
The Free Software Foundation backed that reading. VideoLAN developer Jean-Baptiste Kempf disputed it in a November 2010 post, arguing that the store terms had changed and the answer was not simple.
Apple settled the case by removal, as it had with a GNU Go port earlier (Free Software Foundation), which left the question open.
The Mozilla Public License 2.0 offers a middle path. Copyleft applies file by file, so you publish changes to MPL files and keep the rest of the app closed.
Android’s own project goes further and avoids LGPL libraries in userspace, citing compliance problems for device makers and app developers (Android Open Source Project).
For a closed-source app, keep GPL dependencies out unless a lawyer has signed off.
License checks for dependencies
A framework’s license covers the framework. Every plugin and library in the app carries its own.
Microsoft’s .NET MAUI binding packages show the layering: the bindings are MIT licensed, while the Java library underneath, such as an androidx navigation package, is Apache License 2.0 (NuGet).
Export every dependency’s license from the package manager, flag any GPL or AGPL entry in a closed-source app, and keep the notices and NOTICE files that permissive licenses require.
What open source mobile development really costs
The framework license costs nothing. The money goes to store accounts, macOS build minutes, backend hosting and cloud build services.
These figures were checked in October 2026.
- The Apple Developer Program costs $99 per year, per Apple’s membership page
- Google Play Console registration is $25, paid once, per Google Play Console Help
- A GitHub-hosted macOS runner (3-core or 4-core) runs $0.062 per minute, per GitHub’s billing documentation
- Supabase’s Pro plan is $25 per month, per Supabase’s pricing documentation
- Expo EAS Starter is $19 per month plus usage, per Expo’s billing FAQ
Store accounts
Both stores charge before the first release, and they bill differently.
Apple wants an annual membership, which it waives on request for qualifying nonprofits, accredited educational institutions and government entities that distribute only free apps. Google takes one registration payment per developer account, and asks for a government ID and a card in your legal name.
A separate breakdown of Google Play’s store fees covers the charges beyond registration.
Build minutes and cloud builds
iOS builds need a macOS machine, which makes CI the most variable cost for a mobile team.
GitHub documents standard hosted runners as free in public repositories, which suits an open source app, and self-hosted runners as free to use. Private repositories draw on a monthly quota, and macOS jobs use it up faster than Linux jobs.
Expo’s cloud builds work differently. EAS gives free accounts a limited number of low-priority builds that reset monthly, and an account that uses its quota waits until the next calendar month (Expo documentation).
Expo and the Expo SDK are free and MIT licensed. EAS, the cloud service for builds, submissions and updates, is where pricing applies.
Backend hosting
Supabase is an open source backend released under the Apache License 2.0.
As a backend as a service/), it runs managed in Supabase’s cloud or on your own servers.
Self-hosting removes the plan fee, but it does add work. You pay for servers and storage, and you run the upgrades, backups, connection pooling and monitoring yourself.
Pricing guides disagree on the Pro plan’s unit. An older Supabase pricing post billed it per project, while the current documentation charges the plan fee per organization and bills compute per project, with a monthly compute credit.
How to test, build and release an open source mobile app
The stores fix the order of a release, not the framework.
- Run end-to-end tests on emulators, simulators and real devices
- Create signing credentials for iOS and Android
- Build in CI, on a macOS runner for iOS
- Upload an Android App Bundle and an iOS build made with Xcode 26 or later
- Run a closed test with real testers
- Submit for store review and release
- Ship fixes through a new build or an over-the-air update
Testing with Appium and Detox
Appium is an open-source framework that drives iOS, Android and other apps over the W3C WebDriver protocol, with drivers such as UiAutomator2 for Android and XCUITest for iOS doing the platform work.
Detox was built for React Native and works as a gray-box end-to-end framework under the MIT License. It watches asynchronous work in the app to cut flaky tests, and its README lists compatibility with React Native 0.77 through 0.84 on the New Architecture.
If one suite has to cover several frameworks, Appium fits. Detox makes more sense for a React Native app where flaky tests are the main pain.
Signing, building and uploading
| Item | iOS | Android |
|---|---|---|
| Signing material | Certificates and provisioning profiles | Upload key and keystore |
| Upload format | Build from Xcode 26 or later | Android App Bundle |
| Key custody | Team-held, synced with fastlane match | Google holds the app signing key |
fastlane, an MIT-licensed Ruby toolchain, automates screenshots, provisioning profiles and releases for iOS and Android. Its match tool syncs certificates and profiles across a team through git.
With Play App Signing you keep an upload key and can request a reset in Play Console if it is lost or compromised. Without it, losing the signing key means you can no longer update the app (Android Developers).
The Android App Bundle has been mandatory for new Google Play apps since August 2021 (Android Developers Blog).
Run all of this from continuous integration so every merge produces a signed, uploadable build.
Closed testing and store review
Personal Google Play accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in for 14 continuous days before applying for production access (Google Play Console Help).
Third-party guides commonly say organization accounts are exempt, so check Google’s page for your account type.
On iOS, TestFlight handles beta distribution once the Apple Developer Program membership is active. A step-by-step guide to publishing an app on Google Play covers the console screens for the rest.
Over-the-air updates and store rules
Apple’s App Review Guideline 2.5.2 bars apps from downloading or running code that introduces or changes features. The Apple Developer Program License Agreement, section 3.3.1(B), allows downloaded interpreted code that leaves the app’s primary purpose unchanged, keeps signing and sandbox protections intact and does not create a storefront for other apps.
Bug fixes, copy, translations and layout changes in the JavaScript or web layer can go over the air. Anything that touches native code, SDKs, permissions or entitlements needs a new build.
Google Play covers the same ground in its Device and Network Abuse policy.
When open source mobile app software is the wrong fit
Most of the problems sit around the code, not in it. Hosted services get retired, platform deadlines force yearly upgrades, maintainers run short of reviewers, and nobody owes you support.
Hosted services can disappear
Microsoft retired Visual Studio App Center on March 31, 2025. Its CodePush service for React Native and Cordova apps was part of it, and Microsoft’s notice offered a standalone version that teams run independently.
An open source SDK does not keep a hosted backend alive.
Platform deadlines set your upgrade calendar
Since April 28, 2026, Apple has required uploads built with Xcode 26 or later and the iOS 26 SDK (Apple Developer). Google Play follows from August 31, 2026, when new apps and updates must target Android 16, API level 36 (Google Play Console Help).
A framework that lags either deadline blocks your release. Expo published guidance on the Apple change on April 27, 2026, the day before it took effect.
Skip a year of upgrades and the gap becomes technical debt that the next deadline collects.
Maintainers can run short of reviewers
Backing by a large company does not guarantee review capacity.
In late 2024, members of the Flutter community announced Flock, a fork meant to expand the pool of people working on Flutter and speed up development (Phoronix). The Informatics review notes the same motive, which is access to fixes without waiting for the official team.
Flock’s organizers describe it as a complement that tracks upstream Flutter, not a replacement, so read it as a capacity signal, not a death notice.
Nobody owes you support
Open source licenses provide the software as is. The BSD 3-Clause and Apache License 2.0 texts both say so, and Supabase’s self-hosting documentation describes self-hosted installs as community-supported.
Budget for the support contract you don’t have. That might be a paid vendor plan or a consultant on retainer, or it might just be engineers who can read the framework’s source.
If the team cannot absorb a yearly upgrade cycle, a vendor-supported platform costs less than the open source one.
How to choose a framework for your team
Start from the skills the team already has, then check target platforms and interface style. Survey rankings come last.
- Teams on JavaScript or TypeScript with React should look at React Native
- An existing web app or web team points to Capacitor, with Ionic Framework for UI components
- If performance comes first and a new language is acceptable, Flutter
- Kotlin or Android-first teams have Kotlin Multiplatform
- C# and .NET shops have .NET MAUI
The Informatics review ties the decision to expertise in the same way: React and web teams find React Native more intuitive, and it points performance-first teams toward Flutter’s rendering and compilation.
Hot reload is not a tiebreaker. The review lists it for Flutter, React Native and Ionic alike.
Mobile plus desktop points to .NET MAUI or Kotlin Multiplatform, and mobile plus browser points to Flutter or Ionic Framework. A pixel-identical branded interface favors Flutter, while a platform-native look favors React Native, .NET MAUI or Kotlin Multiplatform with native UI.
The obvious pick isn’t always the right one. A working web or native app is better wrapped with Capacitor or shared through Kotlin Multiplatform than rewritten in Flutter or React Native. Capacitor’s README describes it as designed to drop into any existing modern web app.
The framework is one layer of the tech stack for app development, and the backend, test tools and release automation have to fit it too.
Open Source Mobile App Development Software FAQ
Can you build iOS apps without a Mac?
Not fully. You can write code on Windows or Linux, but the iOS build needs macOS, because Xcode runs only there.
Cloud services such as EAS Build and GitHub-hosted macOS runners supply that Mac remotely. The iOS Simulator also ships with Xcode, so local testing needs a Mac.
Is PhoneGap still available?
Not from Adobe. Adobe discontinued PhoneGap and PhoneGap Build on October 1, 2020, and pointed developers to Apache Cordova, the open source project underneath.
Existing PhoneGap content stays readable in Cordova, so migration means switching tooling, not rewriting the web code.
How secure are open source mobile frameworks?
Open code can be inspected, but that doesn’t make a framework secure. Much of the risk sits in the plugins and dependencies you add on top.
Check each one for its license, recent release dates and open issue activity before it ships in your app.
What is the difference between a framework and an SDK?
It mostly comes down to who calls whom. A framework sets the structure of your app and calls your code. An SDK is a bundle of libraries, tools and documentation for building on a platform.
Many products are both. Flutter describes itself as an SDK, and React Native as a framework.
Prototyping a Framework Before Committing to a Full App
Open source mobile app development software earns a commitment once a prototype of the riskiest feature has passed a real store submission. Weak spots appear at the edges of an app, such as camera access, background tasks and custom graphics, not on a login screen.
Run the checks in this order, because each later one costs more to reverse:
- Build the riskiest screen first
- Send that build through signing and a store test track
- Audit every dependency’s license
A missing camera plugin surfaces on day one, while a license conflict found after launch forces a rewrite.
The prototype delays feature work and proves only one slice of the app. This advice was verified on October 30, 2026, and changes if a chosen framework misses the next Apple or Google SDK deadline.
With the framework settled, the mobile app development cost of the full build is the next figure to pin down.
- Notepad++ for Mac: Does It Exist and What to Use Instead - November 13, 2026
- What Communications Teams Should Ask Before Commissioning a Mobile App - November 12, 2026
- How to Install Node JS in VS Code and Run Your First Script - November 11, 2026
