Confirm the actual target support
Record the installed Flutter SDK, build target and native platform toolchains. Check the target help for the supported obfuscation and split-debug-information options. Avoid applying a command from a mobile build to another target without confirming support in the installed toolchain.
Start from a reproducible release build that already passes application tests. Keep the unobfuscated baseline and note expected outputs for important workflows. This lets you distinguish an obfuscation compatibility failure from an unrelated platform packaging issue.
Separate release output from symbols
Use a private diagnostics directory outside the public release destination. Flutter obfuscation works with the split-debug-information option, and the generated resources are needed to recover useful crash information. Keep the exact build and architecture association rather than only a directory named latest.
The command below is an illustrative Android app-bundle build. Replace the paths and target according to your supported distribution workflow. Protect the diagnostics location and back it up before cleaning the build machine.
flutter build appbundle --obfuscate --split-debug-info=/private/flutter/build-42Exercise name-sensitive features
Identify code that compares runtime type names or relies on string-based lookups. Obfuscation can change those names. Prefer explicit stable identifiers for stored or wire-format contracts and test their behavior using data produced by a prior release. Also test relevant plugins, background work and startup paths.
Review native integration separately. A Dart name transformation does not replace Android keep rules, Apple signing or native crash symbols. Perform all byte-changing build work before the platform signing step, then validate the packaged app and its update behavior through the normal release process.
Prove diagnostic recovery and state the limits
Use a controlled authorized crash to test the matching diagnostic resource. Flutter symbolication workflows vary by target; follow the current official guide for the generated file type rather than assuming one command handles every platform. Verify that the recovered stack identifies the expected application frames.
Audit the public package and storage for accidentally published symbols, maps, configuration files or credentials. A release scan should retain explicit gaps when a container or byte range is unsupported. A passing bounded scan is not a decompilation-resistance certificate.
CloneGuard supplies release screening, receipts and platform guidance. It does not implement a Flutter snapshot obfuscator or measure attacker reconstruction time. If you evaluate resistance, compare equivalent protected and baseline releases against a fixed authorized reconstruction task and report that result separately from app compatibility.
Practical checklist
- Verify target options against the installed SDK.
- Keep exact-build diagnostic resources private.
- Test runtime-name and plugin behavior.
- Validate signing and an authorized crash recovery path.
Sources and further reading
Primary references support the technical details. Procedures here are guidance; only explicitly recorded project results describe tests we ran.
Prepared with AI assistance. How this library is produced. Suggest a correction; keep private code and credentials out of public issues.