Flutter - Deployment

Once your Flutter application is developed and tested, the final step is to build a release version and deploy it to users via app stores or other distribution methods. This chapter covers the basics of preparing and building release versions for Android and iOS.

Preparing for Release

Before building the release version, consider these steps:

App Icon: Ensure you have added appropriate app icons for different resolutions for both Android and iOS. Tools and packages like flutter_launcher_icons can help automate this.
App Name: Verify the display name of your app. For Android, check android:label in android/app/src/main/AndroidManifest.xml. For iOS, check Display Name in ios/Runner/Info.plist (often configured via Xcode).
Application ID / Bundle ID: Confirm your unique identifier. For Android, check applicationId in android/app/build.gradle. For iOS, check Bundle Identifier in ios/Runner.xcodeproj (usually viewed/edited in Xcode under Runner > Signing & Capabilities). This ID must be unique on the respective app stores.
Versioning: Update the version number and build number. This is typically managed in pubspec.yaml under the version key (e.g., version: 1.0.0+1). The part before + is the version name (visible to users), and the part after + is the version code (or build number, must increment for each release). Flutter tools propagate this to the native build files.
Code Signing (Crucial): Release builds must be digitally signed. This verifies the app’s author and ensures it hasn’t been tampered with.
- Android: Requires creating an upload key and keystore file (.jks or .keystore). You’ll configure your android/app/build.gradle file to reference this keystore for release builds. Keep this key secure! Google Play App Signing is recommended, where Google manages the final signing key.
- iOS: Requires an Apple Developer account. Signing is managed through Xcode using certificates and provisioning profiles linked to your developer account and the app’s Bundle ID.
Review Dependencies: Ensure all dependencies are necessary and up-to-date.
ProGuard/R8 (Android): Consider enabling code shrinking and obfuscation for Android release builds to reduce app size and make reverse-engineering harder. Configure this in android/app/build.gradle.
Remove Debugging Code: Ensure print statements, debug banners (debugShowCheckedModeBanner: false in MaterialApp), and other development aids are removed or disabled for release builds.

Building for Android

Building an APK

An APK (Android Package Kit) is the standard package file format used by the Android operating system for distribution and installation of mobile apps. You can build a universal APK or split APKs per architecture.

Command:

flutter build apk

This command (by default) builds a release APK, typically optimized and using AOT (Ahead-Of-Time) compilation. Ensure your signing configuration is set up in android/app/build.gradle.

Output:

✓ Built build/app/outputs/flutter-apk/app-release.apk (4.8MB).

The generated APK will be in the build/app/outputs/flutter-apk/ directory. This file can be installed directly onto devices or distributed outside the Play Store.

For more control (e.g., building split APKs per ABI to reduce size):

flutter build apk --split-per-abi

Building an App Bundle

An AAB (Android App Bundle) is the recommended format for publishing to Google Play. You upload the AAB, and Google Play generates and serves optimized APKs tailored to each user’s device configuration (ABI, screen density, language), resulting in smaller downloads.

Command:

flutter build appbundle

Output:

✓ Built build/app/outputs/bundle/release/app-release.aab (5.0MB).

The generated AAB file will be in build/app/outputs/bundle/release/. Upload this file to the Google Play Console.

Installing a Release Build

To install a specific release build (e.g., the APK you just built) onto a connected device or emulator:

# For APK
flutter install --release

# Note: Installing an app bundle directly usually requires specific tools.
# For testing, installing the release APK is more common.

Building for iOS

Prerequisites

A macOS machine.
Xcode installed.
An Apple Developer account.
Code signing configured in Xcode (Certificates, Bundle ID, Provisioning Profiles).

Building an IPA

An IPA (iOS App Store Package) is the archive file format used to distribute iOS applications.

Command:

flutter build ipa

This command builds a release archive (.xcarchive) and then exports it as an IPA file (.ipa). It relies on the signing configuration set up in your Xcode project.

Output:

✓ Built build/ios/archive/Runner.xcarchive.
✓ Built build/ios/ipa/YourAppName.ipa.

The generated IPA file will be in build/ios/ipa/. This file can be uploaded to App Store Connect using tools like Transporter or directly from Xcode (via the Organizer).

Alternative: Building via Xcode

You can also build and archive your Flutter iOS app directly within Xcode:

Open your project’s ios/Runner.xcworkspace file in Xcode.
Select a physical iOS device or ‘Any iOS Device (arm64)’ as the build target.
Go to Product > Archive.
Once archiving is complete, the Xcode Organizer window will appear, showing your archive.
From the Organizer, you can validate the app, distribute it to App Store Connect, or export the IPA for other distribution methods (like Ad Hoc or Enterprise).

Distribution

Once you have your release build (.aab or .apk for Android, .ipa for iOS):

Google Play Store: Create an app listing in the Google Play Console, upload your App Bundle (.aab), fill in store details, and follow the release process (testing tracks, staged rollouts, production).
Apple App Store: Create an app listing in App Store Connect, upload your IPA (usually via Transporter or Xcode), provide metadata and screenshots, submit for review, and release.
Other Methods: You can distribute builds via Firebase App Distribution for testing, enterprise distribution programs, or direct APK download (for Android, use with caution).

Deployment involves careful planning, adherence to platform guidelines, and thorough testing.