# NativePHP mobile-air: one Laravel codebase shipped as an iOS and Android app > An embedded PHP runtime turns an existing Laravel application into a native mobile binary. The releases show a young project shipping release notes every week. **NativePHP/mobile-air** — Create mobile applications with PHP - Repository: https://github.com/NativePHP/mobile-air - Website: https://nativephp.com - Stars: 1,193 · Forks: 97 - Language: C - License: NOASSERTION - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/nativephp-mobile-air ## The C in the language field is the runtime, not your app GitHub reports the primary language of NativePHP/mobile-air as C, which is misleading if you take it literally. This is a PHP package: `composer.json` sits at the top level next to `phpstan.neon` and `phpunit.xml`, `src/` and `bootstrap/` hold the PHP, and `bin/` and `resources/` carry the pieces that get compiled into the native shell. The C comes from the embedded PHP runtime and the native layer beneath it, which is the part that has to exist as compiled code on both platforms. So the language field is describing the runtime rather than the code you write, and if you are scanning GitHub by language to find PHP projects with mobile support, this one will not show up in a PHP search. The rest of the tree is conventional Laravel and tells you what the project considers its own surface: `config/`, `database/`, `routes/`, `schema/`, `tests/` and a `docs/` directory. There is a `_ide_helper.php` too, which is the file a package publishes so an IDE can resolve facades and helpers it ships. ## An embedded runtime, not a wrapped web page The pitch in the README is that PHP developers should not have to learn Swift or Kotlin to ship a mobile app. The mechanism it names is an embedded PHP runtime with a persistent mode for fast, long-lived execution, which is the phrase that separates this from the usual webview approach. Your Laravel application runs on the device, and native platform capabilities are reached through a plugin system documented separately. That plugin API is the part that decides how much of the platform you can actually use. The README links to a plugins introduction page and lists a specific set of services as part of the offering: background tasks running on device, queue workers, scheduled jobs, and push notifications through APNs and FCM. Queue workers and scheduled jobs are the interesting claim, because they mean work continues when the app is not in the foreground rather than finishing only while a screen is open. A single Laravel codebase produces both an iOS and an Android build. There is no separate mobile branch to keep in sync, which is the practical argument for the approach and also its main constraint: anything the plugin API does not cover has to be built by you, in Swift or Kotlin, and then maintained across two platforms. ## Hot reload is the feature that changes the edit loop Development speed is where this kind of tool is won or lost, and hot reload for simulators and physical devices is listed in the README's feature set. The release notes show what it actually took to make that reliable, which is more informative than the feature bullet. In 4.5.1, hot reload got an explicit trigger on iOS and was restricted to debug builds on Android. The same release gave each iOS simulator and device its own hot reload port, so two simulators running side by side no longer fight over one socket. Both changes point at the same underlying difficulty: a device-attached development server has to find its way back to the right machine, and mobile networking makes that harder than it looks on a laptop. Responsive breakpoints landed in the same release, with `md:`, `lg:` and `xl:` classes resolved against the live window width rather than a fixed assumption. That is a small change on paper and a large one on a device that rotates, splits into a slide-over view, or runs on a tablet. ## Migrations and the NATIVEPHP_RUNNING flag Shipping a Laravel app means shipping its migrations, and release 4.5.1 spent several changes on that. It set `NATIVEPHP_RUNNING` before any artisan runs, and it changed migration to happen once per platform rather than once per process. It also reordered the package jobs migration to run after the app's own migrations, and separately fixed five cases where `native:install` reported success while doing the wrong thing. Those four items read as a single theme: getting database state correct on a device, where the same application code may run several times and where a silent partial failure is much worse than a visible error. Setting the flag before artisan runs is what lets application code detect that it is executing natively rather than on a server, and making it reliable matters because a Laravel app that branches on that flag will take a different code path on device. Version 4.5.0 also added async tasks, described as background PHP work with UI completion callbacks, and restored PHP 8.3 support. If your existing application targets a specific PHP version, that restore is worth checking against your own constraints before you plan around it. ## The README claims MIT, GitHub recognised no licence Here is a discrepancy you can resolve yourself. The last section of the README says NativePHP for Mobile is open-source software licensed under the MIT license, pointing at a `LICENSE.md` file that does exist in the tree. GitHub's licence field for the repository, however, records no recognised licence, reported as NOASSERTION. Both statements describe files that are there. What they do not settle is whether `LICENSE.md` contains an unmodified MIT text with a copyright line, because a licence file can be named that and still be incomplete, and an unrecognised field usually means the detector could not match what it found. If you intend to build on this, read `LICENSE.md` yourself rather than trusting the badge or the field. A second, softer tension sits in the README's own framing. It calls itself accessible, powerful, and gives Laravel developers everything needed to go from idea to App Store, then immediately redirects every reader to nativephp.com/docs/mobile for installation, core concepts and the full API. The README is a signpost, and the documentation site is the manual. ## There is no install command in the README at all Worth stating plainly, because it is unusual: this README contains no code block, no command and no configuration snippet. Installation is entirely delegated to the documentation site, with the getting started page, the plugin introduction, and separate pages for queues and the background tasks bundle. That is a defensible choice for a project whose install path depends on your Laravel version, your Composer setup and both native toolchains. It also means you cannot evaluate readiness from the repository alone. Everything you would want to check, which Laravel versions are supported, whether Xcode is required for iOS builds, what the Capacitor-style layer does about permissions, lives on a site the README points at. The project supports the discussion around it in other ways: weekly livestreams and tutorials on an official YouTube channel, a video course for people who want a structured path, and a Discord community for questions. The contribution guide is also on the documentation site rather than in the repository, which fits a project where the answer to most questions is version-dependent. ## Conclusion NativePHP mobile-air is a real answer to a question most teams hit only once they already have a Laravel application they want on a phone. The embedded runtime, persistent mode, queue workers and push notifications through APNs and FCM are the parts that make it more than a webview, and the release notes through 4.5.1 on 2026-09-19 show the work is current rather than aspirational. Start with the getting started page at nativephp.com/docs/mobile, then read the plugin documentation, because the plugin system is where the interesting work lives and the README itself gives you no install command. Two things to verify first: the MIT claim in the README against the unrecognised licence field in the repository, and whether your target store accounts require the capability declarations that background work on device implies. ## FAQ ### How do I turn a Laravel app into a mobile app with NativePHP? NativePHP mobile-air runs your Laravel application on an embedded PHP runtime inside a native iOS or Android binary, so a single codebase produces both. The README contains no install command; the getting started page on nativephp.com covers installation, core concepts and the available API. ### Does NativePHP mobile-air support background work and push notifications? The README lists background tasks running on device, queue workers, scheduled jobs and push notifications via APNs and FCM among its capabilities, each documented separately on the NativePHP site. ### What license is NativePHP mobile-air released under? The README states MIT and points at a LICENSE.md file in the repository. GitHub's own licence field reports no recognised licence for the repository, so read the LICENSE.md file if you plan to build on it. ### Does hot reload work on a physical phone with NativePHP? The README lists hot reload for rapid development on simulators and physical devices. Release 4.5.1 added an explicit trigger on iOS, limited hot reload to debug builds on Android, and gave each iOS simulator and device its own hot reload port. ## Sources - [Issues](https://github.com/NativePHP/mobile-air/issues) - [NativePHP/mobile-air on GitHub](https://github.com/NativePHP/mobile-air) - [Project website](https://nativephp.com) - [README](https://github.com/NativePHP/mobile-air/blob/main/README.md) - [Releases](https://github.com/NativePHP/mobile-air/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nativephp-mobile-air