WWDC26を整理する。iOS 27、 Xcode 27、Foundation Models、SwiftUI/UIKitの変更点

Tech

WWDC26で発表された、iOS 27世代の開発者向け変更をiOSエンジニア目線で整理します。

今回のWWDC26は、iOS 27やApple Intelligence、Siriのようなユーザー向け機能だけを見る回ではなさそうです。実務目線では、Xcode 27、agents、Device Hub、App Intents、SwiftUI/UIKitのリサイズ対応、Swift 6.3 / 6.4あたりの方が、既存アプリへの影響として先に効いてくるかもしれません。

この記事では、すべてのセッションを網羅するのではなく、実務や既存アプリに影響しそうなものを中心に見ます。

ざっくり何が変わり、どのあたりに影響しそうか。クライアントに聞かれたときに、何を確認してから答えるべきか。そのためのメモです。


全体像:見るべき変更点

今回、iOSエンジニア目線で見る範囲は次のあたりです。

領域主な公式セッション・ページ見る理由
iOS 27 / iPadOS 27Platforms State of the Union / Modernize your UIKit app既存アプリの表示、リサイズ、UI対応、Apple Intelligence連携に関わる
Xcode 27 / agents / MCP / Device HubWhat’s new in Xcode 27 / Xcode, agents, and you / Xcode guideビルド・テスト・実機確認のループにAIが入る可能性がある
iPhone Mirroring / iPad resizingModernize your UIKit app既存iPhoneアプリのレイアウト確認が必要になる可能性がある
SwiftUIWhat’s new in SwiftUI / SwiftUI guideAsyncImage、@State、swipeActions、reorderableなど実務改善がある
Foundation Models / Core AIWhat’s new in the Foundation Models framework / Apple Intelligence guideApple標準AIをアプリに組み込む入口になる
App Intents / Apple IntelligenceBuild intelligent Siri experiences with App Schemas / Discover new capabilities in the App Intents frameworkアプリ機能をSiri、Shortcuts、Spotlight、Apple Intelligenceに出す入口になる
AppIntentsTestingValidate your App Intents adoption with AppIntentsTestingApp Intentsを実装だけでなくテスト対象にできる
Swift 6.3 / 6.4What’s new in SwiftConcurrency警告、anyAppleOS、async defer、性能改善などが既存コードに影響しそう
Trust and SafetyMeet Trust Insights / Secure your app: mitigate risks to agentic featuresAIやagentic featuresを入れるなら安全性・審査も見る必要がある

派手なのはApple IntelligenceやSiri AIです。

ただ、実務で先に効きそうなのは、Xcode 27の開発フロー統合、既存iPhoneアプリのリサイズ対応、App Intentsのテスト基盤、SwiftUIの細かい改善、Swift Concurrencyの診断まわりです。


Xcode 27:コード生成より、ビルド・テスト・実機確認ループを見る

What’s new in Xcode 27では、customization、coding agents、Device Hub、localization、performance、testing toolsが紹介されています。

Platforms State of the Unionでは、XcodeがMCP経由でFigmaやGitHubのような外部ツールと接続すること、Anthropic、OpenAI、GoogleのagentsをXcode内で扱えること、agentsがタップ、スワイプ、入力を行い、スクリーンショット付きでテスト結果を返す流れが紹介されています。

見るべきなのは、単なるコード生成ではありません。

Xcode agentsの価値は、Xcodeの開発ループにどこまで入ってくるかです。

見ること影響
MCP外部ツールやサービスをXcode内のagentとつなげる
agents調査、テスト、ローカライズ、アクセシビリティ改善に使える可能性
Device Hub物理・仮想デバイスを一箇所で扱う
build / testエラー確認、テスト実行、失敗解析に関わる
localizationString Catalogや翻訳作業の補助に関わる
/planのような計画ステップ作業範囲を確認してから進められる

CopilotやClaudeでもコードは書けます。

そのため、Xcode agentsを見るときは、コード生成能力だけではなく、Swift、Apple SDK、Preview、ビルド、テスト、Device Hubまで含めてどこまで統合されるかを見る方がよさそうです。

任せやすそうなこと慎重に見ること
小さな修正案設計判断を含む変更
テスト追加のたたき台既存仕様の解釈
エラー原因の調査大規模リファクタリング
ローカライズ補助文脈依存の文言
Device Hubでの確認補助本番影響のある変更

どこまで任せてよいか。差分を誰がレビューするか。既存コードを壊していないか。

Xcode 27はコード生成AIというより、ビルド・テスト・実行確認のループにagentが入ってくるものとして見た方がよさそうです。


既存アプリの地雷:リサイズ可能なiPhoneアプリ

既存アプリへの影響で一番泥臭そうなのは、iPhoneアプリのリサイズ対応です。

Modernize your UIKit appでは、iPhone Mirroring上のiPhone windowを自由にリサイズできること、iPhone-only appがiPad上でもリサイズ可能になること、そのためアプリは実行時のscene sizeに応じて動的に調整する必要があることが説明されています。

これは、SwiftUI/UIKit混在アプリだけの話ではありません。

固定サイズや端末の向きに強く依存している既存iPhoneアプリ全般で確認が必要になりそうです。

確認したいもの見る理由
scene sizeリサイズ環境では画面サイズが固定ではない
size classesレイアウト判断の中心になりやすい
safe area新UIやデバイス差分で崩れやすい
UIScreen.main参照sceneごとのサイズを見た方がよい場面が増える
userInterfaceIdiom判定iPhone / iPadだけで分ける設計が弱くなる可能性
Auto Layout / constraint固定幅・固定高さが崩れやすい
tab / navigation bar新APIやレイアウト変更の影響を受けやすい

古いiPhoneアプリだと、端末サイズやorientationに依存したレイアウト判断が残っていることがあります。

今までは問題になりにくかった実装でも、iPhone MirroringやiPad上のリサイズ環境で見える可能性があります。

Xcode 27のDevice HubやPreviewsを使って、Simulatorの端をドラッグしながら任意の画面サイズをテストできることも紹介されています。

従来の確認これから見たい確認
特定のiPhoneサイズで確認任意のウインドウサイズで確認
portrait / landscapeで確認scene sizeの変化として確認
実機・Simulatorを切り替えDevice Hubでまとめて確認
画面ごとに手動確認Previewやagent支援も使って確認
iPhone / iPadで分けるサイズクラスやscene geometryで見る

AI機能より先に、既存アプリの画面が崩れるかどうかの方が、実務では問題になりやすいかもしれません。


SwiftUI:地味だが実務に効く改善

SwiftUIについては、新しい見た目よりも、実務改善が気になります。

What’s new in SwiftUIやSwiftUI guideでは、新しいDocument API、reorderable container APIs、List以外へのswipe actions、confirmation dialogs、AsyncImageのHTTPキャッシュ対応、@Stateのmacro化、ViewBuilder / ContentBuilderの改善などが紹介されています。

派手ではありませんが、実務では効きそうです。

変更点何がうれしいか
AsyncImageのHTTPキャッシュ対応画像読み込みまわりで余計な自前実装を減らせる可能性
@Stateのmacro化状態保持まわりの挙動が整理される
Observable lazy initialization@Observableクラスを@Stateで保持するときの初期化タイミングが扱いやすくなる
ViewBuilder / ContentBuilderの改善ビルド時間改善に関係する
swipeActions on arbitrary viewsList以外でもスワイプ操作を使いやすくなる
reorderable container APIsList以外のcontainerでも並び替えを扱いやすくなる
Liquid Glass対応システム全体の新しい見た目への追従が必要になる
appearsActiveウインドウのアクティブ / 非アクティブ状態に応じたUI調整に関わる

特に、AsyncImageのキャッシュと@Stateまわりの変更は、既存アプリの挙動やパフォーマンスに関係します。

これまで画像読み込みやView再描画まわりで細かく気を使っていたところが、標準側で改善されるなら価値があります。

一方で、SwiftUIは動きが速い技術でもあります。

新しいAPIが増えること自体は良いですが、実務では既存UIKit資産、OS対応範囲、チームの経験値、デバッグしやすさも考える必要があります。

実務で見ること理由
既存UIKitとの混在一気にSwiftUIへ移行できないため
OSバージョン差分業務アプリでは対応OS範囲が問題になりやすい
パフォーマンス複雑な画面やリストで効く
Previewの信頼性画面修正の確認効率に関わる
Liquid Glass対応カスタムUIを持つアプリで影響が出やすい
safe area / window state新UIやマルチウインドウ環境で崩れやすい

SwiftUIは「新しいことができる」より、「既存アプリに入れやすくなったか」「細かい痛点が減ったか」を見たいです。


Foundation Models / Core AI:Apple標準AIをアプリに組み込む入口

AIまわりでは、Siri AIそのものより、Foundation Models / Core AIを見たいです。

Apple Intelligence guideでは、Foundation Models frameworkが、Apple Intelligenceを支えるオンデバイスモデルにアクセスできるSwift APIとして説明されています。

Apple Foundation Modelsだけでなく、ClaudeやGeminiのようなクラウドモデル、Language Model protocolに準拠するプロバイダーも扱えるとされています。

What’s new in the Foundation Models frameworkでは、Private Cloud Compute、サードパーティやオープンソースモデルの統合、Vision機能、Spotlightとの連携、Dynamic Profiles、Evaluations framework、fm CLI、Python SDKなどが扱われています。

ここは、単に「Siriが賢くなる」という話ではありません。

Appleが、アプリ開発者向けにAIを組み込むための抽象レイヤーを整えてきた、と見る方がよさそうです。

項目見ること
Apple Foundation ModelsApple標準のモデルをアプリから使えるか
Language Model protocol外部モデルも同じ抽象で扱えるか
Claude / Geminiなどクラウドモデルをどう統合するか
Private Cloud Computeクラウド処理時のプライバシー説明に使えるか
Vision画像入力や画像理解に使えるか
Spotlightアプリ内検索やsemantic searchに関係するか
Dynamic Profiles用途に応じたモデル・設定の切り替えに関わるか
Evaluations frameworkAI機能の評価をどう実装するか
fm CLI / Python SDK開発・評価・検証の補助に使えるか

業務アプリで考えると、使い道はあります。

用途
入力補助フォーム入力、メモ、問い合わせ文の整理
分類ユーザー入力や業務データの分類
要約長い説明文、履歴、メモの要約
検索補助アプリ内情報の自然言語検索
作業支援ユーザーの操作を補助する提案
画像理解画像入力を含むワークフローの補助

ただし、Foundation Models / Core AIだけでアプリが賢くなるわけではありません。

実務では、どの条件で使えるかが重要です。

確認したいこと理由
対応OS既存アプリで使える範囲が決まる
対応端末クライアント案件では古い端末対応が問題になりやすい
日本語対応日本向けアプリでは必須
オンデバイス / クラウドプライバシー、通信、コストに関係する
外部モデル利用利用規約、データ送信、費用、障害時対応が必要
出力の安定性同じ入力で安定して使えるか
失敗時のフォールバックAIが返せないときにアプリとしてどう落とすか
評価実装後に品質をどう測るか

Apple標準の強みは、OS、端末、Swift API、プライバシー、App Storeの文脈に乗ることです。

一方で、外部APIを使ったAI機能はすでに選択肢があります。外部モデルの利用条件や対応範囲は、モデル・プロバイダー側の仕様にも依存します。Apple標準の抽象レイヤーに乗ったからといって、すべてのモデルを同じ条件で扱えるわけではありません。

Apple標準に寄せる価値があるかは、端末条件、日本語、速度、コスト、失敗時設計を見てから判断したいです。


App Intents / AppIntentsTesting:外部公開APIとテスト基盤

SiriやApple Intelligenceを見るときに、個人的にはSiriそのものよりApp Intentsの方が気になります。

Apple Intelligence guideでは、App Intents frameworkがApple IntelligenceやSiri AIとアプリをつなぐ入口として説明されています。

Build intelligent Siri experiences with App Schemasでは、App Entities、App Schemas、App Intentsを使って、アプリのコンテンツや操作をSiriに理解させる流れが紹介されています。

Discover new capabilities in the App Intents frameworkでは、ValueRepresentation、RelevantEntities、EntityCollection、SyncableEntity、long-running intentsなどが扱われています。

App Intentsは、単なる「Siri対応」ではありません。

アプリの機能やデータを、Siri、Shortcuts、Spotlight、Widgets、Apple Intelligenceにどう露出するかという話です。

見ること影響
App Entitiesアプリ内データをシステム側にどう表現するか
App Intentsアプリの操作を外部からどう実行可能にするか
App SchemasSiriが理解しやすい形に機能を合わせる
RelevantEntities状況に応じて関係するentityを出せるか
EntityCollectionentity検索や取得の性能に関わる
SyncableEntity複数デバイス間でentityを扱う場合に関係する
long-running intents長時間処理やキャンセル処理に関わる
Spotlight連携アプリ内コンテンツの検索可能性に関わる
Shortcuts連携ユーザーや業務フローの自動化に関わる
onscreen context画面上の文脈をSiriが扱えるかに関わる

ここで重要なのがAppIntentsTestingです。

Validate your App Intents adoption with AppIntentsTestingでは、AppIntentsTestingが、Siri、Shortcuts、Spotlightと同じインフラを使ってApp Intentsを検証する新しいフレームワークとして紹介されています。

intentの実行、結果の確認、entitiesやqueriesのテスト、Spotlight indexing、View annotationsの検証が扱われており、UI AutomationなしでApp Intentsの動作を検証できる点が重要です。

テストしたいもの理由
intentの実行外部からアプリ操作が正しく動くか
entity querySiriやShortcutsから対象データを見つけられるか
複数intentの連携Shortcutsのような自動化で使えるか
Spotlight indexingアプリ内データが検索に出るか
View annotations画面上の文脈をシステムが認識できるか
test-only intentsテスト用の状態づくりに使えるか
CI連携継続的に壊れていないか確認できるか

Siri対応やShortcuts対応は、実装しただけでは終わりません。

アプリの機能やデータ構造が変われば、App Intents側も壊れる可能性があります。そこでUI Automationに頼らずに検証できるなら、CI上での確認や回帰テストに使える可能性があります。

App Intentsは、AIっぽい便利機能というより、アプリ機能を外部に公開するAPI設計です。

AppIntentsTestingは、その保守と品質確認のための基盤として見たいです。


Swift 6.3 / 6.4:警告、availability、非同期、性能

Swiftまわりは、AIやUIほど派手ではありません。

ただ、実務ではかなり効きます。

What’s new in Swiftでは、Swift 6.3 / 6.4の更新として、everyday language improvements、improved concurrency、safer high-performance code、Swift Testing、Subprocess、Foundation、Swift-C interoperability、Swift-Java、WebAssembly、ownership system / noncopyable typesなどが扱われています。

既存iOSアプリで特に気になるのは、次のあたりです。

変更点見る理由
Taskのthrowエラー無視警告非同期処理の見落としに気づける可能性
async defer非同期クリーンアップを書きやすくなる
anyAppleOS availabilityApple各OS向けのavailability指定を簡潔にできる
@diagnose特定の警告を宣言単位で制御できる
module selectors ::モジュール名と型名の衝突を明確にできる
Swift Testing updates既存テストの移行やCIに関わる
Subprocess 1.0ツールや補助処理を書く場合に関係する
ProgressManagerasync/await時代の進捗管理に関係する
Swift-C interoperability既存C資産との接続に関わる
Span / noncopyable / ownership高性能・低コピーなコードに関わる
UniqueBox / UniqueArray / Ref所有権を意識した標準ライブラリ型として見る

特にTaskのthrowエラー無視に警告が出るようになる点は、既存コードに影響しそうです。

今まで黙って見逃していた危ない非同期処理に気づけるなら良い変更です。ただし、実務では警告対応のコストが出ます。

見ること影響
Taskのエラー無視既存コードで警告が増える可能性
async/awaitcallbackやCombineとの接続に影響
actor境界データ競合やSendableまわりに影響
Combine既存資産として残る可能性が高い
RxSwiftからの移行Combine / Concurrencyへの移行方針に関係
CI警告増加やビルド設定によって影響が出る
Swift TestingXCTest資産との接続や移行に影響

自分の実務文脈では、UIKitからSwiftUI、RxSwiftからCombineまたはSwift Concurrency、古い非同期処理からasync/awaitへ、という移行が絡みやすいです。

新規開発なら新しい書き方に寄せやすいですが、実務では既存コードがあります。

そのため、Swiftの変更は「便利になったか」だけでは見ません。

既存コードで警告が増えるか。チームで直せる範囲か。Combine資産とどう接続するか。actor境界やSendable対応でどこまで影響が出るか。

ここは地味ですが、実務では重要です。


App Store / Trust and Safety:AI時代は審査・安全性も見る

AIやApp Intentsをアプリに入れるなら、技術的に動くだけでは足りません。

App Store審査、プライバシー、ユーザーデータの扱い、安全性も見る必要があります。

WWDC26のセッション一覧には、Meet Trust Insightsや、Secure your app: mitigate risks to agentic featuresのようなセッションもあります。

特にAI機能では、入力データ、出力結果、外部モデル利用、オンデバイス処理、Private Cloud Compute、ユーザーへの説明、失敗時の処理が問題になります。

見ること影響
個人情報AI処理に渡してよいデータか
業務データクライアントに説明できる処理経路か
外部モデル利用規約・データ送信・コストに関わる
オンデバイス処理プライバシー面では説明しやすい可能性
Private Cloud Computeクラウド利用時の説明材料になる
AI出力誤回答や不適切出力への対処が必要
agentic features自律的な処理をどこまで許可するか
App Store審査AI機能やデータ利用の説明が必要になる可能性

「Apple標準だから安心」とは言えません。

Apple標準であっても、アプリ側がどのデータを渡し、何を実行可能にし、失敗時にどう扱うかは設計の問題です。


クライアントに説明する前に確認したいこと

WWDCの発表は、開発者だけでなくクライアント側の関心にも影響します。

特にAIや新しいUIは、「うちのアプリにも入れられますか」と聞かれやすい領域です。

ただ、ここで「できます」とすぐに言うのは危ないです。

実際には、対応端末、OSバージョン、API制約、日本語対応、審査、運用コストがあります。

クライアントの関心エンジニアとして確認したいこと
AIをアプリに入れられるかApple標準APIで可能か、外部APIが必要か
Siriやショートカット連携App Intents / App Schemasでどこまでできるか
アプリ内検索を賢くできるかSpotlight、semantic search、LLM searchを使えるか
新しいUI対応見た目を変える必要があるか、工数はどれくらいか
iPadやMacでの表示iPhone MirroringやiPadリサイズに耐えられるか
対応端末古い端末でどこまで動くか
プライバシー個人情報や業務データをどう扱うか
審査App Store審査で注意点が増えるか
テストApp IntentsやAI機能をどう検証するか
保守intent、schema、UI、OS差分をどう維持するか
開発効率Xcode agentsで本当に工数が減るか

クライアントに説明するなら、発表内容の雰囲気ではなく、実装条件と制約を見てから話したいです。


betaで確認したいこと

発表を見ただけで結論は出せません。

あとでbetaや公式ドキュメントを見ながら、次の点を確認したいです。

確認したいこと見る理由
Xcode agentsの差分品質既存コードを壊さないか見るため
Xcode agentsのテスト連携実行結果をどこまで信じられるか見るため
MCP連携外部ツールとの接続が実務に使えるか見るため
Device Hub実機・Simulator・リサイズ確認の効率を見るため
iPhone Mirroring / iPad resizingレイアウト崩れやorientation依存を洗い出すため
UIScreen.main / orientation依存既存コードで問題になりそうな箇所を確認するため
SwiftUIのAsyncImage cache既存の画像読み込み実装とどう棲み分けるか見るため
@State / Observable lazy initialization再描画や状態生成の挙動を見るため
Foundation Models / Core AIの対象端末クライアント案件で使える範囲を判断するため
日本語での挙動日本向けアプリでは必須
オンデバイスAIの速度実用的なUXになるかを見るため
Private Cloud Computeの扱い業務データを扱うときの説明に関わる
失敗時のフォールバックAIが答えられないときの設計が必要
App Intentsの設計どの機能を外部公開するか判断するため
AppIntentsTestingSiri / Shortcuts / Spotlight連携を保守できるか見るため
Swift Concurrencyの警告既存コードへの影響を見るため
Swift 6.3 / 6.4の新機能availability、async defer、ownershipまわりの影響を見るため
App Store / Trust and Safety審査やプライバシー対応の変化を見るため

WWDCの発表は入口です。

実際に開発者として使えるかは、betaで触り、ドキュメントを読み、既存案件に当てはめてみないと分かりません。


まとめ

WWDC26は、Apple IntelligenceやSiri AIだけを見る回ではなさそうです。

iOSエンジニア目線では、Xcode 27、agents、MCP、Device Hub、iPhoneアプリのリサイズ対応、SwiftUIの実務改善、App Intents / AppIntentsTesting、Swift 6.3 / 6.4の方が、既存アプリや実務に先に効いてくる可能性があります。

Xcode 27はコード生成AIというより、ビルド・テスト・実行確認のループにagentが入ってくるものとして見るべきです。

iPhoneアプリのリサイズ対応は、固定サイズやorientation前提の実装が残っている場合、AI機能より先に問題になりやすい。

SwiftUIは、AsyncImageのキャッシュ対応、@Stateのmacro化、swipeActions、reorderable APIなど、派手ではないが実務に効きそうな改善があります。

Foundation Models / Core AIは有望ですが、端末条件、日本語、失敗時設計を見ないと実務採用は判断できません。

App IntentsはAPI設計として、AppIntentsTestingはその保守基盤として見たいです。

クライアントに「できます」と言う前に、まずbetaで確認する。

今回のWWDC26は、その確認項目を洗い出す回として見ています。


参考リンク

Apple公式・全体

Xcode 27 / agents / Device Hub

iPhoneリサイズ / UIKit / SwiftUI

Foundation Models / Core AI / Apple Intelligence

App Intents / AppIntentsTesting

Swift 6.3 / 6.4

Trust and Safety / App Store

コメント

タイトルとURLをコピーしました