Weave Code
Desktop Laravel Package
nativephp/desktop
NativePHP for Desktop lets Laravel developers build native desktop applications using familiar PHP and Laravel tools. Package apps for Windows, macOS, and Linux with native windows, menus, filesystem access, notifications, and more—no new language required.
Create desktop applications with PHP
Frequently asked questions about Desktop
- How do I install nativephp/desktop in my Laravel application?
- Install it with Composer using composer require nativephp/desktop, then publish the package configuration and run the install, serve, and build Artisan commands that ship with the package. Integration is conventional Composer package adoption, so it works alongside your existing Laravel app rather than replacing it. Expect to spend real time on the build and release pipeline rather than on the code changes.
- Which Laravel and PHP versions does NativePHP Desktop support?
- The package assumes a modern Laravel application and bundles its own PHP runtime into the shipped binary, so your local PHP version and the runtime inside the app are separate concerns. The overview does not publish a full supported version matrix or a deprecation policy, so check the Composer constraints and recent release notes before committing. Confirm your Laravel and PHP minor versions align early, since this is one of the first questions to resolve before approval.
- Do I need to learn Electron, C++, or another language to build a desktop app with Laravel?
- No. NativePHP Desktop lets you keep writing PHP and Laravel for application logic while the interface is rendered with HTML, CSS, and JavaScript in an embedded native webview. The native surface is the shell plus bridged API calls for windows, menus, tray icons, dialogs, and notifications. That means your team keeps Eloquent, queues, validation, policies, and Artisan instead of staffing a separate desktop stack.
- Can I cross-compile a macOS, Windows, and Linux build from a single machine?
- In practice, cross-platform binaries generally require per-OS build runners, and macOS artifacts need macOS hardware for signing and notarization. Plan for CI cost and secrets management for signing certificates across each target. Run a spike to validate build reproducibility before you commit, because the build pipeline, not the PHP code, is the main feasibility constraint.
- What native desktop APIs does NativePHP Desktop expose to Laravel?
- The package exposes OS primitives through a PHP-first API, covering native windows, menus, tray icons, dialogs, notifications, clipboard, and filesystem access. Because the UI is HTML/CSS/JS in an embedded webview, the native layer is the shell and those bridged calls rather than a fully native widget toolkit. Wire these calls behind service classes so they stay testable and swappable.
- How do code signing and notarization work when distributing a NativePHP desktop app?
- You are responsible for obtaining certificates, signing each platform artifact, notarizing macOS builds, and warming up Windows SmartScreen reputation. These are recurring operational tasks rather than one-time setup, and OS policy changes can force you back into the pipeline. Budget for certificate storage and rotation in CI, and treat this as medium-to-high ongoing risk.
- Does NativePHP Desktop work with Livewire, Inertia, Vue, or plain Blade?
- Blade, Livewire, Inertia, and Vue all work because the UI is rendered in an embedded webview. The caveat is that asset bundling and routing assumptions differ in a desktop context, so verify how your front-end build is packaged. Also confirm your data layer, for example SQLite locally versus a remote API, and your queue driver choice for offline scenarios.
- How do I test a NativePHP desktop application?
- Keep your existing Laravel testing conventions and wrap native API calls in service classes so they can be mocked in tests. Most domain logic remains ordinary Laravel code and stays covered by your current test suite. The harder part is per-OS QA, since three platform targets with divergent behaviors grow the verification matrix.
- How do auto-updates and PHP security patches work for shipped desktop binaries?
- There is no managed patching layer described, so you own shipping PHP runtime security updates to endpoints on your own cadence. Confirm whether a supported auto-update mechanism exists and whether it is self-hosted or vendor-hosted before you approve the package. Also clarify the crash reporting and logging story on end-user machines, since web-app operational habits do not automatically transfer to desktop.
- Is NativePHP Desktop production-ready, and how does it compare to Electron or Tauri?
- It is MIT-licensed core with a small maintainer team, and the project sits in early-adopter territory, so pinning versions and budgeting for major-version migration is wise. Compared with Electron or Tauri it avoids a rewrite, letting you reuse Laravel domain logic for internal ops consoles, back-office tooling, kiosks, and offline-capable field apps. It is a weak fit for GPU-bound rendering, sub-frame-latency interaction, or deep OS extension work, so confirm licensing terms for build tooling and updater add-ons before shipping to external customers.
Weaver
How can I help you explore Laravel packages today?