If your crash tool groups issues by matching the stack trace as a string, an obfuscated build can turn one bug into ten “unique” issues overnight. The fix isn’t a better string match — it’s grouping by the shape of the crash instead of its literal text.<\/p>\n
Say a null pointer crash has been stable in your dashboard for weeks: one issue, steady occurrence count, assigned and being worked. Then you ship a release with ProGuard\/R8 rules updated, or a refactor that inlines a couple of methods, or a JS bundle that gets re-minified with different variable names. The exact same crash fires again — same root cause, same broken code path — but the stack trace now reads differently: a class got renamed to A tool that groups by exact string match sees a new trace and opens a new issue. Multiply that across every device and OS version hitting the bug, and by the end of the week you’ve got what looks like five or six distinct crashes in your backlog. It’s one bug, filed six times, because the deduplication logic couldn’t see past the string.<\/p>\n This isn’t a hypothetical edge case — obfuscation and minification are standard practice for production Android and web builds specifically because they shrink and protect the code. Any crash tool that hasn’t accounted for it is going to fracture under normal release hygiene, not just in unusual situations.<\/p>\n Exact stack-trace matching treats the trace as a string to compare. It works fine as long as nothing about the trace’s text changes between occurrences. The moment any of the following happens, the string changes and the match breaks:<\/p>\n None of these change what actually broke. They only change what the trace looks like as text. A matching system that can’t tell the difference between “this is a different bug” and “this is the same bug in a different build” ends up creating duplicate issues as a side effect of normal shipping.<\/p>\n Shakebug’s Crash AI clusters by pattern — the shape of the crash — rather than a literal string match on the trace, specifically so that a rename or a shifted line number doesn’t split one crash into several (shakebug.com\/ai-crash-grouping<\/a>). Grouping runs the same way across iOS, Android, Flutter, React Native, and web from one SDK, and it’s on by default — crash capture and grouping start as soon as the SDK initializes on each platform, with no separate module to wire up.<\/p>\n Each grouped issue keeps a first-seen date, an occurrences-over-time trend, and a breakdown by affected devices and app versions, so a renamed build doesn’t just get grouped correctly — it also stays attached to the history of when the bug first appeared and how it’s trending, instead of resetting the clock every time a new “duplicate” issue opens.<\/p>\n Shakebug has published before\/after numbers from its crash and bug AI grouping: taking a team from roughly 8,000 scattered reports down to about 150 core issues, cutting time spent on resolution by around 95%, and reducing duplicate-report volume by around 80% (shakebug.com\/ai-bug-reporting<\/a>). That gap between “reports filed” and “actual distinct problems” is largely what exact-match grouping fails to close — most of those 8,000 aren’t 8,000 different bugs, they’re a few hundred bugs filed many times over, including across builds where the trace text shifted.<\/p>\n There’s no toggle to find. If you’ve already installed the Shakebug SDK for bug reporting, crash capture and pattern-based grouping are already running:<\/p>\n Full feature breakdown, screenshots of a grouped issue, and platform-by-platform setup: see AI Crash Grouping<\/a>.<\/p>\n Sentry also groups crashes, but its AI-assisted debugging layer — the Seer agent — is a separate paid add-on on top of your plan. Shakebug’s Crash AI, pattern-based grouping included, ships in every plan at no extra cost. For the full breakdown (pricing, session replay limits, what each tool is actually built for), see the Sentry alternative comparison<\/a>.<\/p>\na.b.c<\/code>, a method got inlined into its caller, a line number shifted by three.<\/p>\n<\/span>Why exact-match grouping fails here<\/span><\/h2>\n
\n
<\/span>What pattern-based grouping does instead<\/span><\/h2>\n
<\/span>What this looks like at scale<\/span><\/h2>\n
<\/span>Getting this without extra setup<\/span><\/h2>\n
\/\/ Android (Kotlin)\r\nShakeBug.sharedInstance().initiateWithKey(this, \"<Your Key>\")<\/code><\/pre>\n\/\/ iOS (Swift) — automatic once initialized\r\nShakeBugSDK.sharedInstance.initiateWithKey(\"<Your Key>\")<\/code><\/pre>\n\/\/ Flutter (Dart) — wrap your root widget\r\nShakebugSDK(\r\n androidAppKey: 'your_android_appkey',\r\n iosAppKey: 'your_ios_appkey',\r\n child: MaterialApp(home: const HomeScreen()),\r\n);<\/code><\/pre>\n<\/span>If you’re comparing this against Sentry<\/span><\/h2>\n
<\/span>FAQ<\/span><\/h2>\n