☂️ Supporting Xcode 11 and iOS 13 Beta

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

Compatibility with new UIScene, UISceneDelegate APIs

Fixed Issues

#25182 is apparently related.

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

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.

@shergin

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

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

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.

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.

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:
Unknown argument type 'attribute' in method -[RCTAppState getCurrentAppState:error:]. Extend RCTConvert to support this type.

Will the existing applications built with React Native crash when users upgrade to ios13?

@carlosalmonte04

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.

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

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":""}
Incident Identifier: 1DBCAB2C-8819-4B6E-8024-E637BD8D436A
CrashReporter Key: a1e0c5d1372b56e5695f9f8c1a2d812178664397
Hardware Model: xxx
Process: [56724]
Path: /private/var/containers/Bundle/Application/7277B38A-A665-42D4-889E-B348881CCF3C/
Identifier: com.org.app
Version: 2 (1.0.0)
AppStoreTools: 11C29
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: com.orgapp [2722]

Date/Time: 2020-02-13 12:19:02.9953 -0800
Launch Time: 2020-02-13 12:18:42.8564 -0800
OS Version: iPhone OS 13.3.1 (17D50)
Release Type: User
Baseband Version: n/a
Report Version: 104

Exception Type: EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d
Termination Description: SPRINGBOARD, scene-create watchdog transgression: application<com.org.app>:56724 exhausted real (wall clock) time allowance of 19.70 seconds | ProcessVisibility: Foreground | ProcessState: Running | WatchdogEvent: scene-create | WatchdogVisibility: Foreground | WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 25.900 (user 25.900, system 0.000), 65% CPU", | "Elapsed application CPU time (seconds): 0.292, 1% CPU" | )
Triggered by Thread: 0

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

Moving towards UIWindowScene support (#28058)

UIViewController-based status bar management (#25919)

Moving towards UIWindowScene support (react#28058)

UIViewController-based status bar management (react#25919)

https://github.com/facebook/react-native/issues/25181#issuecomment-54…

Looks like a recent change to RCTAlertController is causing RN Alerts to no longer display in iOS 13+ apps that use the new Scene APIs. Related issue here #31251

Navigation Menu

Repository navigation

☂️ Supporting Xcode 11 and iOS 13 Beta #25181

Related Issues

Known Issues

20 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

☂️ Supporting Xcode 11 and iOS 13 Beta #25181

Description

Related Issues

Known Issues

Activity

lucasbento commented on Jun 7, 2019

chrisspankroy commented on Jun 10, 2019

radex commented on Jun 14, 2019

radex commented on Jun 25, 2019

radex commented on Jun 28, 2019

steipete commented on Jun 28, 2019

maicki commented on Jun 29, 2019

radex commented on Aug 2, 2019

rgomezp commented on Aug 27, 2019

carlosalmonte04 commented on Aug 30, 2019

canpoyrazoglu commented on Sep 3, 2019

cuttlas commented on Sep 6, 2019

20 remaining items

Aung-Myint-Thein commented on Nov 28, 2019

developweb10 commented on Feb 19, 2020

steipete commented on Feb 19, 2020

rodperottoni commented on Feb 20, 2020

mrbrentkelly commented on Mar 26, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions