ios-app-store-submission

name	ios-app-store-submission
description	When the user wants to submit an iOS app to the App Store. Use when the user mentions 'App Store,' 'App Store Connect,' 'TestFlight,' 'iOS submission,' 'app review,' 'EAS build,' 'eas submit,' 'Apple review,' 'app rejection,' or 'iOS release.' This skill covers the entire process from setup to App Store review approval.

iOS Local Build & Submission

ローカルビルド → App Store Connect アップロード → TestFlight / 審査提出の完全ワークフロー。

基本方針

• ローカルビルドをデフォルトにする（EAS Buildは使わない）
• EAS Free tier は月30ビルド。デバッグ反復で一瞬で溶ける
• EASはgit cloneベース → gitに入っていないファイルはビルドに含まれない → 事故の元
• ローカルビルドはファイルシステムを直接使う → 安全・高速・無制限

---

Phase 0: ビルド前チェック

0.1 アプリ特定

# どのアプリをビルドするか確認
ls -d */app.json
# → muednote-mobile/app.json, muedear/app.json

0.2 ブランチ確認

目的	ブランチ
App Store 審査提出	main
TestFlight テスト	feature ブランチ OK

git branch --show-current
git status

0.3 バージョン・ビルド番号の確認

# app.json から現在の version と buildNumber を確認
cat <APP_DIR>/app.json | grep -E '"version"|"buildNumber"'

ルール:

• version: App Store に表示されるバージョン（例: 0.8.4）
• buildNumber: 同一 version 内で一意。常に既存の最大値 + 1 にする
• App Store Connect で使用済みの buildNumber は再利用不可
• version train が閉じたら（リジェクト等）、version を上げる必要あり

0.4 .env 管理

重要: .env の値は prebuild 時ではなく、xcodebuild archive 時に Metro bundler が注入する。

# 現在の .env を確認
cat <APP_DIR>/.env

# バックアップ（初回のみ）
cp <APP_DIR>/.env <APP_DIR>/.env.backup

用途	CLERK_KEY	API_URL
本番 (App Store)	pk_live_...	https://mued.jp
テスト (TestFlight)	pk_test_...	preview deploy URL

TestFlight ビルドの場合:

# .env を TestFlight 用に変更
# EXPO_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_...
# EXPO_PUBLIC_API_URL=https://<preview-url>.vercel.app

本番ビルドの場合:

# .env が本番値であることを確認
# EXPO_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_live_...
# EXPO_PUBLIC_API_URL=https://mued.jp

ビルド後は必ず本番値に戻す:

cp <APP_DIR>/.env.backup <APP_DIR>/.env

---

Phase 1: ローカルビルド

1.1 依存関係インストール & Prebuild

cd <APP_DIR>
npm install
npx expo prebuild --clean

--clean は ios/ を削除して再生成する。常につける。

1.2 Archive

xcodebuild -workspace ios/<SCHEME>.xcworkspace \
  -scheme <SCHEME> \
  -configuration Release \
  -archivePath build/<SCHEME>.xcarchive \
  -destination "generic/platform=iOS" \
  DEVELOPMENT_TEAM=F529L4WT3V \
  CODE_SIGN_STYLE=Automatic \
  -allowProvisioningUpdates \
  archive

アプリ別の値:

アプリ	SCHEME	workspace
MUEDnote	MUEDnote	ios/MUEDnote.xcworkspace
MUEDear	MUEDear	ios/MUEDear.xcworkspace

1.3 Export & Upload

xcodebuild -exportArchive \
  -archivePath build/<SCHEME>.xcarchive \
  -exportPath build \
  -exportOptionsPlist ExportOptions.plist \
  -allowProvisioningUpdates

-allowProvisioningUpdates がないと "No profiles found" エラーになる。

1.4 ExportOptions.plist

各アプリディレクトリに配置済み。なければ作成:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>method</key>
	<string>app-store-connect</string>
	<key>signingStyle</key>
	<string>automatic</string>
	<key>teamID</key>
	<string>F529L4WT3V</string>
	<key>uploadSymbols</key>
	<true/>
	<key>destination</key>
	<string>upload</string>
</dict>
</plist>

1.5 ビルド後の .env 復元

cp <APP_DIR>/.env.backup <APP_DIR>/.env

---

Phase 2: App Store Connect 操作

アップロード完了後、5〜15分で処理完了。

2.1 Chrome 拡張を使う場合

Claude in Chrome 拡張で App Store Connect を操作できる。

1. tabs_context_mcp で接続確認
2. appstoreconnect.apple.com に navigate
3. ユーザーにログインしてもらう（パスワード入力は禁止）
4. ログイン後、アプリ一覧からスクリーンショットで状態確認

注意:

• Chrome 拡張の接続は不安定。切れたら tabs_context_mcp で再接続
• Apple ID / パスワードは絶対に入力しない。ユーザーに任せる
• 「審査へ提出」等の不可逆操作は実行前にユーザー確認を取る

2.2 TestFlight 配信（テスト用）

1. App Store Connect → アプリ → TestFlight タブ
2. ビルドが「終了」（処理完了）であることを確認
3. Internal Testers グループを確認
4. 自動追加されていれば即テスト可能
5. されていなければ「ビルド」タブからビルドを追加

輸出コンプライアンス:

• ITSAppUsesNonExemptEncryption: false が app.json に設定済みなら自動回答
• 未設定の場合、手動で「いいえ」を選択

2.3 App Store 審査提出

⚠ ビルド前にデバッグ残骸を除去:

• Settings画面の Diagnose ボタン → 削除
• apiClient.ts 等のデバッグ console.log → 削除
• 一時的なデバッグUI（ステータスバナー等） → 削除
• .env が本番値であること → 確認

1. App Store Connect → アプリ → 配信 タブ
2. 新バージョンを作成（＋ボタン → バージョン番号入力）
3. 必須項目を確認:
   • スクリーンショット: 前バージョンから引き継がれるが、保存が必要な場合あり
   • ビルド: 「ビルドを追加」から該当ビルドを選択
   • このバージョンの最新情報: 更新内容を英語で記載
4. 保存 → 審査用に追加 → 審査へ提出

よくあるエラー:

エラー	対処
「ビルドを選択してください」	ビルドが保存されていない。再度追加→保存
「このバージョンの最新情報は必須」	What's New を記入
「スクリーンショットが必要」	新バージョンは初回保存後にスクショが引き継がれる
「バージョンXのトレインはクローズ」	version を上げる（0.8.3 → 0.8.4）

---

Phase 3: TestFlight 検証（UIデバッグ）

TestFlight では console.log は見えない。 問題の切り分けにはUI上のデバッグ表示が必須。

3.0 TestFlight 向けデバッグ診断の実装

TestFlight ビルドで新機能やAPI連携をテストする場合、Settings画面に Diagnose ボタン を必ず設置する:

// Settings画面に追加
const handleDiagnose = async () => {
  const lines: string[] = [];

  // 1. 認証状態
  lines.push(`Clerk isSignedIn: ${clerkIsSignedIn}`);
  lines.push(`Clerk userId: ${clerkUserId ?? 'null'}`);

  // 2. トークン取得テスト
  try {
    const token = await getToken();
    lines.push(`Token: ${token ? `OK (len=${token.length})` : 'NULL'}`);
  } catch (err: any) {
    lines.push(`Token ERROR: ${err.message}`);
  }

  // 3. API疎通テスト（直接 fetch で生レスポンスを確認）
  try {
    const resp = await fetch(`${BASE_URL}/api/target-endpoint`, { headers });
    const raw = await resp.json();
    // apiSuccess ラップの有無を確認
    lines.push(`API: ${resp.status}`);
    lines.push(`Has data wrapper: ${'data' in raw}`);
    lines.push(`Response keys: ${Object.keys(raw).join(', ')}`);
  } catch (err: any) {
    lines.push(`API ERROR: ${err.message}`);
  }

  Alert.alert('Diagnose', lines.join('\n'));
};

確認ポイント:

• トークンが NULL → Clerk セッションの問題
• トークン OK だが API が 401 → サーバー側のJWT検証の問題
• API 200 だがデータが undefined → レスポンスラッパー（apiSuccess）の unwrap 漏れ
• Has data wrapper: true → apiClient.handleResponse でアンラップが必要

リリース（審査提出）前に必ず:

1. Diagnose ボタンを削除（またはタップ回数イースターエッグ化）
2. apiClient.ts 等の console.log('[API] Token obtained...') 等のデバッグログを削除
3. デバッグ用の一時UIコンポーネント（バナー、ステータス表示等）を削除
4. これらを確認してからビルド → 審査提出する。デバッグUIが残ったまま審査提出しない

---

Phase 4: ビルド前検証

4.1 Provider で null を返さない

grep -r "return null" <APP_DIR>/src/providers/ 2>/dev/null

NG: if (!isLoaded) return null; OK: ローディング UI を返す

4.2 ATT プラグイン設定（広告使用アプリのみ）

grep -A5 "expo-tracking-transparency" <APP_DIR>/app.json

ベア文字列 "expo-tracking-transparency" はNG。オブジェクト形式が必須。

4.3 gitignore の確認

# modules/*/ios/ が除外されていないか確認
# ios/ ではなく /ios/ (ルート限定) であること
grep "^ios/" <APP_DIR>/.gitignore
grep "^/ios/" <APP_DIR>/.gitignore

ios/ → 全階層の ios/ を除外（ネイティブモジュールのSwiftソースも消える） /ios/ → ルートの ios/ のみ除外（正しい）

---

アプリ別クイックリファレンス

MUEDnote

cd muednote-mobile
npm install && npx expo prebuild --clean
xcodebuild -workspace ios/MUEDnote.xcworkspace -scheme MUEDnote \
  -configuration Release -archivePath build/MUEDnote.xcarchive \
  -destination "generic/platform=iOS" DEVELOPMENT_TEAM=F529L4WT3V \
  CODE_SIGN_STYLE=Automatic -allowProvisioningUpdates archive
xcodebuild -exportArchive -archivePath build/MUEDnote.xcarchive \
  -exportPath build -exportOptionsPlist ExportOptions.plist -allowProvisioningUpdates

• Bundle ID: com.mued.note
• Apple Sign In: あり

MUEDear

cd muedear
npm install && npx expo prebuild --clean
xcodebuild -workspace ios/MUEDear.xcworkspace -scheme MUEDear \
  -configuration Release -archivePath build/MUEDear.xcarchive \
  -destination "generic/platform=iOS" DEVELOPMENT_TEAM=F529L4WT3V \
  CODE_SIGN_STYLE=Automatic -allowProvisioningUpdates archive
xcodebuild -exportArchive -archivePath build/MUEDear.xcarchive \
  -exportPath build -exportOptionsPlist ExportOptions.plist -allowProvisioningUpdates

• Bundle ID: com.mued.muedear
• AdMob + ATT: あり

---

Gotchas

• EAS Build は git clone ベース: ローカルにあっても git に入っていないファイルはビルドに含まれない。.gitignore の ios/ が modules/*/ios/ の Swift ソースまで除外していた事故例あり
• version train がクローズ: App Store Connect でバージョンがリジェクト等でクローズされたら、同じバージョンでは再提出不可。version を上げる
• buildNumber は使い捨て: 一度使った buildNumber は再利用不可。App Store Connect のビルド一覧で最新番号を確認してからインクリメント
• .env はビルド後に必ず戻す: TestFlight用の pk_test のまま本番ビルドすると事故る
• prebuild の --clean は常につける: 古いネイティブコードが残って混乱する原因になる
• 新バージョンのスクショは一度保存が必要: 新バージョン作成直後はスクショが空に見えるが、保存すると前バージョンから引き継がれる

---

Common Rejection Reasons & Fixes

1. App Completeness（黒い画面）

Provider が null を返している。ローディング UI を返すように修正。

2. ATT Not Shown

expo-tracking-transparency のプラグイン設定がベア文字列。オブジェクト形式に変更。

3. Accurate Metadata

スクリーンショットが実際のアプリと一致しない。最新版に更新。

4. Sign In Issues

デモアカウント情報がアプリのフォームと一致しない。プレースホルダーが「メールアドレス」ならメール形式で記載。

Resolution Center コメントテンプレート

We have addressed the issue identified in the previous review:

**[Issue] (fixed)**
- Root cause: [Technical explanation]
- Fix: [What was changed]
- File changed: [File path]

Build [N] contains this fix. Thank you for your review.