Prebuilding react-native pods

[andreialecu]

I've been trying to see if this works with react-native, and one of the first issues I ran into is related to the Podfilebeing moved to the Frameworks directory.

The standard Podfile in react-native looks like:

platform :ios, '10.0'

inhibit_all_warnings!

require_relative '../node_modules/react-native/scripts/react_native_pods'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'

target 'myproject' do

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?

[tcamin]

Could you provide an example project that I could play with?

[andreialecu]

@tcamin sure! I think you could use this one to test:
https://github.com/DylanVann/react-native-fast-image
https://github.com/DylanVann/react-native-fast-image/tree/master/ReactNativeFastImageExample

Make sure you have a recent version of node installed. Then run yarn install in the ...Example directory. The XCode project files are in the ios directory. The podfile is at https://github.com/DylanVann/react-native-fast-image/blob/master/ReactNativeFastImageExample/ios/Podfile

If you cd ios && pod install then run the project in xcode it should work.

Now if you try to use PodBuilder on it, you will run into the issue with paths I originally described.

[andreialecu]

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 cocoapods-binary as well but ran into issues with it as well. What drew me to this project was the json config in which you could exclude certain pods.

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.

[andreialecu]

🚀 I noticed some commits referencing React Native in the v2 branch:
67516d1

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:

1. build for E2E testing - takes 10-12 minutes - mostly Pod compilation
2. run E2E testing - around 8 minutes
3. build for release - takes 10-12 minutes - again, Pod compilation

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. 😆

[andreialecu]

One thing to be aware of is that the Podfile recommendation has changed in the latest RN version, and the example project I linked above isn't updated.

Search for Podfile:
https://react-native-community.github.io/upgrade-helper/?from=0.62.2&to=0.63.2

They mainly just moved here:
https://github.com/facebook/react-native/blob/master/scripts/react_native_pods.rb

[tcamin]

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.

[andreialecu]

I have set up a barebones RN project which also has a dependency on some third party native pods (via the same react-native-fast-image as above):

https://github.com/andreialecu/rn63-newproj

After cloning, run yarn install then cd ios && pod install && cd .., and yarn ios to run it on an emulator (or use xcode to open the ios directory and run from there.

PS: One workaround to make the relative paths work and keep the same directory structure would be to add a symlink from proj/ios/node_modules -> proj/node_modules - but there are still some errors in the ruby script with this approach.

[andreialecu]

One note about the RN project above:

https://github.com/andreialecu/rn63-newproj/blob/master/ios/Podfile#L16-L24

Flipper may not work with use_frameworks! or generate other problems by itself while compiling. So it is safe to comment it out from the Podfile if it creates too many problems, or cannot be made to work. Not being able to use Flipper would be an acceptable trade-off, RN has other powerful debugging options available.

[sunnylqm]

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 🙏

[tcamin]

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 use_framework! entry which makes things tricky when dealing with Swift pods.

[andreialecu]

@tcamin it's fine to suggest using use_frameworks! if there are no other side effects. The Podfile itself is user modifiable.

[andreialecu]

The default Podfile even mentions that you should disable Flipper if you need to use frameworks. See:

https://github.com/andreialecu/rn63-newproj/blob/master/ios/Podfile#L16-L24

[tcamin]

You might give the latest beta a try then, let me know how it goes.

[sunnylqm]

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!

[tcamin]

Beta 34 brings initial support to prebuilding vanilla react-native projects as the one you provided (including Flipper support).

git clone https://github.com/andreialecu/rn63-newproj.git
cd rn63-newproj
yarn install
pod_builder init
pod_builder build_all

Finally you'll need to add export CONFIGURATION=Release in the Bundle React Native code and images build phase as shown below

Since I'm not a RN expert it would be nice if you could provide some feedback it this indeed works as expected

[andreialecu]

Going to try this soon! Can you clarify how to install beta 34? I'm not very familiar with Ruby.

[tcamin]

gem install pod-builder --pre

[tcamin]

Note that prebuilding (at least on my mac) takes quite some time. The good is that once this is done, app starts really quickly :-)

[andreialecu]

I have just tried it on a real-world project and I'm getting:

The following pods are in development mode: `BVLinearGradient, BugsnagReactNative, BugsnagReactNative/Core, FBLazyVector, FBReactNativeSpec, Permission-LocationWhenInUse, RCTRequired, RCTTypeSafety, RNAWSCognito, RNBootSplash, RNCAsyncStorage, RNCClipboard, RNCMaskedView, RNDateTimePicker, RNFastImage, RNGestureHandler, RNImageCropPicker, RNImageCropPicker/QBImagePickerController, RNLocalize, RNPermissions, RNReanimated, RNSVG, RNScreens, RNVectorIcons, React, React-Core, React-Core/Default, React-Core/DevSupport, React-Core/RCTWebSocket, React-CoreModules, React-RCTActionSheet, React-RCTAnimation, React-RCTBlob, React-RCTImage, React-RCTLinking, React-RCTNetwork, React-RCTSettings, React-RCTText, React-RCTVibration, React-callinvoker, React-cxxreact, React-jsi, React-jsi/Default, React-jsiexecutor, React-jsinspector, ReactCommon/turbomodule/core, ReactNativeAutogrowTextinput, Yoga, react-native-config, react-native-contacts, react-native-date-picker, react-native-geolocation-service, react-native-get-random-values, react-native-maps, react-native-netinfo, react-native-notifications, react-native-safe-area-context, react-native-selectable-text, toolbar-android`, won't proceed building.

You can ignore this error by passing the `--allow-warnings` flag to the build command

I did add export CONFIGURATION=Release.

Seems that pod_builder build_all --allow-warnings got past it, but not sure if that's expected.

[tcamin]

but not sure if that's expected

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]

When init I got prompt to input admin password again and again, is that expected?

[sunnylqm]

Got another error with a fresh rn63 project

[sunnylqm]

My system info:

[andreialecu]

@sunnylqm I had the same error related to use_frameworks!. Initially I tried adding it to the ios/Podfile but it didn't help. Then I noticed there's a copy of it in ios/PodBuilder/Podfile and added it there also (manually), and got past the error.

The build itself failed I think though.

There was a Building log line that appeared and stayed for a long time, without any progress logged. Is this normal?

After a while it printed Oh no! Something went wrong during prebuild phase! Do you want to open the prebuild project....

Would've been helpful to see what the actual error was. 🤔

I will fiddle with it some more, and will create a repro soon.

[andreialecu]

@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 more-deps branch on https://github.com/andreialecu/rn63-newproj/tree/more-deps

Remember to run yarn install after switching, so that the deps are installed.

[andreialecu]

Alright, I notice there's a log file created, it seems to contain this as the source of the error:

/Users/andreialecu/Work/rn63-newproj/node_modules/react-native/ReactCommon/yoga/yoga/YGEnums.h:10:10: error: double-quoted include "YGMacros.h" in framework header, expected angle-bracketed instead [-Werror,-Wquoted-include-in-framework-header]
#include "YGMacros.h"
         ^~~~~~~~~~~~
         <YGMacros.h>
1 error generated.

One thing that is weird, is that VSCode, which is the editor of choice for the ecosystem, shows a huge number of git changes after running pod_builder build_all:

Not sure why they're being picked up, seems weird.

[tcamin]

shows a huge number of git changes

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.

[tcamin]

@andreialecu beta 35 fixes the issue you reported (sudo gem install pod-builder --pre to update). You need to remove the use_frameworks! you added in the ios/PodBuilder/Podfile as only static library packaging will be supported for RN projects.

[tcamin]

Would've been helpful to see what the actual error was. 🤔

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

[tcamin]

Give beta 37 a try 🤞

[andreialecu]

🚀 seems like it compiled everything successfully on the master of the sample project. I'll try it out on the real project tomorrow and report back. If this works it will be big! 🤩

[andreialecu]

Seems to have compiled everything successfully on the main project as well! The app also seems to run on the simulator, with some issues:

1. https://github.com/oblador/react-native-vector-icons the vector icons that are part of this package don't seem to render, instead they appear as the unicode missing char symbol [?]. I'll try to figure it out first, and if I can't find anything I'll update the sample project to show a repro.

2. While building for the app store using Fastlane (xcode archive), it seems that the linker complains about:

ld: '/Volumes/Work/Projects/projectsport/ios/PodBuilder/Prebuilt/BVLinearGradient/BVLinearGradient/libBVLinearGradient.a(BVLinearGradientManager.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. file '/Volumes/Work/Projects/projectsport/ios/PodBuilder/Prebuilt/BVLinearGradient/BVLinearGradient/libBVLinearGradient.a' for architecture armv7

And various other pods, and other architectures.

3. Not that I'm complaining, since this seems to reduce like 95% of build time after the initial compilation. But I'm curious why it takes much longer to precompile the pods than it does to fully compile the app, with the pods in it?

Thanks!

[tcamin]

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.

[andreialecu]

Finally you'll need to add export CONFIGURATION=Release in the Bundle React Native code and images build phase as shown below

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.

[tcamin]

Did you tried removing the export CONFIGURATION workaround? If everything builds correctly then you're fine.

[andreialecu]

I pushed a branch here: https://github.com/andreialecu/rn63-newproj/tree/bad-pods

It includes react-native-vector-icons and react-native-config (which reads from .env in the root).

You can try running it normally prior to enabling pod builder. You can do that by running yarn install && cd ios && pod install && cd .. && yarn ios.

Here's what it should show:

Here's what I noticed:

1. If I do not include export CONFIGURATION=Release the app crashes on startup.
2. Running yarn ios --configuration Release fails with:

❌  ld: in /Users/andreialecu/Work/rn63-newproj/ios/PodBuilder/Prebuilt/DoubleConversion/DoubleConversion/libDoubleConversion.a(DoubleConversion-dummy.o), building for iOS Simulator, but linking in object file built for iOS, file '/Users/andreialecu/Work/rn63-newproj/ios/PodBuilder/Prebuilt/DoubleConversion/DoubleConversion/libDoubleConversion.a' for architecture arm64

❌  clang: error: linker command failed with exit code 1 (use -v to see invocation)

3. Adding back export CONFIGURATION=Release makes the app run, but neither react-native-config and react-native-vector-icons work properly. One isn't able to read config values (from .env), and the other doesn't show icons.
   

[tcamin]

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?

[andreialecu]

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 localhost:8080 by default and the native side keeps a websocket connection and downloads the JS from it. This way live reload works properly.

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 react-native-config, above.

I assume that if this url was properly included, everything would work without having to export CONFIGURATION.

[andreialecu]

Here's how the .app's files looks like with normal cocoapods:

Here's how it looks when using prebuilt pods:

The error that results in the crash on startup is:

Thread 1: "No bundle URL present.\n\nMake sure you're running a packager server or have included a .jsbundle file in your application bundle."

See: https://github.com/andreialecu/rn63-newproj/blob/666204b5a9502ebd22c16442aa64a33927935e90/ios/ReactNativeStarter/AppDelegate.m#L51-L55

[andreialecu]

Also relevant:

• This seems to be what bundles the .env vars into the binary:
  https://github.com/luggit/react-native-config/blob/master/react-native-config.podspec
• The fonts would seem to be bundled by this:
  https://github.com/oblador/react-native-vector-icons/blob/master/RNVectorIcons.podspec#L14-L16

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:

$ react-native run-ios
error React Native CLI uses autolinking for native dependencies, but the following modules are linked manually: 
  - react-native-config (to unlink run: "react-native unlink react-native-config")
  - react-native-fast-image (to unlink run: "react-native unlink react-native-fast-image")
  - react-native-vector-icons (to unlink run: "react-native unlink react-native-vector-icons")
This is likely happening when upgrading React Native from below 0.60 to 0.60 or above. Going forward, you can unlink this dependency via "react-native unlink <dependency>" and it will be included in your app automatically. If a library isn't compatible with autolinking, disregard this message and notify the library maintainers.
Read more about autolinking: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md

[tcamin]

Please give beta 38 a try. You have to start from scratch running pod-builder init since some additional changes have been added to that stage. React-Core and React-CoreModules won't be prebuilt since they contain compilation conditional which prevented debugging from running properly. But the end result is still very satisfying in terms of compilation improvement 41s vs 176s and the more dependencies you add the more this gap increases.

[andreialecu]

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.

Not a directory @ rb_file_s_stat - /Volumes/Work/Projects/projectsport/ios/PodBuilder/../../node_modules/react-native-permissions/ios/LocationWhenInUse.podspec/.
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:1305:in `stat'
        /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:1305:in `lstat'
        /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:1350:in `copy'
        /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:478:in `block in copy_entry'
        /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:1484:in `wrap_traverse'
        /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:475:in `copy_entry'
        /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:453:in `block in cp_r'
        /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:1557:in `block in fu_each_src_dest'
        /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:1571:in `fu_each_src_dest0'
        /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:1555:in `fu_each_src_dest'
        /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:452:in `cp_r'
        /Library/Ruby/Gems/2.6.0/gems/pod-builder-2.0.0.beta.38/lib/pod_builder/install.rb:272:in `block in copy_development_pods_source_code'
        /Library/Ruby/Gems/2.6.0/gems/pod-builder-2.0.0.beta.38/lib/pod_builder/install.rb:265:in `each'
        /Library/Ruby/Gems/2.6.0/gems/pod-builder-2.0.0.beta.38/lib/pod_builder/install.rb:265:in `copy_development_pods_source_code'

[tcamin]

Could you double check that the sample project you provided works as expected (including debugging which wasn't working before)?

[andreialecu]

I found out what could be causing it. The Podfile of the real project has this custom snippet in it:

  permissions_path = '../node_modules/react-native-permissions/ios'
  pod 'Permission-LocationWhenInUse', :path => "#{permissions_path}/LocationWhenInUse.podspec"

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)

[andreialecu]

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.

[tcamin]

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> .

[tcamin]

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)

According to CocoaPod's documentation the installation instructions you referenced are wrong since :path => should be a folder that contains the podspec, not the podspec itself. (Using this option CocoaPods will assume the given folder to be the root of the Pod and will link the files directly from there in the Pods project. This means that your edits will persist to CocoaPods installations.)

Local podspecs should be specified using the :podspec => option instead. Anyways since CP is resilient to this situation I'll see if it can be handled by PodBuilder as well.

[andreialecu]

Thanks for the hint, I replaced path with podspec and it built everything successfully!

Seems that debugging and fonts work correctly now. 🎉

One remaining issue seems to be that the config variables from .env (via react-native-config) are not embedded properly and come up as undefined at runtime. I haven't tested if they work in the sample yet, just in the actual app.

I guess one quick workaround might be to exclude react-native-config from precompilation as well. Was this supposed to work too?

Update, it reproduces in the sample app too:

(note the last line)

[andreialecu]

🚀 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.

[tcamin]

One remaining issue seems to be that the config variables from .env (via react-native-config) are not embedded properly and come up as undefined at runtime. I haven't tested if they work in the sample yet, just in the actual app.

Could you clarify what this is? I quickly looked but didn't find any react-native-config pod.

[andreialecu]

The bad-pods branch on the sample project has it, this is the podspec:

https://github.com/luggit/react-native-config/blob/master/react-native-config.podspec

The files are here:
https://github.com/luggit/react-native-config/tree/master/ios

I don't see it in Pods though, so I'm not sure how it works.

Running the bad-pods app should show the same as the screenshot above when on PodBuilder. Without PodBuilder, the behavior is correct.

[andreialecu]

This is also part of the output when using vanilla CocoaPods.

[tcamin]

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.

[tcamin]

I released beta 39 which skips pods with script_phases which won't be supported.

[andreialecu]

🚀 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 path to podspec. You mentioned being able to handle this automatically)

[tcamin]

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.

(ah, just one minor thing, I still have to change path to podspec. You mentioned being able to handle this automatically)

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.