はじめに
ディップ株式会社でバイトルのiOSアプリを作っている権です。
2026年9月11日から13日まで開催された iOSDC Japan 2026 に、ディップはプラチナスポンサーとして協賛しました。3日間スポンサーブースを出し、最終日には弊社・宮川がスポンサーセッションで登壇しています。この記事では、主にブースでやったアンケート企画について書きます。
今月はじめに開催されたDroidKaigi 2026でも似たことをやっていて、そちらは別記事にまとめました。Android側から見た話も入っているので、あわせて読んでいただけると全体像が見えると思います。
iOSDC Japan 2026 について
iOSDC JapanはiOS関連技術をコアテーマにしたカンファレンスです。今年の会場は有明セントラルタワーホール＆カンファレンスで、ニコニコ生放送での配信もありました。
日程 | 構成 |
|---|---|
9月11日（金）DAY 0 | 夕方からトークと各種企画 |
9月12日（土）DAY 1 | オープニング後、終日トーク／ルーキーズLT大会 |
9月13日（日）DAY 2 | 終日トーク、LT大会、クロージング、懇親会 |
毎年恒例の朝ごはんドーナツはありました。朝になるとテーブルにドーナツがずらっと並びます。たくさん用意してくださり、これ目当てに早めに会場入りする人もいるんじゃないでしょうか。
もうひとつが Optional<Bar> という名前のバー。バーの名前がSwiftのOptionalになっているのがいかにもiOSDCでした。
ブースでやったこと
バイトルは20年以上続いているプロダクトです。私たちはそのiOSアプリを、1年以上前からKotlin Multiplatform（KMP）で全面リニューアルしています。
長く運用されたアプリを作り直すとなると、技術選定より前に決めることが山ほどあります。誰が、どこから、どこまでやるのか。ブースではそのあたりを、「あなたがプロダクトをリニューアルするとしたら」というお題にして、来場者のみなさんに聞いてみることにしました。3日間、日替わりで角度を変えています。
日程 | お題 |
|---|---|
DAY 0（9/11） | どのポジションで参画したいですか？ |
DAY 1（9/12） | どの領域に一番ワクワクしますか？ |
DAY 2（9/13） | マルチプラットフォーム、採用しますか？しませんか？ |
付箋に書いて貼ってもらう形式で、貼ってくれた方には「うちはこう判断しました」という話をしていました。以下、3日分を順番に振り返ります。
DAY 0：どのポジションで参画したいですか？
最多はもちろんiOSエンジニア。iOSDCの会場なので当然ではあります。
面白かったのはその外側です。Androidエンジニア、バックエンド、デザイナー、デザインエンジニア、PdM、スクラムマスター、フルスタック、インフラ。iOSのカンファレンスで聞いているのに、回答は職種をまたいで散らばりました。
とくに目を引いたのが、自分の担当領域から出たいという回答です。「デザインを根本から設計しなおしたい」「1から100まで モバイルエンジニアとしてデザインも」「デザインもやってみたい」「iOSエンジニアだけど Androidエンジニア」。作り直すなら、いつもの持ち場じゃないところをやってみたい。そういう気分が出ているように見えました。
もうひとつ多かったのが、積年の書き換え願望です。「Objective C を Swift にリプレイスする!!」「いい感じのSwiftに書きかえたい」。
そしてこの時点で、すでにKMPの名前が何枚か出ていました。「KMPやりたい!!」「iOS + Kotlin」「マルチプラットフォームのiOSエンジニア」。3日目のお題の伏線が初日から貼られていた形です。
バイトルではこうしました
職種をまたいで回答が散らばったのは、実際のリニューアル現場の感覚とかなり近いものでした。画面をゼロから作り直すということは、デザインの再定義とAPIの見直しが同時に走るということです。
そして関わる領域が広がるほど効いてくるのが、決めたことを記録に残すことでした。私たちは設計判断をADR（Architecture Decision Records）として残しています。ドメイン層をどこまで作り込むか、UIアーキテクチャ、iOS側の状態管理パターンの選定、トラッキング基盤をどこに置くか。だいたいこういうテーマです。
書いているのは「なぜその選択をしたか」だけではありません。「なぜ他の選択肢を採らなかったか」と「将来どういう条件で見直すか」まで残しています。リニューアルでは決めることが短期間に大量に発生するので、記録がないとすぐに「これ、なんでこうなってるんだっけ？」が始まるんですよね。ADRがあると、あとから入ったメンバーが過去の判断を掘り返さずに済みます。この話は後半でもう一度出てきます。
DAY 1：どの領域に一番ワクワクしますか？
圧倒的に多かったのがUI/UXでした。「UI/UX」「UI/UX改善」「UI」と表現は違えど、ボードの半分近くがこれです。次いでアーキテクチャ設計。「アーキテクチャ考える」「アーキテクチャ再設計」「アーキテクチャ設計」と、こちらも書き方はさまざまでした。
予想していなかったのが「スリム化」「シンプル化」の多さです。「ライブラリ削除、データ取得を一本化 N+1解消」という具体的なものもありました。長く運用されたプロダクトを作り直すとなったら、機能を足すよりまず削りたい。ここは共感しかありません。
ほかには技術選定、API連携、サーバー周り、コア機能の検討。そしてiPhone Duo対応が複数枚ありました。
バイトルではこうしました
UI/UXとアーキテクチャ設計。私たちがリニューアルで刷新したのも、この2つでした。順番としては、アーキテクチャの土台を先に決めてからUIに着手しています。
アーキテクチャ
新しいバイトルは、Presentation → Domain → Data の3層レイヤー型アーキテクチャに、モジュール分離を組み合わせた構成です。Presentation層だけがプラットフォーム固有で、DomainとDataはKMPで共有しています。
リポジトリは単一で、モジュールは責務ごとに切りました。
baitoru-mobile-app/
├── androidApp/ # Android Presentation層（Jetpack Compose）
├── iosApp/ # iOS Presentation層（SwiftUI）
├── shared/ # KMP共有（Domain + Data）
├── model/ # インフラ依存のない純粋なドメインモデル
├── remote/ # OpenAPI Generatorによる自動生成APIクライアント
└── tracking/ # トラッキング基盤（Adjust / Firebase等）
Domain層のUseCaseには、CQRSを適用して参照系（Query）と更新系（Command）を分けています。読み取りと書き込みでは必要なトランザクション境界やキャッシュ戦略が違うので、同じ抽象に押し込むと歪みが出ます。
エラーハンドリングは sealed class ベースの AppResult<T> に統一しました。例外を投げて呼び出し側で拾うのではなく、失敗が型に現れる形です。KMPでは例外がSwift側で扱いにくいので、共通化前提の設計としても効いています。
データの表現は3つに分けました。Roomに永続化する Entity、API通信に使う DTO、ビジネスロジックが扱う Model。変換はすべてData層のMapperに集約しています。
もうひとつ、設計方針として決めていたことがあります。最初から完成形を作らない、ということです。ドメイン層はDDDを全面導入せずUseCase中心で始めましたし、Presentation層もMVVMから始めました。ただし条件があって、移行パスを事前に設計しておくこと。
実際にiOS側は、一部の機能でViewModelの肥大化と状態の散在が見えてきた段階で、計画どおりMVI/Storeベースへ移行しました。「複雑になったら直す」ではなく「どの兆候が出たら、どう直すか」をあらかじめ書いておいたので、移行のたびに議論をやり直す必要がありませんでした。
UI
iOS側のUIはSwiftUIによるフルネイティブ実装です。状態管理はMVIパターンで、以下を標準としています。
要素 | iOS | Android |
|---|---|---|
UI | SwiftUI View | Composable |
状態管理 | Store + @Observable | ViewModel + MVI |
画面遷移 | NavigationStack | Navigation 3 |
DI | swift-dependencies | Koin |
iOS 17以降のObservation Frameworkを標準採用し、@Observable / @State / @Bindable を使います。逆に @ObservableObject / @StateObject / @Published は禁止、というルールをADRで明文化しました。「使ってもいい」ではなく「使わない」と決め切ると、レビューでこの話題が出なくなります。
フルリニューアルのタイミングで入れたもののひとつが、デザインシステムです。色・タイポグラフィ・スペーシング・角丸・ボーダー幅・不透明度・寸法をStyle Dictionaryでトークン化してSwiftのコードとして生成し、Figma Code ConnectでFigmaのコンポーネントと実装をつなぎ、共通UIコンポーネントは UIComponents パッケージに集約しました。
トークン化のねらいは、実装速度そのものよりも判断を事前に終わらせておくことにあります。「この余白は16pxか20pxか」「このグレーはどれか」を実装中に迎えに行かなくて済む。地味ですが、これがかなり効きます。
ネイティブUIを選んでおくと、iOS 26のLiquid Glass対応のようなOSレベルのUI変化に対して、共通UIフレームワークの追従を待つ必要がありません。その場で判断して手を入れられます。
このあたり、実際にやってみて詰まったところや作り直したところも多いのですが、書ききれませんでした。10月8日のアフターイベントで詳しくお話しするので、興味のある方はぜひ。
DAY 2：マルチプラットフォーム、採用しますか？しませんか？
最終日は「します」と「しません」がちょうど半々に割れました。ここまできれいに二分するとは思っていませんでした。
「します」側で目立ったのはKMPです。
- 「KMPなら乗れる！」
- 「KMPにします。+ CMP」
- 「する。KMP with AI」
- 「します KMP + MVI + AI」
理由として書かれていたのは「デザイナーの負担が減る。機能開発が早くなる」。React Nativeを挙げる方や、「CMPやりたいです」という声もありました。
そして「しません」側の理由が、今年らしくて一番面白いところでした。
共通化しない理由としてAIが挙がる。かつてマルチプラットフォームを選ぶ動機の大きな部分は「2回書かなくて済む」ことでした。そこがAIで埋まるなら、わざわざ共通化しなくてもいい。そういう判断だと思います。前日のボードにも「コードはAIにおまかせ！」という付箋があったのを思い出しました。
「します」側にも、AIが並んでおり、同じAIという前提から逆向きの結論が出ている。半々に割れた中身がこれだったのが、3日間で一番面白かったところです。
AI以外の「しません」理由はこうでした。「しません カスタムが多くて辛いです」「しません 個別対応 速度が（以下隠れて読めず）」「しない まだそのレベルではない」「ネイティブの技能が必要」。
どちらとも言い切らない回答も一定数ありました。「一部のみ採用」「プロダクトの特性にあわせて選びます」「検討する」。
なかでも思わず反応したのが、この1枚です。
「しない！Native 使いごこちがいいから KMPは使う!!」
UIはネイティブ、ロジックはKMP。私たちがバイトルで選んだ結論とほぼ同じでした。
バイトルではこうしました
私たちもKotlin Multiplatformを採用しています。ただし「全部共通化する」という採用ではありません。業務ルールはKMPで統一して、UIは各プラットフォームのネイティブ実装に寄せる。Presentation層だけがSwiftUIとJetpack Composeに分かれて、Domain層とData層はKMPで共通、という形です。
なぜ共通化したかったのか
旧アプリはiOSとAndroidで完全に別実装でした。そこで起きていたのは、同じ機能のはずなのに振る舞いが少しずつずれていく、という現象です。
仕様書に1行しか書かれていないような振る舞いでも、実装が2つある時点で解釈のズレが少しずつ蓄積します。しかもそのズレは片方のOSでだけ見つかることが多いので、原因の切り分けに時間がかかる。
リニューアルで本当に欲しかったのは、コード量の削減ではなく、仕様の正が1つである状態でした。業務ルールがKMPのsharedモジュールに1箇所しかなければ、そもそも解釈のズレが発生する余地がありません。
ここは「AIがあるから共通化しなくていい」という回答とちょうど噛み合う論点だと思っています。AIが解決するのは「2回書く手間」であって、「仕様の正が2つある状態」ではない。私たちが消したかったのは後者のほうでした。
なぜFlutterではなくKMPだったのか
共通化すると決めたあと、Flutterとどちらにするかは迷いました。最終的にKMPにした理由は2つあります。
ひとつは、ネイティブのUIをそのまま使えることです。KMPで共通化するのはロジックだけなので、UIはSwiftUIとJetpack Composeで書くことになります。さきほど書いたLiquid Glassの話もそうですが、OS側の変化にフレームワークの追従を待たずに乗れるというのは、長く使うアプリでは効いてきます。
もうひとつは、10年後の話です。技術には寿命があります。いま選んだものが10年後も使われている保証はどこにもありません。なので、仮にKMPが廃れたとして、そのとき手元に何が残るかを考えました。
KMPで共通化した部分はKotlinで書かれています。つまりKMPをやめたとしても、そのコードはAndroidアプリのコードとしてそのまま生き続けます。共通化をやめて各OSに分けるという撤退の仕方ができるわけです。一方Flutterを選んだ場合、Dartで書いたものはiOSにもAndroidにも引き継げません。
20年以上続いているプロダクトを作り直しているので、次も同じくらいの期間使われる前提で考える必要がありました。撤退したときに片方が資産として残るというのは、けっこう大きな判断材料でした。
どこまで共通化するか
線引きの基準は、ひとつのルールに落としました。
「何をするか」は共通、「どう実現するか」がプラットフォームに依存するなら各OS
これがあると、新機能を作るたびに「これは共通化すべきか」で議論することがなくなります。
KMPとSwiftをつなぐところ
KMPの話は「共通化できた」で終わりがちですが、実際に効いてくるのは接続部の設計でした。
Kotlinの sealed class や suspend 関数、Flow をSwiftから自然に扱うために、SKIEを入れています。これがないと、Swift側で AppResult<T> をswitchで網羅的に処理する、といった書き方ができません。
逆に、Kotlin側では value class を禁止しています。Swift互換性に問題が出るためです。KMPを採用すると、こういう「Kotlin単体なら最適だが、Swift側から見ると困る」という制約がいくつも出てきます。これを都度議論せずルールとして固定したのが、運用に乗せるうえでは大きかったと思います。
トラッキング基盤は shared とは独立させて、依存方向を androidApp / iosApp → tracking → shared にしています。shared は tracking の存在を知りません。
iOS向けのビルドは、ios-export モジュールで shared + tracking を1つの Shared XCFrameworkにまとめています。ビルド時間が効いてくるので、ターゲットを限定するオプションも用意しました。
# 実機向けのみ
./gradlew :ios-export:assembleSharedReleaseXCFramework -PiosDeviceOnly
「1回で済む」がどこで効くか
KMPを選んだときに置いた期待は、設計・実装・レビュー・修正がそれぞれ1回で済むはず、というものでした。
これがどこで効くのかを考えると、新規実装のときではない気がしています。新規はそもそもiOSとAndroidで並行して作るので、差が見えにくいということがありました。効いてくるのは不具合修正や仕様変更のほうで、1箇所直せば両OSで直る、片方だけ直し忘れることがない、という状態が、運用が長くなるほど差として開いていくはずです。
想定していなかった効果
最後にもうひとつ。これはまったく想定していませんでした。
ADRで設計判断を記録して、レイヤーごとのルールをファイルとして明文化していったところ、AIによるコード生成の手応えが変わりました。「このプロジェクトではこう書く」がドキュメントとして存在していると、AIが既存のパターンに沿ったコードを生成してくれます。
ブースで挙がった「AIがあるから共通化しなくていい」とは、少し違う角度の話です。実感としては、AIが効くかどうかはそのプロジェクトのルールが言語化されているかに左右される。フルリニューアルは、そのルールをゼロから明文化できる貴重なタイミングでした。
スポンサーセッション
最終日9月13日、Track Cにて弊社・宮川昌高が「Kotlin Multiplatformを軸にした求人アプリ全面リニューアルの技術戦略」と題して登壇しました。
20年以上の歴史を持つバイトルのiOSアプリを全面リニューアルするにあたって、業務ルールはKMPで統一しUIはネイティブに寄せるというアプローチをどう選び、責務をどう分担したのか。この記事で触れた線引きの基準を、もっと詳しく話しています。
アフターイベントのお知らせ
10月8日に、DroidKaigi・iOSDC合同のアフターイベント「大規模リニューアルの本音を語る会」を開催します。
この記事もセッションも整理された形で話していますが、実際のリニューアルにはうまくいかなかった判断や、やり直した設計もたくさんあります。UI刷新やデザインシステムまわりで詰まったところも含めて、率直に共有する場にしたいと思っています。
おわりに
3日間、ブースに立ち寄って付箋を貼ってくださったみなさん、ありがとうございました。
やはり最終日です。「します」「しません」が半々に割れたうえに、採用しない理由としてAIがずらりと並んだ。同じ前提から逆向きの結論が出ている様子を、付箋の壁で一度に見られたのは貴重な経験でした。
iOSDC Japan 2026の運営のみなさま、スタッフのみなさま、ありがとうございました。
執筆者
権（モバイルアプリチーム / iOSエンジニア）
バイトルのiOSアプリ開発を担当。全面リニューアルでは、KMPを使ったロジック共通化と、SwiftUIによるiOS側のUI実装の両方に関わっています。
