3行まとめ
iOS 26.6 beta 2とiPadOS 26.6 beta 2は2026年6月15日公開、ビルド番号はいずれも23G5043dです。
Release NotesではHealthKit、Object Capture、StoreKitに解決済み問題があり、Stickersには既知問題が残っています。
新機能探しではなく、検証用端末で既知修正を再現確認し、業務端末や本番課金導線に近づけるかを切り分けます。
速報ではなく、Apple公式情報を起点に検証対象を決めるための整理です。
- Apple Developer Releasesでは、iOS 26.6 beta 2とiPadOS 26.6 beta 2が2026年6月15日に公開され、ビルド番号はいずれも23G5043dと確認できる。
- AppleのiOS & iPadOS 26.6 Beta 2 Release Notesでは、HealthKit、Object Capture、StoreKitに解決済み問題があり、Stickersには既知問題が残っている。
- 今回のbeta 2は新機能探しよりも、検証用端末で既知修正を再現確認し、業務端末や本番課金導線に近づけるかを切り分けるために使いたい。
WWDC26後はiOS 27、iPadOS 27、Siri AI、Liquid Glassの話題に視線が集まりがちです。ただし、実際のユーザーがしばらく触るのは現行世代のiOS 26系、iPadOS 26系であり、アプリ開発者や導入担当者にとっては26.6 beta 2も見落とせません。
MacRumorsと9to5Macも2026年6月15日にiOS/iPadOS 26.6 beta 2を取り上げており、読者の関心があることは確認できます。ただし、本稿ではそれらを事実認定には使いません。確認の土台はApple Developer Releases、Apple Developer Documentation、AppleのTesting a beta OS、Feedback Assistantです。
本稿はAppleおよび関係会社とは非提携の独立メモです。beta OSの導入を勧める記事ではなく、Apple公式情報をもとに「どのアプリが、どこから、どの端末で検証するか」を決めるための整理です。2026年6月の他のApple関連更新は、公開済みの<a href="https://aapl-watch.blog.mo-gmo.com/monthly-topics-2026-06/">Apple 2026年6月重要トピックまとめ</a>にも集約しています。
iOS/iPadOS 26.6 beta 2でまず見るべきこと
WWDC26後の次期OS検証とは別に、現行世代に近い環境での回帰確認として扱います。
Apple Developer Releasesの個別ページでは、iOS 26.6 beta 2とiPadOS 26.6 beta 2がそれぞれ2026年6月15日付で掲載され、ビルド番号は23G5043dです。まず確認するべきなのは、betaが出たという速報そのものではありません。自分のアプリや組織にとって、今回のリリースノート項目が検証対象かどうかです。
今回のRelease Notesで目立つのは、HealthKit、Object Capture、Stickers、StoreKitです。HealthKitとStoreKitは、多くのアプリでユーザー体験やテスト自動化に直結します。Object Captureは対象アプリが限られますが、3D生成やARワークフローを扱う開発者には重要です。Stickersは既知問題として残っており、ステッカー作成、表示、iCloud同期が関係するアプリやサポート担当者は保留判断の材料にすべきです。
公開日、ビルド番号、対象読者を確認する
最初に見たい一次情報は、Apple Developer ReleasesのiOS 26.6 beta 2ページとiPadOS 26.6 beta 2ページです。ここで公開日、ビルド番号、Release Notesへの導線を確認します。記事執筆時点では、両方とも2026年6月15日、23G5043dです。
次に、iOS & iPadOS 26.6 Beta 2 Release Notesを開きます。AppleのRelease Notesには、iOS & iPadOS 26.6 SDKがiOS/iPadOS 26.6 beta 2向けアプリ開発をサポートし、Xcode 26.6に同梱されるという説明があります。一方で、Apple Developer Newsの5月26日付「Get ready with the latest beta releases」では、iOS 26.6などのbetaに対してXcode 26.5でビルドとテストを行う案内が出ていました。
この表記差は、読者側で勝手に補完しないほうが安全です。実際に検証を始める日は、Downloadページ、Release Notes、使うXcodeのリリースノートを同じ日に見直してください。WWDC26後の開発環境全体を見る場合は、公開済みの<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はApple silicon Macで確認</a>も参照できますが、今回の26.6 beta 2検証では26.6側のRelease Notesを優先します。
WWDC26後でも26.6 beta 2を見る理由
iOS 27系のbetaを追う理由は、新機能や次期SDKへの準備です。iOS 26.6 beta 2を見る理由は少し違います。すでにユーザーが使っている現行世代に近い環境で、直近の不具合修正や既知問題が自社アプリにどう影響するかを見ます。
特に重要なのは、次の4種類のチームです。
| 優先度 | 対象チーム | 先に見る項目 | 判断の軸 |
|---|---|---|---|
| 高 | HealthKitを使うヘルスケア、フィットネス、医療連携アプリ | 血圧タイプの権限画面、重複サンプル時の統計 | 許可フローと数値表示に誤解が出ないか |
| 高 | StoreKitテストをSimulatorやCIで回すアプリ | SKTestSessionsの接続 | 自動テストの失敗がOS側由来か切り分けられるか |
| 中 | Stickersやメッセージング体験を扱うアプリ | ステッカー作成、表示、iCloud同期 | 既知問題がサポート対象端末へ広がらないか |
| 中 | Object Captureを使う3D/ARアプリ | capture and reconstruction | 既存の失敗ケースを再検証する価値があるか |
新機能の発見を期待して検証端末へ入れるより、既知の問題を再現できるテストケースを持っているチームが、比較のために入れるbetaと捉えるほうが現実的です。
HealthKit修正は医療・ヘルス系アプリから確認する
医療的な正しさを断定する比較ではなく、権限導線と数値表示に誤解が出ないかを見る表です。
iOS & iPadOS 26.6 Beta 2 Release Notesでは、HealthKitに2つのResolved Issuesが掲載されています。ひとつは血圧の拡張期、収縮期に関する権限画面の表示です。もうひとつは、Resting Heart Rateのような離散的な量タイプで、サンプル時刻が重なった場合に時間加重平均の統計クエリが過度に高い値を返す可能性に関する修正です。
HealthKitを扱うアプリでは、こうした項目を単なる開発者向け細目として済ませないほうがよいです。ユーザーは数値や許可画面を信頼して使います。アプリ側が医学的な助言をしていなくても、表示や権限導線が崩れると、サポート問い合わせ、レビュー、法人導入判断に影響します。
血圧タイプの権限画面を先に見る
根拠
Release Notesでは、HKQuantityTypeIdentifierBloodPressureDiastolic または HKQuantityTypeIdentifierBloodPressureSystolic を要求したときにAuthorization Screenが表示されない問題が修正されたとされています。
確認項目
ここで確認するのは、血圧機能の正しさそのものではありません。アプリがHealthKitの血圧データを扱う前に、ユーザーが許可画面を見て判断できるかです。新規インストール、過去に許可済みの端末、過去に拒否した端末、アプリ再インストール後の端末を分けて見ると、権限状態による差が見えやすくなります。
最低限のテストは、次の粒度で十分です。
| ケース | 確認すること | 合格基準 |
|---|---|---|
| 新規インストール | 血圧の拡張期、収縮期を初回要求する | 権限画面が表示され、ユーザーが許可または拒否を選べる |
| 既存許可あり | 以前にHealthKitアクセスを許可済み | 既存許可の扱いが変わらず、不要な再許可が出ない |
| 既存拒否あり | 過去に拒否した状態で再度機能に入る | アプリ内の説明と設定導線が破綻しない |
| iPadOS検証 | iPad向けUIで同じ機能を触る | 画面サイズや分割表示で説明が欠けない |
血圧データは、ユーザーにとって意味の重い健康情報です。記事やアプリ内文言では、beta OS上の挙動確認と医学的な判断を混同しないことも大切です。開発者が見るべきなのは、HealthKit APIの許可フロー、表示、エラーハンドリングです。
時間が重なるサンプルの統計クエリを再検証する
条件
もうひとつのHealthKit項目は、時間が重なるサンプルがある場合の統計クエリです。Release Notesでは、Resting Heart Rateのようなdiscrete quantity typeで、temporally-weighted average statistics queriesが過度に高い値を返す可能性への修正が示されています。
この修正は、平均値やグラフを表示するアプリで見落としやすい領域です。クラッシュのように明白な失敗ではなく、数値が「なんとなく高い」状態として出るため、テストデータが単純だと検出できません。
評価基準
検証するなら、重複する時刻を含むサンプル、短時間に密集したサンプル、通常の連続サンプルを用意し、同じクエリでbeta 2前後の結果を比較します。もし既にbeta 1や社内テスト端末で異常値を見ていたなら、その再現条件を崩さずにbeta 2で試します。結果が改善した場合でも、アプリ側で独自集計やキャッシュを持っているなら、OS側修正だけで本番表示が整うとは限りません。
ログには、OSビルド、Xcode、端末、HealthKitストアの初期状態、サンプル作成条件、クエリの種類を残します。あとでFeedback Assistantに報告する可能性を考えると、再現手順を人が読める文章にしておくほうが役立ちます。
StoreKitとSimulatorテストはCI前に切り分ける
- 1Simulator
StoreKit設定ファイル、購入、キャンセル、更新、失敗系を使い、SKTestSessions接続の修正が自社テストに効くかを見ます。
- 2実機Sandbox
Apple ID、Sandboxアカウント、購入履歴を分けて、実機固有の表示、認証、復元の挙動を確認します。
- 3CI
Xcode、OSランタイム、テスト並列実行をそろえ、自動テストの再現性を記録します。
Simulator修正は課金導線全体の品質を断定する材料ではなく、テスト環境の復旧確認として扱います。
StoreKitのResolved Issuesでは、Simulatorを使うときにSKTestSessionsがテスト環境へ正しく接続せず、テストアクションが失敗する問題の修正が示されています。これは、課金導線そのものの品質を断定する材料ではありません。まずは、Simulator上のStoreKitテストが復旧したかどうかを見る項目です。
アプリ内課金やサブスクリプションを持つアプリでは、StoreKitテストが壊れると、ローカル検証、CI、レビュー前の回帰テストが止まります。今回のbeta 2を確認する価値が高いのは、ここに該当するチームです。
SKTestSessionsの接続修正を確認する
根拠
最初に見るのは、最小構成のStoreKitテストです。複雑なプロモーション、サーバー通知、外部決済導線を一度に走らせると、beta 2で直った部分と、アプリ側や環境側の問題が混ざります。
確認は、次の順番で小さく回すのが安全です。
| 環境 | 先に見ること | beta 2で判断できること | 判断できないこと |
|---|---|---|---|
| Simulator | StoreKit設定ファイル、購入、キャンセル、更新、失敗系 | SKTestSessions接続の修正が自社テストに効くか | 実機Sandboxや本番課金の安定性 |
| 実機Sandbox | Apple ID、Sandboxアカウント、購入履歴 | 実機固有の表示、認証、復元の挙動 | Simulator修正の直接効果 |
| CI | Xcode、OSランタイム、テスト並列実行 | 自動テストの再現性 | ユーザー環境での課金成功率 |
Simulatorで失敗していたテストがbeta 2で通るようになった場合、まずは「SimulatorのStoreKitテスト環境接続が改善した」と記録します。そこで止めるのが大切です。すぐに「課金導線が直った」と書いたり、実機Sandboxや本番環境の安定性まで広げたりしないでください。
Simulatorで直ったことと実機で見ることを分ける
注意点
StoreKitは、開発者のテスト環境とユーザーの購入体験が近いようで、実際には確認する層が違います。SimulatorのStoreKitテストは、ローカルやCIで期待する分岐を確実に走らせるための基盤です。実機Sandboxは、Apple ID、認証、復元、端末状態、ネットワークを含む検証です。本番はさらに審査、商品状態、価格、税、配信地域が入ります。
今回のRelease Notes項目はSimulatorに関するものです。したがって、検証ログでは次を明記します。
- StoreKit設定ファイルのバージョンと対象商品
- Xcodeのバージョン
- SimulatorのOSビルド
- 実行したテストアクション
- 失敗した場合のエラー、成功した場合の前回との差分
アプリ提出やサブスクリプション施策まで含めて確認する場合は、公開済みの<a href="https://aapl-watch.blog.mo-gmo.com/app-store-wwdc26-creative-assets-subscription-bundles-time-allowances-2026-06-12/">App Store新機能をWWDC26後に確認</a>もあわせて見ると、課金やサブスクリプションの検証範囲を広げやすくなります。ただし、この記事の主題はApp Store施策ではなく、iOS/iPadOS 26.6 beta 2上のStoreKitテスト修正です。
Stickers既知問題は導入可否の赤信号として扱う
新しいステッカーを作れるかを確認し、失敗時に別原因として扱っていないかを見ます。
既存ステッカーが表示されるかを確認し、ユーザー資産の見え方への影響を見ます。
同じApple Accountの別端末で問題が続くかを確認し、端末単体で閉じない可能性を見ます。
Stickers作成、表示、同期が主要機能またはサポート対象なら、beta 2の導入範囲を広げない判断を優先します。
Resolved IssuesではなくKnown Issuesのため、直った項目ではなく踏む可能性がある問題として扱います。
iOS & iPadOS 26.6 Beta 2 Release Notesでは、StickersにKnown Issuesが残っています。内容は、ステッカーデータが破損した場合に新しいステッカーを作れない、既存ステッカーを見られない可能性があり、iCloudで同期されると他のデバイスにも問題が持続する可能性があるというものです。
ここは、今回の記事で最も慎重に扱いたい箇所です。Resolved IssuesではなくKnown Issuesです。つまり、beta 2で直った話ではなく、検証時に踏む可能性がある問題として扱います。
新規作成、既存表示、iCloud同期への影響を整理する
影響範囲
Stickersを主要機能として扱うアプリ、メッセージング体験と深く関係するアプリ、社内コミュニケーション端末にbetaを入れる組織では、今回のKnown Issuesを導入保留の材料にできます。
見るべきポイントは3つです。
| 観点 | 確認すること | 注意点 |
|---|---|---|
| 新規作成 | 新しいステッカーを作れるか | 失敗時にアプリ側が別原因として扱っていないか |
| 既存表示 | 既存ステッカーが表示されるか | ユーザー資産の見え方に関わる |
| iCloud同期 | 同じApple Accountの別端末で問題が続くか | 端末単体で閉じない可能性がある |
この項目は、Stickersを使わないアプリには直接関係しないかもしれません。それでも、導入担当者がbeta OSを配る場合には意味があります。問題がiCloud同期で持続する可能性が示されているため、検証端末を共有端末や業務連絡端末に近づけるほど、戻し方を先に決めておく必要があります。
導入担当者は対象端末を絞る
保留条件
beta OSの導入範囲は、興味ではなく影響範囲で決めます。StickersのKnown Issuesが自社アプリに関係ないなら、影響は限定的です。しかし、サポート担当者が「ステッカーが出ない」「別端末にも残った」という問い合わせを受ける可能性があるなら、検証端末を絞るべきです。
判断は次のように分けると迷いにくくなります。
| 判定 | 条件 | 行動 |
|---|---|---|
| 継続検証 | Stickers非依存で、検証端末も限定されている | HealthKitやStoreKitなど関係項目を優先して見る |
| 限定検証 | Stickers表示は使うが、主要機能ではない | iCloud同期を含む再現確認を小さく行う |
| 導入保留 | Stickers作成、表示、同期が主要機能またはサポート対象 | beta 2の導入範囲を広げない |
「Known Issuesがあるから危険」とだけ書くと、読者の判断材料になりません。重要なのは、その既知問題が自社の機能、サポート、端末運用に接続しているかです。
Object Capture利用アプリは再撮影から確認する
- 1入力条件を固定する
入力画像セット、撮影枚数、照明条件、被写体の質感、出力設定をそろえます。
- 2失敗ケースを再実行する
beta 1以前や通常環境で失敗していたcapture and reconstructionを、同じ条件で再実行します。
- 3合格基準を見る
処理完了、出力品質、メモリ警告、アプリ終了の有無、同じ入力での再現性を確認します。
- 4結論を急がない
入力条件を変えた場合は、結果をbeta 2で改善したと結論づけず、条件差として記録します。
Object Captureは対象アプリが限られるため、自社の撮影条件と失敗ケースに絞って見るのが現実的です。
Object CaptureのResolved Issuesでは、capture and reconstructionが失敗する可能性に関する修正が示されています。対象アプリは限られますが、3Dモデル生成、AR確認、ECの商品表示、現場記録のようなワークフローでは、失敗率や再実行の手間がそのまま運用コストになります。
この項目も、全てのObject Capture問題が直ったと読まないことが大切です。AppleのRelease Notesが示しているのは、特定の失敗可能性に関するResolved Issuesです。自社の入力画像、撮影条件、端末、メモリ状態、出力形式が違えば、別の問題が残ることがあります。
capture and reconstructionの失敗修正を見る
比較条件
既にObject Captureの失敗ケースを持っているチームは、beta 2で再撮影から始めるより、まず同じ入力条件を再利用できるか確認します。入力画像セット、撮影枚数、照明条件、被写体の質感、出力設定を変えずに比較できると、OSやSDK側の差分を見やすくなります。
一方、入力条件を変える必要がある場合は、結果を「beta 2で改善」と結論づけないほうがよいです。撮影条件が変われば、成功率や品質も変わります。Release Notesの修正項目を確認する目的なら、失敗ログと入力条件を固定するほうが価値があります。
3D/ARワークフローの合格基準を先に決める
評価基準
Object Captureは、成功か失敗かだけでは判断が粗くなります。処理は完了したがモデルに欠損がある、出力はできたが処理時間が長すぎる、同じ条件で再実行すると結果がぶれる、といった状態もあります。
検証前に、次の合格基準を決めておくと記事や社内メモにしやすくなります。
- 処理完了率
- 出力モデルの欠損や歪み
- 処理時間
- メモリ警告やアプリ終了の有無
- 同じ入力で再実行したときの再現性
- 既存の正式版OSまたは前betaとの比較
beta 2で良い結果が出ても、納品前や業務導入前には正式版または安定版OSで再確認する前提を崩さないほうが安全です。betaの価値は、問題を早く見つけ、Appleへ報告し、アプリ側の備えを早めることにあります。
検証順は「入れる前、入れた後、戻す前」で固定する
- 入れる前
Apple Developer Releases、Release Notes、Downloadページ、Xcode、対象端末、バックアップ、復元手順を確認します。
- 入れた後
HealthKit、StoreKit、Stickers、Object Captureのうち、自社アプリに関係する項目だけを小さく検証します。
- 戻す前
StickersのiCloud同期、HealthKitの数値や権限画面、StoreKitの実機Sandbox問題を分けて記録します。
- 通常回帰へ戻る
関係しない項目は追いすぎず、起動、ログイン、課金、通知、データ同期の回帰テストへ戻ります。
記事やSNSの「出た」という情報だけで業務端末に入れず、公式情報と復元可能な検証端末を前提にします。
AppleのTesting a beta OSは、betaリリースサイクル中に各betaでアプリをテストし、APIの問題や非互換を早く見つけることを促しています。また、現在のApp Store版やTestFlight版を検証端末に入れてユーザーが遭遇する問題を見つけること、beta SDKで再ビルドすると別の変化が入り得ることも示しています。
この考え方に沿うと、iOS/iPadOS 26.6 beta 2の検証順は「入れる前」「入れた後」「戻す前」の3段階で固定できます。
入れる前に確認する一次情報
合格条件
入れる前の確認は、端末より先に資料です。Apple Developer ReleasesでiOS/iPadOS 26.6 beta 2の公開日とビルド番号を確認し、Release Notesで自社アプリに関係する項目を拾います。次に、Downloadページ、Xcode、対象端末、バックアップ、復元手順を確認します。
ここでやってはいけないのは、記事やSNSの「出た」という情報だけで業務端末に入れることです。専門メディアの速報は、需要シグナルとしては役立ちます。しかし、対応デバイス、ビルド、Release Notes、Xcode、既知問題はApple公式側で確認します。
入れる前のチェックリストは、次の程度で十分です。
| 項目 | 見る場所 | 判断 |
|---|---|---|
| OSビルド | Apple Developer Releases | 23G5043dか、更新されていないか |
| Release Notes | Apple Developer Documentation | 関係するResolved Issues、Known Issuesがあるか |
| Xcode | Downloadページ、Xcode Release Notes | 検証に使うXcode表記が一致しているか |
| 端末 | 社内の検証台帳 | 復元可能で、本番端末ではないか |
| データ | バックアップ、テストアカウント | HealthKitやiCloud同期の影響を分離できるか |
入れた後の最小テストセット
確認項目
入れた後は、全機能を一気に触るより、Release Notesで名前が出ている領域から見ます。HealthKitを使わないアプリがHealthKit項目に時間をかける必要はありません。StoreKitを使うアプリなら、SimulatorのSKTestSessionsから見る価値があります。Stickersを使うならKnown Issuesの再現有無を先に確認します。
最小テストセットの考え方は、次のように置けます。
- HealthKitを使うアプリは、血圧タイプの権限画面と重複サンプル時の統計クエリを見る。
- StoreKitを使うアプリは、SimulatorのStoreKitテスト、実機Sandbox、CIを分ける。
- Stickersを扱うアプリは、新規作成、既存表示、iCloud同期を分ける。
- Object Captureを使うアプリは、入力条件を固定し、capture and reconstructionの失敗ケースを再検証する。
- 関係しない項目は追いすぎず、通常の起動、ログイン、課金、通知、データ同期の回帰テストへ戻る。
AppleのTesting a beta OSが示すように、beta OS上の変化はAPI挙動の変化として出ることがあります。問題を見つけたら、該当コード、使っているシステムフレームワーク、期待結果、実際の結果をまとめ、Feedback Assistantへ報告できる状態にします。
戻すか、継続検証するかを判断する
判断基準
beta 2を入れた後に大切なのは、継続するか戻すかを早めに決めることです。検証端末だからといって、問題を抱えたまま次の作業に使い続けると、別の検証結果まで濁ります。
戻す判断は、次の条件で行います。
| 条件 | 判断 |
|---|---|
| StickersのKnown Issuesに該当し、iCloud同期の影響が分離できない | 継続導入しない |
| HealthKitの数値や権限画面で自社アプリ側の追加不具合が見つかった | 原因切り分けまで検証端末を固定する |
| StoreKitのSimulatorテストが復旧したが実機Sandboxで別問題がある | Simulator修正と実機問題を分けて記録する |
| Object Captureの再現条件が変わってしまった | テスト条件を作り直してから再検証する |
| 復元手順やバックアップが未確認 | 業務端末に近い運用へ進めない |
Feedback Assistantへ出す場合は、再現手順、ログ、スクリーンショット、実行したXcodeプロジェクトまたは最小再現プロジェクトをそろえます。AppleのTesting a beta OSでも、問題を早く、継続的に報告することが、正式リリース前の解決可能性を高めるという趣旨が示されています。
2026年6月のApple情報としてどう位置づけるか
2026年6月15日にiOS/iPadOS 26.6 beta 2が公開され、ビルド番号は23G5043dです。
HealthKit、Object Capture、StoreKitにResolved Issues、StickersにKnown Issuesがあります。
検証時点でDownloadページ、Release Notes、使うXcodeのリリースノートを同じ日に見直します。
Testing a beta OSとFeedback Assistantの手順に沿って、対象機能だけを小さく検証します。
派手な次期OSの話題とは分けて、既知修正と既知問題を現場の検証タスクへ落とすための記録です。
iOS/iPadOS 26.6 beta 2は、WWDC26後の派手な次期OS発表に比べると地味です。しかし、開発現場では地味なbetaほど重要なことがあります。新しいSiri AIやLiquid Glassを追う一方で、既存ユーザーが触る26系の安定性、課金テスト、HealthKitの数値、iCloud同期の既知問題を見落とすと、サポートや審査前検証に響きます。
今回の記事で扱った項目は、投資判断や株価材料ではなく、読者が触れるプロダクトと開発者が使うAPIの更新です。Appleの業績や市場反応を読む場合でも、まずこうした利用者影響を押さえてから背景として見るほうが、ニュースを誤読しにくくなります。
iOS 27 betaとは別のレーンで見る
iOS 27 betaは、秋以降を見据えた開発者検証です。iOS 26.6 beta 2は、現行世代の改善と既知問題を確認する検証です。両方を同じ端末や同じテスト表で扱うと、問題の原因を見失います。
たとえば、StoreKitのSimulatorテストが通らない場合、iOS 27 beta側のSDK差分なのか、iOS 26.6 beta 2側の修正対象なのか、Xcodeの違いなのかを分ける必要があります。HealthKitの統計値も同じです。OS、SDK、テストデータ、アプリビルドを分けて記録しないと、あとから原因が追えません。
月次まとめに残すべきメモ
月次で追うなら、次の短いメモを残すだけでも十分です。
- 2026年6月15日、Apple Developer ReleasesでiOS/iPadOS 26.6 beta 2が公開された。
- ビルド番号は23G5043d。
- Release NotesではHealthKit、Object Capture、StoreKitにResolved Issues、StickersにKnown Issuesがある。
- Xcode表記は検証時点でDownloadページとRelease Notesを再確認する。
- 開発者はTesting a beta OSとFeedback Assistantの手順に沿って、対象機能だけを小さく検証する。
この粒度で記録しておくと、次のbetaやRelease Candidateが出たときに、どの問題が残り、どの検証を繰り返すべきか判断しやすくなります。
次に読むなら
Appleの公式発表、製品・サービス更新、開発者向け仕様変更を継続して追う場合は、ニュースレターや月次まとめも使うと、あとから更新点を見失いにくくなります。beta導入の判断では、便利なまとめ記事よりも、最後はApple公式のRelease Notesと自社の検証ログを優先してください。
更新履歴
- 2026年6月16日
Apple Developer Releases、iOS & iPadOS 26.6 Beta 2 Release Notes、Testing a beta OS、Feedback Assistantを確認して初稿を作成しました。
- 導入直前
Release NotesやDownloadページが更新される可能性があるため、ビルド番号、Xcode、既知問題の表記を再確認します。
beta OSの記事は公開後も表記が変わる可能性があるため、検証直前の再確認を前提にします。
- 2026年6月16日、Apple Developer Releases、iOS & iPadOS 26.6 Beta 2 Release Notes、Testing a beta OS、Feedback Assistantを確認して初稿を作成。
- AppleのRelease NotesやDownloadページは更新される可能性があります。検証端末に入れる直前に、ビルド番号、Xcode、既知問題の表記を再確認してください。
参照した主な情報源
- Apple Developer Releases: iOS 26.6 beta 2 (23G5043d)
https://developer.apple.com/news/releases/?id=06152026a
- Apple Developer Releases: iPadOS 26.6 beta 2 (23G5043d)
https://developer.apple.com/news/releases/?id=06152026b
- Apple Developer Documentation: iOS & iPadOS 26.6 Beta 2 Release Notes
https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-26_6-release-notes
- Apple Developer Documentation data: iOS & iPadOS 26.6 Beta 2 Release Notes JSON
https://developer.apple.com/tutorials/data/documentation/ios-ipados-release-notes/ios-ipados-26_6-release-notes.json
- Apple Developer Documentation: Testing a beta OS
https://developer.apple.com/documentation/xcode/testing-a-beta-os
- Apple Developer: Feedback Assistant
https://developer.apple.com/bug-reporting/