Summary:
## Motivation
The concept behind JSCallInvoker doesn't necessarily have to apply only to the JS thread. On Android, we need to re-use this abstraction to allow execution of async method calls on the NativeModules thread.
Reviewed By: PeteTheHeat
Differential Revision: D17377313
fbshipit-source-id: 3d9075cbfce0b908d800a366947cfd16a3013d1c
Summary: Removed Flipper deps from RNTester for now, since it's not compatible with FB CI yet.
Reviewed By: axe-fb
Differential Revision: D17465404
fbshipit-source-id: 581f113506dc9dbd345c404a802eb1b622f68ab7
Summary:
Implements the Appearance native module as discussed in https://github.com/react-native-community/discussions-and-proposals/issues/126.
The purpose of the Appearance native module is to expose the user's appearance preferences. It provides a basic get() API that returns the user's preferred color scheme on iOS 13 devices, also known as Dark Mode. It also provides the ability to subscribe to events whenever an appearance preference changes.
The name, "Appearance", was chosen purposefully to allow for future expansion to cover other appearance preferences such as reduced motion, reduced transparency, or high contrast modes.
Changelog:
[iOS] [Added] - The Appearance native module can be used to prepare your app for Dark Mode on iOS 13.
Reviewed By: yungsters
Differential Revision: D16699954
fbshipit-source-id: 03b4cc5d2a1a69f31f3a6d9bece23f6867b774ea
Summary:
Needed to capitalize the name, since this is the convention used elsewhere too
## Changelog:
[iOS] [Changed] - Renamed yoga podspec to Yoga
Reviewed By: shergin
Differential Revision: D17127104
fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
Summary:
This is needed for use_frameworks! support with CocoaPods. Also, with recent changes to RCTImageLoader etc (moved to CoreModules), we need to add a dep to `React-RCTImage` pod.
If this approach works for 0.61 branch as well, it should be beneficial to pick. Note that https://github.com/facebook/react-native/pull/26151 attempts to fix similar things, but in 0.61 branch, not master.
Reviewed By: axe-fb
Differential Revision: D17120352
fbshipit-source-id: ca96a7a61a6422a6f9fc3a4bf3add51e6f33f4f1
Summary:
This diff adds a JS spec for RCTImageLoader, and conforms to it in ObjC++. Since RCTImageLoader isn't called from JS, the js spec is empty. Since `/CoreModules/` is the only dir in OSS which supports TM, move the ObjC++ impl there.
The change in `NativeExceptionsManager.js` fixes a weird bug I was hitting in codegen, where the codegen cpp file wouldn't compile due to unused variable.
Reviewed By: JoshuaGross
Differential Revision: D16495674
fbshipit-source-id: 191897b87730a6b0b96022eedc6412551fae04a6
Summary:
This diff moves RCTImageLoader, RCTImageEditingManager, and RCTImageStoreManager to CoreModules. This is necessary for us to convert all these NativeModules to TurboModules.
**Note:** As a part of this diff, I had to break apart `RCTImageLoader.h`. All the protocols that were in `RCTImageLoader` are now in their own headers. Furthermore, `RCTImageLoader`'s methods are defined in `RCTImageLoaderProtocol`, so that we can call them from classes like `RCTImageViewManager` in `RCTImage`.
Reviewed By: PeteTheHeat
Differential Revision: D16805827
fbshipit-source-id: 89f6728b0766c30b74e25f7af1be8e6b8a7e6397
Summary:
As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 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 https://github.com/facebook/react-native/pull/25619.
Pull Request resolved: https://github.com/facebook/react-native/pull/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
Summary:
This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349.
It builds on the changes I made in https://github.com/facebook/react-native/pull/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 https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967.
- ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823.
- 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 https://github.com/facebook/react-native/issues/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 33573511f0.
- 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.
Pull Request resolved: https://github.com/facebook/react-native/pull/25619
Test Plan:
### FB
```
buck build catalyst
```
### Sample Project
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.
### 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.
Reviewed By: PeteTheHeat
Differential Revision: D16465247
Pulled By: PeteTheHeat
fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
Summary: For better compatibility re: https://github.com/facebook/react-native/pull/25393, this target should just use `RCTTypeSafety`
Reviewed By: PeteTheHeat
Differential Revision: D16210888
fbshipit-source-id: 6a55d631453cc420909247a7d5a64379587225b7
Summary: For now, suppress this warning - they are harmless.
Reviewed By: mdvacca
Differential Revision: D16198994
fbshipit-source-id: b167d0e98bbc4abcd0461d50f01f364d8d560aec
Summary: TurboModule is now included by default, so no need to have a toggle in autolink script anymore.
Reviewed By: mdvacca
Differential Revision: D16173820
fbshipit-source-id: 215ce7d188ce526b5a71df881bdc992c1ef34b34
Summary:
This is the first step towards fixing https://github.com/facebook/react-native/issues/25349. These are the changes to the podspec to correctly update dependencies and build config that will cause any breaking change for users or libraries.
I am breaking these changes out from https://github.com/facebook/react-native/pull/25393 as suggested by fkgozali in https://github.com/facebook/react-native/pull/25393#issuecomment-508322884.
These are the changes:
- Made C++ headers in `React-Core` private by default so that ObjC files can import the module without failures.
- Reduced the number of `yoga` headers that are exposed for the same reason as above. As far as I can see this doesn't cause issues but we can find another solution if it does.
- Adding some missing dependencies to fix undefined symbols errors.
- Added `DoubleConversion` to `HEADER_SEARCH_PATHS` where it was missing.
## Changelog
[iOS] [Fixed] - Updated podspecs for improved compatibility with different install types.
Pull Request resolved: https://github.com/facebook/react-native/pull/25496
Test Plan:
Everything should work exactly as before. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which points at this branch to show that it is still working `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 podspec-updates`
3. `cd ios && pod install`
4. `cd .. && react-native run-ios`
The sample app will build and run successfully.
Reviewed By: mmmulani
Differential Revision: D16167346
Pulled By: fkgozali
fbshipit-source-id: 1917b2f8779cb172362a457fb3fce686c55056d3
Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs.
Reviewed By: PeteTheHeat
Differential Revision: D16043221
fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
Summary: Now that the Pods/ directory is excluded by ShipIt from GitHub, we can move the Pods/ directory into react-native-github.
Reviewed By: fkgozali
Differential Revision: D15944730
fbshipit-source-id: b8165abbb4e6fef5ad4311da3885187b84ad1b20
Summary: Moves relevant JS files to fb internal, removes stuff we don't need in the RN repo any more. Android and iOS will happen in a follow-up.
Reviewed By: rickhanlonii
Differential Revision: D15468419
fbshipit-source-id: 39fffc22f87534e557788e398bbae575043353b6
Summary:
Simplifies the code anyone on iOS using RN has _to see_. In this case, React Native knows that everyone probably wants all these imports (unless they're using dev mode) and so we can auto-import the pod specs for a user from inside the lib.
Basically auto-link for the React side.
[iOS] [Added] - Adds a ruby function which imports the Pods for RN, so that users only have to include this function and it can change per RN version.
Pull Request resolved: https://github.com/facebook/react-native/pull/24555
Differential Revision: D15044780
Pulled By: cpojer
fbshipit-source-id: c3702a52104706def51da6f1d11ab966d57d1edb
Summary: This sets up RCTSampleTurboModule (and other variants) in RNTester when built with cocoapods. There's no call site yet though. And RNTester.xcodeproj doesn't support it.
Reviewed By: cpojer
Differential Revision: D14932535
fbshipit-source-id: db8eafd6777cbec8f3592dafdccbdd7cf44e38bc
Summary:
For CocoaPods variant only: install TurboModule binding so that sample modules can start using it. This commit only installs `global.__turboModuleProxy` - no sample module is provided.
Note: RNTester.xcodeproj will NOT have TurboModule enabled, due to complication in the .xcodeproj setup (doable, but maybe for some other time...)
To test:
```
console.error(global.__turboModuleProxy == null ? 'BOO' : 'YAY!');
```
Saw `YAY!` in RNTester pod version.
Reviewed By: cpojer
Differential Revision: D14932536
fbshipit-source-id: 3dc083da9154ec320ce6789ec7f2cef5a08fd6a7
Summary:
@public
This resolves the iOS side of #20879.
Reviewed By: natestedman, cpojer
Differential Revision: D14712066
fbshipit-source-id: 88dd0ff80d3467b314cacb9349029dadca4ddf19
Summary:
This is the couple of hacks I used after I finished #23802 in order to get fabric working on RNTester. This is inspired from prior work by kmagiera.
The goal of this PR is to show others what I’m struggling with, and to eventually merge it sans hacks.
- Yarn Install
- Uncomment the commented out pods in RNTester's pod file
- Open RNTesterPods workspace
- Run App
- this is only for pods, the non-pod RNTester will no longer work until updated with fabric too.
- `SurfaceHostingView` & `SurfaceHostingProxyRootView` both try to start the surface immediately, this leads to a race condition due to the javascript not having loaded yet, the hack here is:
1. Swizzle the `start` method on `RCTFabricSurface` to no-op when called.
2. Add observer for `RCTJavaScriptDidLoadNotification`
3. Call private method `_startAllSurfaces` on `_surfacePresenter` in AppDelegate when we receive `RCTJavaScriptDidLoadNotification`.
[General] [Added] - Use Fabric in RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/23803
Reviewed By: shergin, mdvacca
Differential Revision: D14450726
Pulled By: fkgozali
fbshipit-source-id: 8ae2d48634fecb60db539aaf0a2c89ba1f572c27
Summary:
This PR implements the first part of [RFC0004: CocoaPods Support Improvements](353d44f649/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects.
The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are:
* `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies.
* The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`.
*Next steps (not in scope of this PR):*
- Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`.
- Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR)
[iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project
Pull Request resolved: https://github.com/facebook/react-native/pull/23559
Differential Revision: D14179326
Pulled By: cpojer
fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
Summary:
[Folly upgrade](a70625abd7) introduced changes that have to be applied to `Install Third Party` script in order to use `New build system` from Xcode 10. Unfortunately, this might happen again if someone changes folly. Also removes non-existent files from folly podspec.
Pull Request resolved: https://github.com/facebook/react-native/pull/22394
Differential Revision: D13192463
Pulled By: hramos
fbshipit-source-id: ea0eeb6e1e7f6d7dfcdb6d1dee28b1a640ee7097
Summary:
Fixes#20302 (For iOS)
Note:
------
1. Checked the changes did not break CocoaPods integration.
2. The change for glog copying header into exported/ is to prevent build break for folly.
`folly/detail/Demangle.h` will try to use libstdc++'s demangle.h. Unfortunately, glog also has a demangle.h in source code. So I copy exported headers and only search headers in exported/ folder during build.
Pull Request resolved: https://github.com/facebook/react-native/pull/21976
Reviewed By: hramos
Differential Revision: D12818131
Pulled By: fkgozali
fbshipit-source-id: b3c637d09d1b3adde0ea15c82eb56e28f846885b
Summary:
This diff includes a few changes to the `React.podspec` file:
1. Introduce a `jsi` spec for code inside the `ReactCommon/jsi` folder. This depends on the JavaScriptCore framework.
2. Introduce a `jsiexecutor` spec for the code inside the `ReactCommon/jsiexecutor` folder. These files depend on files in `ReactCommon/cxxreact`, `ReactCommon/jsi`, and Folly.
3. Since RCTCxxBridge.mm now depends on `JSIExecutor`, we need to have the `CxxBridge` spec depend on the `jsiexecutor` spec.
Reviewed By: hramos
Differential Revision: D9820323
fbshipit-source-id: 0c96d027eed30ee47b6ee0d2d86cd6b1ad7a5887
Summary:
While the original reason for this change was because of an issue #20780, with further investigation I concluded that the issue is till present for this combo of versions:
glog - 0.3.5
google-cast-sdk - 4.3.1
Downgrading google-cast-sdk to 4.3.0 fixed the build issue.
Release Notes:
--------------
Updated glog version from 0.3.4 to 0.3.5 for iOS
[IOS] [ENHANCEMENT] [GLOG]
Pull Request resolved: https://github.com/facebook/react-native/pull/20811
Differential Revision: D9485221
Pulled By: hramos
fbshipit-source-id: 65caf0839588384a5229a6165506dc6ef62e5fc5
Summary: There are new patterns that require some upgrades to Folly version we're using for the cocoapods/gradle. Until the upgrade happens, Fabric target doesn't need to be included in the normal RNTester podfile (it was there for sanity build check).
Reviewed By: shergin
Differential Revision: D8151782
fbshipit-source-id: 8d83355d65b1eeeab865585f2ae75ac835bdf826
Summary: A few more places to update to target iOS 9.0 (upgraded from 8.0)
Reviewed By: shergin
Differential Revision: D8108719
fbshipit-source-id: f17aa5e5aa34fdad57196202bf67a842735d4cdc
Summary: Moving target deployment to iOS 9.0+ from now on, removing customization for iOS 8.
Reviewed By: shergin
Differential Revision: D8053439
fbshipit-source-id: 292c58f15c6e6caf8b28d15c1521812d6ed675c5
Summary: Each app has its own set of components to support, so this mechanism allows each of them to customize the set. Core library only provides the signature (.h file) without any impl.
Reviewed By: shergin
Differential Revision: D8065360
fbshipit-source-id: c123397afda678e84f1d1fa41a6393f25b2c15e1
Summary:
A few fixes:
* missing include: folly/Optional.h
* switch folly::Optional's `has_value()` to `hasValue()` for now until folly is upgraded to newer version
* fix up import for RCTTextAttributes.h
* fix up includes for "conversions.h" to use namespaced includes
Reviewed By: mmmulani
Differential Revision: D8021149
fbshipit-source-id: d3955986d3ab6b1d9b61ac1e385767893ce57e5e
Summary: Initial attempt to make fabric stuffs built properly with CocoaPods + RNTesterPods project. This simply includes fabric libs to the build, it doesn't change any behavior or enable fabric runtime.
Reviewed By: shergin
Differential Revision: D7626038
fbshipit-source-id: 4a80e0066cffa4478bb442fa8aefeaee6ff56ddd
Summary:
There was a fix around folly::dynamic constructor that will be needed for Fabric work. This was done in 94e964976c (diff-7d1cb97d222ba0c863ea8a8e43b2ee2b) and luckily the release 1 month after the Folly version we used in RN already had the fix, so that we don't need to upgrade to the latest folly yet (minimizing breakages).
Tested by:
* running RNTester xcode project (ios)
* running RNTesterPods workspace via cocoapods
* building android via gradle
Reviewed By: shergin
Differential Revision: D7626037
fbshipit-source-id: cb36ba5b91ba131d4e450300bd620db657cfa1e8
Summary: Should have been checked in previously. No setup change here.
Reviewed By: shergin
Differential Revision: D7626040
fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381