iOS Case Study
「バイブコーディングで速く作る」から始まり、通知信頼性・共有設計・運用コストまで向き合って、 カップルの毎日を支える実用アプリへ育てたプロジェクトです。2026年2月20日にv1.8をリリースしました。
Project Story
最初の版は「とにかく形にする」ことを優先しすぎて、起動直後に通知がうまく入らない、 共有中のデータ境界が直感的でない、という実使用で痛い問題が出ました。 そこで速度重視から方針を変え、使う人の不安を減らす改善を軸に作り直しました。
実装が速くても、信頼を失う体験を残せば意味がない。失敗を認めて原因を分解し、 「次に同じことを起こさない設計」に置き換えることが、リズムシェア開発で得た最大の学びでした。
Failure Journal
ログイン状態の更新とユーザードキュメント確認の順番が噛み合わず、まれに状態不整合が発生。
認証は「成功条件」と「失敗時の巻き戻し」を最初に設計すべき。
Sign in with Apple + Firebase Auth の状態遷移を整理し、失敗時は即座に状態をクリアする実装へ統一。
起動直後のタイミングで通知権限判定が追いつかず、通知が消えて再登録されないケースがあった。
通知機能は「権限確認」と「再スケジュール」を分離して守る必要がある。
スケジュール直前の再評価と、既存通知削除前のガードを入れて取りこぼしを抑制。
「共有中にどこまで編集できるか」が画面ごとに揺れて、ユーザーが混乱する箇所があった。
共有機能はUXより先に、権限制御のルールを一枚の仕様に落とすべき。
招待コード・解除・閲覧専用の境界を明示し、共有/非共有で操作可能範囲を統一。
シフト一括登録でデータ量が増えると、Firestore書き込み上限に近づく設計だった。
小規模リリースでも、増えたときの挙動を先に仕込まないと後で痛む。
WriteBatch上限対策を入れ、処理分割を前提にしたサービス実装へ変更。
Features
自分/パートナーの表示切替で、周期・予定・シフトを一画面で把握。
日常会話とコンディション共有を同じ導線に置き、行動までつなげる設計。
体調配慮タスクや大切な日を管理し、サポート行動を習慣化。
単発登録と期間展開を両立。夜勤またぎも含めて可視化。
自分向け/パートナー向けの通知タイミングを個別設定可能。
StoreKit 2 で月額プランを実装し、UXと収益化を両立。
Tech Stack
UIはナチュラルテーマを中心に設計。機能追加より先に、データ整合性・通知品質・共有時の権限制御を優先して改善しました。
Live App
実際の体験は本番アプリで確認できます。App Store公開版で、開発した改善内容をそのまま体感できます。