In codemagic.yaml, how do instance_type and cache_paths affect a Codemagic Flutter build's speed, and what limits apply to each?

## Two levers on build time A Codemagic build spends its time in three places: preparing the machine, fetching dependencies and compiling. `instance_type` decides the hardware and operating system; `cache` decides how much dependency fetching can be skipped. ## instance_type | Value | Machine | Note | |---|---|---| | `mac_mini_m2` | Apple silicon M2 Mac mini | Available without billing | | `mac_mini_m4` | Apple silicon M4 Mac mini | Billing enabled | | `linux_x2` | Linux | Billing enabled | | `linux_x4` | Linux, larger | Billing enabled | | `windows_x2` | Windows | Billing enabled | Practical rules: - Anything that signs or builds for iOS or macOS needs a **macOS** instance; Xcode exists only there. - Android-only and Flutter web workflows can run on Linux where the account allows it. - A build started through the **REST API** with an `instance_type` parameter overrides the value in the file. - The `environment.xcode` version (`latest`, `edge` or a number) decides which macOS image the build uses, even for an Android build on a Mac. ## cache and cache_paths ```yaml cache: cache_paths: - ~/.pub-cache - $HOME/.gradle/caches - $HOME/Library/Caches/CocoaPods ``` How the cache behaves: 1. It is created from the output of the **first successful build** of the workflow and uploaded to Codemagic. 2. Later builds restore it before the scripts run. 3. It expires after at most **14 days**; the next build fetches everything and creates a new cache. 4. **Each workflow has its own cache**, visible under the Caching tab; there is no sharing between workflows. 5. Size is capped at **10 GB per workflow for teams** and **3 GB per workflow for personal accounts**. ## What to cache and what not to - **Dart packages**: the pub cache (`~/.pub-cache`); the docs also list `$FLUTTER_ROOT/.pub-cache` in one table, so check where the machine's Flutter keeps it. - **Gradle**: `$HOME/.gradle/caches` only. Codemagic warns against caching the whole `$HOME/.gradle`. - **CocoaPods**: `$HOME/Library/Caches/CocoaPods`. - **Swift Package Manager**: `~/Library/Caches/org.swift.swiftpm`, relevant now that Swift Package Manager is on by default in Flutter since 3.44. - **Not** `~/Library/Developer/Xcode/DerivedData`; Codemagic says it does not speed up iOS builds. Xcode 26's compilation cache under `DerivedData/CompilationCache.noindex` is the documented exception when enabled. - **Not** symlinks; Codemagic does not cache them. ## When caching hurts Restoring and uploading a multi-gigabyte archive has its own cost, and Codemagic notes that installing dependencies without a cache can be faster. If dependencies produced warnings or errors while being cached, the cache may appear in the UI yet be incomplete; clear it from the Caching tab or the app's Dependency caching settings and let the next successful build recreate it. ## Machine preparation and timeouts Two more settings change how long you pay for a machine: - **Preparing the machine**: every non-default toolchain version must be installed before the scripts run. Codemagic warns that a non-default Ruby on macOS makes the Preparing build machine step significantly longer; the same logic applies to any version the image does not already carry. - **`max_build_duration`**: the workflow's timeout in minutes, from 1 to 120, with builds timing out after 60 minutes by default. A tight value on PR checks stops a hung test from burning an hour; release workflows that build a large iOS app may need more. ## Choosing for the scooter app PR checks that only run `flutter analyze` and `flutter test` gain little from a large instance and can keep a small cache of `~/.pub-cache`. The iOS release workflow must be on a Mac and benefits from caching CocoaPods; the Android release workflow benefits from the Gradle caches. Measure the build log's timings before and after, because a cache that restores slower than a download is pure cost.