ガイドライン4.8 Login Services:Appleでサインインは必須?
著者:Mehdi Azizi
公開・9 分
GoogleやFacebookログインがあるなら、メールを隠せるApple等のログインも必要です。例外、Expoのコード、アカウント削除まで解説。
ガイドライン4.8は、アプリがGoogle、Facebookなどのサードパーティログインでメインアカウントを作成する時点で適用されます。その場合、同等の別のログイン手段が必要になります。その手段は、データを名前とメールアドレスに限定し、メールアドレスを非公開にでき、同意なしに広告目的でユーザーを追跡しないものでなければなりません。2024年1月以降、この手段は必ずしも「Sign in with Apple」である必要はありません。ただし、Appleがリジェクトのメッセージで名前を挙げているのはこれだけです。
僕のアプリでは、SolysとNoleraがApple、Google、メールアドレスでのログインに対応しています。このガイドでは、Appleの現在の規約文から出発し、Supabaseと連携したExpoアプリにAppleでのサインインを追加する方法と、それによってアカウント削除がどう変わるかを説明します。リジェクト理由の全体像を知りたい場合は、Appleがアプリをリジェクトする理由を読んでください。
ガイドライン4.8 Login Servicesには何が書かれている?
4.8はApp Review Guidelinesのセクション4「Design」にあります。対象は、メインアカウントの作成や認証に「a third-party or social login service」を使うアプリです。Facebook Login、Google Sign-In、Log in with X、LinkedIn、Amazon、WeChatなどが該当します。これらのアプリは「as an equivalent option」として、次の3つの条件を満たす別のログインサービスも提供しなければなりません。
| Appleの条件 | 平たく言うと |
|---|---|
| データの限定 | 名前とメールアドレスだけ |
| メールを非公開にできる | ユーザーがメールを隠せる |
| 同意なしの広告なし | 同意なしの広告トラッキングは一切なし |
規約文はメインアカウントも定義しています。ユーザーがアプリ内で本人確認、ログイン、機能へのアクセスのために作成するアカウントです。この定義によれば、ファイルのインポートにしか使わないGoogleボタンはメインアカウントを作成しません。4.8が対象にしているのは、アプリに入るための画面です。
2024年1月の変更点
2024年より前は、メインアカウントにサードパーティログインを使うアプリには「Sign in with Apple」が義務付けられていました。2024年1月25日、Appleはこの点を緩和しました。Appleでのサインインか、プライバシーを保護する同等のサービスのどちらかを提供すればよくなったのです。今でも逆のことを書いているページはたくさんあります。Expoのドキュメントにも、サードパーティログインがあるアプリはAppleでのサインインを提供しなければならない、とまだ書かれています。
実際には、Appleの開発者フォーラムに公開された4.8のリジェクトメッセージは「Note that Sign in with Apple meets the requirements specified in guideline 4.8」で締めくくられています。Appleは他の適合サービスの名前を一つも挙げていません。審査担当者相手に推測ゲームをしないために、僕はAppleでのサインインを追加しています。
規約文が定める5つの例外
Appleは、別のログイン手段が求められない5つのケースを挙げています。
- アプリが自社のアカウントシステムだけを使っている場合。たとえばメールアドレスとパスワード、またはメールで送るコードなど。
- アプリが代替アプリマーケットプレイスである、またはそこで配布されていて、そのマーケット独自のログインを使う場合。
- 教育、企業、業務向けのアプリで、既存の学校や企業のアカウントが必要な場合。
- 政府や業界が支援する電子IDシステムを使う場合。
- 特定のサードパーティサービスのクライアントアプリで、ユーザーが自分のコンテンツにアクセスするためにメールやSNSにログインする場合。
これらの例外を見る前に、まず自問してください。そもそもアプリにアカウントは必要でしょうか?必要ないなら、ガイドライン5.1.1(v)はログインなしで使えるようにすることを求めています。詳しくはガイドライン5.1.1のガイドで説明しています。
| ログイン画面の構成 | 4.8は適用される? |
|---|---|
| アカウントなし | いいえ |
| メールまたはコードのみ | いいえ |
| Googleのみ | はい |
| Googleとメール | 基本的に、はい |
| GoogleとApple | はい、そして適合 |
| 既存の学校アカウント | いいえ |
| インポート用のGoogle | いいえ、アカウントなし |
ExpoアプリにSign in with Appleを追加する
1. モジュールをインストールしてケイパビリティを宣言する
npx expo install expo-apple-authentication
Expoのドキュメントでは、次にアプリの設定でケイパビリティを有効にするよう指示されています。
{
"expo": {
"ios": {
"usesAppleSignIn": true,
"infoPlist": { "CFBundleAllowMixedLocalizations": true }
}
}
}
2行目は、ボタンをiPhoneの言語で表示するためのものです。EAS Buildでは、ビルド時にApp IDのケイパビリティが有効になります。これはネイティブの設定なので、新しいビルドでしか反映されず、リモートアップデートでは絶対に反映されません。
自分のキットのスターターコードを見直していて見つけた落とし穴があります。このケイパビリティは、シミュレータでアプリを起動するだけでも署名が必要になります。「Apple Development」証明書のないMacでは、ローカルビルドが「No code signing certificates are available to use」で失敗していました。修正方法は、認証サーバーが設定されているときだけAppleでのサインインを有効にすることです。
2. 公式ボタンを、Googleと同じくらい目立つように表示する
Appleのデザインルールは明確です。Appleのボタンは他のログインボタンより小さくしてはならず、画面をスクロールしないと見えない位置に置いてもいけません。Expoのコンポーネントは、Appleが認めたタイトル付きの公式ボタンを描画してくれます。
import * as AppleAuthentication from "expo-apple-authentication";
import { useEffect, useState } from "react";
export function BoutonApple({ onPress }: { onPress: () => void }) {
const [disponible, setDisponible] = useState(false);
useEffect(() => {
AppleAuthentication.isAvailableAsync().then(setDisponible);
}, []);
// Androidとweb:Appleでのサインインはないので、ボタンも出さない。
if (!disponible) return null;
return (
<AppleAuthentication.AppleAuthenticationButton
buttonType={AppleAuthentication.AppleAuthenticationButtonType.CONTINUE}
buttonStyle={AppleAuthentication.AppleAuthenticationButtonStyle.BLACK}
cornerRadius={12}
style={{ width: "100%", height: 50 }}
onPress={onPress}
/>
);
}
Expoによると、幅と高さを指定しないとボタンは表示されません。色と角丸はstyleではなく、buttonStyleとcornerRadiusで指定します。
3. Supabaseでセッションを開始する
import * as AppleAuthentication from "expo-apple-authentication";
import { supabase } from "./supabase";
export async function connexionApple(): Promise<"ok" | "annule"> {
try {
const credential = await AppleAuthentication.signInAsync({
requestedScopes: [
AppleAuthentication.AppleAuthenticationScope.FULL_NAME,
AppleAuthentication.AppleAuthenticationScope.EMAIL,
],
});
if (!credential.identityToken)
throw new Error("Appleのトークンがありません");
const { error } = await supabase.auth.signInWithIdToken({
provider: "apple",
token: credential.identityToken,
});
if (error) throw error;
// 名前は初回の認可時にしか届かないので、すぐに保存する。
const prenom = credential.fullName?.givenName;
if (prenom) await supabase.auth.updateUser({ data: { prenom } });
return "ok";
} catch (e) {
if ((e as { code?: string }).code === "ERR_REQUEST_CANCELED")
return "annule";
throw e;
}
}
Supabaseのドキュメント、Expoのドキュメント、Appleのデザインルールから、重要なポイントが4つあります。
- Supabaseで、AppleプロバイダのClient IDsにバンドルIDを登録してください。 ネイティブ専用のアプリなら、ログインにシークレットキーは不要です。Expo Goでテストする場合は
host.exp.Exponentも追加します。 - 名前とメールアドレスは一度しか届きません。 2回目以降のログインではAppleは返してくれないので、最初のレスポンスで保存してください。
- メールアドレスはリレーアドレスの場合があります。 Appleは、その後で個人のメールアドレスを改めて求めないよう推奨しています。
- キャンセルはエラーではありません。 Noleraでは、Appleのシートを閉じても赤いエラーメッセージは出ません。ユーザーが意図して行った操作だからです。
2026年8月にSolysで実際に起きたケースです。AppleとGoogleのボタンはアプリにありましたが、Supabaseではどちらのプロバイダも有効になっていませんでした。コードは正しく、修正はサーバー側だけで済み、新しいビルドは不要でした。審査担当者の前でAppleのボタンが失敗すれば、4.8の代わりに2.1でリジェクトされます。 詳しくはガイドライン2.1のガイドにあります。
4. 実機のiPhoneでテストする
Expoによると、シミュレータでのテストは限定的で、Expo Goで受け取る認証情報は公開版アプリのものとは異なります。ログイン、ログアウト、再ログインを、TestFlightのビルドを使って実機のiPhoneでテストしてください。
Appleでのサインインとアカウント削除
ガイドライン5.1.1(v)は、アプリ内で作成したアカウントをアプリ内から削除できることを求めています。Appleでのサインインを使う場合、アカウント削除に関するAppleのページはもう一つ手順を追加しています。Sign in with AppleのREST APIを使って、ユーザーのトークンを取り消すことです。
この取り消しには2つのものが必要です。認可コードを検証して得られるユーザーのトークンと、Sign in with Appleの秘密鍵で署名したシークレットです。ネイティブのログインにはシークレットキーが不要でも、取り消しには必要で、そのキーはサーバーに置いておきます。 その理由はExpoアプリのシークレット APIキーで説明しています。
Noleraでは、アカウント削除のときにアプリがもう一度Appleでのサインインを求め、新しい認可コードを取得します。それをサーバー関数に送り、サーバー関数がAppleとコードを交換してからトークンを取り消します。ユーザーがキャンセルした場合は、わかりやすいメッセージでそれを伝え、何も削除しません。データ、サブスクリプション、テストを含む残りの流れはiOSのアカウント削除にまとめています。
4.8でリジェクトされたらAppleにどう返信するか
Appleのメッセージには2つの解決策が示されています。同等の手段を追加するか、すでにあるならApp Store Connectで返信し、それがどれで、なぜ3つの条件を満たすのかを説明するかです。Appleはログイン画面が写っているスクリーンショットの更新も勧めています。App Reviewへの返信の手順は、他のガイドラインの場合と同じです。
英語のテンプレートを置いておきます。状況に合わせて調整してください(ビルド番号は置き換えます)。
Hello,
Thank you for your review.
Build X adds Sign in with Apple as an equivalent login option.
It appears on the same screen as Google Sign-In, with the same
size, and is visible without scrolling.
How to verify: launch the app, open the sign-in screen and
tap "Continue with Apple".
We also updated the screenshots that show the sign-in screen.
Best regards,
提出前の4.8チェックリスト
- アプリにアカウントが必要かどうかを把握している。不要なら、ログインなしで使える。
- Google、Facebook、Xでアカウントを作成するなら、同じ画面にAppleでのサインインがある。
- Appleのボタンは公式ボタンで、他と同じ大きさがあり、スクロールせずに見える。
- サーバー側でAppleプロバイダが有効になっていて、バンドルIDが登録されている。
- キャンセルするとエラーメッセージなしでログイン画面に戻る。
- 名前とメールアドレスは初回ログイン時に保存している。
- アカウント削除では、サーバーからAppleのトークンを取り消している。
- 一度もアプリにログインしたことのないApple Accountで、実機のiPhoneを使ってすべてテストした。
- スクリーンショットのログイン画面は、提出したビルドのものと一致している。
アプリを再提出する前にリジェクトを解消する
4.8でリジェクトされたばかりなら、Apple Review Kitに僕が毎回提出前に確認していることをまとめています。Claude Codeでプロジェクトを見直し、Appleにリジェクトされたときの返信を準備する2つのスキルも入っています。人の目で見てほしいなら、僕と1時間のセッションを予約してください。メッセージを一緒に読み、ログイン画面を確認します。リジェクト後の全体的な進め方はAppleにリジェクトされたアプリのページにあります。
初めてのリリースを準備しているなら、無料の診断を受けてください。最初に取り組むべきステップがわかり、僕のApple リジェクト対策チェックリストも届きます。
Appleがアプリを承認すると保証できる人はいません。それでも、適切な場所にAppleでのサインインを追加すれば、少なくともこのリジェクト理由はリストから消せます。
よくある質問
iOSでAppleでのサインインは必須ですか?
いいえ、すべての場合ではありません。必要になるのは、GoogleやFacebookのようなサードパーティログインでメインアカウントを作成するアプリだけです。2024年1月以降は同等の別サービスでも代替できますが、Appleが適合例として挙げているのはAppleでのサインインだけです。
「Guideline 4.8 - Design - Login Services」とはどういう意味ですか?
Appleのメッセージに書かれるリジェクトの見出しです。アプリがサードパーティログインを提供しているのに、データを名前とメールアドレスに限定し、メールアドレスを隠せて、同意なしに広告に使わない同等の手段を用意していない、という意味です。
Googleと並べてメール登録があれば十分ですか?
保証はありません。規約文はメールアドレスを非公開にできるサービスを求めていますが、通常のフォームはメールアドレスを入力させます。Appleはこのケースについて見解を出しておらず、リジェクトメッセージで挙げているのはAppleでのサインインだけです。僕ならこのリスクは取りません。
AndroidでもAppleでのサインインを提供する必要がありますか?
いいえ。4.8はApp Storeのルールで、Expoのモジュールが動くのはiOSだけです。AndroidではisAvailableAsync()がfalseを返すのでAppleのボタンは表示されず、Googleだけでも問題ありません。
4.8でリジェクトされたら新しいビルドが必要ですか?
はい、ほとんどの場合は必要です。Appleでのサインインにはビルド時に有効になるネイティブのケイパビリティが必要で、リモートアップデートでは追加できません。唯一の例外は、アプリにすでに適合する手段があり、返信でそれをAppleに説明すれば済む場合です。