You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unable to use other configurations than Debug and Release on 0.40 #11813
in XCode we can duplicate the default build Configurations by navigating to our Project -> info tab -> click on the plus symbol and duplicate any of the existing configs (debug, Release). Set a new name. Now when edit our scheme and tell XCode to use our new config the build process won't finish. Most probably you'll end up with this error:
fatal error: 'React/RCTBundleURLProvider.h' file not found
After staring at the screen for a day I think that the issue is that the build script is copying the React files to either debug-iphoneos or release-iphoneos instead of using the "newconfig"-iphoneos directory.
REPROPDUCTION
Steps to reproduce:
create a new RN project:
react-native init test
Now open the project in XCode, click on your project in the folder tree. Then select the project -> your project and navigate to the Info tab. Duplicate one of the configurations and give it whatever name you like.
Edit your current scheme and select the new configuration in the "build configuration" option. Now run the project. It should fail.
You can repeat the same steps on RN 0.39 and it works...
Here a few screenshots of the proper screens in XCode:
And on this screen you can see that RTCBundleURLProvider.h is being copied, but to the wrong path
Solution
Don't have one yet, most probably the issue happens somewhere in runIOS.js
Additional Information
React Native version: 0.40
Platform: iOS
Operating System: MacOS
Reacted by Yves Hoppe, Sean Holbert, Tisho Georgiev, Farzoaq Ahmad, Julian Mann, OpenFeedDev, Philip Shurpik, Jace Chen, Pardeep Singh Sanghera, Jeffery and 44 more
Just figured it out: You need to copy the Release Target in 'React' Project too with the same Name as the parent Target has. Now we need an idea how to make it less troublesome ( without touching React) or we just document it somewhere?
Reacted by Christian Bach, Alan Foster, Chandler Sun and Arturo Menchaca
@K-Leon We have had the same issue with our Staging build configuration. Adding Staging as a configuration to the React.xcodeproj sorted our 0.40.0 build issues. Release and Debug worked out of the box.
Reacted by Daniel Nagy, Alan Foster, Louis Antonelli and 徐太浪
This is a bug/feature of Xcode. It attempts to build sub-projects using the same configuration as the main project. If that configuration does not exist, Xcode uses the Release configuration. With the latest changes to public headers exposed by React.xcodeproj, these headers now go to the build path of the sub-project, which is configuration-dependent.
While adding a configuration with the same name works, it's not the most CI-friendly or future-proof solution. This is what I did, instead:
Added the React build target under the current scheme for my project. (Sidenote: if you're using fastlane to deploy, keep your project's build target in first place, otherwise fastlane gets confused and thinks you're building a library, so it never builds an ipa).
Added React under [Target] > Build Phases > Target Dependencies, which made Xcode build React before building the rest of the project.
Under [Target] > Build Settings, added a new User-Defined setting, called REACT_HEADERS_PATH. For all configurations not named Debug or Release, I set that to $(BUILD_DIR)/Release-$(PLATFORM_NAME)/include.
Under [Target] > Build Settings > Header Search Paths I added $(REACT_HEADERS_PATH) as an entry.
Repeat for all targets in your project.
When my project builds, React builds first, and since it doesn't know about configurations other than Release and Debug, it builds with the Release configuration. This places its headers under [build dir]/Products/Release-iphoneos/include. Since this path is now in the Header Search Paths of the main project, it gets picked up and everything else builds fine.
Hope this helps.
Updated 4/13 to mention repeating these steps for all targets (thanks @Twinski) and to change to the much shorter and more reliable $(BUILD_DIR) (thanks @hoolymama).
Reacted by Julian Mann, Madhu, Haley Koike, YinYin Chiu, Atticus White, Ruben, Steve Kellock, Paul Wong, Daniel Nagy, Josh Antweiler and 60 more
Reacted by Bruno Villanova, JackYu, Halil Bilir and Shintaro Morikawa
Reacted by Kiryl Kavalenka, Atticus White, Ruben, Paul Wong, rajeshsivakumar, mohammed ashfaq, Marina Miranovich, Ryan, Brian Chung, Fernand Lime and 28 more
Reacted by Dmitry Petukhov, Justin Ip, Jeffery, Yordi Uytersprot, Lung, Dominic Visco, Jeff Tannenbaum, TimorYang, Felipe Torres (fforres), Sudeep Sidhu and 14 more
I can't quite make it work with $(BUILT_PRODUCTS_DIR)/Release-$(PLATFORM_NAME)/include
For me it resolves to build/Staging-iphoneos/Release-iphoneos/include
Its probably something with my configuration - I'll experiment a bit later, but for now BUILD_DIR is working okay. Cheers!
Reacted by Tisho Georgiev, YinYin Chiu, Kenny Dits @kenny_dee and Felipe Torres (fforres)
Please give it a try and let me know how it works for you. We've got ~20 native libs now in most of our RN projects, so manually managing this would have been a nightmare.
Reacted by Antoine Lenoir, Jason More, shijun, rOundPeanut, HyperSimon, tsemerad, Hiroki Sato, Olivier THIERRY, Bruno Villanova, Gary Fung and 4 more
Reacted by Antoine Lenoir, rOundPeanut, Hiroki Sato, Matthew, Olivier THIERRY, Bruno Villanova, Brandon Minch and Aemaeth
Guys, the easiest fix that I found - is to set "CONFIGURATION_BUILD_DIR" in buildSettings of your configuration like: CONFIGURATION_BUILD_DIR = "$(BUILD_DIR)/Release$(EFFECTIVE_PLATFORM_NAME)";
Or if you want to set in XCode:
Your Project -> Build Settings -> Build Locations -> Per-configuration Build Products Path
for your new configuration: $(BUILD_DIR)/Release$(EFFECTIVE_PLATFORM_NAME)
Reacted by Gary Fung, Mike Maxwell, Abe Clark, Johan du Toit, SniperGG, Ozzy, James Wainwright, Kamil Sarna, Alex Kompaniets, Hank Brekke-Peer and 11 more
Reacted by Nam Vo, lefoy, Huỳnh Tấn Sĩ, Erin Noe-Payne and Yin cheng
@D1no Thanks for your reply. I looked at the react-native-schemes-manager when I was going to through the comments. I felt that it is doing a lot of magic in the background which always worries me because if things start to break in future, I am not sure where to look at. I tried the suggestions from @philipshurpik and @j2kun using which I was able to build the app using staging configuration. I feel that I should be able to get the frameworks to be also present in the IPA with some change in settings in Xcode.
I will use the react-native-schemes-manager if I don't find a solution to this problem soon.
Actually there is not much magic. Just automation of a very annoying Xcode manual task. Read more at the bottom of the package, it’s sources and what it does. If all react native packages would be cocoa pods, the problem would not exist. But as they all require the rn packanger which has just two build configurations, those need to be copied for all of them. Thinkmill and we use it in production, and probably many more, and it works fine with version react-native@latest with Xcode 9.
So, requiring xproject files from node_modules was never something Xcode was designed for. I mean, sometimes it feels likeXcode projects were not even designed for a code revision system, due to its cryptic uid file steucture.
Until all that changes, or the guys at the metro bundler tackle this problem in a very smart way, the work stays the same. And it is very hard to configure yourself out of that.
@D1no Thanks for the detailed reply. I feel more confident about using the scheme manager now and since I haven't been able to work around the problem I reported, I will start using it.
I just wanted to point out one small thing that after I updated the CONFIGURATION_BUILD_DIR AND POD_CONFIGURATION_BUILD_DIR, I was able to build the app. The missing frameworks in the IPA are all pods that I have installed in my app mainly Sentry, KSCrash, RSKImageCropper and QBImagePicker`. I am not sure if it sheds any more light on the problem I am having since you said that the said issue doesn't occur with packages installed using cocoa pods and that the scheme manager is mainly to fix the projects installed using npm.
Thanks again for taking the time to post your comments.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.
@shohey1226 i tried the same thing but its not working for me. Looks like the pod libraries are getting copied into Staging folder instead of release which leads to #11813 (comment)
/Users/harkirat/Library/Developer/Xcode/DerivedData/wlv1-grovuwlrhzpjbvenlreejvbtlwol/Build/Intermediates.noindex/ArchiveIntermediates/wlv1 Staging/BuildProductsPath
tests-MBP:BuildProductsPath harkirat$ ls
Release-iphoneos Staging-iphoneos
tests-MBP:BuildProductsPath harkirat$
tests-MBP:BuildProductsPath harkirat$ cd Staging-iphoneos/
tests-MBP:Staging-iphoneos harkirat$ ls
GTMOAuth2 Mixpanel QBImagePickerController
GTMSessionFetcher Pods_wlv1.framework RSKImageCropper
GoogleToolboxForMac Protobuf nanopb
tests-MBP:Staging-iphoneos harkirat$
For anyone who comes across this, I managed to piece together a working XCode setup to get:
custom build configs working for Build and Archive in my react-native init apps (using Cocoapods); if you're using fastlane, this supports its deployment, as well
Microsoft's AppCenter and CodePush iOS SDKs working with said custom build configs (Staging, Angel, etc.)
Shout out to @D1no! your solution worked for me! Been banging my head against the wall for the past few days. The solution worked for my CI system as well (buddybuild).
When I jotted that down, I hoped a blog article would be obsolete by the time it goes online. Aka improvements of the metro bundler. Oh well - for better SEO I’ll add it to my todo list. Hopefully saving some devs the long path of desperate hacks until they find that comment. 🙃
Activity
duranmla commentedon Jan 12, 2017
I think what you are looking for is something like:
check this out: 46422dd
K-Leon commentedon Jan 15, 2017
Same Issue for me - could you find a solution @compojoom ?
@javache I think you worked on the compilation stuff. Is there an easy way to get a Staging Target up?
Thank you very much!
K-Leon commentedon Jan 15, 2017
Just figured it out: You need to copy the Release Target in 'React' Project too with the same Name as the parent Target has. Now we need an idea how to make it less troublesome ( without touching React) or we just document it somewhere?
christianbach commentedon Jan 16, 2017
@K-Leon We have had the same issue with our

Stagingbuild configuration. AddingStagingas a configuration to the React.xcodeproj sorted our 0.40.0 build issues.ReleaseandDebugworked out of the box.LeoNatan commentedon Jan 17, 2017
This is a bug/feature of Xcode. It attempts to build sub-projects using the same configuration as the main project. If that configuration does not exist, Xcode uses the Release configuration. With the latest changes to public headers exposed by React.xcodeproj, these headers now go to the build path of the sub-project, which is configuration-dependent.
tisho commentedon Jan 17, 2017
While adding a configuration with the same name works, it's not the most CI-friendly or future-proof solution. This is what I did, instead:
Added the React build target under the current scheme for my project. (Sidenote: if you're using fastlane to deploy, keep your project's build target in first place, otherwise fastlane gets confused and thinks you're building a library, so it never builds an ipa).
Added React under [Target] > Build Phases > Target Dependencies, which made Xcode build React before building the rest of the project.
Under [Target] > Build Settings, added a new User-Defined setting, called
REACT_HEADERS_PATH. For all configurations not named Debug or Release, I set that to$(BUILD_DIR)/Release-$(PLATFORM_NAME)/include.Under [Target] > Build Settings > Header Search Paths I added
$(REACT_HEADERS_PATH)as an entry.Repeat for all targets in your project.
When my project builds, React builds first, and since it doesn't know about configurations other than Release and Debug, it builds with the Release configuration. This places its headers under
[build dir]/Products/Release-iphoneos/include. Since this path is now in the Header Search Paths of the main project, it gets picked up and everything else builds fine.Hope this helps.
Updated 4/13 to mention repeating these steps for all targets (thanks @Twinski) and to change to the much shorter and more reliable
$(BUILD_DIR)(thanks @hoolymama).hoolymama commentedon Jan 18, 2017
@tisho your solution worked for me. Cheers!
I had to use
$(BUILD_DIR)/Release-$(PLATFORM_NAME)/includenot
BUILD_PRODUCTS_DIRtisho commentedon Jan 18, 2017
Good catch. It was actually supposed to say BUILT_PRODUCTS_DIR, not BUILD_PRODUCTS_DIR. I edited the original post to correct that.
hoolymama commentedon Jan 18, 2017
I can't quite make it work with$(BUILT_PRODUCTS_DIR)/Release-$ (PLATFORM_NAME)/include
For me it resolves to build/Staging-iphoneos/Release-iphoneos/include
Its probably something with my configuration - I'll experiment a bit later, but for now BUILD_DIR is working okay. Cheers!
thekevinbrown commentedon Jan 25, 2017
I built a package that should help with automatically setting all of the build configurations up in your libraries on each subsequent install:
https://www.npmjs.com/package/react-native-schemes-manager
Please give it a try and let me know how it works for you. We've got ~20 native libs now in most of our RN projects, so manually managing this would have been a nightmare.
haleykoike commentedon Jan 26, 2017
@tisho solution worked for me too. I also had to follow the same steps to my app's Test target in addition to the main app target
readme: improved “Multi-Deployment Testing” chapter for iOS (#690)
freakinruben commentedon Feb 10, 2017
@tisho you deserve a medal for this!
Move all header imports to "<React/..>"
philipshurpik commentedon Feb 21, 2017
Guys, the easiest fix that I found - is to set "CONFIGURATION_BUILD_DIR" in buildSettings of your configuration like:
CONFIGURATION_BUILD_DIR = "$(BUILD_DIR)/Release$(EFFECTIVE_PLATFORM_NAME)";Or if you want to set in XCode:
Your Project -> Build Settings -> Build Locations -> Per-configuration Build Products Path
for your new configuration:
$(BUILD_DIR)/Release$(EFFECTIVE_PLATFORM_NAME)31 remaining items
varungupta85 commentedon Sep 22, 2017
@D1no Thanks for your reply. I looked at the react-native-schemes-manager when I was going to through the comments. I felt that it is doing a lot of magic in the background which always worries me because if things start to break in future, I am not sure where to look at. I tried the suggestions from @philipshurpik and @j2kun using which I was able to build the app using staging configuration. I feel that I should be able to get the frameworks to be also present in the IPA with some change in settings in Xcode.
I will use the react-native-schemes-manager if I don't find a solution to this problem soon.
D1no commentedon Sep 22, 2017
Actually there is not much magic. Just automation of a very annoying Xcode manual task. Read more at the bottom of the package, it’s sources and what it does. If all react native packages would be cocoa pods, the problem would not exist. But as they all require the rn packanger which has just two build configurations, those need to be copied for all of them. Thinkmill and we use it in production, and probably many more, and it works fine with version react-native@latest with Xcode 9.
So, requiring xproject files from node_modules was never something Xcode was designed for. I mean, sometimes it feels likeXcode projects were not even designed for a code revision system, due to its cryptic uid file steucture.
Until all that changes, or the guys at the metro bundler tackle this problem in a very smart way, the work stays the same. And it is very hard to configure yourself out of that.
varungupta85 commentedon Sep 23, 2017
@D1no Thanks for the detailed reply. I feel more confident about using the scheme manager now and since I haven't been able to work around the problem I reported, I will start using it.
I just wanted to point out one small thing that after I updated the
CONFIGURATION_BUILD_DIRANDPOD_CONFIGURATION_BUILD_DIR, I was able to build the app. The missing frameworks in the IPA are all pods that I have installed in my app mainlySentry,KSCrash,RSKImageCropperand QBImagePicker`. I am not sure if it sheds any more light on the problem I am having since you said that the said issue doesn't occur with packages installed using cocoa pods and that the scheme manager is mainly to fix the projects installed using npm.Thanks again for taking the time to post your comments.
stale commentedon Nov 22, 2017
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.
hushicai commentedon Dec 12, 2017
worked.
salujaharkirat commentedon Dec 25, 2017
@varungupta85 even i am facing the issue of frameworks not being listed in staging scheme. Did you find a solution for this?
salujaharkirat commentedon Dec 25, 2017
@shohey1226 i tried the same thing but its not working for me. Looks like the pod libraries are getting copied into Staging folder instead of release which leads to #11813 (comment)
I tried adding
"$PODS_CONFIGURATION_BUILD_DIR"as recursive to FRAMEWORK_PATH but still it creates 2 folders.hussamkurd commentedon Feb 20, 2018
I just download CORS extension for chrome and it works for me
https://chrome.google.com/webstore/detail/allow-control-allow-origi/nlfbmbojpeacfghkpbjhddihlkkiljbi/related
wkoutre commentedon Mar 8, 2018
For anyone who comes across this, I managed to piece together a working XCode setup to get:
BuildandArchivein myreact-native initapps (using Cocoapods); if you're usingfastlane, this supports its deployment, as wellStaging,Angel, etc.)Made a post on an issue in Microsoft's code-push repo detailing my setup.
aligfl commentedon May 11, 2018
Shout out to @D1no! your solution worked for me! Been banging my head against the wall for the past few days. The solution worked for my CI system as well (buddybuild).
DavidNorena commentedon May 12, 2018
@D1no you should post that in a medium article !! nice !
D1no commentedon May 13, 2018
When I jotted that down, I hoped a blog article would be obsolete by the time it goes online. Aka improvements of the metro bundler. Oh well - for better SEO I’ll add it to my todo list. Hopefully saving some devs the long path of desperate hacks until they find that comment. 🙃