プロポーザル

教員時代に、学校で使えるアプリをなんか作れないかな？
そう思ったのが僕の個人開発のスタートでした。

たまに停滞しつつもコツコツと個人開発を続け、現在累計DL数は9万を超えました。
開発の過程で、ダウンロード数が伸びたり、アクティブユーザーが増えたり、収益が上がったり、ユーザーから直接フィードバックをもらえたりと、様々な喜びや発見がありました。これらの経験を通して、個人開発の「面白さ」を強く感じています。

この記事では、私が見つけた個人開発の「面白さ」を皆さんにお伝えしたいと思っています。具体的には、以下のポイントについて記載する予定です。

本記事で紹介予定の内容

• 何に面白さを感じたのか
• 個人開発を続けるために意識したこと
• アプリの収益を伸ばすために試したこと

このトークを通じて、皆さんが新たに個人開発を始めてみよう、あるいは一度止まってしまったプロジェクトを再開しようと感じていただけたら嬉しいです。ぜひ、個人開発の魅力を一緒に発見しましょう。

皆さんのプロダクトは、Swift 6へのメジャーアップデート、もう対応されましたか？

私たちのチームでは、iOSアプリのSwift6対応を進めようと準備を始めました。
しかし、 そこで直面したのは想像以上に大きな課題でした。
それは、Swift6で新しく導入された「Strict Concurrency Checking」の機能の存在です。
この機能の対応によって、「少しの修正で解決できる」といった簡単な話ではなくなりました。

その結果、私たちは長年使用してきたReactorKitを脱却することを決断します。

このトークでは以下の内容についてお話しします。

• Swift6から導入された「Strict Concurrency Checking」とは一体何なのか
• 脱ReactorKitをどのように進めているか
• まさかの結果とは一体何か！？

これからSwift6対応を検討されている方、ReactorKitを使っている方にとって、きっと共感していただける内容になっています！

iOSDC Japan参加者のみなさんなら、きっとiPhone、iPad、MacBookを持っていますよね！人によってはVision ProやHomePod、Apple TVもお持ちかもしれません。
私達にとっては仕事道具ですが、世間ではAppleプロダクトを使用していることは一種のステータスとも捉えらており、「おしゃれ」や「スタイリッシュ」の代名詞の一つということもできます。

そしてさらにこのスタイリッシュさは「無国籍」です。アメリカでも日本でも、喫茶店でMacBookを広げた姿は国を問わずスタイリッシュと言えるでしょう。
そのため私達はこれらAppleプロダクトを持っていれば世界中どこの国でも「スタイリッシュ」に仕事をすることができます。

でも、なぜAppleプロダクトは世界中どこで使っても「スタイリッシュ」なのでしょうか？

ソフトウェアのUI/UXの良さでしょうか？それともハードウェアのデザインが良いからでしょうか？
もちろんAppleプロダクトはソフトウェアのUI/UXは良いですし、ハードウェアのデザインも最高です。

実は、Appleプロダクトがそのイメージからは一見無関係に見える「建築」の世界からきた「素材」によってもスタイリッシュさが支えられていますとお話したら驚くでしょうか？

このLTではみなさんと一緒にモダニズムの生い立ちと、私達ソフトウェアエンジニアには意外に見えるガラスやアルミニウムといった「素材」の2観点から、Appleプロダクトがスタイリッシュに見える理由を深堀りします。
ソフトウェアエンジニアである私達が普段は見落としがちな「素材」という現実世界の要素が、なぜ「スタイリッシュ」に繋がっているのかを知ることで、皆さんの「プロダクト」作りに素材という新たな視点をもたらすことができれば幸いです。

LT会場でお会いしましょう！

SwiftUIでのUI構築において、GeometryReaderとScrollViewは画面サイズや位置情報を活用した柔軟なレイアウト制御に不可欠なコンポーネントです。しかし「思ったように動かない」「SafeAreaやネスト構造でレイアウトが崩れる」といった課題に直面する開発者も多いのが現状です。

本セッションでは、これらのコンポーネントの動作原理を基礎から丁寧に解説し、実務で遭遇する典型的な問題とその解決策を具体的なコード例とともに紹介します。特に、GeometryReaderの座標系の理解、ScrollViewのオフセット制御、パフォーマンス最適化の観点から、正しい使い方と避けるべきアンチパターンを明確化します。

さらに、PreferenceKeyやAnchorPreferenceなどの代替技術との使い分け、実際のプロダクトで活用できる応用パターン（カスタムスクロールエフェクト、動的レイアウト調整など）も解説し、SwiftUIらしい宣言的UI設計のベストプラクティスをお伝えします。

初学者のつまずきポイント解消から、中級者以上の設計力向上まで、幅広いレベルの開発者にとって実践的な知見を提供し、日々の開発業務で即座に活用できる内容を目指します。

Swift Concurrencyは、async/awaitによる非同期処理の簡素化やactorによるデータ競合安全など、私たちに多くの恩恵を与えてくれます。

一方で、「少し使いたいだけなのに、なんだか難しい…」と感じている方もいらっしゃるのではないでしょうか。特に「ただ普通にコードを書いているだけなのに、なぜ警告やエラーが出るのかわからない...」という声をよく耳にします。

Swiftコアチームは、使いやすさを高めるためのビジョンを掲げ、Swift Evolutionのプロセスと独自の機能改善を通じて、これらの悩みを解消しようとしています。先のWWDC25では、この取り組みが「Approachable Concurrency」として紹介されました。

本トークでは、このApproachable Concurrencyについて、主にWWDC25のセッションではあまり語られなかった部分に焦点を当て、以下の内容を深掘りしてお話しします。

1. Approachable Concurrencyに至った背景
2. 具体的な各機能のちょっと深い紹介(Isolated ConformanceによるProtocolのエラー解消、診断ドキュメントのわかりやすさ改善、など)
3. Approachable Concurrencyから見える、目指すべきiOSアプリの書き方

本トークを聞くことで、Approachable Concurrencyの意義を理解し、謎の警告やエラーに悩まされる回数を減らし、皆さんがConcurrencyをより「親しみやすく」感じる一助となれば幸いです。

概要

近年のAIの急速な発展により、従来のコマンドベースの入出力と比較して、自然言語による入出力が一般的になり、ユーザーインターフェースは大きく変化しています。言語学習や運転中の操作など、ハンズフリーでの対話が求められる場面や、VisionOSなどでのキーボード入力が困難な場合において、音声インターフェースの重要性が増しています。一方で、実際に音声AIエージェントを実装しようとすると、チャットUIとは異なる固有の技術的課題に直面することになります。本セッションでは、現在開発中のAI英会話アプリでの実体験を通じて、音声インターフェース特有の課題とはまりどころ、およびその解決策を具体的なSwift実装とともに解説します。

話す内容（予定）

• 音声AI Agentのアーキテクチャ
• AVAudioEngineを活用したストリーミングによる音声入出力
• 状態管理とそれに基づく会話の割り込み実装
• Swift Concurrencyを利用したストリーミングデータパイプライン
• gRPCストリーミングによるリアルタイム通信

話さない内容

• AIモデルの学習方法や理論的背景
• プロンプトエンジニアリングの詳細
• LLMの性能評価や比較
• 基礎的な音声処理理論

εε＝┌|▼▼|┘ ｳｯﾎｳｯﾎ

Xcodeは素晴らしいIDEって伝えなきゃ

ｳｯﾎｳｯﾎ └|▼▼|┐＝33

本LTでは、Xcodeの素晴らしいところをウホフクロウが軽快に紹介します。
5分間でXcodeをより快適に使えるようになるはずです。

●話すこと
・Xcodeの素晴らしいところ

●話さないこと
・Xcodeの素晴らしくないところ

ウホフクロウを生暖かい目で見守ってくれると幸いです。

私は今年、銀行員からiOSエンジニアへとキャリアチェンジをしました。

最近、「どうやって学習を進めたのか？」「転職までに何をしたのか？」といった質問をいただくようになったため、異業種からiOSエンジニアを目指す方、これからキャリアを築こうとする学生の方、またそうした方をサポートする立場の方に向けて、私自身の経験をまとめて共有したいと思います。

この記事では、独学でどのようにスキルを身につけ、エンジニアコミュニティと出会い、学びを加速させていったのか、そして転職を実現できたかについて、実体験をもとにお話しします。

本記事で紹介する内容：

• 独学でどのように学習したのか
• ロールモデルの存在がキャリア形成に与えた影響
• エンジニアコミュニティ・カンファレンスに参加して得られたもの
• 学びをコミュニティに還元する意義と実践方法

この記事が、iOSエンジニアを目指す方にとっての道しるべとなり、また誰かにアドバイスをする際のヒントになれば幸いです。

モバイルアプリ開発において、アプリに組み込まれた WebView はWeb サイトを表示するだけとは限りません。既存サービスの HTML を活用したり、最軽量かつ最小限のクロスプラットフォームを実現します。これらを制御する場合、HTML や JavaScript などの知識が欠かせません。しかしながら、モバイルアプリエンジニアは必ずしもそれらに精通しているとは限らず、実装上の問題に直面することも少なくありません。

本記事では、アプリに組み込まれた WebView（WKWebView）で遭遇しやすい問題、JavaScript の実行やイベント受信などに関する問題を整理して、その原因と具体的な解決方法を解説します。HTML や JavaScript に不慣れなモバイルエンジニアが、WebView を安全に活用して堅牢なアプリを開発するためのポイントを明示します。また、アクセシビリティの観点についても補足し、誰もが使いやすいアプリを実現するために必要な考え方を紹介します。

iOS アプリの開発において、Xcode 標準の静的解析機能は便利です。しかしながら、開発チーム独自のルールやアクセス制限など細かな要件を十分にカバーすることは難しいです。

本記事では、SwiftLint のカスタムルールを活用して、静的解析を強化する方法を紹介します。非推奨メソッドの使用制限や、アクセス範囲を特定のファイルやディレクトリ内に絞り込むことなどを可能にし、コード品質と保守性の向上を図るための考え方と実践的な導入手法を解説します。

WWDC 2025で待望のSwiftUI向けWebKitが発表され、SwiftUIでWebViewを扱いやすくなりました。
WKWebViewには多くのプロパティやView操作のメソッドがあるため、宣言的UIに適合させるのは容易ではありませんでした。
例えば進む/戻るボタンの表示制御や、ナビゲーションの動作にはWKWebViewへのアクセスが必要です。

SwiftUI向けWebKitでは、WKWebViewを持つWebPageクラスをStateとして扱うことで、WebViewをStateの写像として宣言的に記述できるように設計されています。

一方、私たちはこれまでWKWebViewを宣言的に扱うためのライブラリとして、cybozu/WebUIを設計・公開してきました。
WebUIではproxy APIを通じてSwiftUIからWKWebViewにアクセスできるよう設計しています。

本トークでは、WKWebViewの宣言的UIへの適合を例として今後のSwiftUIに最適なインターフェース設計の指針を提供します。
SwiftUI向けWebKitとWebUIの設計を比較して、よりSwiftUIらしい宣言的なインターフェース設計を掘り下げます。
また、ObservationとObservableObjectの変更監視の機能差から、「なぜ今SwiftUI向けWebKitが登場したのか」についても考察し、これからのインターフェース設計に必要な技術要素にも言及します。

本トークを通じてこれからのSwiftUIインターフェース設計指針と技術的背景について学びます。

対象者

• 宣言的UIの設計原則を深く知りたい開発者
• UIKit ViewのSwiftUIラッパー提供者
• SwiftUIで複雑な状態を扱うView設計者

話さないこと

• 今後のWebUIの開発方針

2024年、Swift界隈で地域コミュニティイベント Japan-\(region).swift の一大ムーブメントが巻き起こりました。
日本各地でSwiftのコミュニティが発足し、Swiftに関する学びがあるだけでなく、各地域の魅力を発信する場にもなりました。

私も「このビッグウェーブに乗るしかない！」とKanagawa.swiftを開催することに。初めての外向けオープンイベントの主催でしたが、多くの方々の協力のおかげで大成功を収めることができました。

本記事では、Kanagawa.swiftの開催記録と、これからSwift地域コミュニティを立ち上げたい方のための手引きをご紹介します。

さらに、全国のJapan-\(region).swiftマップも提供します！あなたも次に行ってみたい Japan-\(region).swift が見つかるかもしれません！

アプリの品質保証において、既存の機能が意図せず壊れていないかを確認するリグレッションテストは不可欠ですが、その多くが手作業で行われ、リリース前のiOSエンジニアにとって大きな負担となりがちです。
多くのチームがE2Eテストの「完全自動化」という理想を追い求めますが、サービス仕様上スムーズに認証を通す事が難しかったり、特定のUI要素の操作が困難だったりして、現実的な課題に直面し、導入を断念してしまうケースも少なくありません。

本トークでは、「完璧な自動化を目指さない」という発想の転換から生まれた「半自動E2Eテスト」のアプローチを紹介します。
既存の全手動運用をベースに、課題となる箇所を段階的に自動化していくことで、最小限のコストで最大限の効果を得る方法を実践例と共に解説します。
具体的には、SMS認証やカメラ操作、OS標準アラートといった自動化が困難なシナリオに対し、RubyのOCRライブラリ活用や座標指定、手動介入のタイミングを知らせる音声ガイドなどの工夫を通じて、どのように「手っ取り早く」運用可能な状態を構築したかをお話しします。

実際に導入から5ヶ月間、継続的に利用され、リグレッションテストの効率化に貢献している本システムの具体的な運用実績と、そこから得られた「壊れやすさを気にしすぎない」「最低限のメリットから始める」という、挑戦を後押しする考え方と安心感について共有します。
このセッションを通じて、リグレッションテストの負担軽減を模索している方、E2Eテスト導入の壁にぶつかっている方々が、新しいアプローチを見つけるきっかけとなれば幸いです。

LLMエージェントによるコーディングが民主化されたことで、プログラミングに新しい時代が到来しました。"Vibe Coding" という言葉が生まれ、多くの人が数行のプロンプトだけで実際に動作するアプリやWebサイトができあがってしまうのを体験しています。

その中で、こう思われた方もいるでしょう。「で、これを仕事で真面目に使うにはどうしたらいいんだ？」と。

詳細はお任せでゼロから適当に作らせればいい個人の遊びとは違い、業務としてのプロダクト開発には例えば以下のような制約やルールがあります。

• 機能要件が予め詳細に決まっている
• デザイン資料の通りにUIを実装する必要がある
• コーディングルールがある
• gitのブランチ運用など開発フローに関する決まりごとがある

本セッションでは、Anthropic社が提供するClaude Codeを実際にiOSアプリの開発業務で活用し、その中で得られた実践的なノウハウをお話します。

• Webアプリを作るのとは違う、iOSアプリ開発ならではの難しさに立ち向かう
• コンテキストが長くなることによる性能低下を防ぐために適度に記憶をリフレッシュする
• 要件定義と実装の工程を分けることで並列に進められるようにする
• AIエージェントをチームの一員として迎え入れるための準備
• プロンプトで指示しても無視することがあるのを、ToDoリスト機能で確実に実行させるようにする

このセッションで、業務にClaude Codeを組み込む際のコツを知っていただき、LLM時代のiOSアプリ開発者としての姿勢について考えるきっかけとなれば幸いです。

普段はWebのバックエンドを担当している私が、Swiftに興味を持ち、SwiftWasmを使ってオンラインプレイグラウンドを開発した実体験をお話しします。

SwiftWasmは、SwiftコードをWebAssembly（Wasm）にコンパイルして、ブラウザ上で実行可能にする技術です。Swiftに触れてみたいと思っていたものの、普段Web開発に慣れていることもあり、馴染みのあるWeb環境でSwiftを体験したいと考え、自作することにしました。

TypeScriptでの開発には慣れていましたが、SwiftWasmやWasm自体の扱いは初めてでした。特に苦労したのは、Swiftプログラムが正しく動作するために必要なWASI（WebAssembly System Interface）の一部を、TypeScriptで模倣する実装です。たとえば、fd_write は標準出力（print()）の処理を、proc_exit はプログラムの終了、random_get は乱数生成に対応しています。

「print()一つ出すのに、こんなに仕組みが必要なのか」と思いながらも、SwiftとWebAssemblyの仕組みを理解していくのはとても楽しい経験でした。

完成したプレイグラウンドでは、ブラウザ上でSwiftコードが実行でき、配列操作やクラス定義、Optional型の処理のデモを行えます。SwiftWasmの使い方やWebAssemblyの基本を、Webエンジニア視点で解説します。

iOSエンジニアの皆さんに、WebAssemblyでSwiftを実行する過程で得た気づきや発見を共有いたします。

SwiftはもともとiOSを中心に発展してきた言語ですが、最近ではその適用範囲が広がり、小型ゲーム機「Playdate」でも活用できるようになりました。

本セッションでは、白黒ディスプレイと物理ボタン、手回しクランクを備えたミニマルなゲーム機「Playdate」を題材に、その開発手法をご紹介します。Appleが新たに公開した「swift-playdate-examples」を活用することで、Swiftを用いてPlaydate向けのゲームを開発する環境が整いつつあります。

開発環境の構築手順を解説し、制約の多いデバイスで直面する独自の課題を取り上げながら、シンプルなゲームを作成するプロセスを共有します。さらに、リソース制限下でのSwift開発に役立つ実践的なヒントをお伝えし、実際にSwiftで制作したPlaydateゲームをデモします。

クリエイティブコーディングやゲーム開発に興味がある方、そしてSwiftの新たな可能性を探りたい方に向けて、iOSアプリの枠を超えたSwiftの魅力を、遊び心あふれる視点でお届けします。

【セッショントピック予定】

• swift-playdate-examples の概要
• Swift製ゲームをPlaydateで動かすための構築手順
• クランクや物理ボタンによるインタラクション設計
• リソース制限下でのゲーム開発における工夫とテクニック
• 制約された環境だからこそ見える Swift の柔軟性と強み

一見シンプルに見えるUIでも、実装してみると意外と時間がかかる──そんな経験はありませんか？

「このデザイン、30分で実装できそう」と思って始めたら、実際は2日かかってしまった。
そんな見積もりのズレは、デザインの「見た目の複雑さ」と「実装の複雑さ」が必ずしも一致しないことが原因です。

本稿では、SwiftUI・UIKit・Androidでの実装経験や考察から得た知見をもとに、デザイン仕様から実装難易度を読み解くための視点や判断基準を紹介します。

特に以下の観点を中心に、プロジェクト計画や実装方針の見極めに役立つ知見を整理します：

• 標準UIかカスタムが必要かを判断するための着眼点
• テキスト入力やChip、スクロールUIで陥りやすい構造的な課題
• カスタムアニメーションやトランジションの見積もりで考慮すべき要素
• GeometryReaderや座標計算を伴うレイアウトの扱いとその難易度
• 無限カルーセルUIを題材としたSwiftUIとUIKitのアプローチ比較

日々のUI実装における小さな判断を支える技術的な視点を、実例を交えてお届けします。

「このアプリ、自分に使える？」
そんな問いに応えるのが、WWDC25で発表されたAccessibility Nutrition Labelsです。
これはVoiceOverやSufficient Contrast、Captionsなどに対応しているかどうかが食品の栄養成分表示のようにラベル形式で表示されるもので、ユーザーはアプリのダウンロード前に自分に合ったアプリかどうかを判断できるようになります。

開発者はApp Store Connect上でアプリのアクセシビリティ機能対応状況について登録でき、その内容がAccessibility Nutrition Labelsとして表示されます。
今後このラベル表示は新規アプリやアップデート時に必須化される予定で、Appleは明確な評価基準や申告手順をガイドラインとして公開しています。
たとえばSufficient ContrastはWCAGの推奨コントラスト比（4.5:1以上）を満たしているかなど、項目ごとに具体的な条件が示されています。

このトークでは、Accessibility Nutrition Labelsの概要や各項目の評価基準を整理した上で、iOSアプリでこれらの基準をどのように満たすか、具体的な実装例を交えて紹介します。
VoiceOver対応のための accessibilityLabel や accessibilityHint、Dynamic TypeやReduce Motionといったシステム設定への対応などの実装方法に加え、XcodeのAccessibility Inspectorを活用した検証手法も解説します。

アクセシビリティは一部のユーザーのためだけの機能ではなく、誰もが恩恵を受けられる設計原則です。
このトークを通じて、あなたのアプリの「アクセシビリティ健康診断」を始めてみませんか？

シニアエンジニアに必須の能力はなんだと思いますか？そうですね、WWDCでの引率能力ですね。後輩たちを博物館や交流会へ連れていきApple Parkへ辿り着かなくてはいけません。
そこで選択肢に挙がるのがレンタカーです。ライドシェアより安く済み、アジア人女性150cmの私が知らない人の車に乗る不安からも解放されます。自動運転タクシーはエリア外だしサービス一時停止してたし。
とはいえ異国での運転は楽ではありません。ご想像の通りの右側通行左ハンドル。愛車の倍の体積のアメ車。そして日本とは違う道路のつくり。ペーパードライバーを脱して1年ですが運転しないことにはスキルが身につきません。やっていきましょう💪

本LTでは、スキルアップのため私がアメ車に初挑戦した経験をもとにサンノゼの交通事情を紹介します。
CarPlay（アメリカのすがた）にも触れますよ！さっそくCarPlayからお昼のピザの注文を……えっ？電話じゃないと注文できないの？？ていうか数百メートル先にHazard Aheadってなになに！？！？

話すこと

• 日本との違いは右側通行だけじゃなかった…
• 助手席からあるとありがたいサポート
• アメリカのCarPlayを研究だ🔍

対象者

• 観光や交流もしなくちゃもったいないと思っている人
• 正直ライドシェアに乗るのが怖い人
• アメリカにおけるCarPlay（navigation, quick food ordering）に興味がある人🍕

2017年以来お世話になった西早稲田。過去参加された方はこの地にいろんな思い出をお持ちでしょう。

あれ？私、駅と63号館との往復しかしてないや。高田馬場や西早稲田や大学のことを何も知らない。たくさんお店があるのに、母の生まれ育った地なのに、10年前に理工展の人と交流したことあるのに、この街のことを何も知らない…！

本記事では、高田馬場&西早稲田を何も知らないまま有明へ行く皆さんのために散策用のマップを提供します。
機会を見つけて散歩してみると面白いですよ！

【掲載内容】

★高田馬場&西早稲田エリアの散策マップ
学生街と住宅街がいい感じに隣り合った街並みを紹介します。
ときどき史跡があったり、少し東に行くとヤギさんがいたりします。

★高田馬場&西早稲田メシの食レポ
個人的に気になったお店をいくつか紹介します。
高田馬場といえばラーメンですが、甘いものも要チェックです。それにカレーとラム。

★早稲田大学西早稲田キャンパスができるまでの歴史
山手線内にまとまった土地があったということは、つまりそういうことですね。

★理工展2024の参加レポ
去年参加された方は、iOSDC Japan 2024のフォトモザイクに「理工展にもきてね！！」と書き込まれていたことに気づいていましたか？私は行ってきましたよ！
学園祭はお子様連れの皆さんにおすすめのイベントです。
理工展の様子はもちろん、キャンパスツアーや学生チーム開発ノウハウ共有カンファレンスも紹介します。

【こんな人におすすめ】

• 街歩きが好きな人
• 食いしん坊な人
• 63号館と居酒屋にしか目がいってなかった人
• こっちのキャンパスにも大隈重信像があることに気づかなかった人