3行まとめ
Image Playground frameworkのImageCreator classは、iOS 27、iPadOS 27、macOS 27、visionOS 27以降で使えなくなる。
beta OSではXcode警告が出始め、ImageCreatorを使うTestFlight buildはruntime errorになる。
TestFlight配布前に依存箇所を探し、Image Playground sheet、別サービス、一時停止のどれで扱うかを決める。
大きなAI機能全体の話ではなく、ImageCreator依存がある画面を先に切り分けることが出発点です。
Appleは2026年6月11日、Image Playground frameworkのImageCreator classを廃止し、iOS 27、iPadOS 27、macOS 27、visionOS 27以降では動作しなくなると開発者向けに告知しました。
beta OSではコードはコンパイルされるもののXcodeで警告が出始め、ImageCreatorを使うTestFlight buildは機能せずruntime errorになる、とAppleは説明しています。public OS releaseではコードがコンパイルできず、該当機能も利用者側で動きません。
画像生成機能を持つアプリは、TestFlight配布前にImageCreator依存を探し、Appleが示したImage Playground sheetへ移すか、条件に応じて別の画像生成サービスへ切り替える判断が必要です。
ImageCreator廃止で何が変わるのか
betaで警告が出るだけの話ではなく、TestFlightとpublic OS releaseで別の失敗が起きる点を分けて見ます。
WWDC26後のApple Intelligence関連トピックでは、Foundation Models framework、App Intents、Xcode 27のagentic codingなど、大きな話題が並んでいます。ただし今回のImageCreator廃止は、AI機能全体の話ではありません。範囲はもっと狭く、そして実装済みアプリにとってはかなり具体的です。
Apple Developer Newsの告知によると、ImageCreatorはImage Playground frameworkに含まれていたclassで、アプリがオンデバイスの画像生成モデルを使ってプログラム的に画像を作るための入口でした。このclassが、iOS 27、iPadOS 27、macOS 27、visionOS 27以降で使えなくなります。
Appleが告知した対象OSと時期
Appleが告知を出したのは2026年6月11日です。Apple Developer Releasesでは、Xcode 27 beta、iOS 27 beta、iPadOS 27 betaが2026年6月8日に公開されていることも確認できます。つまり、WWDC26でOS 27世代のbetaが出た直後に、画像生成APIの一部について移行警告が出た形です。
根拠として扱う一次情報
ImageCreatorの廃止、TestFlight buildでのruntime error、public OS releaseでのcompile failureは、Apple Developer Newsの告知を根拠にします。Apple Intelligence全体やFoundation Models frameworkの説明は周辺文脈として使い、ImageCreatorの挙動を断定する根拠にはしません。
ここで重要なのは、ImageCreatorの廃止を「いつか起きる抽象的な非推奨」と読まないことです。Appleはbeta OS、TestFlight build、public OS releaseで起きることを分けて説明しています。betaで警告が見えるだけなら後回しにしたくなりますが、TestFlightで外部配布する段階に入ると検証計画そのものに影響します。
beta、TestFlight、public OS releaseで起きる違い
| 段階 | Appleが示した挙動 | 開発者が見るポイント | 利用者・テスターへの影響 |
|---|---|---|---|
| beta OS releases | コードはコンパイルされるが、Xcodeで警告が出始める | CIとローカルビルドで警告を拾い、依存箇所を棚卸しする | 社内検証だけでは問題が隠れやすい |
| TestFlight builds | ImageCreatorを使うアプリは機能せずruntime errorになる | 外部テスターへ配る前に該当画面を削除、非表示、差し替えする | テスターが画像生成画面で止まる可能性がある |
| Public OS releases | コードがコンパイルできず、該当機能も動かない | public release前に移行実装を完了する | 画像生成機能が使えず、サポート問い合わせにつながる |
TestFlightを先に見る理由
この表の読み方は単純です。Xcodeの警告は開始合図で、TestFlightは実害が出る段階、public OS releaseはビルドと利用者機能の両方が止まる段階です。特に外部テスター、プレス向け配布、法人顧客向け評価版をTestFlightで回しているチームは、TestFlight buildのruntime errorを軽く見ない方がよいでしょう。
Foundation Models frameworkとは分けて読む
Apple DeveloperのApple Intelligence overviewでは、Foundation Models frameworkがNative Swift APIとしてApple Foundation ModelsやPrivate Cloud Compute、Language Model protocolに対応するモデルプロバイダーへアクセスできる枠組みとして説明されています。これは、アプリ内で言語モデルやマルチモーダルな推論を扱う大きな流れです。
一方で、ImageCreator廃止の移行先としてAppleが告知で示しているのは、Foundation Models frameworkへの置き換えではありません。Appleは、Image Playground sheetを提示し、必要なら別の画像生成サービスを統合する選択肢にも触れています。
この境界は本文全体で大事です。WWDC26後のAI開発者APIを広く追うなら、先に公開済みの<a href="https://aapl-watch.blog.mo-gmo.com/foundation-models-framework-apple-intelligence-wwdc26-2026-06-10/">Foundation Models frameworkをWWDC26後に確認</a>も参考になります。ただしImageCreator依存を解消したい場合、最初に見るべきなのは自社コード内の呼び出しとTestFlight配布経路です。
自社アプリにImageCreator依存があるか確認する
ImageCreator、ImagePlayground、自社ラッパー名、画像生成画面のfeature flagを検索する。
アプリ本体、共有モジュール、拡張、Swift Package、サンプル実装、macOS版、visionOS版まで広げる。
プロフィール画像、投稿用画像、メモ内の挿絵など、生成結果を保存する導線を一覧化する。
対象OS、該当画面、runtime errorの有無、回避導線の有無を残す。
使われていないと思っていたコードが別ターゲットに残ることがあるため、検索範囲を最初から狭めないことが重要です。
ImageCreatorを直接使っているチームなら、まず検索すれば見つかるはずです。問題は、実装がラッパー、社内SDK、Swift Package、古い実験機能、feature flagの奥に残っている場合です。WWDC後に大きな設計変更を進めている時期ほど、使われていないと思っていたコードが別ターゲットに残っていることがあります。
コード検索で直接依存を見つける
最初の確認は、アプリ本体だけでなく、共有モジュール、拡張、サンプル実装、macOS版、visionOS版まで広げます。検索対象はImageCreatorだけでなく、ImagePlayground、自社のラッパー名、画像生成画面のfeature flag、生成結果を保存するサービス層も含めます。
rg "ImageCreator|ImagePlayground|image generation|画像生成" .直接検索だけで終わらせない
このコマンド自体が答えではありません。見つかったファイルがビルドターゲットに含まれているか、実際の画面から呼ばれるか、TestFlight向け構成で有効になるかを確認します。古いサンプルコードだけなら影響は小さい一方、共有パッケージに残っていて複数アプリが取り込んでいる場合は優先度が上がります。
画面と配布導線で依存を洗い出す
コード検索の次は、画面の棚卸しです。画像生成画面だけを見ると見落とします。プロフィール画像作成、投稿前の加工、共有後編集、テンプレート生成、ステッカー作成、プロジェクト内素材の自動生成など、ユーザーにとっては「画像生成」と明示されていない導線にも依存が残ることがあります。
| 確認場所 | 見る文字列・導線 | 壊れ方の想定 | 次の対応 |
|---|---|---|---|
| アプリ本体 | ImageCreatorの直接呼び出し | TestFlightでruntime error | Image Playground sheetか別サービスへ移行 |
| 共通モジュール | 画像生成用ラッパー | 複数ターゲットで同時に影響 | パッケージ単位で差し替え |
| 共有拡張 | 投稿前加工、画像追加 | 一部の配布先だけで再現 | 対象extensionを個別に検証 |
| macOS/visionOS版 | 別UIの生成機能 | iOS版では見つからない | 各プラットフォームで棚卸し |
| feature flag | 実験機能、限定公開 | TestFlightだけで有効化される | 配布前にflagを切るか移行する |
画像生成がアプリの主機能なら、移行はリリース計画の中心になります。補助機能なら、一時的に非表示にして本体機能を守る判断もあり得ます。課金機能、保存済みプロジェクト、法人契約のワークフローに絡む場合は、技術対応だけでなくユーザー説明も同じタイミングで準備した方が安全です。
TestFlightで見るべき失敗を記録する
Appleの告知は、TestFlight buildsではImageCreatorを使うアプリが機能せずruntime errorになる、と説明しています。ただし、この記事では未確認のエラー名やログ文言を断定しません。チーム側で記録すべきなのは、どの画面で、どのbeta OSで、どのビルド番号で、どの操作をしたときに失敗したかです。
| 記録項目 | 書く内容 |
|---|---|
| build | TestFlight build番号、Xcode 27 betaの利用有無 |
| OS | iOS 27 beta、iPadOS 27 beta、macOS 27 beta、visionOS 27 betaの別 |
| 画面 | 画像生成が始まる画面、保存や共有に進む画面 |
| 操作 | プロンプト入力、スタイル選択、生成開始、保存、投稿など |
| 結果 | runtime errorの有無、回避導線の有無、ユーザーに見える文言 |
社内Debugだけで動いているように見えても、TestFlight buildで止まるなら外部検証は進みません。今の段階で大事なのは、beta環境の細かなログを深掘りすることより、ImageCreator依存のある画面をTestFlight配布対象から外すか、差し替え計画へ入れることです。
移行先はImage Playground sheetか別サービスか
この比較は勝敗ではなく条件差の整理です。画像生成が主機能か補助機能かで優先順位が変わります。
Appleの告知では、ImageCreatorを使っている場合の対応として、Image Playground sheetへの移行が示されています。これは、アプリが独自に画像生成処理を抱えるのではなく、システム管理の画像生成体験を表示する方向です。もう一つの選択肢として、開発者が選んだ別の画像生成サービスを統合する道もあります。
Image Playground sheetを選ぶ判断
Image Playground sheetが向いているのは、ユーザーが画面上で画像生成を進める体験を受け入れられ、アプリ側で細かな生成制御を持たなくても成立する場合です。たとえば、ユーザーがプロフィール画像、投稿用画像、メモ内の挿絵のような素材を作り、その結果をアプリへ戻す流れなら、システム管理のsheetに寄せやすいでしょう。
この選択の利点は、Appleが提示している移行先に沿えることです。ユーザー体験もApple側の管理に近づくため、生成画面の説明、権限、エラー表示の一部を自前で抱え込まずに済む可能性があります。
ただし、既存UIの細かな制御をそのまま維持できると考えるのは危険です。プロンプト入力、スタイル選択、プレビュー、履歴、保存、共有のうち、どこをシステムsheetへ任せ、どこをアプリ側に残すかを設計し直す必要があります。
別の画像生成サービスを選ぶ判断
別サービスが候補になるのは、アプリ独自のUIやサーバー側ワークフローが強く、Image Playground sheetに寄せると主要体験が崩れる場合です。バッチ生成、ブランド固有スタイル、複数画像の一括処理、法人向け管理画面、既存課金との連動などがあるなら、外部サービスや自社サーバーを含めた設計の方が合うことがあります。
その代わり、確認項目は一気に増えます。APIキー管理、サーバー経由、レート制限、タイムアウト、画像保存、監視、ログ、障害時のfallback、地域差、利用規約、データ保持、削除依頼、未成年ユーザーの扱いまで、Apple側の廃止対応とは別の運用課題が入ります。
| 選択肢 | 向く条件 | 先に見るリスク | 公開前の確認 |
|---|---|---|---|
| Image Playground sheet | ユーザー操作型の生成で、システム管理UIに寄せられる | 既存UIの自由度が下がる | 生成後の保存、共有、キャンセル時表示 |
| 別サービス | 独自UI、サーバー処理、バッチ生成、ブランド制御が必要 | コスト、プライバシー、障害、規約変更 | App Privacy、利用規約、同意導線、監視 |
| 一時停止 | 画像生成が補助機能で、本体機能を優先したい | ユーザー期待、課金機能との整合 | リリースノート、FAQ、feature flag |
画像生成が主機能か補助機能か
移行先は技術の好みだけで決めません。画像生成がアプリの主機能なら代替実装を急ぎ、補助機能なら一時停止も選択肢に入ります。独自UIが必須か、ユーザー操作型のsheetで成立するかを合わせて見ると、短期対応の優先順位を決めやすくなります。
一時停止も現実的な選択肢になる
すべてのアプリが、public OS release前にきれいな代替実装を出せるわけではありません。画像生成が補助機能なら、まず一時的に非表示にし、本体機能をOS 27世代へ対応させる判断も現実的です。特にTestFlight配布が迫っている場合、壊れる画面を残したまま外部テスターへ配るより、機能を止めた理由を短く説明した方が検証の質を保てます。
一方、画像生成が有料機能や主要価値なら、一時停止はサポート負荷や返金相談に直結します。この場合は、移行先の技術選定だけでなく、既存ユーザーへの説明、App Review向けメモ、サポート返信テンプレートを同時に作る必要があります。
Image Playground sheetへ移る場合の実務チェック
- 11. 既存UIを分ける
プロンプト入力、スタイル選択、プレビュー、履歴、保存、共有のどこをsheetへ渡すか決める。
- 22. sheetを表示する
アプリ独自の生成処理ではなく、Image Playground sheetを表示する流れに組み替える。
- 33. 結果を受け取る
生成後の保存、共有、キャンセル時表示、失敗時の戻し方をアプリ側で確認する。
- 44. 差分を説明する
画面遷移やボタン名、失敗時の見え方が変わる場合は、既存ユーザーへの説明を用意する。
API呼び出しの置き換えだけではなく、ユーザー体験とアプリ側に残る処理をセットで見直します。
Image Playground sheetを選ぶなら、作業は「API呼び出しを置き換える」だけでは終わりません。これまでアプリが持っていた画像生成の責務を、システムsheetへ渡す部分と、アプリ側に残す部分に分ける必要があります。
UI体験をsheet前提に組み替える
既存UIに、プロンプト入力、スタイル選択、プレビュー、複数候補の比較、保存、共有、履歴があるなら、どこをsheetへ渡すかを決めます。ユーザーにとっては「同じ画像生成機能」でも、画面遷移やボタン名、失敗時の見え方が変わることがあります。
移行前の典型的な流れは、アプリ独自UIで入力を受け取り、ImageCreatorで生成し、生成結果をアプリが保存する形です。移行後は、アプリがImage Playground sheetを表示し、生成された結果を受け取って、保存や共有などアプリ固有の処理に進む流れになります。
生成後のアプリ側処理を確認する
sheetへ移した後も、アプリ側に残る責務はあります。生成画像をどこへ保存するか、キャンセルされたときにどう戻すか、保存に失敗したときにどの文言を出すか、共有や投稿に進む前にユーザー確認を挟むか。ここは自社アプリの品質として残ります。
アプリ側に残る責務
| アプリ側に残る責務 | 確認すること |
|---|---|
| 保存 | 生成結果の保存先、失敗時の復旧、既存プロジェクトとの紐づけ |
| 共有 | 共有前の確認、権限、キャンセル時の戻り先 |
| エラー表示 | 生成キャンセル、保存失敗、通信失敗の文言 |
| ヘルプ更新 | 画面変更、操作順、既存ユーザーへの説明 |
| レビュー説明 | App Reviewメモ、外部サービスを使う場合の説明 |
既存ユーザーへの差分説明を用意する
リリースノートやヘルプで、画像生成画面が変わることを短く伝えます。Appleの廃止を理由として前面に出しすぎるより、ユーザーが知りたい「どこから生成するのか」「保存済みデータは残るのか」「以前の生成履歴はどうなるのか」を先に書く方が親切です。
開発者向けには、<a href="https://aapl-watch.blog.mo-gmo.com/xcode-27-beta-apple-silicon-swift-6-4-ios27-sdk-2026-06-09/">Xcode 27 betaの実務チェック</a>も合わせて見ると、SDK更新、警告、対応Mac、ビルド対象の確認を同じ流れで整理できます。ImageCreator移行は、Xcode 27 betaで出る警告を入口にして、TestFlight配布前の確認へつなげるのが自然です。
別サービスへ切り替える場合の設計メモ
外部サービスへの切り替えは高性能化だけでなく、データの扱いと運用責任が変わる判断です。
別の画像生成サービスを選ぶ場合、ImageCreator廃止対応はApple APIの置き換えではなく、アプリのデータフロー変更になります。オンデバイス中心だった体験が、サーバーや外部APIを含む体験へ変わるなら、通信、コスト、規約、プライバシー、障害対応が設計対象に入ります。
技術面で確認すること
最初に見るのは、ユーザー端末から外部サービスへ直接送るのか、自社サーバーを経由するのかです。直接送るならAPIキー管理やクライアント側の保護が問題になります。サーバー経由なら、キュー処理、レート制限、タイムアウト、生成失敗時の再試行、ログの保持、監視が必要です。
また、生成画像をどこに保存するかも変わります。端末内で完結していた機能をクラウド利用に変える場合、通信失敗や待ち時間がユーザー体験に入ります。生成に時間がかかるなら、進行中表示、キャンセル、バックグラウンド復帰、失敗時の再開導線を考える必要があります。
プライバシーと審査説明を見直す
ユーザー写真、プロンプト、生成画像、アカウント情報を外部へ送るなら、App Privacy、利用規約、プライバシーポリシー、同意導線を見直します。データ保持期間、削除依頼、未成年ユーザーの扱い、地域ごとの提供差も確認対象です。
ここで避けたいのは、外部サービスの導入を「高性能化」とだけ説明することです。ユーザーにとっては、どのデータがどこで処理されるのかが重要です。アプリ内の説明が古いままだと、技術的には移行できていても、審査やサポートで詰まる可能性があります。
コストと品質の上振れ、下振れを見る
外部サービスには、独自スタイルや既存ワークフローとの統合で差別化しやすい利点があります。その一方で、API費用、地域制限、品質のばらつき、障害、規約変更の影響を受けます。無料枠だけで判断せず、ユーザー数が増えたときの上限設定と、生成失敗時のfallbackを先に決めておきたいところです。
| 論点 | 確認する担当 | 公開前に必要な更新 | 未対応リスク |
|---|---|---|---|
| APIキーとサーバー経由 | 開発 | キー管理、監視、レート制限 | 不正利用、費用増 |
| ユーザーデータ送信 | 法務・開発 | Privacy表示、同意導線 | 審査指摘、信頼低下 |
| 障害時のfallback | 開発・サポート | エラー文言、再試行、問い合わせ導線 | 生成失敗時の離脱 |
| コスト管理 | PM・運用 | 上限設定、利用状況監視 | 従量課金の急増 |
public OS release前の確認順
- 今日
Xcode 27 betaで警告を拾い、ImageCreator依存のあるターゲットと画面を一覧化する。
- TestFlight配布前
該当機能を削除、非表示、差し替えのどれかにし、外部テスターへ壊れる画面を残さない。
- public OS release前
Image Playground sheetまたは別サービスへの移行、リリース説明、サポート導線を整える。
警告を消す作業だけで終わらせず、配布前の再現テストと公開前の説明更新まで並べて確認します。
対応順は、Xcode警告、TestFlight、public OS releaseの順に分けると整理しやすくなります。Apple Developer ReleasesではXcode 27 betaとiOS 27 betaなどが2026年6月8日に出ています。まずこの環境で警告を拾い、次にTestFlight配布前の壊れ方を確認し、最後に正式公開前の説明とサポート導線を整えます。
まずXcode警告とビルド対象を潰す
Xcode 27 betaでImageCreator関連の警告が出るなら、それは移行タスクの入口です。警告を消すだけでなく、対象ターゲットを確認します。iOS版だけを直しても、iPadOS版、macOS版、visionOS版、共有拡張に残っていれば、別の配布経路で同じ問題が出ます。
CIでbeta SDKを使っている場合は、警告をログに残すだけでなく、担当者が見られるチケットへ変換します。beta時点の警告を「正式版までに変わるかもしれない」と棚上げしないことが大切です。Appleの告知は、public OS releaseではコードがコンパイルできないと明示しています。
次にTestFlight配布前の再現テストを行う
外部テスターに配る前に、ImageCreator依存画面をすべて通します。runtime errorが起きるなら、配布前に機能を削除、非表示、差し替えのどれかにします。テスターが最初に触る導線に画像生成があるなら、アプリ全体の評価に響きます。
TestFlightは、開発チームの内側だけでなく、社外の評価者、法人顧客、レビュー協力者に届くことがあります。そこで止まる機能を残すなら、既知の制限として明示するか、配布対象から外す判断が必要です。
最後にリリース説明とサポート導線を更新する
移行実装が終わっても、ユーザー説明が古いままだと問い合わせが増えます。リリースノート、FAQ、ヘルプ、サポート返信テンプレート、App Reviewメモを確認します。画像生成が有料機能なら、旧仕様からの変更、利用できない期間、代替手段、保存済みデータへの影響を特に丁寧に書く必要があります。
public OS release前の完了条件
| 時点 | 主要タスク | 完了条件 |
|---|---|---|
| 今日 | ImageCreator検索、対象ターゲットの棚卸し | 依存ファイル、画面、配布経路が一覧になっている |
| TestFlight配布前 | 該当画面の削除、非表示、差し替え | runtime errorが外部テスターに出ない |
| public OS release前 | 移行実装、説明更新、サポート準備 | Xcode警告とコンパイル不可リスクが解消している |
需要シグナルとして見るWWDC26後のAI API関心
専門メディアでFoundation ModelsやApple Intelligence開発者APIの解説が目立つことは、関心のシグナルとして読む。
ImageCreatorの廃止時期、TestFlightのruntime error、public OS releaseでのcompile failureはApple Developer Newsを根拠にする。
Apple Intelligence全体の導入判断へ広げすぎず、ImageCreator依存アプリの移行判断に集中する。
需要シグナルは知りたいことを見つけるために使い、仕様の断定は公式情報で確認します。
このトピックを選んだ理由は、Appleの一次情報だけではありません。WWDC26後、専門メディアではFoundation ModelsやApple Intelligence開発者APIの解説が目立ち、開発者が「どのAPIを使えるのか」「どこまでAppleのシステムに任せるのか」を確認している流れが見えます。これは仕様の根拠ではなく、読者需要のシグナルです。
需要と事実認定を分ける
9to5MacやMacRumorsのような専門メディアは、何に注目が集まっているかを読むには有用です。ただし、ImageCreatorの廃止時期、TestFlightでのruntime error、public OS releaseでのcompile failureは、Apple Developer Newsを根拠にしています。
噂や解説記事を読むときの姿勢は、<a href="https://aapl-watch.blog.mo-gmo.com/source-checks/">資料・確認ログ</a>の考え方と同じです。需要シグナルは「読者が知りたいこと」を見つけるために使い、仕様の断定は公式情報で確認します。
Apple Intelligence全体の導入判断へ広げすぎない
今回の記事で扱うのは、ImageCreator依存アプリの移行判断です。Apple Intelligence全体の採用、Siri AI連携、App Intents、Spotlight、Shortcuts連携まで広げると、今すぐ必要なTestFlight対策がぼやけます。
Siri AIやSpotlight、Shortcuts連携の実装判断を見たい場合は、<a href="https://aapl-watch.blog.mo-gmo.com/app-intents-siri-ai-spotlight-shortcuts-wwdc26-developer-check-2026-06-13/">App IntentsをWWDC26後に確認</a>が別軸になります。ImageCreator移行と並行して、アプリ全体のApple Intelligence対応を棚卸しする場合に読むと流れがつかみやすいはずです。
まとめ：ImageCreator依存はTestFlight配布前に切り分ける
- 11. 依存を検索する
ImageCreatorを検索し、対象画面とターゲットを一覧化する。
- 22. 配布前に止める
TestFlight配布前に、該当機能を削除、非表示、差し替えのどれかにする。
- 33. 移行先を整える
public OS release前までに、Image Playground sheetまたは別サービスへの移行を進める。
- 44. 説明を用意する
リリース説明、FAQ、サポート導線を更新し、ユーザーに見える変化を短く伝える。
最初に見るべきなのは大きなロードマップではなく、自社アプリ内の依存箇所です。
ImageCreator廃止で最初に見るべきなのは、Apple Intelligenceの大きなロードマップではなく、自社アプリ内の依存箇所です。Appleの告知では、beta OSではXcode警告、TestFlight buildsではruntime error、public OS releaseではcompile failureと機能停止が示されています。
そのため、対応順は明確です。まずImageCreatorを検索し、対象画面とターゲットを一覧化する。次にTestFlight配布前に、該当機能を削除、非表示、差し替えのどれかにする。最後にpublic OS release前までに、Image Playground sheetまたは別サービスへの移行、リリース説明、サポート導線を整える。
Image Playground sheetに寄せられるアプリは、Appleが示す移行先に沿って体験を組み替えるのが第一候補です。独自UIやサーバー処理が欠かせないアプリは、別サービスを選べますが、その場合はプライバシー、コスト、障害対応まで設計対象に入ります。
なお、Apple Signals JapanはAppleおよび関係会社とは非提携の独立情報サイトです。この記事は開発者向けの公式情報整理であり、投資助言や売買推奨ではありません。
次に読むなら
更新履歴
ImageCreator廃止、TestFlight buildでのruntime error、public OS releaseでのcompile failureを確認した。
Xcode 27 beta、iOS 27 beta、iPadOS 27 betaの公開状況を確認した。
Foundation Models frameworkなど、周辺文脈として扱うApple Intelligence情報を確認した。
WWDC26後の開発者向け文脈と、関連する公式発表の流れを確認した。
更新履歴は仕様の根拠と周辺文脈を分け、2026年6月15日時点の確認範囲として読みます。
- 2026年6月15日: Apple Developer News、Apple Developer Releases、Apple Developer Apple Intelligence overview、WWDC26 Apple Intelligence guide、Apple Newsroomを確認し、
ImageCreator廃止とTestFlight影響を整理しました。
参照した主な情報源
- Apple Developer News: Deprecation of the ImageCreator class
https://developer.apple.com/news/?id=dz9wvq0r
- Apple Developer Releases
https://developer.apple.com/news/releases/
- Apple Developer: Apple Intelligence
https://developer.apple.com/apple-intelligence/
- Apple Developer: WWDC26 Apple Intelligence guide
https://developer.apple.com/wwdc26/guides/apple-intelligence/
- Apple Newsroom: Apple accelerates app development with new intelligence frameworks and advanced tools
https://www.apple.com/newsroom/2026/06/apple-aids-app-development-with-new-intelligence-frameworks-and-advanced-tools/
- 需要シグナルとして確認: 9to5MacのFoundation Models解説記事
Apple’s new Foundation Models explained: on-device AI, cloud AI, and everything in between