とある開発期間1年・iOSメンバー5人の長期アプリ開発プロジェクトにおいて、QAでの不具合発生率を普段の半分以下の2%に抑えることに成功しました。
この要因の1つはメンバー全員が「小さなPull Request」を作り続けてきた事です。
「小さなPR」は品質向上と開発効率に大きく貢献するのです。
「PRは小さければ小さいほどレビュワーに優しく、早くマージされ、バグ発見率も向上する」という原則を深掘りします。
多くの開発者が「差分行数」でPRの粒度を判断しがちですが、本当に重要なのは「関心事の少なさ」です。
ユニットテストやXibの差分でPRが膨らんでもレビューが苦にならないのは、関心事が少ないためです。
本セッションでは、具体的な画面実装の例を挙げ、API層、UIコンポーネント、通信処理など、関心事ごとにPRを分割する具体的な戦略を詳細に解説します。
このセッションを通じて、チーム全体の生産性とプロダクト品質を向上させるヒントを持ち帰っていただければ幸いです。
AIコーディングがiOS開発でも注目される中、visionOSの空間アプリ開発にもClaude Codeを使って挑戦してみました。
SwiftUI × RealityKitでの開発は一筋縄ではいかず、空間体験の構築には想像以上の試行錯誤が必要でした。
コーディングだけでなく、3Dモデルは生成AIやBlender MCP、Skyboxは画像生成AI、効果音は音声生成AIに任せ、アセット面でもAIをフル活用。
さまざまな壁にぶつかりながらも、AIと二人三脚で空間アプリを形にしていく中で得た知見をお伝えします。
このトークでは、VisionフレームワークのOCR機能とCoreMLのシンプルなテキスト分類モデルを活用し、レシートの自動仕分けに挑戦した事例を紹介します。
画像からテキストを読み取り、正規表現を用いて金額を抽出し、商品名をカテゴリに分類するプロセスについて解説します。
複雑な前処理や高度なモデルを用いず、どれだけシンプルな仕組みで実用化に近づけるかを探求した結果を共有します。
手軽に試せる手法であるため、個人で家計簿や経費精算の自動化アプリを作成したいと考えている方々にとって、有益なヒントとなることを目指しています。
@Environment(.keyPath)、それはSwiftUIが提供しているデータフローの仕組みの一つであり、SwiftUIでアプリを組んでいるエンジニアで、これを全く使ったことがない人はいないでしょう。
ところが、あなたは本当に@Environment(.keyPath)を正しく使っているのか?もしくは@Environment(.keyPath)の実力を知ってて使っているのか?@Environment(.keyPath)の思わぬ落とし穴に陥ったことありませんか?
このLTでは、そんな@Environment(.keyPath)にまつわるクイズを集め、ぜひ会場の皆さんに挑戦していただきたいです!そして全問正解の方は、「@Environment(.keyPath)王」の称号を授けましょう(嘘)!
日々の開発の中で「この処理をBuild時やCIで実行しておきたい」と思い、自作コマンドを作ってる人は少なくないと思います。
しかしながら、自作のツールをチームに共有する手法が確立していないという問題があります。
毎回メンバーにビルドしてもらうのは避けたいですし、バイナリを配布するのはhomebrewのtapを作ったりする必要があったりとなかなか面倒でした。
SwiftではartifactbundleとCommandPluginを活用することでサードパーティのツールに頼らず、ビルド済みのバイナリを配布し実行することができます。
このトークではSwiftツールチェインだけでSwift製バイナリを配布・実行する方法について紹介します。
本文の提案:
アプリ開発で、バックエンドAPIの準備が整っていないために、モックサーバ構築に多くの時間を費やした経験はありませんか。
本セッションでは、iPhoneを活用して軽量なHTTPサーバを動作させ、開発中のアプリが必要とするAPIを迅速に提供する手法を紹介します。
この手法は、複数クライアントを捌く本格的なサーバではなく、1対1で開発中のアプリとペアリングするシンプルな構成であり、手軽に導入できる点が特徴です。
従来のモックサーバ構築では、APIスキーマの定義、レスポンスデータの準備、サーバ環境の構築など、多くの工程が必要でした。
しかし、iPhoneサーバアプリを使用することで、これらの課題を効率的に解決できます。
このセッションで話すこと:
対象者:
UIテスト時にUI要素を特定するための識別子であるAccessibility Identifierですが、SwiftUIのViewにAccessibility Identifierを指定するには各Viewに accessibilityIdentifier Modifierを適用する必要があり、テストケースの増加に伴いModifierの適用が面倒になってくるという課題があります。
Swift 6.0から「SE-0415: Function Body Macros」という、既存の関数の中身を書き換えることができるSwiftマクロが導入されました。本トークでは、Function Body Macrosを使ってSwiftUIのViewにaccessibilityIdentifier Modifierを自動で付与する方法と、実装時に遭遇した落とし穴とその回避策についてご紹介します。
Accessibility Identifierを自動付与することで、accessibilityIdentifier Modifierを各Viewに適用する煩わしさから解放されましょう!
話すこと:
「暑い日にスマートフォンを使っていて、アプリの動作が遅くなった…」そんな経験、ありませんか?
特に屋外で利用されるアプリにとって、端末の温度はユーザー体験を大きく左右する重要な要素です。
スマートフォンが熱を持つと、アプリのパフォーマンスが著しく低下したり、一部の機能が制限されたりすることがあります。このような影響を把握しておくことは、快適なサービス提供のために非常に重要です。
本LTでは、Foundationフレームワークに含まれる ProcessInfo.ThermalState API に注目します。このAPIを使うことで、デバイスの熱状態を4段階で把握することが可能です。
今回は、実際に屋外で利用されるモビリティアプリにおいて、春から夏にかけてThermalStateがどのように変化するのかなど、実測データと共にご紹介します。
さらに、端末が高温になった際にアプリが取ることができる対策についても触れます。
スマートフォンを「熱中症」から守り、夏でもクールで快適なユーザー体験をお届けしましょう!
広島という地方生まれの私がパソコンを触るようになったのはExcelでお小遣い管理を始めたのがきっかけでした。そこからVBAを触ったりブログを作ったり、Webサービスを開発するようになりました。最初は書籍を通じて学べていたものの、次第に相談できる人が必要になりました。でも周りに詳しい人はいませんでした。
そんな時出会ったのが地域のITコミュニティでした。
メンバーに相談していく中でカンファレンス運営に携わる機会やインターンを紹介して頂くこともできました。
今、僕が都内でiOSエンジニアとして働くことができるようになったのはコミュニティ活動によるものが大きいと実感するようになりました。
上京や転職など私の人生に大きく影響しているITコミュニティ活動について変遷を紹介します。
iOSDCをはじめとするカンファレンスやSwift愛好会などのコミュニティなどは基本的に有志のメンバーが活動・運営しています。
このセッションを通して少しでもコミュニティに興味を持っていただけると幸いです。
日々の開発作業でシミュレータを操作する際、細かな手間が積み重なって、貴重な時間を奪われていませんか?
「ダークモードの表示を確認したいだけなのに、ホーム画面に戻って、設定アプリを開いて、デベロッパメニューをタップして…。」
「プルリクに添付する動画を撮りたいけど、QuickTime Playerを起動して、収録範囲を選ぶのが地味に手間…。」
そんな、誰もが経験する「ちりつも」な手間に、貴重な開発時間を奪われていませんか?
もし、その面倒な操作がキーボードショートカット一発で片付いたら、どうでしょう?
例えば、あれだけ手間だったダークモードとライトモードの切り替えも、たった一つのコマンドで瞬時に行えます。
本トークでは、このように日々の動作確認を劇的に効率化する、選りすぐりのショートカット術をデモを交えて紹介します。
画面の回転やスクリーンショットといった基本技はもちろん、意外と知られていない2本指操作やシェイク操作など、知っているだけで開発体験が格段に向上するテクニックを厳選しました。
このセッションを聴き終えれば、あなたはもうマウスに頼ることなく、キーボードだけでシミュレータを自在に操れるようになります。開発をもっと快適に、もっと集中できる時間にしましょう。
※ 本セッションは非常に真面目な内容となっております
iOSアプリ開発において画像リソースを格納することは多々あるかと思います。
でもその格納するファイルの形式や内部の構造について正しく把握していますでしょうか。何も考えることなくPDFやSVG形式にしていませんか?
ファイル形式や方法を間違えるとたった100KBの画像を格納したつもりでも、アプリサイズを30MB増えたりする可能性もあります。
本セッションでは、普段何気なく利用している画像リソースの拡張子や格納方法について現時点のベストプラクティスを探求し、効率的な格納方法を見つけ出していきます。
現代のiOSアプリ開発ではSwiftUIの LinearGradient
や MeshGradient
、CIFilterの linearGradientFilter
などを使えば簡単にグラデーションを実現することができます。
多くの場合はこれらの強力なAPIを使うことで事足りるのですが、イラスト制作におけるグラデーション効果などにおいては、表現の幅を広げるためにより高機能なグラデーション描画を行いたいことがあります。
例えば、虹のような表現を行うためにグラデーションの制御点を複数用意したり、透明色からブラシ色に徐々にグラデーションするような表現が用いられたり、色の変化に緩急をつけるために補間関数を設定するようなケースがあります。
そのようなケースにおいて、既存コンポーネントでは実現することが難しいため、自分でシェーダーを記述して実現することになります。
このLTでは上記のような高度なグラデーションをAppleプラットフォーム向けのグラフィックスAPIであるMetalを利用して行った話と、その際にハマった透明色の扱いについて紹介します。
Kotlin Multiplatform(KMP)を使うことでかんたんにクロスプラットフォーム開発をすることができます。
最近ではAndroid開発でよく使われている便利なライブラリもKMPに対応し、より一層KMPの開発体験が向上しています。
例えば、ローカルでデータを永続化するためのライブラリ「Room」もKMPに対応しました。
Roomを使って開発をする場合はすべてのコードを共通化できるのではなく、プラットフォームによって実装が違う箇所があり、その場合はactual / expect 修飾子を使って実装します。
プラットフォーム別に動くコードは簡単に書くことができたのですが、テストコードを書こうとすると詰まる箇所があり苦労しました。
本セッションでは、Roomを使って開発する際にプラットフォーム別にactual / expectをどのように実装していくかと、そのコードに対してのテストの実装方法について、具体的なコード例を交えながら紹介します。
皆さんのアプリでは、分析ログを正確かつ漏れなく収集できていますか?
私たちのサービスでも多くのログを送信していますが、かつては実装漏れやデグレによる送り漏れが頻発し、効果測定ができず仮説検証に大きな支障が出ていました。
とはいえ、少人数チームかつiOS・Androidの両対応、さらに限られた予算の中で、導入できる手段には制約がありました。
そこで私たちは、「ログ送信箇所にテストコードを追加する」方針をとることにしました。
この実践により、徐々に実装漏れがなくなり、デグレによるログ欠損も減少しました。
テストコードといえば通常はビジネスロジックに対して書くものという認識があるかもしれません。
「なぜそこにテストを?」と思われるかもしれませんが、設計を工夫すればログ送信にも十分活用でき、ビジネス上の価値も高いと感じています。
本トークでは、ログ送信に対してテストを書くことの効果や実例、そして設計上の工夫についてご紹介します。
ログ品質の担保に課題を感じている方に、実践的なヒントをお届けいたします。
【あらすじ】
社内で突然始まった、Swift 6対応プロジェクト。
しかし、iOSエンジニアはたった2人。
そのうちの1人は、「自分でやるのは面倒だから」という理由で、すべてをもう1人に丸投げしてしまう。
重すぎる作業量を前に、残されたiOSエンジニアは1人で抱えきれないと判断し、他部署や他社のiOSエンジニアなど、あらゆるリソースに声をかけて助けを求めた。
「Swift 6対応を乗り切るためなら、手段は問わない」
そうして集まった応援メンバーの協力もあり、プロジェクトは加速度的に進んでいく。
しかしその裏で、誰にも気づかれぬまま、少しずつ歯車は狂い始めていた。
ようやく作業が完了し、落ち着いたかに見えたその時、そのiOSエンジニアの前に現れたのは、思いもよらぬ「代償」だった…!?
このLTは「てんとう虫コミックス ドラえもん5巻収録『ドラえもんだらけ』」のオマージュです。
チームでの実装・レビュー遅延やレビューコメントの反映漏れに悩んでいた経験から、Cursorを導入し「実装→レビュー→修正」の開発フローを効率化しました。本発表では、以下の8ステップでCursorを活用し、開発速度と品質を両立できたプロセスを技術的に解説します。
Cursor導入前後でiOS開発が如何ほど効率化されたか、導入を検討中のチームに即活用できる提案をお届けします。
UIKitで長年運用しているアプリに、SwiftUI画面を一部導入する機会がありました。そこで採用したのが、iOSDC2023で紹介された「SVVSアーキテクチャ(Store・ViewState・View)」です。
MVVMやTCAも検討した中で、なぜSVVSだったのか? UIKitコンテキストとの親和性、学習コスト、段階導入のしやすさなど、現場目線で感じた「ちょうどよさ」を共有します。
5分という短い時間ですが、SVVSの魅力と、実際にどうやって導入し、どんな課題があってどう乗り越えたかを簡潔に紹介します。SwiftUIを使ってみたいけどまだ一歩踏み出せていない方、UIKitとの橋渡しに悩んでいる方に刺さる話です!
課題は以下のような内容になります。
・チームメンバーへの理解促進(勉強会・ペアプロ)
・エラーハンドリングが煩雑になる問題
・Storeの強みが活かせない問題
・UIKitからSwiftUIへの遷移の違和感
・UIKitのタブが正しく表示されない問題
「SwiftUIなら、きっとサクサク動くはず!」
そう信じて開発したアプリのスクロールがカクついた時、パフォーマンス改善という大きな壁にぶつかりました。「一体何から手をつければ…?」と途方に暮れたのは、きっと私だけではないはずです。
このトークは、そんな私がXcodeのInstrumentsと格闘し、Viewの描画の仕組みやLazyVStackなどの基本的な知識を武器に、"もっさりUI"を改善していくまでの奮闘記です。
本セッションでは、
を、失敗談を交えながら共有します。
パフォーマンスチューニングは、ベテランだけのものではありません。この発表が、同じ悩みを持つ皆さんの「はじめの一歩」を踏み出すきっかけとなれば幸いです。
ゲーム開発といえばUnityやUnreal Engineが代表的ですが、学習コストやライセンス費用に不安を感じていませんか?
実はApple純正フレームワークだけでも、ゲーム開発に必要な、接触判定・リアルタイム通信・ランキング・ゲームパッド対応など、実用に足る機能群がすべて揃っています。
さらに最近では、iOSのゲーム体験を高めるための公式機能が充実してきており、ユーザーがゲームにアクセスしやすくなるような変化も見られるため、ゲームデバイスとしてのiOSに注目が集まっています。
このトークは、ゲーム好きですが一般のアプリしか作れなかった私が、純正フレームワークのみでオンライン通信対戦ゲームを完成させ、インディーゲームイベントへの出展を目指した経験をもとに、以下のトピックについてお話しします。
Swiftで業務アプリを作っているあなたも、すでにゲーム開発に必要な材料を持っていたのです──
Apple純正フレームワークだけでもここまで「戦える」ということを、実例を交えてお伝えします。
ゲーム開発は特別なスキルが必要──そんな思い込みを、そっと壊す5分間です。
iOSDC Japan 連載4コマ漫画「輝け!俺のViewController」が打ち切r...最終回を迎えたのは、ネタが尽きたからです。
しかし、そんな燃え尽きた俺を差し置いて、Apple Intelligenceは進化を遂げました。
「Apple Intelligencesを使えば無限にネタが出て来ると思うし、自動『輝け!俺のViewController』生成アプリを作ればいいのでは・・・?」
プロンプトに関係なく暴走するAI、足りないAPIで試行錯誤、やばい、デバイスが燃えるほど熱い!あこれ、デバイスあったかいしホッカイロアプリとして使えるのでは...?
AIで「輝け!俺のViewController」は進化するのか?怒涛の5分間、衝撃の結末「刮目」せよ