做跨平台游戏这几年我最大的感受是在 Cocos Creator 里做游戏是一回事把它真正变成 iPhone 上能下载的 App 又是一回事。刚入行时我以为引擎里点一下 Build再用 Xcode 点一次 Run就能直接拿去上架 App Store结果光是理清开发者证书和发布签名的关系就折腾了半个月后面还被苹果审核连拒三次。跑完整个流程之后回头再看其实 Cocos Creator 打包 iOS 游戏并上架这件事并不复杂但链条特别长中间任何一环出错反馈都不直观。这篇东西不是官方文档的复述而是我自己在 Creator 2.x 老项目、Creator 3.x 新项目里反复跑过 iOS 包之后攒下来的实操记录。适合第一次接触 iOS 打包的 Cocos 开发者也适合已经上架过其他平台、但第一次被 iOS 工程和 Xcode 弄到头疼的人。我会按真实流程走一遍构建前的工程配置、Creator 导出原生工程、Xcode 签名与真机调试、Archive 打包上传、TestFlight 测试再到 App Store 审核时碰到的常见问题。每一步我都会把“为什么要这么做”讲清楚因为只告诉你点哪里下一次换个项目照样卡住。1. 先理清 Cocos 到 iOS 的完整链路1.1 为什么“点一下构建”不等于已经出包Cocos Creator 的构建按钮很容易让人产生误会。尤其你以前只做过 Android 包习惯了在编辑器里一键出 APK到 iOS 这里会发现Creator 构建完并没有直接生成一个可以上架的 .ipa而是生成了一个原生 Xcode 工程。这个工程才是真正能被苹果工具链识别的东西。后续的编译、签名、打包、上传全部要交给 Xcode 或命令行工具处理。也就是说上架 iOS 是一段“双构建”流程第一段是 Cocos Creator 把你的游戏资源和脚本按原生工程需要的格式整理出来第二段是 Xcode 读取这些内容链接 Cocos 引擎库和系统框架最终编译成 iOS App。所以你在 Creator 面板里看到的“构建完成”只代表第一段结束了。打开生成的目录你会看到一堆 .h、.mm、.swift 文件还有 ios 目录下的 xcodeproj 工程文件后面所有原生操作都围绕这些东西展开。连 Android 都不需要依赖 Android Studio 的人到 iOS 这一步也必须接受Xcode 不是可选项是必经环节。1.2 Creator 2.x 和 3.x 在 iOS 构建上的差异如果你的项目还是 Creator 2.4.x构建 iOS 插件会直接生成一个可用的 .xcodeproj位置通常在 build 目录下。这个工程相对简单双击就能打开。Creator 3.x 之后原生构建逻辑变化很大工程改走 CMake 组织流程很多原生存量代码都被收敛到引擎的 native 目录里。生成的工程路径一般是 build/ios/proj但可执行的名字会根据你填的包名变化别习惯性地只找固定名称。在 3.x 里要特别注意构建选项里有一项叫“生成 Xcode 工程”它和“生成资源”有时是分开的。资源生成慢工程生成快如果你只点了构建资源发现目录里没有 xcodeproj 别奇怪回到构建任务里把生成工程的任务补上就好。版本之间的另一个差异是原生插件的接入方式。2.x 时代很多国内 SDK 组件都有成熟的 OC 或者 JS 绑定方案3.x 初期因为原生目录结构大改不少第三方插件一度没跟上导致很多人卡在“引擎升级后原生不能编译”这一步。如果你要上架的是一款包含登录、支付、统计等原生能力的游戏建议先确认你依赖的 SDK 明确支持当前 Creator 版本而不是先写完游戏逻辑再去踩原生兼容性的坑。1.3 你需要准备哪些账号和工具打包 iOS 不能绕开的硬性条件是开发者账号。个人开发者账号或公司开发者账号都能上架 App Store区别主要在 Team 名称、团队成员管理和 App 的归属主体上。个人做小游戏个人账号完全够用。账号里几个角色要说清楚Account Holder 是账号所有者拥有最高权限Admin 能管理证书、设备和 AppApp Manager 能管理 App 的元数据和用户但证书方面权限有限Developer 只能真机调试。Cocos 属于引擎层不需要参与开发者账号管理但你有合作伙伴或外包团队协作时记得角色分配会影响谁能提交审核版本。除了开发者账号你还需要几样东西一台能装 Xcode 的 Mac、Xcode 本体、Cocos Dashboard 对应版本的 Creator、可用的 Apple ID。Xcode 版本最好和系统版本配套别拿最新系统配老版 Xcode打包时会遇到一堆签名工具链的兼容报错。提示首次准备环境时别把时间花在“装哪个模拟器”上。模拟器 Runtime 可以后续按需下载但 Xcode 必须装完。Cocos 游戏上架前必须用真机验证模拟器只适合快速看 UI 或粗略功能很多原生 API 行为和性能数据在模拟器上不准。2. 构建前要检查的基础配置2.1 包名、版本号、构建号一个都不能随意Cocos Creator 项目里有个地方叫“项目设置”其中“包名”这一项几乎决定了 iOS 上架的世界里 App 的身份证号。苹果生态里它叫 Bundle Identifier规则是反向域名格式比如 com.mycompany.matchgame只能包含字母、数字、点和连字符不能有下划线。包名是项目创建后最不该改的东西。一旦你用这个包名在某个渠道出过包、接过后台数据、注册过推送后面再改包名所有关联关系全部断裂甚至会出现“设备上覆盖安装不成功”“支付回调校验不过”这种历史遗留问题。所以项目初始化时一定先想清楚最终要上架的主体域名和产品名一次性填好。另一方面iOS 有 Version 和 Build 两个容易搞混的概念。Version 是对用户展示的版本号比如 1.0.0Build 是内部递增的构建号用户看不到但每次上传都必须大于上一次否则 App Store Connect 会提示“构建版本号非法”。我的习惯是版本号只在功能迭代时手动加Build 号则直接用一个脚本或者变量在构建时递增避免每次手动改还容易漏。很多人在 Creator 项目设置里只填一次版本号后续每次打包都用同一个值等到上传 App Store 就会卡在“Build 已存在”这个异常上。正确做法是上一版 Build 为 1下一个出包至少是 2哪怕 Version 还是 1.0.0 也可以等正式发新功能时再把 Version 改成 1.0.1Build 重新从 1 开始。2.2 图标和启动屏最容易拖慢进度的地方iOS App 图标有一套比较老的尺寸规范不同设备会用到从 20pt 到 1024pt 的多种规格。好在你把图标上传到 App Store Connect 后台时系统会根据你提供的 1024x1024 无透明通道大图自动生成各尺寸图标Xcode 工程里其实也会用 Asset Catalog 来自动处理不需要手做十几个 png。但 Cocos 游戏工程的图标和 Launch Screen启动屏仍需要在 Creator 里配置。Creator 的“项目设置”里如果提供了图标构建时引擎会把它写入原生资产目录。我第一次做的时候只改了桌面的 1024 大图忘了看“竖屏/横屏”的启动图方向结果安装到手机上启动瞬间有一块黑边或拉伸变形观感非常业余。Launch Screen 的推荐做法是固定颜色 居中的 Logo不要搞复杂的动画。苹果后台审核时如果启动屏图片显得过于简陋或者比例错乱不影响功能但确实会在“视觉设计”这一层被扣分。还有一点经常被忽略游戏如果支持横竖屏切换启动屏也要提供多方向的适配或者直接设定只支持某一种方向避免提交后用户在系统设置里强制旋转出现布局异常。2.3 iOS 权限声明写多了不行写少了会崩溃游戏经常是到真机测试阶段才暴露权限问题。比如你的游戏接了某个广告 SDKSDK 内部需要访问用户相册来保存一张分享图但你的 Info.plist 里没有写任何相册用途描述。真机上 SDK 一旦调用相册接口App 就会直接闪退控制台会输出类似“This app has crashed because it attempted to access privacy-sensitive data without a usage description”的日志。Cocos 引擎自带的编辑器不会主动帮你生成所有权限文案它默认只是在资源层做了一个最小配置。你需要根据游戏实际用到的能力在原生工程的 Info.plist 里加对应键值。常见的有相机权限 NSCameraUsageDescription、相册权限 NSPhotoLibraryUsageDescription、麦克风权限 NSMicrophoneUsageDescription、位置权限 NSLocationWhenInUseUsageDescription。反过来也不要盲目地把所有权限字符串都写进 plist。苹果审核时有静态扫描机制如果你的 App 其实没有调用相机功能Info.plist 却存在相机权限描述审核人员可能会追问理由。第一次过审时我因为批量拷贝别人的权限模板平白无故被要求解释为什么要用摄像头最后只能发个新版去掉多余描述才过审。2.4 隐私政策、ATT 弹窗这些不是小事如果只是开发一个单机休闲游戏你可能觉得隐私政策完全没必要。但 App Store 上架时几乎所有需要收集用户数据的 App 都必须提供隐私政策链接且链接必须在你提审前填到 App Store Connect 的对应字段里。即使你的游戏完全不上报数据苹果也默认你需要解释数据收集情况。对于 Cocos 游戏来说真正常见的坑是广告归因。接了 AdMob、Meta 广告或者一些国内聚合广告 SDK 后SDK 可能会读取 IDFA广告标识符此时必须遵守 App Tracking Transparency 规则。简单说你要在 Info.plist 里配置 NSUserTrackingUsageDescription并在 App 启动后弹 ATT 权限框用户同意后才能追踪。如果一个功能确实没有用到 IDFA我建议直接不要碰广告 SDK 的追踪开关并且提审时在后台的数据收集栏中如实选择。苹果的机器审核会探测代码里是否包含获取 IDFA 的逻辑如果探测到但后台隐私声明没写对应用途大概率会被打回重审。见过不少团队因为“明明没做追踪但 SDK 默认带了”而被拒排查起来极其被动。另一个经常被提审备注要求说明的是你的游戏是否需要用户登录是否支持删除账号。如果游戏有账号体系但 App 内找不到“删除账号”入口苹果会以 5.1.1(v) 的 App 账号删除条款拒绝。这一点对很多休闲游戏是没有影响的但如果你的游戏接入了第三方社交登录就一定要设计好账号注销逻辑。3. 从 Creator 导出原生工程操作与避坑3.1 构建面板的关键选项怎么选Cocos Creator 顶部菜单找到“项目”-“构建发布”弹出构建窗口后先点击“新建构建任务”。平台选择 iOS这里不要选成“iOS 模拟器”或“Mac”除非你想本地调试。在构建选项里包名先用刚才在项目设置里确认好的那个 Bundle Identifier其他几个常用项值得逐一说清。MD5 Cache 建议开启它会让资源文件名变成基于内容的哈希值好处是热更新时能有效避免老资源缓存残留。缺点是每次更改资源后构建出来的文件名不同如果你还接了自己写的资源服务器需要认真对待资源版本表否则新旧客户端会加载混乱。Polyfills 和脚本压缩默认开启就好。iOS 的 JavaScriptCore 对 ES6 的支持这些年越来越强但引擎内部的运行环境和浏览器不完全一致保留 polyfill 可以避免莫名其妙的 API 报错。纹理压缩格式保持默认或选择支持 iOS 的 PVRTC / ASTC。iOS 设备从 A13 以后对 ASTC 支持很好如果你的游戏用了大量高清图资源体积精简约 30% 是完全可能的。注意如果你在 Android 上已经选了 ETC2到 iOS 构建时不要照搬同一套配置否则可能出现非标准纹理。构建完成后Creator 窗口会显示出输出目录。3.x 项目打开 build/ios/proj 下的 xcodeproj2.x 的构建目录一般是 build/ios 或 build/ios/proj按实际情况找。3.2 Xcode 工程打开后先改什么很多新手拿到 xcodeproj 后的第一反应是立刻点 Run结果报错说签名不对。先别急着改签名你需要先确认工程里的 Base Bundle Identifier 和刚才 Creator 里的包名一致。Creator 构建时通常会把包名写入但不排除 Cocos 的版本缓存导致少数项目出现旧值尤其是从老工程升级过来的出现一个后缀为 .ios 的奇怪包名并不罕见。按习惯我打开 Xcode 后先检查两处Target 里的 General 页签下的 Bundle IdentifierSigning Capabilities 里的 Team 是否为空。Cocos 生成的工程默认使用手动签名你要在 Signing 里把 Automatically manage signing 勾上然后在 Team 下拉栏选择你的开发者团队。如果没有设置签名后面真机跑不起来Archive 也会在导出阶段直接报 missing signing identity 之类。如果团队下拉列表是空的多半是 Xcode 里还没登录 Apple ID。打开 Xcode 的 Settings - Accounts添加你的开发者 Apple ID。这里只负责账号登录真正签名的证书会由 Xcode 在勾选自动签名后自动创建并下载到本机钥匙串。3.3 真机调试前先把签名和设备配对搞明白游戏在模拟器上能转是一回事iPhone 真机能不能稳定 60 帧是另一回事。尤其 Cocos 游戏涉及引擎渲染、内存纹理占用、iPhone 发热降频这些变量必须上真机验证。真机调试的第一步是让 Xcode 认识你的设备。用数据线连接 iPhone手机端会提示“是否信任此电脑”点击信任后再到手机的“设置 - 隐私与安全性 - 开发者模式”里打开开发者模式。这一步在新版 iOS 里是必须的很多人在 Xcode 里看到设备但点 Install 失败原因就是没开开发者模式。然后打开 Xcode 菜单 Window - Devices and Simulators左侧列表中能看到你的设备。如果设备旁边有黄色感叹号点击它系统会提示 Register Device。注册设备这一步会把你的 iPhone UDID 加入到开发者账号名下。在 Automatically manage signing 开启时Xcode 会自动在开发者后台创建包含你这个设备的 Development Provisioning Profile不需要手动去网页端操作。如果你硬要选择手动配置文件又没在后台把当前设备加进证书那大概率会出现“no devices registered”之类的提示。真机跑起来后首包会比较慢。Cocos 3.x 首次启动需要在 Xcode 里继承并编译一半引擎静态库长则十几分钟都是正常的。图标首次出现在手机桌面并显示“未受信任的开发者”时进设置去信任一下就好。这是个人开发者签名的老惯例不是你的包有问题。3.4 原生工程和第三方 SDK 的兼容性问题纯 Cocos 官方能力构建出来的 iOS 原生工程在 Xcode 中一般能直接编译通过。但只要是接入了统计、广告、登录、支付之类第三方原生 SDK 的游戏原生编译环节一定是最容易翻车的。常见问题之一是库或源码只支持真机架构不带模拟器 x86_64/arm64 slice。你在模拟器上 Build 时报错可能不是代码问题而是 SDK 本身限制了模拟器运行。解决方法是尽量用真机调试如果确实需要模拟器就去确认该 SDK 是否有模拟器版本。另一个常见问题是重复符号duplicate symbol。Cocos 工程里可能因为原生插件配置重复集成了两个相同底层库的不同编译产物。遇到这类问题别急着改 Build Settings先检查 Cocos 项目里的“原生插件配置”有没有重复引用。还有一类更容易被忽略Cocos 3.x 的原生工程使用了 CMake 来组织第三方原生代码如果你的 SDK 是通过 CocoaPods 引入的可能出现 Podfile 与工程签名 Target 冲突。此时在工程目录下执行 pod install然后重新打开 .xcworkspace 而不是 xcodeproj。很多人看到 Cocos 默认生成 xcodeproj 就一直打开它完全没意识到 Pods 项目没有被加载进来导致所有通过 Pod 集成的 SDK 方法都找不到。我在一个广告聚合项目中就碰到过这种问题Xcode 报Undefined symbols按网上教程一顿清理 DerivedData 也没用最后发现是项目自从某次 Creator 升级后构建脚本不再默认执行 pod install手动装一次 Pods 才恢复正常。4. Xcode 正式打包与 TestFlight4.1 Archive 前必须做的检查清单当你确认游戏在真机上已经能稳定运行、性能不掉帧、资源没有明显缺失以后就可以进入正式打包环节了。Xcode 顶部菜单里的设备要先选择“Any iOS Device (arm64)”或“Generic iOS Device”而不是一根真机。只有选择了通用设备菜单里的 Product - Archive 按钮才会亮起。Archive 就是归档它会生成一个带签名的 .xcarchive 文件里面是发布用的完整应用产物。点入 Archive 之前我建议你按下面的清单再检查一遍任何一项漏了都会延长 debug 时间Current Project Version 下 Build 号不小于上一次上传的构建号Target 的 Deployment Target 是否和你的最低支持版本一致很多第三方 SDK 对最低版本有要求是否开启了 bitcode。老版本 Xcode 里常见 bitcode 选项新版已废弃如果你因为老工程遇到 bitcode 编译错误直接关掉即可签名 Team 是否正确选择为 Distribution 对应的团队Info.plist 中的版本号和 App Store Connect 后台准备提交的版本号一致。Archive 的编译通常需要几分钟到十几分钟。编完后 Xcode 会自动弹出 Organizer 窗口左边列表里能看到刚生成的归档。此时先别急着上传可以顺手点窗口右侧的“Distribute App”或右键归档导出但在导出方式上要选 App Store Connect而不是 Development 或 Ad Hoc。看日志时如果出现 File was built for archive which is not the architecture being linked说明某静态库不支持当前架构通常是你工程里混入了只有模拟器架构的调试库重新拉取发布版 SDK 即可。4.2 上传到 App Store Connect后台也要先建好“空壳”Xcode 上传其实很简单但它有一个前置条件你必须在 App Store Connect 后台已经创建了一条 App 记录并且 Bundle ID 要跟工程里的完全一致。后台创建的入口是“我的 App”里左上角的加号选择“新建 App”取一个在 App Store 上展示用的名称、主语言再选包 ID。如果你在这个界面里搜索不到刚才那个 Bundle ID说明开发者账号里还没有注册相应的 App ID需要先去 Certificates, Identifiers Profiles 页面把 Identifiers 注册出来。常见错误发生在后台根本没建 App就急着用 Xcode 的 Distribute App上传到一半报 “No suitable application records were found.” 这时不是重新签名的问题而是后台没有对应记录可以接收这个上传包。App Store Connect 后台需要填的信息非常多但必须一次性填对的是“App 信息”页签的内容描述、分类、年龄分级、隐私政策 URL。描述建议精确说明“这是什么类型游戏、玩家要做什么、是否有内购”。分类一旦填错会影响推荐位早期不建议反复修改因为审核对话里可能会留下记录。提交到 Xcode 后上传的方式有两种一种是在 Organizer 里点 Distribute AppXcode 会直接把构建传到后台另一种是用 Xcode 自带的 Transporter 工具上传 .ipa。Transporter 更稳定适合网络不好的场景因为可以断点续传。第一次上传时如果你看到上传进度槽长时间停在 90% 之后报网络错误先看看系统代理是否有干扰或者换 Transporter 试试。4.3 TestFlight不等于审核通过但能暴露 80% 的坑上传成功后在 App Store Connect 后台“TestFlight”页签里你会看到这个构建开始“处理”。处理时间有时只需几分钟有时会长达半小时取决于服务器负载。构建状态变成“可供测试”后就可以添加内部测试员或外部测试员。内部测试员其实就是你开发者账号里的成员不需要经过审核添加后对方直接会在 TestFlight App 里看到这个版本。外部测试员需要邮箱邀请首次提交外部测试时苹果会做一次 Beta App Review不是完整审核但会检查明显违规点通常几小时到一天内会出结果。我的建议是把“内部测试”当成在真实 iOS 设备上进行全流程测试的最后机会至少安排 3~5 名不同机型的测试者。因为 Cocos Creator 在不同 iOS 版本上的 WebView、字体、本地存储行为都有差异只在自己的一台 iPhone 上测很难发现老 iPhone 内存不足、刘海屏安全区遮挡按钮这类问题。TestFlight 版和最终审核版在功能上几乎一样审核团队下载的也是类似版本。如果在 TestFlight 上出现“启动就崩溃”“资源加载不出来”千万不要期待正式审核能蒙混过关。苹果审核员拿到 App 后会先做基础启动测试启动崩溃是最常见也最严重的拒绝理由。5. 提审前与审核后的高频问题实录5.1 4.3 被拒App 撞脸了怎么办4.3 Spam 是中文开发者圈里的网红条款。苹果审核文案一般比较模式化“We noticed your app shares a similar binary, metadata and/or concept as apps submitted by another developer.”如果是一手打造的原创游戏但使用了大量第三方商店购买“模板”那被 4.3 命中非常正常。审核系统会把类似的二进制结构、界面布局和资源素材聚合到一个签名体系里。比如 A 开发者提交了 10 个长得一样、只换皮肤的球球游戏苹果机器审核直接会快速筛出相同点。如果你的游戏确实包含原创玩法和视觉但依然被判 4.3先别在论坛搜“如何过 4.3”这种旁门左道。最可靠的做法是回 Apple 的 App Review 信息里提交一条申诉说明解释玩法差异点并附上视频链接。注意这个视频不能是录屏然后拼接演示而应该在真机上从启动开始逐步展示核心玩法最好带上可交互过程。另外一个更容易做到的调整是审视你在 App Store Connect 填的分类、截图、文案是否和别的模板 App 太接近。如果你选择“娱乐”分类但截图第一张和竞品一样是礼包弹窗更容易被判定为相似引用。把截图改到玩法实际场景每张截图上标注一句功能说明这在机器审核眼里是很强的差异化信号。5.2 5.1.1 隐私问题为什么改了权限还不行隐私相关被拒的具体描述往往很长核心其实是几类缺少隐私政策 URL、权限用途文案不清、数据收集说明与代码行为不一致。第一次做中轻度休闲游戏时我的隐私政策是从某个开源源码仓库里复制的一份通用文本只改了 App 名称。上传后审核人员指出我没有说明第三方广告 SDK 会收集哪些数据。后来我只能回后台逐项核对项目里每个 SDK 的能力写明数据用途比如“AdMob用于广告投放可能收集设备信息”才算通过。如果你采用了“用户点击不同意隐私政策就退出 App”的做法请在提审备注里解释清楚。这在国内应用市场很常见在 iOS 上也是允许的但需要注意点是隐私弹窗文案必须明确说明收集数据的类型和用途不能只写“优化用户体验”这种模糊描述。关于 IDFA有 Cocos 开发者把 ATT 弹窗文字写得过于宽泛比如“用于广告个性化推荐”但你的游戏并没有投放个性化广告能力。审核人员会在隐私详情里核对写得太宽反而会带来麻烦。按真实用途写就好。5.3 需要登录的游戏没给测试账号会被打回如果你的游戏包含账号登录、排行榜、好友对战等需要联网服务的功能审核人员必须要一个有效测试账号才能完整体验游戏。很多开发者只把精力放在包体上忘了在提审备注里写账号密码结果审核员无法进入游戏直接以“无法完成审核”为由拒绝。提供测试账号时注意不要给真实充值过的账号也别给后台权限过高的管理员账号。审核员会使用测试账号体验核心玩法如果你给了管理员账号对方可能误触后台界面并认为 App 包含未注明的后台管理功能。使用“通过 Apple 登录”的合规性同样值得关注。如果游戏提供微信/QQ/Google 等第三方登录并且 iOS 审计师要求你必须同时提供“通过 Apple 登录”作为等价选项。Cocos 项目如果只做中国大陆发行且没有第三方登录就不受影响一旦接海外账号体系这一条尽量提前做免得提审后打回再补来回浪费好几天。5.4 由 WebView 引发的误判Cocos 游戏内部嵌入 WebView 很常见比如用来加载用户协议、活动页面或广告。但苹果对“单纯包了一个网页”的行为极度反感审核员看到 App 内显示大面积网页内容时会怀疑你是不是把网页套壳成 App 提交。为了减少这种误判你的核心玩法一定要在原生渲染的 Cocos 场景里体现不要让 WebView 成为游戏打开后的第一个界面。更不要做成“进入 App 默认先跳到一个 H5 活动页”的逻辑苹果审核员对这种模式相当敏感。我之前调整过策略启动后只短暂判断一个开关如果网络超时则直接进入离线主界面不让审核员长时间停留在 WebView。WebView 在 iOS 上的内存使用也要小心。Cocos 3.x 的 iOS WebView 渲染背后是 WKWebView加载复杂 H5 页面时内存占用增长明显。有些 iPhone 老机型会因此触发系统强杀。如果你发现 App 在真机上跑一会儿闪退但日志里又看不到明显异常建议先看是不是 WebView 页面频繁重定向导致的内存激增。5.5 高频审核与被拒问题的速查表网上案例五花八门但 Cocos 游戏被拒最集中的区域往往都围绕这么几个点。我把平时做技术支持和答疑时最高频的问题整理成一个速查表提审前后可以对照自查。现象常见原因解决建议启动后直接闪退资源加密或热更新路径问题、Info.plist 权限缺失用 TestFlight 复现看 crash log 是 ObjC/C 崩点还是 JS 层崩溃上传报 ITMS-90167Bundle ID 与后台不一致后台 Identifiers 和工程 Target 逐个比对上传后后台长时间没有 Build 显示构建号为 0 / 重复 / 上传不完整Build 号改为正整数重新 Archive或换 Transporter4.3 被拒模板资源、同质玩法和文案提供核心玩法视频申诉修改截图与文案强化原创证据5.1.1 被拒隐私政策 URL 不可访问 / 数据收集说明不一致补充合法可访问的隐私政策页后台 App 隐私栏如实填写1.2 被压到无法安装 / 审核无法打开 App证书异常导致“未受信任开发者”测试设备信任证书后再提审发行包用 Distribution 签名访问相册/摄像头时崩溃缺 NSPhotoLibraryUsageDescription 等键值在 Info.plist 中补权限描述这里没有写“百分之百能过审”的加速器因为审核本来就是个规则判断过程。你把属于自己产品的每一环都做干净审核失败的几率自然会降低。6. 上架之后还想说几句6.1 更新版本时要同步哪些信息第一次上架成功后很多人觉得流程结束了但游戏只要在运营版本更新是注定要面对的。iOS 的更新流程和首次上架稍有区别难点在于“同步信息”而不是“重新提交”。新版本在 Creator 里构建时如果你是同一套 Bundle ID签名逻辑不用重来。Version 号从 1.0.0 改成 1.1.0Build 号随便从 1 开始或延续之前的递增都可以但必须大于上一次构建号。App Store Connect 里新建一个版本后等上传构建处理完把它选择到对应版本上再走一次提交审核。另一个容易漏掉的是“隐私信息”栏目的变化。新版本如果新增了申请相机权限用于拍照、新增了统计 SDK、新增了账号删除功能记得回到 App Store Connect 的 App 隐私部分更新否则就可能因“App Privacy 标签与 App 实际行为不符”被打回。这块很多人理所当然觉得只有第一次填写时才做实际上每次变更都该检查。6.2 崩溃日志和原生问题的排查方法上下架之后游戏在用户 iPhone 上出现崩溃你是看不到代码异常堆栈的只有用户的描述和后台的崩溃日志。这时需要一位能看懂 Xcode Organizer 或者 App Store Connect “崩溃”栏的人去定位问题。Cocos 游戏的崩溃日志通常分成两种。如果你在 JS 层写代码比如空指针调用、TypeErrorXcode 日志里往往只有一行“JavascriptCore”异常入口看起来像原生崩溃但真正错误还得靠你在引擎里开启日志穿透或者用 Cocos 的报错信息捕获来定位。如果是原生层崩溃比如纹理内存爆了、音频底层出错日志会直接显示某个 .mm/.cpp 文件的行号。我有个印象很深的项目上线两周后用户反馈某张地图频繁闪退但本地和 TestFlight 测试都没有问题。后来通过崩溃日志发现崩溃集中在 iPhone 8 以下机型并且发生在纹理上传的 GPU 接口处。排查之后发现是场景里有一张不带 mipmap 的超大图在高分辨率设备上加载正常在老设备上纹理内存超限被系统强制杀掉。解决办法很简单把资源拆分为小图或启用 mipmap但如果没有崩溃日志和真机内存观测这类问题真的要靠猜。所以上架后不要只在后台看下载量和收入开发者的核心工作是把这套“版本发布 - 线上监控 - 崩溃定位 - 下版修复”的节奏跑顺。打包上架不是终点游戏能持续稳定地被玩家玩下去才是一款产品真正活着的开始。
Cocos Creator 打包 iOS 上架 App Store 全流程实操指南
做跨平台游戏这几年我最大的感受是在 Cocos Creator 里做游戏是一回事把它真正变成 iPhone 上能下载的 App 又是一回事。刚入行时我以为引擎里点一下 Build再用 Xcode 点一次 Run就能直接拿去上架 App Store结果光是理清开发者证书和发布签名的关系就折腾了半个月后面还被苹果审核连拒三次。跑完整个流程之后回头再看其实 Cocos Creator 打包 iOS 游戏并上架这件事并不复杂但链条特别长中间任何一环出错反馈都不直观。这篇东西不是官方文档的复述而是我自己在 Creator 2.x 老项目、Creator 3.x 新项目里反复跑过 iOS 包之后攒下来的实操记录。适合第一次接触 iOS 打包的 Cocos 开发者也适合已经上架过其他平台、但第一次被 iOS 工程和 Xcode 弄到头疼的人。我会按真实流程走一遍构建前的工程配置、Creator 导出原生工程、Xcode 签名与真机调试、Archive 打包上传、TestFlight 测试再到 App Store 审核时碰到的常见问题。每一步我都会把“为什么要这么做”讲清楚因为只告诉你点哪里下一次换个项目照样卡住。1. 先理清 Cocos 到 iOS 的完整链路1.1 为什么“点一下构建”不等于已经出包Cocos Creator 的构建按钮很容易让人产生误会。尤其你以前只做过 Android 包习惯了在编辑器里一键出 APK到 iOS 这里会发现Creator 构建完并没有直接生成一个可以上架的 .ipa而是生成了一个原生 Xcode 工程。这个工程才是真正能被苹果工具链识别的东西。后续的编译、签名、打包、上传全部要交给 Xcode 或命令行工具处理。也就是说上架 iOS 是一段“双构建”流程第一段是 Cocos Creator 把你的游戏资源和脚本按原生工程需要的格式整理出来第二段是 Xcode 读取这些内容链接 Cocos 引擎库和系统框架最终编译成 iOS App。所以你在 Creator 面板里看到的“构建完成”只代表第一段结束了。打开生成的目录你会看到一堆 .h、.mm、.swift 文件还有 ios 目录下的 xcodeproj 工程文件后面所有原生操作都围绕这些东西展开。连 Android 都不需要依赖 Android Studio 的人到 iOS 这一步也必须接受Xcode 不是可选项是必经环节。1.2 Creator 2.x 和 3.x 在 iOS 构建上的差异如果你的项目还是 Creator 2.4.x构建 iOS 插件会直接生成一个可用的 .xcodeproj位置通常在 build 目录下。这个工程相对简单双击就能打开。Creator 3.x 之后原生构建逻辑变化很大工程改走 CMake 组织流程很多原生存量代码都被收敛到引擎的 native 目录里。生成的工程路径一般是 build/ios/proj但可执行的名字会根据你填的包名变化别习惯性地只找固定名称。在 3.x 里要特别注意构建选项里有一项叫“生成 Xcode 工程”它和“生成资源”有时是分开的。资源生成慢工程生成快如果你只点了构建资源发现目录里没有 xcodeproj 别奇怪回到构建任务里把生成工程的任务补上就好。版本之间的另一个差异是原生插件的接入方式。2.x 时代很多国内 SDK 组件都有成熟的 OC 或者 JS 绑定方案3.x 初期因为原生目录结构大改不少第三方插件一度没跟上导致很多人卡在“引擎升级后原生不能编译”这一步。如果你要上架的是一款包含登录、支付、统计等原生能力的游戏建议先确认你依赖的 SDK 明确支持当前 Creator 版本而不是先写完游戏逻辑再去踩原生兼容性的坑。1.3 你需要准备哪些账号和工具打包 iOS 不能绕开的硬性条件是开发者账号。个人开发者账号或公司开发者账号都能上架 App Store区别主要在 Team 名称、团队成员管理和 App 的归属主体上。个人做小游戏个人账号完全够用。账号里几个角色要说清楚Account Holder 是账号所有者拥有最高权限Admin 能管理证书、设备和 AppApp Manager 能管理 App 的元数据和用户但证书方面权限有限Developer 只能真机调试。Cocos 属于引擎层不需要参与开发者账号管理但你有合作伙伴或外包团队协作时记得角色分配会影响谁能提交审核版本。除了开发者账号你还需要几样东西一台能装 Xcode 的 Mac、Xcode 本体、Cocos Dashboard 对应版本的 Creator、可用的 Apple ID。Xcode 版本最好和系统版本配套别拿最新系统配老版 Xcode打包时会遇到一堆签名工具链的兼容报错。提示首次准备环境时别把时间花在“装哪个模拟器”上。模拟器 Runtime 可以后续按需下载但 Xcode 必须装完。Cocos 游戏上架前必须用真机验证模拟器只适合快速看 UI 或粗略功能很多原生 API 行为和性能数据在模拟器上不准。2. 构建前要检查的基础配置2.1 包名、版本号、构建号一个都不能随意Cocos Creator 项目里有个地方叫“项目设置”其中“包名”这一项几乎决定了 iOS 上架的世界里 App 的身份证号。苹果生态里它叫 Bundle Identifier规则是反向域名格式比如 com.mycompany.matchgame只能包含字母、数字、点和连字符不能有下划线。包名是项目创建后最不该改的东西。一旦你用这个包名在某个渠道出过包、接过后台数据、注册过推送后面再改包名所有关联关系全部断裂甚至会出现“设备上覆盖安装不成功”“支付回调校验不过”这种历史遗留问题。所以项目初始化时一定先想清楚最终要上架的主体域名和产品名一次性填好。另一方面iOS 有 Version 和 Build 两个容易搞混的概念。Version 是对用户展示的版本号比如 1.0.0Build 是内部递增的构建号用户看不到但每次上传都必须大于上一次否则 App Store Connect 会提示“构建版本号非法”。我的习惯是版本号只在功能迭代时手动加Build 号则直接用一个脚本或者变量在构建时递增避免每次手动改还容易漏。很多人在 Creator 项目设置里只填一次版本号后续每次打包都用同一个值等到上传 App Store 就会卡在“Build 已存在”这个异常上。正确做法是上一版 Build 为 1下一个出包至少是 2哪怕 Version 还是 1.0.0 也可以等正式发新功能时再把 Version 改成 1.0.1Build 重新从 1 开始。2.2 图标和启动屏最容易拖慢进度的地方iOS App 图标有一套比较老的尺寸规范不同设备会用到从 20pt 到 1024pt 的多种规格。好在你把图标上传到 App Store Connect 后台时系统会根据你提供的 1024x1024 无透明通道大图自动生成各尺寸图标Xcode 工程里其实也会用 Asset Catalog 来自动处理不需要手做十几个 png。但 Cocos 游戏工程的图标和 Launch Screen启动屏仍需要在 Creator 里配置。Creator 的“项目设置”里如果提供了图标构建时引擎会把它写入原生资产目录。我第一次做的时候只改了桌面的 1024 大图忘了看“竖屏/横屏”的启动图方向结果安装到手机上启动瞬间有一块黑边或拉伸变形观感非常业余。Launch Screen 的推荐做法是固定颜色 居中的 Logo不要搞复杂的动画。苹果后台审核时如果启动屏图片显得过于简陋或者比例错乱不影响功能但确实会在“视觉设计”这一层被扣分。还有一点经常被忽略游戏如果支持横竖屏切换启动屏也要提供多方向的适配或者直接设定只支持某一种方向避免提交后用户在系统设置里强制旋转出现布局异常。2.3 iOS 权限声明写多了不行写少了会崩溃游戏经常是到真机测试阶段才暴露权限问题。比如你的游戏接了某个广告 SDKSDK 内部需要访问用户相册来保存一张分享图但你的 Info.plist 里没有写任何相册用途描述。真机上 SDK 一旦调用相册接口App 就会直接闪退控制台会输出类似“This app has crashed because it attempted to access privacy-sensitive data without a usage description”的日志。Cocos 引擎自带的编辑器不会主动帮你生成所有权限文案它默认只是在资源层做了一个最小配置。你需要根据游戏实际用到的能力在原生工程的 Info.plist 里加对应键值。常见的有相机权限 NSCameraUsageDescription、相册权限 NSPhotoLibraryUsageDescription、麦克风权限 NSMicrophoneUsageDescription、位置权限 NSLocationWhenInUseUsageDescription。反过来也不要盲目地把所有权限字符串都写进 plist。苹果审核时有静态扫描机制如果你的 App 其实没有调用相机功能Info.plist 却存在相机权限描述审核人员可能会追问理由。第一次过审时我因为批量拷贝别人的权限模板平白无故被要求解释为什么要用摄像头最后只能发个新版去掉多余描述才过审。2.4 隐私政策、ATT 弹窗这些不是小事如果只是开发一个单机休闲游戏你可能觉得隐私政策完全没必要。但 App Store 上架时几乎所有需要收集用户数据的 App 都必须提供隐私政策链接且链接必须在你提审前填到 App Store Connect 的对应字段里。即使你的游戏完全不上报数据苹果也默认你需要解释数据收集情况。对于 Cocos 游戏来说真正常见的坑是广告归因。接了 AdMob、Meta 广告或者一些国内聚合广告 SDK 后SDK 可能会读取 IDFA广告标识符此时必须遵守 App Tracking Transparency 规则。简单说你要在 Info.plist 里配置 NSUserTrackingUsageDescription并在 App 启动后弹 ATT 权限框用户同意后才能追踪。如果一个功能确实没有用到 IDFA我建议直接不要碰广告 SDK 的追踪开关并且提审时在后台的数据收集栏中如实选择。苹果的机器审核会探测代码里是否包含获取 IDFA 的逻辑如果探测到但后台隐私声明没写对应用途大概率会被打回重审。见过不少团队因为“明明没做追踪但 SDK 默认带了”而被拒排查起来极其被动。另一个经常被提审备注要求说明的是你的游戏是否需要用户登录是否支持删除账号。如果游戏有账号体系但 App 内找不到“删除账号”入口苹果会以 5.1.1(v) 的 App 账号删除条款拒绝。这一点对很多休闲游戏是没有影响的但如果你的游戏接入了第三方社交登录就一定要设计好账号注销逻辑。3. 从 Creator 导出原生工程操作与避坑3.1 构建面板的关键选项怎么选Cocos Creator 顶部菜单找到“项目”-“构建发布”弹出构建窗口后先点击“新建构建任务”。平台选择 iOS这里不要选成“iOS 模拟器”或“Mac”除非你想本地调试。在构建选项里包名先用刚才在项目设置里确认好的那个 Bundle Identifier其他几个常用项值得逐一说清。MD5 Cache 建议开启它会让资源文件名变成基于内容的哈希值好处是热更新时能有效避免老资源缓存残留。缺点是每次更改资源后构建出来的文件名不同如果你还接了自己写的资源服务器需要认真对待资源版本表否则新旧客户端会加载混乱。Polyfills 和脚本压缩默认开启就好。iOS 的 JavaScriptCore 对 ES6 的支持这些年越来越强但引擎内部的运行环境和浏览器不完全一致保留 polyfill 可以避免莫名其妙的 API 报错。纹理压缩格式保持默认或选择支持 iOS 的 PVRTC / ASTC。iOS 设备从 A13 以后对 ASTC 支持很好如果你的游戏用了大量高清图资源体积精简约 30% 是完全可能的。注意如果你在 Android 上已经选了 ETC2到 iOS 构建时不要照搬同一套配置否则可能出现非标准纹理。构建完成后Creator 窗口会显示出输出目录。3.x 项目打开 build/ios/proj 下的 xcodeproj2.x 的构建目录一般是 build/ios 或 build/ios/proj按实际情况找。3.2 Xcode 工程打开后先改什么很多新手拿到 xcodeproj 后的第一反应是立刻点 Run结果报错说签名不对。先别急着改签名你需要先确认工程里的 Base Bundle Identifier 和刚才 Creator 里的包名一致。Creator 构建时通常会把包名写入但不排除 Cocos 的版本缓存导致少数项目出现旧值尤其是从老工程升级过来的出现一个后缀为 .ios 的奇怪包名并不罕见。按习惯我打开 Xcode 后先检查两处Target 里的 General 页签下的 Bundle IdentifierSigning Capabilities 里的 Team 是否为空。Cocos 生成的工程默认使用手动签名你要在 Signing 里把 Automatically manage signing 勾上然后在 Team 下拉栏选择你的开发者团队。如果没有设置签名后面真机跑不起来Archive 也会在导出阶段直接报 missing signing identity 之类。如果团队下拉列表是空的多半是 Xcode 里还没登录 Apple ID。打开 Xcode 的 Settings - Accounts添加你的开发者 Apple ID。这里只负责账号登录真正签名的证书会由 Xcode 在勾选自动签名后自动创建并下载到本机钥匙串。3.3 真机调试前先把签名和设备配对搞明白游戏在模拟器上能转是一回事iPhone 真机能不能稳定 60 帧是另一回事。尤其 Cocos 游戏涉及引擎渲染、内存纹理占用、iPhone 发热降频这些变量必须上真机验证。真机调试的第一步是让 Xcode 认识你的设备。用数据线连接 iPhone手机端会提示“是否信任此电脑”点击信任后再到手机的“设置 - 隐私与安全性 - 开发者模式”里打开开发者模式。这一步在新版 iOS 里是必须的很多人在 Xcode 里看到设备但点 Install 失败原因就是没开开发者模式。然后打开 Xcode 菜单 Window - Devices and Simulators左侧列表中能看到你的设备。如果设备旁边有黄色感叹号点击它系统会提示 Register Device。注册设备这一步会把你的 iPhone UDID 加入到开发者账号名下。在 Automatically manage signing 开启时Xcode 会自动在开发者后台创建包含你这个设备的 Development Provisioning Profile不需要手动去网页端操作。如果你硬要选择手动配置文件又没在后台把当前设备加进证书那大概率会出现“no devices registered”之类的提示。真机跑起来后首包会比较慢。Cocos 3.x 首次启动需要在 Xcode 里继承并编译一半引擎静态库长则十几分钟都是正常的。图标首次出现在手机桌面并显示“未受信任的开发者”时进设置去信任一下就好。这是个人开发者签名的老惯例不是你的包有问题。3.4 原生工程和第三方 SDK 的兼容性问题纯 Cocos 官方能力构建出来的 iOS 原生工程在 Xcode 中一般能直接编译通过。但只要是接入了统计、广告、登录、支付之类第三方原生 SDK 的游戏原生编译环节一定是最容易翻车的。常见问题之一是库或源码只支持真机架构不带模拟器 x86_64/arm64 slice。你在模拟器上 Build 时报错可能不是代码问题而是 SDK 本身限制了模拟器运行。解决方法是尽量用真机调试如果确实需要模拟器就去确认该 SDK 是否有模拟器版本。另一个常见问题是重复符号duplicate symbol。Cocos 工程里可能因为原生插件配置重复集成了两个相同底层库的不同编译产物。遇到这类问题别急着改 Build Settings先检查 Cocos 项目里的“原生插件配置”有没有重复引用。还有一类更容易被忽略Cocos 3.x 的原生工程使用了 CMake 来组织第三方原生代码如果你的 SDK 是通过 CocoaPods 引入的可能出现 Podfile 与工程签名 Target 冲突。此时在工程目录下执行 pod install然后重新打开 .xcworkspace 而不是 xcodeproj。很多人看到 Cocos 默认生成 xcodeproj 就一直打开它完全没意识到 Pods 项目没有被加载进来导致所有通过 Pod 集成的 SDK 方法都找不到。我在一个广告聚合项目中就碰到过这种问题Xcode 报Undefined symbols按网上教程一顿清理 DerivedData 也没用最后发现是项目自从某次 Creator 升级后构建脚本不再默认执行 pod install手动装一次 Pods 才恢复正常。4. Xcode 正式打包与 TestFlight4.1 Archive 前必须做的检查清单当你确认游戏在真机上已经能稳定运行、性能不掉帧、资源没有明显缺失以后就可以进入正式打包环节了。Xcode 顶部菜单里的设备要先选择“Any iOS Device (arm64)”或“Generic iOS Device”而不是一根真机。只有选择了通用设备菜单里的 Product - Archive 按钮才会亮起。Archive 就是归档它会生成一个带签名的 .xcarchive 文件里面是发布用的完整应用产物。点入 Archive 之前我建议你按下面的清单再检查一遍任何一项漏了都会延长 debug 时间Current Project Version 下 Build 号不小于上一次上传的构建号Target 的 Deployment Target 是否和你的最低支持版本一致很多第三方 SDK 对最低版本有要求是否开启了 bitcode。老版本 Xcode 里常见 bitcode 选项新版已废弃如果你因为老工程遇到 bitcode 编译错误直接关掉即可签名 Team 是否正确选择为 Distribution 对应的团队Info.plist 中的版本号和 App Store Connect 后台准备提交的版本号一致。Archive 的编译通常需要几分钟到十几分钟。编完后 Xcode 会自动弹出 Organizer 窗口左边列表里能看到刚生成的归档。此时先别急着上传可以顺手点窗口右侧的“Distribute App”或右键归档导出但在导出方式上要选 App Store Connect而不是 Development 或 Ad Hoc。看日志时如果出现 File was built for archive which is not the architecture being linked说明某静态库不支持当前架构通常是你工程里混入了只有模拟器架构的调试库重新拉取发布版 SDK 即可。4.2 上传到 App Store Connect后台也要先建好“空壳”Xcode 上传其实很简单但它有一个前置条件你必须在 App Store Connect 后台已经创建了一条 App 记录并且 Bundle ID 要跟工程里的完全一致。后台创建的入口是“我的 App”里左上角的加号选择“新建 App”取一个在 App Store 上展示用的名称、主语言再选包 ID。如果你在这个界面里搜索不到刚才那个 Bundle ID说明开发者账号里还没有注册相应的 App ID需要先去 Certificates, Identifiers Profiles 页面把 Identifiers 注册出来。常见错误发生在后台根本没建 App就急着用 Xcode 的 Distribute App上传到一半报 “No suitable application records were found.” 这时不是重新签名的问题而是后台没有对应记录可以接收这个上传包。App Store Connect 后台需要填的信息非常多但必须一次性填对的是“App 信息”页签的内容描述、分类、年龄分级、隐私政策 URL。描述建议精确说明“这是什么类型游戏、玩家要做什么、是否有内购”。分类一旦填错会影响推荐位早期不建议反复修改因为审核对话里可能会留下记录。提交到 Xcode 后上传的方式有两种一种是在 Organizer 里点 Distribute AppXcode 会直接把构建传到后台另一种是用 Xcode 自带的 Transporter 工具上传 .ipa。Transporter 更稳定适合网络不好的场景因为可以断点续传。第一次上传时如果你看到上传进度槽长时间停在 90% 之后报网络错误先看看系统代理是否有干扰或者换 Transporter 试试。4.3 TestFlight不等于审核通过但能暴露 80% 的坑上传成功后在 App Store Connect 后台“TestFlight”页签里你会看到这个构建开始“处理”。处理时间有时只需几分钟有时会长达半小时取决于服务器负载。构建状态变成“可供测试”后就可以添加内部测试员或外部测试员。内部测试员其实就是你开发者账号里的成员不需要经过审核添加后对方直接会在 TestFlight App 里看到这个版本。外部测试员需要邮箱邀请首次提交外部测试时苹果会做一次 Beta App Review不是完整审核但会检查明显违规点通常几小时到一天内会出结果。我的建议是把“内部测试”当成在真实 iOS 设备上进行全流程测试的最后机会至少安排 3~5 名不同机型的测试者。因为 Cocos Creator 在不同 iOS 版本上的 WebView、字体、本地存储行为都有差异只在自己的一台 iPhone 上测很难发现老 iPhone 内存不足、刘海屏安全区遮挡按钮这类问题。TestFlight 版和最终审核版在功能上几乎一样审核团队下载的也是类似版本。如果在 TestFlight 上出现“启动就崩溃”“资源加载不出来”千万不要期待正式审核能蒙混过关。苹果审核员拿到 App 后会先做基础启动测试启动崩溃是最常见也最严重的拒绝理由。5. 提审前与审核后的高频问题实录5.1 4.3 被拒App 撞脸了怎么办4.3 Spam 是中文开发者圈里的网红条款。苹果审核文案一般比较模式化“We noticed your app shares a similar binary, metadata and/or concept as apps submitted by another developer.”如果是一手打造的原创游戏但使用了大量第三方商店购买“模板”那被 4.3 命中非常正常。审核系统会把类似的二进制结构、界面布局和资源素材聚合到一个签名体系里。比如 A 开发者提交了 10 个长得一样、只换皮肤的球球游戏苹果机器审核直接会快速筛出相同点。如果你的游戏确实包含原创玩法和视觉但依然被判 4.3先别在论坛搜“如何过 4.3”这种旁门左道。最可靠的做法是回 Apple 的 App Review 信息里提交一条申诉说明解释玩法差异点并附上视频链接。注意这个视频不能是录屏然后拼接演示而应该在真机上从启动开始逐步展示核心玩法最好带上可交互过程。另外一个更容易做到的调整是审视你在 App Store Connect 填的分类、截图、文案是否和别的模板 App 太接近。如果你选择“娱乐”分类但截图第一张和竞品一样是礼包弹窗更容易被判定为相似引用。把截图改到玩法实际场景每张截图上标注一句功能说明这在机器审核眼里是很强的差异化信号。5.2 5.1.1 隐私问题为什么改了权限还不行隐私相关被拒的具体描述往往很长核心其实是几类缺少隐私政策 URL、权限用途文案不清、数据收集说明与代码行为不一致。第一次做中轻度休闲游戏时我的隐私政策是从某个开源源码仓库里复制的一份通用文本只改了 App 名称。上传后审核人员指出我没有说明第三方广告 SDK 会收集哪些数据。后来我只能回后台逐项核对项目里每个 SDK 的能力写明数据用途比如“AdMob用于广告投放可能收集设备信息”才算通过。如果你采用了“用户点击不同意隐私政策就退出 App”的做法请在提审备注里解释清楚。这在国内应用市场很常见在 iOS 上也是允许的但需要注意点是隐私弹窗文案必须明确说明收集数据的类型和用途不能只写“优化用户体验”这种模糊描述。关于 IDFA有 Cocos 开发者把 ATT 弹窗文字写得过于宽泛比如“用于广告个性化推荐”但你的游戏并没有投放个性化广告能力。审核人员会在隐私详情里核对写得太宽反而会带来麻烦。按真实用途写就好。5.3 需要登录的游戏没给测试账号会被打回如果你的游戏包含账号登录、排行榜、好友对战等需要联网服务的功能审核人员必须要一个有效测试账号才能完整体验游戏。很多开发者只把精力放在包体上忘了在提审备注里写账号密码结果审核员无法进入游戏直接以“无法完成审核”为由拒绝。提供测试账号时注意不要给真实充值过的账号也别给后台权限过高的管理员账号。审核员会使用测试账号体验核心玩法如果你给了管理员账号对方可能误触后台界面并认为 App 包含未注明的后台管理功能。使用“通过 Apple 登录”的合规性同样值得关注。如果游戏提供微信/QQ/Google 等第三方登录并且 iOS 审计师要求你必须同时提供“通过 Apple 登录”作为等价选项。Cocos 项目如果只做中国大陆发行且没有第三方登录就不受影响一旦接海外账号体系这一条尽量提前做免得提审后打回再补来回浪费好几天。5.4 由 WebView 引发的误判Cocos 游戏内部嵌入 WebView 很常见比如用来加载用户协议、活动页面或广告。但苹果对“单纯包了一个网页”的行为极度反感审核员看到 App 内显示大面积网页内容时会怀疑你是不是把网页套壳成 App 提交。为了减少这种误判你的核心玩法一定要在原生渲染的 Cocos 场景里体现不要让 WebView 成为游戏打开后的第一个界面。更不要做成“进入 App 默认先跳到一个 H5 活动页”的逻辑苹果审核员对这种模式相当敏感。我之前调整过策略启动后只短暂判断一个开关如果网络超时则直接进入离线主界面不让审核员长时间停留在 WebView。WebView 在 iOS 上的内存使用也要小心。Cocos 3.x 的 iOS WebView 渲染背后是 WKWebView加载复杂 H5 页面时内存占用增长明显。有些 iPhone 老机型会因此触发系统强杀。如果你发现 App 在真机上跑一会儿闪退但日志里又看不到明显异常建议先看是不是 WebView 页面频繁重定向导致的内存激增。5.5 高频审核与被拒问题的速查表网上案例五花八门但 Cocos 游戏被拒最集中的区域往往都围绕这么几个点。我把平时做技术支持和答疑时最高频的问题整理成一个速查表提审前后可以对照自查。现象常见原因解决建议启动后直接闪退资源加密或热更新路径问题、Info.plist 权限缺失用 TestFlight 复现看 crash log 是 ObjC/C 崩点还是 JS 层崩溃上传报 ITMS-90167Bundle ID 与后台不一致后台 Identifiers 和工程 Target 逐个比对上传后后台长时间没有 Build 显示构建号为 0 / 重复 / 上传不完整Build 号改为正整数重新 Archive或换 Transporter4.3 被拒模板资源、同质玩法和文案提供核心玩法视频申诉修改截图与文案强化原创证据5.1.1 被拒隐私政策 URL 不可访问 / 数据收集说明不一致补充合法可访问的隐私政策页后台 App 隐私栏如实填写1.2 被压到无法安装 / 审核无法打开 App证书异常导致“未受信任开发者”测试设备信任证书后再提审发行包用 Distribution 签名访问相册/摄像头时崩溃缺 NSPhotoLibraryUsageDescription 等键值在 Info.plist 中补权限描述这里没有写“百分之百能过审”的加速器因为审核本来就是个规则判断过程。你把属于自己产品的每一环都做干净审核失败的几率自然会降低。6. 上架之后还想说几句6.1 更新版本时要同步哪些信息第一次上架成功后很多人觉得流程结束了但游戏只要在运营版本更新是注定要面对的。iOS 的更新流程和首次上架稍有区别难点在于“同步信息”而不是“重新提交”。新版本在 Creator 里构建时如果你是同一套 Bundle ID签名逻辑不用重来。Version 号从 1.0.0 改成 1.1.0Build 号随便从 1 开始或延续之前的递增都可以但必须大于上一次构建号。App Store Connect 里新建一个版本后等上传构建处理完把它选择到对应版本上再走一次提交审核。另一个容易漏掉的是“隐私信息”栏目的变化。新版本如果新增了申请相机权限用于拍照、新增了统计 SDK、新增了账号删除功能记得回到 App Store Connect 的 App 隐私部分更新否则就可能因“App Privacy 标签与 App 实际行为不符”被打回。这块很多人理所当然觉得只有第一次填写时才做实际上每次变更都该检查。6.2 崩溃日志和原生问题的排查方法上下架之后游戏在用户 iPhone 上出现崩溃你是看不到代码异常堆栈的只有用户的描述和后台的崩溃日志。这时需要一位能看懂 Xcode Organizer 或者 App Store Connect “崩溃”栏的人去定位问题。Cocos 游戏的崩溃日志通常分成两种。如果你在 JS 层写代码比如空指针调用、TypeErrorXcode 日志里往往只有一行“JavascriptCore”异常入口看起来像原生崩溃但真正错误还得靠你在引擎里开启日志穿透或者用 Cocos 的报错信息捕获来定位。如果是原生层崩溃比如纹理内存爆了、音频底层出错日志会直接显示某个 .mm/.cpp 文件的行号。我有个印象很深的项目上线两周后用户反馈某张地图频繁闪退但本地和 TestFlight 测试都没有问题。后来通过崩溃日志发现崩溃集中在 iPhone 8 以下机型并且发生在纹理上传的 GPU 接口处。排查之后发现是场景里有一张不带 mipmap 的超大图在高分辨率设备上加载正常在老设备上纹理内存超限被系统强制杀掉。解决办法很简单把资源拆分为小图或启用 mipmap但如果没有崩溃日志和真机内存观测这类问题真的要靠猜。所以上架后不要只在后台看下载量和收入开发者的核心工作是把这套“版本发布 - 线上监控 - 崩溃定位 - 下版修复”的节奏跑顺。打包上架不是终点游戏能持续稳定地被玩家玩下去才是一款产品真正活着的开始。