Free Programming learning guide
Build Production-Ready Mobile Apps with Flutter
Build Production-Ready Mobile Apps with Flutter — a free intermediate-level guide covering how to build a mobile app with flutter. Learn with clear...
What you will learn
1. Project Architecture & Dependency Injection
The Anatomy of a Scalable Flutter App Imagine you join a team building a fast-growing delivery app. The repository is a monolithic mess: API calls are triggered directly inside StatelessWidget build methods, hardcoded API keys live in a constants.dart file, and adding a new feature requires touching 15 unrelated files. The build times are creeping past five minutes, and onboarding a new developer takes weeks. This scenario is the inevitable result of treating a Flutter project as a simple script rather than a software ecosystem. As applications grow, the "flat" structure generated by flutter create quickly breaks down. To build a mobile app capable of scaling, you need an architecture that enforces separation of concerns, predictability, and testability from day one. A robust architecture serves three primary purposes: Isolation: UI changes don't break business logic, and database changes don't break UI. Testability: You can mock dependencies to test components in isolation. Onboarding: Developers can locate features and their associated files instantly. We will achieve this by adopting a feature-first architecture combined with strict layer separation, wired together via automated dependency injection. Feature-First Folder Structures When structuring a Flutter app, you generally choose between a layer-first approach (folders for models, views, controllers) or a feature-first approach (folders for authentication, checkout, profile). For intermediate to large projects, layer-first structures fail because navigating a single feature requires jumping between multiple top-level directories. Feature-first structures group everything related to a specific domain together, creating highly cohesive, decoupled modules. The Layered Feature Structure Inside each feature, we apply a layered architecture (often inspired by Clean Architecture). Each feature is divided into data, domain, and presentation layers. Here is a blueprint for a scalable feature-first structure: Separating Business Logic from UI The golden rule of this structure is dependency rule: dependencies must point inward. The presentation layer depends on domain, and data depends on domain. The domain layer knows nothing about the UI or the data sources. Real-World Example: User Login Flow Consider a login screen. A naive approach puts the HTTP request inside the button's onPressed callback. In our architecture, the flow is strictly separated: 1. Presentation Layer: The LoginPage widget calls a method on a controller/viewmodel (e.g., authController.login(email, password)). It only cares about showing a loading spinner or navigating on success. 2. Domain Layer: The controller calls the LoginUseCase. This use case contains business rules (e.g., "Validate email format before proceeding") and calls an abstract AuthRepository. 3. Data Layer: The concrete AuthRepositoryImpl is called. It fetches credentials, passes them to the AuthRemoteDataSource (which makes the actual Dio HTTP request), maps the JSON response to a domain User entity, and returns it. If you later decide to switch from a REST API to GraphQL, you …
2. Advanced UI Rendering & Custom Painters
When Standard Widgets Aren't Enough You are building a fitness tracking app. The design team hands you a mockup featuring a scrolling dashboard where a complex radial progress chart shrinks and snaps into the app bar as the user scrolls. Below it, a custom waveform visualizes heart rate data in real time. You look at the standard Flutter widget catalog—ListView, Container, Slider—and realize quickly that none of them will get you there. Flutter is famous for its rich set of pre-built Material and Cupertino widgets. But its true superpower lies beneath that layer: a highly performant rendering engine that gives you direct access to the canvas and the layout pipeline. When you need pixel-perfect custom graphics or scroll-driven UI that defies standard BoxScrollView behavior, you must drop down to the rendering layer. Building on the feature-first architecture and layer separation principles established in Chapter 1, we will explore how to implement these advanced visual features entirely within your Presentation Layer, keeping your UI logic isolated, testable, and maintainable. Optimizing Widget Rebuilds: The Foundation of Complex UIs Before drawing a single pixel, we must ensure our rendering pipeline is efficient. Complex UIs fail when widgets rebuild unnecessarily. In Chapter 1, we discussed how dependency injection via getit and injectable helps separate our concerns. Now, we must ensure our widget tree respects that separation efficiently. The Power of const Constructors Flutter's compiler is aggressive about optimization. When you mark a widget constructor as const, Flutter instantiates a single canonical instance at compile time and reuses it. If a parent widget rebuilds, the framework short-circuits: it sees the const child, skips the rebuild entirely, and moves on. In complex UIs, failing to use const where possible causes cascading rebuilds. If a top-level provider or state object triggers a rebuild, every non-const child will be rebuilt and reconciled, even if its inputs haven't changed. Make const your default; remove it only when a widget requires runtime parameters. Using Keys for Structural Identity When dealing with dynamic lists of custom widgets—such as a column of custom-drawn graphs—Flutter needs to know which widget corresponds to which state when the list reorders or changes. This is where Keys come in. - ValueKey: Best for widgets with a unique identifier (e.g., a graphId). - ObjectKey: Useful when the widget's identity is tied to a complex domain object. - GlobalKey: Use sparingly. It forces the framework to preserve the state and element across the entire tree, which is expensive. It is justified only when you need to access a child's state directly or measure its rendered size. If you are building a custom scrolling list of widgets that animate or change position, omitting keys will result in state "jumping" …
3. Robust State Management with Riverpod
The Anatomy of a Provider In Chapter 1, we established a strict dependency rule where our Presentation Layer depends on the Domain Layer, and the Data Layer sits at the bottom. To enforce this layer separation within our feature-first architecture, we used getit and injectable for Dependency Injection (DI). But while getit is excellent for providing dependencies (like an API client or a local database repository), it does not solve the problem of reactive state. When a user’s profile updates in memory, how do we ensure the UI re-renders automatically without manually calling setState() across deeply nested widgets? This is where Riverpod enters our architecture. Riverpod is a compile-safe, reactive state management framework that bridges the gap between our domain logic and our Presentation Layer. It acts as the ultimate state notifier, ensuring that when state changes, only the exact widgets that depend on that state rebuild. Riverpod offers several provider types, each tailored to a specific use case. Let’s look at the three you will use most frequently. Providers vs. FutureProviders vs. StateNotifiers A Provider in Riverpod is the most fundamental building block. It is used to expose a synchronous value or a function. If you have a service that parses local JSON or a repository that returns a hardcoded list, a standard Provider is sufficient. A FutureProvider is specifically designed for asynchronous operations. It takes a Future and automatically resolves it, exposing the result to the UI. It handles the boilerplate of converting a Future into something the widget tree can listen to synchronously. This will become incredibly useful in the next chapter when we integrate remote APIs, but for now, it applies to any async domain task. A StateNotifier (and its Riverpod wrapper, StateNotifierProvider) is the tool for mutable, interactive state. While Provider and FutureProvider are read-only from the UI's perspective, a StateNotifier exposes methods that allow the UI to mutate state predictably. It encapsulates state logic and ensures that state transitions happen in a controlled, testable environment rather than scattered across widget files. Exposing State to the UI Riverpod offers two primary ways to consume state in the UI: the standard ConsumerWidget and Riverpod Hooks (HookConsumerWidget). Both achieve the same goal of listening to providers, but they cater to different coding styles and complexity levels. Using ConsumerWidget The ConsumerWidget is the most straightforward way to access a provider. It replaces the standard StatelessWidget and provides a ref object in the build method. This ref object is your gateway to reading state. Leveraging Hooks As apps grow, ConsumerWidget can become verbose, especially when you need to manage local UI state (like animation controllers or text controllers) alongside global state. In Chapter 2, we explored advanced UI rendering. …
4. API Integration & Data Serialization
The Anatomy of a Network Request A mobile app that doesn't talk to the outside world is just an expensive calculator. By the time you reach this stage in your application's lifecycle, you have already established a feature-first architecture with strict Layer separation and wired up your dependencies using getit and injectable. Your Presentation Layer is rendering complex UI, and your Domain Layer is holding your business logic. Now, we must bridge the gap between your pristine Dart environment and the messy reality of the internet. REST APIs communicate primarily via JSON. JSON is dynamically typed, inherently nullable, and completely oblivious to the Dart type system. When you fetch a JSON payload, you are inviting Map<String, dynamic into your app. If these maps leak into your Domain Layer, you lose compile-time safety, autocompletion, and the guarantees of your dependency rule. To prevent this, our Data Layer must act as a strict translation boundary. It converts raw network responses into immutable, type-safe Dart objects before they ever reach your state management or UI. To do this efficiently at scale, we rely on two industry-standard packages: dio for networking, and the combination of freezed and jsonserializable for data serialization. Type-Safe Models with Freezed and jsonserializable Writing fromJson and toJson methods by hand is tedious and error-prone. For a single model, it might take five minutes. For fifty models with nested arrays and complex polymorphism, it becomes a massive liability. freezed is a code generation package that acts as a syntax enhancer for Dart data classes. It generates copyWith methods, implements value-based equality (so two objects with identical properties are considered equal), and handles == and hashCode. When paired with jsonserializable, it automates the mapping between JSON maps and Dart objects. Setting up the Data Class Consider a real-world scenario: fetching a list of articles from a CMS. The JSON might look like this: To map this safely, we define a Freezed model. We use @freezed on an abstract class, and a private $ factory constructor to trigger the code generator. The Power of Annotations Notice how we handled the mismatches between JSON conventions and Dart conventions using annotations: - @JsonKey(name: 'publishedat'): JSON APIs often use snakecase for keys, while Dart uses camelCase. This annotation bridges that gap without requiring a global configuration override. - @Default([]): If the API occasionally omits the tags array, a standard List<String would throw an assertion error when parsed. @Default ensures the field falls back to an empty list, hardening your app against incomplete payloads. - DateTime parsing: jsonserializable automatically detects DateTime fields and attempts to parse standard ISO-8601 strings. If your API uses a non-standard format (e.g., Unix epochs), you would write a custom JsonConverter. Once you …
5. Offline-First Data Persistence
The Anatomy of an Offline-First Architecture A user opens your app on a subway train. The screen loads, but the spinning indicator just hangs. Ten seconds later, a generic "No Internet Connection" dialog appears. The user closes the app. In mobile development, network connectivity is a privilege, not a guarantee. An offline-first architecture flips the traditional request-response model on its head: the local database becomes the single source of truth for the UI, and the remote API acts as a synchronization endpoint. Building on the Data Layer and feature-first architecture established in Chapter 1, and the API integration patterns from Chapter 4, we will now implement local persistence. The UI—managed by Riverpod—should remain completely decoupled from whether the device is online or offline. It simply reads from and writes to the local database. To achieve this, we need to select the right tools for the job. For NoSQL lightning-fast caching, we will use Hive. For structured, relational data, we will look at sqflite and Drift. Finally, we will wire these local stores back to our remote servers using background synchronization. NoSQL Caching with Hive When you need to cache API responses, JSON blobs, or unstructured data, setting up a full relational database is often overkill. Hive is a lightweight, key-value NoSQL database written entirely in Dart. It excels at fast read/write operations and stores data in binary boxes. Integrating Hive into the Data Layer Following our dependency rule, the Data Layer is responsible for managing data sources. Let's implement a local data source using Hive. First, register a HiveBox within your getit environment configuration during app initialization: With the box registered, we can build a UserProfileLocalDataSource that acts as a cache for our UserProfileRepository. When to Choose Hive Hive shines when dealing with ephemeral data or when you don't need complex querying. If your app fetches a list of configuration flags, user preferences, or simple JSON payloads that just need to be retrieved by a single key, Hive is the optimal choice. However, if you need to filter, sort, or join datasets locally, it's time to look at relational databases. Local Relational Databases: sqflite vs. Drift When your offline features require complex queries—such as fetching "all incomplete tasks assigned to this user, sorted by due date"—a NoSQL key-value store becomes cumbersome. You need a relational database. The Raw Power of sqflite sqflite is the standard SQLite plugin for Flutter. It provides a thin wrapper over the native SQLite implementation, meaning you write raw SQL strings. While sqflite gives you absolute control, writing raw SQL strings in Dart is error-prone. A typo in a SQL string won't be caught until runtime. This is where Drift comes in. Type-Safe Databases with Drift …
6. Secure Authentication Flows
The Anatomy of a Secure Auth Flow A user taps "Login", waits 800 milliseconds, and suddenly has access to their financial history, private messages, and personal documents. In that brief window, your app must verify credentials with a remote server, receive an access token, store that token in a location inaccessible to other apps, and update the application state to unlock the UI. If any link in that chain is compromised, the entire system fails. Building on the feature-first architecture and layer separation established in earlier chapters, we will construct an authentication system that respects the dependency rule: UI components remain blissfully unaware of how tokens are stored, while repository classes handle the secure orchestration of credentials and session state. Securing Credentials with fluttersecurestorage Storing authentication tokens in SharedPreferences is a critical security vulnerability. On Android, SharedPreferences writes to plain XML files, and on iOS, to plist files. On a rooted Android device or a jailbroken iPhone, these files are trivially readable. To securely persist tokens, we use the fluttersecurestorage package. It delegates to the platform's underlying hardware-backed keystore: - Android: Uses the EncryptedSharedPreferences API (backed by AES-256) and the Android Keystore. - iOS: Uses the Keychain Services API, which can be configured to require device passcode or biometric unlock. Configuring the Storage Provider Following our established Dependency Injection (DI) pattern using getit and injectable, we define an abstract class for secure storage to maintain Testability:. When registering the base FlutterSecureStorage instance in your DI container, you can enforce platform-specific options, such as requiring the iOS Keychain to be accessible only when the device is unlocked: State Management for Authentication In Chapter 3, we explored Robust State Management with Riverpod. Authentication state is the perfect use case for a StateNotifier or Notifier that acts as a bridge between your Presentation Layer: and Data Layer:. We define three distinct states for our auth flow: The Auth Notifier The AuthNotifier orchestrates the login, logout, and token refresh logic. It depends on the AuthRepository (which handles API calls) and the SecureStorageService. Implementing Route Guards With our auth state globally available via Riverpod, we need to prevent unauthenticated users from accessing protected screens. In Flutter, this is achieved using a Redirect function within GoRouter (or a similar routing package). A route guard intercepts navigation attempts. If a user tries to access /dashboard without a valid token, the router redirects them to /login. Conversely, if an authenticated user tries to navigate to /login, they should be bounced to /dashboard. Real-World Example: Deep Link Protection Imagine a user clicks a magic link in an email to view a specific invoice (https://app.com/invoice/123). If the app is closed, the router initializes in AuthInitial. The deep link attempts to …
7. Native Platform Integration
Bridging the Dart-Native Divide Your Flutter app needs to check the battery level. It seems like a trivial task, but Dart has no direct access to the iOS or Android battery APIs. You could search pub.dev for a package, but adding a dependency for a single API call adds unnecessary bloat and potential maintenance overhead. Instead, you can ask the underlying operating system directly. This is where MethodChannels come in. They are the mechanism Flutter uses to bridge the Dart runtime with the native Android (Kotlin/Java) and iOS (Swift/Objective-C) runtimes. Given the feature-first architecture and strict layer separation established earlier in this book, native integrations should never bleed into your UI. Instead, they belong squarely in the Data Layer (or a dedicated platform layer), abstracted behind interfaces defined in the Domain Layer. This ensures Testability: and Isolation:, allowing you to mock native calls during unit testing and swap implementations effortlessly. Communicating via MethodChannels A MethodChannel is a named pipe that passes messages asynchronously between Dart and native code. The data is serialized to binary at the edges, meaning you are limited to standard JSON-like types: null, bool, int, double, String, Uint8List, List, and Map. Invoking Native Code from Dart To open a channel, you provide a unique name. It is a best practice to prefix the channel name with your app's domain to prevent collisions. Notice the invokeMethod call. It takes a string method name and an optional Map<String, dynamic of arguments. Handling the Call on Android On the Android side, you must register the channel in your MainActivity.kt. The native code receives the method name and arguments, executes the native API call, and returns a result. Handling the Call on iOS Similarly, register the channel in AppDelegate.swift. Architecting Native Integrations Plumbing MethodChannels directly into your widgets violates the dependency rule. Instead, wrap your native interactions in a repository pattern. Real-World Example: Biometric Authentication Bridge In Chapter 6, we covered Secure Authentication Flows. Suppose you want to enhance the Onboarding: process by allowing users to log in using device biometrics (Face ID/Touch ID). While packages exist for this, building it natively demonstrates how to structure the bridge. First, define an abstract class in your Domain Layer: Next, implement this repository in your Data Layer, wrapping the MethodChannel: Finally, register this implementation using getit and injectable as established in Chapter 1. Your Riverpod notifiers or BLoCs can now depend on IBiometricRepository without ever knowing a MethodChannel exists under the hood. Requesting and Handling Runtime Permissions Accessing native features almost always requires runtime permissions. Android uses a system of explicit permission requests via ActivityCompat, while iOS utilizes Info.plist declarations and system prompts. The Permission Flow 1. Determine if permission is needed: Check …
8. Testing & Performance Profiling
The Anatomy of a Testable Flutter App You’ve just spent two weeks building a complex offline-first data persistence layer with secure authentication. The feature works perfectly on your emulator. You ship it to QA, and within an hour, a tester reports that the app crashes when switching between Flutter Flavors from staging to production, or that a critical button becomes unresponsive after a network timeout. The difference between catching these issues on a Tuesday morning versus discovering them in production usually comes down to two things: automated tests and performance profiling. Because we adhered strictly to the dependency rule and separated our app into Domain, Data, and Presentation layers, our codebase is inherently testable. Now, we cash in on that architectural investment. Structuring Your Test Suite Flutter categorizes tests into three primary buckets. Understanding when to use each prevents bloated, slow test suites. - Unit Tests: Validate individual functions, methods, or classes in isolation. They are lightning-fast and should make up the vast majority of your test count. - Widget Tests: Validate the UI and interactions of a single widget or a small section of the widget tree. They run in a sandboxed environment and are slower than unit tests. - Integration Tests: Validate complete user flows end-to-end, running on a real device or simulator. They are the slowest but provide the highest confidence. Unit Testing Business Logic and Providers Because we utilized layer separation and Dependency Injection (DI) via getit and injectable, our business logic doesn't depend on Flutter’s UI engine or direct API calls. This makes unit testing remarkably straightforward. When testing Riverpod providers, the key is overriding the provider dependencies. Let’s look at a Real-World Example: User Login Flow. Assume our AuthRepository handles network requests, and an authNotifier consumes it. Instead of hitting a real API, we inject a mock repository. By using ProviderContainer with overrides, we isolate the AuthController entirely. We are testing the logic of state transitions without relying on the broader widget tree. Widget Testing Complex UI Components Unit testing state is only half the battle. If a user taps a "Submit" button, does the correct Riverpod action fire? Does the UI display a loading spinner while waiting? Widget tests require a WidgetTester to pump the widget tree. When dealing with widgets that rely on Riverpod, we must wrap our test widget in a ProviderScope. Real-World Example: Complex Onboarding Carousel In Chapter 6, we discussed Onboarding: flows. Let's test a specific onboarding widget that requires both a complex layout (using Custom Painters from Chapter 2) and state management to track the current page index. Key considerations for widget tests: - pump() vs pumpAndSettle(): Use pump() to advance time by a single frame (useful for …
9. CI/CD & App Store Deployment
The Anatomy of a Release Bottleneck It is 4:00 PM on a Friday. Your team has just merged a critical hotfix for the Secure Authentication Flows introduced in Chapter 6. The fix works perfectly locally. Now, you have to ship it. An hour later, you are staring at Xcode cursing at a "provisioning profile not found" error, while your Android terminal spits out an obscure Gradle signing exception. The manual process of bumping version numbers, cleaning build artifacts, generating signed binaries, navigating App Store Connect, and uploading to Google Play Console is fraught with friction. The longer it takes to get this hotfix into production, the more users are locked out of their accounts. Continuous Integration and Continuous Deployment (CI/CD) eliminates this bottleneck. By leveraging Fastlane to automate the tedious platform-specific build steps, and GitHub Actions to orchestrate the pipeline on every pull request, you can transform a multi-hour, error-prone manual process into a single-click, fully automated release workflow. Configuring Fastlane for Automated Builds Fastlane is an open-source tool suite written in Ruby that automates iOS and Android build and release tasks. Rather than interacting with Xcode GUIs or wrestling with Gradle commands manually, Fastlane allows you to define your release logic in code. Initialization and Structure To begin, navigate to your Flutter project root and initialize Fastlane for both platforms: This generates a fastlane/ directory in both your ios and android folders. The most important file in these directories is the Fastfile, which contains your lane definitions. A lane is a sequence of actions that execute a specific task, such as building the app or pushing it to a testing track. Integrating Flutter Flavors In Chapter 1, we established Flutter Flavors for development, staging, and production. Fastlane must be aware of these flavors to correctly target your App IDs and provisioning profiles. For Android, Fastlane interfaces directly with Gradle. For iOS, Fastlane interacts with Xcode schemes. When configuring your lanes, you will pass the flavor as a parameter to ensure the correct environment is built. Managing App Signing and Provisioning Profiles Code signing is the most notorious hurdle in mobile deployment. Apple requires apps to be signed with a valid certificate and provisioned with a profile linked to an App ID. Google requires APKs or App Bundles to be signed with an upload keystore. iOS Signing with match Manual signing—where developers export .cer and .mobileprovision files and share them via Slack or email—is a recipe for disaster. If a certificate expires or a profile is revoked, your CI pipeline breaks. Fastlane solves this with match. match stores your certificates and provisioning profiles in a private, encrypted Git repository (or a cloud storage bucket). When your CI machine needs to …
Continue learning
- Intermediate Python Automation Scripts for BeginnersIntermediate Python Automation Scripts for Beginners — a free intermediate-level guide covering intermediate python automation scripts for beginners....
- Intermediate Python Projects for Portfolio BuildingIntermediate Python Projects for Portfolio Building — a free intermediate-level guide covering intermediate python projects for portfolio building....
- C# for Beginners: A Complete Step-by-Step GuideC# for Beginners: A Complete Step-by-Step Guide — a free beginner-level guide covering how to learn c# for beginners. Learn with clear explanations,...
- Advanced SQL for Data Analysts: Mastering Complex QueriesAdvanced SQL for Data Analysts: Mastering Complex Queries — a free advanced-level guide covering advanced sql queries for data analysts. Learn with...