☂️ Supporting Xcode 11 and iOS 13 Beta

[hramos]

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

• Supporting Project Catalyst: Running iPad apps on macOS
• Initial UIKitForMac support
• Initial UIWindowScene support

Known Issues

• Compatibility with new UIScene, UISceneDelegate APIs

Fixed Issues

• EXC_BAD_ACCESS in fishhook.c (iOS 13/Xcode 11)
• __unused signature changed

[lucasbento]

#25182 is apparently related.

[chrisspankroy]

I've opened a PR that fixes #25182 at #25212

[radex]

• A lot of things in UIApplication / UIApplicationDelegate are deprecated and you're supposed to move to UIScene / UISceneDelegate (this is groundwork for supporting multiple windows on iPadOS and macOS -- and even if you don't, this is where the APIs will evolve in the future). I might be interested in sending some pull requests with the necessary changes (necessary for those willing to implement multiple window support in their own apps -- with full backwards compatibility so that most people don't have to do anything)

EDIT:

Listing a few places I found so far that need a change:

• RCTRedBox.dismiss - do not use delegate.window
• RCTDeviceInfo - Dimensions should be per-RootView, not per bridge
• RCTPerfMonitor - do not use appDelegate.window
• status bar - minimum effort: switch from controlling status bar on UIApplication to controlling it on UIWindowScene. Better: use best-practices approach and do view controller-based status bar controlling.

[radex]

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
for example, status bar is a NativeModule - https://github.com/facebook/react-native/blob/master/React/Modules/RCTStatusBarManager.m

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
now, this would be almost a non-issue if every UIScene (window) had its own bridge (the bridge could reference the uiscene somehow, and each would have its own native module). BUT this is not the right way to do this

the right way (for perf, memory usage, and usability) is to have one RCTBridge and multiple root views
I think we should therefore transitions APIs like this to be component-based instead of plain NativeModules. this is also relevant e.g. for Dimensions

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.

cc @shergin @fkgozali

[radex]

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 UIApplication.setStatusBarStyle etc. — UIWindowScene.statusBarManager is a read-only API.

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 RCTRootViewController: UIViewController class, that will conform to status bar management protocol, and have the right hooks for StatusBarManager to be able to control this. The default template for new apps would use RCTRootViewController in the AppDelegate.m. This would be the new default, but 100% opt in — old apps don't have to use it (StatusBarManager would fall back to deprecated UIApplication-based APIs), or brownfield apps / apps that use react-native-navigation or other libraries that mess with view controllers.

WDYT? I'm willing to send the necessary PRs :)

EDIT: Alternatively (or in addition to this), there could be an RCTRootViewControllerProtocol so that people can conform their own UIViewController to whatever is necessary for RN to be able to toggle the state of the status bar

[steipete]

Using a RCTRootViewController seems to be the best solution here. This also requires that UIViewControllerBasedStatusBarAppearance is set to true (this is the default, so simply deleting the entry will do).

To offer a fallback-mode we could control what is returned in childViewControllerForStatusBarStyle on this RCTRootViewController. Default should pass on to whatever view controller is on top, this would nicely resolve the current compatibility issues with 3rd-party plugins. And the old-style calls to StatusBarManager simply set the status on RCTRootViewController and trigger a setNeedsStatusBarAppearanceUpdate - this should result in roughly the same experience as currently.

If native view controllers are used (e.g. navigation plugin) then these need to be updated to support the legacy API.

[maicki]

We had a similar idea around a RCTRootViewController a while back as we needed "base view controllers" for integrating React Native into brown field: https://github.com/maicki/react-native-view-controller .

There is no status bar appearance handling in there yet though.