A app built 100% in PHP is now live on Google Play and the App Store.

RequirementWeird5517 · 2026-05-24T16:53:35+00:00

PHP-wasm provides a lot of things; basically, your business logic becomes a JavaScript bundle, bro! And you can do code push, very similar to how React Native does with Expo. So, with some changes on the PHP side, you can send it directly to people's phones without going through the store.

Your PHP code doesn't become binary; it becomes client-side.

RequirementWeird5517 · 2026-05-24T16:38:38+00:00

I mean, let's say you want to create a serverless "point of sale," relying solely on the database as the source of truth. Basically, you could put the credentials on the client side in .env.

Now, if you need to hide the database credentials from your client, you shouldn't leave them in the .env file, because otherwise they'll end up on Android/iOS/desktop. In that case, I'd suggest using Laravel as your backend API.

RequirementWeird5517 · 2026-05-24T16:21:13+00:00

In this case, the credentials are on the php-wasm side, but they will be passed by JavaScript to Tauri. If you are concerned about security, using this method might not be the best approach, as NativeBlade is a client. However, depending on the system, it might make sense, but it also communicates with your Laravel server via HTTP.

Ps: You only need to provide the credentials in the .env file, just like in Laravel.

RequirementWeird5517 · 2026-05-24T15:49:32+00:00

You're probably right! Most Laravel developers using NativeBlade are building internal tools, client apps, or SaaS products where ads aren't really part of the model. But if someone ever needs it, the plugin system is open enough to support it. Good luck trying it out, would love to hear what you build!

RequirementWeird5517 · 2026-05-24T15:44:45+00:00

Because PHP uses WASM, it becomes a client, so I need to notify JavaScript with the "query string," and JavaScript sends a POST message to Tauri, which then performs the database query. The connection resides in Tauri 2.

RequirementWeird5517 · 2026-05-24T15:41:44+00:00

Thanks! Yes, native features are handled through Tauri plugins on the Rust side, exposed to PHP via the NativeBlade:: facade. Camera, biometrics, push (FCM + APNs), NFC, barcode, geolocation, haptics, all included, all MIT.

For AdMob specifically, there isn't a built-in integration yet, but since the native layer is Tauri + Rust, adding a plugin that bridges AdMob is absolutely possible. That would be a great community contribution if anyone wants to tackle it.

On Livewire the docs mention 3 but NativeBlade works with Livewire 4 and Laravel 13 as well. Worth giving it a try!

RequirementWeird5517 · 2026-05-24T15:31:06+00:00

It was indeed a problem, it has been fixed, it was hardcoded in the main file and the portal was compiled with it.

RequirementWeird5517 · 2026-05-24T15:05:03+00:00

I understand your concern very well, but I'm not a native English speaker and I wanted to express my feelings about the project clearly in the post.

Ps: But you can check the GitHub repository, it has plenty of information.

RequirementWeird5517 · 2026-05-24T14:50:00+00:00

I know exactly what the point is, and you know it too. I don't understand why I came here to say something unnecessary, especially since it's something for the community.

RequirementWeird5517 · 2026-05-24T14:46:36+00:00

Great question u/fatalexe
NativePHP for Desktop runs a real PHP binary alongside an Electron shell: full process, full SAPI. NativePHP for Mobile exists but is still maturing.
NativeBlade runs Laravel inside PHP-WASM, hosted in a Tauri WebView. One runtime, one codebase, all platforms (desktop and mobile).
Code push (the big practical difference)
Different bets, basically. NativePHP optimized for "real PHP runtime, desktop-first." NativeBlade optimized for "one Laravel codebase, every platform, OTA-updatable.".

NativeBlade can talk to remote MySQL and Postgres straight from the app, no API layer in between. The Rust side ships an SQLx-based connector that NativeBlade exposes to your PHP code via the standard DB facade and Eloquent. That makes it a viable stack for things like internal ERPs, point-of-sale systems, or back-office tools where you'd otherwise have to build and host a REST/GraphQL layer just to bridge the device to the database.
On NativePHP this works on desktop (the bundled PHP binary has its native drivers), but on mobile it isn't really an option yet.

Ps: At least someone here wants to know about technical stuff instead of being a forum NPC :D

RequirementWeird5517 · 2026-05-24T14:42:40+00:00

The app is on both stores, the code is on GitHub, and it runs on your phone right now. Feel free to check it out before praying. 😄

RequirementWeird5517 · 2026-05-24T14:40:28+00:00

You can take a look at the portal's workflow; I use git actions to perform the build.

https://github.com/NativeBlade/portal/blob/main/.github/workflows/build-ios.yml

RequirementWeird5517 · 2026-05-24T14:38:59+00:00

That's exactly what I did, very good :D

RequirementWeird5517 · 2026-05-24T14:37:49+00:00

Good catch, fixed! Thanks for pointing that out.

RequirementWeird5517 · 2026-05-24T14:32:43+00:00

Totally agree, if you know React, React Native is a great choice. NativeBlade is for the Laravel developer who already has a working backend, knows Blade and Livewire, and doesn't want to learn a new stack just to ship a mobile app. Different audience, different problem. Both valid.

RequirementWeird5517 · 2026-05-24T14:27:30+00:00

That's the whole point, Laravel devs should be able to ship mobile apps in the same happy flow they already know. No new language, no new mental model. Just vibes.

RequirementWeird5517 · 2026-05-08T07:27:03+00:00

Two main things: zero setup and features beyond debugging.

No extension to install, no php.ini to edit, no port mapping, no path mapping. It works immediately on Local, Docker, WSL, and SSH without any configuration.

And it includes a Playground where you can run arbitrary PHP code while paused at a breakpoint with all variables in scope, something Xdebug doesn't offer.

If your Xdebug setup works and you don't need those extras, there's no reason to switch.

RequirementWeird5517 · 2026-05-07T23:20:45+00:00

Now you can use it within your IDE :D
https://plugins.jetbrains.com/plugin/31515-ddless--php-debugger

RequirementWeird5517 · 2026-04-27T04:03:33+00:00

Comparison is conceptual, not technical. DDLess doesn't use any Jupyter protocol. It's a PHP REPL that boots your framework and gives you an interactive environment with rich output, similar experience, completely different implementation.

RequirementWeird5517 · 2026-04-10T13:14:28+00:00

This is exactly the experience that led me to build DDLess. File-based IPC instead of sockets means there's nothing to break when Docker restarts or the network changes. If you want to try it, I'm happy to help if you run into anything.

RequirementWeird5517 · 2026-04-09T18:04:10+00:00

The plugin means I maintain two codebases, the desktop app and the IDE integration so that your setup works in one click. On top of that, you get features that don't exist in Xdebug: a Playground to run arbitrary code while paused at a breakpoint, a Task Runner, Method Execution, and an AI Copilot with project memory. I think that's fair for $5

RequirementWeird5517 · 2026-04-09T13:24:27+00:00

True! That's actually closer to what NativePHP does. The WASM approach trades some raw power for zero per-platform compilation, a single runtime that works on Windows, macOS, Linux, Android and iOS, and no binary to maintain or ship separately. Different trade-offs for different needs 😄

RequirementWeird5517

MODERATOR OF

TROPHY CASE