React-native-firebase: 🔥 [v6] Dynamic Links - ios - crash when a dynamic link is opened for the second time, with the app in foreground.

Created on 1 Nov 2019  ·  27Comments  ·  Source: invertase/react-native-firebase


Issue



I'm using Dynamic Links with the v6.
I didn't find any information about the installation of the module in the v6 documentation, so I followed the v5 documentation, with the following changes:

Respect the v5 documentation I did the following changes to avoid errors at building time:

  • RNFirebaseLinks with RNFBDynamicLinksAppDelegateInterceptor
  • Instance with sharedInstance

I didn't find any documentation about this changes in the migration document, however, reading the v6 library files, I found how to make compile my project.

At this point I'm able to open the app clicking on a dynamic link if the app is closed and if the app is in foreground. BUT if i click on the link a second time (with the app in foreground) I have a crash:

0x101291c3c __50-[FIRDynamicLinks handleUniversalLink:completion:]_block_invoke_2 + 458 (FIRDynamicLinks.m:458)

Additionally to this crash I noticed another bug: the onLink listener is called twice after the link is opened (obviously with the app in foreground), while it works properly on android.

Project Files






iOS

Click To Expand

#### `ios/Podfile`: - [ ] I'm not using Pods - [x] 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'

# Pods for MY-APP
pod 'React', :path => '../node_modules/react-native/'
pod 'React-Core', :path => '../node_modules/react-native/React'
pod 'React-DevSupport', :path => '../node_modules/react-native/React'
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-RCTWebSocket', :path => '../node_modules/react-native/Libraries/WebSocket'

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 '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'


target 'MY-APP-Tests' do
  inherit! :search_paths
  # Pods for testing
end


target 'MY-APP' do
  use_native_modules!
end

target 'MY-APP-dev' do
  use_native_modules!
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/RCTRootView.h>
#import <Firebase.h>
#import <RNGoogleSignin/RNGoogleSignin.h>
#import <FBSDKCoreKit/FBSDKCoreKit.h>
#import "Orientation.h"
#import "RNFBDynamicLinksAppDelegateInterceptor.h"

@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{

  [FIROptions defaultOptions].deepLinkURLScheme = @"MY.URL.SCHEME";
  [FIRApp configure];

  [[FBSDKApplicationDelegate sharedInstance] application:application didFinishLaunchingWithOptions:launchOptions];

  RCTBridge *bridge = [[RCTBridge alloc] initWithDelegate:self launchOptions:launchOptions];
  RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge
                                                   moduleName:@"MY_APP"
                                            initialProperties:nil];

  rootView.backgroundColor = [[UIColor alloc] initWithRed:1.0f green:1.0f blue:1.0f alpha:1];

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

}//didFinishLaunchingWithOptions


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


- (BOOL)application:(UIApplication *)application
            openURL:(NSURL *)url
            options:(NSDictionary<NSString *, id> *)options {

  BOOL handledByFacebook = [[FBSDKApplicationDelegate sharedInstance] application:application
                                                                          openURL:url
                                                                sourceApplication:options[UIApplicationOpenURLOptionsSourceApplicationKey]
                                                                       annotation:options[UIApplicationOpenURLOptionsAnnotationKey]];

  BOOL handledByGoogle = [RNGoogleSignin application:application
                                             openURL:url
                                   sourceApplication:options[UIApplicationOpenURLOptionsSourceApplicationKey]
                                          annotation:options[UIApplicationOpenURLOptionsAnnotationKey]];

  BOOL handledByFirebase = [[RNFBDynamicLinksAppDelegateInterceptor sharedInstance] application:application openURL:url options:options];

  return handledByFacebook || handledByGoogle || handledByFirebase;

}//openURL


- (void)applicationDidBecomeActive:(UIApplication *)application {
  [FBSDKAppEvents activateApp];
}//applicationDidBecomeActive


- (UIInterfaceOrientationMask)application:(UIApplication *)application supportedInterfaceOrientationsForWindow:(UIWindow *)window {
    return [Orientation getOrientation];
}//supportedInterfaceOrientationsForWindow

- (BOOL)application:(UIApplication *)application
continueUserActivity:(nonnull NSUserActivity *)userActivity
 restorationHandler: (nonnull void (^)(NSArray<id<UIUserActivityRestoring>> *_Nullable))restorationHandler {
  return [[RNFBDynamicLinksAppDelegateInterceptor sharedInstance] application:application
                            continueUserActivity:userActivity
                              restorationHandler:restorationHandler];
}


@end

Environment

Click To Expand

**`react-native info` output:** 

 System:
    OS: macOS Mojave 10.14.6
    CPU: (4) x64 Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz
    Memory: 173.46 MB / 8.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 12.4.0 - /usr/local/bin/node
    Yarn: 1.16.0 - /usr/local/bin/yarn
    npm: 6.9.0 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  SDKs:
    iOS SDK:
      Platforms: iOS 12.2, macOS 10.14, tvOS 12.2, watchOS 5.2
    Android SDK:
      API Levels: 23, 26, 27, 28, 29
      Build Tools: 28.0.3, 29.0.0
      System Images: android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom
  IDEs:
    Android Studio: 3.4 AI-183.6156.11.34.5692245
    Xcode: 10.2.1/10E1001 - /usr/bin/xcodebuild
  npmPackages:
    react: 16.8.6 => 16.8.6 
    react-native: 0.60.5 => 0.60.5 
  npmGlobalPackages:
    react-native-cli: 2.0.1
    react-native-create-library: 3.1.2
    react-native-git-upgrade: 0.2.7
- **Platform that you're experiencing the issue on**: - [x] 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:** - `Dynamic Links` - **Are you using `TypeScript`?** - `N`

Firebase SDK Crash iOS Links >= 6
Source
picture cark1
👍6

Most helpful comment

Hey all! I stumbled on the same issue (identical to what @alexeypopovich described).

I played with the Xcode debugger a bit and found an interesting piece of code in RNFBDynamicLinksAppDelegateInterceptor.m:

// Per Apple Tech Support, a network failure could occur when returning from background on iOS 12.
// https://github.com/AFNetworking/AFNetworking/issues/4279#issuecomment-447108981
// So we'll retry the request once
if (error && !retried && [NSPOSIXErrorDomain isEqualToString:error.domain] && error.code == 53) {
  retried = YES;
  [[FIRDynamicLinks dynamicLinks] handleUniversalLink:userActivity.webpageURL completion:completion];
}

Now, this seems to be the culprit: app is essentially returning from the background, from the second Dynamic Link click and is unable to resolve the short link, due to sockets having been reclaimed:

When your app issues a request, URLSession starts a TCP connection over which to run the this request. When the request completes URLSession holds on to this TCP connection in case you issue a new request. [...] When the user moves your app to the background, the system suspends your app and then reclaims socket resources.
When the user then moves the app back to the foreground and your app issues a new request, URLSession assigns this request to one of its cached connections, at which point it notices the socket resource reclaim and fails the request

I followed the linked GH issue (https://github.com/AFNetworking/AFNetworking/issues/4279#issuecomment-447108981) and there, a quote from Apple engineer says that there are a couple of workarounds to fix this. One is to retry manually, which is already done in the snippet above (and doesn't seem to work in this case).

The other is to:

C. You can invalidate your session when you go into the background and then re-create the session when you come back into the foreground. The new session will not share any connections with the old one, so this problem just can’t occur.

So I tried doing that and _I think_ it solved the issue. In order to try out my solution, edit ios/Pods⁩/⁨FirebaseDynamicLinks⁩/Firebase⁩/DynamicLinks⁩/FIRDynamicLinkNetworking.m and in the void FIRMakeHTTPRequest(NSURLRequest *request, FIRNetworkRequestCompletionHandler completion) { method body, replace

NSURLSession *session = [NSURLSession sharedSession];

with

NSURLSessionConfiguration *sessionConfig = [NSURLSessionConfiguration defaultSessionConfiguration];
NSURLSession *session = [NSURLSession sessionWithConfiguration:sessionConfig];

This should result in NSURLSession being recreated on each Dynamic Link resolution and avoid the crash.

Disclaimer: I'm not sure if this is the best solution (even if it's _the_ solution) and what impact re-creating the session object might have on memory/performance (versus using a shared instance). I'd appreciate if someone more experienced with iOS could take a look at this.

@alexeypopovich, @cark1 could you try and see if this workaround also works for you?

picture rszalski on 21 Nov 2019
👍5 🚀1 ❤1

All 27 comments

Out of curiosity - I saw RNFB version 6.0.0, does it still happen if you move to 6.0.3 and pods 6.11.0? (i.e., the most current?)

mikehardy picture mikehardy on 2 Nov 2019

Hi @mikehardy , I just updated all modules to 6.0.3

Installing RNFBApp 6.0.3 (was 6.0.0)
Installing RNFBAuth 6.0.3 (was 6.0.0)
Installing RNFBCrashlytics 6.0.3 (was 6.0.0)
Installing RNFBDynamicLinks 6.0.3 (was 6.0.0)
Installing RNFBFirestore 6.0.3 (was 6.0.0)
Installing RNFBFunctions 6.0.3 (was 6.0.0)
Installing RNFBStorage 6.0.3 (was 6.0.0)

But the problems are still there :/

What do you mean with:

move pods to 6.11.0

I'm using autolinking, I'm not declaring the RNFB modules in my pod explicitly

cark1 picture cark1 on 2 Nov 2019

@cark1 yeah - was a bit of a longshot that would actually fix the problem but better to have the reproduction at least on current stable so fixes will be valid. By moving the pods I mean using the override feature to specify current pods vs taking the default #2589 / https://github.com/invertase/react-native-firebase/commit/95f2f0fd6d9a9e62712fa4e243f9c9fddc2dddc8 - based on my read of the release notes 6.9.0 should be absolutely fine as a test, but there were breaking changes introduced with 6.10.0 to MLKit, if you are using those modules I think 6.9.0 is the limit, otherwise you can go all the way to 6.11.0

mikehardy picture mikehardy on 2 Nov 2019

Hey @cark1 👋 could you also provide the full stack trace from the crash log, rather than the single line above - thanks

Salakar picture Salakar on 2 Nov 2019

@mikehardy I just forced pod to 6.11.0, and the problems are still there :(

@Salakar
This is the full stack trace collected with Crashlytics

Crashed: com.apple.main-thread
0  punchlab                       0x100be579c __50-[FIRDynamicLinks handleUniversalLink:completion:]_block_invoke_2 + 458 (FIRDynamicLinks.m:458)
1  libdispatch.dylib              0x1bd2a0a38 _dispatch_call_block_and_release + 24
2  libdispatch.dylib              0x1bd2a17d4 _dispatch_client_callout + 16
3  libdispatch.dylib              0x1bd24f008 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1068
4  CoreFoundation                 0x1bd7f7b30 <redacted> + 12
5  CoreFoundation                 0x1bd7f2a68 <redacted> + 1924
6  CoreFoundation                 0x1bd7f1fc4 CFRunLoopRunSpecific + 436
7  GraphicsServices               0x1bf9f379c GSEventRunModal + 104
8  UIKitCore                      0x1ea173c38 UIApplicationMain + 212
9  punchlab                       0x1009286f0 main + 14 (main.m:14)
10 libdyld.dylib                  0x1bd2b28e0 start + 4
cark1 picture cark1 on 3 Nov 2019

Any updates?
I'm experiencing a similar issue, but it seems to appear only on iOS 12.
Works fine on iOS 13.
Happens only with short links.

> RNFBDynamicLinks: Unknown error occurred when attempting to handle a universal link: Error Domain=NSPOSIXErrorDomain Code=53 "Software caused connection abort" UserInfo={_kCFStreamErrorCodeKey=53, _kCFStreamErrorDomainKey=1}
> Printing description of completion:
> (FIRDynamicLinkUniversalLinkHandler) completion = (null)

image

alexeypopovich picture alexeypopovich on 13 Nov 2019
👍4 ❤1

Hey all! I stumbled on the same issue (identical to what @alexeypopovich described).

I played with the Xcode debugger a bit and found an interesting piece of code in RNFBDynamicLinksAppDelegateInterceptor.m:

// Per Apple Tech Support, a network failure could occur when returning from background on iOS 12.
// https://github.com/AFNetworking/AFNetworking/issues/4279#issuecomment-447108981
// So we'll retry the request once
if (error && !retried && [NSPOSIXErrorDomain isEqualToString:error.domain] && error.code == 53) {
  retried = YES;
  [[FIRDynamicLinks dynamicLinks] handleUniversalLink:userActivity.webpageURL completion:completion];
}

Now, this seems to be the culprit: app is essentially returning from the background, from the second Dynamic Link click and is unable to resolve the short link, due to sockets having been reclaimed:

When your app issues a request, URLSession starts a TCP connection over which to run the this request. When the request completes URLSession holds on to this TCP connection in case you issue a new request. [...] When the user moves your app to the background, the system suspends your app and then reclaims socket resources.
When the user then moves the app back to the foreground and your app issues a new request, URLSession assigns this request to one of its cached connections, at which point it notices the socket resource reclaim and fails the request

I followed the linked GH issue (https://github.com/AFNetworking/AFNetworking/issues/4279#issuecomment-447108981) and there, a quote from Apple engineer says that there are a couple of workarounds to fix this. One is to retry manually, which is already done in the snippet above (and doesn't seem to work in this case).

The other is to:

C. You can invalidate your session when you go into the background and then re-create the session when you come back into the foreground. The new session will not share any connections with the old one, so this problem just can’t occur.

So I tried doing that and _I think_ it solved the issue. In order to try out my solution, edit ios/Pods⁩/⁨FirebaseDynamicLinks⁩/Firebase⁩/DynamicLinks⁩/FIRDynamicLinkNetworking.m and in the void FIRMakeHTTPRequest(NSURLRequest *request, FIRNetworkRequestCompletionHandler completion) { method body, replace

NSURLSession *session = [NSURLSession sharedSession];

with

NSURLSessionConfiguration *sessionConfig = [NSURLSessionConfiguration defaultSessionConfiguration];
NSURLSession *session = [NSURLSession sessionWithConfiguration:sessionConfig];

This should result in NSURLSession being recreated on each Dynamic Link resolution and avoid the crash.

Disclaimer: I'm not sure if this is the best solution (even if it's _the_ solution) and what impact re-creating the session object might have on memory/performance (versus using a shared instance). I'd appreciate if someone more experienced with iOS could take a look at this.

@alexeypopovich, @cark1 could you try and see if this workaround also works for you?

rszalski picture rszalski on 21 Nov 2019
👍5 🚀1 ❤1

Hi, I'm also getting this error on iOS 12.4.2 and applied @rszalski's solution and it seems to have gone away. I haven't tested this on any other versions of iOS yet.

marqroldan picture marqroldan on 13 Dec 2019

Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.

stale[bot] picture stale[bot] on 10 Jan 2020

@stale This is still an issue for me.

Retested today on the following lib versions:

package.json:

    "@react-native-firebase/app": "6.2.0",
    "@react-native-firebase/dynamic-links": "6.2.0",

Pods:

$ cat Podfile.lock
PODS:
  - boost-for-react-native (1.63.0)
  - DoubleConversion (1.1.6)
  - FBLazyVector (0.61.4)
  - FBReactNativeSpec (0.61.4):
    - Folly (= 2018.10.22.00)
    - RCTRequired (= 0.61.4)
    - RCTTypeSafety (= 0.61.4)
    - React-Core (= 0.61.4)
    - React-jsi (= 0.61.4)
    - ReactCommon/turbomodule/core (= 0.61.4)
  - Firebase/Core (6.13.0):
    - Firebase/CoreOnly
    - FirebaseAnalytics (= 6.1.6)
  - Firebase/CoreOnly (6.13.0):
    - FirebaseCore (= 6.4.0)
  - Firebase/DynamicLinks (6.13.0):
    - Firebase/CoreOnly
    - FirebaseDynamicLinks (~> 4.0.5)
  - FirebaseAnalytics (6.1.6):
    - FirebaseCore (~> 6.4)
    - FirebaseInstanceID (~> 4.2)
    - GoogleAppMeasurement (= 6.1.6)
    - GoogleUtilities/AppDelegateSwizzler (~> 6.0)
    - GoogleUtilities/MethodSwizzler (~> 6.0)
    - GoogleUtilities/Network (~> 6.0)
    - "GoogleUtilities/NSData+zlib (~> 6.0)"
    - nanopb (= 0.3.9011)
  - FirebaseAnalyticsInterop (1.4.0)
  - FirebaseCore (6.4.0):
    - FirebaseCoreDiagnostics (~> 1.0)
    - FirebaseCoreDiagnosticsInterop (~> 1.0)
    - GoogleUtilities/Environment (~> 6.2)
    - GoogleUtilities/Logger (~> 6.2)
  - FirebaseCoreDiagnostics (1.1.2):
    - FirebaseCoreDiagnosticsInterop (~> 1.0)
    - GoogleDataTransportCCTSupport (~> 1.0)
    - GoogleUtilities/Environment (~> 6.2)
    - GoogleUtilities/Logger (~> 6.2)
    - nanopb (~> 0.3.901)
  - FirebaseCoreDiagnosticsInterop (1.1.0)
  - FirebaseDynamicLinks (4.0.6):
    - FirebaseAnalyticsInterop (~> 1.3)
    - FirebaseCore (~> 6.2)
  - FirebaseInstanceID (4.2.7):
    - FirebaseCore (~> 6.0)
    - GoogleUtilities/Environment (~> 6.0)
    - GoogleUtilities/UserDefaults (~> 6.0)

<snip>

• iOS 12.4.4 (iPhone 6) - Crashes
• iOS 13.3 (iPhone 11 Pro) - Works

If anyone is interested in a more automated workaround from https://github.com/invertase/react-native-firebase/issues/2807#issuecomment-557067373:

  1. Create pod_patches/FIRDynamicLinkNetworking.m.diff inside your project's root dir, with the following content:
--- Pods/FirebaseDynamicLinks/Firebase/DynamicLinks/FIRDynamicLinkNetworking.m
+++ Pods/FirebaseDynamicLinks/Firebase/DynamicLinks/FIRDynamicLinkNetworking.m
@@ -65,7 +65,8 @@
 }

 void FIRMakeHTTPRequest(NSURLRequest *request, FIRNetworkRequestCompletionHandler completion) {
-  NSURLSession *session = [NSURLSession sharedSession];
+  NSURLSessionConfiguration *sessionConfig = [NSURLSessionConfiguration defaultSessionConfiguration];
+  NSURLSession *session = [NSURLSession sessionWithConfiguration:sessionConfig];
   NSURLSessionDataTask *dataTask =
       [session dataTaskWithRequest:request
                  completionHandler:^(NSData *_Nullable data, NSURLResponse *_Nullable response,
  1. Append the following lines to the end of Podfile:
post_install do | installer |
  `patch -p0 < ../pod_patches/FIRDynamicLinkNetworking.m.diff`
en
rszalski picture rszalski on 16 Jan 2020

Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.

stale[bot] picture stale[bot] on 13 Feb 2020

No, the issue hasn't been fixed yet.

pilotocheg picture pilotocheg on 14 Feb 2020

Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.

stale[bot] picture stale[bot] on 13 Mar 2020

No, the issue hasn't been fixed yet.

pilotocheg picture pilotocheg on 13 Mar 2020

Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.

stale[bot] picture stale[bot] on 10 Apr 2020

No, the issue hasn't been fixed yet.

pilotocheg picture pilotocheg on 10 Apr 2020

Any updates?
I'm experiencing a similar issue, but it seems to appear only on iOS 12.
Works fine on iOS 13.
Happens only with short links.

> RNFBDynamicLinks: Unknown error occurred when attempting to handle a universal link: Error Domain=NSPOSIXErrorDomain Code=53 "Software caused connection abort" UserInfo={_kCFStreamErrorCodeKey=53, _kCFStreamErrorDomainKey=1}
> Printing description of completion:
> (FIRDynamicLinkUniversalLinkHandler) completion = (null)

image

I have the same issue like this. Any update on work around?

edwinwong90 picture edwinwong90 on 30 Apr 2020

I have the same issue too, still waiting for an update...

vyppN picture vyppN on 5 May 2020

Potential one for you to look at @russellwheatley - iOS thread related crash 🤓

Salakar picture Salakar on 6 May 2020

Looking at the solution above that is patching the Firebase iOS Pod itself has anyone raised this as an issue over at https://github.com/firebase/firebase-ios-sdk ? If that is the solution then it's not something we can fix I don't think

Salakar picture Salakar on 12 May 2020

Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.

stale[bot] picture stale[bot] on 9 Jun 2020

This is still an issue with Firebase iOS SDK 6.25.0 (RNFB: Dynamic Links 7.1.4)
And as of Firebase iOS SDK 6.27.0 the line on the file where the patch is used remains unchanged

https://github.com/firebase/firebase-ios-sdk/blob/master/FirebaseDynamicLinks/Sources/FIRDynamicLinkNetworking.m#L68

marqroldan picture marqroldan on 23 Jun 2020
👍2

@marqroldan fantastic working this upstream, and looks like you have tentative approval on the patch approach if you PR it, might be a real fix upstream for 6.28 if you PR it and it goes quickly :muscle:

mikehardy picture mikehardy on 23 Jun 2020
👍3

Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.

stale[bot] picture stale[bot] on 25 Jul 2020

No, this issue hasn't been fixed yet

pilotocheg picture pilotocheg on 25 Jul 2020
👍4

I think this can be closed now because of the recent release of @react-native-firebase/messaging (v 7.6.1) which uses Firebase iOS SDK 6.28.1

marqroldan picture marqroldan on 4 Aug 2020

Agreed - this should be done now, thanks @marqroldan !

mikehardy picture mikehardy on 4 Aug 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

alizahid picture alizahid  ·  3Comments
escobar5 picture escobar5  ·  3Comments
joecaraccio picture joecaraccio  ·  3Comments
noahtallen picture noahtallen  ·  3Comments
Damnum picture Damnum  ·  3Comments