Why we are building NativeWatch

A NativePHP app carries Laravel onto someone's computer or phone. That changes where a bug happens and how you discover it. The failing code may be running on a device you cannot reach, in an older app build, after a network connection disappeared.

NativeWatch exists to make those failures easier to investigate. Our focus is error tracking for NativePHP desktop and mobile apps: collecting useful evidence from the app, grouping repeated failures into issues, and giving a team a practical starting point for a fix.

The ambition is straightforward. A developer should be able to move from “the app stopped working” to a specific occurrence, the relevant build, and the evidence available for that failure. Getting there requires careful capture and clear limits, as much as it requires a dashboard.

#Start with the app's actual architecture

NativePHP builds on Laravel and a bundled PHP runtime. Desktop also brings Electron into the picture, while mobile has native platform code and can combine native screens with webviews. Those boundaries are visible in NativePHP's own desktop documentation and mobile documentation.

A Laravel exception is not interchangeable with a JavaScript failure or a native crash. Each has a different observer, different timing, and different evidence. A PHP exception may be reported while the app continues. A fatal native failure may leave a report that can only be collected after the next launch.

Our goal is to make those distinctions understandable in one workflow. We want developers to know what produced an occurrence and what it can tell them, without requiring them to reconstruct the entire reporting path during every investigation.

#What NativeWatch does today

The capabilities below describe our reviewed prelaunch implementation; the desktop and mobile SDK packages are not yet publicly published on Packagist as of 29 October 2026.

The current desktop and mobile SDKs share PHP capture, breadcrumbs, release and environment context, and a bounded outbox. Reportable Laravel exceptions can reach a project where repeated occurrences are grouped into issues. Teams can investigate an issue, resolve it, and see it reopen when the same failure returns. The errors and issues guide explains that workflow.

Webview JavaScript reporting is available through an explicit script directive. It observes errors and unhandled rejections in the window where it is installed. That scope matters: adding it to a layout does not instrument Electron's main process or make every JavaScript failure observable. The JavaScript guide describes the setup.

The mobile plugin adds native crash reporting with an explicit diagnostic choice. Native collection and later delivery are tied to that consent state. A rebuild is required to include the native plugin changes. We also provide controls for withdrawing consent and clearing pending SDK reports, documented in privacy and consent.

These are separate integrations with shared investigation tools. We want the product to preserve those boundaries clearly, because the difference between “the integration is installed” and “this crash path was verified” matters when you depend on a report.

#Better evidence from the build you shipped

Two current features help turn an occurrence into a more useful starting point.

For PHP, NativeWatch can use release evidence published from CI to suggest commits that changed reported lines between shipped builds. It matches the occurrence's exact build identifier. This is a lead for investigation, not proof that a particular commit caused the bug. Missing build evidence should remain missing evidence, rather than being replaced with whatever happens to be on the default branch. See releases and commits.

For iOS native crashes, matching dSYMs can resolve supported frames into function names and source locations. The match depends on the actual binary identity and architecture. Apple's symbolication documentation explains why the symbols must correspond to the distributed build. NativeWatch's iOS symbolication guide covers upload and investigation.

Neither feature manufactures certainty. Optimized code and system frames may lack a usable source line. A changed line may be related to a failure without causing it. Useful tooling shows the evidence and lets the developer reason from it.

#Reliability needs visible boundaries

An app can crash without a network connection. NativeWatch therefore keeps pending reports on the device and supports later delivery. That is valuable, but it does not mean every report will arrive. Storage is bounded, users can remove app data, diagnostic choices can change, and an installation may never reopen.

We want to describe those conditions plainly. The offline delivery guide explains the queue and retry behavior. Capture and disk operations also have a cost; we do not describe error reporting as having no performance impact.

Verification should be equally precise. An API test establishes API behavior. A screenshot establishes what a screen displayed. A native build establishes that code compiled. A real device crash followed by a matching received event establishes something different. Each kind of evidence is useful when it is labeled accurately.

#Where we want to go

We are researching how NativeWatch could serve ordinary Laravel and Inertia web applications, and how a mobile client's failure could be connected to the remote API request involved in it. Those are future ambitions. Cross-application client/API correlation and a broader web monitoring product are not shipped capabilities being promised here.

That research raises practical questions: how to carry a request identity across boundaries, distinguish a failed request from a failed client operation, and avoid joining unrelated events. We want answers that developers can verify before presenting a unified trace as fact.

For now, the priority is the NativePHP app: a clear installation, honest capture coverage, useful issue context, and build evidence that points to the code actually shipped. If that is the problem you are working on, start with getting started, choose the platform guide, and verify a real error in your own app.