Getting started with NativeWatch
Create a NativeWatch project, configure your NativePHP app, obtain diagnostic consent and verify your first stored event by UUID.
By NativeWatch Updated
NativeWatch collects errors from your NativePHP app and groups related occurrences into issues. Start with one development project and verify a real event before adding release information or native crash tests.
Create a project
Create or join a workspace, then add an app with the appropriate platform: Desktop, iOS or Android. The project's Setup guide contains its ingest key and installation steps. Keep separate projects when you need separate error streams, such as independent iOS and Android apps.
GitHub is optional. You can configure reporting and receive your first error without connecting a repository. Repository connection becomes useful when you add release and commit evidence.
Choose the integration
Both SDKs require PHP 8.4 or later within PHP 8, and support Laravel 11, 12 and 13.
| Your app | Guide | What to verify first |
|---|---|---|
| NativePHP desktop | Install the desktop SDK | PHP exception capture in the packaged app |
| NativePHP iOS or Android | Install the mobile SDK | Consent, PHP reporting, then the rebuilt native plugin |
| A web view in either app | JavaScript errors | An uncaught error in the rendered web view |
As of 29 October 2026, the SDK packages are not listed on public Packagist. The installation guides name the packages and commands, but Composer needs access to their distribution before those commands can succeed. Confirm package access before changing your app's dependency settings.
Configure the destination and consent
Use the ingest key from the receiving project. Set the URL explicitly because older SDK configuration defaults to a different domain:
NATIVEWATCH_KEY=nw_your_project_key
NATIVEWATCH_URL=https://native.watch
NATIVEWATCH_ENABLED=true
NATIVEWATCH_REQUIRE_CONSENT=true
NATIVEWATCH_ENVIRONMENT=development
Replace the example key. These settings must be present before the SDK boots and included in the configuration used by your packaged app. Clear stale configuration during development:
php artisan config:clear
With consent required, reporting starts off. Add the diagnostic choice described in privacy and consent, then explicitly opt in using that screen. A terminal command and an installed app may use different storage directories, so a device choice does not necessarily enable a command running on your development machine.
Receive your first event
From the configured development app, after granting consent in that environment, run:
php artisan nativewatch:test
Save the printed event UUID. Success means the API accepted that specific diagnostic. Processing happens afterwards; open the intended project and match the UUID to the stored occurrence. The setup guide completes only when an occurrence has been processed and stored.
This command captures a constructed PHP exception. It does not crash the native process or prove that Laravel's automatic reporting hook ran. Test those paths separately using the platform guide.
If the event is missing
Check the destination, project key, enabled setting and consent first. A capture can also be discarded by sampling or a beforeSend callback. An accepted event can still be waiting for server processing. A failed delivery may remain in the local outbox; offline delivery explains how to inspect it without mistaking queue removal for acceptance.
Once the UUID is visible, review the stack, release, environment and included context using errors and issues. Inspect that payload for sensitive information before enabling diagnostics in a distributed build.