Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[iOS] CocoaPods frameworks compatibility: Step 2 #25619

Closed
wants to merge 7 commits into from

Conversation

@jtreanor
Copy link
Contributor

commented Jul 12, 2019

Summary

This is my proposal for fixing use_frameworks! compatibility without breaking all <React/*> imports I outlined in #25393 (comment). If accepted, it will fix #25349.

It builds on the changes I made in #25496 by ensuring each podspec has a unique value for header_dir so that framework imports do not conflict. Every podspec which should be included in the <React/*> namespace now includes it's headers from React-Core.podspec.

The following pods can still be imported with <React/*> and so should not have breaking changes: React-ART,React-DevSupport, React-CoreModules, React-RCTActionSheet, React-RCTAnimation, React-RCTBlob, React-RCTImage, React-RCTLinking, React-RCTNetwork, React-RCTPushNotification, React-RCTSettings, React-RCTText, React-RCTSettings, React-RCTVibration, React-RCTWebSocket .

There are still a few breaking changes which I hope will be acceptable:

  • React-Core.podspec has been moved to the root of the project. Any Podfile that references it will need to update the path.
  • React-turbomodule-core's headers now live under <turbomodule/*> Replaced by #25619 (comment).
  • React-turbomodulesamples's headers now live under <turbomodulesamples/*> Replaced by #25619 (comment).
  • React-TypeSaferty's headers now live under <TypeSafety/*> Replaced by #25619 (comment).
  • React-jscallinvoker's headers now live under <jscallinvoker/*> Replaced by #25619 (comment).
  • Each podspec now uses s.static_framework = true. This means that a minimum of CocoaPods 1.5 (released in April 2018) is now required. This is needed so that the __has_include conditions can still work when frameworks are enabled.

Still to do:

  • Including React-turbomodule-core with use_frameworks! enabled causes the C++ import failures we saw in #25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed). Addressed by 3357351.
  • I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the <React/*> namespace since it is new? 馃

Changelog

[iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks.

Test Plan

Sample Project

Everything should work exactly as before, where use_frameworks! is not in Podfiles. I have a branch on my sample project here which has use_frameworks! in its Podfile to demonstrate this is fixed.

You can see that it works with these steps:

  1. git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git
  2. git checkout fix-frameworks-subspecs
  3. cd ios && pod install
  4. cd .. && react-native run-ios

The sample app will build and run successfully. To see that it still works without frameworks, remove use_frameworks! from the Podfile and do steps 3 and 4 again.

RNTesterPods

RNTesterPodsPods can now work with or without use_frameworks!.

  1. Go to the RNTester directory and run pod install.
  2. Run the tests in RNTesterPods.xcworkspace to see that everything still works fine.
  3. Uncomment the use_frameworks! line at the top of RNTester/Podfile and run pod install again.
  4. Run the tests again and see that it still works with frameworks enabled.
@fkgozali

This comment has been minimized.

Copy link
Contributor

commented Jul 12, 2019

There are still a few breaking changes which I hope will be acceptable

The ones you listed are fine to be changed. I had internal diff renaming typesafety stuff to RCTTypeSafety too, so we're on the same page. For TM, I was thinking to create a higher level TM spec with core/sample subspec, etc (like fabric) but we can deal with it later. I think a few of them under ReactCommon can be combined into a common podspec, with subspec for each.

For fabric, most of fabric is already not using <React/, you meant just the ObjC part (RCTFabric)? If so, I think it's ok to move it out. I suggest RCTFabric namespace for the time being.

@fkgozali

This comment has been minimized.

Copy link
Contributor

commented Jul 12, 2019

React-turbomodule-core's headers now live under <turbomodule/>
React-turbomodulesamples's headers now live under <turbomodulesamples/
>
React-TypeSaferty's headers now live under <TypeSafety/>
React-jscallinvoker's headers now live under <jscallinvoker/
>

You may want to make these separate PRs for easier merging

@fkgozali

This comment has been minimized.

Copy link
Contributor

commented Jul 12, 2019

@ericlewis - thoughts?

@fkgozali

This comment has been minimized.

Copy link
Contributor

commented Jul 12, 2019

@jtreanor - 0c8c95f handled the TypeSafety stuff

I'm experimenting with ReactCommon podspec as I mentioned, so hopefully that makes it easier for you as well

@fkgozali

This comment has been minimized.

Copy link
Contributor

commented Jul 13, 2019

Notes:

I tested header prefix like <react/turbomodule/*.h> - this worked fine if not using frameworks, but Xcode failed to find the header when use_frameworks! is set. I don't know what the workaround is at this point, so to unblock, I'll just flatten jscallinvoker and turbomodule into <ReactCommon/ for the time being. All of these are just subspecs under the new ReactCommon.podspec that I'll be adding.

facebook-github-bot added a commit that referenced this pull request Jul 13, 2019
Summary:
For better cocoapods compatibility, refactored TM podspec to be a subspec of ReactCommon, then use `<ReactCommon/` header prefix for all TM files.

Relevant efforts:
#25619
#25393

Reviewed By: hramos

Differential Revision: D16231697

fbshipit-source-id: 38d3418b19978ff54aa0c61b064ac45ac0e1c36c
facebook-github-bot added a commit that referenced this pull request Jul 13, 2019
Summary:
It was added due to missing TM support in .xcodeproj, but since .xcodeproj has been deprecated, we don't need this flag anymore.

Relevant efforts:
#25619
#25393

Reviewed By: hramos

Differential Revision: D16231698

fbshipit-source-id: b3276d1fc64394624e5110f2ecd31acc2bb2d240
facebook-github-bot added a commit that referenced this pull request Jul 13, 2019
Summary:
This essentially changes the header namespace to `<ReactCommon/`
Relevant efforts:
#25619
#25393

Reviewed By: PeteTheHeat

Differential Revision: D16233125

fbshipit-source-id: 83eda4cc50ebb01efd1ce3eb18f47c97a049cffa
@fkgozali

This comment has been minimized.

Copy link
Contributor

commented Jul 13, 2019

@jtreanor I landed a few commits to deal with jsireact stuffs:

use_framework! still hasn't fully worked since we need the rest of your fix, but TM seems to build correctly. I'm not sure what C++ error you got, so probably good to try it out again after rebasing.

Let me know if I can help further here.

@jtreanor

This comment has been minimized.

Copy link
Contributor Author

commented Jul 13, 2019

Thanks a lot @fkgozali!

These changes will be very helpful.

@jtreanor jtreanor force-pushed the jtreanor:try/subspec-approach branch from 87ea162 to eae2948 Jul 16, 2019
@jtreanor jtreanor force-pushed the jtreanor:try/subspec-approach branch from eae2948 to 42491b1 Jul 16, 2019
@jtreanor

This comment has been minimized.

Copy link
Contributor Author

commented Jul 16, 2019

Okay, I have rebased master and @fkgozali's changes have helped a lot. Thank you again!

I am still seeing the C++ error I mentioned above, so I'll give more detail here. When I add use_frameworks! to RNTester/Podfile, I get this build error:

Screenshot 2019-07-16 at 17 11 45

As you can see, this is the same error I encountered when investigating #25349 that led me to make C++ headers private by default. The problem seems to be that an Objective C file importing the React module, includes all public headers and fails to build the C++. I don't understand why the fix I made previously is not working.

As a hack and to confirm this is the only issue, I was able to get the build working by updating Pods/Target Support Files/React-Core.common/React-Core.common-umbrella.h as follows:

...
+#ifdef __cplusplus
#import "JSCExecutorFactory.h"
#import "NSDataBigString.h"
#import "RCTCxxBridgeDelegate.h"
#import "RCTMessageThread.h"
#import "RCTObjcExecutor.h"
#import "DispatchMessageQueueThread.h"
#import "RCTCxxMethod.h"
#import "RCTCxxModule.h"
#import "RCTCxxUtils.h"
#import "RCTNativeModule.h"
#import "RCTFollyConvert.h"
+#endif
...

This stops the C++ headers from being imported into the umbrella header and the build succeeds. Of course, modifying this file doesn't solve our problem, but confirms it.

The only way to customise the umbrella header is to define a custom modulemap and umbrella header. However, I feel like there should be a way to solve the problem without resorting to this.

I will keep investigating but I'm open to any ideas at all.

@fkgozali

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

I am still seeing the C++ error I mentioned above

Hmm, perhaps there's a missing compiler_flag in the individual podspec/subspec to hint that it's C++ code? React-RCTWebSocket.podspec doesn't seem to have any C++ flag configured, so maybe if you look at Xcode workspace, that framework is compiled for ObjC?

@jtreanor

This comment has been minimized.

Copy link
Contributor Author

commented Jul 16, 2019

Hmm, perhaps there's a missing compiler_flag in the individual podspec/subspec to hint that it's C++ code? React-RCTWebSocket.podspec doesn't seem to have any C++ flag configured, so maybe if you look at Xcode workspace, that framework is compiled for ObjC?

Unfortunately, I don't think that would suffice. If we fix the problem for React-RCTWebSocket and the other RN pods, any user code that imports a React header into an ObjC file would still get this error.

@fkgozali

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

any user code that imports a React header into an ObjC file would still get this error.

I think it's fine to require that callsites have .mm extension (ObjC++), not .m (ObjC), given that down the road everything will involve C++ (TurboModule/Fabric). If that's the only concern, I think it's ok to proceed (assuming we fix all podspecs to be C++ compatible)

@jtreanor

This comment has been minimized.

Copy link
Contributor Author

commented Jul 16, 2019

Oh, I see. I'll look a little more to see if there is a simple way to avoid that requirement but otherwise I'll proceed as you suggest.

I am mostly wondering why this wasn't an issue prior to the podspec split. I'd like to understand what's going on here before choosing the best solution.

@fkgozali

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

Another approach (not always applicable) is to move the .h imports to the .mm instead of inside another .h. That would isolate the change to just the relevant .mm files, so other libs aren't affected.

@pull-bot

This comment has been minimized.

Copy link

commented Jul 18, 2019

Warnings
鈿狅笍 馃敀 package.json - Changes were made to package.json. This will require a manual import by a Facebook employee.

Generated by 馃毇 dangerJS against e2a73e8

@jtreanor jtreanor requested review from janicduplessis and shergin as code owners Jul 18, 2019
@fkgozali

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2019

As a result of this, use_frameworks! now works with RNTesterPods. I have also made a few small updates to get the tests working and updated the PR description.

@jtreanor Thank you so much for working on this! I didn't have a chance to review/merge this yet due to unrelated work. cc @hramos @cpojer. I'll get back to this some time next week if others don't get to merge it by then.

The only thing not working at this point is Fabric. I'm not sure if we should address that in this PR or separately.

Yeah, this is fine. Fabric had missing configuration unrelated to this use_frameworks! issue, so it's ok to solve it separately. It's also not enabled by default yet, so it won't block any release atm.

@kdawgwilk

This comment has been minimized.

Copy link

commented Jul 23, 2019

I appreciate all the work going into fixing this issue but my concern is how do we make sure this doesn鈥檛 break going forward? It would be a shame if we fixed this now but broke it in another release. Will having this integrated into RNTesterPods make sure that all of these different CocoaPods scenarios don鈥檛 break? e.g. use_frameworks! enabled or disabled

@fkgozali

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2019

I appreciate all the work going into fixing this issue but my concern is how do we make sure this doesn鈥檛 break going forward?

There's now a CI test to cover standard pods build with RNTester, so that will help prevent future breakage. We'll likely need to add a second variant using use_framework! though - cc @hramos

@jtreanor

This comment has been minimized.

Copy link
Contributor Author

commented Jul 23, 2019

Yes, we can absolutely add a CI step to integrate and test RNTesterPods with use_frameworks!. Of course, this will increase CI run time but I'm happy to add it if that's acceptable.

@fkgozali

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2019

Yes, we can absolutely add a CI step to integrate and test RNTesterPods with use_frameworks!. Of course, this will increase CI run time but I'm happy to add it if that's acceptable.

We'll likely need a new RNTester project just for this variant. Let's visit this after we fully resolve this issue.

@jtreanor

This comment has been minimized.

Copy link
Contributor Author

commented Jul 24, 2019

We'll likely need a new RNTester project just for this variant.

I don't think that will be needed. For example, a change like this to RNTester/Podfile would allow running USE_FRAMEWORKS=1 pod install to install with frameworks:

-  # Uncomment for Swift
-  #  use_frameworks!
+ use_frameworks! if ENV['USE_FRAMEWORKS'] == 1

Let's visit this after we fully resolve this issue.

Okay, I'll hold off on any changes for this to allow whats here to be reviewed first.

@@ -32,8 +32,9 @@ Pod::Spec.new do |s|
s.platforms = { :ios => "9.0", :tvos => "9.2" }
s.source = source
s.header_dir = "ReactCommon" # Use global header_dir for all subspecs for use_framework compatibility
s.static_framework = true

This comment has been minimized.

Copy link
@fkgozali

fkgozali Jul 24, 2019

Contributor

could you help me understand why this line matters?

This comment has been minimized.

Copy link
@fkgozali

fkgozali Jul 25, 2019

Contributor

OK, found the explanation in your summary:

Each podspec now uses s.static_framework = true. This means that a minimum of CocoaPods 1.5 (released in April 2018) is now required. This is needed so that the __has_include conditions can still work when frameworks are enabled.

I think it's worth exploring not using static_framework, but we can do it outside of this PR. I'm not sure if it's 100% possible given the current directory structure.

This comment has been minimized.

Copy link
@jtreanor

jtreanor Jul 25, 2019

Author Contributor

Just to clear this up completely, here is a more thorough explanation.

In a number of places throughout the codebase, there is code like this:

#if RCT_DEV && __has_include(<React/RCTDevLoadingView.h>)
    // Note: RCTDevLoadingView should have been loaded at this point, so no need to allow lazy loading.
    RCTDevLoadingView *loadingView = [weakSelf moduleForName:RCTBridgeModuleNameForClass([RCTDevLoadingView class])
                                       lazilyLoadIfNecessary:NO];
    [loadingView updateProgress:progressData];
#endif

The trouble is that this code lives in React-Core.podspec but RCTDevLoadingView is part of React-DevSupport. It works fine when not using frameworks but when use_frameworks! is used and RCT_DEV is enabled there is an error compiling React-Core.podspec as RCTDevLoadingView is not found. This is because React-DevSupport is not linked with React-Core.

The solution is to add s.static_framework = true to each of the podspecs. Now all symbols are linked into the same executable so RCTDevLoadingView is present at build time. It is necessary to add s.static_framework = true to all podspecs as static frameworks are not allowed to have dynamic dependencies.

As mentioned above the main disadvantage of this is that it requires CocoaPods 1.5 or later to be used (released in April 2018). Another drawback is that I believe CocoaPods complains if a target has transitive static dependencies. This means any third party podspec that depends on React would also need to have s.static_framework = true.

I think it's worth exploring not using static_framework, but we can do it outside of this PR. I'm not sure if it's 100% possible given the current directory structure.

The only way I can think of that would be possible would be to make React-DevSupport a subspec of React-Core as it was before the podspec split.

This comment has been minimized.

Copy link
@fkgozali

fkgozali Jul 25, 2019

Contributor

This means any third party podspec that depends on React would also need to have s.static_framework = true.

Yeah, this is my worry: it could be too limiting for those libs.

The only way I can think of that would be possible would be to make React-DevSupport a subspec of React-Core as it was before the podspec split.

I was actually trying this on top of your PR, but got a dependency cycle error, so I didn鈥檛 proceed. Perhaps it鈥檚 worth another look?

This comment has been minimized.

Copy link
@jtreanor

jtreanor Jul 25, 2019

Author Contributor

I was actually trying this on top of your PR, but got a dependency cycle error, so I didn鈥檛 proceed. Perhaps it鈥檚 worth another look?

I can take a look.

This comment has been minimized.

Copy link
@jtreanor

jtreanor Jul 25, 2019

Author Contributor

Ah, I remember the problem with that now. DevSupport depends on React-RCTWebSocket which depends on React-Core.

If we make React-RCTWebSocket a subspec too, it will work. I'll open a PR.

This comment has been minimized.

Copy link
@jtreanor

jtreanor Jul 25, 2019

Author Contributor

Okay, I've done that here: #25816

Copy link

left a comment

@fkgozali has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

s.source_files = "**/*.{c,h,m,mm,cpp}"
s.header_dir = "React"
s.source_files = "**/*.{c,m,mm,cpp}"
s.header_dir = "CoreModules"

This comment has been minimized.

Copy link
@fkgozali

fkgozali Jul 24, 2019

Contributor

I think this one would be a breaking change (more files will be moved here for TurboModule migration), I'll see if I can move it up as a subspec inside React-Core.podspec

This comment has been minimized.

Copy link
@fkgozali

fkgozali Jul 24, 2019

Contributor

nvm, I think this is meaningless now that you removed the .h files from the list

This comment has been minimized.

Copy link
@jtreanor

jtreanor Jul 25, 2019

Author Contributor

Yes, thats right.

@react-native-bot

This comment has been minimized.

Copy link
Collaborator

commented Jul 25, 2019

This pull request was successfully merged by @jtreanor in 8131b7b.

When will my fix make it into a release? | Upcoming Releases

@jtreanor

This comment has been minimized.

Copy link
Contributor Author

commented Jul 25, 2019

Thanks for reviewing @fkgozali!

@fkgozali

This comment has been minimized.

Copy link
Contributor

commented Jul 25, 2019

Thanks for reviewing @fkgozali!

You鈥檙e welcome! Thanks for the all the work.

I think as the next steps we can:

  • add framework variant to CI test for RNTester
  • see if we can not use static_frameworks for better third party support?
@jtreanor

This comment has been minimized.

Copy link
Contributor Author

commented Jul 25, 2019

I think as the next steps we can:

  • add framework variant to CI test for RNTester

I've opened a draft PR for this here: #25818. It may require some discussion on the best approach.

  • see if we can not use static_frameworks for better third party support?

PR opened for this here: #25816 as mentioned above.

@jtreanor jtreanor deleted the jtreanor:try/subspec-approach branch Jul 25, 2019
facebook-github-bot added a commit that referenced this pull request Jul 25, 2019
Summary:
As part of the fix for #25349 I added `s.static_framework = true` to each podspec in repo (see #25619 (comment) for more context).

This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled.

However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries.

This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required.

This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors.

## Changelog

I don't think this needs a changelog entry since its just a refinement of #25619.
Pull Request resolved: #25816

Test Plan:
Check `RNTesterPods` still works both with and without `use_frameworks!`:

1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.

Reviewed By: hramos

Differential Revision: D16495030

Pulled By: fkgozali

fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
facebook-github-bot added a commit that referenced this pull request Jul 25, 2019
Summary:
This adds a `test_ios_frameworks` job to CircleCI to test the `RNTesterPods` project with `use_frameworks!` enabled. It will ensure the issue in #25349 is not reintroduced as suggested in #25619 (comment).

## Changelog

[iOS] [Internal] - Added CircleCI job for testing `RNTesterPods` with `use_frameworks!` enabled.
Pull Request resolved: #25818

Test Plan: Tests seem to be failing on `master` at the moment but you can see that the new job builds successfully [here](https://circleci.com/gh/facebook/react-native/103929?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link). You can confirm it installs the pods with `use_frameworks!` by seeing that `Installing pods with use_frameworks!` is at the start of the log for the `Generate RNTesterPods Workspace` step.

Reviewed By: hramos

Differential Revision: D16495016

Pulled By: fkgozali

fbshipit-source-id: 8ef607cc3a152f599d226f9f45d990fba50a65d4
@kdawgwilk kdawgwilk referenced this pull request Jul 30, 2019
TMomemt added a commit to TMomemt/react-native that referenced this pull request Aug 5, 2019
Summary:
This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in facebook#25393 (comment). If accepted, it will fix facebook#25349.

It builds on the changes I made in facebook#25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`.

The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` .

There are still a few breaking changes which I hope will be acceptable:

- `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path.
- ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by facebook#25619 (comment).
- ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by facebook#25619 (comment).
- ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by facebook#25619 (comment).
- ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by facebook#25619 (comment).
- Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled.

Still to do:

- ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in facebook#25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by facebook@3357351.
- I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? 锟

[iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks.
Pull Request resolved: facebook#25619

Test Plan:

```
buck build catalyst
```

Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed.

You can see that it works with these steps:

1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git`
2. `git checkout fix-frameworks-subspecs`
3. `cd ios && pod install`
4. `cd .. && react-native run-ios`

The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again.

`RNTesterPodsPods` can now work with or without `use_frameworks!`.

1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.

Reviewed By: PeteTheHeat

Differential Revision: D16465247

Pulled By: PeteTheHeat

fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
TMomemt added a commit to TMomemt/react-native that referenced this pull request Aug 5, 2019
鈥25816)

Summary:
As part of the fix for facebook#25349 I added `s.static_framework = true` to each podspec in repo (see facebook#25619 (comment) for more context).

This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled.

However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries.

This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required.

This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors.

I don't think this needs a changelog entry since its just a refinement of facebook#25619.
Pull Request resolved: facebook#25816

Test Plan:
Check `RNTesterPods` still works both with and without `use_frameworks!`:

1. Go to the `RNTester` directory and run `pod install`.
2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine.
3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again.
4. Run the tests again and see that it still works with frameworks enabled.

Reviewed By: hramos

Differential Revision: D16495030

Pulled By: fkgozali

fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
TMomemt added a commit to TMomemt/react-native that referenced this pull request Aug 5, 2019
Summary:
This adds a `test_ios_frameworks` job to CircleCI to test the `RNTesterPods` project with `use_frameworks!` enabled. It will ensure the issue in facebook#25349 is not reintroduced as suggested in facebook#25619 (comment).

[iOS] [Internal] - Added CircleCI job for testing `RNTesterPods` with `use_frameworks!` enabled.
Pull Request resolved: facebook#25818

Test Plan: Tests seem to be failing on `master` at the moment but you can see that the new job builds successfully [here](https://circleci.com/gh/facebook/react-native/103929?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link). You can confirm it installs the pods with `use_frameworks!` by seeing that `Installing pods with use_frameworks!` is at the start of the log for the `Generate RNTesterPods Workspace` step.

Reviewed By: hramos

Differential Revision: D16495016

Pulled By: fkgozali

fbshipit-source-id: 8ef607cc3a152f599d226f9f45d990fba50a65d4
@waqas19921 waqas19921 referenced this pull request Sep 16, 2019
2 of 5 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can鈥檛 perform that action at this time.