-
Notifications
You must be signed in to change notification settings - Fork 24.4k
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
☂️ Supporting Xcode 11 and iOS 13 Beta #25181
Comments
#25182 is apparently related. |
EDIT: Listing a few places I found so far that need a change:
|
Copying over from a thread on discord (sorry about formatting): I'm doing some digging around React Native core to prepare it for support for new UIScene based APIs — that's necessary to be able to support multiple windows on iPadOS (and therefore, multiple windows on macOS via Catalyst) a problem I'm seeing is that there are many APIs that are RCTBridge-global — and assume the app has one window this is a problem, because we need to be able to target a specific UIScene, not the whole UIApplication I'm interested in helping out on this front as I'd like @Nozbe 4 to work nicely with multiple windows the right way (for perf, memory usage, and usability) is to have one RCTBridge and multiple root views Another idea I've just had is that could have a react context automatically set up, such that when there's a RCTRootView, anywhere in the react tree you can useIOSScene() (or a simple context consumer) that would return some sort of tag uniquelly identifying a UIWindowScene (that this component is embedded in) that you could pass on to NativeModule-based APIs. That would ease the transition and still allow people to invoke some of these functions imperatively if needed. |
Update regarding StatusBar: I tried upgrading StatusBar to work with multiple UIScenes by passing rootViewTag to StatusBarManager: https://github.com/facebook/react-native/pull/25425/files I did most of the work, but what I realized is that there is no one-to-one replacement API for What Apple really wants us to do is to finally adopt view-controller based status bar management. Here's what I suggest: I think we should add a WDYT? I'm willing to send the necessary PRs :) EDIT: Alternatively (or in addition to this), there could be an |
Using a To offer a fallback-mode we could control what is returned in childViewControllerForStatusBarStyle on this If native view controllers are used (e.g. navigation plugin) then these need to be updated to support the legacy API. |
We had a similar idea around a There is no status bar appearance handling in there yet though. |
Update regarding StatusBar: Other than Peter's comments, I received no specific guidance as for view controller-based status bar management, so I just went ahead and made this PR proposing the adoption of RCTRootViewController: #25919 |
I'm getting the error: |
Will the existing applications built with React Native crash when users upgrade to ios13? |
@carlosalmonte04 nope, they work. I've been on iOS 13 (beta) for months, and actively developing my React Native app on my phone with no issues (expect minor things like textbox placeholder texts hard to see because of color changes in Dark Mode etc). |
So, if I understood correctly, the StatusBar component is not working on iOS 13 yet? not even with the last RN version? I was going to open an issue because I couldn't make it work with React Native 0.59.1 and iOS 13 beta. |
@cuttlas Pretty sure But in any case I would recommend upgrading to React Native 0.60.x before making any kind of compatibility determinations. Edit: Just ran It did fail to find the removed iPhone X simulator, so I had to add the new default when running run-ios: The boilerplate Edit 2: An old React Native |
Anybody know anything about: Started happening when our build machines updated to xcode11 - the code compiles fine, but the iOS app crashes on launch.
react-native infoReact Native Environment Info: System: OS: macOS 10.14.6 CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz Memory: 540.87 MB / 16.00 GB Shell: 5.3 - /bin/zsh Binaries: Node: 11.15.0 - ~/.nvm/versions/node/v11.15.0/bin/node npm: 6.7.0 - ~/.nvm/versions/node/v11.15.0/bin/npm SDKs: iOS SDK: Platforms: iOS 13.0, DriverKit 19.0, macOS 10.15, tvOS 13.0, watchOS 6.0 Android SDK: API Levels: 29 Build Tools: 29.0.2 System Images: android-29 | Google Play Intel x86 Atom IDEs: Android Studio: 3.5 AI-191.8026.42.35.5791312 Xcode: 11.0/11A419c - /usr/bin/xcodebuild npmPackages: react: 16.8.3 => 16.8.3 react-native: 0.59.10 => 0.59.10 npmGlobalPackages: react-native-cli: 2.0.1 |
@jorisw did you turn on dark appearance in the simulator? |
@zhigang1992 I have now, no issues here. |
@hramos The issue is still opened, does it mean that |
@rumax I haven't heard anything from official support from the RN team, but I am supporting my app in production on iOS 13. The only big big issues I have ran into are the fishhook.c EXC_BAD_ACCESS bug (very critical) and contact imports don't allow access to the notes property. I haven't ran into anything else major quite yet, but we are monitoring closely. I hope this helps. |
+1 |
react-native": "0.58.4" -- admittedly a little backdated I could build the app but it got completely hung up on the error below as soon as the app got past the splash screen. Everything went back to normal after downgrading Xcode to 10.3. Digging around, it seems to pertain to 'autoResize' on the IOS side. I have zero clue how I would debug this in a meaningful way. Any pointers I could find assumed the dev had coded in Objective-C/Swift.
|
when I push to RN page with Xcode 11, the iOS app crashes, but it's no problem with Xcode 10. Exception 'createView:(nonnull NSNumber *)reactTag viewName:(NSString *)viewName rootTag:(attribute((unused)) NSNumber *)rootTag props:(NSDictionary *)props is not a recognized Objective-C method.' was thrown while invoking createView on target UIManager with params ( RCTFatal |
+1 |
I have the same problem |
1 similar comment
I have the same problem |
I solved my problem by use the following method: in your project directory, open file in myproject/node_modules/react-native/React/Base/RCTModuleMethod.m. Then correct as below: https://github.com/facebook/react-native/pull/25146/files#diff-263fc157dfce55895cdc16495b55d190 |
I also solved the problem by use your method, thx |
I got error in UITableView I am using UIView and UITableView without storyboard in sildeMenu. `- (UIModalPresentationStyle)modalPresentationStyle
}
// self.lst_MainMenu.frame = frame;
} //
//
//
//
//
//
//
|
Excelent, works! :)) |
Our app is already on RN 0.61.4 and was trying to run with xcode 11.2.1 but the app crashed in xcode after the build is successful. It was running fine for xcode 10. Did anyone face this problem before? I need to use xcode 11 because I will need Apple Authentication. Screenshots for xcode crash is attached. Thanks a lot as I have zero knowledge on iOS Dev but started purely on RN :D |
I managed to get xcode 11 working. I needed to update Firebase and Facebook Login SDK :D |
Summary: I'm taking the first step towards supporting iOS 13 UIScene APIs and modernizing React Native not to assume an app only has a single window. See discussion here: facebook#25181 (comment) The approach I'm taking is to take advantage of `RootTagContext` and passing it to NativeModules so that they can identify correctly which window they refer to. Here I'm just laying groundwork. - [x] `Alert` and `ActionSheetIOS` take an optional `rootTag` argument that will cause them to appear on the correct window - [x] `StatusBar` methods also have `rootTag` argument added, but it's not fully hooked up on the native side — this turns out to require some more work, see: facebook#25181 (comment) - [x] `setNetworkActivityIndicatorVisible` is deprecated in iOS 13 - [x] `RCTPerfMonitor`, `RCTProfile` no longer assume `UIApplicationDelegate` has a `window` property (no longer the best practice) — they now just render on the key window Next steps: Add VC-based status bar management (if I get the OK on facebook#25181 (comment) ), add multiple window demo to RNTester, deprecate Dimensions in favor of a layout context, consider adding hook-based APIs for native modules such as Alert that automatically know which rootTag to pass ## Changelog [Internal] [Changed] - Modernize Modal to use RootTagContext [iOS] [Changed] - `Alert`, `ActionSheetIOS`, `StatusBar` methods now take an optional `surface` argument (for future iPadOS 13 support) [Internal] [Changed] - Do not assume `UIApplicationDelegate` has a `window` property Pull Request resolved: facebook#25425 Test Plan: - Open RNTester and: - go to Modal and check if it still works - Alert → see if works - ACtionSheetIOS → see if it works - StatusBar → see if it works - Share → see if it works Reviewed By: PeteTheHeat Differential Revision: D16957751 Pulled By: hramos fbshipit-source-id: f9d36ecdb3a11b137b36234049e9e256b88b45ac
Summary: Pull Request resolved: facebook#28058 I'm taking the first step towards supporting iOS 13 UIScene APIs and modernizing React Native not to assume an app only has a single window. See discussion here: facebook#25181 (comment) The approach I'm taking is to take advantage of `RootTagContext` and passing it to NativeModules so that they can identify correctly which window they refer to. Here I'm just laying groundwork. - [x] `Alert` and `ActionSheetIOS` take an optional `rootTag` argument that will cause them to appear on the correct window - [x] `StatusBar` methods also have `rootTag` argument added, but it's not fully hooked up on the native side — this turns out to require some more work, see: facebook#25181 (comment) - [x] `setNetworkActivityIndicatorVisible` is deprecated in iOS 13 - [x] `RCTPerfMonitor`, `RCTProfile` no longer assume `UIApplicationDelegate` has a `window` property (no longer the best practice) — they now just render on the key window Next steps: Add VC-based status bar management (if I get the OK on facebook#25181 (comment) ), add multiple window demo to RNTester, deprecate Dimensions in favor of a layout context, consider adding hook-based APIs for native modules such as Alert that automatically know which rootTag to pass ## Changelog [Internal] [Changed] - Modernize Modal to use RootTagContext [iOS] [Changed] - `Alert`, `ActionSheetIOS`, `StatusBar` methods now take an optional `surface` argument (for future iPadOS 13 support) [Internal] [Changed] - Do not assume `UIApplicationDelegate` has a `window` property Pull Request resolved: facebook#25425 Test Plan: - Open RNTester and: - go to Modal and check if it still works - Alert → see if works - ACtionSheetIOS → see if it works - StatusBar → see if it works - Share → see if it works Reviewed By: PeteTheHeat Differential Revision: D16957751 Pulled By: hramos fbshipit-source-id: 4dae1a8126822038891e3bc3e0aa9640b86dfe66
Summary: Pull Request resolved: facebook#28058 I'm taking the first step towards supporting iOS 13 UIScene APIs and modernizing React Native not to assume an app only has a single window. See discussion here: facebook#25181 (comment) The approach I'm taking is to take advantage of `RootTagContext` and passing it to NativeModules so that they can identify correctly which window they refer to. Here I'm just laying groundwork. - [x] `Alert` and `ActionSheetIOS` take an optional `rootTag` argument that will cause them to appear on the correct window - [x] `StatusBar` methods also have `rootTag` argument added, but it's not fully hooked up on the native side — this turns out to require some more work, see: facebook#25181 (comment) - [x] `setNetworkActivityIndicatorVisible` is deprecated in iOS 13 - [x] `RCTPerfMonitor`, `RCTProfile` no longer assume `UIApplicationDelegate` has a `window` property (no longer the best practice) — they now just render on the key window Next steps: Add VC-based status bar management (if I get the OK on facebook#25181 (comment) ), add multiple window demo to RNTester, deprecate Dimensions in favor of a layout context, consider adding hook-based APIs for native modules such as Alert that automatically know which rootTag to pass ## Changelog [Internal] [Changed] - Modernize Modal to use RootTagContext [iOS] [Changed] - `Alert`, `ActionSheetIOS`, `StatusBar` methods now take an optional `surface` argument (for future iPadOS 13 support) [Internal] [Changed] - Do not assume `UIApplicationDelegate` has a `window` property Pull Request resolved: facebook#25425 Test Plan: - Open RNTester and: - go to Modal and check if it still works - Alert → see if works - ACtionSheetIOS → see if it works - StatusBar → see if it works - Share → see if it works Reviewed By: PeteTheHeat Differential Revision: D16957751 Pulled By: hramos fbshipit-source-id: 7bbe694c17a490a7ba7b03e5ed31e679e2777b68
iOS app rejected by apple due to following issue, app crashed on iOS version 13, on other it is working fine. {"app_name":"","timestamp":"2020-02-13 12:19:03.15 -0800","app_version":"1.0.0","slice_uuid":"353b6dbc-72d2-3f16-894f-ee0be7638ff7","adam_id":1495537992,"build_version":"2","bundleID":"com.org.app","share_with_app_devs":true,"is_first_party":false,"bug_type":"109","os_version":"iPhone OS 13.3.1 (17D50)","incident_id":"1DBCAB2C-8819-4B6E-8024-E637BD8D436A","name":""} Date/Time: 2020-02-13 12:19:02.9953 -0800 Exception Type: EXC_CRASH (SIGKILL) |
This looks like you are stalling the main thread roo long on startup, the SPRINGBOARD watchdog timer kicks in. Are you maybe doing sync network requests on startup? |
Same here. App rejected because of crashes on 13.3.1. Works fine when running a debug version of the app. Will post an update here if I figure it out |
Summary: Pull Request resolved: #28058 I'm taking the first step towards supporting iOS 13 UIScene APIs and modernizing React Native not to assume an app only has a single window. See discussion here: #25181 (comment) The approach I'm taking is to take advantage of `RootTagContext` and passing it to NativeModules so that they can identify correctly which window they refer to. Here I'm just laying groundwork. - [x] `Alert` and `ActionSheetIOS` take an optional `rootTag` argument that will cause them to appear on the correct window - [x] `StatusBar` methods also have `rootTag` argument added, but it's not fully hooked up on the native side — this turns out to require some more work, see: #25181 (comment) - [x] `setNetworkActivityIndicatorVisible` is deprecated in iOS 13 - [x] `RCTPerfMonitor`, `RCTProfile` no longer assume `UIApplicationDelegate` has a `window` property (no longer the best practice) — they now just render on the key window Next steps: Add VC-based status bar management (if I get the OK on #25181 (comment) ), add multiple window demo to RNTester, deprecate Dimensions in favor of a layout context, consider adding hook-based APIs for native modules such as Alert that automatically know which rootTag to pass ## Changelog [Internal] [Changed] - Modernize Modal to use RootTagContext [iOS] [Changed] - `Alert`, `ActionSheetIOS`, `StatusBar` methods now take an optional `surface` argument (for future iPadOS 13 support) [iOS] [Changed] - RCTPresentedViewController now takes a nullable `window` arg [Internal] [Changed] - Do not assume `UIApplicationDelegate` has a `window` property Pull Request resolved: #25425 Test Plan: - Open RNTester and: - go to Modal and check if it still works - Alert → see if works - ACtionSheetIOS → see if it works - StatusBar → see if it works - Share → see if it works Reviewed By: PeteTheHeat Differential Revision: D16957751 Pulled By: hramos fbshipit-source-id: ae2a4478e2e7f8d2be3022c9c4861561ec244a26
Summary: {emoji:26a0} This is a follow up to #25425 -- which isn't merged yet… See https://github.com/facebook/react-native/pull/25919/files/2a286257a6553a80a34e2b1f1ad94fc7bae36ea3..125aedbedc234c65c8d1b2133b79e926ad6cf145 for actual diff Currently, StatusBar native module manages the status bar on iOS globally, using `UIApplication.` APIs. This is bad because: - those APIs have been deprecated for 4 years - Apple really, really wants you to have an explicitly defined view controller, and control the status bar there - it [breaks external native components](#25181 (comment)) - it's [not compatible with iPadOS 13 multi window support](#25181 (comment)) for those reasons I we should transition towards view controller-based status bar management. With that, there is a need to introduce a default React Native root view controller, so I added `RCTRootViewController`. Using it is completely opt-in and there is no breaking change here. However I believe this should be a part of the template for new RN iOS apps. Additionally, I added `RCTRootViewControllerProtocol` with hooks needed for RCTStatusBarManager to control the status bar. This means apps that want to have total control over their view controller can still opt in to react native VC-based status bar by conforming their root view controller to this protocol. ## Changelog [iOS] [Added] - Added `RCTRootViewController` and `RCTRootViewControllerProtocol` [iOS] [Fixed] - `UIViewControllerBasedStatusBarAppearance=YES` no longer triggers an error as long as you use `RCTRootViewController` [iOS] [Fixed] - Status bar style is now correctly changed in multi-window iPadOS 13 apps if you use `RCTRootViewController` and set `UIViewControllerBasedStatusBarAppearance=YES` Pull Request resolved: #25919 Test Plan: - Open RNTester → StatusBar → and check that no features broke Reviewed By: fkgozali Differential Revision: D16957766 Pulled By: hramos fbshipit-source-id: 9ae1384ee20a06933053c4404b8237810f1e7c2c
Summary: Pull Request resolved: facebook#28058 I'm taking the first step towards supporting iOS 13 UIScene APIs and modernizing React Native not to assume an app only has a single window. See discussion here: facebook#25181 (comment) The approach I'm taking is to take advantage of `RootTagContext` and passing it to NativeModules so that they can identify correctly which window they refer to. Here I'm just laying groundwork. - [x] `Alert` and `ActionSheetIOS` take an optional `rootTag` argument that will cause them to appear on the correct window - [x] `StatusBar` methods also have `rootTag` argument added, but it's not fully hooked up on the native side — this turns out to require some more work, see: facebook#25181 (comment) - [x] `setNetworkActivityIndicatorVisible` is deprecated in iOS 13 - [x] `RCTPerfMonitor`, `RCTProfile` no longer assume `UIApplicationDelegate` has a `window` property (no longer the best practice) — they now just render on the key window Next steps: Add VC-based status bar management (if I get the OK on facebook#25181 (comment) ), add multiple window demo to RNTester, deprecate Dimensions in favor of a layout context, consider adding hook-based APIs for native modules such as Alert that automatically know which rootTag to pass ## Changelog [Internal] [Changed] - Modernize Modal to use RootTagContext [iOS] [Changed] - `Alert`, `ActionSheetIOS`, `StatusBar` methods now take an optional `surface` argument (for future iPadOS 13 support) [iOS] [Changed] - RCTPresentedViewController now takes a nullable `window` arg [Internal] [Changed] - Do not assume `UIApplicationDelegate` has a `window` property Pull Request resolved: facebook#25425 Test Plan: - Open RNTester and: - go to Modal and check if it still works - Alert → see if works - ACtionSheetIOS → see if it works - StatusBar → see if it works - Share → see if it works Reviewed By: PeteTheHeat Differential Revision: D16957751 Pulled By: hramos fbshipit-source-id: ae2a4478e2e7f8d2be3022c9c4861561ec244a26
Summary: {emoji:26a0} This is a follow up to facebook#25425 -- which isn't merged yet… See https://github.com/facebook/react-native/pull/25919/files/2a286257a6553a80a34e2b1f1ad94fc7bae36ea3..125aedbedc234c65c8d1b2133b79e926ad6cf145 for actual diff Currently, StatusBar native module manages the status bar on iOS globally, using `UIApplication.` APIs. This is bad because: - those APIs have been deprecated for 4 years - Apple really, really wants you to have an explicitly defined view controller, and control the status bar there - it [breaks external native components](facebook#25181 (comment)) - it's [not compatible with iPadOS 13 multi window support](facebook#25181 (comment)) for those reasons I we should transition towards view controller-based status bar management. With that, there is a need to introduce a default React Native root view controller, so I added `RCTRootViewController`. Using it is completely opt-in and there is no breaking change here. However I believe this should be a part of the template for new RN iOS apps. Additionally, I added `RCTRootViewControllerProtocol` with hooks needed for RCTStatusBarManager to control the status bar. This means apps that want to have total control over their view controller can still opt in to react native VC-based status bar by conforming their root view controller to this protocol. ## Changelog [iOS] [Added] - Added `RCTRootViewController` and `RCTRootViewControllerProtocol` [iOS] [Fixed] - `UIViewControllerBasedStatusBarAppearance=YES` no longer triggers an error as long as you use `RCTRootViewController` [iOS] [Fixed] - Status bar style is now correctly changed in multi-window iPadOS 13 apps if you use `RCTRootViewController` and set `UIViewControllerBasedStatusBarAppearance=YES` Pull Request resolved: facebook#25919 Test Plan: - Open RNTester → StatusBar → and check that no features broke Reviewed By: fkgozali Differential Revision: D16957766 Pulled By: hramos fbshipit-source-id: 9ae1384ee20a06933053c4404b8237810f1e7c2c
This task tracks issues with Xcode 11 and iOS 13. Both are currently in Beta, with an expected release date sometime in September 2019.
Related Issues
Known Issues
Fixed Issues
__unused
signature changedThe text was updated successfully, but these errors were encountered: