wa/ri アップデート情報 2026/09
v2.06 で「1回のお会計を明細ごとに分ける」記録と、レシートを撮るだけの明細取り込みに対応しました。続く v2.07 では、記録を3章立てのPDFレポートとして残せるようにし、CSV/PDF の出力前に出していた広告をやめました。
続きを読む →
個人で割り勘アプリ wa/ri を作った。iOS / Android / Web / LINE(LIFF)の4プラットフォームに対応している。
マルチプラットフォーム開発といえば、まず出てくる選択肢は「Flutter一本化」だろう。工数を最小化できるし、ロジックも共通化できる。個人開発なら特にそのメリットは大きい。
でも、wa/riではあえてその選択をしなかった。
iOS は Swift(SwiftUI)、Android / Web は Flutter という構成にした。その理由と、その選択のトレードオフについて書く。
| プラットフォーム | 実装 | UIデザイン指針 |
|---|---|---|
| iOS | Swift / SwiftUI | Liquid Glass(Apple HIG準拠) |
| Android | Flutter | Material Design 3 |
| Web | Flutter(静的ビルド → nginx配信) | Material Design 3 |
| LINE(LIFF) | Webクライアントをそのまま再利用 | Material Design 3 |
Flutter一本化の最大のメリットは工数削減だ。これは間違いない。
ただ、wa/riを作るにあたって一番避けたかったのは「使い始めるハードルの高さ」だった。登録不要、連携不要、広告なし──構造的な気軽さを徹底的に追求したアプリで、見た目だけが「なんか違う」という状態にしたくなかった。
iOSユーザーはAppleのHIGに沿ったUIに慣れている。AndroidユーザーはMaterial Designに慣れている。Flutterで両方をターゲットにすると、どちらにも「ちょっとだけ違和感がある」UIになりやすい。
特にiOSは、iOS 26から導入された Liquid Glass に代表されるように、Apple独自のデザイン言語が非常に強い。FlutterはこのあたりのネイティブUIとの乖離が出やすく、「なんかAndroidっぽいな」という印象をiOSユーザーに与えてしまう。
wa/riではその違和感をなくすことを選んだ。
正直、工数は増える。ロジックを二重に持つわけではないが(後述)、UIの実装は完全に別物になる。
これを一人でやるのは、確かにしんどい部分もあった。
wa/riではフロントエンド側で極力計算をさせない設計を採っている。割り勘の計算ロジックはすべてバックエンド(NestJS)に集約されており、クライアントはAPIを叩くだけだ。
これがマルチプラットフォームとの相性が非常に良かった。
UIは分けたが、ロジックは一本化した。この構造のおかげで、「Swift + Flutter」という一見コストの高い選択が、現実的に成立している。
チーム開発や事業としてのプロダクトであれば、Flutter一本化が正解になるケースの方が多いと思う。
保守コストの分散、メンバーのスキルセット、リリーススピード──どれを取っても一本化に優位性がある。
ただ、個人開発で「自分が使いたいものを作る」という文脈では話が変わる。
wa/riはもともと自分用に作り始めたアプリだ。iOSネイティブのUIが好きで、その体験を犠牲にしたくなかった。それだけのことでもある。
Flutter一本化しなかった理由を一言で言うなら、「誰に何を届けたいか」を技術選定の軸にしたからだ。
工数削減より、ユーザーが感じる「自然さ」を優先した。その選択を支えたのは、ロジックをバックエンドに集約するという設計の工夫だった。
技術選定に絶対の正解はない。ただ、「なぜその選択をしたのか」を自分の言葉で説明できる状態にしておくことは、個人開発でも、チーム開発でも、たぶん大事なことだと思っている。
v2.06 で「1回のお会計を明細ごとに分ける」記録と、レシートを撮るだけの明細取り込みに対応しました。続く v2.07 では、記録を3章立てのPDFレポートとして残せるようにし、CSV/PDF の出力前に出していた広告をやめました。
続きを読む →9月公開予定の v2.06 では、1回のお会計を明細ごとに分けて記録できるようになります。さらに iOS / Android 版では、レシートを撮るだけで明細・日付・店名をまとめて取り込めます。外税や値引きの扱いまで含めて、実際の画面図つきで先にご紹介します。
続きを読む →3人で10,000円を割ると3,333.33円。端数を誰が持つか、立て替えが何件も混ざったときに誰が誰へいくら払えばよいか。実際の計算手順と、精算回数を最小にする考え方をまとめました。
続きを読む →