Flutter Deer: 24 plugins, a 2024 APK, and no Navigator 2.0 yet

MVP on top of provider 6.x and dio 5.x, with Bean classes generated for you

The architecture is the lesson here: an MVP split, provider 6.x for state, and dio 5.x wrapped in one networking layer. The model classes are not typed by hand. The project runs FlutterJsonBeanFactory against the JSON payloads and generates the Bean layer, so the classes match what a server returns rather than the other way round. Routing is modular instead of file based, and design/ holds the UI drawings, with each page carrying a code comment that gives that drawing's relative path, which is how a newcomer maps a screen to its target. pubspec.yaml is where the dependency truth lives, and the README points there instead of restating versions. What this setup cannot do is point at a backend you own. No server endpoint, authentication scheme or environment switch is named in the documentation, so the dio layer needs rewiring before the app talks to anything of yours.

Debug mode stutters by design, so the first build should be a release bundle

Some lag in debug mode is expected here, and the stated answer is a release build rather than a bug hunt. Two commands produce one:

flutter build apk
flutter build ios

The Android command is also the only way to get a package of your own, since the newest Android package on the releases page is 1.3.2 from 2024-02-15. Expect your toolchain to match the pair the project states, Flutter version 3.47.4 and Dart version 3.13.0,. If you lift a screen into your own repository, change the version pinning first, otherwise the same import fails somewhere else and you will read it as a bug in the copied widget.

The feature walkthrough runs through a driver file rather than a test filter

Rather than a suite you can target by name, the demo path is a single driver script:

flutter drive --target=test_driver/driver.dart

That target lives in test_driver/, next to integration_test/ and test/ at the top of the repository, and the build badge points at .github/workflows/flutter-drive.yml. The integration and accessibility coverage the project advertises is exercised by that walkthrough driving real screens. The cost is granularity: no way to run one step or one assertion is documented, so when a screen misbehaves you rerun the whole driver and read the log to work out where it stopped.

Only Android ships a binary, and it is release 1.3.2 from 2024-02-15

The releases page holds an Android package, and version 1.3.2 published on 2024-02-15 is the newest one there, with 1.3.0 from 2023-08-22 behind it. The source tree moved on 2026-09-18, which puts the download more than two years behind the code anyone would clone today. That gap is the practical limitation here: a fix made after February 2024 exists in the repository and not in the APK, and the size figure that gets repeated, 10.3M down to 10.1M, belongs to the null safety migration recorded in the plan list rather than to the artifact in your hands. For iOS there is nothing to download at all. You clone the repository, point your Flutter install at the folder and build.

Windows and macOS are preview only, because the plugins want native code

Some of the packages this app leans on reach for native features, so the two desktop targets are explicitly preview only, mainly on the native side, with the interface itself described as fine. The README attributes it to some plugins without naming them; the dependency list includes flutter_2d_amap for the AMap 2D map, qr_code_scanner for scanning, and vibration and image_picker for device interaction. The consequence for a reader is that windows/ and macos/ are not a build you can hand to users. Treat those folders as places where screens get laid out, and keep anything you intend to ship on mobile. Desktop trouble is also undocumented: the roundups in docs/ cover iOS and Android only.

The web demo loads slowly on GitHub Pages because the JavaScript payload is large

A live web build sits at simplezhli.github.io/flutter_deer/, and the documentation is blunt about why it is not quick: the JavaScript and other assets are heavy and the deployment is on GitHub, so access will be slower. Nothing describes a CDN, a service worker or an asset cache that would change that, which means a reader timing load or frame rate on that URL is measuring GitHub Pages plus a big bundle rather than the app. Build locally and measure there. The web target is otherwise real, not a stub: localization runs through intl with an l10n.yaml at the repository root, dark mode is supported, the Sliver components drive the complex scrolling, and the AMap address picker is noted as working on web.

Three entries in the dependency table are replaced rather than upgraded

The package table names flutter_swiper, flustars and azlistview, and the known-problems list says plainly that none of them has caught up with Flutter 3. The replacements are named too: flutter_swiper_null_safety_flutter3 in place of flutter_swiper, flustars_flutter3 in place of flustars, and for azlistview the note is to upgrade scrollable_positioned_list. Two Flutter lines are flagged in the same list, 3.10.0 against #105203 and #113595, and 2.0.0 against #68571, #73351, #74890, #79773 and #79931. The practical consequence is that pubspec.yaml, not the README table, is what you reconcile when something breaks. A cosmetic entry sits in that list too: a ListView with no divider set can leave a gap of about one pixel between some items.

Routes go through fluro, and the Navigator 2.0 line is still an open checkbox

Navigation is handled by fluro as one modular route table rather than by Navigator 1.0 calls scattered across widgets, which suits an app with this many screens. In the plan list, every other line is ticked: map support, dark mode, semantics, web, the null safety migration, integration tests. One is not. Migrating to Navigator 2.0 is still an empty checkbox, so the declarative routing model that newer Flutter work leans on is absent from this codebase. If your own app needs deep links, router configuration or platform route APIs, what you get here is a table worth reading and no pattern worth copying, and the cheapest move is to keep the fluro layer inside what you already maintain.

Editorial conclusion

Take Flutter Deer if you want one app that shows provider, dio, fluro and Sliver patterns wired together, and read pubspec.yaml before you copy anything. Leave it out as a product base: desktop targets are preview only, the downloadable Android package is release 1.3.2 from 2024-02-15, and three listed dependencies have not been adapted to Flutter 3. Check first that your Flutter and Dart versions match the pinned 3.47.4 and 3.13.0.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. simplezhli/flutter_deer on GitHub