Build fails when targeting Mac (Project Catalyst)

[brunolemos]

Issue

macOS Catalina was released today to the public after some months of betas. The new Xcode adds a target option "Mac" in addition to "iOS" and "iPad":

When enabling it, there's at least one build error coming from react-native-firebase.

/node_modules/@react-native-firebase/app/ios/RNFBApp/RNFBUtilsModule.m:63:23: 'fetchAssetsWithALAssetURLs:options:' is unavailable: not available on macCatalyst

react-native-firebase/packages/app/ios/RNFBApp/RNFBUtilsModule.m

Line 63 in 16e67dd

asset = [[PHAsset fetchAssetsWithALAssetURLs:@[ localFile ]

If you comment that line, the next error comes from the underlying ios firebase sdk.
So there are a few things to fix on this repo and others that we'll have to wait (or contribute to) the underlying sdk.

Dependent on firebase/firebase-ios-sdk#3144
Related: react-native-community/discussions-and-proposals#131

---

Project Files

iOS

Click To Expand

ios/Podfile:

• I'm not using Pods
• I'm using Pods and my Podfile looks like:

platform :ios, '9.0'
require_relative '../../../node_modules/@react-native-community/cli-platform-ios/native_modules'

target 'devhub' do
  # Pods for devhub
  pod 'FBLazyVector', :path => "../../../node_modules/react-native/Libraries/FBLazyVector"
  pod 'FBReactNativeSpec', :path => "../../../node_modules/react-native/Libraries/FBReactNativeSpec"
  pod 'RCTRequired', :path => "../../../node_modules/react-native/Libraries/RCTRequired"
  pod 'RCTTypeSafety', :path => "../../../node_modules/react-native/Libraries/TypeSafety"
  pod 'React', :path => '../../../node_modules/react-native/'
  pod 'React-Core', :path => '../../../node_modules/react-native/'
  pod 'React-CoreModules', :path => '../../../node_modules/react-native/React/CoreModules'
  pod 'React-Core/DevSupport', :path => '../../../node_modules/react-native/'
  pod 'React-RCTActionSheet', :path => '../../../node_modules/react-native/Libraries/ActionSheetIOS'
  pod 'React-RCTAnimation', :path => '../../../node_modules/react-native/Libraries/NativeAnimation'
  pod 'React-RCTBlob', :path => '../../../node_modules/react-native/Libraries/Blob'
  pod 'React-RCTImage', :path => '../../../node_modules/react-native/Libraries/Image'
  pod 'React-RCTLinking', :path => '../../../node_modules/react-native/Libraries/LinkingIOS'
  pod 'React-RCTNetwork', :path => '../../../node_modules/react-native/Libraries/Network'
  pod 'React-RCTSettings', :path => '../../../node_modules/react-native/Libraries/Settings'
  pod 'React-RCTText', :path => '../../../node_modules/react-native/Libraries/Text'
  pod 'React-RCTVibration', :path => '../../../node_modules/react-native/Libraries/Vibration'
  pod 'React-Core/RCTWebSocket', :path => '../../../node_modules/react-native/'

  pod 'React-cxxreact', :path => '../../../node_modules/react-native/ReactCommon/cxxreact'
  pod 'React-jsi', :path => '../../../node_modules/react-native/ReactCommon/jsi'
  pod 'React-jsiexecutor', :path => '../../../node_modules/react-native/ReactCommon/jsiexecutor'
  pod 'React-jsinspector', :path => '../../../node_modules/react-native/ReactCommon/jsinspector'
  pod 'ReactCommon/jscallinvoker', :path => "../../../node_modules/react-native/ReactCommon"
  pod 'ReactCommon/turbomodule/core', :path => "../../../node_modules/react-native/ReactCommon"
  pod 'Yoga', :path => '../../../node_modules/react-native/ReactCommon/yoga'

  pod 'DoubleConversion', :podspec => '../../../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
  pod 'glog', :podspec => '../../../node_modules/react-native/third-party-podspecs/glog.podspec'
  pod 'Folly', :podspec => '../../../node_modules/react-native/third-party-podspecs/Folly.podspec'

  use_native_modules!
end

target 'devhub-tvOS' do
  # Pods for devhub-tvOS

end

AppDelegate.m:

/**
 * Copyright (c) Facebook, Inc. and its affiliates.
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 */

#import "AppDelegate.h"

#import <React/RCTBridge.h>
#import <React/RCTBundleURLProvider.h>
#import <React/RCTLinkingManager.h>
#import <React/RCTRootView.h>

#import <Firebase.h>

@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
  RCTBridge *bridge = [[RCTBridge alloc] initWithDelegate:self launchOptions:launchOptions];
  RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge
                                                   moduleName:@"devhub"
                                            initialProperties:nil];

  // #1F2229 (dark-gray)
  rootView.backgroundColor = [UIColor colorWithRed:0.12 green:0.13 blue:0.16 alpha:1.0];

  self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
  UIViewController *rootViewController = [UIViewController new];
  rootViewController.view = rootView;
  self.window.rootViewController = rootViewController;
  [self.window makeKeyAndVisible];

  [FIRApp configure];

  return YES;
}

- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge
{
#if DEBUG
  return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"packages/mobile/index" fallbackResource:nil];
#else
  return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"];
#endif
}

- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
  return [RCTLinkingManager application:app openURL:url options:options];
}

@end

---

Android

Click To Expand

Have you converted to AndroidX?

• my application is an AndroidX application?
• I am using android/gradle.settings jetifier=true for Android compatibility?
• I am using the NPM package jetifier for react-native compatibility?

android/build.gradle:

// N/A

android/app/build.gradle:

// N/A

android/settings.gradle:

// N/A

MainApplication.java:

// N/A

AndroidManifest.xml:

<!-- N/A -->

---

Environment

Click To Expand

react-native info output:

react-native v0.60.2

System:
    OS: macOS 10.15
    CPU: (4) x64 Intel(R) Core(TM) i5-6267U CPU @ 2.90GHz
    Memory: 75.53 MB / 16.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 12.10.0 - /var/folders/xh/gcxkb1qx2rd3fmqz5vxrs2lh0000gn/T/yarn--1570483392765-0.2572019673201511/node
    Yarn: 1.19.0 - /var/folders/xh/gcxkb1qx2rd3fmqz5vxrs2lh0000gn/T/yarn--1570483392765-0.2572019673201511/yarn
    npm: 6.11.3 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  SDKs:
    iOS SDK:
      Platforms: iOS 13.0, DriverKit 19.0, macOS 10.15, tvOS 13.0, watchOS 6.0
    Android SDK:
      API Levels: 28
      Build Tools: 28.0.3
  IDEs:
    Android Studio: 3.5 AI-191.8026.42.35.5900203
    Xcode: 11.0/11A420a - /usr/bin/xcodebuild
  npmPackages:
    react-native: 0.61.2 => 0.61.2

• Platform that you're experiencing the issue on:
  • Mac
  • iOS
  • Android
  • iOS but have not tested behavior on Android
  • Android but have not tested behavior on iOS
  • Both
• react-native-firebase version you're using that has this issue:
  • 6.0.0
• Firebase module(s) you're using that has the issue:
  • app, analytics
• Are you using TypeScript?
  • Y

[mikehardy]

Wow, I just read the related issues. This looks like it's nowhere near ready at the "underlying SDK support" or react-native level. PRs welcome?

[brunolemos]

nowhere near ready at the "underlying SDK support"

First step is getting the build to work, hopefully there won't be much to change on react-native-firebase itself, mostly on the underlying sdk that is already being worked on. They merged a lot of related prs.

react-native level

I recall seeing tweets of people that made it work for basic apps, don't know about complex apps.

PRs welcome?

I'm trying to get build to work by commenting stuff (😄), but I don't have native experience to really help.

[Salakar]

Interesting, I think we can swap out that PHAsset API out with something more compatible, what that is yet I'm not sure. That or add a macro condition for Catalyst specifically to use a different API.

But ye, the main chunk of work will be external to this project and in RN & Firebase iOS SDK.

[brunolemos]

looks like it's nowhere near ready at the "underlying SDK support" or react-native level.

About the "react-native level", I got my app to run and 99% of the things are working as expected. I only had to remove Firebase and disable the WebSocket module for it to work. Didn't need to make code changes or remove any other native dependencies like bugsnag-react-native or react-native-gesture-handler.

Tweeted a more complete video here: twitter.com/brunolemos/status/1185636022346043392

[mikehardy]

"disable the websocket module" -> what are the impacts of that, is that metro-bundler specific and imply that the standard fast refresh dev cycle does not work? Looks promising

[brunolemos]

Development mode doesn't work at all because of that. So that is super annoying but since the app is basically the same as the iPad app you can run the iPad one on development mode and check the mac one on release mode for now.

[mikehardy]

Looks like if you comment out the one line failing the build in this module, then do this workaround firebase/firebase-ios-sdk#3500 (comment) you could actually have firebase working

[brunolemos]

Haven't tried this yet but I don't think so because the errors I got weren't related to signing

[Salakar]

@brunolemos if there's anything we can look at for this let us know, I'm not sure yet what the scope is of this not working, whether it's down to our implementation in RNFirebase or the Firebase iOS SDKs themselves.

If it helps btw, you can swap out the Firebase iOS SDK versions quite easily now in your Podfile if you need to try newer versions to see if there's been improvements in support, see the iOS section of: https://invertase.io/oss/react-native-firebase/guides/overriding-native-sdk-versions

[brunolemos]

disable the WebSocket module for it to work
Development mode doesn't work

React Native has fixed the WebSocket/Development issue, it's on master: facebook/react-native#27469

We still need to wait for the firebase sdk support firebase/firebase-ios-sdk#3144.

react-native-firebase still needs to replace fetchAssetsWithALAssetURLs as well.

[brunolemos]

I wonder if this means it’s possible to build for Catalyst: https://github.com/firebase/firebase-ios-sdk/pull/4532/files

[mikehardy]

Looks like admob, analytics, crashlytics, inAppMessaging, MLKit and Performance are still off-limits for catalyst, but the rest yeah

[pie6k]

Is there ANY positive update/light in the tunnel/perspective for next few months?

[pie6k]

@Salakar as far as I know, iOS SDK is now supporting Mac basing on their release notes (https://firebase.google.com/support/release-notes/ios), also - in last React Native update (0.62.0) has resolved issues related to Sockets, so it's possible to build for Mac - facebook/react-native#27469

So I think labels of this issue (blocked) are not relevant anymore.

[pie6k]

@Salakar It's my 3rd 'spam' reply on this issue. While I understand it might be very hard to resolve, it's quite important as it impacts root decisions related to choosing libraries for react native project if you plan to support MacOS.

Lack of any (yes/no/maybe/dont know) response on this topic is very confusing. Also seems it's not included in any kind of roadmap.

I've tried to sit down with my friend iOS developer, and we've managed to 'comment out' most of the issues as a lot of them were related to Photos Library, assets library etc.

We didn't manage to build analytics as they seemed to be included even if I removed analytics pod, as this pod is included in firebase core.

[mikehardy]

This was the last reply from @Salakar

Interesting, I think we can swap out that PHAsset API out with something more compatible, what that is yet I'm not sure. That or add a macro condition for Catalyst specifically to use a different API.

But ye, the main chunk of work will be external to this project and in RN & Firebase iOS SDK.

So, "the main chunk of work" appears to be done.

That leaves the RNFB part which would likely be "swap out that PHAsset API out with something more compatible" or "add a macro condition for Catalyst specifically" to use a different API, or (to avoid false dichotomy) perhaps something we aren't thinking of yet.

I imagine that could go mainline though if there was a PR. @pie6k have you examined available Catalyst APIs that could replace the unavailable PHAsset one to see what the universe of alternatives is? Have you tried one? That would be the next step - a PR that proposes exactly how to handle the straddle across the platform.

And that might be all there is to it

[andymatuschak]

That does seem to be the case. My project only uses /firestore and /functions, but I was able to get it running without issue after disabling the deprecated PHAsset fetch.

[mikehardy]

@andymatuschak

have you examined available Catalyst APIs that could replace the unavailable PHAsset one to see what the universe of alternatives is? Have you tried one? That would be the next step - a PR that proposes exactly how to handle the straddle across the platform.

[andymatuschak]

Those APIs are deprecated and have been for several years. They represent a way to access assets via an older URL representation. Clients using those old-style URLs will need to migrate to the newer style URLs. The ReactNative sources using the older PHAsset APIs should throw in those branches #if TARGET_OS_MACCATALYST.

[mikehardy]

Wow, you're not wrong: https://developer.apple.com/documentation/photokit/phasset/1624782-fetchassets

The Assets Library framework is deprecated in iOS 8.0 and later, replaced by the Photos framework. Use this method if your app has previously stored URLs from ALAsset objects and you need to retrieve the corresponding Photos framework objects.

And the other option we use is available since iOS8

@Salakar I think this was possibly deprecated 3 years ago when you first coded it: https://github.com/invertase/react-native-firebase/blame/v2.x.x/ios/RNFirebase/storage/RNFirebaseStorage.m#L257

Seems like maybe anything if ([localFilePath hasPrefix:@"assets-library://"]) { in it should give an ugly warning now in prep for delete, and for catalyst since it doesn't exist yeah, could just throw

@andymatuschak if you proposed anything like that it seems sensible to me though Mike D might know more