概要
公開日: 2026-05-13
翻訳生成に失敗したため、原文をそのまま保存しています。
原文
You need speed. Whether you’re a student shipping your first app between classes, an engineer sneaking in progress on your side project over lunch, or part of an enterprise team responsible for millions of users, the constraint is the same. You don’t have time to wait on builds. You need feedback instantly. You need to ship while the idea is still fresh. When builds are slow, momentum dies. When builds are fast, you stay in flow and that’s when great products actually get made. Our aim is to provide the fastest builds to you no matter what plan you are on. To deliver on this promise we are taking steps to address the unprecedented demand for Expo, mac hardware, and scaling to meet the needs of enterprise engineers and vibe coders alike. Mac Minis are a hot commodity for aspiring AI automators using OpenClaw, especially the configurations with extra RAM (which itself was already a scarce resource). If you've ever taken a peek at our build server configuration page, you know iOS builds run on well-equipped M4 Mac Minis. With the perfect storm of long lead times for Mac Mini shipments worldwide, a surge of app development across the world from vibe coders, indie devs, local business, and enterprises, it’s only natural to wonder how this might affect Expo’s Build and Workflows queues. Here is what we are doing to speed up builds and increase our infra: - First, we've recently added dozens of new M4 Pro and Max Mac Minis to our fleet, we are racking more as we speak and have more ordered and en route. - We’re taking several measures to make each build faster, which means more builds for everyone. - We recently deployed compiler-level caching for SDK 54 and 55 projects to improve the speed of your fastlane and gradlew step by up to 30%. - We’re deploying Gradle caching to improve Android build performance. - We’re adding prebuilt binaries for commonly-used packages like react-native-reanimated and react-native-screens to practically eliminate the time that it takes to build those artifacts. - SDK 56 ships prebuilt XCFrameworks for our most complex Expo modules on iOS, to speed up your iOS builds. Our vision is to give every builder the chance to make something real. The first time you use Expo and a build finishes fast you feel it. Then it happens again, and at some point you stop thinking about builds entirely. You trust that things will work and they’ll be fast. That’s the bar for us: infrastructure you don’t have to think about so you can focus on building something beautiful. The same bar applies to our tools. Our developer tools should help you make the most of each build and make it easier to tap into the capabilities of your own hardware. Building less often with fingerprint-based workflows What’s even faster than building on an EAS M4 Max large worker with ccache and prebuilt React Native binaries enabled? How about not building at all? Even if you don’t need Expo’s OTA Updates to deliver bug fixes over-the-air to your production app, it’s a great fit for making your preview app feedback loop as tight as possible. Most apps don’t need a full rebuild on every code change, since most code changes are JavaScript only. Instead, ship an update to rebuild only the JavaScript and let your existing app install download the new code. Run eas update:configure to setup your app to use EAS Update and rebuild. You can use a dynamic app config to enable updates just for your preview app (set updates.enabled to false in this case). You could then update your app manually by running eas update --channel preview whenever you know you didn’t change any native code or dependencies. Or, you can set this up as an EAS workflow that runs automatically on commit and selectively either builds or updates based on the sampling of a native fingerprint, a hash that only changes when your native code changes. Connect your Expo project to Github, and then add this workflow to the .eas/workflows folder: name: Build or update preview on main push, based on