• 戻る（その他、開発の色々）

下記リンク先に記載。

移行メモ（Xamarin はサポート終了）: Xamarin は
2024 年 5 月 1 日にサポートが終了した。
現在の .NET でのモバイル GUI 開発は
.NET MAUI（Xamarin.Forms の後継）が公式の手段である
（ネイティブ vs クロスプラットフォーム）。

【.NET でのモバイル GUI の選択肢（現在）】
   ・.NET MAUI                … 公式。単一プロジェクト構成 ★
   ・.NET MAUI Blazor Hybrid  … UI を Blazor で書く（Web と共有）
   ・[Uno Platform](MS_UnoPlatform) … XAML。Web/デスクトップも
   ・Avalonia                 … XAML。デスクトップ中心

Android では FCM を、iOS では APNs を使用する。

• FCM は APNs と連携可能なので、ココでは、FCM との連携手順を書く。

• コードを見ると、APNs へのプッシュ通知の実装は難易度が高そう。

• FCM 経由にすると APNs の複雑さも、サーバー側でブラックボックス化される。

補足（この判断は今も正しい）: 「FCM 経由にすると APNs の複雑さが
ブラックボックス化される」——この設計判断は妥当である。
なぜ APNs が難しいのかを補っておく。

【APNs（Apple Push Notification service）が難しい理由】

 ① 【証明書または認証キーの管理】★
     ・p12 証明書方式： 【年 1 回の更新が必要】。失効すると通知が止まる
     ・p8 認証キー方式（現在の推奨）： 失効しない。Team ID / Key ID が要る

 ② 【環境が分かれる】
     開発（sandbox）と本番でエンドポイントが違う
     → 「開発では届くのに本番で届かない」の典型的な原因

 ③ 【HTTP/2 が必須】（旧バイナリ プロトコルは廃止済み）
     → クライアント ライブラリが HTTP/2 に対応している必要がある

 ④ エラーの扱いが独特（トークン失効の検出など）

【FCM 経由にすると】
   ・Firebase 側に APNs の認証キーを登録しておけば、
     アプリからは【FCM の API だけ】を叩けばよい ★
   ・Android / iOS を【同じコードで】扱える
   ・トークン管理も統一される

一方、FCM 経由の代償も押さえておく。

・Google のサービスに依存する（障害・仕様変更の影響）
・中国本土の Android 端末では Google Play 開発者サービスが
  使えないことがある ★
・通知の遅延が APNs 直よりわずかに増える
・Firebase の利用規約・データの所在（データ主権）

フロントエンドの手順は、

• プラットフォーム毎に別々になる。

• 詳しくは、個々のフロントエンドの項を参照。

  • Cordova
  • Flutter
  • , etc.

• ここでは、.NET で実装する、サーバ側の実装について言及する。

• 必要なパッケージを NuGet からインストール（FirebaseAdmin）

• FCM のコンソールから秘密鍵
  （serviceAccountKey.json）をダウンロード

• プッシュ通知のプログラムを実装する。

  • 秘密鍵を読む
  • メッセージの作成・指定
  • トークンの指定
  • プッシュ通知の送信

※ トークンは、ネイティブ・アプリのインストール時に生成される。
　従って、サーバは事前に、このトークンを入手しておく必要がある。

補足（実装例と、運用上の要点）: 手順は正確なので、
コードと注意点を補う。

// NuGet: FirebaseAdmin
FirebaseApp.Create(new AppOptions
{
    Credential = GoogleCredential.FromFile("serviceAccountKey.json"),
});

var message = new Message
{
    Token = deviceToken,                       // ← 端末ごとのトークン
    Notification = new Notification { Title = "件名", Body = "本文" },
    Data = new Dictionary<string, string> { ["orderId"] = "12345" },
};
var id = await FirebaseMessaging.DefaultInstance.SendAsync(message);

① 秘密鍵（serviceAccountKey.json）の扱い★

【これは極めて機微な情報である】
   ・持っていれば【誰にでも通知を送れる】
   ・Firebase の他の機能にもアクセスできうる

【やってはいけない】
   ・リポジトリにコミットする
   ・アプリと一緒に配布する（クライアントに置かない）

【正しい置き場】
   ・【Key Vault / Secrets Manager】★
   ・マネージド ID（Google なら Workload Identity）
   → [*.configの暗号化](MS_ConfigEncryption) /
     [FaaS config](MS_FaaSConfig) と同じ指針

② トークンの管理が実務上の主要な課題

【トークンは変わる】★ 原文の※の補足
   ・アプリの再インストール
   ・端末の初期化
   ・一定期間の未使用
   ・アプリ データの削除
     → 【古いトークンに送ると失敗する】

【設計】
   ・アプリ起動時に毎回トークンを取得し、サーバへ送る
   ・サーバは【ユーザー × 端末】でトークンを保持する
      → 1 ユーザーが複数端末を持つ
   ・送信結果が Unregistered / InvalidArgument なら
     【DB から削除する】★
      → 溜め込むと、送信のたびに無駄なエラーが積み上がる
   ・ログアウト時はトークンを無効化する
      → しないと【他人の端末に通知が届く】（情報漏洩）★

③ 通知の内容に個人情報を入れない

【ロック画面に表示される】ことを前提にする
   ✗ 「田中様の検査結果が出ました（陽性）」
   ○ 「新しいお知らせがあります」＋ data で ID だけ渡し、
      アプリを開いてから API で取得する ★

④ 大量送信

・FCM には【マルチキャスト送信】がある（最大 500 トークン/回）
   SendEachForMulticastAsync
・トピック配信（購読者全員へ）も使える
・レート制限・リトライ（指数バックオフ）を実装する
・【送信は非同期のバックグラウンド処理にする】★
   → Web リクエストの中で同期送信しない

OTA アップデートをサポートするためのプラットフォーム

移行メモ（CodePush / App Center は終了）: Microsoft の
Visual Studio App Center は 2025 年 3 月 31 日にサービスを終了した。
App Center 上で提供されていた CodePush も同時に終了している
（Visual Studio App Center）。

【現在の代替】
   ・React Native  → 【Expo Updates】、またはセルフホスト版 CodePush
   ・Capacitor     → Capacitor Live Updates（Ionic Appflow）
   ・.NET MAUI     → 【OTA の仕組みは標準にない】★
                      → ストア経由の更新が基本

【留意点】（[ネイティブ vs クロスプラットフォーム](MS_NativeVsCrossPlatform) にも記載）
   ・OTA でアプリの主要な機能を変えることは
     ストアの規約上リスクがある
   ・バグ修正・コンテンツ更新の範囲に留める

• C#でFCMを利用してPUSH通知を送信する方法 - 備忘録
  https://kagasu.hatenablog.com/entry/2019/09/04/141424

• NuGet Gallery | FirebaseAdmin
  https://www.nuget.org/packages/FirebaseAdmin/

• iOS の Push 通知 のサーバー側を ASP.NET Web API で - miso_soup3 Blog
  https://miso-soup3.hateblo.jp/entry/20130513/1368452204

• MitsuoMasuda/APNS: C#でiOSのプッシュ通知を実行するプログラム
  https://github.com/MitsuoMasuda/APNS

移行メモ（APNs の参考リンクは古い）: 挙げられている 2 つは
2013 年頃の記事であり、
当時の「バイナリ プロバイダ API」は 2021 年に廃止されている。
現在 APNs へ直接送るなら、
HTTP/2 ベースの Provider API + p8 認証キーを使う。

// 現在の APNs 直送の骨格（HTTP/2 + JWT）
var jwt = /* p8 キーで ES256 署名した JWT（Team ID / Key ID） */;
var http = new HttpClient { DefaultRequestVersion = HttpVersion.Version20 };
var req = new HttpRequestMessage(HttpMethod.Post,
    $"https://api.push.apple.com/3/device/{deviceToken}");   // 本番
//  https://api.sandbox.push.apple.com/... ← 開発（環境の違いに注意）★
req.Headers.Add("authorization", $"bearer {jwt}");
req.Headers.Add("apns-topic", "com.example.myapp");
req.Content = JsonContent.Create(new { aps = new { alert = "本文" } });

とはいえ、原文の判断どおり
FCM 経由にする方が実装・運用とも容易である。

• iOS (APNs)
• Android (FCM)

• .NET MAUI とは
  https://learn.microsoft.com/ja-jp/dotnet/maui/what-is-maui
• App Center の廃止
  https://learn.microsoft.com/ja-jp/appcenter/retirement
• Azure Notification Hubs
  https://learn.microsoft.com/ja-jp/azure/notification-hubs/notification-hubs-push-notification-overview

補足（Azure Notification Hubs という選択肢）: .NET 開発者向けに
補足しておく。

【Azure Notification Hubs】
   APNs / FCM / WNS 等を【まとめて抽象化する】マネージド サービス
     ・複数のプラットフォームへ 1 つの API で送れる
     ・タグによるセグメント配信
     ・大量配信のスケーリングを担う
     ・【トークンの管理を任せられる】★

【FCM 経由との比較】
   FCM 経由           … Google に寄せる。無償。実装が単純
   Notification Hubs  … Azure に寄せる。有償。大規模・多媒体向け

 → 既に Azure を使っており、大量配信が要るなら検討に値する

---

Tags: 移行, プログラミング, ASP.NET, ASP.NET Web API, ASP.NET SPA, JavaScript