DEV Community: mavoryl

I scanned 10 mobile codebases for health issues — here's what I found

mavoryl — Fri, 08 May 2026 12:23:48 +0000

Every mobile repo I worked on had similar problems: very large PNG images, unused asset files that nobody removed, secret files added to git years ago, gradle files that changed from default settings. So I made a small CLI that scans a mobile repo and gives it a 0–100 health score in four areas (size, speed, stability, hygiene) with 50 checks.

To test the rules on real projects, I ran it on ten codebases I had on my laptop. Seven are well-known open-source projects. Three are from my own work and stay anonymous below — I will only describe them by stack ("a Flutter app", "an Android app").

npx mobile-repo-doctor scan ./your-repo

Everything runs locally. Your code, file paths, and scan results never leave your machine. No account, no login, no telemetry. The CLI is one npm package. If you don't trust me, the npm bundle is a single file you can read.

The dataset

Public (7): AppFlowy, wikipedia-ios, compose-multiplatform, iCarousel, mundraub-android, golden_matrix, auto-dev.

Private (3, anonymous): two Flutter apps, one Android app.

By stack: 3 Flutter, 2 Android, 2 iOS, 2 KMP, 1 multi-stack (AppFlowy).

What the numbers said

The middle score across the ten repos was 95/100. This surprised me — I expected lower scores. But two repos scored below 60. The worst was 52.

	Median	Worst
Overall score	95	52
Size	91	4
Speed	96	83
Stability	100	71
Hygiene	93	33

Total findings across all ten repos: 327. Most are Info (148) — these are summaries like "here are your top size contributors", not real problems. The rest: 3 Critical, 17 High, 90 Medium, 69 Low.

I expected stability to be the worst area — security flags, low SDK targets, manifest problems. It was not. People now know these rules well. I saw almost no usesCleartextTraffic="true", almost no NSAllowsArbitraryLoads, almost nobody using a very old API level. The areas where modern repos get lower scores are size and hygiene — boring things nobody checks in CI.

The most common findings were not security issues

The top of the list, sorted by how many of the ten repos had each finding:

Finding	Repos affected
Top size contributors (info)	10/10
Module/package inventory (info)	9/10
Duplicate asset files	8/10
WebP candidates (PNGs that should be WebP)	8/10
Oversized images	7/10
Unoptimized PNGs	7/10
Sensitive files in repo	6/10

Eight of ten repos have PNG assets large enough to benefit from WebP. This is a simple fix — one cwebp -q 80 command and you save real size. compose-multiplatform alone has about 7 MB of PNGs that could be WebP. AppFlowy has another 2.4 MB. One of the private Flutter apps has more than 10 MB. None of these are bugs. Nobody just did it yet.

The same with duplicate assets between sub-packages. Half of the multi-package repos had the same logo, icon, or splash image copied across four to six modules. wikipedia-ios has about 3.4 MB of duplicates. Nobody runs find on these files.

The "secrets" finding needs more explanation

Six of ten repos had a sensitive-file finding. But I want to be honest about what this means. Most are Tier-2 hits: google-services.json, GoogleService-Info.plist, debug.keystore. These files are usually safe to commit (Firebase configs are project-scoped, debug keystores are not release credentials). The check marks them as Low/ReviewNeeded for a reason — they need a careful decision, not an automatic reaction.

The honest number: two of ten repos (20%) had Critical-level sensitive files — .env files in tooling subdirectories of two open-source projects. One has been there for years.

I also found one wrong finding: a _pub.pem file marked as sensitive because it ends in .pem. It is a public key — safe to commit. Fix coming soon.

A few things that surprised me

The number of findings does not show health well. The repo with the most findings (69) was iCarousel — an old, well-maintained iOS library. Almost all of its findings are info-level summaries, not problems. It scored 97/A. Meanwhile a Flutter repo with 61 findings scored 58/C. The mix of severities matters more than the count.

Even AppFlowy has image problems. AppFlowy is a popular OSS project with many contributors. They have ~7 MB of oversized images, 6 MB of unoptimized PNGs, 2.4 MB of WebP candidates. Nobody is bad here — this is what happens to an old project when no one takes care of asset hygiene.

KMP repos look good. auto-dev and compose-multiplatform scored 97 and 78. Only 2 repos so I cannot make strong conclusions, but the KMP ecosystem is young and the asset pipelines are usually clean. I need more samples.

The biggest concrete wins were boring

If I had to give each public repo one one-day task:

AppFlowy: compress those cover images — ~7 MB of oversized PNGs.
wikipedia-ios: remove duplicate assets across packages — ~3.4 MB of duplicates plus ~12 MB of unoptimized PNGs.
compose-multiplatform: oversized images add up to ~26 MB. Some are documentation samples, but worth checking.
iCarousel: really fine. Nothing to do here.

For the private apps: the Android one was clean (97/A, 12 findings). The two Flutter apps split — one was almost perfect (94/A), the other had ~80 MB of total reducible size across oversized + unoptimized + duplicate images. That is not a typo. It is also the one that scored 58/C.

What else it checks

This post focused on what showed up most in this scan, but the rule set covers more:

Android: low targetSdk/minSdk, debuggable release builds, missing ProGuard rules, missing minification, dependency hygiene (dynamic versions, SNAPSHOT deps, legacy support libs, mixed kapt/ksp), missing ABI splits, APK instead of AAB, native libs forced to extract on install.
Flutter: unused assets in pubspec, missing assets that are in pubspec, heavy dependencies (Lottie/SVG runtime weight), dependency_overrides in production, vendored packages, oversized SVGs, missing split-debug-info, large workspaces with too many local packages.
iOS: arbitrary network loads in Info.plist, hardcoded user paths in pbxproj, unversioned pods, low deploy target, too many disabled SwiftLint rules, bitcode enabled (deprecated), oversized resources outside sticker packs.
Cross-platform / hygiene: missing lockfiles (gradle wrapper, podfile.lock, pubspec.lock), deeply nested directory trees, large generated files committed by accident, sensitive files (with the Tier-1/Tier-2 split above).

71 checks total across all stacks.

Try it on your own repo

npx mobile-repo-doctor scan .

Or as a GitHub Action (Marketplace listing):

- uses: Mavoryl/mobile-repo-doctor-action@v1
  with:
    scan-path: '.'

You get HTML + JSON output, a health score, top issues, quick wins, and file paths for each finding. 50 checks for Android / Flutter / iOS / KMP / cross-platform. Runs locally, no telemetry, no account.

Caveats

Ten repos is a small sample. Per-stack medians (especially KMP at n=2) are noisy — treat them as informal. The dataset is mostly already-maintained projects, so scores are higher than a random sample would be. And the _pub.pem wrong finding is a reminder: even rules that are 95% correct need a way to suppress them, which is on the roadmap.

npm: https://www.npmjs.com/package/mobile-repo-doctor
GitHub Marketplace: https://github.com/marketplace/actions/mobile-repo-doctor

If you run it on your own repo, I would love to hear what you found — both real findings and wrong findings. The wrong ones are how the rules get better.

A simpler way to write golden tests in Flutter — golden_matrix

mavoryl — Tue, 05 May 2026 10:53:03 +0000

I want to share a Flutter package I made. It is called golden_matrix. It helps you write golden tests when your app has many themes, locales, and devices.

The problem

My app has 5 locales, light and dark themes, and many device sizes. I also need to test different text scales for accessibility.

If I want to test one button, I need many golden tests:

testGoldens('button - en - light - small phone', ...);
testGoldens('button - en - dark - small phone', ...);
testGoldens('button - ru - light - small phone', ...);
testGoldens('button - ru - dark - small phone', ...);
// ...30 more tests

This is too much copy-paste. Most people give up and only test one combination. Then bugs come from the combinations they did not test.

The idea

With golden_matrix, you write one test:

matrixGolden(
  'MyButton',
  scenarios: [
    MatrixScenario('default', builder: () => const MyButton(label: 'OK')),
    MatrixScenario('disabled', builder: () => const MyButton(label: 'OK', enabled: false)),
  ],
  axes: MatrixAxes(
    themes: [MatrixTheme.light, MatrixTheme.dark],
    locales: [Locale('en'), Locale('ru'), Locale('ar')],
    textScales: [1.0, 2.0],
    devices: [MatrixDevice.phoneSmall, MatrixDevice.tablet],
  ),
);

This makes 48 golden files. One declaration. No loops.

The package knows that Arabic is RTL, so it sets that for you. Each file has a clear name like goldens/default/dark_ar_rtl_2x_tablet.png.

What if 48 tests is too many?

You can use smaller test sets:

Smoke — only a few key combinations:

matrixGolden('Widget', scenarios: [...], axes: axes,
  sampling: MatrixSampling.smoke); // about 5 tests

Pairwise — covers all pairs of values with the smallest number of tests:

matrixGolden('Widget', scenarios: [...], axes: axes,
  sampling: MatrixSampling.pairwise); // about 12 tests

Most bugs come from how two settings work together (like dark theme + Arabic). Pairwise testing finds these bugs with much fewer tests.

Presets — for common cases:

matrixGolden('Widget', scenarios: [...], preset: MatrixPreset.componentSmoke);

A nice extra feature

Golden tests check pixels. But sometimes a widget is broken even when pixels look the same.

For example: your row has an icon, text, and a button. It looks fine. But on a small phone with large text, the button goes off the screen.

A RenderFlex overflowed by 613 pixels on the right.

Flutter cuts off the extra part, so the image looks "okay". The pixel test passes. But the user sees a broken button.

golden_matrix catches these errors. It listens for Flutter warnings during the test. You get a report like this:

{
  "scenario": "default",
  "device": "phoneSmall",
  "textScale": 2.0,
  "status": "passed",
  "warnings": [
    "A RenderFlex overflowed by 613 pixels on the right."
  ]
}

The test passes, but you see the warning. You can fix the bug before users find it.

HTML reports

After tests run, the package makes one HTML file. You open it and see all your golden images on one page. You can filter by theme, status, or scenario. You can click an image to see it bigger.

This is much faster than opening files one by one.

How to start

Add the package:

# pubspec.yaml
dev_dependencies:
  golden_matrix: ^0.6.1

Set up fonts (do this once):

// test/flutter_test_config.dart
import 'dart:async';
import 'package:golden_matrix/golden_matrix.dart';

Future<void> testExecutable(FutureOr<void> Function() testMain) async {
  await loadAppFonts();
  return testMain();
}

Write a test:

import 'package:golden_matrix/golden_matrix.dart';

void main() {
  matrixGolden(
    'MyButton',
    scenarios: [
      MatrixScenario('default', builder: () => const MyButton(label: 'OK')),
    ],
    preset: MatrixPreset.componentSmoke,
  );
}

Run:

flutter test --update-goldens
flutter test

That is all.

Testing full screens

For screens with navigation or special setup, use screenMatrixGolden. You give it a function that builds your app:

screenMatrixGolden(
  'LoginScreen',
  appBuilder: (combination) => MaterialApp(
    theme: combination.theme.resolve(),
    locale: combination.locale,
    home: LoginScreen(
      errorMessage: combination.scenario.name == 'error' ? 'Invalid' : null,
    ),
  ),
  states: [
    MatrixScenario('default', builder: () => const SizedBox.shrink()),
    MatrixScenario('error', builder: () => const SizedBox.shrink()),
  ],
  preset: MatrixPreset.screenSmoke,
);

You control the app. The package handles the matrix.

Why I made this

Other packages did not work for me:

golden_toolkit — not updated since 2023
alchemist — good for one case, but no matrix idea

So I made golden_matrix. It is MIT license, no extra dependencies, 108 tests, and on pub.dev.

It is not perfect. It may not fit every project. But if you have many themes and devices to test, give it a try.

If something does not work or you want a new feature, open an issue. I will help.

Links:

pub.dev/packages/golden_matrix