NativePHP v3.1: 10x Faster Mobile Apps with Persistent PHP Runtime

NativePHP v3.1 dropped in March 2026, and calling it a point release undersells what actually changed. The team shipped the biggest performance improvement in the project’s history, added background queue processing, expanded Android device support by a massive margin, and filled in the ICU/Intl gap that was blocking real-world packages like Filament from running on iOS.

If you have been watching NativePHP from the sidelines waiting for it to feel production-ready, this is the release worth your attention.

The Problem v3.1 Solves

Every version of NativePHP before 3.1 booted a full Laravel kernel for every single request the app made. Register service providers, resolve the container, handle the request, tear it all down. On every tap. Every page load. Every navigation event.

That boot cycle cost roughly 200-300ms per request. On a phone, that lag is noticeable. It is the difference between an app that feels native and one that feels like a web page wrapped in a shell.

The v3.1 release fixes this at the architecture level.

Persistent Runtime

The core change in 3.1 is simple in concept and dramatic in effect: Laravel boots once, and the kernel is reused for every subsequent request.

Response times drop from 200-300ms down to 5-30ms. That is roughly a 10x improvement. Taps feel instant. Navigation feels native. The gap between “PHP mobile app” and “real native app” shrinks considerably.

Enabling it is straightforward:

// config/nativephp.php

'runtime' => [
    'mode' => 'persistent', // 'classic' reverts to per-request boot
    'reset_instances' => true,
    'gc_between_dispatches' => false,
],

persistent is the new default. The framework handles Livewire state, router state, and facade instances automatically across requests. If a persistent boot fails for any reason, it falls back to classic mode so your app does not crash.

For most applications, you can upgrade to v3.1 and get the performance improvement without touching any application code.

Background Queue Workers

Queue support was the most requested missing feature in NativePHP. v3.1 delivers it using ZTS (Thread-Safe) PHP with a dedicated worker running on a separate thread, completely isolated from the main request cycle.

Setup is as minimal as it gets:

QUEUE_CONNECTION=database

That’s the entire configuration change. Dispatch jobs exactly as you would in any Laravel application:

use App\Jobs\SyncData;

SyncData::dispatch($payload);

The worker starts automatically when the app boots. Jobs are persisted to the SQLite database on the device. They survive app restarts. Laravel’s standard retry and failure handling works without modification.

This unlocks use cases that were previously off the table: background API syncing, file processing, push notification handling, and any other task that should not block the UI thread. It works on both iOS and Android.

Android 8+ Support

Previously, NativePHP Mobile required Android 13 (API 33). That cut out a significant portion of real-world Android devices, especially in markets where older hardware stays in service longer.

v3.1 drops the minimum to Android 8 (API 26), which covers the vast majority of active Android devices globally. The team achieved this via static linking for better performance and reliability, and the SDK targets are now configurable:

// config/nativephp.php

'android' => [
    'compile_sdk' => env('NATIVEPHP_ANDROID_COMPILE_SDK', 36),
    'min_sdk' => env('NATIVEPHP_ANDROID_MIN_SDK', 33),
    'target_sdk' => env('NATIVEPHP_ANDROID_TARGET_SDK', 36),
],

If you need to support Android 8 specifically, set NATIVEPHP_ANDROID_MIN_SDK=26 in your .env. The defaults remain at API 33 for new projects, so existing builds are unaffected unless you explicitly change the target.

ICU/Intl on iOS

ICU and the PHP intl extension have been available on Android for a while. iOS was the gap. v3.1 closes it.

Full ICU support on iOS means packages that rely on intl for date formatting, number formatting, and pluralization now work on both platforms without workarounds. The practical headline here is Filament: a full Filament admin panel can now ship as a native mobile app on iOS and Android.

ICU adds around 10-15MB to the binary. If you want to keep your app size down and do not need intl, you can opt out:

php artisan native:install --without-icu

But for most apps, the default ICU support with English locale coverage is the right choice.

PHP Version Matching

NativePHP now reads your composer.json and automatically selects the matching PHP binary when downloading. Supports PHP 8.3 through 8.5. Binaries are cached locally in nativephp/binaries, so you are not re-downloading them on every build.

This is a small quality-of-life change, but it removes a recurring source of friction where the framework’s bundled PHP version did not match what you were developing against.

Upgrading

v3.1 has no breaking changes. Update your composer.json:

"require": {
    "nativephp/mobile": "~3.1.0"
}

Then run:

composer update
php artisan native:install --force

The --force flag updates native project files, PHP binaries, and config to match v3.1. Without it, native project files from earlier versions stay in place.

Other Developer Experience Changes

A few smaller improvements worth noting:

native:plugin:register now discovers and registers multiple plugins in a single pass
native:run warns you if registered plugins have not been compiled
Platform names accept shorthand: ios/i and android/a work anywhere you would type the full name
react/http and react/socket dependencies have been removed from the core
Laravel 13 is fully supported

Where This Puts NativePHP

The v3.1 performance story changes the calculus for teams evaluating NativePHP against React Native or Flutter. The persistent runtime means your app no longer carries a 200-300ms overhead per interaction. Background queues mean you can build async workflows. The expanded Android support means you can realistically target the full market.

The framework is still PHP and still Laravel under the hood, which means your existing knowledge, packages, and tooling all apply. That is NativePHP’s core value proposition. v3.1 makes it harder to argue that the performance trade-off is too steep to accept.

If you have a Laravel application and have been considering a mobile companion, the barrier to entry is lower than it has ever been.