Building iOS and Android apps with PHP? Understanding NativePHP
My read on what NativePHP actually buys a team, where it compresses the stack intelligently and where I would start distrusting the proposition.
11 min
Building iOS and Android apps with PHP? Understanding NativePHP
Core thesis
NativePHP is interesting not because it redefines mobile, but because it shortens the distance between Laravel teams, app distribution and product validation. The main point isn’t to replace Swift, Kotlin, Flutter or React Native, but to understand in which contexts reusing the stack pays for the tradeoffs in runtime, UI and ecosystem.
Who this article is for
- Technical leaders evaluating stacks for MVPs or internal tools
- Laravel teams curious about NativePHP
- Mobile engineers interested in mapping the real limits of the proposition
Context
Mature backend teams frequently run into the same problem: they need to create an installable experience, but they don’t want to open a new mobile engineering front right at the start. NativePHP answers that dilemma by promising to embed a PHP runtime and run a Laravel application locally on the device.
Simplified architecture
flowchart TD
User["User"] --> Shell["Native shell (Swift / Kotlin)"]
Shell --> Runtime["Embedded PHP Runtime"]
Runtime --> Laravel["Laravel Application"]
Laravel --> UI["HTML / CSS / JS UI"]
Laravel --> Native["Bridge to native APIs"]
Native --> Device["Camera, files, notifications"]How it works in practice
composer require nativephp/mobile
php artisan native:install
php artisan native:serve
php artisan native:buildMinimal example:
Route::get('/', function () {
return view('hello');
});<!DOCTYPE html>
<html>
<head>
<title>NativePHP Demo</title>
</head>
<body>
<h1>Hello World</h1>
<p>This app is running Laravel inside a mobile app.</p>
</body>
</html>Where it creates value
- Knowledge reuse by Laravel teams
- Speed gains on MVPs and internal apps
- Lower initial friction to distribute installable apps
- Possibility of offline flows in some scenarios
Where the tradeoffs bite
- Slower startup
- Higher memory consumption
- UI less faithful to native
- Smaller ecosystem
- More risk in apps with a heavy dependency on hardware, animation and polish
Positioning comparison
| Technology | Language | UI | Expected performance | Maturity |
|---|---|---|---|---|
| Native iOS / Android | Swift / Kotlin | Native | Very high | Very high |
| Flutter | Dart | Own rendering engine | High | High |
| React Native | JS / TS | Native bridge | Medium to high | High |
| NativePHP | PHP | Web UI | Low to medium | Low |
When I would consider using it
- Internal tools
- Administrative dashboards.
- MVPs
- Products with a strong Laravel team and a need to learn fast
When I would avoid it
- Core mobile product
- Highly refined UI
- Apps with heavy hardware usage
- Long roadmaps dependent on a mature ecosystem
Conclusion
NativePHP can be a valid experiment track. I wouldn’t treat it as a natural replacement for mature mobile engineering. If the goal is stack compression and early speed, it’s worth a serious prototype. If the goal is experience, scale and platform longevity, I’d stick with more established stacks.
CTA
If this topic interests you, the discussion worth having is less about whether the idea is intriguing and more about where it actually fits without generating technical debt too early.