7月13日の朝、iOS 27 のパブリックベータ公開の知らせを見て、まずビルド番号を確かめました。24A5380h。手元の検証機に入っている開発者向けベータ3と、同じ文字列でした。
その時点で私の判断は決まりました。入れ替える作業は発生しない、と。
ビルド番号がひとつ同じだっただけの話ですが、ベータの扱いはこの種の「確かめてから動く」の積み重ねだと感じています。個人でアプリを保守していると、検証に使える端末も時間も限られます。だからこそ、入れる前に決めておくことがいくつかあります。
同じビルド番号が、最初に教えてくれること
今回のパブリックベータ 24A5380h は、開発者向けベータ3と同一のビルドです。名前が違うだけで、中身は同じものが配信されています。
ここから読み取れることは単純です。すでに開発者向けベータを入れている端末を、パブリックベータへ「移す」意味はありません。移行先に新しいものは何もないからです。
一方、まだ何も入れていない方にとっては、パブリックベータが iOS 27 に触れる最短の入口になりました。開発者アカウントの設定を経由せずに、同じ中身へ到達できます。
| いまの状態 | 7/13 時点で取る行動 |
|---|---|
| 開発者向けベータ3が入っている | 何もしない。同じビルドなので入れ替えは無意味 |
| ベータ未導入・検証機がある | パブリックベータを検証機に入れる |
| ベータ未導入・端末が1台だけ | 入れない。理由は次の節に書きます |
配信物の中身は、Apple Intelligence の新機能、Siri の強化、新しいペアレンタルコントロール、Liquid Glass の refinements（見え方の強度を調整するスライダーが入りました）、Spotlight の改善、そして全体的な性能向上です。
このうち、自分のアプリの見た目に直接響くのは Liquid Glass の強度スライダーだと私は見ています。理由は後述します。
端末を決めてから、はじめて入れる
ベータの話で最も戻しにくいのは、OS そのものではなく端末の選択です。
iOS はダウングレードの署名がいずれ閉じます。閉じた後は、正規の手順で前のバージョンへは戻れません。加えて、新しい OS で取ったバックアップは、古い OS へ復元できません。つまり「ベータを入れて、駄目なら戻す」という往復は、実際には片道になりがちです。
私が線を引いているのは、次の3点です。
- 日常の連絡と決済が乗っている端末には入れない
- 実機でしか確認できない課金フローの最終確認に使う端末には入れない
- ベータ用の端末には、業務の主要アカウントでサインインしない
| 端末の役割 | iOS 27 ベータ | 理由 |
|---|---|---|
| 日常利用のメイン機 | 入れない | 戻せない前提では生活側のリスクが大きすぎる |
| 課金・実機確認の本番相当機 | 入れない | リリース中のアプリの不具合切り分けが濁る |
| 検証専用の旧端末 | 入れる | 初期化して作り直せる範囲に被害が収まる |
端末が1台しかない場合、私は入れない側に倒します。触りたい気持ちは分かるのですが、リリース中のアプリに問い合わせが来たとき、手元の環境がベータだと「アプリの不具合」と「OS ベータの挙動」を切り分けられなくなります。切り分けられない環境は、検証機として機能しません。
入れる前にアーカイブしておくもの
検証機に入れると決めた後、私が必ず先に残すものが3つあります。
現行 OS でのバックアップ。ベータを入れた後に取ったものは、元の OS へ戻せません。入れる直前の状態を、暗号化バックアップとして手元に置いておきます。
現在 App Store に出ているビルドの成果物。.ipa と dSYM を、いま出ているバージョンのぶんだけ確実に保管します。ベータ環境でクラッシュを見つけたとき、シンボリケートできないログはほとんど手掛かりになりません。
現行 OS でのスクリーンショット一式。これが今回いちばん効くと思っています。Liquid Glass の強度スライダーが入るということは、同じ画面が同じ端末で違う見え方をしうる、ということです。比較対象が手元にないと、「ベータで変わったのか、もともとこう見えていたのか」が判断できません。
なお、iOS 26 SDK 以降でのビルドが App Store Connect へのアップロード要件になっている件は、4月28日から続いている別の話です。ベータ検証の可否とは切り離して考えたほうが混乱しません。手元の提出パイプラインがその要件を満たしているかは、ベータの前に済ませておく確認です。
自分のアプリの、どこから見るか
ベータを入れた検証機で、全機能を端から確認していく余裕は私にはありません。当たりを付けて、順番を決めます。
私が保守しているのは背景画像を扱うアプリで、画面の作りとして「写真の上に半透明のパネルを重ね、その上に文字を載せる」構造を多用しています。ここに Liquid Glass の強度スライダーが効きます。ユーザーが強度を下げた状態と上げた状態で、パネル背後の写真の情報量が変わり、その上の文字のコントラストが変わります。
だから私の確認順は、強度スライダーを最小にした状態と最大にした状態で、文字が読めるかどうかから始まります。中間値ではなく両端から見るのは、破綻するとしたら端だからです。
| iOS 27 の変更 | 自分のアプリで見る箇所 | 優先度の判断 |
|---|---|---|
| Liquid Glass の強度スライダー | 半透明パネルの上に文字を置いている画面 | 高（ユーザー設定で見え方が変わる） |
| Spotlight の改善 | App Intents・インデックス登録している要素 | 中（露出が増える可能性がある側） |
| 新しいペアレンタルコントロール | 年齢設定に関わる導線・表示物 | アプリの対象年齢次第 |
| Apple Intelligence・Siri の強化 | Intent を公開している機能 | 公開していなければ後回しでよい |
OS 側の AI 機能をどこまで自分のアプリに取り込むかという判断は、ベータ検証とは別の設計の話になります。その線引きについては「OS の AI に任せるか、自分で持つか — iOS 27 世代の機能境界を決める」で考えを書いています。
確認の手順を、毎回同じ形に畳む
ベータは繰り返し来ます。毎回その場で思い出しながらやると、確認する箇所が回によってぶれます。ぶれた確認は、あとから比較できません。
私はチェックリストをリポジトリの中に置いています。端末の役割、アーカイブ対象、確認する画面の順序を、テキストで書いたものです。ベータが来るたびにそれを開き、終わったら気づいたことを1行足します。
自動化できる部分もあります。ただ、任せる範囲は絞っています。
| 作業 | エージェントに任せるか | 線を引いた理由 |
|---|---|---|
| 各画面のスクリーンショットを一巡して撮る | 任せる | 手順が固定で、結果がファイルとして残る |
| 現行 OS 版との画像差分を出す | 任せる | 差が出た箇所の列挙までは機械の仕事 |
| 差分が「許容範囲か」の判断 | 任せない | 読めるかどうかは目で見ないと分からない |
| どの端末にベータを入れるかの決定 | 任せない | 戻せない選択を委譲する理由がない |
判断材料が全部リポジトリの中にあるものは任せ、端末や見え方のように外にあるものは手元に残す。私はこの基準で分けています。
配布の側では、App Store Connect が Xcode 27 ベータでビルドしたアプリの TestFlight に対応しました。検証機へビルドを届ける経路としては、これがいちばん手数が少なくて済みます。配信そのものの自動化については「AntigravityでTestFlightベータ配信を完全自動化する実践ガイド」にまとめてあります。
Figma と Sketch 向けの公式デザインキットも iOS 27・iPadOS 27・macOS 27 で提供が始まりました。実機を触る前に、デザイン側で当たりを付けておく手もあります。
次の一歩
もし開発者向けベータ3が入っているなら、今回はやることがありません。ビルドが同じである以上、それが正解です。
まだ入れていないなら、最初に決めるのは端末です。OS を入れる前に、その端末を初期化して作り直せるかどうかを自分に確認してください。作り直せない端末は、検証機ではありません。
私自身、戻せると思い込んで痛い目を見たことがあります。同じ回り道をされる方が減れば嬉しく思います。