3 May 2026
Reading a Flutter monorepo without drowning in packages
A practical order of attack for auditors facing many packages, shared kernels, and platform channels that nobody documented.
Flutter monorepos grow quietly: a shared design package here, a payments plugin there, three apps that almost share a networking client. In a codebase audit we refuse to “review everything equally.” Equal attention is how you miss the release risk.
Start at the shipping app
Identify which package produces the binary headed to the store. Trace its pubspec and platform folders first. Shared packages only matter in this engagement if the shipping app depends on them for the upcoming release.
Platform channels next
Undocumented MethodChannels are where “it works on my machine” hides. We list channels, call sites, and native implementations, then mark any channel without tests or ownership as elevated risk.
Dependency age with purpose
We do not grade a team for every outdated transitive package. We highlight dependencies that touch cryptography, payments, webviews, or store billing — areas where age correlates with concrete incident history.
Teams preparing a Mobile App Codebase Audit can help by naming the shipping package and the release owner before day one.