Why can't some players launch my game?

Usually because of a device or OS-specific startup crash, or a regression from a recent build, the game fails to start under conditions you did not test. Launch failures, where the game crashes at startup before the player can play, have a few common causes: a device-specific issue (the game crashes on startup on particular hardware, a GPU, a chipset, a device model, your code does not handle), an OS-version issue (the game fails to launch on a specific OS version that behaves differently or lacks something it needs), or a regression (a recent build broke launching for some configuration). These are invisible on your dev machine, where the game launches fine, so they only show in field data from the affected players. The key is that launch failures are usually specific, to a device, an OS version, or a build, not universal, so the way to find the cause is the pattern: which devices and OS versions are failing, and whether the failures started on a particular build. So some players can't launch your game most likely because of a device-specific or OS-version-specific startup crash, or a regression from a recent release, all of which are invisible to you and revealed only by the device/OS/version pattern in captured field data. Bugnet captures startup crashes from the field with device, OS, and version context, so you can see which devices and OS versions are failing to launch and whether the failures started on a build, revealing the cause (device-specific, OS-specific, or regression) so you can fix it and verify per version that players can launch again.

How do I debug a startup crash I cant reproduce?

Use the captured device, OS, and version context from the affected players to find the cause, since the crash happens on configurations you did not test, the field context is what reveals it. A startup crash you cannot reproduce is happening on a device or OS version different from yours (which is why it launches fine for you), so local debugging will not surface it, the captured field context will. Capture the startup crashes from real players with device, OS, version, and whatever stack/context is available, then read the pattern: if the failures cluster on a specific device model, the cause is device-specific (something about that hardware your startup code does not handle), if they cluster on an OS version, the cause is OS-specific (that version behaves differently or lacks something), and if they started on a build, the cause is a regression in that release. The clustering tells you which device or OS to test on to reproduce (now that you know it is specific to that configuration), and the captured context narrows the cause. So you debug a startup crash you cannot reproduce by relying on the captured device/OS/version context from affected players (not local reproduction, which fails because the crash is configuration-specific), reading the pattern to identify the cause (device, OS version, or regression), and using the clustering to target reproduction on the right configuration. Bugnet captures startup crashes with full device/OS/version context, so a startup crash you cannot reproduce locally still has the field data, which devices and OS versions fail, whether it started on a build, that reveals the cause, letting you fix a launch failure you could never reproduce on your own machine, then verify per version that it stopped.

How do I make sure my game launches on all devices?

Test on a range of real devices and OS versions, and capture startup crashes from the field to catch launch failures on configurations you cannot test, then fix the device/OS-specific issues. You cannot own every device, and launch failures are device and OS-specific, so ensuring your game launches everywhere is a combination of testing what you can and capturing what you cannot. First, test on a representative range of real devices and OS versions (especially common ones and the older/low-end ones where startup issues, like out-of-memory or missing capabilities, are more likely), launching the game on each to catch failures before release. Second, capture startup crashes from the field, since you cannot test every device, the field data from real players catches launch failures on configurations you did not test (the device/OS pattern revealing which fail). Third, fix the device/OS-specific failures the field data reveals (handle the hardware/OS difference causing the startup crash), and verify per version that the failures stopped. Fourth, watch each release for new launch failures (a regression that breaks launching on some configuration), per-version monitoring catches a build that introduced a startup crash. So you make sure your game launches on all devices by testing a range of real devices/OS versions (catching what you can before release), capturing startup crashes from the field (catching launch failures on untested configurations), fixing the device/OS-specific issues, and monitoring per version for regressions. The key is that launch failures are configuration-specific and invisible on your dev machine, so capturing them from the field is essential, no amount of testing covers every device, so the field data is how you find and fix the launch failures that testing missed. Bugnet captures startup crashes from the field with device/OS/version context, so you catch launch failures on devices you cannot test, see the pattern (which configurations fail), and fix them, progressively ensuring more players can launch your game.

What to Do When Players Can't Launch Your Game

Quick answer: Capture startup crashes with device and OS context to see which devices and OS versions fail, identify the pattern (often a specific device, OS, or recent regression), and fix the launch failure while verifying per version.

When players can't launch your game, you lose them before they ever play, the worst kind of failure. These failures are usually device or version-specific and invisible to you. Here is what to do when players can't launch your game.

Capture the Startup Crashes With Device and OS Context

Players who can't launch are crashing at startup, often before any of your code's usual logging runs. Capture these startup crashes from the field with device, OS, and version context, so you can see which devices and OS versions fail, since launch failures are usually specific to particular hardware or OS versions you did not test.

Bugnet captures crashes from the field with device and OS context, so even startup crashes show you which devices and OS versions are failing to launch. That context is essential, launch failures are invisible on your dev machine (where the game launches fine), so the captured device/OS pattern from real players is how you see them.

Identify the Pattern Behind the Failures

Read the pattern: do the launch failures cluster on a specific device model, a particular OS version, or did they appear after a recent build? Clustering on a device or OS version points to a device/version-specific cause, while failures starting after a release point to a regression. The pattern tells you the cause.

Bugnet groups startup crashes by signature and shows device, OS, and version, so the pattern, a device, an OS version, or a regression from a build, is visible. That pattern is the diagnosis: failures on one OS version mean an OS-specific launch issue, failures after a release mean the build broke launching, so you know what to fix.

Fix the Launch Failure and Verify Per Version

Fix the cause the pattern revealed: handle the device/OS-specific issue, or revert/fix the regression that broke launching. Then verify per version that the startup crashes stopped on the affected devices, confirming players can launch again rather than assuming.

Bugnet tracks crashes per version, so after fixing you can confirm the startup crashes stopped on the affected devices and OS versions. This verifies players can launch again, you see the launch failures disappear from the field data on the new build, rather than hoping the fix reached the players who couldn't start your game.

When players can't launch your game, capture startup crashes with device and OS context to see which configurations fail, identify the pattern (device, OS, or regression), and fix it while verifying per version. Launch failures are configuration-specific and invisible on your dev machine.