トーク

JetbrainsのAppCodeが販売終了した年の2022年4月に私はAndroidエンジニアからiOSエンジニアになりました。
使い慣れたJetbrains製のIDEへ恋い焦がれつつも、わたしは、かの有名な IDE に慣れ親しんでいきました...。

それから3年の時が経った。
ときは2025年某日、Android StudioのKotlin Multiplatform向けプラグイン “Kotlin Multiplatform IDE plugin” がiOS開発を強力にサポート！遂にわたしが恋い焦がれた状況が結実。

待ち望んだ状況を迎え、Kotlinの存在しない、Pure SwiftのiOSアプリ開発環境をAndroid Studioで構築し、快適に開発することができるのか！？あの有名なIDEとの関係性はどうなってしまうのか。

いまAndroid StudioでiOS開発するための最短ステップを5分でお届けします。

ウワサの次期OS「iOS26」が話題の今、未来のデザインに胸を躍らせる今だからこそ、僕たちが毎日触れてきたiOSのUIデザインの歴史をタイムスリップしてみませんか？最新のデザインを深く理解するためのヒントは、そのルーツにこそ隠されているはずです！

このトークではまず、多くの開発者の記憶に刻まれているであろうiOS 6までの「スキューモーフィズム」の世界へご案内します。緑のフェルトが敷かれたGame Center、革の表紙がめくれるiBooks。なぜあの頃のUIは、現実世界の質感を忠実に再現しようとしていたのでしょうか？？

次に、世界に衝撃を与えたiOS 7の「フラットデザイン」への大転換を振り返っていきます！
アイコンから光沢が消え、UI全体がミニマルになったあの瞬間。
開発者たちが熱狂し、あるいは困惑したデザイン思想の変化を探っていきます！

そして、単なるフラットデザインに留まらず、すりガラスのような半透明のブラー表現、ウィジェットやLive Activitiesによる新たな情報提示、物理法則を感じさせるアニメーションなど、リッチでインタラクティブに進化した現在のデザインへと旅を続けます。

ベテランの方には懐かしさを、若手の方には新鮮な発見を。
スクリーンショット満載でUIの"エモさ"の変遷を辿り、未来のデザインを考えるきっかけを持ち帰っていただける、そんなLTです！

昨年、私が寄稿したiOSDC Japan 2024のパンフレット記事においてSwift Playgroundsを紹介した際、教育分野での活用の可能性に触れました。 今回のLTでは、その着想を実際に形にした、ZOZOでの「Girls Meet STEM」プログラミング体験イベントの学びを共有します。

イベントでは、AppleのSwift Playgroundsに標準搭載されているレッスンを活用し、中高生がプログラミングの基礎（条件分岐やループなど）を楽しく学べるよう取り組みました。実際に開催してみて、Swift Playgroundsはビジュアルプログラミングからのステップアップに適しており、教える側にとっても扱いやすいツールだと分かりました。LTでは、具体的な事例から見えてきた活用メリットとデメリットについてお話しします。

本イベントで得られた知見が未来のiOSエンジニアを育むきっかけとなり、iOSコミュニティのさらなる発展に繋がればと思います。

SwiftUIを使った機能開発が主流となり、複雑な動作も十分実装することができるようになりました。
iOS16以降ではmodifierが充実しており、大抵の機能はSwiftUIのみで実装可能です。
またWebSocketによる双方向リアルタイム通信もiOS13より標準でサポートされ、以前より導入しやすくなっています。

技術的には「簡単にできそう」に見えたリアルタイムチャット機能の実装でしたが、実際にプロダクションレベルで動くものを作ると想像以上に複雑でした。

このLTでは、実装過程で遭遇した「チャットUIのスクロール位置制御の困難さ」と「WebSocket通信のエラーハンドリングの複雑さ」について、実際のコード例を交えて紹介します。

SwiftUIでチャット機能を実装予定の方や、WebSocketを使ったリアルタイム通信を検討中の方に実践的な知見をお届けします。

エッジAIとは、iPhoneなどの端末上で直接動作するAI技術のことで、プライバシー保護やネットワーク帯域の節約など、さまざまな観点から注目を集めています。近年ではエッジデバイスの高性能化により、その存在感がますます高まっています。

しかし、実際にアプリにAIを組み込もうと思うと、さまざまな「迷いポイント」に直面します。
私自身、個人開発アプリにAIを導入する際に、

• 本当にエッジAIを使うべき？
• Apple純正からサードパーティ製まで多くのAPI・ツールの中で、どれを選べばいい？
• モデルやデータセットのライセンスは大丈夫？

といった疑問に悩み、何度も手が止まりました。

このLTでは、そんな試行錯誤の中で得た「迷いポイントの全体像」をベースに、iOSエッジAI導入の判断プロセスをフローチャート形式でサクサク整理していきます。
iOSアプリにAIを組み込みたいが、何から始めればいいか分からない──そんな開発者に向け、Apple公式資料だけではカバーされない導入判断フェーズの実践知を凝縮し、5分間でスッキリ理解できる判断軸をお届けします。

iOSは言語やフレームワークの進化が早く、技術的負債が溜まりやすい領域です。私が携わっている大規模サービスは約10年にわたり運用が続いており、その中で技術の進化に合わせて複数のアーキテクチャが共存しています。各アーキテクチャに適したライブラリやツールが導入されてきたことで、プロジェクト全体の構成が複雑化し、技術の全体像を把握するのが難しくなっていました。

こうした状況では、新しい技術の導入判断が難しく、技術選定が特定のメンバーの知見に依存してしまうことや、オンボーディング時の使用技術のキャッチアップに時間がかかるなど、複数の課題が浮き彫りになります。これらを解決するため、チームではThoughtWorksが提唱する「Technology Radar」を導入しています。

Technology Radarは、技術の採用や評価を4段階（Adopt / Trial / Assess / Hold）に分類し、意思決定を支援するフレームワークです。私たちはこのモデルをiOS開発に合わせてカスタマイズし、チームメンバー間でディスカッションを行い、現在プロジェクトに導入されている技術を網羅的に分類し可視化しています。

この取り組みにより、技術選定に一貫性が生まれ、レビューや設計の議論でも各技術の扱いが明確な前提のもとで議論できるようになりました。チーム内で“技術の地図”の共通認識があることで、意思決定のスピードと納得感が大きく向上したと感じています。

このトークでは、Technology Radarの基本的な概念から、iOS開発に合わせてカスタマイズしたフレームワーク、そしてチーム内での運用方法を紹介します。

Swiftの勉強を始めたばかりの頃は、自分のアイデアをアプリとして形にすること自体がとても楽しく感じられました。 しかし、学習や開発を重ねるうちに、エンジニアにとって重要なのは単なる実装に留まらず、いかに効率的かつ安全に実装できるかであるという考えを持つようになりました。

その中で「クラスと構造体を使い分ける際、メモリの観点ではどのような違いがあるのだろう？」という疑問が生まれ、やがてそれはより根本的なメモリ構造、つまりハードウェアレベルでのメモリの仕組みへの関心へと広がっていきました。 メモリにはコード領域・データ領域・ヒープ領域・スタック領域があり、それぞれの役割について図解しながら調べて学習を進めました。

この学習を通して、COW（Copy-On-Write）構造、クラスと構造体の選定基準、ARCやクロージャのキャプチャの仕組みなど、これまで何となく知っていたけれどうまく説明できなかった概念を、より明確に理解し、自分の言葉で説明できるようになりました。 今回のルーキーセッションでは、こうした学びと気づきを皆さんに共有したいと思います。

トーク内容

• コード・データ・ヒープ・スタックに関する概念の解説と図解
• クラス vs 構造体、値型 vs 参照型 ― 実際のメモリ使用の違いと選定基準
• Swiftにおける自動メモリ管理（ARC）とメモリリーク、クロージャのキャプチャ問題

チームで最も多くのバグを発見する私が、日常的に実践しているテストの観点を共有します。実装の隙を突くイレギュラーなテストでいかにしてアプリの品質を守るのか。その具体的な手法と、明日から実践できるマインドセットをお話します。

WebからiOS開発に転身した私が最初に直面したのは、「ドキュメントが抽象的で、読んでも実装のイメージが湧かない」という大きな壁でした。しばし実際に動作確認してみないと理解できないものが多々あり、スピードが求められる開発現場ではこの「試行錯誤の多さ」はボトルネックとなりました。なぜ、これほどまでに分かりにくさを感じるのか？ 本発表では、その原因をWeb開発者にはお馴染みのドキュメントMDN Web Docsとの「文化の違い」から考察し、筆者を救った「ドキュメント」についてお話します。

WWDC23でApple公式のローカライズ管理機能「String Catalogs」が発表されました。
しかし、初期バージョンでは、他のライブラリと比べて選択に迷う部分もあり、「他のローカライズライブラリの方が便利」「移行はまだ早いかも」と感じていた方も多いのではないでしょうか。

今年のWWDC25でString Catalogsの新機能が発表され、Xcode 26から利用可能になりました。
特に「Generated Symbols」機能により、TextやStringをシンボル指定できるようになり、利便性が大きく向上しています。
R.swiftやSwiftGenで実現できていた機能も登場し、いよいよ移行を検討するタイミングかも?

このトークでは、新しくなったString Catalogsの注目機能を紹介し、R.swiftやSwiftGenなど他のローカライズライブラリと比較しながら、その利点についてお話しします。

魅力的な体験や没入感のあるアプリを作るためには、写真や動画などのメディアコンテンツを効果的に表示することが欠かせません。
iOS標準のPhotoアプリでは、優れたレイアウトとジェスチャーに対応したインタラクションで写真・動画のコンテンツを心地よく閲覧できます。

Rettyでは、ユーザーさんが投稿した写真を「iOSのPhotoアプリのような体験で振り返られる」というコンセプトでメモリーズという機能を開発しました。
その際、UICollectionViewのCompositionalLayoutやTransitionLayoutを総動員して、モザイクレイアウトやレイアウトの切り替えなど、写真を振り返るリッチな体験を実装しました。

このLTでは、新機能の開発の流れを、ユーザー体験の作り込みや、それにまつわる技術的な観点でお話しします。

トーク内容:

• iOSのPhotoアプリにおける注目すべき体験
• メモリーズ機能で写真振り返り機能を実装した際の技術構成と実装の流れの紹介
• 没入感のある体験のためにUICollectionViewのカスタムLayoutやTransitionを作り込んだ箇所の紹介

参考:
メモリーズ機能: https://corp.retty.me/news/article/?id=8ahxxd_ukqf

Swift Package Manager（SPM）は、もはやiOS開発に欠かせないツールです。しかし、皆さんは Package.swift ファイルの中身をじっくり読んだり、自分でゼロから書いたりしたことがありますか？Xcode任せで、「とりあえず動けばOK」と思っていませんか？
このLTでは、まずSPMを使い始めたばかりの初心者の方に向けて、Package.swift の基本的な構造、各項目の役割、そしてシンプルなパッケージの作り方を分かりやすく解説します。そして、中〜上級者の方には、「え、そんなこともできるの！？」と膝を打つような、「カスタムビルドツールプラグイン」という応用テクニックをご紹介します。
この機能を使えば、Package.swift を起点にコード生成やリンティングといったビルドプロセスを自動化できます。普段意識しない Package.swift の奥深さに触れることで、SPMをより深く理解し、あなたの開発ワークフローをさらに効率化するヒントが得られるはずです。

「ゲームの攻略アプリやファンアプリを作りたいけど、著作権ってどうなってるの？」 個人でアプリ開発をしていると、誰もが一度はぶつかるこの疑問。特に既存の有名ゲームのキャラクターや世界観を使用することについて、漠然とした不安を抱えている方も多いのではないでしょうか。 本LTでは、実際に個人開発者が知っておくべき著作権の基本的な考え方や、実際にどこまでが許されて、どこからが侵害になるのかを、過去の事例や企業のガイドラインも交えて解説します。 法的な専門用語を避け、あくまで「個人開発者の目線」で、アプリ開発で著作権トラブルを回避するためのヒントをお伝えします。

筋トレを始めてすぐは効果を実感できますが、数ヶ月経つと目に見える成果が停滞し、モチベーションが低下しがちです。
私自身も筋トレを3ヶ月ほどやってきましたが、最近は成長の停滞を感じます。
そんな状況を打破すべく、Apple WatchやiPhoneで測定した体脂肪率、筋肉量、消費カロリーなどのヘルスケアデータをHealthKitを用いて「見える化」し、栄養素や運動量の数値の変化でどれだけの筋肉の成長が期待できるのかを検証していきます。
普段なんとなく計測しているApple Watchの運動量測定データを活用すれば、筋トレに効果的ではないかと考えたことが始まりです。
世の中には数多の筋トレ記録アプリがリリースされていますが、栄養素と運動量等のデータにフォーカスしたものは見つけられませんでした。
本発表では、HealthKitから得られるデータの紹介、取得したデータを活用した最適な栄養素の摂取量測定、実際にアプリを使用して得られた体脂肪率の減少や筋肉量の増加といった検証結果を紹介します。
HealthKitであなたの最適な身体作りプランを知り、筋トレの停滞を打破していきましょう！

　長年運用されてきたアプリケーションのデバッグメニューは、開発を円滑に進める上で不可欠な存在です。しかし、弊社のプロダクトに組み込まれたデバッグメニューは、開発当初から10年近く利用され続け、機能追加に伴う肥大化や、モダンな開発手法との乖離といった技術的負債に直面していました。特に、古い実装が原因でSwiftUIへの対応が困難となり、さらにはCocoaPodsからSPMへの移行が思うように進まないといった具体的な課題を抱えていました。

　本セッションでは、このレガシーなデバッグメニューをSwiftUIで全面的に刷新したプロジェクトの全貌をお話しします。リニューアルに至った背景から、その進め方、そして具体的な技術選定に至るまでを詳細に解説します。

具体的には、以下のようなテーマに焦点を当てて解説します。

• 旧デバッグメニューの課題と、それらを解決するための新しいデバッグメニューの設計思想。
• ネットワークログの収集にPulseを、一般的なログ出力にswift-logを導入した経緯とその効果、具体的な活用方法。
• 開発効率を劇的に向上させる新デバッグメニューに実装した便利機能の数々とその紹介 。
• そして、CocoaPodsからSPMへの移行に挑戦したものの断念せざるを得なかった苦い経験や、使えなくなってしまったUIデバッグツールへの対応 など、実務で直面した困難とそこから得られた教訓についても包み隠さず共有します。

このセッションを通じて、聴講者の皆様には、大規模な既存コードベースのモダナイズにおける具体的なアプローチ、最新のデバッグツールの導入と活用方法、そして現場で役立つ設計の知見を持ち帰っていただけます。技術的課題に直面している方、開発効率の向上を目指す方にとって、実践的なヒントと明日からの開発に活かせる学びを提供することをお約束します。

1. Rosetta 2とは
   • Rosetta 2について詳しく紹介します。
   • Rosetta 2に依存し続けることで将来的にどのような課題が生じるかを説明します。
2. 2つのCPU
   • Intel CPUとApple Siliconの特徴を比較し、それぞれの利点と制約を詳しく紹介します。
3. Rosetta 2なしで生きるために
   • Rosetta 2に依存しない開発手法の紹介。
   • Apple Siliconの特性を最大限に活用するための最適化手法を紹介します。

―「最近アプリがもっさりしてきた」「なんだか動作がもたつく」―
こうしたパフォーマンスに関するフィードバックを一度は受け取ったことがあるのではないでしょうか。
しかし、この「もっさり」は一体なにが原因で、どれくらい遅いのか？定性的な印象だけでは、改善の手がかりがつかめません。
弊社が開発しているアプリでも、特に利用頻度の高いユーザーから「もっさりする」といった声が寄せられていました。
そんな見えない「もっさり」の正体を明らかにし、改善につなげるためにMetricKitを活用しました。

このトークで話すこと

本トークでは、ユーザーの「アプリがもっさりする」という定性的な問題を、MetricKitを使って定量的に分析し、改善した方法を紹介します。

• MetricKitを使ったパフォーマンスの見える化
• メトリクスの分析から見えたボトルネックとなっていたCoreDataの処理
• 実際に行った改善アプローチとその効果
• コードのパフォーマンスを測定する方法

あなたのアプリにも、ユーザーがまだ言葉にしていない「もっさり」が潜んでいるかもしれません。
パフォーマンス改善の第一歩は、現在の状態を正しく測ること。つまり、「定量化」です。
本トークを通じて、ユーザーの体感を数字で捉え、改善へつなげる方法を知ることができます。
ユーザーから「アプリが軽くなった！」という喜びの声を聞く方法を一緒に学びましょう！

先日、生成AIのAPIを利用してユーザーがAIとチャットできるアプリをリリースしたところ、ユーザーがリクエストするプロンプトが激しすぎて1ヶ月でAPIレベルで垢BANされました。

生成AIを利用したアプリ開発では、利用規約で定められた禁止事項（違法行為助長、ヘイトスピーチ、誤情報拡散など）に抵触すると、APIレベルで利用制限や停止を受けるリスクがあります。多くの開発者が「運用開始時は問題なかったものの、禁止ワードや表現の見逃しで制限→サービス停止」という課題に直面しているのではないでしょうか？

本セッションでは、実際にGemini APIを中心に、禁止事項に引っかからないようにする対策から、Googleから警告が来た時の対処方法まで紹介します。

どこからでも触れるシングルトンは、スレッド安全性を保証しないまま肥大化しがちです。結果として実行時のクラッシュや不具合の温床になり、保守コストを引き上げます。Swift6では strict concurrency checkingがデフォルトで有効化され、Sendable 準拠や @MainActor／actor の宣言によって静的にデータ競合を防げます。シングルトンもここに乗せれば「安全な共有状態」へ生まれ変われます。

しかし、 巨大な責務を抱えアプリ全体の至る所から利用されてしまっているいわゆる"神シングルトン" は、Actor 化しようにも MainActor と非 MainActor のコードが混在し、さらには大量の状態管理を行なっているなど、Swift6への対応を複雑化させます。シングルトンを解体して適切な単位にリファクタリングすることはSwift6への対応においても、コードの保守性においても理想ですが、神シングルトンは影響範囲が広く、重要な機能を担っていることも多いため、現実的な選択肢としてリファクタリングを選択できないことも多いかと思います。

本トークでは、そんな神シングルトンを神シングルトンのまま実際に Swift 6 へ対応させた経験をもとに、対応する上でありがちな状況、工夫、知見を共有します。
皆さんのプロジェクトに眠る神たちをSwift6の世界に安全にお連れするためのご参考になれば嬉しいです。

Swiftで非同期処理といえば、かつてはClosure一択。ですが、複雑なネストや可読性の低さに悩んだ経験はありませんか？
本LTでは、若手エンジニアである私が「Closure地獄」から抜け出すきっかけとなった個人開発でのasync/await体験をもとに、チーム内での技術導入に挑戦した実話をお話しします。
私は学習の一環でFirebaseとSwiftUIを使ったチャットアプリを開発していました。そこではじめてSwiftのasync/awaitを本格的に使い、kotlinライクなtry-catch構文処理の見通しやすさ、エラーハンドリングの明快さに衝撃を受けました。
「これ、業務でも絶対に使える」
そう確信し、上司やチームの理解を得るために比較資料を作成し、サンプルコードを用意して小さなPull Requestから導入を開始しました。反対意見や不安の声もありましたが、自分で課題を見つけ、自分で提案し、自分でコードを書いて示すことで、徐々に受け入れられていきました。
今では、チームの新しいコードには自然にasync/awaitが使われるようになり、非同期処理の可読性が大きく改善されました。
この経験を通じて実感したのは、「仕事は与えられるものだけじゃない。自分で作ることもできる」ということです。
若手でも、技術の力でチームを変えられる。その一歩を踏み出す勇気を、このLTで少しでもお伝えできたら嬉しいです。