iOS Prebuilds for React Native Dependencies

[cipolleschi]

Starting from React Native 0.80, we are shipping part of React Native for iOS as a prebuild. This helps to reduce build times and build errors related to React Native.

We experimented and benchmarked how much time this initial prebuild for iOS is saving and, in our benchmarks, run on an M4 machine, iOS builds are roughly 12% faster with the prebuild rather than by building from source.

Build Time [s]	With Prebuilds	No Prebuilds	Improvement [%]
Average	131.491	150.262	12.5 %
St. Deviation	10.6257536	15.15225454	29.9 %

T-statistic: -3.1505; p-value: 0.00553

From our experience, we also observed that several bug reports from users are caused by build issues related with React Native’s 3rd party dependencies (example #39568).
Prebuilding the 3rd party dependencies allows us to build them for you, so that you won’t face these build issues anymore.

Note that we are not pre-building the whole React Native: we are only pre-building the libraries Meta does not directly control, such as Folly and GLog.

In a future release, we will also ship the rest of React Native core as a prebuild.

How to use them

This feature is still experimental, so it is not turned on by default.
If you want to use them, you can install your pods by adding the RCT_USE_RN_DEP env variable:

RCT_USE_RN_DEP=1 bundle exec pod install

Alternatively, if you want to enable it for all the developers working on that, you can modify your Podfile like this:

if linkage != nil
  Pod::UI.puts "Configuring Pod with #{linkage}ally linked Frameworks".green
  use_frameworks! :linkage => linkage.to_sym
end

+ENV['RCT_USE_RN_DEP'] = '1'

target 'HelloWorld' do
  config = use_native_modules!

The goal of this discussion is to track issues you might encounter when turning this feature on.

If you experience any problem with the prebuilds, please post a comment below this discussion.

[shirakaba]

Does the benchmark table need editing? Currently the data is suggesting that builds take 40 seconds longer when using prebuilds.

[cortinico]

Thanks for the report @shirakaba. That was obviously a mistake. I've updated the table with the correct number

[jvenene]

It looks like the blog post link is broken.

[cortinico]

It should work by now 👍

[Spring-Rebirth]

When this experimental feature is enabled, integrating the nativewind library causes a build error during compilation.

[kraenhansen]

@Spring-Rebirth great you're experimenting with this! I'd expect there's a high likelihood that sharing the contents of this build error would help fix it 😊 Getting the exact error message and steps needed to reproduce with be great 💙

[Spring-Rebirth]

I didn't save the error log. The way to reproduce is to create a new project and add that line of code in the 'Podfile'. Then follow the nativewind documentation to configure it, and finally execute 'npm run ios', and then some error logs will appear in the terminal. If you turn off this pre-build function, it will return to normal.

[Spring-Rebirth]

add this

ENV[‘RCT_USE_RN_DEP’] = ‘1’

[Spring-Rebirth]

@kraenhansen I found the root cause of the error, it was caused by 'user script sandboxing' being turned on. I'm not sure if enabling 'ios prebuild' made Xcode enable 'user script sandboxing'.

[craiganderson-iotv]

The Podfile syntax to enable this feature looks inconsistent with incorrect quote types.
For example, the blog post suggests:

ENV[‘`RCT_USE_RN_DEP`’] = ‘1’

Whereas this post uses:

ENV[‘RCT_USE_RN_DEP’] = ‘1’

From other usages within the Podfile and empirical testing, it should be:

ENV['RCT_USE_RN_DEP'] = '1'

[cipolleschi]

Fixed it, it was just bad copy-and-paste from a doc. The right ones are always '

[craiganderson-iotv]

It looks promising, until I get the following error when fetching the podspec for ReactNativeDependencies:

[!] Unable to find a specification for `RCT-Folly` depended upon by `AmplifyRTNCore`

Is this a React-Native issue, or should I raise an issue with AWS Amplify JS?

[SandrineProusteau]

Same issue :

[!] Unable to find a specification for `RCT-Folly` depended upon by `react-native-keep-awake`

You have either:
 * mistyped the name or version.
 * not added the source repo that hosts the Podspec to your Podfile.

Using "@sayem314/react-native-keep-awake": "^1.3.0", in package.json

[sharifhh]

aws-amplify/amplify-js#14493

we need to ask all libraries maintainers to use the scripts that RN team is providing to avoid breaking.

[edoko]

@microsoft/react-native-clarity also had the same issue, so I created an issue.
microsoft/clarity-apps#153

[cipolleschi]

Yeah, unfortunately, if library maintainers does not update their libraries there isn't much we can do, as we can't go to all the 1000+ libraries and open PRs to fix them. :(

The install_modules_dependencies function has been around for more than 2 years (September 2022), now. That's the only change we require so that we can ensure that libraries don't have to make other changes to their podspecs because we can control it from react-native.

[BasixKOR]

Unsure why this is the case, but it seems like there are cases where the prebuilt binaries just doesn't exist. We're seeing errors like:

::error file=rsync(7252)::/Users/runner/work/app/ios/Pods/ReactNativeDependencies/framework/packages/react-native/ReactNativeDependencies.xcframework/ios-arm64/*: (l)stat: No such file or directory

Bit cryptic but I assume this means there are no binaries available... I'm on React Native 0.80.1, with CocoaPods 1.15.2.

[BasixKOR]

After I sshed into the CI box I've found the xcframework, but it is bit out of the place.

$ ls ios/Pods/ReactNativeDependencies/framework/packages/react-native/third-party/ReactNativeDependencies.xcframework
Headers                         _CodeSignature                  ios-arm64_x86_64-maccatalyst    macos-arm64_x86_64              tvos-arm64_x86_64-simulator     xros-arm64_x86_64-simulator
Info.plist                      ios-arm64                       ios-arm64_x86_64-simulator      tvos-arm64                      xros-arm64

It seems like in some cases the third-party directory isn't removed properly. Still digging into this.

[BasixKOR]

Apparently updating from macOS 15.5 to macOS 15.6.1 solves this somehow. I know this sounds ridiculous and I'm still completely puzzled.