Life-Up — 習慣化アプリ

SUMMARY

概要

概要

毎日の小さな実践をクエストに変える習慣化アプリ。習慣を記録するとコインがたまり、そのコインでバディを育てます。

担当

企画・デザイン・アプリ・Webポータル・サーバー・決済・ストア公開・運営まで、すべて自社

技術

React Native（Expo）・React・Spring Boot・RevenueCat・Paddle・Kubernetes

Life-Upは、意志の力に頼らず「続ける理由」をつくるアプリです。タスクや習慣を記録するとコインがたまり、そのコインでバディを育てます。毎週更新されるマガジン、設定した時間に届くリマインダー、広告なしで使えるサブスクも入っています。小さなアプリに見えますが、性格の違う機能が5つ絡み合っているため、最初に決めた構造がその後の修正コストを左右しました。

判断 01

変わる速さで、サーバーを6つに分けました

課題

習慣の記録、バディ育成、マガジン、リマインダー、サブスクは、変わる速さが違います。マガジンは毎週新しい記事が載り、機能にもよく手を入れます。決済はほとんど変わらない代わりに、一度間違えるとお金の問題になります。1つのサーバーにまとめると、マガジンの画面を1か所直すだけで決済のコードまで配信し直すことになります。

選択

認証・習慣・ゲーム・マガジン・リマインダー・サブスクをそれぞれ別のサーバーに分け、その前にゲートウェイを1つ置きました。アプリとWebはゲートウェイのアドレスだけを知っていて、奥がどう分かれているかは知りません。配信もサーバーごとに自動化しています。

理由

直した部分だけを配信すればよいので、マガジンを直す日も決済サーバーには触れません。1つのサーバーに問題が起きても、ほかの機能は動き続けます。その代わり運用するサーバーが増えるため、お客様のアプリに最初からこの分け方をおすすめするわけではありません。機能の数と変わる速さを見て決めます。

判断 02

アプリ内課金とWeb決済を、1つのグレードにまとめました

課題

アプリの中でサブスクを販売するには、AppleとGoogleのアプリ内課金を使う必要があります。Life-UpはWebポータルでもサブスクを販売しています。2つの決済がばらばらだと、Webで支払った人がアプリを開いたときに無料会員として扱われ、広告まで表示されてしまいます。

選択

アプリはRevenueCatでApp Store・Google Playの課金を、WebにはPaddleを導入しました。両方から届く決済完了の通知をサーバーが受け取り、アカウントごとに1つのグレードにまとめます。両方ある場合は上位のグレードを使います。決済通知は、事前に取り決めた認証値があるときだけ受け付けます。アドレスさえ分かれば、誰でも「支払いが済んだ」と送れてしまうからです。

理由

どこで支払っても、同じ権利が得られるべきだからです。また、グレードを確認できないときは広告を出さないほうを選びました。無料会員に広告を1回出し損ねるより、お金を払った人に広告が見えるほうがずっと問題だからです。

判断 03

1つのコードで2つのOS、3言語は最初から

課題

iOSとAndroidを別々につくると、直すたびに2回直すことになり、時間がたつと2つのアプリが少しずつずれていきます。言語も同じで、画面の文字をコードに直接書くと、後から翻訳を加えるときにすべての画面を開き直すことになります。

選択

React Native（Expo）で1つのコードから両OSのアプリをつくり、最初の画面から文字を言語ファイルに分けて、韓国語・英語・日本語を同時に入れました。ストアの説明文、アップデート情報、マガジンの記事も3言語で出しています。

理由

どちらも、後から変えようとすると事実上つくり直しになる決定です。最初に決めておけば、海外公開をいつ決めてもアプリをつくり直す必要がありません。

RESULTS

結果物

• アプリiOS・Android、1つのコード（React Native・Expo）、韓/英/日
• Webポータルサブスク決済、アカウント管理
• サーバー機能別6つ（認証・習慣・ゲーム・マガジン・リマインダー・サブスク）＋ゲートウェイ、サーバーごとの自動配信（Kubernetes）
• ログインGoogle・Appleログイン、登録なしで使えるゲストモード
• 決済アプリ内サブスク（RevenueCat）＋Webサブスク（Paddle）を1つのグレードに統合
• リマインダー・マガジン設定した時間のリマインダー、3言語のマガジン（週1回発行）
• 公開App Store・Google Play。Appleの審査では、ログイン方式（4.8）、アカウント削除（5.1.1）、サブスク画面の規約リンク（3.1.2）、プロモーション画像内の価格（2.3.2）でリジェクトを受け、修正して通過しました。

お客様の案件では

サブスク・決済のあるアプリなら

アプリ内課金とWeb決済の両方を運用してきた経験を、そのまま活かします。どこで販売するか、別々に購入されたサブスクをどうまとめるか、決済通知をどう検証するかを企画の段階で決めます。

Appleが課金アプリで確認する点（サブスク画面の規約リンク、購入の復元ボタン、プロモーション画像）を提出前に点検し、リジェクトされたら修正して再提出するところまで追加費用なしで対応します。

サーバーをいくつに分けるかは、アプリの規模を見て決めます。小さなアプリなら、1つのサーバーで始めるほうが運用費を抑えられます。