Flutter / Maintenance
What should you check before working on an existing Flutter app?
The Flutter repository is only part of a product. Maintenance also requires platform configuration, API access and the ability to publish store updates. Check these before committing to a deadline for the first change.
1. Reproduce the version users have
Identify the commit corresponding to the App Store and Google Play releases. Record Flutter and Dart versions, the SDK channel and how the team selects versions. Check pubspec.yaml, pubspec.lock and any dependency_overrides. An override may be a deliberate workaround that must not be removed without checking.
Build the app in an isolated environment with its existing dependencies. Do not start by upgrading all packages. Run analysis and tests, but also launch the app on both platforms: a successful Android build says nothing about iOS configuration completeness.
2. Understand data flow and state management
Trace one important scenario from the screen through state and data layers to the API. Check module responsibilities, dependencies, navigation and local storage. The name of a state management library alone does not establish the architecture's quality.
If the project uses BLoC, check events, states, error handling and operation cancellation. Ask the same data-flow questions for other solutions. Taking over a project does not require immediately replacing its state management with the new team's preferred option.
In the Spontan app, Flutter and BLoC work with a Laravel backend. This is one specific toolset, not a requirement for every project.
3. Separate environments and check the API contract
Establish how the app selects the API URL, app identifier and service configuration: flavours, environment files or build parameters. The test variant should be recognisable and must not accidentally send data to production. Do not assume a secret embedded in a mobile app will remain secret.
Check sign-in, token storage, session renewal and sign-out. Test expired tokens, offline operation and switching users. Identify supported API versions and whether the backend remains compatible with older app versions.
4. Test push and deep links beyond a normal app launch
For notifications, check provider configuration, device token registration and renewal, and system permissions. Test receipt in the foreground and background, and opening the app from a notification. Firebase and APNs configuration must match the correct app and environment.
A deep link should reach the right screen even when the app is not running or the user is signed out. Define what happens with an outdated identifier, deleted content or a link to an unauthorised resource. A link itself does not grant access to data.
5. Check Android, iOS and the ability to publish updates
On Android, review the application identifier, Gradle and SDK configuration, permissions, variants and release signing. Access to the correct Google Play account and key management process is required. Do not replace an existing app's key with a randomly generated new file.
On iOS, check Xcode, Bundle ID, the developer team, capabilities, certificates and provisioning profiles. Compare the local environment with the release process. Establish who manages App Store Connect access; a previous contractor's personal account should not be the only publication route.
6. Reproduce the release process and error monitoring
If CI/CD exists, check runner configuration, tool versions, secrets and artifact storage. For manual releases, record repeatable steps for another person. Prepare a test release in the appropriate distribution channel before functional changes.
Identify analytics and crash reporting if used. Check whether reports can be linked to an app version and whether the team has access. Do not add tracking merely because an old configuration is missing; data collection scope requires a deliberate decision.
7. Agree on change priorities and readiness criteria
First separate build and publication blockers from housekeeping. Plan Flutter, package and native configuration updates with regression tests. Check which libraries are maintained, which require migration and whether replacing one would force app-wide changes.
A handover is operationally ready when the team can build both versions, reproduce key scenarios, diagnose a fault and publish an update. Missing access or signing credentials are real blockers even when the code looks good.
We describe handover and further development in our Flutter mobile app services.
Documentation for your next steps
Use installation instructions that match the versions in your project. The sources below cover these topics in more detail.