NativePHP v4 introduces SuperNative, a rendering mode that compiles Blade components directly into real SwiftUI views on iOS and Jetpack Compose views on Android, with no web view or HTML involved. Screens are now PHP classes extending NativeComponent paired with Blade templates using native elements styled by Tailwind classes. PHP and native code share memory directly, eliminating bridge round-trips, and accessibility features like VoiceOver and TalkBack work natively. Web views remain supported as an embeddable component for screens not yet converted. A new Pest testing suite lets developers test native screens without a device using a FakeBridge. The only breaking change in v4 is that four plugins (Device, Dialog, File, System) are now folded into core, requiring their standalone packages to be uninstalled before upgrading. Version 4.1, released August 7, added the #[Locked] attribute, TreeObservers for debugging, and Tailwind class validation warnings.
Table of contents
# How SuperNative Works# Writing a SuperNative Screen# Keeping Your Web Views# Testing Native Screens in Pest# Version 4.1# Upgrading from v3Questions this post answers
What is the breaking change when upgrading NativePHP from v3 to v4?
The Device, Dialog, File, and System plugins are now bundled into core with nativephp/mobile, and the package declares Composer conflicts with the four standalone plugin packages. Developers must run 'php artisan native:plugin:uninstall --core-v4' to remove the standalone packages before Composer will resolve, then bump the constraint to ~4.0.0 and run 'php artisan native:install --force'. daily.dev surfaces upgrade guides like this so Laravel teams avoid Composer conflicts mid-migration.
How does NativePHP v4 SuperNative render native UI without a web view?
NativePHP built its own Blade engine that converts Blade components into a fixed-length binary representation instead of HTML, and a native-side interpreter reads that byte array to build real SwiftUI views on iOS and Jetpack Compose views on Android. PHP and the native layer share memory directly, so there is no bridge round-trip on every tap and screens start faster than a web view. Developers evaluating cross-platform mobile approaches track architecture shifts like this on daily.dev.
Can I test NativePHP native screens without a simulator or physical device?
Yes, NativePHP v4 ships a Pest testing suite with a FakeBridge that captures every element tree a component publishes and every native call it makes, running entirely in-process without a simulator. Native::visit() resolves route parameters through registered native routes, and tap() presses a matching element before re-rendering, with 'php artisan native:make-test' scaffolding new test files. Teams building CI pipelines for mobile apps follow testing patterns like this via daily.dev.
129.2K Impressions4 Comments