fix: backport the 0.10.0 setup fixes (#1448, #1449, #1450, #1452) - #1451
Merged
Conversation
## Description `use_frameworks!` makes CocoaPods build this pod as a framework, and two things break there: - plain `use_frameworks!` means dynamic linkage (what Firebase's docs show), and `pod install` refuses it: `transitive dependencies that include statically linked binaries: opencv2.xcframework` - every header was public, and 21 basenames repeat, so Xcode flat-copies them onto each other: `Multiple commands produce .../Headers/Types.h` Fixed with `s.static_framework = true` and `public_header_files` limited to the Objective-C entry points. The C++ headers stay reachable through `HEADER_SEARCH_PATHS`. Root cause found by @barhanc. ### Introduces a breaking change? - [ ] Yes - [x] No ### Type of change - [x] Bug fix (change which fixes an issue) - [ ] New feature (change which adds functionality) - [ ] Documentation update (improves or adds clarity to existing documentation) - [ ] Other (chores, tests, code style improvements etc.) ### Tested on - [x] iOS - [ ] Android ### Testing instructions Expo 57 app with the pod kept as a framework: | podspec | `pod install` | `xcodebuild` | | --- | --- | --- | | as published | fails | | | + `static_framework` | passes | fails, 21 errors | | + both | passes | `BUILD SUCCEEDED` | No regression: `:linkage => :static` installs clean, and a clean build with no `use_frameworks!` still succeeds. `__tests__/api/podspecPublicHeaders.test.ts` fails if `public_header_files` is dropped (the shipped 0.10.0 state) or widened onto the C++ tree. ### Related issues #203 ### Checklist - [x] I have performed a self-review of my code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have updated the documentation accordingly - [x] My changes generate no new warnings --------- Co-authored-by: Bartosz Hanc <bartosz.hanc02@gmail.com> (cherry picked from commit 12ce3bb)
## Description The `react-native-worklets` peer was `^0.10.0` and undocumented: the requirements page claimed React Native 0.81+ / Expo SDK 54+, which that peer rules out, and the install command asks for worklets with no version. - peer becomes `>=0.10.0 <0.13.0`. `^0.10.0` excluded worklets 0.11 and 0.12, the current releases, which carry the same API and typecheck clean here. - 0.10 stays the floor: it is the first release to serialize an `ArrayBufferView` natively ([reanimated #9475](software-mansion/react-native-reanimated#9475)). Below it a view is rebuilt over its whole backing buffer, so `new Uint8Array(buffer, 64, 16)` arrives with `length` 1024 instead of 16. Our public API takes views from user code, so that is silent corruption, not slowness. - Getting Started states the range and what SDK 55/56 users must install, since those SDKs bundle an older worklets and Reanimated pins it exactly: ```bash npm install react-native-worklets@^0.10.0 react-native-reanimated@^4.5.0 ``` Cost: Expo SDK 54, React Native 0.81 and 0.82 drop out. Expo 55 and 56 are inside worklets 0.10's range once asked for explicitly. ### Introduces a breaking change? - [ ] Yes - [x] No ### Type of change - [x] Bug fix (change which fixes an issue) - [ ] New feature (change which adds functionality) - [ ] Documentation update (improves or adds clarity to existing documentation) - [ ] Other (chores, tests, code style improvements etc.) ### Tested on - [x] iOS - [ ] Android ### Testing instructions | worklets | React Native peer | native ArrayBufferView serialization | | --- | --- | --- | | 0.8.3 / 0.9.3 | `0.81 - 0.85` | no | | 0.10.4 / 0.11.4 | `0.83 - 0.86` | yes | | 0.12.2 | `0.83 - 0.87` | yes | `__tests__/api/workletsVersionRange.test.ts` ties the range to the installed worklets, to the React Native floor it implies, and to the number in the docs, which is the pair that drifted. ### Related issues Follow-up to the compatibility question raised alongside #1448. ### Checklist - [x] I have performed a self-review of my code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have updated the documentation accordingly - [x] My changes generate no new warnings ### Additional notes The first commit took the opposite approach (peer down to 0.8.0 plus a copy at the worklet boundary); the second supersedes it, so review the net diff. `0.8.x` / `0.9.x` on React Native 0.86 are marked untested rather than guessed. Flip those cells if you know. --------- Co-authored-by: Bartosz Hanc <bartosz.hanc02@gmail.com> Co-authored-by: Mateusz Słuszniak <msluszniak1@gmail.com> (cherry picked from commit c51f76a)
Setup failures that reach the user as an error pointing somewhere else. All reproduced against the published 0.10.0. **Guards.** The native artifacts are downloaded by the postinstall hook, which pnpm 10 blocks by default (`Ignored build scripts`), as do `--ignore-scripts` and `npm ci --ignore-scripts`. `pod install` still succeeds, because CocoaPods never checks that a vendored framework exists, and the build dies later on `Build input files cannot be found`. The podspec and `build.gradle.kts` now check first and name `pnpm approve-builds` / `npm rebuild`. **Config block in a monorepo.** It was read only from `INIT_CWD`, the workspace root, so a block in `apps/mobile/package.json` was ignored and an app declaring `"libs": []` got OpenCV anyway. The lookup now also walks up from the installed package and logs which manifest it read. **Android `minSdkVersion`.** Default was 21, docs said Android 13+, nothing enforced either. `.note.android.ident` reads API 26 in all three shipped `.so` files, so anything lower shipped a library the linker is not guaranteed to load. Default is now 26. **Docs.** A Troubleshooting page keyed by the exact error text covers the rest: | setup | symptom | | --- | --- | | `use_frameworks!` dynamic | `transitive dependencies that include statically linked binaries` | | another OpenCV pod | `frameworks with conflicting names: opencv2.xcframework` | | Intel Mac, Rosetta, Intel CI | `None of the architectures in ARCHS (x86_64) are valid` | | Expo without `expo-build-properties` | iOS 17 requirement is a warning only | | default `reactNativeArchitectures` | `armeabi-v7a` / `x86` splits ship without the `.so` | The OpenCV conflict has a verified escape hatch: `"libs": ["phonemis"]` drops `opencv-rne` and `pod install` then succeeds, at the cost of every vision task. - [ ] Yes - [x] No - [x] Bug fix (change which fixes an issue) - [ ] New feature (change which adds functionality) - [ ] Documentation update (improves or adds clarity to existing documentation) - [ ] Other (chores, tests, code style improvements etc.) - [x] iOS - [ ] Android `pod ipc spec react-native-executorch.podspec` in a checkout without artifacts prints the missing paths and the fix, and passes once they exist. 7 tests in `__tests__/api/nativeLibsConfig.test.ts` cover the config lookup. Docs build and lint clean. - [x] I have performed a self-review of my code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have updated the documentation accordingly - [x] My changes generate no new warnings **The Gradle guard has not been run.** It configures at the top of `build.gradle.kts`, so please build an Android app on this branch before merging. Raising `minSdkVersion` can also break an app currently on 21-25; that build was already unsound, but it is a behaviour change. --------- Co-authored-by: Bartosz Hanc <bartosz.hanc02@gmail.com> Co-authored-by: Mateusz Słuszniak <msluszniak1@gmail.com> (cherry picked from commit a1ff6c9)
`if enable_opencv` was never closed: its `end` sat at the bottom of the spec, so `pod_target_xcconfig`, `libraries`, `frameworks`, `static_framework` and `vendored_frameworks` were all assigned only when OpenCV was on. An app that turns it off through the `libs` config block got a pod with no HEADER_SEARCH_PATHS and no ExecutorchLib, which fails at compile or link with nothing pointing back here. The same commit started reading `opencvPod` from `rne_build_config`, which the `else` branch above never assigns, so a checkout without `rne-build-config.json` raised `NoMethodError` for nil during `pod install`. That branch is gone: the config is a hash either way and every flag already reads `!= false`. `pod install` is the only thing that runs this file, and no example app covers a config other than the default, so `podspecAttributes.test.ts` now evaluates the podspec under a stubbed `Pod::Spec` and asserts the build-critical attributes are assigned for every config row. (cherry picked from commit 080e764)
msluszniak
changed the title
msluszniak
added a commit
that referenced
this pull request
Sep 9, 2026
#1452) ## Description Two defects in #1450, both reproduced against `main` at `a1ff6c9`. **`if enable_opencv` was never closed.** Its `end` sat at the bottom of the spec, one line above `install_modules_dependencies(s)`, and the indentation of everything after the `s.dependency` call reads as if the block had already ended. So five attributes were assigned only when OpenCV was on: | attribute | what an app loses without it | | --- | --- | | `pod_target_xcconfig` | every `HEADER_SEARCH_PATHS` entry | | `vendored_frameworks` | `ExecutorchLib.xcframework` | | `static_framework` | the `use_frameworks!` fix from #1448 | | `libraries` | `z`, `sqlite3` | | `frameworks` | `Accelerate`, `CoreML`, Metal | An app that turns OpenCV off through the `libs` config block installs fine and then fails to compile or link. #1450 is what made this reachable: before it, a config block in an app package was ignored and OpenCV was always on. **`rne_build_config` was nil without a config file.** The `else` branch set the five `enable_*` flags but never assigned the hash, and #1450 added `rne_build_config["opencvPod"]` on the path that branch reaches, so a checkout without `rne-build-config.json` raised `NoMethodError` during `pod install`. The comment above it names that case as supported ("a fresh checkout where the native libs were provisioned manually"). The branch is gone: the config is a hash either way, and every flag already reads `!= false`, so an empty hash means all-enabled. **Test.** `pod install` is the only thing that runs this file, and every example app takes the same config row, so a misplaced `end` passes lint, types, tests and review. `__tests__/api/podspecAttributes.test.ts` evaluates the real podspec under a stubbed `Pod::Spec` and asserts the build-critical attributes are assigned, for eight config rows. Against `a1ff6c9` it fails three of them: ``` ● with no config file (manual provisioning) podspec:242: undefined method `[]' for nil:NilClass (NoMethodError) ● with opencv off ● with every optional library off missing: pod_target_xcconfig, static_framework, vendored_frameworks, libraries, frameworks ``` ### Introduces a breaking change? - [ ] Yes - [x] No ### Type of change - [x] Bug fix (change which fixes an issue) - [ ] New feature (change which adds functionality) - [ ] Documentation update (improves or adds clarity to existing documentation) - [ ] Other (chores, tests, code style improvements etc.) ### Tested on - [ ] iOS - [ ] Android ### Testing instructions ```bash yarn workspace react-native-executorch test __tests__/api/podspecAttributes.test.ts git stash && yarn workspace react-native-executorch test __tests__/api/podspecAttributes.test.ts # 3 failures ``` Needs an `enableOpencv: false` `pod install` on a device build before merge; I have only run the podspec evaluation. ### Related issues Follow-up to #1450. ### Additional notes Backport to `release/0.10` goes on top of #1451.
msluszniak
marked this pull request as ready for review
September 9, 2026 17:14
barhanc
approved these changes
Sep 9, 2026
msluszniak
added a commit
that referenced
this pull request
Sep 9, 2026
## Description Patch release **v0.10.1**. The fixes are already on `release/0.10` via #1451 (backports of #1448, #1449, #1450, #1452); this PR only bumps the version. - `packages/react-native-executorch/package.json`: `0.10.0` -> `0.10.1`. `nativeLibsVersion` stays `0.10.0`; the native artifacts release is unchanged. - `src/fetcher/telemetry.ts`: `LIB_VERSION` -> `0.10.1`, asserted equal to the package version by `__tests__/fetcher/telemetry.test.ts`. Satellites (`bare-resource-fetcher`, `expo-resource-fetcher`, `webrtc`) are untouched by the backports, so their versions stay at `0.10.0`. `models.ts` stays on `resolve/v0.10.0`; no model files moved. ### Introduces a breaking change? - [ ] Yes - [x] No ### Type of change - [x] Other (chores, tests, code style improvements etc.) ### Tested on - [ ] iOS - [ ] Android ### Testing instructions CI runs `yarn workspace react-native-executorch test`; the telemetry version assertion covers the bump. ### Related issues #1451 ### Checklist - [x] I have performed a self-review of my code - [x] My changes generate no new warnings
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Description
Backports the three 0.10.0 setup fixes from
maintorelease/0.10, plus the follow-up that fixes two defects in the third one. Cherry-picked with-x, no manual edits to any of them.12ce3bbc51f76aa1ff6c9080e764All four are now on
main; #1452 merged asc8f44f6.Only conflict was
docs/versioned_docs/version-0.10.0/**: that snapshot exists onmainonly, since on this branchdocs/docsis the 0.10 documentation. Those three hunks were dropped and the equivalentdocs/docschanges came across in the same commits.packages/react-native-executorch/package.jsonkeeps0.10.0; only the worklets peer range changed.Introduces a breaking change?
Type of change
Tested on
Testing instructions
yarn workspace react-native-executorch testpasses, 3868 tests across 34 suites.The podspec,
android/build.gradle.kts,scripts/download-libs.jsand the new podspec test on this branch are byte-identical tomain:Related issues
#1448, #1449, #1450, #1452