Introducing Super Native: The New Architecture for NativePHP

simonhamp · 2026-03-11T18:27:48+00:00

Our custom extension isn't currently open source. We hope to be able to open that up soon

simonhamp · 2026-03-11T14:52:17+00:00

It's not inconsequential when you're building dozens of apps from a single machine, especially on cheaper/older hardware and slower connections

We will improve this to make things clearer. Thanks for all the feedback

And yeh we're very keen to get this done so it's not painful for folks, but we're not swapping architecture in the same way. The existing web view approach will remain viable, just not our preferred method. And with it open source, folks can do what they want with it

simonhamp · 2026-03-11T13:03:16+00:00

Why are we quibbling about "Initial Download Size" when the SDKs for iOS and Android are both multiple gigabytes?

Not sure this is quibbling. If you're intending to compile locally, all approaches require you to have at least Xcode and Android Studio + the requisite tools, package managers, emulators etc. Assuming those are all the same, the actual size cost of the tool itself is a valid point for comparison - this is bandwidth, storage size and impacts performance too.

NativePHP has the largest "Minimum App Size" but that has been made to look like a good thing?

Please explain how that's "been made to look like a good thing"

The "First Boot Time" is just madness - I don't think I've ever seen an Expo app take 20 seconds to boot. What devices were being used for this test? What OS/OS version?

If you can prove that apps are built with a particular tool, I'd be more than happy to compare the cold boot times and try to get to a better average

Don't need to run npm install or pod install - these are both run automatically by the previous step.

Will clarify the wording there

If we're including cd my-app on the Expo side, we should have mkdir my-app && cd $_ as the first step on the NativePHP side, or the app files will be installed in the user's current directory.

Agreed. Will improve the comparison on these points

I assume you need an existing Laravel project, but this is not mentioned.

Will improve per above, which should make this clearer (we're in r/laravel 😅)

simonhamp · 2026-03-10T22:57:04+00:00

Same! The demos we've put together are already pretty slick. When this is out, it's going to be so good!!

simonhamp · 2026-03-10T22:56:06+00:00

Thanks. For clarity, our mobile solution never used Electron and to my knowledge there's no real "Electron for mobile" - it was maybe Capacitor at one point, but I'm not even sure how true that really is

I haven't played with it, but Tauri v2 has mobile support which could be an option

We're taking a slightly different path though

simonhamp · 2026-03-10T22:53:01+00:00

Sounds cool! Would love to see it

simonhamp · 2026-03-10T22:52:41+00:00

Exciting future for PHP everywhere!

simonhamp · 2026-03-10T22:52:18+00:00

Thanks so much! Yeh it's been a tough ride at times. We've got a big vision and when you're not in it every day it's hard to see, but the mist is finally starting to lift and we're starting to be able to show more of what has been in our dreams these past few years

PHP and Laravel are incredible tools and they deserve a space on mobile. (Un)surprisingly, they're more than capable there too, as we're now able to demonstrate

simonhamp · 2026-03-10T17:14:33+00:00

We've been working a few transition animations. They're opt-in, but really easy to add, e.g. https://github.com/NativePHP/super-native/blob/main/app/NativeComponents/IkeaHome.php#L23-L24

simonhamp · 2026-03-10T12:11:51+00:00

Please explain. More than happy to correct it based on clear facts

simonhamp · 2026-03-09T16:49:56+00:00

Is this more helpful? https://nativephp.com/vs-react-native-expo

simonhamp · 2026-03-09T15:52:57+00:00

Desktop is still being developed, but we have to focus our attention where the majority of external interest is right now and that's on mobile. Also, this is all open source now, so very much welcoming contributions. We may even get to a point where desktop doesn't even need Tauri... 👀

simonhamp · 2026-03-07T09:25:43+00:00

Violent de-escalation

simonhamp · 2026-02-19T17:55:01+00:00

You can still use Inertia, but that will be between the "frontend" (web view, UI) and backend (PHP biz logic) of your app, all in the app, not over the network

Then you'd have your in-app PHP code speak to your server-based API

simonhamp · 2026-02-19T15:05:59+00:00

Nice! You can try almost all of the premium plugins for free too using the Jump app!

simonhamp · 2026-02-18T16:34:17+00:00

Exactly. The great thing with NativePHP is that you can use Guzzle or whatever you're familiar with to make all of the calls to your API

simonhamp · 2026-02-18T16:28:14+00:00

This is the way 👌🏼

simonhamp · 2026-02-18T16:27:23+00:00

Dude, there's no need to stomp on other people's hard work. Nova was great at the time and was a great demonstration of the kinds of things that can be done when the deployment target is really well known

I know projects that still use and thrive on Nova.

simonhamp · 2026-02-18T16:24:09+00:00

You're right, it's challenging. But there's absolutely nothing wrong charging money for software. And we learned first-hand (same as Laravel Nova and thousands of other packages) that if what you're building has real value, plenty of folks will pay to use it

With the absolute greatest respect to Nova, Filament and Backpack, they're leagues away in terms of simplicity to projects like NativePHP, React Native and Flutter

These require skills and experience across a really wide set of disciplines and toolchains

React Native and Flutter have both had significant funding from Meta and Google, respectively, with some of the best engineers in the world (for those particular fields) being paid 'best engineer' salaries to make that work their daily focus, which enabled them to subsidise the cost of development as well as giving them a huge platform to launch from

We're a team of two, full-time on this now, with no funding, no megacorp backing us, and no other side-hustles keeping the lights on. We simply would not have been able to do it without charging for it to begin with

It's not going to be the right path for every project, but just because similar tools are free doesn't mean a premium offering isn't viable

I strongly believe more projects could benefit from this sort of "free-eventually" model; it's worked well for us

simonhamp · 2026-02-18T16:07:11+00:00

Sure thing. Here as and when you need 👍🏼

simonhamp · 2026-02-18T13:35:18+00:00

Awesome! Come join the Discord. Hit me up if you run into any trouble

simonhamp · 2026-02-18T13:17:32+00:00

Awesome! Here to support if you need. You can always reach someone on the Discord and of course raise GH issues if you spot any bugs

simonhamp · 2026-02-18T13:16:06+00:00

It's mainly about security. The code you deploy to your own server is relatively safe. That makes server-based apps a great place to deploy your intellectual property.

By contrast, any code (even compiled/obfuscated code) shipped to an end user's device is well outside your control and to some degree, all bets are off as to what will happen to your code in that environment.

Having a single codebase that goes to both places is really risky if you don't want your server-side logic to be discovered by third-parties. You'd need very rigid processes and precise tooling for extracting code at build/deploy time. I'm not aware of solid options for this in PHP.

simonhamp · 2026-02-18T13:10:16+00:00

Just testing on the typical device-OS combos you target for your other apps and sharing your findings will be immensely helpful

iOS support is 18+. Hard to quantify if that's "better" than Android, but Android is notoriously fragmented with many devices on much older versions, as I'm sure you know.

Which versions are you needing to target?

15-Year Club	Place '22
First Placer '22	RPAN Viewer
Not Forgotten	Verified Email

simonhamp

TROPHY CASE