トーク

iOSアプリエンジニアとして、ビジネスやデザインの要望にただ従うだけになっていませんか？
iOSプラットフォームは我々の手で育てていくものであり、その中で「iOSらしさ」をどう守り、活かすかが重要です。

このLTでは、ガワネイティブやクラスプラットフォームによる開発が広まる中で、iOSアプリをあえてネイティブで作ることを提案・実現していくための考え方を紹介します。
「これがiOSの良さ」と言えるポイントを明確にし、プロダクトの方向性にiOS開発者として主体的に関わるきっかけになれば幸いです。

皆さん、iOSアプリ開発でTCAを使ったことはありますか？

正直、TCAってめっちゃ難しいですよね...
TCAはiOSアプリ開発において採用されることが多いアーキテクチャパターンの1つです。
単方向データフローにより処理の流れの処理の流れが追いやすく、またアプリの状態管理やコンポーネントごとのテストが実施しやすいという特徴がある一方、コードの書き方が独特で初期学習のコストが高く、規模が小さいアプリではオーバーエンジニアリングになりがちというデメリットもあります。

最近は勉強会や技術記事で取り上げられる機会も多く、また公式のチュートリアルも充実しているため、TCAを導入するハードルはかなり下がりました。
しかし、これらで触れている内容はあくまで「導入」や「コーディング」に関することであって、アプリの「運用・保守」に関する情報はあまり多くないように感じます。

最近はTCAを採用したアプリも多くリリースされており、私も複数のプロジェクトでTCAを使った新規開発や保守・運用を経験してきました。
実務でTCAを使った開発を行う中で、勉強会や技術記事などではあまり触れられていなかったTCAのメリット・デメリットは想像以上に多くありました。
このトークでは、私が実際にTCAを使ってみて率直に感じたホンネを皆さんと共有したいと思います。

アプリのアーキテクチャというものはコードの根幹を支えるものであり、一度決めると変更することはなかなかできません。
現在アーキテクチャ選定に悩んでいる人や、これからアプリ開発を行う人に向けて、このトークを贈りたいと思います。

ベンチャー企業から有名ベンチャー企業への転職を成功させ、年収アップを実現した私の経験とそのコツについてお話しします。

まず、転職を考えた理由ですが、キャリアアップと年収の向上を目指していました。特に35歳を過ぎるとリーダー経験が求められることが多く、転職難易度が上がるため、若いうちに戦略を練ることが重要です。

私が転職を成功させたポイントは以下の通りです：

「技術スキルの向上」
Swift、Objective-C、そして最新のiOSフレームワークを使いこなすことができるようにしました。
特にSwiftUIやCombineなどの新しい技術を積極的に学び、プロジェクトに適用しました。

「問題解決能力」
チーム内でのコミュニケーションを重視し、問題が発生した際には迅速に対応しました。
例えば、アプリのパフォーマンスが低下した際には、コードの最適化とアーキテクチャの見直しを行い、パフォーマンスを30%向上させました。

「職務経歴書の見やすいフォーマット」
職務経歴書は、プロジェクトごとに成果を数字で示し、具体的なエピソードを交えて記載しました。

「面接官との想定問答」
面接官が求める人材や解決したい課題を事前にリサーチし、それに対する解決策を具体的なエピソードで説明しました。

「リーダー経験の積み方」
若いうちからリーダー経験を積むために、プロジェクトリーダーやチームリーダーの役割を積極的に引き受けること。

「会社の情報を洗い出すAIプロンプトの紹介」

転職先の会社がリモートワークに適しているか、出社が求められるかなど、自分に合った働き方ができるかをリサーチするために、AIプロンプトを活用しました（本番で詳細にお伝えいたします）

これらの戦略を駆使して、私は転職を成功させ、年収アップを実現しました。ぜひ参考にしていただきたいです！

In-App Purchases(以下IAP)のサービスを展開していると、様々な問題に遭遇することがあります。
例えば申請内容に不備があってrejectされてしまった、IAPの公開日時が設定できない、求められるアカウント権限が強すぎてやりたい操作ができない、App Storeでエラーが出ているがこれってユーザーに告知していいの、などなど。。。

これらの問題についていろいろ質問したいなぁと思っていたところ、運よくWWDC25に参加できることになりました。
また現地ではApp Storeのオフラインlabが開催されており、実際に参加し色々質問してくることができました。
ただ人気のlabのため事前登録が必要、labの時間は15分のみ、通訳もなく英語に自信がない、Apple Parkは初めていくので色々と不安な自分は色々と準備をしていくことになりました。。

このトークでは、App Store Lab参加までの準備や実際の様子、何を質問し何を得られたのかを共有をします。
labには何を準備していったら良いのか、現地labはどんな様子なのか、labでは何を得られるのか、皆さんのlab参加への一助になるような話ができればと思います。

ゴール:
・Appleのlabに参加するためにやっておいた方が良い準備がわかる
・実際のlabの様子を知り、labに参加する意欲が湧く

アジェンダ:
・何に困っていたのか
・App Store Lab参加のための準備
・labの実際の様子、得られた回答

対象者:
・labの様子や回答内容が知りたい方
・labに参加してみたいがまだ勇気が出ない方

ちょっとそこのあなた、「Swift 6の新機能を使いたいのにSwift Concurrencyの対応をしないとまだSwift 6にはできない」などと思っていませんか？

もしあなたがXcode 16をインストールしXcode CLI ToolsをXcode 16と設定してビルドできている時点で、実はもうSwift 6によってアプリをビルドできているのです。なぜなら、Xcode 16のCLI Toolsに同梱されるSwiftコンパイラバージョンはSwift 6だからです。つまり、あなたはすでにSwift 6の言語機能も使えるんです。

勘違いの原因として、デフォルトでlanguage-modeがSwift 5と設定されていることをSwift 5系でコンパイルしている、と勘違いしている可能性があるんじゃないでしょうか。またはPackage.swiftの最上部に書かれた// swift-tools-version: 5.xをコンパイルするSwiftのバージョンと勘違いしているということはないでしょうか？

このLTでは、CLI Toolsの基礎、コンパイラバージョンとlanguage-modeの違い、それが提案されたSwift Evolutionのプロポーザルなどについて話します。

Liquid Glass、いいですよね。私もユーザーとして触ってみたいです。

Liquid Glass といえば、Flutter は独自のレンダリングエンジンで画面を描画しているため Liquid Glass を使えず公式も対応を見送っている、という話をご存知でしょうか。ということは Flutter を使っている限り「古い」見た目のアプリしか作れないのでしょうか？

、、と悲観的に見てしまうのはちょっと軽率です。

そもそも Flutter の UI に対する優先度はそこではありません。Flutter の UI に対する姿勢には「プラットフォーム標準」よりも優先したい要素があり、Flutter アプリ開発者にとって Liquid Glass の完全再現はそこまで求めるものでもなかったり、というかそもそも「Liquid Glass が使えない」にも語弊がありまして、、そんな話を 5 分間だけ好き勝手に話させてください！

AVFoundation は高機能なカメラアプリを作る上では欠かすことのできないフレームワークです。

AVFoundation は iPhone のカメラ関連のハードウェアと共に進化してきました。

本トークでは、時系列に iPhone のカメラ機能の進化を見ながら、 AVFoundation のカメラ関連の API がどのように変化してきたのかについて紹介します。

今後のカメラ機能の進化に備え、これまでの歴史を今一度振り返りましょう！

「空間だからこそできる動画編集体験」を目指し、Apple Vision Pro上で直感的に操作できる動画編集UIをRealityKitとSwiftで実装しました。
トリム、プレビューなど従来は2D平面で行っていた操作を、空間上に拡張することで身体感覚と結びついた編集体験を実現しています。

本セッションでは、以下のような実装事例と工夫を、Vision Pro実機でのデモを交えて紹介します：

• 空間タイムライン：自分の前方に展開される映像軸を、手や視線で操作可能に
• ジェスチャー・Gaze操作： 直感的にトリム／再生／選択できるUIコンポーネントの設計
• カット編集・プレビューの一体化：動画の前後関係を空間で俯瞰し、リアルタイム編集が可能

特に「視線・身体位置・奥行き」という空間コンピューティングならではの要素を活かしたUX設計とその技術的裏付けを解説します。

動画編集に限らず、空間UIで複雑な操作を扱いたい方や、Vision Proで直感的で没入感のあるツール設計を目指す開発者にとって有益な内容です。

SwiftでもProcessingのように気軽にクリエイティブコーディング作品を作りたい、そんな思いから作成したSwiftyCreativesライブラリについて紹介します。
このライブラリではMetalベースの独自レンダラーを実装しており、circle()やpush()など直感的なAPIを用いてiOS/macOS/visionOSアプリ上にリッチな2D/3Dグラフィックスを表示させることが可能になります。
本LTではSwiftyCreativesの設計思想とともに、このライブラリを用いたアート作品制作事例、そして公開アプリでの活用事例を紹介し、Swiftを用いたクリエイティブコーディングの可能性を提示します。

公開URL
https://github.com/yukiny0811/swifty-creatives

内容
・既存のMetalラッパーでは満足できなかった背景
・実際にこのライブラリを用いて作った作品を紹介
・コア設計について
・visionOS対応について
・Swiftでクリエイティブコーディングをすることの良さ
・公開アプリでの活用事例紹介

コード例

class MySketch: Sketch {
    override func draw(encoder: SCEncoder) {
        color(1, 0, 1, 1)
        box(1, 1, 1)
        push {
            translate(5, 0, 0)
            box(1, 1, 1)
        }
    }
}
struct ContentView: View {
    var body: some View {
        SketchView(MySketch())
    }
}

Apple から Swift-Java Interoperability への OSS コントリビュートを広く募っています。筆者が環境構築を行なった際に遭遇した事象から Issue を作成してレポートを行い解決に至った事例を紹介します。

Swiftは年々進化を続け、私たちiOSエンジニアに多くの便利な言語機能を提供してくれています。
しかしながら、普段Swiftを書いていて何気なく使っている言語機能がなんという正式名称なのかも知らないなんてことも多いでしょう。

このトークでは、私が日々の開発の中で「これは便利！」「Swiftらしい！」と感じているお気に入りの言語機能を発表します。
なぜそれらが好きなのか、どんな場面で役立つのか、現場での活用例やTipsも交えながら、短い時間でギュッとお伝えします。

Swiftの言語機能をもっと使いこなしたい方や、他のエンジニアがどんな機能を推しているのか知りたい方におすすめの内容です！一緒にSwiftの楽しさを再発見し愛でましょう！

SwiftUIを用いた宣言的UI開発における状態管理では、ライブラリを活用した巨人の肩に乗るアプローチや、独自実装を選択するアプローチなど、さまざまな選択肢が存在します。

本トークでは、コミュニティで広く適用されているTCA（The Composable Architecture）やMVVMとの比較を簡単に行いながら、Fluxのデータフローを実現するWebフロントエンドライブラリZustandを基にしたSwiftUI実装時の必要最低限のストア実装を紹介します。
Fluxデータフロー、SSoT（Single Source of Truth）を叶えるシンプルな選択肢の一つになれば幸いです！知見をお届けします！

こんな経験ありませんか？
C言語ライブラリのエラーコードをSwift.Errorとして扱えたら楽なのに...
C言語関数を使う際に必要なUnsafeMutablePointerを間違えた操作をしてクラッシュしてしまった...

その不満、関数にattribute(属性)を足すだけで、解決できるかもしれません。
上記の例ではエラーコードの宣言箇所にattribute((ns_error_domain(CustomError))を追加するだけでSwiftではErrorに準拠したCustomErrorとしてモダンに扱えます。
また、Xcode26から導入される__counted_byを使えばコンパイラレベルでC言語関数を安全に呼び出せることを保証できるかもしれません。

本トークでは、そんなSwiftの特徴であるモダンな文法やメモリ安全性を、attributeやannotationをたった1行付与することでCファミリーAPIに持ち込むユースケースを解説・紹介します。

実際の現場での導入事例やXcode26で利用できる新たなアノテーション(counted_by)の使い方を紹介しながら、「書き換えゼロのセーフティ向上」と「API が一気に Swifty になる爽快感」をお届けします。

WWDC25 と同時に映画『F1: The Movie』の予告編「Haptic Trailer」が公開され、 iPhone の Apple TV+ アプリで見ると映像に合わせてデバイスが振動し、まるでF1ドライバーになったかのような感覚を体験できると話題になりました。振動による力強いエンジンの再現には、多くの方が驚かれたことでしょう。

iOSエンジニアの皆さんなら、「この機能はどのように実現されているのか？」と興味を持たれたのではないでしょうか。調査の結果、新しい体験と感じられたこれは、1st PartyであるAppleにしかできない事...ではなく、我々3rd Party開発者にも利用可能な AVFoundation や Core Haptics のAPIで実現できることが分かりました。プラットフォームの能力を理解し、最大限に活用することは、優れたユーザー体験の創造において非常に重要です。紐解いていく過程も含めて詳細を共有しますので、皆さんが動画にプラスアルファをして素晴らしい体験を作るための参考になればと思います。

SwiftUIをメインで使っているプロダクトでは、デザイナーやPdMとのやり取りで誰もがこんな経験をしたことがあるのではないでしょうか。

👩‍💼： 「この機能、〇〇アプリみたいなUIにしてください！」
🧑‍💻： 「了解です〜！」
（実装中・・・）
🧑‍💻： 「iOS 15や16だとちょっと上手く動かないんですよね…」
👩‍💼： 「えっ、〇〇アプリではできてますよ？」
🧑‍💻： 「ちょっとやり方変えてみますね…（仕方ない、UIKitを使うか…）」

SwiftUIは年々進化していて、新しい表現力やインタラクションを作り出せる強力なツールです。しかし、多くの有名アプリではまだUIKitが使われており、デザイナーやPdMがそれらを参考にすることも多いです。その結果、SwiftUIだけでは再現が難しいUI表現を求められる場面がよくあります。

開発者は、UIViewRepresentableやUIViewControllerRepresentableを使ってUIKitを取り入れる選択を迫られますが、これによりSwiftUI本来の宣言的なスタイルや一貫した状態管理が崩れ、保守性や可読性に新たな課題が生まれます。

このLTでは、実際に「SwiftUIだけでは実装できなかったUI」や、「UIKitを使わざるを得なかったシーン」を例に挙げつつ、そのときに考えた工夫やトレードオフを共有します。たとえば、カスタムトランジションやインタラクティブなスクロール、特殊なジェスチャー処理など、現場でぶつかったリアルな壁を紹介します。

Swift は値型を中心とした言語です。値型を用いてコードを書くと、あるオブジェクトを変更したところ、別のオブジェクトも一緒に変更されてしまった！のような意図しない変更を防ぐことに繋がります。

では、Swiftにおける値型と参照型の違いはなんでしょうか。上記のようなオブジェクトの振る舞いから説明する人もいるでしょう。公式ドキュメントを確認すると、値型は、変数や定数への代入、または関数への引数渡しのときに、値がコピーされる型であると定義があります。一方で参照型は、変数や定数への代入、または関数への引数渡しのときに、コピーされるのではなく、インスタンスへの参照が使用される型であると記載があります。

さて、WWDC24「Consume noncopyable types in Swift」の動画の中で、以下のような言及があります。
「Notice how copying worked the same in both cases. The only difference is whether you're copying a value, or a reference.」
「どちらの場合も（struct も class も）、コピーの動作は同じでした。 唯一違う点は、値をコピーするか、参照をコピーするかという点です。」

あれ？！値型と参照型のコピーの動作って同じなの？！
公式ドキュメントに、参照型はコピーされないって書いてたよ？
一体、どっちが正しいの？！

このLTは、公式ドキュメントとWWDC24のセッション動画との表現上の対立の謎に迫り、そして真理を求める人間が、Swiftの内部実装を紐解きオブジェクトのコピーとは何かを理解することに自らの信念と命を掛けた物語です。「コピーとは何か？」を突き詰めることで、改めて値型と参照型のそれぞれの内部動作の違いに迫ります。

近年よく「成長機会」「開発者体験」「イノベーション」などのワードを耳にすることがあると思いますが、あなたの組織ではこれらに対して取り組むことができているでしょうか？

私の所属している株式会社kubellのiOSアプリ開発グループでは、今年から「学びラボ」という新たな取り組みを開始しました。
『学びラボ』とは「通常業務とは離れて興味のある内容を自由に学ぶことができる日」を新設し、iOSメンバーの成長機会創出や、学習したことや得たアイデアなどによる業務への貢献、学びの発信による採用ブランディングなどを期待した取り組みです。
この取り組みにより、iOSエンジニアが作成したプロトタイプの機能が実際のプロダクトへ取り込まれたり、学んだことを外部登壇で発信したりといったような成果が出ています。

本セッションでは

• 学びラボの運用方法
• 実際に取り組まれたことや得られた効果
  についてお話しします。

組織として成長機会の創出や開発者体験向上、業務改善を推進したい方は必見です！

生成 AI の進化により、個人でも驚くほどのスピードでアプリを開発できる時代になりました。
しかし「開発は速いけれど、マーケティングにかけられる予算はごくわずか……」というジレンマに直面する方も多いのではないでしょうか。

本 LT では、“少額”でも効果を出すアプリマーケティング手法を、国内外の成功事例や各種リサーチをもとに整理し、5 分に凝縮してご紹介します。

具体的には
• ASO（App Store Optimization）を最短で回すチェックリスト
• ブログ／LPなどを活用した「検索＆メディア流入」に関して
• 低コストでの広告運用

など、今日から試せる具体的アクションを中心にまとめます。開発フェーズだけでなく、その先のユーザー獲得までを視野に入れ、AI 時代を戦い抜く個人開発者の“少額マーケティング”を一緒に考えましょう。

ーーー時は令和7年、そこには決して負けられない戦いがあったーーー

SwiftUIが初登場して2年後に出たiOS15。かなり使いやすくなったかと思いきや、サポートするにはまだ不便な部分も多く、数多の検証を繰り返しながらようやくサポートすることができました。

とはいえ、現時点でなんとXcode26 Beta2 Release Notesに、「The Xcode 26 beta 2 release supports on-device debugging in iOS 16 and later」と書かれています。

お疲れ様の気持ちを込めて、時にUIKitの力を借り、時にデザインの調整を行い、時に妥協案を考えながら、iOS15をサポートするために実践した泥くさい戦いの軌跡について語ります。

モバイルアプリ開発において、ユーザー行動を把握し改善に繋げる上でイベント計測は不可欠です。
しかし、その恩恵を最大限に受けるためには、イベント名やパラメータ名をアプリコードに正確に実装する必要があります。
この「実装」のプロセスが、いかに退屈で、手作業によるミスが生まれやすく、そして長期的なメンテナンスにおいて多大なコストを要するか、多くの開発者が経験しているのではないでしょうか。

私達はこの長年の課題を解決するために、イベント定義（イベント名、パラメータ名）を記述したCSVファイルから、Swiftのenumコードを自動生成する社内ライブラリを作りました。
まず、スプレッドシートやエクセルでイベント定義を書き、それをCSV形式で出力します。そのCSVをツールに渡すだけで、イベント定義がSwiftのコードに反映されます。
手作業での文字列定義やタイプミスから解放され、イベント実装の速度と正確性を飛躍的に向上させることができるのです。

【話すこと】

• イベント実装を手作業で行う退屈さ・リスク
• ツールでできること・できないこと
• ツールの技術的解説
  • CSVパースからenumコード生成までのプロセス
  • Packageとしての実装のポイント
• ツール導入により得られた結果（コードの安全性向上、新機能追加時のイベント定義・実装コスト削減など）

このセッションを通じて、イベント定義・実装にまつわる退屈な作業から解放され、より本質的な開発に時間を費やしたいと考えるiOS開発者の皆様に、具体的な解決策と新たな視点を提供できれば幸いです。