fix: dynamically resolve RCTRootContentView for Expo SDK 56 static-framework builds

[1kuko3]

Summary

Fixes #40 — the Undefined symbols ... _OBJC_CLASS_$_RCTRootContentView link error reported under Expo SDK 56 / RN 0.82 with static frameworks.

RCTView+Helpers.swift references RCTRootContentView directly, which is no longer reliably exposed as an Obj-C symbol under use_frameworks! :linkage => :static in newer React Native versions. This PR looks it up at runtime via NSClassFromString("RCTRootContentView") instead — the same pattern as commit 7936d90 (fix FollyConvert.h for static frameworks).

Changes

• closestParentReactContentView resolves RCTRootContentView via NSClassFromString and uses the closure-based recursivelyFindParentView(where:) / recursivelyFindSubview(where:) helpers with isKind(of:).
• Return type widened from RCTRootContentView? → RCTView?. This is unavoidable: keeping RCTRootContentView? as the declared return type reintroduces the static type reference that caused the link error in the first place.
• Added import Foundation for NSClassFromString.

Why this version vs. the patch in #40

@julian-gargicevich posted a similar workaround in #40 using:

guard let targetType = NSClassFromString("RCTRootContentView") as? RCTView.Type else { return nil }
self.recursivelyFindParentView(whereType: targetType)

This PR uses isKind(of:) with the closure-based helpers instead, which avoids relying on the dynamic metaclass being castable to RCTView.Type and matches the existing whereType: semantics more directly. Credit to @julian-gargicevich for identifying the dynamic-lookup approach.

API change note

The return-type change is source-breaking for any external consumer that explicitly annotated the result as RCTRootContentView? or relied on subclass-specific members. In practice the only member used internally is reactTouchHandlers (line 68), which is defined on RCTView, so the internal caller still works. Calling out explicitly so the maintainer can weigh.

Test plan

• Verified in production under Expo SDK 56 in a consumer app (Lugg / consumer-app). The exact same change resolves the _OBJC_CLASS_$_RCTRootContentView link error reported in Expo SDK 56 #40 and has been running in our Expo SDK 56 builds.
• Local example build of examples/example-v0.80.1 was attempted with USE_FRAMEWORKS='static' RCT_NEW_ARCH_ENABLED=1 (the failing config from Expo SDK 56 #40) but is blocked by a pre-existing toolchain incompat — Xcode 26 vs the fmt version pinned by RN 0.80.1 (consteval strictness change in fmt/format-inl.h). This fails identically on clean upstream master, so it's not introduced by this change.
• Recommend the maintainer run scripts/test-build-ios-all.sh on the supported Xcode (16.2 per log-test-build-ios-all.txt) and refresh that log if accepted.

🤖 Generated with Claude Code

[1kuko3]

@nandorojo can we get your 👀 on this? Fixes #40 — verified in prod under Expo SDK 56.

[hknakn]

I hit this same iOS build blocker after upgrading to Expo SDK 56 / RN 0.85.3.

I already fixed the related Galeria SDK 56 issue here: nandorojo/galeria#128, but this PR is still needed because the build now fails in react-native-ios-utilities.

Would be great to get this merged/released.

cc: @dominicstop @nandorojo @OrkhanAlikhanov @julian-gargicevich

[nandorojo]

merged thank you. i think we might need a version number bump for this to publish

[Bartek532]

Can we get it released?

[davdream]

Hey @nandorojo, can we get a new version pls?

[Bartek532]

hey @nandorojo I saw you created a new release on Github, but it seems it never reached npm and it could not be installed (I guess some access token expired?). Could we handle that?

[nandorojo]

I unfortunately don't have Npm access but I reached out to @dominicstop

[Bartek532]

Any updates on this?

[davdream]

@nandorojo did you hear back from @dominicstop?

[zigcccc]

hey gang - @dominicstop any chance this gets bumped and released? thank you!

[Bartek532]

Is there any workaround to allow upgrading to Expo SDK 56 without this lib updated?

[1kuko3]

@Bartek532 a couple of options until this gets published to npm:

1. Patch it locally with your package manager (pnpm patch, bun patch, etc.) and apply the diff from this PR on top of your installed version.
2. Point the dependency at the commit - since this is already on main, you can install straight from git instead of maintaining a patch: "react-native-ios-utilities": "github:dominicstop/react-native-ios-utilities#1352a26b515438ea5d1646c5953065c37c311e6b"

[davdream]

This is embarrassing. Two months have passed and still no release on NPM. @nandorojo @dominicstop