Mobile VR Game Crash and Error Monitoring
Mobile VR—Quest 2/3 standalone, Pico 4, legacy Cardboard—has specifics that make crash monitoring more complex than desktop games. The device is autonomous, logs aren't visible in real time, the user doesn't know what happened, and the developer console is far away. If crash reporting isn't built into the build in advance, after release you work practically blind.
Why standard Unity Crash Reporter doesn't work for VR
Unity Cloud Diagnostics (old Unity Analytics) and built-in UnityCrashHandler cover C# exceptions and manageable crashes. But mobile VR crashes often occur deeper—in the native layer: GPU driver, Vulkan runtime, Oculus platform layer. These crashes come as SIGSEGV or SIGABRT with hex stack, which without NDK symbolication is unreadable.
Concrete example: Quest 2, Unity 2022.3 LTS, URP, crash happened on devices with specific Horizon OS v57 firmware. Stack from logcat: #00 pc 0x00000000012abc14 /data/app/com.yourcompany.game/lib/arm64/libunity.so. Without symbol table from the corresponding Unity version, this says nothing. With symbol table (available on Unity Download Archive for each LTS version)—it expands to a specific call inside Vulkan buffer allocation that failed due to memory limit changes in Horizon OS v57.
For IL2CPP builds—you need .pdb files or il2cpp_data directory from the build for proper C# stack symbolication. Without them, Firebase Crashlytics will show native stack without C# class mapping.
Tools and configuration
Firebase Crashlytics is the de facto standard for mobile VR. Integrates via Firebase Unity SDK. Requires google-services.json in the project and configuration in launcherTemplate.gradle. Crashlytics automatically collects native and managed crashes, groups by stack, shows trending.
Key settings for Android/Quest: enable android.useNewApkSplitting if using asset bundling, so Crashlytics correctly maps versions. Symbol upload via Firebase CLI: firebase crashlytics:symbols:upload --app=APP_ID path/to/libil2cpp.so.
Sentry Unity SDK is an alternative with more flexible on-premise option. Useful for studios with data storage requirements in specific jurisdictions. Configuration via Sentry.Init() in first MonoBehaviour with release and environment tags—lets you filter crashes by version and channel (dev/staging/production).
Additionally to crash reporting—custom event logging for soft errors: situations without crashes but incorrect behavior. Analytics.CustomEvent("tracking_lost", {"duration": 5.2, "lighting": "low"}) lets you see degradation patterns without crashes.
Analyzing crash reports and establishing priorities
After monitoring setup—regular cycle of analysis. Group crashes by app version, OS version, device model. For Quest—separate filtering by Horizon OS version: some crashes appear strictly on specific firmware.
Crash-free rate metric (% of sessions without crash) is the main KPI. For VR applications, normal is >99% on supported devices. If below 97%—active investigation.
Typical crash causes in mobile VR:
- Out of memory: 6 GB RAM on Quest 3 sounds like lots, but Horizon OS leaves app about 3–4 GB. Native memory leaks, incorrect AssetBundle unload, texture memory accumulation in addressables cache—all lead to OOM kill.
- Vulkan validation errors in dev builds become crashes in release if
GraphicsDeviceTypeswitched without shader compatibility check. - Threading violations: accessing Unity API from non-main thread without
UnityMainThreadDispatcheror equivalent.
| Task | Estimated timeline |
|---|---|
| Firebase Crashlytics integration with symbolication | 1–2 business days |
| Full monitoring stack setup (Crashlytics + Sentry + custom events) | 3–5 business days |
| Analysis and fix of top 5 crashes after integration | 1–3 weeks (depends on complexity) |
Cost is calculated after project analysis and current monitoring status.