fix(🍏): include cpp/skia in HEADER_SEARCH_PATHS for static frameworks

[mini-777]

Summary

Under use_frameworks! :linkage => :static (Expo: expo-build-properties with ios.useFrameworks: 'static'), the iOS native build fails with:

'include/core/SkImage.h' file not found
'include/core/SkRefCnt.h' file not found

The header exists at cpp/skia/include/core/SkImage.h. Skia's own vendored headers reference each other using the root-relative form #include "include/core/SkImage.h" — for example:

• cpp/skia/include/core/SkSurface.h
• cpp/skia/include/gpu/ganesh/SkImageGanesh.h
• cpp/skia/include/gpu/graphite/Image.h
• cpp/skia/include/effects/SkImageFilters.h

Under static frameworks the recursive "$(PODS_TARGET_SRCROOT)/cpp/"/** glob in HEADER_SEARCH_PATHS doesn't appear to propagate cpp/skia as a search root, so those root-relative includes don't resolve.

Adding cpp/skia explicitly to HEADER_SEARCH_PATHS fixes the native compile step.

Context

I previously opened #3849 for what looked like a related issue (also static frameworks). It was superseded by #3853, which fixed cpp/api/* includes by rewriting their relative paths. That approach doesn't apply here because the failing includes live inside Skia's vendored headers in cpp/skia/include/**, which can't be rewritten on the react-native-skia side.

It's possible the existing test-package-e2e-static-frameworks job doesn't surface this — the Expo template likely only exercises shallow Skia API and doesn't transitively pull in SkSurface/SkImage headers. Happy to extend the e2e test if useful.

Verified

Same app, same useFrameworks: 'static', two back-to-back EAS production builds:

• Without this change (@shopify/react-native-skia@2.6.3 stock): native compile fails with 'include/core/SkImage.h' file not found / 'include/core/SkRefCnt.h' file not found.
• With this change applied locally via patch-package: the native compile step passes and the build proceeds to subsequent stages.

Scope note

My local patch had added five paths (cpp/api, cpp/skia, cpp/jsi, cpp/rnskia, cpp/utils) — that was the original PR #3849. After #3853 landed, the other four don't seem necessary for my build; cpp/skia is the one that remains required. Keeping the change minimal here. If I've missed a case where one of the others is still needed, happy to add them back.

[wcandillon]

My apologies for the PR not fixing and thank you for your comprehensive bug report, your issue, is there any chance you could update the test-package-e2e-static-frameworks so I could reproduce the issue? That being said, this is a very sensible report and I will investigate it.

…

On Sat, May 23, 2026 at 7:13 PM Sung Min ***@***.***> wrote: Summary Under use_frameworks! :linkage => :static (Expo: expo-build-properties with ios.useFrameworks: 'static'), the iOS native build fails with: 'include/core/SkImage.h' file not found 'include/core/SkRefCnt.h' file not found The header exists at cpp/skia/include/core/SkImage.h. Skia's own vendored headers reference each other using the root-relative form #include "include/core/SkImage.h" — for example: cpp/skia/include/core/SkSurface.h cpp/skia/include/gpu/ganesh/SkImageGanesh.h cpp/skia/include/gpu/graphite/Image.h cpp/skia/include/effects/SkImageFilters.h Under static frameworks the recursive "$(PODS_TARGET_SRCROOT)/cpp/"/** glob in HEADER_SEARCH_PATHS doesn't appear to propagate cpp/skia as a search root, so those root-relative includes don't resolve. Adding cpp/skia explicitly to HEADER_SEARCH_PATHS fixes the native compile step. Context I previously opened #3849 for what looked like a related issue (also static frameworks). It was superseded by #3853, which fixed cpp/api/* includes by rewriting their relative paths. That approach doesn't apply here because the failing includes live inside Skia's vendored headers in cpp/skia/include/**, which can't be rewritten on the react-native-skia side. It's possible the existing test-package-e2e-static-frameworks job doesn't surface this — the Expo template likely only exercises shallow Skia API and doesn't transitively pull in SkSurface/SkImage headers. Happy to extend the e2e test if useful. Verified Same app, same useFrameworks: 'static', two back-to-back EAS production builds: Without this change ***@***.******@***.*** stock): native compile fails with 'include/core/SkImage.h' file not found / 'include/core/SkRefCnt.h' file not found. With this change applied locally via patch-package: the native compile step passes and the build proceeds to subsequent stages. Scope note My local patch had added five paths (cpp/api, cpp/skia, cpp/jsi, cpp/rnskia, cpp/utils) — that was the original PR #3849. After #3853 landed, the other four don't seem necessary for my build; cpp/skia is the one that remains required. Keeping the change minimal here. If I've missed a case where one of the others is still needed, happy to add them back. ________________________________ You can view, comment on, or merge this pull request online at: #3854 Commit Summary 0b9a1a9 fix(🍏): add cpp/skia to HEADER_SEARCH_PATHS for static frameworks File Changes (1 file) M packages/skia/react-native-skia.podspec (2) Patch Links: https://github.com/Shopify/react-native-skia/pull/3854.patch https://github.com/Shopify/react-native-skia/pull/3854.diff — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mini-777]

Update — I was able to reproduce locally with a clean, minimal command (no signing, no archive).

Reproduction

Stock @shopify/react-native-skia@2.6.3, expo-build-properties with ios.useFrameworks: 'static', then:

xcodebuild build \
  -workspace ios/app.xcworkspace \
  -scheme app \
  -configuration Release \
  -sdk iphoneos \
  -destination 'generic/platform=iOS' \
  CODE_SIGNING_ALLOWED=NO

Result on stock 2.6.3:

node_modules/@shopify/react-native-skia/cpp/api/third_party/SkottieUtils.h:10:10:
fatal error: 'include/core/SkRefCnt.h' file not found
   10 | #include "include/core/SkRefCnt.h"
** BUILD FAILED **

With this PR's one-line change applied, the same command succeeds.

Why the existing test-package-e2e-static-frameworks doesn't catch it

The current job runs expo run:ios --device <simulator>, which builds:

• Configuration: Debug
• SDK: iphonesimulator
• Architecture: arm64 + x86_64 (simulator)

The failure only surfaces in:

• Configuration: Release
• SDK: iphoneos
• Architecture: arm64 (device)

So archive mode / signing are not necessary to repro — Release + iphoneos alone is enough. Likely a HEADERMAP/vfs resolution difference between the two SDKs under use_frameworks! :linkage => :static.

Failing files (both in the pod's source set)

apple/ViewScreenshotService.h:15        → #include "include/core/SkImage.h"
cpp/api/third_party/SkottieUtils.h:10   → #include "include/core/SkRefCnt.h"

Environment where this fails (EAS production build of my app)

Xcode	26.4 (17E202)
CocoaPods	1.16.2
Configuration	Release
SDK	iphoneos
Arch	arm64 (device)

Suggested e2e extension

Adding a Release + iphoneos device build (no signing) to the static-frameworks job should reproduce this in CI. Happy to push that to this PR's branch — let me know if you'd like me to.

[RodolfoSilva]

After applying this patch, it solved my build issue. I also had to exclude @shopify/react-native-skia from expo install --check/expo-doctor. Thanks @mini-777

@shopify+react-native-skia+2.6.3.patch

[peterjskaltsis]

Same issue here, and the patch worked for me too

[AryashDubey]

This patch worked for me as well

[wcandillon]

Thanks a lot for this 💚

[github-actions]

🎉 This PR is included in version 2.6.4 🎉

The release is available on:

• v2.6.4
• GitHub release

Your semantic-release bot 📦🚀