u/ExpoOfficial

The numbers are uncomfortable: The App Store has over 2 million apps. Paid acquisition costs are up 30% year over year. And 65 to 70% of downloads still come from App Store search, not from ads, social, or influencers. That means your title, subtitle, keyword field, and screenshots are doing more for your install count than almost anything else.

A few things most mobile devs miss:

◆ Your title is your strongest ranking signal. A core keyword in the title can lift rankings by up to 10%.
◆ Apple now indexes the text inside your screenshots. Semantic search means captions are a ranking factor, not just a conversion tool.
◆ The iOS keyword field is 100 characters, hidden from users, and fully indexed. No spaces after commas, no duplicates from the title, no filler.
◆ Localization is the biggest untapped lever. Every locale gets its own title, keywords, and screenshots, and most teams ship English only.
◆ Ratings and reviews are a direct ranking factor. Prompt at the right moment, after a user finishes something meaningful, never on first launch.

Full repo of 20+ ASO Skills and best practices can be found in this new blog post from a community member: https://expo.dev/blog/aso-skills-aso-in-your-ai-workflow

Hey folks. Wanted to share what we've been working on around build speed, since it's the thing we hear most about and the thing that most directly impacts how fast you can iterate.

The short version: Mac Minis are scarce globally right now (AI automators, indies, enterprise teams all buying at once + long lead times), and that affects every cloud build service running on Apple silicon. We're addressing it head-on rather than letting queue times creep up.

What's actually happening:

◆ Dozens of new M4 Pro and Max Mac Minis added to our build fleet. More are being racked. More are on the way.
◆ Compiler-level caching is now live for SDK 54 and 55, speeding up fastlane and gradlew steps by up to 30%
◆ Gradle caching rolling out for Android
◆ Prebuilt binaries for react-native-reanimated and react-native-screens so you stop paying that compile cost
◆ SDK 56 will ship prebuilt XCFrameworks for our most complex iOS Expo modules

The other angle we're pushing: building less in the first place. If you haven't set up EAS Update + fingerprint workflows yet, this is the move. Most code changes are JS-only and don't need a full rebuild. Fingerprint workflows hash your native code, so commits that don't touch native just ship an update instead of triggering a new build.

And the Expo CLI can also build locally via your Xcode or Android Studio install if you need to debug native or work around network restrictions. npx expo run:ios and npx expo run:android both work and play nicely with development builds.

Full write-up with the workflow examples and local build guide: https://expo.dev/blog/build-fast-no-matter-what-how-expo-is-optimizing-for-speed

Happy to answer questions in the thread.

SDK 56 beta is available today. This cycle was focused on two things: speed and stability.

On the speed side: iOS builds are 50%+ faster with precompiled XCFrameworks (on by default, no config needed). Android cold starts are 40% faster and first render is 33% faster via a new Kotlin compiler plugin that replaces runtime reflection with build-time codegen. We also removed the Objective-C++ bridge between Swift and JSI entirely, so native module calls go straight from Swift to C++. Bundling is ~30% faster with Hermes v1 as the default engine.

On the stability side: Expo UI is production-ready (SwiftUI on iOS, Jetpack Compose on Android, universal components, web experimentally). iOS widgets are stable. Calendar, contacts, and media library APIs are stable.

A few other things worth knowing: expo-router has been completely rebuilt and no longer sits on top of react-navigation. You can now write native modules inline alongside your TypeScript. And we added drop-in replacements for several popular community packages so migration is just an import change.

For teams with existing native apps, SDK 56 adds multi-app brownfield support so you can embed multiple Expo apps in one host app without symbol collisions.

Try it: npx create-expo-app@latest --template default@next

Obviously we also have a biblically long changelog with all the details: https://try.expo.dev/reddit-beta

App & Flow published a benchmark study comparing per-frame UI thread cost across four React Native animation approaches.

What was tested:
◆ react-native-ease (platform animation APIs: Core Animation on iOS, ObjectAnimator on Android)
◆ Reanimated with Shared Values
◆ Reanimated with CSS Animations
◆ RN Animated with useNativeDriver: true

Run on iPhone 15 Pro and Moto G8 Plus with Expo SDK 55, React Native 0.83, and Reanimated 4.3.0.

Useful findings:
◆ Debug builds significantly inflate Reanimated's numbers. Always reproduce in a release build before changing anything.
◆ Reanimated's static feature flags (ANDROID/IOS_SYNCHRONOUSLY_UPDATE_UI_PROPS) cut overhead 11-19% by skipping shadow tree commits for non-layout props.
◆ Library choice matters most for long-running animations, lists with many animated items, and low-end devices.
◆ For short one-shot transitions, any library works fine.
◆ Gesture-driven and layout-changing animations still need Reanimated. Ease covers declarative trigger-based animations on visual properties.

React Native 0.85 ships an experimental Shared Animation Backend that will eventually make the SYNCHRONOUSLY_UPDATE_UI_PROPS feature flags unnecessary for Reanimated once integration lands. Worth tracking.

Full benchmark methodology, charts, and source for the example app are in the post: https://expo.dev/blog/the-real-cost-of-react-native-animations-benchmarking-every-approach