-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prebuilding react-native pods #10
Comments
Could you provide an example project that I could play with? |
@tcamin sure! I think you could use this one to test: Make sure you have a recent version of node installed. Then run If you Now if you try to use |
By the way, there is currently no information on being able to pre-build pods for react native projects anywhere that I could find online. I've been looking at If we'd manage to get this working, I think the project could see incredible notoriety :) React Native xcode projects are generally mainly pods. The app logic is separate, in JavaScript/TypeScript, and doesn't contribute much to build time. Compiling all the pods takes anywhere from 5-10 minutes and this is especially costly and inefficient on CI systems, considering that the pods almost never change (unless you upgrade react-native or some dependency). I assume you do not use react native yourself, so if you need any further information, let me know. |
🚀 I noticed some commits referencing React Native in the v2 branch: If I can help in testing it, let me know. If this works it would really be a killer feature for React Native builds. For example, one of the projects I have CI set-up for has 3 steps:
Having the pods prebuilt should slash the times for step 1 and 3 to probably 5 minutes total. For a total run-time of less than half. Also good for the environment, less wasted CPU cycles. 😆 |
One thing to be aware of is that the Search for Podfile: They mainly just moved here: |
Is there any updated example project you can point me to? To be fair the build chain of the RN project is pretty convoluted so I'm unsure if this is actually feasible with a reasonable number of changes. |
I have set up a barebones RN project which also has a dependency on some third party native pods (via the same https://github.com/andreialecu/rn63-newproj After cloning, run PS: One workaround to make the relative paths work and keep the same directory structure would be to add a symlink from |
One note about the RN project above: https://github.com/andreialecu/rn63-newproj/blob/master/ios/Podfile#L16-L24 Flipper may not work with |
I am also very interested in prebuilt pods for rn, not only because it's slow but more importantly, it's extremely difficult to download pod sources in China. Hope this could be a savior 🙏 |
I've been giving this a look in my spare time but unfortunately supporting rn goes beyond fixing relative paths and requires a series of non trivial changes mainly because by default AFAIU the Podfile does not include the |
@tcamin it's fine to suggest using |
The default https://github.com/andreialecu/rn63-newproj/blob/master/ios/Podfile#L16-L24 |
You might give the latest beta a try then, let me know how it goes. |
tried beta.25 and got an error like this: Found multiple xcworkspaces:
........../node_modules/@react-native-community/geolocation/ios/RNCGeolocation.xcworkspace
........../ios/superlab.xcworkspace
/Library/Ruby/Gems/2.6.0/gems/pod-builder-2.0.0.beta.25/lib/pod_builder/core.rb:152:in `find_xcodeworkspace'
/Library/Ruby/Gems/2.6.0/gems/pod-builder-2.0.0.beta.25/lib/pod_builder/core.rb:159:in `prepare_basepath'
/Library/Ruby/Gems/2.6.0/gems/pod-builder-2.0.0.beta.25/lib/pod_builder/command/build_all.rb:8:in `call'
/Library/Ruby/Gems/2.6.0/gems/pod-builder-2.0.0.beta.25/exe/pod_builder:381:in `block in parse_commandline'
/Library/Ruby/Gems/2.6.0/gems/pod-builder-2.0.0.beta.25/exe/pod_builder:380:in `each'
/Library/Ruby/Gems/2.6.0/gems/pod-builder-2.0.0.beta.25/exe/pod_builder:380:in `parse_commandline'
/Library/Ruby/Gems/2.6.0/gems/pod-builder-2.0.0.beta.25/exe/pod_builder:396:in `<top (required)>'
/usr/local/bin/pod_builder:23:in `load'
/usr/local/bin/pod_builder:23:in `<main>'
Command failed! |
Beta 34 brings initial support to prebuilding vanilla react-native projects as the one you provided (including Flipper support).
Finally you'll need to add Since I'm not a RN expert it would be nice if you could provide some feedback it this indeed works as expected |
Going to try this soon! Can you clarify how to install beta 34? I'm not very familiar with Ruby. |
|
Note that prebuilding (at least on my mac) takes quite some time. The good is that once this is done, app starts really quickly :-) |
I have just tried it on a real-world project and I'm getting:
I did add Seems that |
yes, I forgot that allow-warnings needs to be passed to properly build. Will make it default for RN projects. If compilation fails it would help to have a sample project with your setup. |
@sunnylqm I had the same error related to The build itself failed I think though. There was a After a while it printed Would've been helpful to see what the actual error was. 🤔 I will fiddle with it some more, and will create a repro soon. |
@tcamin I added some extra dependencies to the starter project, which should show the build failing. I still haven't confirmed what the error is. Switch to the Remember to run |
You opened the temporary project that PodBuilder uses to prebuild libs (see the path that is /private/tmp/pod_builder). Those are not changes to your project and can be safely ignored. |
@andreialecu beta 35 fixes the issue you reported ( |
The project that opens when you answer 'Y' to the error message allows you to build the prebuilding project which will show the error in Xcode. Compilation error messages can be very complex and seeing them directly in Xcode is the most effective solution |
Give beta 37 a try 🤞 |
🚀 seems like it compiled everything successfully on the |
Seems to have compiled everything successfully on the main project as well! The app also seems to run on the simulator, with some issues:
And various other pods, and other architectures.
Thanks! |
This might be an issue with the RNVectorIcons pod which I remember to have workarounded since it was failing copying some of its resources (it may be a problem with the podspec). If you pinpoint the problem it would make fixing the issue faster. By default libraries are prebuilt with bitcode disabled (since it is more convenient in most cases). In the sample project you provided you have bitcode enabled in release mode. Just switch it off and errors should go away. If you really need bitcode support you have to enable it also in development and rebuild everything enabling bitcode in PodBuilder. See https://github.com/Subito-it/PodBuilder/tree/deterministic_build#build_settings The fact is that libraries are built for several architectures. For example your example project deploys back to iOS 10 which means you still support 32 bit devices. This means that PodBuilder has to build 4 architectures (i386, x86_64 simulators, armv7 and arm64 for devices). Bumping to iOS11 should cut the prebuilt times by half since 32 bit devices are no loner supported. The advantage to prebuild all architectures is that you have everything ready both for simulators and devices. When you normally compile the app you build just one architecture at the time. Even when you archive you build just 2 architectures instead of 4. |
I have a question about this. Adding it prevents debugging the app, which would break development workflow. Does it get baked into prebuilt pods? Or what is the purpose of manually adding it? From my understanding, the RN CLI tools automatically add it if building for release. |
Did you tried removing the |
I pushed a branch here: https://github.com/andreialecu/rn63-newproj/tree/bad-pods It includes You can try running it normally prior to enabling pod builder. You can do that by running Here's what it should show: Here's what I noticed:
|
Libraries are prebuilt in release build configuration in order to be usable to submit the app to the store. Binaries are different in release and debug and that's why I suggested to switch the configuration to be always release and from what you reported it is indeed needed. I really did not have the time to dig into RN project workflow but what about setting DEV to be always true in react-native-xcode.sh as shown below? Does that reenable the ability to debug the app? |
The reason for the crash on startup seems to be that it cannot find the bundle location URL. The way RN debugging works, is it sets up a webserver at When built with PodBuilder, the bundle location seems to not be properly bundled into the app. I guess this might be a similar issue to I assume that if this url was properly included, everything would work without having to export |
Here's how the Here's how it looks when using prebuilt pods: The error that results in the crash on startup is:
|
Also relevant:
It's possible the React Native auto linker runs those or does some extra magic, because I also noticed these being logged when using prebuilt pods:
|
Please give beta 38 a try. You have to start from scratch running |
Seem to be getting this error on the latest beta on the real project. Not sure why it's expecting that to be a directory, since it's a file.
|
Could you double check that the sample project you provided works as expected (including debugging which wasn't working before)? |
I found out what could be causing it. The
See here for an explanation: https://github.com/zoontek/react-native-permissions#ios I can rewrite it to something PodBuilder might like, if you can guide me. (you should be able to add the snippet above to the sample project and see the same failure as well) |
I would also have one additional suggestion, could the temporary directory being created be random instead of I'm not sure how common it would be, but perhaps people might start two builds simultaneously, and they'd overlap their files. I was planning on starting two then going away for a few hours and checking the results later, for instance. I know I could run them sequentially, but then I might miss any logs from the first one, so it's easier to just start two terminals, and seems like an easy fix. |
This is unfortunately not possible because PodBuilder relies on a
consistent build path to allow some advanced features like debugging
prebuilt frameworks (see read me)
…On Thu, 22 Oct 2020 at 18:16 Andrei Alecu ***@***.***> wrote:
I would also have one additional suggestion, could the temporary directory
being created be random instead of /private/tmp/pod_builder? Something
like /private/tmp/pod_builder_qwerty123.
I'm not sure how common it would be, but perhaps people might start two
builds simultaneously, and they'd overlap their files. I was planning on
starting two then going away for a few hours and checking the results
later, for instance.
I know I could run them sequentially, but then I might miss any logs from
the first one, so it's easier to just start two terminals, and seems like
an easy fix.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGVUEPMVDHK3XND6NI5PW3SMBLGFANCNFSM4QDZFFHQ>
.
|
According to CocoaPod's documentation the installation instructions you referenced are wrong since Local podspecs should be specified using the |
Thanks for the hint, I replaced Seems that debugging and fonts work correctly now. 🎉 One remaining issue seems to be that the config variables from I guess one quick workaround might be to exclude Update, it reproduces in the sample app too: (note the last line) |
🚀 As a quick benchmark, it seems that a clean (no-cache) Archive compilation on a real world app using prebuilt pods takes 331 seconds. The same compilation, without PodBuilder, takes 947 seconds. Out of the 331 seconds, at least 2 minutes are taken by the JS compilation step, so this is a fantastic improvement and will help CI greatly. |
Could you clarify what this is? I quickly looked but didn't find any |
The https://github.com/luggit/react-native-config/blob/master/react-native-config.podspec The files are here: I don't see it in Running the |
Did you try adding the pod to the list of skip_pods in PodBuilder.json? The pod has a rather convoluted podspec with a script_phase (which are not supported by PodBuilder) and just a few files to compile. The benefits of prebuilding should be minimal. |
I released beta 39 which skips pods with script_phases which won't be supported. |
🚀 Success! With beta 39 everything just works by default based on my brief testing. I will need to update some workflows to use PodBuilder, so it might take a bit until everything is fully switched over on my end to do full testing. But it seems that there are no issues so far, in a relatively complex app. Thank you so much for working on this! (ah, just one minor thing, I still have to change |
Nice to hear this! It took slightly more than expected as I worked on it on my limited spare time. While I don't use RN myself adding support for it allowed me to hit and fix a bunch of problems in the generic implementation so thanks for all the feedback.
I prefer to keep this as is at the moment. I'll close the issue, feel free to open new ones if you have any further problem. |
I've been trying to see if this works with
react-native
, and one of the first issues I ran into is related to thePodfile
being moved to theFrameworks
directory.The standard Podfile in
react-native
looks like:All paths are wrong, and because of the intermediary directory, they would need to be resolved to
'../../node_modules
instead.This seems an easy enough change to do manually, but unfortunately it is not enough. Other pods within
node_modules
are used by react native's auto-linking system and the paths there are hardcoded and cannot be changed.I wonder if there is any solution for this?
The text was updated successfully, but these errors were encountered: