Conversation
…49072) # Why resolves #43118 by default, so far, notifications delivered to the app while it's foregrounded, were ignored. Users would have to set their own handler using `setNotificationHandler`. # How - set default notification handler that presents notifications - also present notifications by default when the handler times out - on android the timeout path passed no behavior at all, which resolves priority differently from what the default handler asks for. docs are in the stacked PR #49077. # Test Plan - notification tester app - `apps/test-suite` Notifications specs, on android and ios: default shows, slow handler still shows once it times out, removed handler doesn't show # Checklist <!-- Please check the appropriate items below if they apply to your diff. --> - [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) - [ ] 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) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
# Why replacement for #43118 Stacked on top of #49072, which makes `expo-notifications` show a notification that arrives while the app is in the foreground. The guides still described the old behavior, where such a notification was dropped unless the app set a handler that asked for it. this adds the docs # How update docs # Test Plan # Checklist - [x] Documentation is up to date to reflect these changes (this PR is the documentation). - [x] Conforms with the [Documentation Writing Style Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md). - [ ] `CHANGELOG.md` entry — not applicable; the changelog entry for this behavior ships in #49072. - [ ] Ran `et check-packages` — not applicable; this PR changes no package. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
# Why `expo-notifications` still wrapped `NotificationsEmitterModule` and `NotificationsHandlerModule` in the deprecated `LegacyEventEmitter` # How migrate away from it # Test Plan - Built and ran `apps/notification-tester` on an iOS simulator and drove it through a few test cases # 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)
…ges (#49065) # Why Expo's EAS build service hosts prebuilt XCFramework versions of some of the main npm packages that are most often used in Expo projects to reduce build times (specifically reduces build times for C++ heavy packages). A workflow exists to rebuild these when we change our versions of these packages in our repo (`.github/workflows/ios-prebuild-external-xcframeworks.yml`). The problem with this is that our XCFrameworks are rebuilt only when the version of the package itself has changes, but not when React Native itself has changed. Since the URLs for these packages includes a key on the RN version these packages will never be rebuilt when RN itself changes (without the 3rd part package itself is changed): `<pkg>/output/<pkgVersion>/<rnVersion>/<hermesVersion>/<flavor>/xcframeworks/<Product>.tar.gz` (Hermes version is always connected to the RN-version, so it could've been omitted here) # How Fix the detect logic in the workflow to also include the React Native version when testing if frameworks should be rebuilt, and then issue a rebuild all when RN's version changed. # Test Plan Replayed the detection logic against three different commits and verified that changes in RN version now results in rebuilding all packages. # Checklist - [x] This diff will work correctly for `npx expo prebuild` & EAS Build (eg: updated a module plugin). --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Automated upstream sync of generated reference content. | Generator | Status | | --- | --- | | App config schema | ➖ No changes | | Expo Skills | ✅ Synced | | EAS CLI reference | ➖ No changes | | Android permissions | ➖ No changes | ## Files - `docs/ui/components/ExpoSkillsTable/data/expo-skills.json` Co-authored-by: Expo Bot <expo-bot@users.noreply.github.com>
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.
4 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 : )