AppleのWWDCをはじめ、世界にはiOS開発者向けの国際カンファレンスがたくさんあります。今年4月には、私自身も英語トークが推奨される「try! Swift Tokyo 2025」に登壇する機会を得ました。
私はいわゆる「英語初心者」で、登壇準備では発音練習、原稿作成、スライド構成にかなり苦戦しました。しかし、同時に大きな成長と達成感があり、「もっと挑戦したい!」と思える経験になりました。
現在では、AIをはじめ英語学習の方法も大きく変わってきています。
このLTでは、以下のような私が実際に使った英語登壇のためのTIPSを紹介します。
英語登壇に興味があるけれど「英語だから無理」と思っている方へ。「完璧じゃなくてもいいから、一歩踏み出してみる」そんな勇気を持ってもらえる5分にしたいと思います。
私もまだまた挑戦中ですが、一緒に一歩を踏み出してみましょう!
2ヶ月ほど前Swift Forumsに投稿された Xtool: cross-platform Xcode replacement. Build iOS apps on Linux and more! という投稿をご存知でしょうか。
Linux上でネイティブのiOSアプリ開発をビルドするためのXcodeに成り変わるツールを開発したという内容で、これは私にとってとても衝撃的でした。
iOSアプリ開発といえばmacOSが必要というのは多くの人に知られていると思います。IDEであるXcodeを始め、プロジェクトをビルドするための xcodebuild
や署名用の codesign
など、多くのツールがmacOS上でしか提供されていないためです。
それではこのXToolというツールはどのようにmacOS外でのiOSアプリビルドを可能にしたのでしょうか。それにはSwiftのビルド技術の進化が大きく関わっています。
このトークで話さないこと
このトークで話すこと
Apple Vision Proを活用し、自分の発した声や楽器の音程を空間上に可視化する機能を実装しました。
単に周波数を表示するのではなく、「今の音が目的の音程に対して高いか・低いか」を3D空間に直感的に表示し、自分の音感をリアルタイムで補正できる仕組みを構築。
実際にこのアプリを使って練習を継続した結果、ピッチのズレ補正が体感でき、音感トレーニングとしての実用性が期待できそうです。
本セッションでは、空間UIによる音程フィードバック設計、Vision Pro上での周波数検出と3Dビジュアライズ手法、日々の改善プロセスまで、実装から習熟までの過程を具体的に解説します。
空間コンピューティングの新しい応用例や、感覚の可視化×習得支援に興味のある方にとって、技術面・UX面の学びを持ち帰っていただける内容です。
Swiftでバックエンドも開発できたら、便利だと感じたことがある方は多いのではないでしょうか?
フロントエンドとバックエンドで異なる言語を使い分ける必要がなく、一つの言語でアプリケーション開発を完結できれば、開発効率は格段に向上します。
Server-Side Swiftは、開発者がフロントエンドとバックエンドをSwiftで統一できる選択肢を提供します。
本LTではSwiftをサーバーサイドでも活用する利点と、複数あるServer-Side Swiftのフレームワークの中でも、特にVaporに焦点を当てます。
【本LTで得られること】
Vaporは型安全性、Swift Concurrencyのサポートなど、Swiftの強みを最大限に活かしたフレームワークです。
本LTでは、まずSwift Package Managerを使用した環境構築手順を説明し、その後、基本的なルーティング設定とミドルウェア構築について解説します。続いて、async/awaitを活用した非同期処理を実際のコードで示します。さらに、Codableプロトコルを活用したモデル定義とJSONレスポンスの実装を通して、iOSアプリとサーバー間でのスムーズなデータ連携方法を示します。
今日からすぐに試せる具体的な知識と実装テクニックを5分間でお届けします。
Embedded Swiftの登場により、Swiftで組み込み機器向けのプログラミングが可能になりました。
AppleがSecure Enclaveの開発でEmbedded Swiftを使っていたり、去年のiOSDC JapanでもRaspberry Pi PicoやPlaydate、ゲームボーイアドバンスをEmbedded Swiftでプログラミングをするトークがあったりと、とても注目の領域です。
私もそれに触発されてゲームボーイアドバンスのプログラミングをはじめました。しかし、"Safe"が売りのSwiftで、組み込みプログラミングに特有の"Unsafe"な手続きをどう実装したらいいか、かなり試行錯誤しました。
C言語やObjective-Cを使えば簡単なのはわかっています。でも、私はなるべくSwiftだけでプログラミングしたい! なぜならSwiftが好きだから!
このトークでは、ゲームボーイアドバンスでのプログラミング例と共に、「アドレス指定のメモリアクセス」「レジスタ操作」「関数ポインタによる割り込み処理」「_attribute_の利用」「インラインアセンブラ」に挑戦した結果を紹介します。
Embedded Swiftの可能性と「危なさ」を体感してください!
Apple Vision Proの登場で注目される空間写真や空間ビデオなどの3Dコンテンツ。しかし、Appleやサードパーティのアプリで提供されるコンテンツはクオリティが高いものの、それだけでは物足りなさを感じている方も多いのではないでしょうか。
そんな方におすすめしたいのが、自分で撮影したオリジナルコンテンツです。思い出や特別な瞬間を切り取った自作のコンテンツは、プロが作った作品とは一味違う、特別な価値をもたらしてくれます。
先日のWWDC25では、時期OSに向けてVR撮影機器との連携を強化する発表もされました。iPhoneで撮影しても手軽に楽しめますが、様々な専用の機材で撮影して活用する土壌も整えられつつあります。
本発表では、比較的安価で手を出しやすいミラーレスカメラを使い空間写真や空間ビデオを撮影する方法と、その魅力についてご紹介します。Apple Vision Proの新たな可能性を、自らの手で引き出してみませんか?
あるとき、開発しているサービスのユーザから「この挙動不便なんだよね」と打ち明けられ、「なにその話、それ仕様じゃなくて意図せぬ挙動です」と不具合に気付いたことはありませんか。同じことが我々開発者とプラットフォーム提供者(Apple)の間でも起こっています。伝えることで解決する不具合や訊くことで判明する方略があります。
APIもフレームワークもガイドラインも天から降ってきて受け取るだけのものではありません。疑問があったら質問をしましょう。要望があったら介入しましょう。大切なのはコミニュケーションです。
フィードバックフォームやオンラインでのエンジニアとのone-on-oneなど、Appleは我々サードパーティの開発者とコミニュケーションを取る複数の方法を提供しています。それらを活用することで、あなたの開発はもっと充実したものになるでしょう。このトークではその使い方と効能を登壇者の実感とともに紹介します。
以下の話をします:
・Appleとコミュニケーションを取る方法の紹介
・それぞれの手段のProとCon
・上記に関する登壇者の体験事例
・フィードバックを出すことに関する啓蒙
以下の話はしません:
・企業としての特別ルートの会話
対象とする聴講者:
・Appleの提供する技術を使っているすべての開発者
・ルーキー
「来年度からチームにジョインする新卒のメンターよろしくね」 そう言われたとき、少しでも不安を感じる方は多いのではないでしょうか。
ZOZOTOWN iOSチームでは、これまで新卒メンバーのメンタリングはメンターの経験と裁量に委ねられていたため、メンターの得意不得意によって新卒メンバーが活躍するまでの期間が左右されてしまう、属人性の高さが課題でした。
そこでZOZOTOWN iOSチームでは、2024年新卒のメンバー受け入れにあたり 「初めてのメンターでも、iOS未経験の新メンバーでも最高のスタートダッシュを切れる」 ことを目指した教育プランを作成しました。
このプランでは、iOS開発やチーム開発の基礎知識の習得だけでなく、ZOZOTOWNという巨大で歴史のあるプロジェクトならではのリファクタやリアーキを前提にした開発ステップなど、実務に向けたエッセンスを凝縮した実践課題を通して新卒メンバーがスムーズにステップアップできるようになっています。
本トークでは、教育プランの具体的な内容と、実際に1年間メンターとして伴走した結果、新卒メンバーがどのような成長を遂げたのかをご紹介します。
iOSエンジニアを目指す学生の方々には効果的な学習ステップのヒントとして、企業のメンターやリーダーの方々には再現性の高い育成の仕組み作りの具体例として、役立つ知見をお届けします。
クラウドAIエージェント「Devin」などの活用が進む中で、iOSアプリの開発も“人がビルドしてエラーを確認する”時代から“AIが自律的にビルド&デバッグする”時代へ向かっています。
しかし、私たちが取り組んだTCA採用プロジェクト「LogoREGI」では、xcodebuildによるCLIビルドそのものが大きな壁として立ちはだかりました。
例えば、 SKIP_MACRO_VALIDATION=YES ではMacroが展開できず、 defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES を設定しなければビルドできない、というCLI環境特有の落とし穴にハマりました。
さらに、 destination と sdk オプションの相互作用によるビルド失敗、煩雑で読みにくいログ出力など、「まずビルドを通すこと」自体が大きな課題となりました。
このLTでは、try! Swift TokyoのiOSもくもくハッカソン参加時に試行錯誤しながら見出した、「まずビルドを通す」→「安定してAIと連携できる構成へ」進めるまでの実践知を共有します。
LTで話すこと:
このLTが、CLIビルドの壁にぶつかるiOS開発者にとって、自動化に踏み出すきっかけとなれば嬉しいです。
近年、汎用的なLLMエージェントは、自然言語による指示からブラウザ操作までを自律的に行えるようになりつつあります。中でもDevinのようなエージェントは、複雑なUIの解釈やフォーム入力、ページ遷移などを含む一連の操作を一貫して実行できるポテンシャルを持っています。また、ブラウザの操作に限らず、Androidアプリを自律的に操作できるエージェントも増えています。
一方、iOSでは、Appleのセキュリティポリシーによる制約により、iPhoneを完全に自動操作するエージェントはApp Storeの審査でリジェクト対象になります。よって、現時点では一般向けには存在しません。しかし、将来的にiOSアプリがエージェントによって操作される日が訪れるかもしれません。そんな日に備え、エージェントによる自律的なUI操作の実態を分析・解剖して未来を見据えることが重要です。
このLTでは、居酒屋でのモバイルオーダーというタスクに注目し、エージェントとしてのDevinの振る舞いをエスノグラフィー調査を通じて分析した結果を報告します。また、お店のQRコードと参加者の食の好みを入力、モバイルオーダーの注文結果を出力として定義し、幹事としてのDevinの挙動を厳正に評価します。エージェントといえど、飲み会の幹事に忖度はありません!実験は、初回実験(参加者8人)と追試実験(参加者16人)の2回にわたり実施しました。
Devinに胃袋を捧げた参加者とともに、厳正に実施した実験の結果に注目です!
ブラウザ操作ができるようになり自由の翼を得たLLMは、さらなる自由を求め、どこまで突き進むのか。
胃袋の限界が来るまで、進み続けるんだ!
唐揚げが来ても、唐揚げが来た後も。
これは、お前が始めた物語だろ!
弊社のプロダクト開発中に遭遇した、予想を超える怖いバグの実例をご紹介します。
このバグは、機器からBLE(Bluetooth Low Energy)で取得したデータをテーブルビューに反映させる際に発生しました。
正常に動作していると思っていたのに、なぜか意図しない場所のデータが変更されてしまいます。
この不具合の真相は何だったのでしょうか。私たちはどのようにしてこの問題に立ち向かったのでしょうか。
バグの発見、原因の特定、そして解決に至るまでの一連の流れを、具体的なエピソードを交えてお話しします。
このセッションでは、普段あまり遭遇しないような不具合に対する対処法や、問題解決のための新たな視点を得ることができるかもしれません。開発者やエンジニアの方々には、まさかのときに役立つ知識をお持ち帰りいただける内容となっています。ぜひご参加ください。
SkyWay SDK開発においてWebSocketライブラリを切り替えた実践について説明する。
背景:
これまで、WebSocketの実装にはサードパーティライブラリであるSocketRocketを使用していた。しかし、依存ライブラリを削減し、バイナリサイズを縮小するために、新しいライブラリへの移行を決定した。
具体的な作業:
移行にあたって、iOS 13以降で利用可能なURLSessionを使用することにした。しかし、SkyWayではiOS 12を最低保証バージョンとしていたため、まず最低保証バージョンを引き上げる必要があった。調査の結果、技術サイドではiOS 14または15への引き上げを検討し、最終的にiOS 14に引き上げることでビジネスサイドと合意した。
開発作業として:
切り替え手順:
テストコードが以前と同様のパフォーマンスを維持し、複数回の実行に耐えうることを確認しつつ、置き換え作業を進めた。次に結合テストを同様の要件で実行し、問題がないことを確認した。過去のプルリクエストを収集し、チェックリスト化することで、過去に発生した問題が再発しないことを確認した。最後にコードをリファクタリングして作業を完了した。
苦労した点:
イベントハンドラと使用しているWebSocketの機能を満たすために、独自の工夫を加える必要があった。
切り替えの効果:
SocketRocketの使用による手間が削減され、さらに1MB程度のバイナリサイズ削減を達成した。
WWDC25でAppleは「Liquid Glass」という新しいデザインを発表しました。
Appleプラットフォームにおいて、デザインの更新はiOS 8のフラットデザイン以来なので12年振りです。
Liquid Glassは、液体(Liquid)の流動感とガラス(Glass)の光学特性を兼ね備えた新しい素材です。
ガラスのように美しいタブバー…
スクロールすると後ろのビューが透けて見え、ガラスの中に液体が入っているようなブラーがかかる…
コンテンツを邪魔しない、透明感のあるデザイン…
よ過ぎか??
もう一度言います。
よ過ぎか??????
WWDC25をリアルタイムで視聴していたワイ、深夜テンションもあってブチ上がるの巻。
さすがにエグい。
スキューモフィズム(Aqua)やフラットデザインのよさも残していると感じ、まさに新時代のデザインです。
ガチでこれからのiOSアプリ開発モチベが爆上がりました。
こんなカッコいいデザイン、みんなで眺めてニヤニヤするしかないよなぁ??
●もくじ
・Liquid Glassの特徴
・iOS 26における純正アプリのデザインをみんなで眺める
・Liquid Glass対応した個人アプリ紹介
ますます勢いを増す日本のiOSアプリ開発者コミュニティ。しかし、そこで生まれるすばらしい知見は、まだまだ日本の中だけに留まっています。
今こそ、自分のトークを日本だけでなく世界中のみなさんに届けてみませんか?
このトークでは、海外登壇を夢見るみなさんのために、カンファレンスの見つけ方から登壇準備、実際に参加した時の様子や海外iOSコミュニティのノリまでギュギュッと5分にまとめてお送りします。
海外登壇にはお金がかかる?いえいえ、旅費を出してくれるカンファレンスも世の中にはあるんですよ!
このLTの直前にもどこかで登壇してきたばかりなので、情報の鮮度はきっとバッチリです。
「海外登壇ってハードル高そう…」と思っているあなたへ。その一歩を踏み出すための全てをお届けします。
海外登壇の流れを広げていくことで、日本から生まれる知が世界中に広がる世の中を一緒に作っていきましょう。
近年のSwift言語やXcodeの進化に伴い、従来のXCTestに代わるモダンなテストフレームワーク「Swift Testing」が注目されています。本セッションでは、ココナラiOSチームが実際にXCTestからSwift Testingへ移行した事例をもとに、導入の背景や具体的な手法をご紹介します。
まず、なぜ移行を決断したのか。急速に機能が増える中で、XCTestでは「テストが仕様書として機能しない」「分岐の多いテストはボイラープレートが増える」「テストケースに依存したセットアップが煩雑化」などの課題が浮き彫りにしたいと思います。
特にViewModelのテストにおいては、BDD(Given‑When‑Then)スタイルで記述できる点が大きな魅力です。
続いて、Swift Testingの特徴とメリットについて。マクロベースで直感的な構文や、型安全かつ並列実行対応、パラメタライズテストやtrait機能(OSや時間帯によってテストを制御)など、XCTestよりも柔軟で表現力豊かなテストが可能になります
ココナラでの具体的な移行ポイントは以下の4つ
setUp()に頼らず、各テスト内でViewModelやMockを初期化
@Suiteを使って条件ごとにネスト構造を整理
@Testやメソッド名を日本語で書き、仕様の可読性を重視
複数分岐のテストは@Suite内の独立した@Testで構造化
そして、パラメタライズテストにも対応可能ですが、ViewModelのようにロジックが複雑なケースでは適切でない場合もあるため、要件に応じて使い分けています。
最後に、実際のコード例(XCTest→Swift Testing両対応)や、BDDコードが「仕様書としても読める」利点をお見せしつつ、フレームワーク選定・チーム規約への組み込みなど実務ベースでの導入ノウハウを共有します
Swift 6.1から、引数の末尾に ,
(カンマ)を付けられるようになりました。
func foo(
a: String,
b: String, // !!!: カンマを付けてもビルドが通る
) {
}
みなさんはこちらの新機能をご存知でしたか?
このようにSwift 6.1と6.2の主な新機能を5分でサクッと紹介します。
サクッと理解したあとは、公式ドキュメントを読んで正しく理解を深めてくれよな!
リリース前のE2Eテストを、実サービスに適用可能なレベルで運用するには、ツールを導入するだけでは不十分です。
SwiftUI・UIKit・WebView が混在するiOSアプリにAppiumを用いたE2Eテストを導入・維持する中で直面したさまざまな課題と、それをどう解決してきたかを本セッションでご紹介します。
まず、accessibilityIdentifierの管理が煩雑になった問題です。
画面ごとにidentifierの付け方がバラバラで、統一された基準がないためにテスト実装時に混乱が生じていました。
この問題をプロジェクト内でどのように整理し、テストしやすい構造に落とし込んでいったのかをお話しします。
最後に、複雑なUIフローに起因するflakyテストの問題です。
日付選択 → オプション選択 → 決済画面への遷移 → WebViewでのメッセージ受信など、状態変化が多いフローにおいて、テストの安定性を確保するために取った構造的アプローチを紹介します。
3つ目は、E2Eテストをリリースフローに安定して組み込むための課題です
テスト実装 → 実行 → 結果確認 → QA → リリース、という一連のプロセスをどのように定着させたのか、実際のチーム運用をもとに共有します。
テスト自動化ツールを導入したものの、信頼性のあるテスト体制を作れずに悩んでいる方や、複雑なUI構成の中でテスト運用に課題を感じている方にとって、少しでもヒントとなれば幸いです。
AI Agentの進化によって、「Design to Code」への期待値が大きく高まっています。
その動きを受けて、Figmaで作成されたデザインを元に、GitHub Copilot Agentを活用してSwiftUIコードを自動生成する取り組みを行いました。
精度向上のためにコンテキスト整備(ディレクトリ構造、コード規約、TCAの実装パターンなど)やプロンプト最適化(実装計画や注意事項の指示追加など)を試みましたが、リスト表示の消失やアイコンがそのまま残るなど、UIの再現度が著しく下がってしまい、期待通りにAgentが動いてくれないこともしばしばでした。
これらの課題をどのように解決し、どのような結果が得られたのか、AI Agentを使いこなすために得られたヒントをお話しします。
visionOSやAndroid XRの登場により、私たちアプリ開発者にも「空間をデザインする力」が求められる時代になりました。
そこで注目したいのが、オープンソースの3D編集ツール「Blender」です。
このLTでは、開発者が知っておきたいBlender活用術を紹介します。
「ちょっと触ってみようかな」と思えるきっかけを5分でお届けします!
Swiftでは、Arrayに対してfilterやmapをつなげた宣言的な記述をよく使いますが、「この書き方で実行速度は大丈夫?」と感じたことはないでしょうか?
このLTでは、users.filter { $0.isActive }.map { $0.name } のような典型的な記述を対象に、filterやmapをつなげた場合の処理速度を、書き方の違いによって比較検証した結果を交えて紹介します。
ちょっとした記述の違いやlazyの有無によって意外な差が生まれ、期待通りに高速化されないケースもありました。
実際のコード例や計測結果を交えながら、宣言的コードとパフォーマンスのバランスをどう考えるかについてお話しします。
「lazyは速いと思ってたのに…」そんな小さな驚きと発見をお届けします。