firebase-ios-sdk
firebase-ios-sdk copied to clipboard
firebase
Intermittent Issue with fcmToken being nil since June 24th
Description
We have been experiencing intermittent errors in retrieving the token via Firebase Crashlytics since June 24th. Upon analysis, it appears that the fcmToken is occasionally nil in the didReceiveRegistrationToken method. While I have searched for similar issues, none seem to match our case.
We are currently storing the fcmToken in a singleton variable (I understand this is not ideal, but we plan to address it after an upcoming security review). The fcmToken is set exclusively in the didReceiveRegistrationToken method, and is only retrieved elsewhere in the code.
Example:
- (void)messaging:(FIRMessaging *)messaging didReceiveRegistrationToken:(NSString *)fcmToken {
NSLog(@"FCM registration token: %@", fcmToken);
[HDSingleton sharedInstance].fcmToken = fcmToken;
//doSometing
}
I initially considered that the issue might be due to calling the variable before the singleton instance is created, but this seems unlikely as the error has been consistently occurring 1-8 times daily since June 24th. (Interestingly, this error did not occur before June 24th and has only started affecting some users since then.)
I checked the Firebase SDK version change log and noticed an update on June 24th. Although the update details do not specifically mention changes related to fcmToken, I suspect there might be a compatibility issue if there were server-side changes.
Attached are the relevant Firebase Crashlytics logs and information. Please let me know if additional data is required.
Note: The code on line 96 of HDLoginPresenter.m is as follows:
NSDictionary *userInfo = @{@"fcmToken": [HDSingleton sharedInstance].fcmToken};
This error occurs because we are attempting to insert a nil value into the NSDictionary.
Reproducing the issue
I tried debugging by manually setting the singleton variable to nil, which resulted in the same error in the code. However, I could not replicate this issue during actual use. All the information we have comes from the errors reported in Firebase Crashlytics. (We are conducting tests in our development environment on actual devices, but have not been able to reproduce the error.)
- (Although problems occur on other days as well, 13,607 people used the app on July 9 alone. Among them, the issue occurred for 7 users. Therefore, it is even more difficult to reproduce.)
Firebase SDK Version
10.25.0
Xcode Version
15.3
Installation Method
CocoaPods
Firebase Product(s)
Messaging
Targeted Platforms
iOS
Relevant Log Output
Fatal Exception: NSInvalidArgumentException
0 CoreFoundation 0x83f20 __exceptionPreprocess
1 libobjc.A.dylib 0x16018 objc_exception_throw
2 CoreFoundation 0x15e6c -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]
3 CoreFoundation 0x15a88 +[NSDictionary dictionaryWithObjects:forKeys:count:]
4 MyApp 0x44bf0 __47-[HDLoginPresenter requestAPIcheckInWithBlock:]_block_invoke + 96 (HDLoginPresenter.m:96)
5 MyApp 0x775d4 __81-[HDNetworkManager HTTPRequestOperationWithRequest:useIndicator:success:failure:]_block_invoke + 206 (HDNetworkManager.m:206)
6 libdispatch.dylib 0x213c _dispatch_call_block_and_release
7 libdispatch.dylib 0x3dd4 _dispatch_client_callout
8 libdispatch.dylib 0x125ec _dispatch_main_queue_drain
9 libdispatch.dylib 0x121b8 _dispatch_main_queue_callback_4CF
10 CoreFoundation 0x56710 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
11 CoreFoundation 0x53914 __CFRunLoopRun
12 CoreFoundation 0x52cd8 CFRunLoopRunSpecific
13 GraphicsServices 0x11a8 GSEventRunModal
14 UIKitCore 0x40a90c -[UIApplication _run]
15 UIKitCore 0x4be9d0 UIApplicationMain
16 MyApp 0xbb490 main + 14 (main.m:14)
17 ??? 0x1ba425e4c (누락)
Crashed: com.google.firebase.crashlytics.ios.exception
0 FirebaseCrashlytics 0x21c10 FIRCLSProcessRecordAllThreads + 184
1 FirebaseCrashlytics 0x21ff0 FIRCLSProcessRecordAllThreads + 1176
2 FirebaseCrashlytics 0x18e74 FIRCLSHandler + 48
3 FirebaseCrashlytics 0x13a84 __FIRCLSExceptionRecord_block_invoke + 96
4 libdispatch.dylib 0x3dd4 _dispatch_client_callout + 20
5 libdispatch.dylib 0x132c4 _dispatch_lane_barrier_sync_invoke_and_complete + 56
6 FirebaseCrashlytics 0x12a00 FIRCLSExceptionRecord + 220
7 FirebaseCrashlytics 0x13548 FIRCLSExceptionRecordNSException + 456
8 FirebaseCrashlytics 0x12608 FIRCLSTerminateHandler() + 404
9 libc++abi.dylib 0x14068 std::__terminate(void (*)()) + 16
10 libc++abi.dylib 0x1400c std::terminate() + 108
11 libobjc.A.dylib 0x3cafc objc_terminate + 16
12 libdispatch.dylib 0x3de8 _dispatch_client_callout + 40
13 libdispatch.dylib 0x125ec _dispatch_main_queue_drain + 1060
14 libdispatch.dylib 0x121b8 _dispatch_main_queue_callback_4CF + 44
15 CoreFoundation 0x56710 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
16 CoreFoundation 0x53914 __CFRunLoopRun + 1996
17 CoreFoundation 0x52cd8 CFRunLoopRunSpecific + 608
18 GraphicsServices 0x11a8 GSEventRunModal + 164
19 UIKitCore 0x40a90c -[UIApplication _run] + 888
20 UIKitCore 0x4be9d0 UIApplicationMain + 340
21 MyApp 0xbb490 main + 14 (main.m:14)
22 ??? 0x1ba425e4c (누락)
com.apple.uikit.eventfetch-thread
0 libsystem_kernel.dylib 0x1808 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x5008 mach_msg2_internal + 80
2 libsystem_kernel.dylib 0x4f20 mach_msg_overwrite + 436
3 libsystem_kernel.dylib 0x4d60 mach_msg + 24
4 CoreFoundation 0x53f5c __CFRunLoopServiceMachPort + 160
5 CoreFoundation 0x53600 __CFRunLoopRun + 1208
6 CoreFoundation 0x52cd8 CFRunLoopRunSpecific + 608
7 Foundation 0xc7e4c -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
8 Foundation 0xc7c9c -[NSRunLoop(NSRunLoop) runUntilDate:] + 64
9 UIKitCore 0x41e640 -[UIEventFetcher threadMain] + 420
10 Foundation 0xde718 __NSThread__start__ + 732
11 libsystem_pthread.dylib 0x606c _pthread_start + 136
12 libsystem_pthread.dylib 0x10d8 thread_start + 8
Thread
0 libsystem_kernel.dylib 0x1590 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x4980 _pthread_wqthread + 364
2 libsystem_pthread.dylib 0x10cc start_wqthread + 8
com.google.firebase.crashlytics.MachExceptionServer
0 libsystem_kernel.dylib 0x1808 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x5008 mach_msg2_internal + 80
2 libsystem_kernel.dylib 0x4f20 mach_msg_overwrite + 436
3 libsystem_kernel.dylib 0x4d60 mach_msg + 24
4 FirebaseCrashlytics 0x1b5bc FIRCLSMachExceptionServer + 104
5 libsystem_pthread.dylib 0x606c _pthread_start + 136
6 libsystem_pthread.dylib 0x10d8 thread_start + 8
AFNetworking
0 libsystem_kernel.dylib 0x1808 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x5008 mach_msg2_internal + 80
2 libsystem_kernel.dylib 0x4f20 mach_msg_overwrite + 436
3 libsystem_kernel.dylib 0x4d60 mach_msg + 24
4 CoreFoundation 0x53f5c __CFRunLoopServiceMachPort + 160
5 CoreFoundation 0x53600 __CFRunLoopRun + 1208
6 CoreFoundation 0x52cd8 CFRunLoopRunSpecific + 608
7 Foundation 0xc7e4c -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
8 Foundation 0xc7d20 -[NSRunLoop(NSRunLoop) run] + 64
9 MyApp 0x8f87c +[AFURLConnectionOperation networkRequestThreadEntryPoint:] + 164 (AFURLConnectionOperation.m:164)
10 Foundation 0xde718 __NSThread__start__ + 732
11 libsystem_pthread.dylib 0x606c _pthread_start + 136
12 libsystem_pthread.dylib 0x10d8 thread_start + 8
Thread
0 libsystem_kernel.dylib 0x1590 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x4980 _pthread_wqthread + 364
2 libsystem_pthread.dylib 0x10cc start_wqthread + 8
com.apple.NSURLConnectionLoader
0 libsystem_kernel.dylib 0x1808 mach_msg2_trap + 8
1 libsystem_kernel.dylib 0x5008 mach_msg2_internal + 80
2 libsystem_kernel.dylib 0x4f20 mach_msg_overwrite + 436
3 libsystem_kernel.dylib 0x4d60 mach_msg + 24
4 CoreFoundation 0x53f5c __CFRunLoopServiceMachPort + 160
5 CoreFoundation 0x53600 __CFRunLoopRun + 1208
6 CoreFoundation 0x52cd8 CFRunLoopRunSpecific + 608
7 CFNetwork 0xfdc90 _CFHostIsDomainTopLevel + 108176
8 Foundation 0xde718 __NSThread__start__ + 732
9 libsystem_pthread.dylib 0x606c _pthread_start + 136
10 libsystem_pthread.dylib 0x10d8 thread_start + 8
Thread
0 libsystem_kernel.dylib 0x1590 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x4980 _pthread_wqthread + 364
2 libsystem_pthread.dylib 0x10cc start_wqthread + 8
Thread
0 libsystem_kernel.dylib 0x1590 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x4980 _pthread_wqthread + 364
2 libsystem_pthread.dylib 0x10cc start_wqthread + 8
Thread
0 libsystem_kernel.dylib 0x1590 __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x4980 _pthread_wqthread + 364
2 libsystem_pthread.dylib 0x10cc start_wqthread + 8
If using Swift Package Manager, the project's Package.resolved
Expand Package.resolved snippet
Replace this line with the contents of your Package.resolved.
If using CocoaPods, the project's Podfile.lock
Expand Podfile.lock snippet
PODS:
- FirebaseAnalytics (10.25.0):
- FirebaseAnalytics/AdIdSupport (= 10.25.0)
- FirebaseCore (~> 10.0)
- FirebaseInstallations (~> 10.0)
- GoogleUtilities/AppDelegateSwizzler (~> 7.11)
- GoogleUtilities/MethodSwizzler (~> 7.11)
- GoogleUtilities/Network (~> 7.11)
- "GoogleUtilities/NSData+zlib (~> 7.11)"
- nanopb (< 2.30911.0, >= 2.30908.0)
- FirebaseAnalytics/AdIdSupport (10.25.0):
- FirebaseCore (~> 10.0)
- FirebaseInstallations (~> 10.0)
- GoogleAppMeasurement (= 10.25.0)
- GoogleUtilities/AppDelegateSwizzler (~> 7.11)
- GoogleUtilities/MethodSwizzler (~> 7.11)
- GoogleUtilities/Network (~> 7.11)
- "GoogleUtilities/NSData+zlib (~> 7.11)"
- nanopb (< 2.30911.0, >= 2.30908.0)
- FirebaseCore (10.25.0):
- FirebaseCoreInternal (~> 10.0)
- GoogleUtilities/Environment (~> 7.12)
- GoogleUtilities/Logger (~> 7.12)
- FirebaseCoreExtension (10.25.0):
- FirebaseCore (~> 10.0)
- FirebaseCoreInternal (10.25.0):
- "GoogleUtilities/NSData+zlib (~> 7.8)"
- FirebaseCrashlytics (10.25.0):
- FirebaseCore (~> 10.5)
- FirebaseInstallations (~> 10.0)
- FirebaseRemoteConfigInterop (~> 10.23)
- FirebaseSessions (~> 10.5)
- GoogleDataTransport (~> 9.2)
- GoogleUtilities/Environment (~> 7.8)
- nanopb (< 2.30911.0, >= 2.30908.0)
- PromisesObjC (~> 2.1)
- FirebaseInstallations (10.25.0):
- FirebaseCore (~> 10.0)
- GoogleUtilities/Environment (~> 7.8)
- GoogleUtilities/UserDefaults (~> 7.8)
- PromisesObjC (~> 2.1)
- FirebaseMessaging (10.25.0):
- FirebaseCore (~> 10.0)
- FirebaseInstallations (~> 10.0)
- GoogleDataTransport (~> 9.3)
- GoogleUtilities/AppDelegateSwizzler (~> 7.8)
- GoogleUtilities/Environment (~> 7.8)
- GoogleUtilities/Reachability (~> 7.8)
- GoogleUtilities/UserDefaults (~> 7.8)
- nanopb (< 2.30911.0, >= 2.30908.0)
- FirebaseRemoteConfigInterop (10.25.0)
- FirebaseSessions (10.25.0):
- FirebaseCore (~> 10.5)
- FirebaseCoreExtension (~> 10.0)
- FirebaseInstallations (~> 10.0)
- GoogleDataTransport (~> 9.2)
- GoogleUtilities/Environment (~> 7.13)
- GoogleUtilities/UserDefaults (~> 7.13)
- nanopb (< 2.30911.0, >= 2.30908.0)
- PromisesSwift (~> 2.1)
- FLAnimatedImage (1.0.17)
- FLEX (5.22.10)
- GoogleAppMeasurement (10.25.0):
- GoogleAppMeasurement/AdIdSupport (= 10.25.0)
- GoogleUtilities/AppDelegateSwizzler (~> 7.11)
- GoogleUtilities/MethodSwizzler (~> 7.11)
- GoogleUtilities/Network (~> 7.11)
- "GoogleUtilities/NSData+zlib (~> 7.11)"
- nanopb (< 2.30911.0, >= 2.30908.0)
- GoogleAppMeasurement/AdIdSupport (10.25.0):
- GoogleAppMeasurement/WithoutAdIdSupport (= 10.25.0)
- GoogleUtilities/AppDelegateSwizzler (~> 7.11)
- GoogleUtilities/MethodSwizzler (~> 7.11)
- GoogleUtilities/Network (~> 7.11)
- "GoogleUtilities/NSData+zlib (~> 7.11)"
- nanopb (< 2.30911.0, >= 2.30908.0)
- GoogleAppMeasurement/WithoutAdIdSupport (10.25.0):
- GoogleUtilities/AppDelegateSwizzler (~> 7.11)
- GoogleUtilities/MethodSwizzler (~> 7.11)
- GoogleUtilities/Network (~> 7.11)
- "GoogleUtilities/NSData+zlib (~> 7.11)"
- nanopb (< 2.30911.0, >= 2.30908.0)
- GoogleDataTransport (9.4.1):
- GoogleUtilities/Environment (~> 7.7)
- nanopb (< 2.30911.0, >= 2.30908.0)
- PromisesObjC (< 3.0, >= 1.2)
- GoogleMaps (7.4.0):
- GoogleMaps/Maps (= 7.4.0)
- GoogleMaps/Base (7.4.0)
- GoogleMaps/Maps (7.4.0):
- GoogleMaps/Base
- GoogleUtilities/AppDelegateSwizzler (7.13.3):
- GoogleUtilities/Environment
- GoogleUtilities/Logger
- GoogleUtilities/Network
- GoogleUtilities/Privacy
- GoogleUtilities/Environment (7.13.3):
- GoogleUtilities/Privacy
- PromisesObjC (< 3.0, >= 1.2)
- GoogleUtilities/Logger (7.13.3):
- GoogleUtilities/Environment
- GoogleUtilities/Privacy
- GoogleUtilities/MethodSwizzler (7.13.3):
- GoogleUtilities/Logger
- GoogleUtilities/Privacy
- GoogleUtilities/Network (7.13.3):
- GoogleUtilities/Logger
- "GoogleUtilities/NSData+zlib"
- GoogleUtilities/Privacy
- GoogleUtilities/Reachability
- "GoogleUtilities/NSData+zlib (7.13.3)":
- GoogleUtilities/Privacy
- GoogleUtilities/Privacy (7.13.3)
- GoogleUtilities/Reachability (7.13.3):
- GoogleUtilities/Logger
- GoogleUtilities/Privacy
- GoogleUtilities/UserDefaults (7.13.3):
- GoogleUtilities/Logger
- GoogleUtilities/Privacy
- nanopb (2.30910.0):
- nanopb/decode (= 2.30910.0)
- nanopb/encode (= 2.30910.0)
- nanopb/decode (2.30910.0)
- nanopb/encode (2.30910.0)
- PromisesObjC (2.4.0)
- PromisesSwift (2.4.0):
- PromisesObjC (= 2.4.0)
DEPENDENCIES:
- FirebaseAnalytics
- FirebaseCore
- FirebaseCrashlytics
- FirebaseMessaging
- FLAnimatedImage (~> 1.0)
- FLEX
- GoogleMaps
SPEC REPOS:
https://github.com/CocoaPods/Specs.git:
- FirebaseAnalytics
- FirebaseCore
- FirebaseCoreExtension
- FirebaseCoreInternal
- FirebaseCrashlytics
- FirebaseInstallations
- FirebaseMessaging
- FirebaseRemoteConfigInterop
- FirebaseSessions
- FLAnimatedImage
- FLEX
- GoogleAppMeasurement
- GoogleDataTransport
- GoogleMaps
- GoogleUtilities
- nanopb
- PromisesObjC
- PromisesSwift
SPEC CHECKSUMS:
FirebaseAnalytics: ec00fe8b93b41dc6fe4a28784b8e51da0647a248
FirebaseCore: 7ec4d0484817f12c3373955bc87762d96842d483
FirebaseCoreExtension: 8a47811d0b155501559ef05d089518152a0a1677
FirebaseCoreInternal: 910a81992c33715fec9263ca7381d59ab3a750b7
FirebaseCrashlytics: 4b96efb0ce73b38b2a85e8b8bd1bd8f63f09d015
FirebaseInstallations: 91950fe859846fff0fbd296180909dd273103b09
FirebaseMessaging: 88950ba9485052891ebe26f6c43a52bb62248952
FirebaseRemoteConfigInterop: b25018791b204c0d78a90e394d6c62d9b1f22da8
FirebaseSessions: c0939656253a1fa0e94ecc266ccf770cc8b33732
FLAnimatedImage: bbf914596368867157cc71b38a8ec834b3eeb32b
FLEX: f21ee4f498eed3f8a1eded66b21939fd3b7a22ce
GoogleAppMeasurement: 9abf64b682732fed36da827aa2a68f0221fd2356
GoogleDataTransport: 6c09b596d841063d76d4288cc2d2f42cc36e1e2a
GoogleMaps: 032f676450ba0779bd8ce16840690915f84e57ac
GoogleUtilities: ea963c370a38a8069cc5f7ba4ca849a60b6d7d15
nanopb: 438bc412db1928dac798aa6fd75726007be04262
PromisesObjC: f5707f49cb48b9636751c5b2e7d227e43fba9f47
PromisesSwift: 9d77319bbe72ebf6d872900551f7eeba9bce2851
PODFILE CHECKSUM: 42c53e4a392cb267d7a102308db901173ee5a9df
COCOAPODS: 1.15.2
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
For the time being you can avoid constructing the dictionary if the FCM token is nil and log a non-fatal error manually through Crashlytics instead. If you manually implement the didRegisterForRemoteNotificationsWithDeviceToken, does it always execute before you construct the userInfo dictionary in HDLoginPresenter.m?
For the time being you can avoid constructing the dictionary if the FCM token is nil and log a non-fatal error manually through Crashlytics instead. If you manually implement the
didRegisterForRemoteNotificationsWithDeviceToken, does it always execute before you construct theuserInfodictionary inHDLoginPresenter.m?
-
I modified it to insert an empty string (””) into the NSDictionary when the FCM token is nil. However, what I want to understand is the fundamental reason why the FCM token is not being received. Because even though I prevented Crashlytics by inserting an empty string, if those users (who experienced the crash) do not run the app again, the push notifications will not be sent. (The userInfo is created as part of the process to save the FCM token on the server. If it is not saved on the server, push notifications will not be sent.)
-
I am implementing
didRegisterForRemoteNotificationsWithDeviceTokenin theAppDelegate, and there, I am notifying Firebase that the deviceToken has been issued using[FIRMessaging messaging].APNSToken = deviceToken;. According to the debugging results, the sequence of calls is as follows:- didRegisterForRemoteNotificationsWithDeviceToken
- didReceiveRegistrationToken
- userInfo created
umm... I have been continuously thinking about and debugging this error. Then I realized that the error occurrence date doesn’t matter.
I speculate that the fcmToken might have been intermittently coming as nil, but it was reported to Crashlytics because I added new code to create an NSDictionary using a singleton variable. (The updated version was uploaded on June 20th.) So, I discovered an issue that I hadn’t recognized before.
To summarize, the error occurred because I added code in HDLoginPresenter.m (refer to the description above), but the issue of fcmToken coming as nil has potentially been happening all along. The new code(of HDLoginPresenter.m) addition revealed this latent issue.
I am implementing didRegisterForRemoteNotificationsWithDeviceToken in the AppDelegate, and there, I am notifying Firebase that the deviceToken has been issued using [FIRMessaging messaging].APNSToken = deviceToken;. According to the debugging results, the sequence of calls is as follows: [...]
In didReceiveRegistrationToken:, can you also log a non-fatal if the token value is ever nil?
I am implementing didRegisterForRemoteNotificationsWithDeviceToken in the AppDelegate, and there, I am notifying Firebase that the deviceToken has been issued using [FIRMessaging messaging].APNSToken = deviceToken;. According to the debugging results, the sequence of calls is as follows: [...]
In
didReceiveRegistrationToken:, can you also log a non-fatal if the token value is ever nil?
I’m not sure if I understood @morganchen12 question correctly, but originally, I did not check for nil and directly assigned the value to the singleton’s variable. Since the variable type is NSString, it did not cause a fatal error. The error occurred later in the process when the singleton variable was assigned to an NSDictionary and it was nil.
In the revised code, if fcmToken is nil in didReceiveRegistrationToken:, it re-requests the fcmToken, and if it’s still nil, a custom error is logged to Firebase Crashlytics (the actual user won’t know about the error).
Although the nil check is done, is there a way to prevent fcmToken from being nil from Firebase in the first place? Due to this issue, some users are unable to receive push notifications.
I have discovered something new.
If it were a Firebase server issue, the same null value should occur on Android as well, but it only happens on iOS. Here are the reasons for this judgment:
Each time the app runs, it receives the fcmToken and saves it to the server only if it exists (the app crashes if it is null). However, at some point, we started getting file not found errors when sending push notifications from the server.
Although it is speculative, the occurrence frequency data is similar, and since the server checks whether it is iOS or Android, I reviewed the logs and found that it only happens on iOS. It seems to be an organically connected issue.
(Even before the code I uploaded in June, the app was set to crash if the fcmToken was null, but this issue started occurring recently, so there must be some changes or issues on the Firebase side.)
When the fcmToken is nil on an iOS device, an error occurs, preventing it from being saved to the server. In this case, the fcmToken stored on the server remains the previous (expired) fcmToken, leading to the problem.
Therefore, it seems to be an issue with the SDK rather than the API.
I understand that issues are closed after 7 days of inactivity… I want to update the SDK to the latest version and monitor whether null values still occur, but it is practically difficult to test with the app that actual users are using. So, I have safely added a logic to re-request the fcmToken after a null check (as mentioned in a previous comment). This seems to resolve the issue. We plan to release a new version soon, so I should be able to comment on whether the issue is resolved. If there are any additional updates, I will add them as comments.
I believe this is similar to what I am seeing.
pod FirebaseMessaging, '10.28'
What seems to be happening in my case:
- On first login of the application, we prompt the user to Allow Push notifications.
- If the player accepts push notifications, we utIlize the Firebase SDK to create a APNS token and then from that create a FCM Token.
- Now that we have the FCM token, we kill the application, and send a Test Message via Firebase Console.
- We receive the notification and can click it to enter the game.
- On repeat initialization of the FirebaseMessaging plugin we can verify that the users push notification status is "authorized"
- We then try to get the token from firebase again, and this time Firebase returns NULL/nil
- If we try to force the token and delete it, we also get NULL/nil on the deletion and again on the set.
- No matter what happens moving forward we cannot get a valid FCM token.
So the point here is that I cannot get a valid FCM token after the first success. There is definitely something wrong here, as it is working for Android, no problems.
I'm going to be downgrading the SDKs to see if a specific update introduced this issue.
@jeungeun0
I have discovered something new.
If it were a Firebase server issue, the same null value should occur on Android as well, but it only happens on iOS. Here are the reasons for this judgment: Each time the app runs, it receives the fcmToken and saves it to the server only if it exists (the app crashes if it is null). However, at some point, we started getting
file not founderrors when sending push notifications from the server. Although it is speculative, the occurrence frequency data is similar, and since the server checks whether it is iOS or Android, I reviewed the logs and found that it only happens on iOS. It seems to be an organically connected issue. (Even before the code I uploaded in June, the app was set to crash if the fcmToken was null, but this issue started occurring recently, so there must be some changes or issues on the Firebase side.) When the fcmToken is nil on an iOS device, an error occurs, preventing it from being saved to the server. In this case, the fcmToken stored on the server remains the previous (expired) fcmToken, leading to the problem. Therefore, it seems to be an issue with the SDK rather than the API.
There is a difference here betwen Android and iOS. Which can point to a Firebase server issue.
Android: FCM Token iOS: APNS Token then FCM Token.
I've been doing some testing on my application. It looks like when the Firebase SDK first boots and we prompt the user for Push Notification Prompt (approval) we get a valid APNS token, and then create a valid FCM token. However on repeat boots, the APNS token is returned as nil but the FCM token is still defined.
There were related changes in 10.19.0 and 10.20.0, so it would be interesting to see if going back to 10.18.0 makes a difference https://github.com/firebase/firebase-ios-sdk/blob/main/FirebaseMessaging/CHANGELOG.md
There were related changes in 10.19.0 and 10.20.0, so it would be interesting to see if going back to 10.18.0 makes a difference https://github.com/firebase/firebase-ios-sdk/blob/main/FirebaseMessaging/CHANGELOG.md
I went back to 10.11 same problem. 😞
The 10.6.0 change looks like the next earliest related SDK change.
Another possibility is a race condition in the app.
The 10.6.0 change looks like the next earliest related SDK change.
Another possibility is a race condition in the app.
Going back to 10.6 there is still an issue with the APNS token on repeat application boots.
I'm going to submit a ticket with Firebase. In my opinion this seems to point to a server side problem on their side 🤔
Has there been any update on this? Is there a version or work around? I am running into similar issue which has been a hinderance during app store submission.
Hi all, is this issue still occurring? Does upgrading to the latest Firebase major version resolve this?
Hey @jeungeun0. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.
If you have more information that will help us get to the bottom of this, just add a comment!
Since there haven't been any recent updates here, I am going to close this issue.
@jeungeun0 if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.