NativePHP in 2024

[simonhamp]

Hi all,

Firstly I want to say a huge THANK YOU to all of you who have tried out NativePHP during its alpha and continue to support the project by spreading the word, filing issues and sending in PRs.

We are absolutely blown away by this community and your willingness to 'muck in' and help each other solve problems. Please keep that up.

We're also thrilled to see all the great stuff you've been producing: from your prototypes and apps, to tutorials in blog posts and videos. It's been incredible.

It's 2024: LFG!

I know there have been very few formal updates from us over the past few months. That's going to change this year.

There are many reasons for why we've been collectively less involved, but the primary reason has been a lack of available time.

As many of you know, building open source is often a labour of love. NativePHP started out as merely an idea, a proof of concept. But the interest in it has been phenomenal.

Marcel and myself still believe strongly in it and are determined to make it production-ready in 2024.

We really appreciate your continued patience and support, but I'm also here to say the time for waiting is almost over. Let's do this!

Our Goals for 2024

Production ready 🟢

What does this mean exactly?

It means that the core packages all reach a point (let's call it v1) that we’re happy enough with their stability to commit to no breaking changes from one week to the next (unless a breaking change is unavoidable, e.g. for security reasons).

It also means that we think NativePHP will be in a position for you to distribute your apps to end users safely.

We've still got a few things to do before we get to that point, but the stability of the alpha has given us great confidence that we're on the right path already.

Will both the Electron and Tauri drivers be available?

Yes! Another big part of being production-ready is to have both drivers available. Read on for an update on the Tauri driver and how what that means for the Electron driver too.

Will builds be secured in some way so that my PHP source code isn’t discoverable?

At this time, it’s tricky to say. We had hoped coming into 2024 that we’d have some better news on this front, but it’s a very tricky problem to solve for PHP.

Frankly, PHP has never really been built with this need in mind. This can be seen in the fact that there isn’t already a good solution for this on the market.

While a few folks are working on various implementations that show great promise, none are ready for prime time just yet.

We're excited about the progress these projects are making and we're actively involved with some of them, but for now, we’re going to have to say that it's very unlikely that we're going to have a mechanism to protect your source code in time for NativePHP v1.

We know for some of you this will be a dealbreaker.

We have some solutions that we’ll be deploying to make sure apps are as secure as they can be, but source code encryption and/or obfuscation looks like it's going to be hard to get for v1.

Still, we’re hopeful that this story changes throughout the course of the year.

What about Windows support and cross-compilation?

See the section on Windows support below for more detail.

Cross-compilation - specifically, building for multiple platforms from a single platform - isn't something that both drivers support.

For Electron, there's some support for this. Tauri doesn't have this kind of tooling yet.

We’ll provide as much as we can to help you get compiling for every platform you want to support, with documentation and sample GitHub Actions etc.

What about PHP version support?

We are working on supporting both PHP8.2 and PHP8.3 and making both of these available to you to use.

PHP8.1 is now in ‘security fixes only’ territory, so we will be phasing it out over the course of the year and will stop supporting it before it reaches end of life on 25 November 2024.

We’re going to work strictly to the same support schedule as PHP as this will help maintain security for your applications and your users.

It will also mean we can keep NativePHP moving forward without having to worry too much about backwards compatibility.

We will only make the latest stable release of the currently-supported PHP binaries available and we strongly encourage you to only use those.

This will also hopefully encourage you to keep your apps up to date, using the latest versions of Laravel and other tools.

Tauri driver 🦀

Tauri is where NativePHP began life. Tauri is an exceptional framework in the space of building browser-based, cross-platform web apps because of its focus on security and performance.

We’ve been heads-down, working on getting a Tauri build ready right from the beginning of NativePHP, but we’ve also set ourselves a high bar for it.

While we were able to create an Electron build for the NativePHP alpha quite rapidly thanks to the accessibility of JavaScript/TypeScript and the huge Electron ecosystem and community, Tauri has proven to be a different beast.

Built on Rust (which neither me nor Marcel know deeply) and having some quite different properties (as it doesn’t ship a browser engine), Tauri required much more of an investment than we had originally anticipated.

After discussions with some of the core Tauri team, we also agreed that a key feature of moving forward with Tauri was to be able to build applications that aren’t reliant upon web servers.

Wait. No web servers? What do you mean? 🤯

Almost every app built with PHP today requires a web server of some kind. The primary exception to this would be a CLI application.

In a typical web application setup, the web server (e.g. nginx, Caddy, Apache etc) is what your user’s browser communicates with, handling incoming HTTP requests and outgoing responses, distributing the work between the different parts of your infrastructure.

The web server takes care of a number of steps for you: it transforms HTTP requests into the relevant environment variables, manages multiple PHP processes or threads (depending on your configuration) so your app is readily available, serves static assets from outside of the PHP runtime, and of course sends your app’s response HTML/JSON etc.

For the NativePHP alpha, it was extremely convenient to stick with this paradigm by booting up web servers on both sides of the application: the PHP side and the Electron side.

This kept things familiar and approachable whilst we worked on building out the core interfaces. But it comes at a cost.

If every app you opened on your computer spun up two web servers (which is what every NativePHP app does today), you'd have a lot of issues: firstly, there would be a performance penalty at multiple points, especially on machines with limited resources - locking up TCP ports, system memory and CPU cycles.

But more importantly, security would be a significant concern! Every web server is an attack vector, which would mean every NativePHP app your users install increases their risk level.

Hardening all of these servers is a complex challenge that we could avoid by skipping this reliance upon web servers altogether.

As everything is contained on the user’s device, there's no need for the broker-like services that a traditional web server brings - even a basic dev one like PHP’s built-in server - as there are no network boundaries to cross for one part of your app to talk to another.

And because any running instance of your NativePHP app is most likely to be in use by only one user at a time, it's quite straightforward for the runtime (Electron/Tauri) to manage the necessary PHP processes/threads directly.

So we've been working hard over the past few weeks to move NativePHP away from its dependency on web servers, to simplify your apps, make better use of your user’s system resources, and provide a much tighter security perimeter.

We’re exploring this under the Tauri driver first and we’ll look to port that to Electron once it's stable.

We’re really excited about the progress we’re making on the Tauri driver and will finally be releasing the first version of it in the next few weeks.

Windows support 🪟

For those that don’t know, NativePHP uses static builds of PHP created by the static-php-cli library.

What’s a static build of PHP?

PHP is usually built in such a way that PHP extensions can be loaded dynamically at runtime. This is one of the features of PHP that has made it so flexible and easy to adopt, which is a big part of why it runs a huge proportion of the Internet.

It means you can change PHP’s configuration, adding and removing extensions dynamically, without having to recompile PHP every time. If your extension is already built, you simply enable and configure it (usually in your php.ini) and relaunch your SAPI (Apache, nginx etc).

It also allows system administrators to tune PHP for the exact workload they have, so they can completely remove unneeded extensions easily. This can significantly improve PHP’s performance whilst still keeping it flexible.

This is fine when you’re installing PHP onto a set of servers and each needs different extensions. But it’s not a great way to distribute PHP to lots of people who are not system administrators, as it results in a sprawling set of executables and dynamically-linked libraries which aren’t really consumer-friendly. If not configured carefully, it can also result in potential security holes.

A static build, on the other hand, creates a single binary that contains all of the needed extensions compiled in. It means you can’t add or remove extensions at runtime, but it comes with the added benefits of being faster - because enabled extensions don’t need to be loaded dynamically - and also more secure - an attacker can’t load their own extensions at runtime.

It's also possible to enforce a given configuration that isn't changeable by simply editing a text because it's baked into the binary.

At the end, you get a single file, the PHP binary which can work on any machine that's the same architecture (OS and instruction set) as the one it was created on, e.g. Mac-ARM64 or Win-x86.

That means you can distribute this single file to another person and now they have the exact same PHP as you do.

Windows support has been on its list of priorities for some time and the good news is that incredible progress has been made in recent weeks.

We’ve been closely involved in the static-php-cli project, ever since I was able to use it to build the distributable PHP executable that got NativePHP off the ground last March.

We’re excited to announce today that official Windows support is finally coming to NativePHP!

We hope to have this available in the next few weeks. Look out for the Windows release here soon!

We need your support 🙏

As excited as we are for all of this, we have to be honest: finding time to make meaningful progress on Open Source projects is not easy, especially on something as complex as NativePHP.

As many of you know, Marcel is part of the BeyondCode team, making awesome premium products for developers like Tinkerwell, What The Diff, and Laravel Herd.

That's a time-consuming job on its own, let alone having multiple open source projects to support.

And it's a similar story for me too. Personally, I am freelancing as a Laravel consultant and engineer, and the last few months of 2023 required me to focus on paid client work above everything else.

While that occupied most of my time, it has afforded me a small window of opportunity to work on other projects. Obviously NativePHP was going to be one of those projects.

But for NativePHP to keep making progress this year - the progress that we all so desperately want to see - it really needs at least one person on it consistently.

I offer myself as tribute! I would absolutely love to be able to devote all of my time to NativePHP. But the reality is that it just doesn't make financial sense yet to do so—not without your help.

Please sponsor our work via GitHub.

If you see real potential in NativePHP we would really welcome your support. We want to keep it free and open source so that the barrier to entry remains low for thousands of developers. We believe it has huge potential thanks to how rapidly you'll be able to build rich, robust, native app experiences.

We have an initial funding target which will allow us to consistently support NativePHP - which means me being available on Discord, responding to GitHub issues and PRs in a timely fashion and building new features.

The target is just $2,500/month.

Sponsors will also get some great benefits:

• Added to the Sponsor role on Discord, with Sponsors-only privileges, including...
• Access to the #sponsors-only channel.
• Plus, advance updates and early access to all things NativePHP, such as beta testing new features before we share them with the world

And more to come.

---

I hope you're as excited about these updates as we are to bring them to you. I'm really looking forward to what we can do together in 2024 and what new opportunities NativePHP might unlock for you.

Now, come on team, let's get to work!

[dbelyaeff]

Great! Simon, how is the progress? You've wrote in that post about a few weeks to release Tauri driver for NativePHP. Is there a release date?

[simonhamp]

Hey there. Tauri progress is coming along. My estimate of "next few weeks" was definitely ambitious as my focus has been on Windows support and stabilising the existing ecosystem. But now that WIndows support is out there, I should be able to get back to Tauri and make some progress. 👍🏼

[abishekrsrikaanth]

@simonhamp just checking to see if there are any new updates on Tauri and Electron? Also DM'ed you on discord for access to the sponsor only channel, waiting to hear from you on the same. Got an app pretty close to Production, just not sure how to proceed in terms of release and deployment. Would love to get some update.

[alnutile]

@dbelyaeff @abishekrsrikaanth can you all maybe explain why "Tauri driver for NativePHP" is so important?

Just curious as a user of NativePHP who added a ticket about it not even installing on my Mac (Herd PHP or even Valet) and the other Issues

That just seem to be more foundational why this one is getting attention?

@simonhamp the update you provided here can I assume that "Production Ready" is just:

It means that the core packages all reach a point (let's call it v1) that we’re happy enough with their stability to commit to no breaking changes from one week to the next (unless a breaking change is unavoidable, e.g. for security reasons).

It also means that we think NativePHP will be in a position for you to distribute your apps to end users safely.

We've still got a few things to do before we get to that point, but the stability of the alpha has given us great confidence that we're on the right path already

And not these bigger changes like Tauri?

Maybe I am missing the importance of Tuari that will lead to the issues related to "Error when running php artisan native:serve on a new laravel app" and "[Bug]: Fresh Install on Mac with Herd (and without Herd) " other "base issues" (eg developers can not really get going on an app)

Otherwise I just feel like questions like "when will Tuari be ready" might be putting pressure on your before other foundational things are ready?

This is not to put down anyones requests or needs just trying to understand the order of the road map so I can pester you accordingly :)

[dbelyaeff]

It's all that simple – bundle size and memory consumption.

Electons app unpacked size is about 300+ Mb. Tauri apps can be as little as 3-4Mb per bundle.

[simonhamp]

From my point of view, Electron is not production-ready yet. I hope to share more specifics about this soon (nothing secretive, just not confirmed yet, so don't want to jump the gun), but suffice to say that Tauri is going to be the driving force for making NativePHP really secure.

So it's not just about bundle size, performance and memory footprint, a huge part of it is security.

[abishekrsrikaanth]

@alnutile, may be https://twitter.com/simonhamp/status/1749933255564947806 gives you some context on why tauri. But I do agree that some of the existing issues do require some attention, especially those that affect the development of apps. I had to go through different workarounds to get a fresh installation of NativePHP source code to compile and get it to work.

[alnutile]

it does look impressive, thanks for the link

[abishekrsrikaanth]

A lot of changes have been made to how the app loads with Tauri, which makes it a better choice for starting apps in NativePHP than electron right now. There are a few apps I've already finished that use the Electron driver, but I can't get them to my clients smoothly because of problems that are already being discussed and being talked about. It does need personal attention, especially when it comes to making releases and deployments, since the auto-updates don't seem to work right for apps that aren't registered. Hopefully, all of these are being taken care of with the Tauri driver. Updates to the documentation on how to register apps and enable auto-updates would be great.

[dlopez525]

Hi Simon, there is documentation for DEEP LINKING, I'm trying to make it work on Windows but nothing. I would appreciate your help. I also want to take the opportunity to congratulate you on the project.

[simonhamp]

Thanks 🙏🏼

Can I just confirm what you mean by 'deep linking'? What are you trying to achieve?

In fact, let's move this to another discussion thread please

[ceau74]

Hi Simon.

First of all, thank you so much for the great work of NativePHP project, although still in alpha version, it has many important features.

Like me, many project's fans want the project to move to production version. I'm sure the production version, many developers will be sponsors the project..

Thanks for all.

NativePHP project is amazing.

[simonhamp]

Thanks for the kind words 😊

It's a bit of a catch-22 situation, because this isn't an easy project - there are many complex parts and it needs a lot of work to get it to a point where it can be considered 'production-ready'.

That takes funding. So if you're keen to see it get to production quality, I'd urge you to support the project financially in some way.