XCode12からの新機能のひとつとして、ローカル環境で課金（StoreKit)のテストをする環境が追加されました。 この記事では、そんなローカルで課金のテストをする方法を試しています。 はじめに XCode12からの新機能のひとつとして、ローカル環境で課金（StoreKit)のテストをする環境が追加されました。 StoreKit構成ファイルをローカルで作成し有効にすると、App Storeのサーバーに接続しないで課金のテストを実行することが出来ます。 今回はローカルで課金をしてみるまでの流れを簡単にではありますが試してみました。 具体的にどんなことが出来るようになったの？ Appleのサイトによると以下の項目が挙げられています。 開発の初期段階、またはApp Store Connectでアプリ内購入を構成する前に課金ができる。 ネットワーク接続が利用できない場合のローカルテスト。 San

In-App Purchasesの概要 In-App Purchasesとはアプリ内課金のことであり、アプリ内でプレミアムコンテンツや、デジタル商品、サブスクリプションなどの追加コンテンツをアプリ内で直接ユーザーに提供できます。 In-App Purchasesには、以下の４種類があります。 消耗型 非消耗型 自動更新サブスクリプション 非更新サブスクリプション 詳細についてはここを参照してください。 今回は自動更新サブスクリプションの実装方法について見ていきます。 (が他の種類の実装を行うにしても、基本的な考え方は同じだと思います。) 購入処理に必要な主なStoreKitのAPIについて アプリ内コンテンツの購入処理を実装する際、StoreKitというフレームワークを使用します。 まずはStoreKitが提供する主なAPIについて説明していきます。 SKProduct ユーザーに提供する

個人開発しているアプリ でサブスクリプションによる有料プランを提供しており、そのバックエンドにはFirebase(Authentication, Firestore, Cloud Functions)を使っています。 運用が難しそうな課金周りのバックエンドも、Firebaseで実現することでサーバー管理など不要で、個人開発でも安定してサービス提供できます。 今回はその大まかな実現方法とともに、個人開発でも意外と容易にサブスクリプション導入できることを紹介します。 尚、この記事は典型的な、有料プラン１種類のみ提供することを前提に書かれています。異なる種類・期間のプランを複数提供する場合は、アップグレード・ダウングレード・クロスグレードを考慮する必要があり、より複雑なものになります。 また、iOS以外の、WebやAndroidなどのプラットフォームで並行してサービスを提供する場合も、課金状態の