SwiftUIアプリを24時間で作ってリリースするひとりハッカソンの結果報告

2019年はSwiftUI誕生の年

2019年のSwiftUIの発表はたいへんインパクトがありましたね！ Objective-CからSwiftへの変遷と同様に、ここ数年で間違いなくSwiftUIがiOSアプリ開発のスタンダードになるものと思います。

いっぽうでSwiftUIはまだまだ機能不足、情報不足で実際にリリースする案件に適用するには心許ないというのが2020年1月時点での現状です。特に自社のメインサービスやクライアントワークでSwiftUIの導入を決断をするのはなかなか難しい時期かもしれません。

また次の6月のWWDCでアップデートが発表され状況は変わってくると思いますが、それを待つのも…

ということでハッカソン

ということで、冬休みにひとりでハッカソンを実施して、

• 24時間でSwiftUIでiOSアプリを開発して
• AppStoreでリリースする

ところまでやる！ということにしました。

自分で勝手に企画して出すアプリですのでSwiftUIを使っても誰にも文句は言われません！

必須利用技術

このハッカソン企画での必須利用技術は、

• SwiftUI
• Firebase（Firestore）
• Sign in with Apple

の３つとしました。

SwiftUI はもちろんですが、ローカルオンリーで動作するアプリだとSwiftUIの検証には弱いかなと思い、サーバにデータを保管するようにしバックエンドには Firebase(Firestore) を利用することにしました。 また、SwiftUIを採用する時点でターゲットOSがiOS 13以降になるので、ついでにiOS 13の新要素 Sign in with Apple でのSign inを実装することにしました。

リリースの定義

今回はゴールであるリリースの定義を、

• アプリを開発し終えて
• AppStore用のメタデータやスクリーンショットを作って投稿して
• 実際に審査に出す

ところまで、としました。

作るアプリ

作るアプリはちょうど自分が欲しいと思っていた「こどもたちのお金を親が管理するアプリ」にしました。

Photo by Michael Longmire on Unsplash

解決したい課題

我が家ではこどもたちにお金の教育を兼ねて毎月おこづかいを渡しているのですが、

• 先月のおこづかい渡したっけ？渡してなかったけ？とよくわからなくなる
• お年玉が高額で幼稚園児に管理させるのが不安（かといって子供の銀行口座を作るのは面倒）
• 弟が姉の貯金箱を漁る事件が発生！
• お店でこどもが「おこづかいでこのおもちゃ買いたい！」という時におこづかいを持ってきていない
• ○○カメラでおこづかいでおもちゃを買わせたいが、ほんとは〇〇カメラのポイント使っちゃいたい！
• ほんとは余っている〇〇Payで支払いたい！

など様々な悩みが出てきました。

解決するための機能

これらを解決するためには、

• こどもに現金を持たせないで親が残高だけ管理すれば十分
• 記録さえ残せば、親の財布が銀行代わりで、財布から出金、財布に入金でかまわない
• 入金、出金の記録は親もあとから削除・修正できないようにして証拠として残せばこどもも安心
• 普段使いの少額の現金はその残高から出金してこどもに渡せばOK
• おこづかいを使う時は親の財布から出金すればよいので〇〇カメラのポイントも○○Payもクレジットカードも使い放題！

と考え、シンプルに親のアプリでこどものおこづかい残高を管理するのがよいと仮定しました。

24時間で実装する機能

こういったアプリを作るうえで欲しい機能はいろいろと浮かんだものの、慣れないSwiftUIを使って24時間となるとだいぶ機能を絞る必要があると思い、

• こどもは複数人管理できる
• おこづかいやお年玉などを手動入金できる
• こどもが使った額を出金できる
• Sign in with AppleでSign inできる
• Firebase上に残高と履歴を保存できる

を必須機能としました。

先送りにする機能

いっぽうで、以下のアイデアはハッカソンが終わった後に、また時間があるときに実装することにしました。

• こども用のView専用のアプリもつくる
• こども用のViewではお金をお札やコインとして触れるUIをつける（幼稚園児でも残高を理解しやすいように）
• おこづかいをスケジューリングして自動入金させる
• 入金や出金を関係者にプッシュ通知する

ハッカソンの結果

まず24時間でリリースをできたかという結果ですが、無事にリリースできました！

https://apps.apple.com/app/id1494070556

リリースしたアプリ

だいぶ簡素なものですがこんな画面遷移です。 今回は、ひとりハッカソンとして、1人で24時間限定で開発し、弊社UIデザイナーも関わっていませんので、弊社のアウトプットがこのレベル、というみかたはしないでくださいね！！

画面遷移だけでは分かりませんが、サーバ上のDB（Firestore）が更新されれば、どの画面の要素もリアルタイムに自動更新されるようになっています。

SwiftUIで開発/リリースをしてみた所感

SwiftUIでスピーディに開発できる？

まず私のこの時点での知識と経験では、従来どおりのUIKitベースでの開発のほうがだいぶ速く開発できます。UI部分の開発は従来のやりかたの2倍以上かかってしまったかもしれません¹。

ただし、これには 現時点では という前置きが必要です。SwiftUIは現時点では、

• 私本人にもネット上にも知見が少ない
• SwiftUI自体にも機能として足りないと感じる部分がある

というのがあり、そこで時間がかかってしまっています。しかしこれらは、いずれもここ2年程度で解決されていく話と考えています。 感覚としては、Swiftが発表された年のObjective-CとSwiftの関係に近いと思います。

SwiftUIのどこがよかった？

ひとことで言えば「ぼくがなにも考えずに作っても勝手に良い感じの構成になってくれた」という印象です。

今回、設計などほとんど考えずに手なりで１画面ずつ作っていきました。結果として、

• チュートリアルどおりにViewにState（プロパティ）をおいたら勝手にリアクティブに更新される画面
• PreviewありきでViewを作ったらデータが勝手に差し替え可能

になりました。

前者はSwiftUIの売りの部分なので当然ですが、後者は意図せずそうなったので感心してしまいました。

実際に今回のハッカソンでは、最初にFirebaseにまったく触れない状態でローカルデータ（ただのメモリ上の配列です）だけで全画面を作りました。そしてそのあとViewはいじらずに裏側だけFirebaseに繋ぎ込みをするよう作り替える、という順番で開発をしました。おおむねスムーズに作り替えができたと思います²。

ダークモードやDynamic Typeも勝手に対応

これも特に意識していたわけではないですが、WWDCでの発表どおりSwiftUIでプレーンにアプリを作ったら、

• ダークモード
• Dynamic Type（フォントのサイズ変更）

にも勝手に対応されていました。

ダークモードに関しては本当に全く手を加えていません。

Dynamic Typeについては文字を大きくしてみたら一部の画面でレイアウトが崩れたので３０分程度で手直ししました。

SwiftUIはいつから使うべき？

2020年1月時点ではまだ人柱感が強すぎます。2020年の6月のWWDCでのアップデートでだいぶ実用的になってくれるのではと期待しています。

逆に2021年の6月のWWDCのアップデートあたりで誰もが使っても良い、と思えるくらいになっていそうです。そうなってしまうと、その頃には従来のUIKitベースでの作り方が負債と感じてしまうかもしれません。

2020年から2022年初めまでが移行期で採用の判断が難しい時期になりそうです。

それ以降はSwiftUIがスタンダードな世界になっていると予想しています。

実装面の話題

たいへんシンプルなアプリなので、この記事ではその他実装面の話題については書きません。

場合によっては、別の記事で実装面の具体的な話（といっても入門レベルの内容になりそうですが）を書いたり、このアプリを題材として機能追加するときに使う要素技術の話題なども書かせてください。