Swift＆Xcodeのバージョンアップにまつわる怖かった思い出 / Scary Memories of Swift and Xcode Updates

登壇者名：酒井文也
登壇したイベントタイトル：Toranomon Tech Hub 第8回 IT業界、本当にあった怖い話
登壇したイベントのURL：https://toranomon-tech-hub.connpass.com/event/395274/

Transcript

1. Swift＆Xcodeのバージョンアップにまつわる怖かった思い出 ※現職でのお話とは全く関係ありませんが ...1つ昔話をしよう 株式会社ビットキー 酒井文也 2026/07/28
2. 自己紹介 酒井 文也 Sakai Fumiya @fumiyasac 2 ※長いのでモバイルアプリエンジニアになってからを抜粋して紹介します 2016.09 30歳の誕生日からiOSアプリ開発の勉強をスタート この時はまだWebエンジニアをしていました ソーシャルゲームやWebサービスの開発に従事 仕事→iOSアプリ開発の勉強 or 勉強会参加の毎日 2019.03 数社でiOSアプリ開発を経験した後に独立 iOSアプリ開発を軸に据えて様々な開発現場を経験 2021年からはAndroidアプリ開発にも挑戦 2023.01 国内最大級のハンドメイドマーケットアプリの開発に シニアエンジニアとして従事 iOS＆Androidアプリ開発を中心に幅広く新機能開発や 既存機能改善に携わっていました Now 2026年2月にビットキーに入社 homehub開発部 homehub Mobileに所属 現在は「homehub」のモバイルアプリ開発を担当 Flutter歴 = 社歴
3. Mission・Vision つなげよう。 人は、もっと自由になれる。 Bitkey Recruiting Book © Bitkey inc All rights reserved.
4. 現在、事業展開している２つのプロダクト 現在は「暮らし」「働く」という２つの事業領域において、 hubシリーズ（プロダクト群）をリリースし、 様々なステークホルダーに対して、プラットフォーム・プロダクト・サービスを展開しています。 デリバリー会社 暮らしサービス オフィス テナント ビル(オーナー) ワーカー 居住者 マンション オーナー デベロッパー 不動産管理会社 フレキシブル オフィス 管理組合 対象カスタマー/ユーザー テンポラリーユー ス
5. homehubは「暮らし」に関わる様々な体験を実現する。 その中心にあるのがスマートロック 「暮らし」
6. イントロダクション 現在の開発領域 iOSアプリ開発のみが中心 1. iOSアプリ開発からモバイルエンジニアとしてのキャリアを開始 2. その後 Androidアプリ開発にも挑戦 3. 現在は Flutterによるモバイルアプリ開発が中心 4. UI実装・アーキテクチャ・品質改善に関する発信や登壇を継続 現在も変わらない点 6 iOS/Android両輪でのアプリ開発 クロスプラットフォーム開発でも、iOS版を届ける限りXcodeからは逃げられません。 Flutterを利用したアプリ開発
7. イントロダクション このLTの前提＆今日の主題 • 昔話だけで終わらせない 過去のバージョンアップ対応を振り返りつつ、 2026年現在の開発環境に置き換えて考えます。 • • 7 今日の主題 • どうやって3週間で蘇生させたのか？ • なぜその状態を作ってはいけないのか？ • 生成AI時代でも人間が握るべき判断は何か？ 失敗に近い実体験を、次の保守設計へつなげる 本日のアジェンダ • 過去の実体験 - 短期間でアプリを蘇生させた話 • 2026年への置き換え - Xcode・Swift・SDK・生成AIの変化 • 今後の教訓 - 二度とアップデートを溜めないための習慣 過去 👉 現在 👉 次に備える の3部構成
8. バージョンアップの館に入ってしまった 最後のコミットから約 1年。残された期間は 3週間。 ‼ こちらは現在から約 8年前のまだ Swiftが2から3へ破壊的変更があった時期で確か 2018年当時を振り返ったお話です 8
9. バージョンアップの館に入ってしまった 封印されていたアプリ 入口は少し古いだけ に見えていました ...。 • 当時を振り返るとこの様な感じ • • 数世代前のXcode • SNSアカウント認証 • 破壊的変更前の古いSwift • 自動更新購読型のアプリ内課金 • 最後のコミットは約1年前 • API通信 • 一部のライブラリを独自にFork • ファイルダウンロード 👻 静かな恐怖ポイント① 今動いているのなら問題ないという認識 9 アプリに含まれていた機能 1. 既存ユーザーは利用できていたため、更新できない危険性が見えにくい状態 2. 画面が表示できるだけでは、移行成功とは判断できない 👻 静かな恐怖ポイント② 壊した時の影響が大きい機能ばかり
10. バージョンアップの館に入ってしまった 立ちはだかる困難 様々な事情から 猶予は 3週間。その中で今からできる事をやらねばならない ...。さて、どうする？ • Xcodeは一気に上げられない Step1: バージョンアップ前のMac & 現在動作するXcode Step2: バージョンアップ前のMac & 途中段階で動作するXcode Step3: バージョンアップ後のMac & 当時最新で動作するXcode 😅 試行錯誤ポイント① 各段階でビルド可能な状態を作る必要性 10 • 自動変換の先に待ち受ける恐怖 • 大量のコンパイルエラー • 大量の警告 • 新しい環境では動かないライブラリ • 自分たちで修正が必要なFork部分 😅 試行錯誤ポイント② 構文が変わっても意図までは変換されない 1. 放置によって当時は小さかった差分が大きな差分となる場合がある。故に 大きな差分は早期段階で小さな差分に分解 する。 2. 自動変換は正解まで連れて行ってはくれない場合がある。故に 機械的に直せる差分と仕様理解が必要な差分に分解 する。
11. バージョンアップの館に入ってしまった コードだけでは正しさを確認できない 規模感としては小規模なアプリであったけど、バージョンアップ作業時には やはりそれなりの困難は伴う もの。 • 確認が必要だった 3つの層 古いライブラリ起因による珍事 重要ポイント1 👉 サービス・業務仕様 事象: Xcode上にログが全く表示されない！ 重要ポイント2 👉 アプリ側の処理 （半日を費やしながら調査にあたると...🔬） 重要ポイント3 👉 API・データベース側の構造 原因: 元々利用していたLoggerライブラリが使えなくなった！ 📝 注意すべきポイント① 認証・課金・ユーザー状態・通信失敗時の挙動 11 • 1. 最初に直すべきだったのは、コードではなく 調べられる状態 にすること。 2. コンパイルが通ることと、 アプリとして正しいこと は別である。 📝 注意すべきポイント② まずは観測可能な状態にする
12. バージョンアップの館に入ってしまった 3週間の緊急対応を経てアプリは蘇生した 綺麗にすることより、 安全に生還することを優先しました。 • • 12 緊急対応を経ての変化 Before After 数世代前のXcode 当時の提出要件を満たす Xcode 破壊的変更前の Swift 当時の現行 Swift 約1年間更新停止 再びアップデート可能 重要仕様が曖昧 主要導線を再確認 短期間の緊急対応で蘇生できた条件 • 作成当時の開発者にヒアリングができた • 画面数及び画面遷移が比較的シンプルだった • API側の大幅修正が不要 / 課金・認証周辺の修正範囲が限定的だった
13. この経験を2026年に置き換えるなら？ 大きな移行を一度に行う時代から、複数の変化を継続的に受け取る時代へ。 13
14. この経験を2026年に置き換えるなら？ バージョンアップの館を経た経験と現在地 • 過去の経験から振り返って ◦ 本当に怖かったもの ▪ ◦ • 時間とともに失われるもの ▪ 仕様・経緯・判断根拠・確認手順 ▪ 積み重なっていたのは、 コードの負債だけではなく「記憶の負債」もある 怖さは消えず形を変えている ◦ 提出要件という締切は今もある ▪ ◦ 2026年4月28日以降、App Store Connectへ提出するアプリには「 Xcode 26以降・iOS 26 SDK以降」が必要 動いていると提出できるは別 ▪ 14 実装した理由が分からない / Forkした理由が分からない / 正しい挙動を知る人が減っていく / 検証方法が残っていない 放置していても締切の方から近づいてくる（※ Apple Developer「Upcoming Requirements」参照）
15. この経験を2026年に置き換えるなら？ 確認対象の広がりと新しい環境を受け入れること バージョンアップは決してネガティブな作業ではなく 新しい環境を受け入れる ための準備期間と捉える事もできます。 • • 現在は確認対象が広がっている 新しい環境にはご褒美もある • Swiftと言語機能 • Xcode 27 betaのCoding Agent • Concurrencyとデータ競合安全性 • 実機とSimulatorをまとめて扱うDevice Hub • Xcode・iOS SDK・CI • SwiftUIの新しい並べ替え・操作API • Swift Package・SDK・Plugin • AsyncImageのHTTPキャッシュ改善 変更はアプリコードの外側からも入ってくる • 守りだけでなく開発体験の改善にもつながる Flutterでも、Plugin・ネイティブSDK・ビルド設定を通してAppleプラット 提出要件や互換性を守るだけでなく、新しい道具や選択肢を受け取る フォーム側の変更を受け取ります。 機会でもあります。 現在はSwiftだけを上げれば終わりではない 15 • バージョンアップを負債返済だけで終わらせない
16. この経験を2026年に置き換えるなら？ 道具は進化したが判断は残る Coding Agentの台頭により、以前よりも遥かにバージョンアップ関連作業はやり易くなりました。 • • 16 道具は大きく進化した AIが支援する 人が判断する 調査と分類 守るべき仕様 変更案の作成 着手の優先順位 • エラーや警告の分類 • 変更候補の提示 • 影響範囲の調査 • テストのたたき台 機械的な修正 採用・不採用 • Release Notesの要約 テスト案の作成 最終的な正しさ AIで進める際は変更を小さく • 最初に調査と計画を依頼する • 1つの機能・1つの差分に分ける • Build・Test・実機で検証する • 変更理由を自分の言葉で説明する AIは”直し方”の候補を出せる。”何を壊してはいけないか”は人が決める。 AIで速く直せることと、安全に直せることは同じではありません。 🤖 AI活用を前提とする場合のバージョンアップ関連作業の前提
17. バージョンアップの館を作らないために アップデートを数年に一度の特別なプロジェクトにしない。 17
18. バージョンアップの館を作らないために 小さく・定期的に・確認できる状態で進める: その1 個人の頑張りではなく、チームの習慣と仕組みに変えていく。 • 4つの習慣 次の環境で定期的にビルドする • 更新時期を予定に入れる • 現行環境で引き続きビルドできるか • 次の環境でも定期的にビルドする • 新しいStable環境で警告が増えていないか • 依存関係を棚卸しする • Beta環境で主要導線が壊れていないか • 重要導線の検証方法を残す • CIや署名まわりに影響がないか 👀 確認する時期も先に決める WWDC後・正式版公開後・提出要件の発表後 18 • 1. 時間ができたらではなく、 先に時間を確保する 。 2. 問題は締切直前に見つかるほど高くつく。 ✅ 早めに壊して、早めに気づく バージョンアップに起因する問題の早期検知
19. バージョンアップの館を作らないために 小さく・定期的に・確認できる状態で進める: その2 知っている・把握できている状態を作り出す。 • 依存関係を棚卸しする アプリの記憶を残す • Swift Package • なぜこの仕様なのか？ • CocoaPods • なぜこの依存関係が必要なのか？ • Forkしたライブラリ • どの手順で正しさを確認するのか？ • サードパーティーSDK • 今回何を変更しなかったのか？ • Flutter Plugin • ネイティブ連携部分 更新する・置き換える・削除する・自分たちで保守する 19 • 特に残したい重要導線の例 : 認証・課金・Push通知・Deeplink・通信 1. 依存関係は未来のバージョンアップ難易度を決める 。 🧠 記録は未来の調査時間を減らす 2. 誰が知っているかではなく どこを見れば分かるか にする。 検証手順 / 期待結果 / 関連API / 管理画面 / 既知の注意点 / 判断の履歴
20. まとめ＆伝えたいメッセージ まとめ＆伝えたいメッセージ • 過去 ◦ • 現在 ◦ • 3週間でアプリを蘇生させた。ただし 失われかけた記憶の復元も必要だった 。 生成AIで調査と実装は速くできる。ただし 守るべき正しさは人が判断する 。 教訓 ◦ 変化と記憶を溜め込まず、小さな更新を日常の保守にする。 本当に怖いのは、XcodeやSwiftが変わることではない。変化を溜めている間に、アプリを知る人と判断するための記録が消えていくことだ。 バージョンアップは、コードを新しくするだけの作業ではない。システムの記憶を失わないための定期点検である。 生成AIは最高の伴走者になり得る。何を守りどの状態を正解とするかは人が決める。 ご清聴ありがとうございました！質疑応答・感想などお気軽にどうぞ！ 20
21. We Are Hiring ! 左の2次元コードから ご連絡ください！ Copyright © Bitkey Inc. All rights reserved. 21