悩んだ末に、1年半以上付き合っていたFirestoreからSwiftDataに切り替えることに決めました
Firestoreで作り込んできた女性向けのアプリ。今更ながら、クラウド側にデータを置いていいのか非常に悩んでいる。
というのも、先日のWWDC2023でSwiftDataが出てきたからだ。
特に今、作ってるのは現行すでに公開済みのSeleneという女性向けのアプリで、主に私が妊活中に基礎体温を記録するためだけに作ったアプリ。
もう娘たちが無事産まれて、8歳と5歳になっているので、完全に用無しなんだけど、それはまた別記事で語るとして、今は完全にただの実験場である。
つまり、一回めの公開から8年くらいはすでに経っているわけだ。その間に技術は移り変わる。その度に移行してきた。公開までには至ってないけれど、実験場としていい教材だったのだ。
言語はObjective-CからSwiftに切り替え
フロント技術はUIKit+StoryboardからSwiftUIに切り替え
データ管理はRealmからFirestoreに切り替える前提で作り込んでいたタイミングで
SwiftDataの登場である。
女性向けのアプリは、当然、かなりセンシティブなデータになるので、クラウド側には持ちたくないというのがある。セキュリティ的な不安もあるし、何より個人アプリでなかなかその辺りのリスクを背負うには覚悟がいる。
とはいえ、FirestoreはGoogleが作っているものだし、正しく使えばセキュリティリスクは少なくなるでしょう。そして、NoSQLを使ってみたいという興味もあった。
ということで2年近く、本業の傍ら、細々と開発をしてきて、Firestoreの使い所もよくわかってきて、リニューアル公開できるまであと少し！！というタイミングで、やっぱりローカルデータ管理にして、SwiftDataを使おうかな。。という気持ちになってしまっているのである。
困りましたね。
まだ、正式公開されてないし（間も無くかな）、このタイミングで勉強しながら、やると、またあと半年かかっちゃうんじゃないのー？もうこのアプリ開発してるの飽きたわ〜〜〜とか思ってるのですが。ただの「女性向けの自分の記録をする」的なシンプルなアプリなのに、クラウド＆NoSQL＆リアルタイム反映データベースを使うのはオーバースペックだし、Readするだけでお金かかるしなぁー（微々たるものだけど）。みたいな気持ちになってる。
と、ここでSwiftDataと比較して、Firestoreを評価してみる。
Firestoreを使う場合のユーザーメリット
- Authenticationとの併用で、ログインさえできればユーザーは再度過去のデータにアクセスできる
- もしAndroid版を作った場合に、iOS⇄Androidのデータ移行ができるようになる。
Firestoreを使う場合の開発者メリット
- バグによって、何かデータの不整合が起きた時に、調査できて、こちらでリカバリしやすい。
- データ分析に活用できる（個人と分離した形で、全体の利用傾向は見たい）
Firestoreのリスクやデメリット
- Readだけでお金かかるので実装方法をかなり気にしなければならない。
- できるだけ無駄なReadをせずに今のUIを実現しようと思うと、かなり細やかなデータ制御を実装する必要がある。
- 結果として、リアルタイム反映のデータベースなのにその技術は全く使えなかった。リアルタイム反映にすると、UIがもたつくのである。。UIビューの作り方に問題があったかもしれないが。。
- そこそこ苦労して、上記の対応はほとんど終わっているが、リファクタした過程でバグが起こると、データ不整合が起きやすい。
- その辺りをカバーするのがセキュリティルールなんだろうけど、そこもすごい気を遣う
- 例えば、このアプリはデイリーごとで行う記録アプリなので、基本、同じ日付のデータを作らないという制約を設けたい。が、Firestoreはそれが簡単にできない。MySQLだとこの辺りは楽で、データベース側でカラムに対してユニーク制御を設けることができる。Firestoreでその辺りをやろうとすると、毎回保存時に、データ全件読んでチェックみたいなことを求められる。その都度全件分Read料金が加算されるという。データが増えれば増えるほど、加算される負荷。（いや、普通のことだとは思うんだけど。。）
- クラウドに保存するので、プライバシーポリシーしっかり書かないと。
- バックアップの仕組みも作らないと。
うーーーーん。やはりSwiftDataに切り替えるか。
とはいえ、どのみちRealmからのマイグレーションを考えなきゃいけないのである。あと半年がんばろ。
追記：ここで作業ログをまとめてます。
Discussion