自分は普段会社員をしていますが個人でもアプリ開発を行っています。
話題の技術Firebaseですが、凄い凄いといってもなかなか事例を晒している事が少ないので晒してみます。
この記事はあくまで経験のシェアです。個人開発の為失敗もたくさんできました。
設計や作り方がお手本になるかは別です。
なぜ晒そうと思ったのか？
このアプリは絶対いけると思った。思いのほかダウンロード数が伸びずこのままゾンビ化するなら検体として世に出した方が役に立つと思った。あとは単純にFireStoreの布教活動をしたかった。本当に便利なので。
アプリの概要
底値帳アプリ ソコネオ
https://itunes.apple.com/jp/app/みんなで作る底値帳アプリ-ソコ/id1120010427?mt=8
コツコツお店の価格を入力して最安値を管理するアプリ。
商品はバーコードから読み込めるのでとっても簡単。
コツコツ入力した価格をみんなで共有する。
底値の共有が可能で、全国の底値を簡単に調べることができる。
例えばカップヌードルが日本で一番安い店を調べることが可能。
地図のUIでお店の価格が見ることが可能。
超画期的と自分は思っている。
そう自分の中ではな。
開発チーム
個人プロジェクトでリリースまで友人のアプリエンジニア2人で作りました。
自分は全体の設計と企画、デザインとDB、iOSアプリ全般
相方はiOSの地図や共有周りの実装
初めは会社みたいにチケット作ってコードレビューみたいな事やってたのですが
相方の能力が高い上開発スピードがはやいのでコードレビューに時間がかかってしまい
無駄だったので自由に開発するスタイルにしました。ペアプロしたり楽しかったです。
gitの管理: Bitbucket
チケット管理: Jooto
Wiki: GoogleDocs
コミュニケーション: Slack
使用したFitebaseの機能
Firebase Authentication
Firebase Realtime Database
CloudFireStore （2019年現在）
Firebase Analytics
Firebase Crash Reporting
Firebase Cloud Storage
Firebase Notification
Firebase Cloud Messaging
Firebase Cloud Functions
ほぼ一式
使用したライブラリ / API
ライブラリ
SVProgressHUD
ObjectMapper / SwiftyJSON (現在はCodable(Decodable)へ)
SDWebImage Nuke
Realm
RxSwift (削除 FireStore使ってたらいらないw)
Google-Maps-iOS-Utils
API
GooglePlaceAPI
設計
Cocoaに則り基本的に
https://developer.apple.com/library/content/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html
MVC
6年ほど iOSアプリを開発してきてとても多くの現場を見てきた個人的な意見ですが
Appleの設計に乗っかるのが一番です。
ここ2年くらいはMVVMなど見てきましたが非常に辛い現場が多くやはりApple公式の設計がやってて楽しい。これに尽きます。
ということでCocoaのMVCで作り始め現在はMVP
具体的な数字
リリース半年序盤は調子良かったのですが....
総DL数 5000 現在10000
1日のDL数
10〜20😭かわらず(´；ω；｀)
おかげさまで日/100DL🎉
1週間のコホート リテンション30%前後
総評: 頑張りが足りない
ようやく軌道に乗り始めた
Firebaseの維持費について
現時点でユーザー数はMAUは2200程度
DAUで600-800 (平日と土日の差が激しい)
MAU 10000
Firebaseのプランは無料プラン
まだ余裕あり
他のアプリはわかりませんがこのアプリの作りの試算だと
DAU3000
MAU18000
くらいまで無料でいけると思います。
安い！！！
経験上MAU1万で10万くらいの収益にはなっていると思うので
非常にコストパフォーマンスは優れていると感じました。
このアプリの収益について
月間で
課金2000 ~ 8000円程度
広告1000 ~ 3000円程度（AdMob/nend）
月に約1万円
お小遣い程度😭
時給に換算すると数百円でしょうか。
得たノウハウはプライスレス!
Firebaseはお勧めできるか？
本当にオススメ。運用に関わるランニングコストが圧倒的に安く済む。例えスケールアップしたとしてもローカルのDB連携が秀逸な為、通信コストは低くなります。MAU20万規模でも大した金額にならない。因みにMAU20万は経験上80万DL相当。
10年先わざわざバックエンド言語と分けて設計するとか無くなってるかも。サーバーレスの時代来た。
本当に煽りぬきでこのアプリのような作りだとバックエンド言語は必要ないと思いました。
自分は以前PHPでAPI周りは書いていたがFirebaseに出会ってアプリ作るのに、もうそんな時代じゃないと感じた。
Javascriptでも実装が可能なのでますます普及しそうです。
企業は導入できるのか?
ありだと思います。むしろ入れてほしい。
エンジニアの学習コストも運用コストも抑えられる。
ただし既存のサービスがある場合は検討が必要。
Firebaseで困ったこと
周知の通り、全文検索や空間検索は基本的にはできません。algoliaというサービスやRealmを使用する必要があります。
https://www.algolia.com
設計に慣れるまで大変。
Googleも公認のサービスなので安心して使えるが
有料って事も頭に入れておく必要がある。
うまくやれば無料でいける。
MySQLなどのRelationalDBの設計思想は捨てなければなりません。
Firebaseで失敗した事😇
FirebaseDBの設計全般
現在の形になるまで稼働しているにもかかわらず2回作り直しています。
作り方には知識が必要で、
https://qiita.com/1amageek/items/64bf85ec2cf1613cf507
のようなクセのある設計を学ぶ。
Pringとかどうなの？
非常に素晴らしいライブラリです。しかし細かいパフォーマンスチューニングや実装などを行う場合注意が必要です。
ちなみにヘルパーはCodableFirebaseしか導入していません。
画像容量の節約施策
アプリで使用する画像はFirebase Cloud Storageで管理しています。
画像のサイズはちょっと小さめ程度に適当にやっていたらなかなかな容量になり、はじめからきちんと圧縮しておけばよかったなと。
圧縮率は低めで解像度も劣化がないかどうかをギリギリまでプレビューしながらやり込む事が大切。
このような素晴らしい記事があります。
https://techlife.cookpad.com/entry/2018/11/02/100000
プッシュ通知をきちんとニュースのViewと連動させることの大切さ
プッシュ通知とニュース情報の連動はリリースと同時に作って置くべきです。特にuserpropertyは最初に設定しておかないとユーザーのsegmentが思い通りになりにくくなります。入れておかないとユーザーを簡単に操作できるので後々グロースハックする時に後悔します。userpropertyも多種多様になることがわかっていればトピックでFCMを使用すべきです。
FirebaseUIの闇
FirebaseUIのAuthを使用したボクの感想ですがまだ入れるべきではないと感じました。
理由としてカスタマイズに癖があり、結局Viewを作ったりしていたら余計に手間が増えた。
アイデア次第では使いみちはありそう。
データ使用量・転送量の節約について
作りながら容量を確認しないと大変なことになります。
特にリレーションする部分、ｌoopが乱立すると思うのでしっかりテストを書いておく必要があります。
現在の問題点
開発からデザイン・グロースハック・運営を一人で行っているので機能が多くバグが潰しきれない。
他のアプリも運用しているので手がまわらない。
最大の敵はbuild時に空いた時間でやってしまうソシャゲです。最悪ソシャゲにハマり運用を怠るとという自体に陥ってしまいます。
このアプリにバグが残っている原因はFFBEです。（完全に言い訳です）
自分でも全然完璧だと思っていない。修正したいところはたくさんある。
誰か一緒に作りましょう。趣味で楽しく。
それでも1ヶ月に一度はゆるく更新しています。
CloudFireStoreどうなの
現在はCloudFireStoreで作られている
実はもう新しいアプリを開発中で3月にリリースします。
感じたことはかなり良くなってる。
DBの設計が楽になった。リレーションする時に独特なテクニック・知識がいらない。
現時点の欠点はdefaultの機能だとModel内配列property全文検索がやはり厳しい戦い。
頑張ればできる。頑張れば。
ソコネオも来年あたりお引越ししたい。
これから作るにはFireStore一択。
最後に一言
本年もお世話になりました。また新年もどうぞよろしくお願いいたします。