fix(ios): keep the podspec's build attributes out of the OpenCV branch - #1452
Merged
Conversation
`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.
8 tasks
barhanc
approved these changes
Sep 9, 2026
msluszniak
added a commit
that referenced
this pull request
Sep 9, 2026
) ## Description Backports the three 0.10.0 setup fixes from `main` to `release/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. | commit | PR | | --- | --- | | `12ce3bb` | #1448 fix(ios): narrow the podspec's public headers | | `c51f76a` | #1449 fix(deps): require worklets >=0.10.0 <0.13.0 and document it | | `a1ff6c9` | #1450 fix(build): fail with the cause when the setup is wrong | | `080e764` | #1452 fix(ios): keep the podspec's build attributes out of the OpenCV branch | All four are now on `main`; #1452 merged as `c8f44f6`. Only conflict was `docs/versioned_docs/version-0.10.0/**`: that snapshot exists on `main` only, since on this branch `docs/docs` **is** the 0.10 documentation. Those three hunks were dropped and the equivalent `docs/docs` changes came across in the same commits. `packages/react-native-executorch/package.json` keeps `0.10.0`; only the worklets peer range changed. ### 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 `yarn workspace react-native-executorch test` passes, 3868 tests across 34 suites. The podspec, `android/build.gradle.kts`, `scripts/download-libs.js` and the new podspec test on this branch are byte-identical to `main`: ```bash git fetch origin main git diff origin/main HEAD -- packages/react-native-executorch/react-native-executorch.podspec \ packages/react-native-executorch/android/build.gradle.kts \ packages/react-native-executorch/scripts/download-libs.js \ packages/react-native-executorch/__tests__/api/podspecAttributes.test.ts ``` ### Related issues #1448, #1449, #1450, #1452 --------- Co-authored-by: Bartosz Hanc <bartosz.hanc02@gmail.com> Co-authored-by: Mateusz Słuszniak <msluszniak1@gmail.com>
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
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
Two defects in #1450, both reproduced against
mainata1ff6c9.if enable_opencvwas never closed. Itsendsat at the bottom of the spec, one line aboveinstall_modules_dependencies(s), and the indentation of everything after thes.dependencycall reads as if the block had already ended. So five attributes were assigned only when OpenCV was on:pod_target_xcconfigHEADER_SEARCH_PATHSentryvendored_frameworksExecutorchLib.xcframeworkstatic_frameworkuse_frameworks!fix from #1448librariesz,sqlite3frameworksAccelerate,CoreML, MetalAn app that turns OpenCV off through the
libsconfig 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_configwas nil without a config file. Theelsebranch set the fiveenable_*flags but never assigned the hash, and #1450 addedrne_build_config["opencvPod"]on the path that branch reaches, so a checkout withoutrne-build-config.jsonraisedNoMethodErrorduringpod 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 installis the only thing that runs this file, and every example app takes the same config row, so a misplacedendpasses lint, types, tests and review.__tests__/api/podspecAttributes.test.tsevaluates the real podspec under a stubbedPod::Specand asserts the build-critical attributes are assigned, for eight config rows. Againsta1ff6c9it fails three of them:Introduces a breaking change?
Type of change
Tested on
Testing instructions
Needs an
enableOpencv: falsepod installon a device build before merge; I have only run the podspec evaluation.Related issues
Follow-up to #1450.
Additional notes
Backport to
release/0.10goes on top of #1451.