Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[messaging][ios] APNs token type is inferred from DEBUG instead of the signed APNs environment

クローズ
  • 何か問題がありますか？
#9,348 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
56/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
firebase, ios, objective-c, react-native
領域
mobile

調査の方向性

Start in packages/messaging/ios/RNFBMessaging/RNFBMessaging+AppDelegate.m, where the APNs token type is selected from DEBUG. Read Firebase Messaging's supported unknown or autodetected APNs token behavior and determine how the signed aps-environment should drive the association. Done means Release builds signed for development no longer receive a production token type and FCM delivery succeeds.

索引モデルが issue の本文から書いたものです。

説明

Needs Attention type: bug

Issue

On iOS, @react-native-firebase/messaging currently determines the APNs token type from the DEBUG compilation macro in RNFBMessaging+AppDelegate.m:

#ifdef DEBUG
  [[FIRMessaging messaging] setAPNSToken:deviceToken
                                    type:FIRMessagingAPNSTokenTypeSandbox];
#else
  [[FIRMessaging messaging] setAPNSToken:deviceToken
                                    type:FIRMessagingAPNSTokenTypeProd];
#endif

This assumes that:

DEBUG defined     == APNs sandbox
DEBUG not defined == APNs production

However, the build configuration / DEBUG macro and the APNs environment of the signed application are independent.

A valid Release build can be signed using Apple Development provisioning and therefore have:

aps-environment = development

while DEBUG is not defined.

I reproduced this configuration on a physical iPhone.

Reproduction

Environment used for the runtime reproduction:

@react-native-firebase/messaging: 21.14.0
Firebase Messaging iOS SDK: 11.11.0
GoogleUtilities: 8.1.0
Xcode: 27.0
Device: iPhone 16e
iOS: 26.5

The application was:

Build configuration: Release
Signing: Apple Development
Signed aps-environment: development
DEBUG macro in RNFBMessaging: not defined
FirebaseAppDelegateProxyEnabled: not explicitly disabled

The signed application entitlement was verified from the built .app, rather than inferred from the Xcode build configuration.

With the standard RNFirebase AppDelegate integration, the RNFirebase callback therefore selected:

FIRMessagingAPNSTokenTypeProd

even though the signed application was using the APNs development environment.

After obtaining an FCM registration token, sending a real FCM notification resulted in:

HTTP 400
APNs error: BadDeviceToken
Control experiment

In an isolated diagnostic build I disabled the automatic proxy and explicitly associated the APNs token as sandbox as the initial association:

[[FIRMessaging messaging] setAPNSToken:deviceToken
                                  type:FIRMessagingAPNSTokenTypeSandbox];

I then deleted the existing FCM registration token and generated a new one after the correct APNs association.

Using the same physical device and Firebase project, FCM delivery then succeeded.

Multiple subsequent real pushes were successfully delivered.

This was only a diagnostic control; I am not proposing that applications should manually force sandbox.

Why this appears to be incorrect

DEBUG describes how the code was compiled. It is not the authority for the APNs environment used by the signed application.

The APNs environment is determined by the application's signing/provisioning and resulting aps-environment entitlement.

For example, this is a valid combination:

Release configuration
DEBUG not defined
Apple Development signing
aps-environment = development

In that case the current RNFirebase heuristic selects Production while the APNs token belongs to Sandbox.

Conversely, relying on DEBUG could theoretically produce the opposite mismatch for a build where DEBUG is defined but the signed APNs environment is production.

Expected behavior

The APNs token type should not be inferred solely from DEBUG.

It should instead be determined from the actual APNs environment of the signed application, or RNFirebase could potentially allow Firebase Messaging to perform its supported APNs environment autodetection rather than explicitly forcing Sandbox/Prod from the compilation macro.

For example, Firebase Messaging supports an unknown/autodetected APNs token type, although I am not prescribing a specific implementation.

Current upstream source

I originally reproduced the issue with RNFirebase 21.14.0.

I also checked the current main branch and the AppDelegate callback still uses the same #ifdef DEBUG distinction:

https://github.com/invertase/react-native-firebase/blob/dce165d7283a30060c5b08066cf5841d9247105a/packages/messaging/ios/RNFBMessaging/RNFBMessaging%2BAppDelegate.m

I have not repeated the physical-device reproduction against the current main branch, so the runtime reproduction described above should be considered specific to 21.14.0; the current-source observation is source inspection only.

Impact

This does not appear to affect the usual combinations:

Debug + development signing
Release + App Store/TestFlight production signing

because the DEBUG heuristic happens to agree with the APNs environment in those cases.

It can affect valid configurations such as:

Release + development signing

which may be used for internal testing, QA, physical-device testing, or Release-mode builds that need to run without Metro.

In the reproduced case, the user-visible effect was complete FCM push delivery failure due to BadDeviceToken.

主要言語
TypeScript
スター
12.3k
フォーク
2.3k
平均マージ
1日 16時間
マージ済み PR（30日）
23

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

invertase/react-native-firebase のほかの issue

invertase/react-native-firebase の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。