Support the default value of UIViewControllerBasedStatusBarAppearance (true)

cpojer commented 5 years ago

This issue was originally created by @steipete as facebook/react-native#11710.

Description

React Native currently requires that UIViewControllerBasedStatusBarAppearance is set to NO. This is an app-global setting and Apple offers this to help bringing old (pre-iOS 7) apps over to newer OS versions. It's not recommended that this is set for new apps. The methods for manual status bar control are already deprecated and Apple explicitly discourages using them:

To opt out of the view controller-based status bar appearance behavior, you must add the UIViewControllerBasedStatusBarAppearance key with a value of false to your app’s Info.plist file, but doing so is not recommended. https://developer.apple.com/reference/uikit/uiapplication/1622923-setstatusbarstyle#discussion

The check was added in 2015: https://github.com/facebook/react-native/blame/64a4c6070df7e711e7fd01c490f369bbd0d0fb28/React/Modules/RCTStatusBarManager.m#L109-L111

At PSPDFKit we offer a React Native module. We also have a very similar check that warns if the value of UIViewControllerBasedStatusBarAppearance is still set to the old behavior. https://pspdfkit.com/blog/2016/react-native-module/

Here's our FAQ article about it: https://pspdfkit.com/guides/ios/current/faq/uiviewcontrollerbasedstatusbarappearance/

Other platforms (Xamarin) are switching to the new style as well: https://github.com/xamarin/Xamarin.Forms/pull/463

Reproduction

See the code check for UIViewControllerBasedStatusBarAppearance. React should either support both or just default to the non-deprecated style. Currently any modification of the status bar requires this key to be set to false (true is the default)

Solution

This is tricky. See the related discussion on Twitter with Nick who wrote the original check: https://twitter.com/nicklockwood/status/816334935422337025

I realize that React doesn't own the parent View Controller. There are still quite a few ways how the parent VC can be accessed and how hooks could be installed to both have the current flexibility (so we do not break any API) and offer compatibility with the new way of controlling the status bar.

I am willing to help and work on this but I'd first love to hear if there are any discussions around this that I missed while searching for it and what the mid- to long-term plans here are. I know that everything related to the status bar on iOS is painful, so I'm apologizing in advance for bringing up this issue.

Additional Information

React Native version: 0.39
Platform: iOS
Operating System: MacOS

steipete commented 5 years ago

Thanks for copying this over. I don’t believe anyone tried working on that so far. I assume react uses exactly one root view controller? Moving the logic should be quite straightforward then, or am I missing something obvious?

saibayadon commented 5 years ago

I think throwing a YellowBox warning with a proper message instead of a fatal error would be more useful. That'd be a nice stopgap before fully fixing this particular error, no?

I know it's not the main RN use-case, but in my particular case I had to integrate a 3rd-party SDK that made use of the <StatusBar /> component in a native app. This resulted in a fatal error when we tried to display the RN view since our app uses UIViewControllerBasedStatusBarAppearance set to true (as per Apple recommendation). So our options were either forking RN and removing the fatal error (we were hiding the status bar anyways on the RN view) or refactor the native app.

It's also unfortunate that not enough people have this issue (which makes sense, since if you're doing a RN only app you'll just set UIViewControllerBasedStatusBarAppearance to false and be on your merry way. I'm still not fully certain why this is enforced as an error though? Is it to prevent people filing bugs saying "my status bar is not being updated" because the didn't read the documentation stating that UIViewControllerBasedStatusBarAppearance should be false? Thus having an error is better because it forces them to fix it as soon as they encounter it?