今年10月に恋するAIのサービスを終了することになりました。
この記事ではサービス終了にあたってアプリで対応したことと、審査に苦戦した話を紹介します。
サービスについて
恋するAIとは記憶するAIパートナーとのチャット・会話を楽しむことができるアプリです。
2024年10月をもってサービスを終了することになりました。
アプリの詳しい技術構成についてはこの記事では触れないため、チームメンバーが書いたこちらの記事を参照ください。
https://developers.cyberagent.co.jp/blog/archives/46393/
サービス終了にあたって対応したこと
サービス終了にあたっての対応はビジネスサイドのメンバーを中心に内容、スケジュール、意思決定者、担当者を記載したチェックリストを作成し、都度メンバーで確認をしながら進めました。
アプリ内では段階的に下記の対応を行いました。
1. サービス終了の告知を行う（終了2ヶ月前）
サービス終了の告知をアプリ内, X等で告知しました。
2. アプリ内で常にサービス終了ダイアログを表示する
アプリ起動時に常にサービス終了ダイアログを表示し、強制アップデートを有効にしました。
AppStore上で配信が停止された後でもインストール済みのユーザーは引き続きアプリを利用できてしまうため、常時メンテナンス状態にしました。
3. AppStoreでの配信停止
AppStore Connectの配信状況から配信を停止することで24時間以内にAppStoreから削除されます。
4. 各種ツールの削除
- Firebaseのプロジェクト削除
- XcodeCloudのワークフロー無効化
- GitHub Repositoryのアーカイブ
- 不要になった証明書の削除
etc...
配信停止後に利用していたツールなどの整理を行いました。
リジェクトされた話
アプリ起動時に常にサービス終了ダイアログを表示するようにし、最後のアップデートを審査に提出しました。
しかし、下記のガイドラインに抵触してしまい、リジェクトされてしまいました。
- Guideline 4.2 - Design - Minimum Functionality
We continue to found that the usefulness of your app is limited by its minimal amount of content or features.While we understand that you want to decommission the app, the current app should continue to provide some lasting functionality as long as it is available on the App Store.
Next Steps
It would be appropriate to revise your app so that users can continue to use your app after the message redirecting them to the new version appears.
Resources
Learn more about our policies for apps with minimum functionality.
https://developer.apple.com/app-store/review/guidelines/#minimum-functionality
- ガイドライン4.2 - デザイン - 最小限の機能性
アプリの有用性は、最低限のコンテンツや機能によって制限されることが分かっています。アプリの廃止を望んでいることは理解しますが、現在のアプリはApp Storeで入手可能である限り、ある程度の永続的な機能を提供し続けるべきです。
次のステップ
新バージョンへのリダイレクトメッセージが表示された後もユーザーがアプリを使い続けられるよう、アプリを修正するのが適切でしょう。
リソース
最低限の機能を持つアプリに関するポリシーの詳細については、こちらをご覧ください。
https://developer.apple.com/app-store/review/guidelines/#minimum-functionality
そこでiOSDC Japan 2023でのGO株式会社の登壇事例を参考に、サービス終了日以降はメンテナンスと同じ状態にすることで、配信停止後にインストール済みのユーザーがアプリを利用できないようにしました。
恋するAIではアプリ内の機能をFirebaseを活用して実装しており、強制アップデートやメンテナンスの機能はFirebase Remoteconfigを利用して運用していました。
しかし今回は
- 配信停止後にFirebaseなどの外部ツールを削除したい
- 停止以前にインストールしていたユーザーがアプリを使えないようにする
という2点を満たすために、サービス終了の告知に関してはアプリ内完結する形で実装しました。
こうして無事に審査を通過し、最後のリリースを終えました。
反省点として、先述した事例のようにメンテナンス等の緊急性の高い機能については実現しておくとスムーズに対応できたのではないかと思います。
最後に
エンジニアとして初めてリリースから終了まで関わったサービスであったため、サービス終了に際してユーザーの皆様から多くの暖かいレビューをいただけて嬉しかったです！
また、改めてサービスの将来を見据えた設計の重要性を感じました。
この記事が今後サービス終了に立ち会う際の参考になれば幸いです。ご覧いただきありがとうございました。