⚠️

重要前提

安装AI Skills的关键前提是：必须科学上网，且开启TUN模式，这一点至关重要，直接决定安装能否顺利完成，在此郑重提醒三遍：科学上网，科学上网，科学上网。查看完整安装教程 →

iOS App Store 提交完整指南：本地构建、TestFlight 与审核流程

ios-app-store-submission by kimny1143/claude-code-template

77 周安装量

GitHub

安装命令

npx skills add https://github.com/kimny1143/claude-code-template --skill ios-app-store-submission

iOS 移动应用开发运维

🇨🇳中文介绍

iOS 本地构建与提交

本地构建 → App Store Connect 上传 → TestFlight / 审核提交的完整工作流程。

基本原则

默认使用本地构建 （不使用 EAS Build）
EAS Free tier 每月 30 次构建。调试迭代会瞬间耗尽
EAS 基于 git clone → 未提交到 git 的文件不会包含在构建中 → 事故根源
本地构建直接使用文件系统 → 安全、快速、无限制

阶段 0: 构建前检查

0.1 确认应用程序

# 确认要构建哪个应用
ls -d */app.json
# → muednote-mobile/app.json, muedear/app.json

0.2 确认分支

目的	分支
App Store 审核提交	`main`
TestFlight 测试	功能分支 OK

git branch --show-current
git status

0.3 确认版本号与构建编号

# 从 app.json 确认当前的 version 和 buildNumber
cat <APP_DIR>/app.json | grep -E '"version"|"buildNumber"'

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

用途	CLERK_KEY	API_URL
生产 (App Store)	`pk_live_...`	`https://mued.jp`
测试 (TestFlight)	`pk_test_...`	preview deploy URL

阶段 1: 本地构建

1.1 安装依赖 & Prebuild

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

--clean 会删除 ios/ 并重新生成。建议始终加上。

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

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

阶段 2: App Store Connect 操作

上传完成后，处理需要 5~15 分钟。

2.1 使用 Chrome 扩展的情况

可以使用 Claude in Chrome 扩展操作 App Store Connect。

1. 使用 tabs_context_mcp 确认连接
2. 导航到 appstoreconnect.apple.com
3. 让用户登录（禁止输入密码）
4. 登录后，从应用列表通过截图确认状态

Chrome 扩展的连接不稳定。断开后使用 tabs_context_mcp 重新连接
绝对不要输入 Apple ID / 密码。交给用户操作
执行“提交审核”等不可逆操作前，务必获得用户确认

2.2 TestFlight 分发（测试用）

App Store Connect → 应用 → TestFlight 标签页
确认构建状态为“完成”（处理完毕）
确认 Internal Testers 组
如果自动添加，即可立即测试
如果未添加，则从“构建”标签页添加构建

如果 app.json 中已设置 ITSAppUsesNonExemptEncryption: false，则会自动回答
如果未设置，则手动选择“否”

2.3 App Store 审核提交

⚠ 构建前清除调试残留:

Settings 界面的 Diagnose 按钮 → 删除
apiClient.ts 等处的调试 console.log → 删除
临时调试 UI（状态横幅等） → 删除
.env 为生产值 → 确认

App Store Connect → 应用 → 分发标签页
创建新版本（+ 按钮 → 输入版本号）
确认必填项:
- 屏幕截图 : 会从前一版本继承，但有时需要保存
- 构建 : 从“添加构建”中选择对应构建
- 此版本最新信息 : 用英文填写更新内容
保存 → 添加以供审核 → 提交以供审核

错误	处理方式
“请选择构建”	构建未保存。再次添加→保存
“此版本最新信息为必填项”	填写 What's New
“需要屏幕截图”	新版本首次保存后会继承屏幕截图
“版本 X 的 train 已关闭”	提升 version（0.8.3 → 0.8.4）

阶段 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）解包遗漏
Has data wrapper: true → 需要在 apiClient.handleResponse 中解包

发布（提交审核）前务必:

删除 Diagnose 按钮（或改为点击次数彩蛋）
删除 apiClient.ts 等处的 console.log('[API] Token obtained...') 等调试日志
删除调试用的临时 UI 组件（横幅、状态显示等）
确认以上内容后再进行构建 → 提交审核。切勿在调试 UI 残留的情况下提交审核

阶段 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/（正确）

各应用快速参考

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: 有

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: 有

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 始终要加上 : 残留的旧原生代码会导致混乱
新版本的屏幕截图需要先保存一次 : 创建新版本后，屏幕截图看起来是空的，但保存后会从前一版本继承

常见拒绝原因与修复方法

1. App Completeness（黑屏）

Provider 返回了 null。修改为返回加载 UI。

expo-tracking-transparency 的插件配置是裸字符串。改为对象形式。

3. Accurate Metadata

屏幕截图与实际应用不符。更新为最新版本。

演示账户信息与应用表单不符。如果占位符是“メールアドレス”，则用邮件格式填写。

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.

🇯🇵日本語

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 配信（テスト用）

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

輸出コンプライアンス:

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

2.3 App Store 審査提出

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

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

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

よくあるエラー:

エラー	対処
「ビルドを選択してください」	ビルドが保存されていない。再度追加→保存
「このバージョンの最新情報は必須」	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 でアンラップが必要

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

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

Weekly Installs

Repository

kimny1143/claud…template

First Seen

Feb 9, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykPass

Installed on

claude-code61

gemini-cli34

codex34

opencode33

github-copilot33

amp32

Azure 升级评估与自动化工具 - 轻松迁移 Functions 计划、托管层级和 SKU

124,500 周安装

iOS App Store 提交完整指南：本地构建、TestFlight 与审核流程

🇨🇳中文介绍

iOS 本地构建与提交

基本原则

阶段 0: 构建前检查

0.1 确认应用程序

0.2 确认分支

0.3 确认版本号与构建编号

相关 Skills

0.4 .env 管理

阶段 1: 本地构建

1.1 安装依赖 & Prebuild

1.2 Archive

1.3 Export & Upload

1.4 ExportOptions.plist

1.5 构建后恢复 .env

阶段 2: App Store Connect 操作

2.1 使用 Chrome 扩展的情况

2.2 TestFlight 分发（测试用）

2.3 App Store 审核提交

阶段 3: TestFlight 验证（UI调试）

3.0 为 TestFlight 实现调试诊断功能

阶段 4: 构建前验证

4.1 Provider 不要返回 null

4.2 ATT 插件配置（仅限使用广告的应用）

4.3 确认 gitignore

各应用快速参考

MUEDnote

MUEDear

注意事项

常见拒绝原因与修复方法

1. App Completeness（黑屏）

2. ATT Not Shown

3. Accurate Metadata

4. Sign In Issues

Resolution Center 评论模板

🇯🇵日本語

iOS Local Build & Submission

基本方針

Phase 0: ビルド前チェック

0.1 アプリ特定

0.2 ブランチ確認

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

0.4 .env 管理

Phase 1: ローカルビルド

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

1.2 Archive

1.3 Export & Upload

1.4 ExportOptions.plist

1.5 ビルド後の .env 復元

Phase 2: App Store Connect 操作

2.1 Chrome 拡張を使う場合

2.2 TestFlight 配信（テスト用）

2.3 App Store 審査提出

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

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

Phase 4: ビルド前検証

4.1 Provider で null を返さない

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

4.3 gitignore の確認

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

MUEDnote

MUEDear

Gotchas

Common Rejection Reasons & Fixes

1. App Completeness（黒い画面）

2. ATT Not Shown

3. Accurate Metadata

4. Sign In Issues

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

最新 Skills