--- title: "Android Development on MacBook Silicon: 2026 Baseline" slug: "android-development-macbook-silicon-2026-baseline" published: "2026-05-31" updated: "2026-06-03" categories: - "Tools" tags: - "android development on macbook silicon" - "apple silicon android development" - "android studio quail" - "android gradle plugin 9.2" - "gradle 9.4.1" - "jdk 17 android" - "kotlin 2.3.21" - "compose bom 2026.05.00" - "arm64-v8a emulator android-36" - "android sdk command-line tools" llm-intent: "reference" audience-level: "intermediate" framework-versions: - "android studio quail 2026.1.1 (mac arm)" - "android sdk command-line tools (sdkmanager, avdmanager)" - "android gradle plugin 9.2.0" - "gradle 9.4.1" - "jdk 17" status: "stable" llm-purpose: "Android development on MacBook Silicon: follow a version-aligned setup - Android Studio Quail, AGP 9.2, Gradle 9.4.1, JDK 17 and ARM64 emulator. Start now." llm-prereqs: - "Access to Android Studio Quail 2026.1.1 (Mac ARM)" - "Access to Android SDK command-line tools (sdkmanager, avdmanager)" - "Access to Android Gradle Plugin 9.2.0" - "Access to Gradle 9.4.1" - "Access to JDK 17" llm-outputs: - "Completed outcome: Android development on MacBook Silicon: follow a version-aligned setup - Android Studio Quail, AGP 9.2, Gradle 9.4.1, JDK 17 and ARM64 emulator. Start now." --- **Summary Triples** - (Android Studio Quail 2026.1.1 (Mac ARM), requiredFor, recommended Apple Silicon IDE build) - (Android Gradle Plugin 9.2.0, compatibleWith, Gradle 9.4.1) - (Gradle 9.4.1, requires, JDK 17 for reliable builds) - (Compose BOM 2026.05.00, alignsWith, compileSdk 36 and Jetpack Compose runtime versions) - (system-images;android-36;google_apis;arm64-v8a, recommendedFor, Emulator on Apple Silicon (native ARM performance)) - (compileSdk 36, pairedWith, buildTools 36.0.0 and targetSdk 36) - (minSdk 26, baselineFor, new native Android apps (balance modern APIs and device reach)) - (sdkmanager / avdmanager (command-line), usedTo, install SDK packages and create ARM64 AVDs) - (Use of ARM64 emulator images, avoids, Rosetta/translation overhead and improves performance on Apple Silicon) - (Version drift, causes, build failures if IDE, AGP, Gradle, Kotlin, SDKs are out of alignment) ### {GOAL} Android development on MacBook Silicon: follow a version-aligned setup - Android Studio Quail, AGP 9.2, Gradle 9.4.1, JDK 17 and ARM64 emulator. Start now. ### {PREREQS} - Access to Android Studio Quail 2026.1.1 (Mac ARM) - Access to Android SDK command-line tools (sdkmanager, avdmanager) - Access to Android Gradle Plugin 9.2.0 - Access to Gradle 9.4.1 - Access to JDK 17 ### {STEPS} 1. Install Android Studio Quail (Mac ARM) 2. Install Android command-line tools 3. Install SDK packages and ARM64 image 4. Install and configure JDK 17 5. Pin Gradle wrapper and AGP 6. Pin Kotlin and Compose BOM 7. Set environment variables 8. Verify build and install # Android Development on MacBook Silicon: 2026 Baseline > Android development on MacBook Silicon: follow a version-aligned setup - Android Studio Quail, AGP 9.2, Gradle 9.4.1, JDK 17 and ARM64 emulator. Start now. Matija Žiberna · 2026-05-31 I spent the better part of a morning recently helping a developer get an Android project building on a new MacBook Pro with an M4 chip. The hardware was not the issue — M-series Macs are more than fast enough for Android work. The issue was version drift. Android Studio, AGP, Gradle, Kotlin, Compose, SDK packages, emulator images, and JDK requirements all move on slightly different schedules, and when you set up a machine from memory or from a guide that is even six months old, you end up fighting mismatched versions for half a day instead of writing code. This post is the baseline I would use today for a new native Android app on a MacBook with Apple Silicon. The date matters here: this reflects the current stable stack as of **June 3, 2026**. --- ## Short answer If you want the shortest possible recommendation, use this: - **Machine:** MacBook with Apple Silicon - **IDE:** Android Studio Quail 1 | 2026.1.1 for Mac ARM - **Language:** Kotlin - **UI:** Jetpack Compose + Material 3 - **Android Gradle Plugin:** 9.2.0 - **Gradle:** 9.4.1 - **JDK:** 17 - **compileSdk / targetSdk:** 36 - **minSdk:** 26 - **Build Tools:** 36.0.0 - **Compose BOM:** 2026.05.00 - **Emulator image on Apple Silicon:** `system-images;android-36;google_apis;arm64-v8a` If you follow that matrix, you are aligned with the current Android toolchain instead of fighting mismatched versions. The rest of this post explains where each of those numbers comes from and how to get everything running. --- ## The latest stable Android Studio for Apple Silicon Before touching any SDK packages or build configuration, you need to make sure you are running the right build of Android Studio itself. On Apple Silicon, that distinction matters more than it sounds. As of June 3, 2026, the stable Mac ARM download on the official Android Studio page is: - **Android Studio Quail 1 | 2026.1.1 for Mac (ARM)** - File: `android-studio-quail1-mac_arm.dmg` The reason to be explicit about the ARM version is that there are two downloads on the Android Studio page — one for Intel, one for Apple Silicon. On an M-series Mac, you want the native ARM build. Running the Intel version under Rosetta works, but it is slower, and the emulator story gets more complicated when the host process and the emulator images are not aligned on architecture. If you prefer working in Cursor, VS Code, or another editor, you can still install only the command-line tools and skip Android Studio as your daily driver. But knowing which version of Studio corresponds to the current stable toolchain is useful context even if you never open it. --- ## The latest command-line tools for macOS For developers who prefer a terminal-first workflow, the Android SDK does not require Android Studio at all. The current macOS command-line tools package listed by Google is: - `commandlinetools-mac-14742923_latest.zip` That package gives you `sdkmanager`, `avdmanager`, and the rest of the Android SDK command-line toolchain. Once installed, everything else flows through those tools rather than through the Studio UI. This is the setup I prefer when the main workflow looks like this: ```txt Editor Terminal Gradle wrapper Android SDK command-line tools Real device and/or emulator ``` Android Studio still earns its place for certain tasks. SDK bootstrapping, emulator setup, Compose previews, Logcat, the profiler, and deeper device debugging are all easier in Studio than in a terminal. But none of those are daily-driver requirements for most projects. The command-line tools give you the full SDK surface without making Studio a dependency. --- ## The current version matrix that actually matters The most important compatibility anchor in the Android toolchain is the Android Gradle Plugin release. Everything else — Gradle version, JDK, Build Tools, SDK level — is documented relative to the AGP version. Getting that number right first is what keeps the rest of the stack from fighting itself. As of the current AGP 9.2.0 release, Google documents this compatibility baseline: - **AGP:** 9.2.0 - **Gradle:** 9.4.1 - **SDK Build Tools:** 36.0.0 - **JDK:** 17 - **Maximum supported API level:** 36.1 That gives you the practical starting point for a new project on macOS Apple Silicon: ```txt compileSdk = 36 targetSdk = 36 minSdk = 26 AGP = 9.2.0 Gradle = 9.4.1 JDK = 17 Build Tools = 36.0.0 ``` For Kotlin, the currently released stable version is **2.3.21**, published on **April 23, 2026**. For Compose, the current stable BOM shown in the official docs is **2026.05.00**. Those two are worth pinning separately because they follow their own release cadence rather than tracking AGP directly. That is the complete stack I would start with for any new Android app today. The next section covers how to actually get those pieces onto a clean machine. --- ## What I would install on a MacBook Silicon today Setting up a clean Apple Silicon machine for Android work involves four distinct pieces. Getting them in the right order saves a round of troubleshooting later. ### 1. Android Studio for Mac ARM Optional for daily coding, but worth having installed. Use it for initial SDK bootstrapping, emulator and device management, Compose preview, profiling, and deeper Android-specific debugging. Even if your daily driver is a different editor, Studio is the most reliable way to get the SDK laid down correctly on a new machine. ### 2. Android SDK command-line tools Install the current command-line tools package, then use `sdkmanager` to install: ```txt cmdline-tools;latest platform-tools platforms;android-36 build-tools;36.0.0 emulator system-images;android-36;google_apis;arm64-v8a ``` That last package is the Apple Silicon-specific detail worth calling out. On a MacBook with Apple Silicon, you want the ARM64 emulator image: ```txt system-images;android-36;google_apis;arm64-v8a ``` Not the x86_64 image. The x86_64 image runs under emulation on ARM and loses a significant amount of the performance advantage that makes the emulator tolerable on M-series hardware. ### 3. JDK 17 Do not improvise here. The current AGP compatibility table is explicit: use **JDK 17**. JDK 21 is not yet the supported default, and older versions will cause build failures. Install a named JDK 17 distribution and point `JAVA_HOME` at it explicitly rather than relying on whatever the system resolves. ### 4. Gradle wrapper in the project Even though AGP 9.2.0 aligns with Gradle 9.4.1, the project wrapper is still the right way to manage the Gradle version rather than a global install. Pin it in the project: ```bash ./gradlew assembleDebug ``` That keeps the version in the repo rather than in your machine state, which matters as soon as more than one person is working on the project. --- ## A sane Apple Silicon environment setup Once the tools are installed, the environment configuration is straightforward. The goal is predictability: every relevant tool should resolve from the same paths, and the paths should survive shell restarts. A typical macOS setup looks like this: ```bash export ANDROID_HOME="$HOME/Library/Android/sdk" export ANDROID_SDK_ROOT="$ANDROID_HOME" export PATH="$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH" ``` If your JDK is installed separately from the system default: ```bash export JAVA_HOME="/path/to/jdk-17" export PATH="$JAVA_HOME/bin:$PATH" ``` The simplest way to verify the setup is working is to check four things: - `java -version` resolves to JDK 17 - `sdkmanager` runs without errors - `adb` is on the path - `./gradlew assembleDebug` completes from the project root If those four things are true, the machine is ready. If any of them fail, the environment paths are usually the culprit before anything else. --- ## The stack I would choose for a new app With the machine set up, the question of what to actually build with is worth addressing directly. For a new native Android app on Apple Silicon in 2026, I would not get creative with the architecture: - Kotlin - Jetpack Compose - Material 3 - ViewModel + StateFlow - Navigation Compose - Retrofit + OkHttp or Ktor Client - Coil for images - DataStore first, Room later if you actually need offline or structured local cache The last point about DataStore versus Room is worth elaborating on. Room is a solid library, but it adds complexity that most new projects do not need on day one. DataStore handles the majority of local persistence requirements until the app has a real use case for relational data. Starting with DataStore and adding Room later is much cleaner than starting with Room and realizing half of its machinery is unused. The same logic applies to module structure. One `app` module is still the right default for a small or medium product. The instinct to split into feature modules early is usually premature. Let the codebase earn that structure through growth, not through upfront architecture decisions that add friction before they add value. --- ## Emulator or real device? On Apple Silicon, the emulator story is finally good enough that avoiding it is no longer necessary. The ARM64 emulator images run natively on M-series hardware, and the performance gap between emulator and device is much smaller than it was on Intel Macs. That said, I still would not default to the emulator for everything. My order of preference is: 1. Real Android phone for routine app testing, especially for anything involving input, gestures, or network behavior 2. Apple Silicon emulator for layout checks, API-level verification, and device-profile testing across screen sizes 3. Android Studio only when I need something that a text editor and terminal cannot provide — Compose preview, the profiler, or Logcat for complex multi-process debugging The emulator is fast enough to be the primary development target for most UI work. But nothing replaces a real device for confirming that the app actually feels right in a human's hand. --- ## My practical recommendation If you are starting fresh on a MacBook Silicon today, the complete checklist is short: 1. Install **Android Studio Quail 1 | 2026.1.1 for Mac ARM** 2. Install the current Android command-line tools 3. Install SDK 36 packages and the Apple Silicon ARM64 emulator image 4. Make sure your build runs on **JDK 17** 5. Create or update the project to use AGP 9.2.0, Gradle 9.4.1, Kotlin 2.3.21, and Compose BOM 2026.05.00 6. Verify the setup with two commands from the project root: ```bash ./gradlew assembleDebug ./gradlew installDebug ``` If both of those complete without errors, you have a working Android development setup on Apple Silicon. Anything older than this matrix is now legacy setup. Anything newer should be adopted deliberately — when you have a specific reason to upgrade — not by accident when a dependency pulls in a newer transitive version. --- ## Final take Android development on Apple Silicon is no longer the awkward edge case it was a few years ago. The hardware is strong, the native ARM64 emulator images are fast, and the official toolchain has a clear path for M-series Macs. The investment Google has made in the ARM build of Android Studio and the SDK tools shows in the current experience. The difficulty that remains is not hardware or tooling quality — it is version alignment. The Android build system has more moving parts than most ecosystems, and those parts have slightly different release cadences. If you pin the versions described here and keep the workflow terminal-first, a MacBook Silicon machine is now a genuinely good default for Android development. Most setup problems are not exotic — they are a wrong JDK, a stale Build Tools version, or an Intel emulator image running on an ARM machine. Getting the baseline right takes about an hour. Getting it wrong costs a day. Let me know in the comments if you run into anything specific to your setup, and subscribe for more practical development guides. Thanks, Matija --- ## Sources - Android Studio download page: https://developer.android.com/studio - Android Studio install guide: https://developer.android.com/studio/install - Android SDK command-line tools and `sdkmanager`: https://developer.android.com/tools - `sdkmanager` usage: https://developer.android.com/tools/sdkmanager - Android Gradle Plugin 9.2.0 release notes: https://developer.android.com/build/releases/gradle-plugin - Build from command line: https://developer.android.com/build/building-cmdline - Compose BOM docs: https://developer.android.com/develop/ui/compose/bom - Kotlin releases: https://kotlinlang.org/docs/releases.html ## LLM Response Snippet ```json { "goal": "Android development on MacBook Silicon: follow a version-aligned setup - Android Studio Quail, AGP 9.2, Gradle 9.4.1, JDK 17 and ARM64 emulator. Start now.", "responses": [ { "question": "What does the article \"Android Development on MacBook Silicon: 2026 Baseline\" cover?", "answer": "Android development on MacBook Silicon: follow a version-aligned setup - Android Studio Quail, AGP 9.2, Gradle 9.4.1, JDK 17 and ARM64 emulator. Start now." } ] } ```