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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

☂️ Supporting Xcode 11 and iOS 13 Beta #25181

Closed
2 of 3 tasks
hramos opened this issue Jun 6, 2019 · 37 comments
Closed
2 of 3 tasks

☂️ Supporting Xcode 11 and iOS 13 Beta #25181

hramos opened this issue Jun 6, 2019 · 37 comments
Labels
Platform: iOS iOS applications. Type: Discussion Long running discussion.

Comments

@hramos
Copy link
Contributor

hramos commented Jun 6, 2019

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

@hramos hramos added Platform: iOS iOS applications. Type: Discussion Long running discussion. labels Jun 6, 2019
@lucasbento
Copy link

#25182 is apparently related.

@chrisspankroy
Copy link

chrisspankroy commented Jun 10, 2019

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

@radex
Copy link
Contributor

radex commented Jun 14, 2019

  • 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
Copy link
Contributor

radex commented Jun 25, 2019

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
Copy link
Contributor

radex commented Jun 28, 2019

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
Copy link

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
Copy link
Contributor

maicki commented Jun 29, 2019

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.

@radex
Copy link
Contributor

radex commented Aug 2, 2019

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

@rgomezp
Copy link

rgomezp commented Aug 27, 2019

I'm getting the error:
Unknown argument type 'attribute' in method -[RCTAppState getCurrentAppState:error:]. Extend RCTConvert to support this type.

@redpanda-bit
Copy link

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

@canpoyrazoglu
Copy link

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).

@cuttlas
Copy link

cuttlas commented Sep 6, 2019

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.

@jorisw
Copy link

jorisw commented Sep 11, 2019

@cuttlas Pretty sure <StatusBar /> works fine on iOS 13. We have an app in production with React Native 0.59.9 that uses it, and my phone has been running iOS 13 since it first went in beta. Same goes for current iOS 13.1 beta 3.

But in any case I would recommend upgrading to React Native 0.60.x before making any kind of compatibility determinations.

Edit: Just ran react-native init to create a 0.60.5 project, and it built fine with Xcode 11 installed, and ran fine in the Simulator running iOS 13.0 GM.

It did fail to find the removed iPhone X simulator, so I had to add the new default when running run-ios: react-native run-ios --simulator="iPhone 11 Pro Max".

The boilerplate App.js included a <StatusBar /> which worked also.

Edit 2: An old React Native 0.59.9 based project of mine builds and runs too, using Xcode11 and iOS 13.0 GM, which also uses the <StatusBar /> component.

@cmcaboy
Copy link

cmcaboy commented Sep 23, 2019

@rgomezp That error has been fixed. See #25138

@awgeorge
Copy link

awgeorge commented Sep 24, 2019

Anybody know anything about:

Started happening when our build machines updated to xcode11 - the code compiles fine, but the iOS app crashes on launch.

Last Exception Backtrace:
0   CoreFoundation                	0x193d73278 __exceptionPreprocess + 220 (NSException.m:199)
1   libobjc.A.dylib               	0x193a9c0a4 objc_exception_throw + 56 (objc-exception.mm:565)
2   APP_NAME.               	0x1023cbcb4 RCTFatal + 668
3   APP_NAME.               	0x10241c824 facebook::react::invokeInner(RCTBridge*, RCTModuleData*, unsigned int, folly::dynamic const&) + 712
4   APP_NAME.               	0x10241c3b4 invocation function for block in facebook::react::RCTNativeModule::invoke(unsigned int, folly::dy... + 88
5   libdispatch.dylib             	0x193a40658 _dispatch_call_block_and_release + 24 (init.c:1408)
6   libdispatch.dylib             	0x193a411cc _dispatch_client_callout + 16 (object.m:495)
7   libdispatch.dylib             	0x1939f3290 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1044 (inline_internal.h:2487)
8   CoreFoundation                	0x193cf0c74 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12 (CFRunLoop.c:1749)
9   CoreFoundation                	0x193cebc68 __CFRunLoopRun + 2004 (CFRunLoop.c:3069)
10  CoreFoundation                	0x193ceb16c CFRunLoopRunSpecific + 464 (CFRunLoop.c:3192)
11  GraphicsServices              	0x19db23328 GSEventRunModal + 104 (GSEvent.c:2246)
12  UIKitCore                     	0x197d55d0c UIApplicationMain + 1936 (UIApplication.m:4687)
13  APP_NAME.               	0x1022bc738 main + 88 (main.m:16)
14  libdyld.dylib                 	0x193b76424 start + 4

Thread 0 name:
Thread 0 Crashed:
0   libsystem_kernel.dylib        	0x0000000193b6bebc __pthread_kill + 8
1   libsystem_pthread.dylib       	0x0000000193a87794 pthread_kill$VARIANT$mp + 112 (pthread.c:1456)
2   libsystem_c.dylib             	0x00000001939dc8c0 __abort + 112 (abort.c:136)
3   libsystem_c.dylib             	0x00000001939dc850 abort + 112 (abort.c:107)
4   libc++abi.dylib               	0x0000000193b347d4 abort_message + 128 (abort_message.cpp:76)
5   libc++abi.dylib               	0x0000000193b349c4 demangling_terminate_handler() + 296 (cxa_default_handlers.cpp:66)
6   libobjc.A.dylib               	0x0000000193a9c358 _objc_terminate() + 124 (objc-exception.mm:701)
7   APP_NAME.               	0x00000001028611a4 CLSTerminateHandler() + 348
8   libc++abi.dylib               	0x0000000193b41304 std::__terminate(void (*)()) + 16 (cxa_handlers.cpp:59)
9   libc++abi.dylib               	0x0000000193b4129c std::terminate() + 44 (cxa_handlers.cpp:87)
10  libdispatch.dylib             	0x0000000193a411e0 _dispatch_client_callout + 36 (object.m:498)
11  libdispatch.dylib             	0x00000001939f3290 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1044 (inline_internal.h:2487)
12  CoreFoundation                	0x0000000193cf0c74 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12 (CFRunLoop.c:1749)
13  CoreFoundation                	0x0000000193cebc68 __CFRunLoopRun + 2004 (CFRunLoop.c:3069)
14  CoreFoundation                	0x0000000193ceb16c CFRunLoopRunSpecific + 464 (CFRunLoop.c:3192)
15  GraphicsServices              	0x000000019db23328 GSEventRunModal + 104 (GSEvent.c:2246)
16  UIKitCore                     	0x0000000197d55d0c UIApplicationMain + 1936 (UIApplication.m:4687)
17  APP_NAME.               	0x00000001022bc738 main + 88 (main.m:16)
18  libdyld.dylib                 	0x0000000193b76424 start + 4
react-native info
 
    React 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
    

@zhigang1992
Copy link
Contributor

@jorisw did you turn on dark appearance in the simulator?

@jorisw
Copy link

jorisw commented Sep 25, 2019

@zhigang1992 I have now, no issues here.

@rumax
Copy link
Contributor

rumax commented Sep 25, 2019

Both are currently in Beta, with an expected release date sometime in September 2019.

@hramos The issue is still opened, does it mean that Xcode 11/iOS 13 is not officially supported yet? Any official plans/date to resolve this issue?

@cmcaboy
Copy link

cmcaboy commented Sep 26, 2019

@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.

@AurangzaibRamzan
Copy link

+1

@pixeltight
Copy link

pixeltight commented Sep 27, 2019

react-native": "0.58.4" -- admittedly a little backdated
xcode 11

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.

2019-09-27 12:43:51.207578-0400 maxReactNative[1114:334083] [LayoutConstraints] Unable to simultaneously satisfy constraints.
	Probably at least one of the constraints in the following list is one you don't want. 
	Try this: 
		(1) look at each constraint and try to figure out which you don't expect; 
		(2) find the code that added the unwanted constraint or constraints and fix it. 
	(Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) 
(
    "<NSAutoresizingMaskLayoutConstraint:0x280da5ae0 h=-&- v=-&- UIView:0x12de0d670.height == UIWindow:0x12de0cf00.height   (active)>",
    "<NSAutoresizingMaskLayoutConstraint:0x280da5cc0 h=--- v=--- UIWindow:0x12de0cf00.height == 568   (active)>",
    "<NSLayoutConstraint:0x280da84b0 UILabel:0x12de0da50'maxReactNative'.centerY == 0.333333*UIView:0x12de0d670.bottom + 1   (active)>",
    "<NSLayoutConstraint:0x280da49b0 UILabel:0x12de0da50'maxReactNative'.centerY == UIView:0x12de0d670.centerY   (active)>"
)

Will attempt to recover by breaking constraint 
<NSLayoutConstraint:0x280da84b0 UILabel:0x12de0da50'maxReactNative'.centerY == 0.333333*UIView:0x12de0d670.bottom + 1   (active)>

Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKitCore/UIView.h> may also be helpful.
2019-09-27 12:43:51.280139-0400 maxReactNative[1114:334083] [MC] System group container for systemgroup.com.apple.configurationprofiles path is /private/var/containers/Shared/SystemGroup/systemgroup.com.apple.configurationprofiles
2019-09-27 12:43:51.281125-0400 maxReactNative[1114:334083] [MC] Reading from public effective user settings.
2019-09-27 12:45:52.832007-0400 maxReactNative[1114:334415] [BoringSSL] nw_protocol_boringssl_get_output_frames(1301) [C1.1:2][0x12de43560] get output frames failed, state 8196
2019-09-27 12:45:52.832593-0400 maxReactNative[1114:334415] [BoringSSL] nw_protocol_boringssl_get_output_frames(1301) [C1.1:2][0x12de43560] get output frames failed, state 8196
2019-09-27 12:45:52.833681-0400 maxReactNative[1114:334415] TIC Read Status [1:0x0]: 1:57
2019-09-27 12:45:52.835368-0400 maxReactNative[1114:334415] TIC Read Status [1:0x0]: 1:57
2019-09-27 12:55:24.483556-0400 maxReactNative[1114:334083] Could not load IOSurface for time string. Rendering locally instead.
Message from debugger: Terminated due to signal 9

@lxy8228535
Copy link

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 (
2,
RCTView,
1,
{
flex = 1;
pointerEvents = "box-none";
}
)

RCTFatal
-[RCTBatchedBridge callNativeModule:method:params:]
__33-[RCTBatchedBridge handleBuffer:]_block_invoke.388
_dispatch_call_block_and_release
_dispatch_client_callout
_dispatch_lane_serial_drain
_dispatch_lane_invoke
_dispatch_workloop_worker_thread
_pthread_wqthread
start_wqthread

@articice
Copy link

articice commented Oct 5, 2019

+1

@vagase
Copy link

vagase commented Oct 10, 2019

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 (
2,
RCTView,
1,
{
flex = 1;
pointerEvents = "box-none";
}
)

RCTFatal
-[RCTBatchedBridge callNativeModule:method:params:]
__33-[RCTBatchedBridge handleBuffer:]_block_invoke.388
_dispatch_call_block_and_release
_dispatch_client_callout
_dispatch_lane_serial_drain
_dispatch_lane_invoke
_dispatch_workloop_worker_thread
_pthread_wqthread
start_wqthread

I have the same problem

1 similar comment
@tryao
Copy link

tryao commented Oct 10, 2019

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 (
2,
RCTView,
1,
{
flex = 1;
pointerEvents = "box-none";
}
)

RCTFatal
-[RCTBatchedBridge callNativeModule:method:params:]
__33-[RCTBatchedBridge handleBuffer:]_block_invoke.388
_dispatch_call_block_and_release
_dispatch_client_callout
_dispatch_lane_serial_drain
_dispatch_lane_invoke
_dispatch_workloop_worker_thread
_pthread_wqthread
start_wqthread

I have the same problem

@tryao
Copy link

tryao commented Oct 11, 2019

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 (
2,
RCTView,
1,
{
flex = 1;
pointerEvents = "box-none";
}
)

RCTFatal
-[RCTBatchedBridge callNativeModule:method:params:]
__33-[RCTBatchedBridge handleBuffer:]_block_invoke.388
_dispatch_call_block_and_release
_dispatch_client_callout
_dispatch_lane_serial_drain
_dispatch_lane_invoke
_dispatch_workloop_worker_thread
_pthread_wqthread
start_wqthread

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

@lxy8228535
Copy link

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 (
2,
RCTView,
1,
{
flex = 1;
pointerEvents = "box-none";
}
)
RCTFatal
-[RCTBatchedBridge callNativeModule:method:params:]
__33-[RCTBatchedBridge handleBuffer:]_block_invoke.388
_dispatch_call_block_and_release
_dispatch_client_callout
_dispatch_lane_serial_drain
_dispatch_lane_invoke
_dispatch_workloop_worker_thread
_pthread_wqthread
start_wqthread

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

@HsuMyatMash
Copy link

HsuMyatMash commented Oct 21, 2019

I got error in UITableView

I am using UIView and UITableView without storyboard in sildeMenu.
After clicking slide menu image button, TableView appear in ios12 but in ios13 only transparent screen appear and none of table data appear.

`- (UIModalPresentationStyle)modalPresentationStyle
{
return UIModalPresentationOverCurrentContext;
}

  • (void)viewWillDisappear:(BOOL)animated
    {
    [super viewWillDisappear:animated];

    CGRect frame = self.lst_MainMenu.frame;
    frame.size.width = 0;

    [UIView beginAnimations:nil context:nil];
    [UIView setAnimationDuration:0.1];
    [UIView setAnimationDelegate:self];
    [UIView setAnimationDidStopSelector:nil];
    self.lst_MainMenu.frame = frame;
    [UIView commitAnimations];

}
//

  • (void)viewDidAppear:(BOOL)animated
    {
    [super viewDidAppear:animated];
    // NSInteger r = self.arr_list.count;
    //
    // CGRect frame = self.lst_MainMenu.frame;
    CGRect frame = self.orgFrame;
    // frame.size.height = self.lst_MainMenu.rowHeight * r;
    frame.size.width = 270;
    frame.size.height += self.ypos;
    frame.origin.y = self.ypos;

    CGRect startFrame = frame;
    startFrame.size.width = 0;
    self.lst_MainMenu.frame = startFrame;

// self.lst_MainMenu.frame = frame;
self.lst_MainMenu.hidden = false;

self.lst_MainMenu.separatorInset = UIEdgeInsetsZero;
if ([self.lst_MainMenu respondsToSelector:@selector(layoutMargins)]) {
    self.lst_MainMenu.layoutMargins = UIEdgeInsetsZero;
}

[UIView beginAnimations:nil context:nil];
[UIView setAnimationDuration:0.1];
[UIView setAnimationDelegate:self];
[UIView setAnimationDidStopSelector:nil];
self.lst_MainMenu.frame = frame;
[UIView commitAnimations];

}

//

  • (void)viewDidLoad
    {
    [super viewDidLoad];

    // Do any additional setup after loading the view from its nib.
    self.lst_MainMenu.delegate = self;
    self.lst_MainMenu.dataSource = self;
    self.lst_MainMenu.rowHeight = 44.0f;

    self.arr_list = _arr_list;

    self.orgFrame = self.lst_MainMenu.frame;
    self.lst_MainMenu.tableFooterView = [[UIView alloc] init];

    if (@available(iOS 13.0, *)) {
    self.overrideUserInterfaceStyle = UIUserInterfaceStyleLight;
    }
    }

//

  • (void)didReceiveMemoryWarning
    {
    [super didReceiveMemoryWarning];
    // Dispose of any resources that can be recreated.
    }

//

  • (void) touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event
    {
    [self dismissViewControllerAnimated:YES completion:nil];
    }

//

  • (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
    {
    return 1;
    }

//

  • (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
    {
    return self.arr_list.count;
    }

//

  • (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
    {
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"Cell"];

    if (cell == nil)
    {
    cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"Cell"];
    }
    [cell setBackgroundColor:[UIColor blackColor]];
    cell.textLabel.textColor = [UIColor whiteColor];
    [cell setSelectionStyle:UITableViewCellSelectionStyleGray];

    cell.textLabel.text = self.arr_list[indexPath.row];

    return cell;
    }

//

  • (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
    {
    self.lst_MainMenu.hidden = true;

    [self dismissViewControllerAnimated:YES completion:nil];

    [self.delegate selectedMainMenuItem:indexPath.row];

    NSLog(@"Selected : %ld", (long)indexPath.row);

    [self.lst_MainMenu deselectRowAtIndexPath:indexPath animated:YES];
    }
    `

@skraloupak
Copy link

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 (
2,
RCTView,
1,
{
flex = 1;
pointerEvents = "box-none";
}
)
RCTFatal
-[RCTBatchedBridge callNativeModule:method:params:]
__33-[RCTBatchedBridge handleBuffer:]_block_invoke.388
_dispatch_call_block_and_release
_dispatch_client_callout
_dispatch_lane_serial_drain
_dispatch_lane_invoke
_dispatch_workloop_worker_thread
_pthread_wqthread
start_wqthread

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

Excelent, works! :))

@Aung-Myint-Thein
Copy link

Aung-Myint-Thein commented Nov 25, 2019

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

Screenshot 2019-11-25 at 10 49 20 PM
Screenshot 2019-11-25 at 10 50 34 PM
Screenshot 2019-11-25 at 10 50 56 PM

@Aung-Myint-Thein
Copy link

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

Screenshot 2019-11-25 at 10 49 20 PM
Screenshot 2019-11-25 at 10 50 34 PM
Screenshot 2019-11-25 at 10 50 56 PM

I managed to get xcode 11 working. I needed to update Firebase and Facebook Login SDK :D

hramos pushed a commit to hramos/react-native that referenced this issue Feb 13, 2020
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
hramos pushed a commit to hramos/react-native that referenced this issue Feb 14, 2020
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
hramos pushed a commit to hramos/react-native that referenced this issue Feb 14, 2020
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
@developweb10
Copy link

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

@steipete
Copy link

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?

@rodperottoni
Copy link

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

facebook-github-bot pushed a commit that referenced this issue Mar 4, 2020
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
facebook-github-bot pushed a commit that referenced this issue Mar 4, 2020
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
osdnk pushed a commit to osdnk/react-native that referenced this issue Mar 9, 2020
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
osdnk pushed a commit to osdnk/react-native that referenced this issue Mar 9, 2020
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
andybangs added a commit to andybangs/react-native that referenced this issue Jun 9, 2020
@mrbrentkelly
Copy link
Contributor

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

@kelset kelset removed the iOS 13 label Jan 23, 2023
@kelset kelset closed this as completed Feb 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Platform: iOS iOS applications. Type: Discussion Long running discussion.
Projects
None yet
Development

No branches or pull requests