見出し画像

なぜ設立2年のNOT A HOTELはiOSアプリ開発でSwiftUI×TCAを採用したのか？

Yusuke KUROIWA / きんちゃん。

こんにちは、NOT A HOTEL という設立2年のスタートアップでソフトウェアエンジニアをしている、きんちゃん。(@wa_kinchan)です。

NOT A HOTEL は、建築とテクノロジーの力で「世界中に自宅がある、あたらしい暮らし」をつくるため、ボタンひとつで自宅にもホテルにもなる建物を空間の設計から建築、それを実現するためのソフトウェアやハードウェアの開発をおこなっています。また、「新しい暮らし」をすべての人に届けるための FinTech 領域にも取り組んでいます。

COMPANY DECKより

※詳しくは COMPANY DECK や他メンバーの note をご覧ください。

わたしは、もともと iOS エンジニアをしていましたが、現在 NOT A HOTEL の中では、後述の4つのソフトウェアプロダクト開発全般を、横断的に携わっています。

少人数で様々なプロダクトを並行して開発している最中で、今回は NOT A HOTEL での iOS アプリ開発について説明します。他プロダクトについても note で発信していく予定です。

現在、社員の中に iOS をメインとするエンジニアがおらず、絶賛 1 人目の iOS  エンジニア募集中です。


NOT A HOTEL がつくるソフトウェア・プロダクト

CTO @okbtks の note 「NOT A HOTELでソフトウェアエンジニアがつくるもの」でも触れられていますが、わたしたちが現在取り組んでいるのは、主に下記4つのプロダクトです。その中で「オーナー・ゲスト向けアプリ」「ホームコントローラー」「エントランスアプリ」については、iOS アプリを開発しています。

開発中のソフトウェア・プロダクト

例えば「ホームコントローラー」は、空調や照明、床暖房を始め、サウナやエレベーターなどの制御も、タブレット 1 枚でハウスの機器をすべてコントロールできるようなアプリになります。
スマートホームの実現は、わたしが入社したきっかけでして、非常に魅力的なUXを兼ね備えた iPad Pro 12.9 inch で動作する統合型コントローラーアプリの実現にあたり、必要なプロトコルをかなり踏み込んで理解してきました。

ホームコントローラーの UI イメージ

iOS アプリ開発のチーム構成

現在は、3 名の iOS エンジニアと社員のわたしで開発を行っており、3名とも業務委託や副業の形で開発に参画いただいてます。

わたしが直接知り合いに声をかけたり、Twitter や YOUTRUST 経由の募集で手伝っていただける人を探しました。

開発チームの立ち上げ期からつい最近まで、@d_date さんや @noppe さんを始めとした、とても強力なメンバーもジョインしてくれていて、彼らが技術選定から初期の設計までがっつりとコミットしていただきました。後述しますが、かなり興味深い開発環境が整っています。まだ未リリースともあり、iOS アプリ開発は壮大な遊び場にしています。

そこから入れ替わりもありつつ、現在の形となっています。

技術環境

採用情報にも掲載していますが、iOS アプリ開発で使用している技術は下記です。

  • Swift

  • SwiftUI

  • The Composable Architecture (TCA)

  • Swift Package Manager (SPM), Multi module

  • Renovate, Periphery, swift-format

  • Bitrise, TestFlight

  • Deployment target iOS 15.0

  • Protocol Buffers, gRPC

  • Figma, GitHub, Notion, Slack, Jamf Pro

太字にしたキーワードは、NOT A HOTEL の iOS アプリ開発の中でも特徴的なところなので、詳しく紹介していきます。

1. SwiftUI と TCA という選択

NOT A HOTEL の iOS アプリ開発では原則 SwiftUI を使っています。SwiftUI では表現できないところに限り、UIKit を導入しています。

わたしたちは昨年の 2021 年 3 月から開発を始めたため、UIKit に囚われることがなく、SwiftUI と TCA で開発をはじめました。

SwiftUI を書いたことがある人はわかると思いますが、SwiftUI はリリースされて 3 年経つとはいえ、UIKit のように成熟していないフレームワークであるため、表現に乏しく、UIKit に頼るしかないような場面があり、まだデファクトスタンダードとは言い切れない状況です。そんな中、原則 SwiftUI でアプリ開発を実現する会社は、徐々に増えてきたものの、まだ珍しいのではないでしょうか。

何より SwiftUI の良いところは、自明ではありますが、宣言的 UI での実装が可能で、モバイルアプリ開発にとって大きな工数を割く必要がある View の組み立てを爆速で行うことが可能で、スタートアップで 3 つもアプリを作らないといけない会社とエンジニアにはもってこいな選択であると言えます。

また、NOT A HOTEL の建築も含めたプロダクト開発のポリシーとして、機能要件だけ満たせばよいというわけではなく、デザインから体験の細部まで拘ります。

NOT A HOTEL では、既に物件を購入いただいたオーナー、またはこれから物件を購入いただくオーナーの体験を最大化することを最も重要と考えています。そのため、それに応える建築やソフトウェア、運営など様々な側面で最高の体験・プロダクトをつくらないといけません。それゆえ、ソフトウェア観点では、デザイナーが細部の細部までこだわった UI とインタラクションを設計しており、それを SwiftUI で実現していくことも、おもしろい挑戦です。副次的にゲストのお客さまが利用するアプリとしても、かなり作り込みをしたアプリとなっています。

次は、アーキテクチャについての話についてです。
SwiftUI との親和性が高いとされる The Composable Architecture (TCA) を使用しています。TCA についての記事はいろんな方が出していただいているので、詳細はここでは省きますが、ざっくり説明すると Redux ライクなアーキテクチャで、コンポーネント指向でかつ、公式でテストコードを提供しているなどテスト容易性も強調しているフレームワークであり、アーキテクチャでもあります。
下記の今城さんの動画でも触れられていますが、Reducer からしか State を変更ができないため、View から State を直接書き換えることは原則できません。データの流れが一方向になるよう制御されるため State の管理が楽になるといった特徴をもっています。

参考動画: 「iOS アプリ開発のための "The Composable Architecture" がすごく良いので紹介したい / 今城 善矩」

NOT A HOTELでは、SwiftUI を全面的に使う前提で、開発の高速化を行いつつも、前述のメリットを得られるため、TCA が最適であったと考えています。

2. SPM と Multi module 構成

2 つ目の特徴として、SPM による Multi module 構成について紹介します。

iOSDC 2021での @d_date さんの発表「 Swift Package 中心のプロジェクト構成とその実践」でも、その Case Study の1つとして紹介されていますが、まだリリース前かつ少人数での開発ながら、Multi module が整備されています。成熟したプロダクトではよく話を聞きますが、iOS チームメンバーが業務委託含めて 4 人ほどの会社で採用しているのは珍しいのではないでしょうか。

SPM と Multi module に関しては @d_date さんの下記の記事が大変参考になります。

一般的に Multi module にすると得られる、下記のようなメリットが生まれています。逆に開発速度が遅くなるなどの弊害は現状感じておりません。

  • ビルドの高速化

    • すでにビルドしたコードに変更を加えた場合、ビルド時にはその変更があった Framework だけをコンパイルすればよいため、全体的なビルド時間が削減される

  • 開発効率の向上

    • 機能単位で Preview app を分離することができ、その中でビルドしたいものだけビルドしてプレビューすることができる

    • どのフレームワークが何の機能を有しているかがすぐわかる

左: Targets 右: ReservationFeaturePreview.app の起動直後

また、わたしたちのプロジェクトで面白い取り組みの1つとして、先ほど上げた３種類のアプリが、1つ の Xcode Workspace の中でマルチプロジェクト化されて、存在していることです。
これによりアプリのコンテキストは違いますが、上記で上げたような恩恵を得つつ、同じ基盤を利用したリソースの活用が可能となり、アプリ間の開発のスイッチングコストが下がります。Main アプリで利用している DesiginSystem (StyleGuide) や Resource を HomeController アプリに適用することが可能となっています。

Multi projects

3. 開発アプリの配布で TestFlight の利用

特段、目新しい技術ではないですが、Staging 環境のテストアプリを配布するために TestFlight の最大100人まで配布可能な内部テスター機能を利用しています。

実は以前、弊社では Flutter でアプリを作成していた時代もあり、Firebase App Distirbution を使用していました。しかしながら、事前にデバイス登録をする手間がありました。

TestFlight の場合は、App Store Connect へのユーザー登録後、 TestFlight への招待は必要であるものの、一度テスト者の環境さえ整えば、テスト者のデバイスが変わろうが、開発者は関与はしなくて良くなります。

NOT A HOTEL では、建築家やシェフなど通常のテックカンパニーにはいない職種のメンバーもいます。そういったステークホルダーにも気軽にリリース前にアプリを触ってみてもらう必要があり、TestFlight が活躍しています。ファーストリリース後は、ソフトウェア・プロダクトに関わるメンバー以外は、内部から外部テスターに切り替える予定です。

また、ファーストリリース・Submit 前の段階ですが、 Submit のために別で TestFlight デプロイ作業が不要になります。他のデプロイサービスへの関心事がなくなり、開発のスピード感をシビアに求められるスタートアップにとってはとてもありがたいことです。

また、TestFlight では業務委託の @noppe さんが始めた施策で、Apple から提供されているプロジェクトの UIKit Catalog を社内配布しています。デザイナー含めデフォルトのコンポーネントの挙動を確認出来るようになっています。

[Apple] UIKit Catalog: Creating and Customizing Views and Controls

NOT A HOTEL の iOS アプリ開発のこれから

本記事では、現在の NOT A HOTEL の iOS アプリ開発がどのように行われているかを紹介しました。

リリース前のサービスではありますが、 SwiftUI のポテンシャルを最大限に発揮させたり、今後もメンバーが増えていく毎に進化させていくには、面白い開発環境であると思っています。

今は人的リソースも限られており、初期は MVP で出す部分もあるため、将来 NOT A HOTEL が大きくなってきた際にやりたい挑戦が、既に数年先まで考えてもぎっしり待っています。

また、夏に最初のシステムリリースを控えていますが、そのリリースはもちろんゴールではありません。

ソフトウェアも含めて建築は Ver 1.0
大きなプロダクトとして Semantic Versioning で管理しています

9 月のオーナーの滞在、ゲストの滞在をはじめ、全国、そして世界中に NOT A HOTEL が増えていくと、様々な機能が追加されてアプリの規模も大きくなっていくことでしょう。各地・各国の状況や文化に合わせたローカライゼーションなどにも取り組んでいくことになります。

こういった会社やサービスのグロースに対して、アプリやアーキテクチャをどう変化させていくか。どう意思決定を重ね、どうやってよりよりプロダクトを実現していくか。解決すべきおもしろい難題がまだまだたくさん出てくると思います。

このような環境で、「世界をもっと楽しく」するため、全力で自分たちが楽しみながら仕事するソフトウェアエンジニアの方は、ぜひ声をかけてくれるとうれしいです！

余談ですが、わたしは以前から、iOS デバイス管理の MDM が大好きで、かなり挑戦的な iPad アプリの開発と、共有 iPad 機能を駆使して綿密にプライバシー設計をした iPad デバイス管理もする予定です。それについても、おいおいどこかでお話したいと思います。

おまけ

建設中の「NOT A HOTEL AOSHIMA」の様子

「NOT A HOTEL AOSHIMA」は建設中ですが、隣接のレストランは先行して今週末にオープンします！工事現場やレストラン準備の様子です。わたしも宮崎に駆けつける予定です。