NativePHP Desktop

NativePHP Desktop lets Laravel developers build installed applications for Windows, macOS and Linux. It packages a PHP application with the runtime it needs and connects familiar Laravel code to desktop features. A document organiser, local reporting tool or companion application for an existing service can use the same language and application structure as the team's web projects.

This listing covers the stable Desktop v2 project and its Electron runtime. The separate NativePHP Mobile listing covers applications for iOS and Android, including Mobile 4's SuperNative interfaces. The products share a name and PHP foundations, but have different rendering systems, APIs and release workflows. Use the documentation for the target you intend to ship.

Laravel inside a desktop application

The Desktop introduction describes a combination of operating-system APIs, packaging tools and a bundled PHP runtime. Your users do not need to set up PHP themselves. You build the interface with web technologies and can choose tools such as Livewire, Inertia, Vue or React to suit the application.

Electron supplies the desktop shell for this version. That makes existing HTML, CSS and JavaScript experience useful, while Laravel continues to handle application behaviour. It also makes the frontend a real design decision: a browser layout squeezed into an application window may need changes to navigation, spacing and keyboard interaction.

The Composer package is nativephp/desktop, and the source repository is MIT licensed. The installation guide lists PHP 8.3+, Laravel 11 or higher and Node 22+ for development, with Windows 10+, macOS 12+ or Linux. Check those requirements against the release you install before adapting an existing project.

Windows and menus that fit the task

The window API provides control over opening, closing, sizing and positioning application windows. Windows can have distinct identifiers, titles and routes, so an editor and a settings window can serve different purposes. Options also cover minimum sizes, remembered window state and whether a window can be resized.

For a first release, keep the window model simple. A separate window is useful when someone needs to consult two views at once; ordinary navigation may be easier when they only need to move between tasks. Think through what happens to unsaved work when a window closes and which window should receive focus afterward.

Application menus expose familiar desktop actions through a PHP API. The documentation covers predefined menus, custom submenus, keyboard shortcuts and context menus. Putting an action in the menu should lead to the same behaviour as its button in the interface, with validation and permission checks kept in the shared application operation.

Working with files and notifications

Native dialogs let users choose files or folders and select a save destination. They support options such as file filters and multiple selections. A save dialog returns a path; your application still writes the file. Handle cancellation as an ordinary outcome, and give people a clear result when an import or export finishes.

For application-owned files, NativePHP adapts Laravel's storage location to the user's application-data directory. The files documentation explains how the usual storage helpers and Storage facade work in that environment. Keep persistent user data separate from the installed application bundle so an update does not treat it as a replaceable asset.

Desktop notifications appear through the operating system and can trigger application events when clicked. They suit work that finishes while someone is using another application, such as a completed export. Keep the result available inside the application too, so a dismissed notification does not become the only way to find it.

Local data with SQLite

NativePHP Desktop supports SQLite out of the box, with Eloquent or PDO available for working with it. The database lives on the user's machine, and production startup handles migrations when the application version changes. Development uses a separate NativePHP database.

This is a useful foundation for applications that retain records between sessions without requiring a database server. It also changes release planning: a migration runs against copies of data held by individual users. Test an upgrade with representative existing records, and decide how the application will provide backup and export. Synchronisation with an online account remains an application feature to design, including conflict resolution and failed requests.

Building, publishing and updating

The build workflow bundles the application and Electron for a target platform. Signing and macOS notarisation need the appropriate configuration and credentials. Platform support does not mean that every build can be produced on any host, so plan the build environment for each operating system you intend to support.

Publishing adds uploading the resulting artifacts to a configured provider. The updater supports GitHub Releases, Amazon S3 and DigitalOcean Spaces. Automatic updates on macOS require a signed application. Versioning, update hosting and the experience of installing a new release belong in the release plan alongside the initial download.

A useful evaluation is one complete workflow: open a document, change it, save it, close the application and reopen it. Then repeat that workflow after upgrading the installed build. Check each target platform directly, including file paths, menus and keyboard behaviour. This overview describes documented capabilities; it does not report tested cross-platform builds.

Security on a user's computer

The security guide explains why a distributed application cannot treat embedded secrets like private server configuration. Keep shared service credentials out of the bundle, use authenticated HTTPS connections and restrict file operations to the locations the feature needs. PHP runs with the current user's access to the machine.

NativePHP also authenticates communication between its PHP and desktop runtime components. Preserve that protection when customising the application. Familiar Laravel structure remains valuable here: keep operations small, validate input and apply authorisation wherever the application accesses a remote service. Desktop packaging changes where the code runs, while leaving those responsibilities with the developer.

Sources: Desktop v2 documentation and NativePHP Desktop source, with feature-specific documentation linked above. Image: the official NativePHP Desktop logo from the project's brand assets, credited by NativePHP to Caneco.