Starter Desktop Flux Laravel Package

Product Decisions This Supports

• Desktop distribution strategy. This starter kit is the fastest path from a Laravel web app to a shippable native desktop app (macOS/Windows/Linux) built on NativePHP Desktop. It directly enables the “do we ship a desktop client?” decision and the follow-on “how fast can we prototype it?” question.
• Build vs. buy for scaffolding. Rather than spending engineering time wiring a desktop shell, menus, auto-updates, and a build pipeline, adopting this kit makes the first desktop spike a same-day exercise via laravel new.
• Ecosystem alignment as a roadmap input. The 2.0.0 release tracks NativePHP Desktop v2 — meaning the package now inherits the current upstream support window, security posture, and feature set. Roadmap discussions should treat the desktop runtime version as a dependency risk item, not a detail.
• Security and maintenance baseline. The release rolls up dependency bumps (form-data, vite) that resolve open advisories. For a PM, this is a low-cost, high-signal “we are current” claim you can make to security review without a bespoke audit.
• Use cases this unlocks: internal tools packaged for offline field use, kiosk/point-of-sale style apps, companion desktop apps for an existing SaaS, and demos that need to look like real software rather than a browser tab.

When to Consider This Package

Adopt it when:

• You already have (or plan to have) a Laravel codebase and want a desktop target without a second frontend stack.
• You need a working prototype in days, not a quarter — the starter kit removes the “hello world native window” phase entirely.
• You are comfortable pinning to NativePHP Desktop v2. The major version bump here is deliberate lockstep with upstream; the package is only as current as the runtime it targets.
• Your team accepts that a desktop app is a new release surface — code signing, installers, auto-update channels, and OS-level QA are part of the cost, and none of that is handled by the starter kit alone.

Look elsewhere when:

• You need a mature, long-term-supported desktop framework with guaranteed LTS windows. NativePHP is young; a 1.x → 2.x major bump with no deprecation runway (the guidance is simply “stay on 1.x”) is a real migration event.
• Your desktop requirements are heavy native integration (deep OS APIs, complex peripherals, GPU work). An embedded-PHP desktop shell may become the wrong tool.
• You need cross-team stability: a starter kit that jumps a major version to stay aligned upstream means your dependency review cadence must match theirs.
• You are on NativePHP Desktop v1 today and have no capacity to migrate — stay on 1.x, but treat that as a dated commitment with a defined exit, not a resting place.

How to Pitch It (Stakeholders)

For executives: We can offer a desktop version of our product using the stack we already have, starting from a maintained scaffolding package rather than a blank page. The 2.0.0 release keeps us on the current version of the underlying desktop runtime and clears known dependency vulnerabilities, so adopting it now means we are starting from a supported, patched baseline. The cost is not the prototype — it is the ongoing desktop release engineering (signing, installers, updates) that follows.

For engineering: This is the NativePHP desktop starter kit, now on nativephp/desktop:^2.0. Version 2.0.0 is a major bump taken to stay in lockstep with NativePHP’s own versioning — there is no incremental deprecation path, so v1 users must pin 1.x or migrate. The release is mostly dependency hygiene (form-data, vite security bumps) plus the runtime alignment. Recommendation: evaluate it in a timeboxed spike, pin the major version explicitly in composer, and log the NativePHP runtime version alongside our other framework dependencies so the next major bump is a planned task rather than a surprise.