Conversation
# Why Naming suspense boundaries is generally a good practice for debugging. Also, with transition tracing and other tracing solutions for React, suspense boundary names can help identify the source of an async operation. # How Just added the name in the suspense boundary, using the route name if available. # Test Plan CI # Checklist - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [x] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [x] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
# Why The `Props` block on API reference pages renders as a bare list of rows separated by thin top borders, without the rounded outer card that wraps every other API section (Constants, Methods, Types, Enums). The mismatch is visible on `/versions/v56.0.0/sdk/router/experimental-stack/`, where the Props block sits right above a Types card and reads as visually unfinished. <img width="2418" height="598" alt="CleanShot 2026-05-11 at 16 19 12@2x" src="https://github.com/user-attachments/assets/929dc00e-f408-4878-94d7-98d7cde7210f" /> # How <!-- How did you build this feature or fix this bug and why? --> Fix Props rendering on API reference pages by using `STYLES_APIBOX`. # Test Plan <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> <img width="2524" height="474" alt="CleanShot 2026-05-12 at 13 29 53@2x" src="https://github.com/user-attachments/assets/956a43f5-41e8-4141-b45e-1ced4c380c05" /> # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [ ] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…ion (#45248) # Why <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> This PR partly addresses this issue: expo/eas-cli#3682. In the issue, the user reports that the documentation of Gradle JVM args doesn't match the actual `GRADLE_OPTS` set in builds. # How <!-- How did you build this feature or fix this bug and why? --> I have compared the documentation with the worker code (https://github.com/expo/eas-cli/blob/8229dc826513845d82ac4279d0b62394623935cf/packages/worker/src/env.ts#L84-L105), and confirmed the discrepancy. To clarify the Gradle opts, I've created a dedicated sub-section in "Build reference -> Infrastructure" documentation. Apart from clarifying the `GRADLE_OPTS` value, I have also added a warning about those opts overriding JVM args set in a project's `gradle.properties`; I have also provided an information about the possibility to override the `GRADLE_OPTS` by specifying them in `env` manually. # Test Plan <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> Tested manually <img width="987" height="792" alt="image" src="https://github.com/user-attachments/assets/536e616c-5d3c-4c6d-a424-7037f1145765" /> # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [ ] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [x] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
# Why
Wire `expo-observe` up to `expo-router` so navigation produces the
metrics App Metrics needs out of the box: time-to-render (TTR) for every
screen plus time-to-interactive (TTI) for screens that call
`useObserve().markInteractive()`. Previously the integration scaffolding
existed but emitted nothing — no listeners, no metrics.
# How
```mermaid
sequenceDiagram
participant App as App launch
participant Router as expo-router
participant Init as init.ts (listeners)
participant Hook as useObserveForRouter
participant Metrics as AppMetrics
App->>Init: appLaunchTime = Date.now()
Router->>Init: pageFocused (first)
Init->>Metrics: TTR { isAppLaunch: true }
Router->>Init: actionDispatched (NAVIGATE)
Note right of Init: store dispatchTime
Router->>Init: pageFocused
Init->>Metrics: TTR { isAppLaunch: false }
Hook->>Metrics: markInteractive() → TTI (now − dispatchTime)
```
# Test Plan
- Observe tester -> check session for navigation category
- Click house
<img width="590" height="505" alt="Screenshot 2026-05-08 at 20 59 08"
src="https://github.com/user-attachments/assets/727f0724-3891-492e-a9d5-e13c75a7ad4f"
/>
# Checklist
<!--
Please check the appropriate items below if they apply to your diff.
-->
- [ ] I added a `changelog.md` entry and rebuilt the package sources
according to [this short
guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting)
- [ ] This diff will work correctly for `npx expo prebuild` & EAS Build
(eg: updated a module plugin).
- [ ] Conforms with the [Documentation Writing Style
Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…45664) # Why We were seeing tvOS builds try to link an iOS-only precompiled Expo XCFramework. With `EXPO_USE_PRECOMPILED_MODULES=1`, CocoaPods treated the prebuilt XApplication.tar.gz as available just because the tarball existed. It did not check whether EXApplication.xcframework/Info.plist contained a tvos slice. So for a tvOS target, CocoaPods vendored the iOS-only EXApplication.xcframework, and the Xcode build later failed at link time with errors like: ``` ld: framework 'EXApplication' not found ``` The fix makes prebuilt resolution platform-aware, so tvOS falls back to source when the prebuilt XCFramework only contains iOS slices. # How Instead of using a prebuilt XCFramework just because its tarball exists, precompiled_modules.rb now reads the XCFramework Info.plist and checks AvailableLibraries[*].SupportedPlatform against the current CocoaPods target platform. osx is normalized to macos. AutolinkingManager passes the target platform into PrecompiledModules, so tvOS/macOS/etc. fall back to source when a prebuilt only contains iOS slices. We also cached the slice checks to avoid repeatedly unpacking tarballs. # Test Plan ✅ Ran temp tvOS project with `EXPO_USE_PRECOMPILED_MODULES=1` and verified the error. Applied the fix and reran. ✅ Verified BareExpo ✅ Verified Minimal Tester # Checklist - [x] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [x] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin).
# Why The Expo UI overview page listed only `DateTimePicker` under "Drop-in replacements", while the dedicated `drop-in-replacements` page listed the full set. Two lists drifted out of sync. <!-- Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests. --> # How <!-- How did you build this feature or fix this bug and why? --> # Test Plan <!-- Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction. --> # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [ ] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
…45633) # Why Turns out that `startSession` and `stopSession` are not needed for router integration anymore. # How 1. Remove android native implementation 2. Update types 3. Update module.web # Test Plan CI # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [ ] I added a `changelog.md` entry and rebuilt the package sources according to [this short guide](https://github.com/expo/expo/blob/main/CONTRIBUTING.md#-before-submitting) - [ ] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). - [ ] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
# Why There was a bug in calculating the safe area bounds for the FAB. In the first invocation of `rememberFabState`, `SafeBarInsets` were (0,0). <img width="906" height="50" alt="Screenshot 2026-05-11 at 15 09 16" src="https://github.com/user-attachments/assets/35f0a8c1-eef8-47db-9a58-b9b92764cb65" /> This value stayed in `FabState` forever because the `remember` clause lacked change keys, causing the FAB to be positioned above the statusBar: <img width="377" height="93" alt="Screenshot 2026-05-12 at 10 52 11" src="https://github.com/user-attachments/assets/415a047d-2f57-4a19-a769-b7f9ee0ee463" /> The easier fix would be to make bounds mutable: ```kotlin val state = remember { FabState(initialOffset, fabBounds, prefs) } state.fabBounds = fabBounds ``` However, there is a better solution: slightly changing the architecture to move safe-area responsibility to `MovableFloatingActionButton`. This is achieved with the `safeDrawingPadding` modifier. It works like `WindowInsets.systemBars` but removes the need for manual calculations in `rememberFabState`. This way, the source of truth for bounds is the `BoxWithConstraints` size, not `rememberFabState` logic. # How - Simplified FabState to properties used inside the class; moved the rest of responsibilities to `MovableFloatingActionButton` - Made state bounds mutable so they can update when they change (as seen in the screenshot above). # Test Plan BareExpo ✅ [Screen_recording_20260512_104957.webm](https://github.com/user-attachments/assets/352ed42a-fec9-479c-9216-8c950a7f9fe3)
# Why Follow-up to the #45564, updating the imports from expo-modules-core to expo. # How - Updated the imports in packages that use permissions-related types and functions from expo-modules-core. # Test Plan BareExpo ✅
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )