定制开发的App提审App Store被拒，先改代码还是先改提审资料？

结论先说：定制开发的App提审App Store被拒，多数不是代码跑不通，而是提审资料与审核规则没对齐。2026年交付中高频卡点集中在五类：账号注销入口、登录方式、虚拟商品支付路径、权限与隐私文案、元数据与截图。先按规则自查再决定动不动代码，通常比反复提交省时间；重新提交到出结果的常见区间为1到3天，遇上补充说明会更久。

为什么被拒经常不是技术问题

团队第一次被拒，本能是回去查崩溃日志。但审核反馈里出现更多的词，往往是account deletion、privacy、metadata这类规则项。审核分机器预检和人工复核：机器预检扫权限声明、隐私清单与二进制里的SDK；人工复核看账号体系、支付路径和描述文案是否自洽。两层的关注点都不在业务逻辑对不对，而在用户能不能自己退出、自己删号、扣费是否讲清楚。

技术功能正常只是过审的必要条件，不是充分条件。把审核当成一份有明确条目的验收清单，比当成一次代码考试更贴近实际。需要依据时，直接对照App Store审核指南的当前条目和App Store Connect的提审提示逐条核对，比凭印象改更省时间。

交付现场见过一种常见情况：客户定的发布节点只剩两周，隐私政策还没定稿，截图用的还是设计稿。做法是先把账号注销入口和权限用途文案补齐，再统一出截图；代价是设计端要多改一轮，但比提交后被拒、整段延期要轻。这类资料类返工的常见区间在1到3个工作日，而支付路径改动往往要按周算。

提交前先核对的五类提审资料

这五类互相关联：登录方式影响账号注销怎么做，支付规则影响描述怎么写，权限又同时出现在隐私文案和截图里。按下面顺序自查，能减少来回返工。

1. 账号体系：能注册就要能注销，注销入口要能在App内找到，不能只留客服邮箱。补做这块的常见区间是3到10个工作日。
2. 登录方式：如果提供第三方登录，要按当前指南评估是否需要等效的其它注册或登录路径，不要照抄旧项目。
3. 支付路径：先判断卖的是虚拟内容还是实物或线下服务，两者规则不同，走错一边是较容易被拒的原因之一。
4. 隐私与权限：每条权限的用途说明要写清具体用途，不能写为了更好体验这类空话，隐私政策链接要能打开。
5. 元数据与截图：截图里不要出现未完成的占位文字、测试账号提示或其它平台的水印。

自查做到什么算合格：找一个没参与开发的人，拿真机从注册走到注销，中途不问你，能走完就算过；走不完的地方，通常就是审核会卡的地方。

账号注销和登录方式，为什么总在这两处翻车

账号注销被拒的根因，往往不是没做功能，而是做在审核员找不到的位置。常见情况是注销入口藏在设置-关于-更多第三层，或者需要先联系客服再人工处理。审核复核时不会替你找，找不到就按缺失处理。

登录方式这块容易受旧经验影响。2026年常见做法是，如果App支持第三方账号登录，同时评估是否要提供等效的注册或登录路径，而不是只留一个第三方入口。具体条款会更新，交付时要先核对当前审核指南，不要直接沿用两年前的方案。

• 合格线：注册、登录、注销三步在App内闭环，不依赖外部客服。
• 反例：注销按钮只写申请注销，点了跳到一个表单，填完等邮件。
• 代价：这类问题返工不大，但每轮审核沟通常见要1到3天，赶上发布节点容易整段延期。

虚拟商品和实物服务，支付边界怎么分

支付是审核争议集中的地方，核心区别是用户花钱买到的是App内的数字内容，还是App外的实物或线下服务。前者通常要走应用内购买，后者一般可以走第三方支付。判断错方向，改起来涉及订单链路和退款逻辑，不是改个按钮的事。

• 方案A：应用内购买适合会员、解锁功能、虚拟道具、去广告等数字内容；平台会按规则参与分成，接入与对账周期通常要预留1到3周。
• 方案B：第三方支付适合实物商品、到店服务、线下履约类订单；需要提前准备商户资质，审核时要能说清履约发生在App外。
• 混合场景：一个App里同时卖虚拟和实物，要分入口、分说明，别让审核员在一页里分不清买了什么。

如果不确定算哪一类，按2026年常见做法，先看审核指南里关于数字内容与实物商品的定义条目，再决定技术方案，比先开发后补救更省成本。

还有哪些不显眼的坑

有些细节开发自己觉得没关系，审核规则上却有明确要求，提审前值得顺手过一遍。

• 把测试环境写进截图：截图里出现测试、demo、请联系管理员，容易被当成未完成品。
• 隐私政策是模板没改：公司名、收集字段、SDK清单对不上，容易被要求补充说明。
• 权限申请文案太笼统：相机、定位、通讯录的用途说明要和实际功能一致。
• 描述里写绝对化用语：提审描述和截图文案都可能因夸大表述被卡。

自查是否合格，可以用一个简单标准：让不熟悉项目的人，只看App内文案和截图，能不能说清这个App收集什么、怎么退、怎么删、怎么付费。说不清，就还有被拒的风险。

适用场景与边界

这套自查法适用于准备提交App Store的定制开发项目，尤其是账号体系、支付、隐私权限都自己实现的项目，以及第一次上架的团队。它解决的是提交前该核对什么，不解决功能是否符合业务预期。

不适合直接照搬的情况也要说清：只在企业内部用MDM或企业签名分发的App，不走App Store公开审核，规则不同；只上安卓第三方市场的App，各市场要求也不完全一致；纯H5或小程序不涉及这套流程。边界句：如果App不面向公开用户下载，或不做任何账号与支付，那么本文的多数检查项可以先跳过，把精力放在对应渠道的规范上。

常见问题

被拒后重新提交，一般要等多久？

按经验区间，重新提交到出结果常见为1到3天，遇到节假日或需要补充说明会更久，所以能一次自查完就别拆成多轮试。

注销功能做成客服代删，能过吗？

通常不够。审核更认可App内可自助完成的注销路径，客服代删在部分情况下会被要求补充自助入口。

虚拟商品用第三方支付，一定会被拒吗？

多数情况下会被要求改走应用内购买，除非能清晰证明购买的是App外履约的实物或线下服务，判断依据以当前审核指南为准。

安卓上架和iOS审核的坑一样吗？

不完全一样。账号注销、隐私权限是共同项，但支付规则、元数据和渠道素材要求各家不同，建议按渠道分别出清单。

找外包提交，自己还要管审核吗？

建议自己保留提审账号和最终确认权。按交付习惯，提审材料由乙方整理、甲方确认，能减少因描述不合规导致的反复沟通。

准备提审时，先把账号注销、登录方式、支付类型、权限文案、截图元数据五项过一遍，再对照当前审核指南补漏。若项目卡在自有团队没有上架经验，可让犀跃公司在交付阶段同步整理提审清单。若App不面向公开商店分发，先按对应渠道规范核对即可。