`run-ios` in release configuration

[lunaleaps]

There are a couple of issues with npx react-native run-ios --configuration 'Release'

1. index.js does not exist

@mikehardy has reported an error with

npx react-native init TestProject66 --version 0.66.0-rc.0
cd TestProject66
npx react-native run-ios --configuration 'Release'

and getting error:

❌  error: Entry file index.js does not exist. If you use another file as your entry point, pass ENTRY_FILE=myindex.js

2. thread-local storage is not supported for the current target

@lunaleaps has issue with Xcode 12.5 for both 0.65.1 and 0.66.0-rc.0 when running:

npx react-native init TestProject [--version 0.66.0-rc.0]
cd TestProject
npx react-native run-ios --configuration 'Release'

and getting the error:

warning: Capabilities for Signing & Capabilities may not function correctly because its entitlements use a placeholder team ID. To resolve this, select a development team in the MyTestProject66 editor. (in target 'MyTestProject66' from project 'MyTestProject66')
/Users/luwe/MyTestProject66/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.5.99. (in target 'YogaKit' from project 'Pods')
/Users/luwe/MyTestProject66/ios/Pods/Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.5.99. (in target 'Flipper-Glog' from project 'Pods')

The following build commands failed:
    CompileC /Users/luwe/Library/Developer/Xcode/DerivedData/MyTestProject66-efwtfjnninejtqfidwsnxehgajhj/Build/Intermediates.noindex/Pods.build/Release-iphonesimulator/RCT-Folly.build/Objects-normal/i386/F14Table.o /Users/luwe/MyTestProject66/ios/Pods/RCT-Folly/folly/container/detail/F14Table.cpp normal i386 c++ com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)

This seems like a known issue and has some discussion here: https://github.com/facebook/react-native/issues/31480#issuecomment-897733307

@lunaleaps has tried following @MikeHardy's suggestions by adding this to Podfile: https://github.com/facebook/react-native/issues/31480#issuecomment-902912841 but hasn't worked.

[lunaleaps]

Action Items:

• If anyone can repro number 1, please comment.
• For number 2, @lunaleaps is going to try with Xcode 13 and see if run into same issues

[mikehardy]

I'm surprised the post install doesn't work, it must not have been applied correctly, if it really moved deployment target up, then the symbol exists and f14table compiles this is a rare 'really really does work around it' 100% certainty workaround. That sad, still needs a real fix 😁

[mikehardy]

Xcode 13 only works with same workarounds, I've tested. Also needs the swift hack I think, to set library path

[fkgozali]

@mikehardy I did a clean try on Xcode 12.5. With your post_install workaround, I was able to successfully build the Release flavor. I couldn't repro the index.js issue though

The post_install hack: https://github.com/facebook/react-native/issues/31480#issuecomment-902912841

[fkgozali]

I couldn't repro the index.js issue though

oops, looks like I accidentally had an unrelated index.js in a parent dir, so that "avoided" the problem but incorrectly. The issue is this line is looking for index.js at the wrong directory level...:

https://github.com/facebook/react-native/blob/main/scripts/react-native-xcode.sh#L77

We'll fix forward and pick to 0.66 RC

[lunaleaps]

@mikehardy Yup as Kevin mentioned we were able to repro your issue and found the cause to be changes in https://github.com/facebook/react-native/pull/29263

Additionally, I got around the thread-local storage is not supported for the current target error with your "dance" post_install hook. I just didn't realize I needed to run pod install after updating the Podfile. I thought npx react-native run-ios.. would run it..whoops!

Thanks for all your help!

[lunaleaps]

But as a side-note.. we should figure out how to not have to do this "dance".. I'm not exactly sure what that would be.. but on my radar

[mikehardy]

I also would really love to avoid the intricate post-install hackery but:

a) I am happy that I'm not crazy / I'm generating reproducible reports at all. I mean, that's like 90% of the job and it's quite frustrating at times! b) I am really happy that you were able to see the full requirement of post-install hackery needed, and also see that when you put it all together, it really does work, see a) about reproduction :-) b) I am really really happy that you were able to find the release mode issue - since that's the only issue I saw, makes me excited to see 0.66 wind its way to release

Cheers!

[fkgozali]

@mikehardy - any concern if we include your post_install workaround in the app template for 0.66 for now? Yes it's not ideal, but it would unblock many ppl atm.

[mikehardy]

None at all - I've been using it personally and hearing success feedback on it for all the major configs (M1 or intel, hermes or no) so it should improve dev experience, and worst case it's just the template, people can rip it out

[mikehardy]

(although that said, no good deed will be unpunished, I'm sure we'll discover some new corner cases if/when it goes in - still, incremental improvement...)

[fkgozali]

Yeah understood, we're just trying to buy some time atm :). I'll add your workaround with a big warning

[fkgozali]

Alright, ENTRY_FILE fix: https://github.com/facebook/react-native/commit/945c5f714d9b3a75f0be02b3a408f865c9021aa7 And post_install recipe: https://github.com/facebook/react-native/commit/ac4ddec542febda744de218dae3a3d34edc7da84

[fkgozali]

Keeping this open until commits are picked and in case you wanna verify @mikehardy

[mikehardy]

Hey @fkgozali i checked and the commit listed as fixing m1 builds does not work

https://github.com/facebook/react-native/commit/eb938863063f5535735af2be4e706f70647e5b90

That might fix xcode 13 on Intel, but m1 requires swift libs first not last. Of course that seems strange but it's a real thing, I tested both variations, only swift first builds on m1 in my experience. Unexpected result but that's what I saw, and there's positive results with it on the Apple m1 issue.

Discussion visible on ios discord channel

[fkgozali]

That might fix xcode 13 on Intel, but m1 requires swift libs first not last.

Yeah I saw your discussion with @sammy-SC. In fact, a commit is landing as of now to switch that order in app template and RNTester. So with those picked to RC 0.66, hopefully that's all we need :)

[mikehardy]

Fantastic! Then yes - with that order being swift-first and the Folly "dance" (ios version bump + avoiding redefining time symbol) everything on Apple machines should be happy :crossed_fingers:

[fkgozali]

Alright, here's the commit: https://github.com/facebook/react-native/commit/329b026f3a48a4228a89696540ba459276f9a2c2 -- will request pick

[lunaleaps]

Closing as this is now fixed in 0.66.0-rc.2