For its first three major versions, NativePHP for Mobile has been built around a fast, opinionated web view.
And it has worked incredibly well for building native apps (often called hybrid apps), especially if you want a somewhat consistent UX across platforms.
But on mobile, web views still miss the mark in a few important ways.
The Cost of Convenience#
Using a web view to ship a cross-platform app in any shape—whether in a native shell, a PWA, or a good old-fashioned web app—is a huge convenience, with incredible cost-savings, especially for smaller teams.
The web is so ubiquitous, almost everyone knows how to build for it. So in theory, leaning on web tech should be the way of the future.
But there are a number of fundamental problems with the way we (as a software industry) are doing things today that make web views subpar.
These boil down to two key issues: Performance and Accessibility.
Performance#
Web views are complex pieces of software that often use excessive system memory and other resources.
Why? Because they need to spin up JavaScript VMs, parse CSS rules, and convert plaintext HTML into DOMs and components, handling a vast array of edge cases gracefully, all while trying to maintain a smooth 60fps.
Browser vendors have worked exceptionally hard over the past 30-something years to build ever faster browsers, with incredible results. And those results have poured straight back into the underlying web views.
But no matter how fast and how efficient they get, they will never be able to rival the performance of truly native UIs.
You can argue that it's imperceptible to the user and most people don't care how an app is built, or even notice the occasional UI hang or framerate panic. All they care about is that it works.
But what you often don't hear about are the rough edges when teams fight for days, weeks or months to work around a limitation or shortcoming of a particular web view rendering issue or performance bottleneck that would be trivially avoided by just going native.
Why do teams tend to power through instead of switching? Because they're stuck between convenience and quality. They know quality leads to better outcomes, but they cant let go of the cost-savings.
The alternative is investing in two fully native apps and the relevant resources to support them. Even with AI in the mix, this is a time-consuming, costly and risky endeavor.
With SuperNative, you don't have to choose! The normal trade-offs fizzle away.
Accessibility#
Smartphones have become incredibly accessible to almost every person and are a lifeline for millions of people around the world living with accessibility issues, such as visual impairment, hearing loss, amputation, aphonia, adactyly, or some kind of motor neurone disease—to name just a few.
With powerful assistive technologies baked into the core of the operating systems on these devices, even people living with severe impairments are able to lead healthy and full lives thanks to their phones.
The accessibility story across the web stack is very strong, but there are still major issues when web views are used to build hybrid apps:
- Screen reader focus can get trapped inside the web view, or fail to enter it at all. VoiceOver and TalkBack cross the native/web boundary inconsistently.
- The back gesture or system back button may not behave as expected relative to web view history.
- Native accessibility APIs and web ARIA are bridged imperfectly. Roles, states, and live regions announced in a browser may be announced differently or not at all inside a web view.
- Accessibility labels on native chrome (headers, nav bars) can conflict with headings inside rendered pages.
- DynamicType/font scale, dark mode, reduced motion, increased contrast, and bold text settings often don't carry over automatically to web views and must be explicitly wired up.
- The platforms' own accessibility support inside their own web views is still patchy.
A great accessibility story for your apps is not just a moral obligation; in some cases it can be a legal one.
A native screen is usually accessible by default, which beats a hybrid one you have to patch.
AI Benefits#
With all of these improvements, your LLMs are happier too!
As AI-assisted development becomes more common, native UI trees are also much easier for tools to inspect, reason about and manipulate than your application nested another layer deep running inside a web view.
With SuperNative, you don't even need to think about it. These tools all just work.
The Challenge for NativePHP#
Considering these fundamental issues and opportunities, it became clear: we must support fully native UIs.
But even before this, we wanted fully native UIs. It's just a cool problem to solve. But it's also turning out to be a pragmatic one for the project as a whole.
While at first it feels great to be able to spin up an app and load it onto your phone using just your favorite web tools, it actually ends up being more complex.
It ties your app's UI to a stack of moving parts we don't own, and every upstream release becomes a risk that something breaks.
For example, Inertia 3 dropped its axios dependency and broke NativePHP apps built on Inertia. Livewire 4 began emitting filenames containing an emoji (⚡️love-you-caleb.blade.php) that our bundled PHP binaries initially couldn't read.
We spend real energy chasing a massive target that's constantly moving in hundreds of directions all at once, and the cost of that is huge.
SuperNative completely changes that equation. It's built in a stack we own end to end, from the PHP engine itself, through nativephp/mobile in your Laravel app, all the way down to the native view tree on the device.
Dramatically less dependency on third-parties and fewer moving parts.
That means our effort can be focused on making that one stack fast, stable, and capable, rather than reacting to churn elsewhere. It simply makes business sense for us to focus our efforts on SuperNative as we look forwards.
With the upcoming NativePHP for Mobile v4, SuperNative is the default architecture.
The web view isn't going away: our PHP-enriched web views will still be available as components for the cases that genuinely need HTML, but to do this you'll need to explicitly opt-in to using a <native:webview>.
For those keen to continue this way, we will be leaning more heavily on the community to support this approach over time, but we fully anticipate that once everyone sees the ease and benefits of going SuperNative our web view support can taper off.
SuperPHP#
We're just beginning to explore what's possible with this new stack and we've got some incredible things that we can't wait to share with everyone—things that only become possible when you combine the flexibility of PHP with the power of native.
All in good time.
The goal of NativePHP has never been simply to enable PHP developers to ship web apps to phones; it's to enable millions of people to build native apps. Web views were the best path to that vision when we started. SuperNative is simply the next step.
Our immediate focus is to ship and refine SuperNative as part of Mobile v4 and have NativePHP truly live up to its name.
Now it's over to you to start building with it and go SuperNative!
Here's how:
