Sumi Mahjong 禅艺麻将 · 12 · 上架审核：把离线、无广告和买断说清楚

Sumi Mahjong 的上架准备不是最后写几句描述，而是把前面的产品哲学、技术架构和商业模式翻译成商店页、隐私政策、IAP 说明和截图标题。

如果产品承诺是离线、无广告、一次买断，那么审核材料也必须保持一致：不要在截图里夸张玩法，不要把主题解锁写成会员，不要让用户误以为这是四人麻将，也不要把隐私说明写得含糊。

本轮资料里没有找到 Sumi 的正式 App Review 拒审信；真实发生的是提审前 ASC 阻塞：build 1 声明支持 iPad，版本页就要求 13-inch iPad 截图。处理方式是改成 iPhone-only build 2，重新上传并替换版本页构建。

这篇日志关注的是落地阶段：如何让 App Store Connect 里的字段、截图、IAP 展示、本地化文案、Review Notes 和构建设备族都围绕同一个真实体验。

开发细节补充：这篇记录放在 Sumi Mahjong 禅艺麻将 的产品日记里，不是为了把一个功能包装成故事，而是把“12 · 上架审核：把离线、无广告和买断说清楚”放回真实项目推进中看。它要同时回答三件事：用户为什么需要这个点，开发时哪些边界必须先定住，以及这个选择会怎样影响上架、推广和后续课程复盘。平台口径是 iPhone / iOS / 游戏，当前公开状态是 App Store / 无广告 / 无追踪，所以文案不能脱离真实发布进度。

对应的 docs 线索主要来自 ZenMahjong 产品策略、玩法算法与判定、牌面资产和动效记录、完成审计与本地化上架文档。公开页面不会照搬内部工作记录，而是把可公开、可学习、不会泄露私密路径和账号信息的事实整理出来。ZenMahjong docs 覆盖开发哲学、痛点功能清单、命名品牌、UI 结构、主题美术、定价 IAP 和本地化上架。 开发计划记录了玩法算法、两折线判定、周 1 开发日志、动效粒子、开源布局参考、随机布局策略和牌面生成流程。 完成审计把玩法、隐私、无广告、StoreKit、素材和上架说明合在一起，让游戏不是只停留在可玩 Demo。 公开文章要说明为什么小游戏也需要不做清单：无广告、无账号、无体力、无排行榜，都是架构和商业化选择。

从产品功能看，Sumi Mahjong 禅艺麻将 关联的能力包括：144 张手调水墨麻将牌、经典两折线连接规则、撤销、提示、洗牌、无广告 SDK、无账号、无第三方追踪。写这类日记时，不能只说“做了什么”，还要说明为什么先做这些、为什么暂时不做另一些。比如一个按钮、一个导入流程、一个本地模型开关或一段截图文案，放在代码里只是小改动，放在产品里却会影响用户理解、审核员复现和后续推广素材。

从工程推进看，这篇日记对应的检查点是：轻量游戏的上架、IAP 和隐私边界；产品页如何表达安静体验。真实开发最容易失真的是中间过程，因为最后页面看起来只有一个结果，但实际会经历方案取舍、权限确认、素材准备、测试设备、审核备注和发布节奏。把这些过程写下来，后面做同类产品时才不会重新踩同一个坑。

从隐私和合规看，当前约束是：正常游玩不需要网络；付费解锁通过 Apple StoreKit 完成。这类信息必须前置到开发日记里，因为独立产品的可信度不是靠口号建立的，而是靠数据在哪里处理、用户能不能退出、功能是否离线可用、商店页怎么承诺、隐私政策是否与实现一致这些小事实积累出来的。

从课程和复用看，这篇内容可以沉淀到 iOS 小游戏、StoreKit 2、无广告产品、多语言上架。它的价值不只是给访问者看一个产品，而是展示一个独立开发者怎样把想法转成可验证的产品：先收窄场景，再选技术路径，再做体验最小闭环，最后把审核、推广、运营数据和失败教训都纳入下一次迭代。

轻量游戏也可以成为完整产品案例：规则、手感、美术、IAP、审核和推广都能拆开复用。 这也是为什么每篇产品日记都要写到足够长：不是为了凑字数，而是为了把“证据、决策、实现、边界、复盘”都放在同一页，让读者看到一个判断是怎样被逐步验证出来的。最难的是让麻将消除既安静又耐玩，同时避免广告化和过度游戏化破坏产品气质。

所以这篇日记的结论不是“功能已经写完”，而是把一个阶段的判断公开化：哪些证据足够支撑继续推进，哪些资料还需要回到源码、商店材料、公开文案或运营观察里补齐。这样的记录会比单纯的发布公告更慢，但也更真实，能让产品页、发布记录和课程内容保持同一条事实线。

验收时我会把它拆成四个层次：第一层是用户路径能不能走通，第二层是异常状态有没有被诚实处理，第三层是页面上的按钮、状态、截图和文案是否对应真实发布渠道，第四层是公开证据能否支撑这个判断。只要其中一层对不上，产品看起来再完整，也不能算真正进入下一个阶段。

交接时也要保留边界：源码、构建、测试、商店元数据、公开文案、平台反馈和运营观察分别保存原始资料。产品日记只把这些事实翻译成读者能理解的过程，不替任何私有记录保存原始材料。

把这些内容公开出来，还有一个很现实的原因：AI 教程如果只展示成功结果，很容易让人误以为产品是一次生成出来的。真实情况恰好相反，真正可学习的是一次次收窄、验证、失败、补证据和重新提交。日记越具体，后续读者越能看到判断的脉络，而不是只看到一个漂亮的截图。

第一步：把产品边界写成审核语言

审核员真正关心的是用户会不会被误导、数据会不会被收集、付费项是否清楚、App 是否有足够价值。Sumi Mahjong 的回答必须非常直接：完整玩法免费，付费只解锁视觉主题，没有广告，没有账号，没有服务器服务。

这类说明最好从产品结构里长出来，而不是临时编。因为 App 如果真的没有广告 SDK、没有账号系统、没有外部服务，那么隐私页、审核备注和用户支持都会很容易统一。

第二步：避免名字和截图误导

麻将这个词容易让人误以为是四人麻将，所以副标题和描述要讲清楚这是 tile match / solitaire 类型的消除游戏。截图也要真实展示局面，不用夸张广告图暗示不存在的玩法。

本地化时也要保持这个边界。繁中、简中、英文、日文、韩文可以用不同语感表达，但核心信息不能漂移：无广告、离线、一次买断、安静游玩、主题美术。

第三步：IAP 文案要降低误解

一次买断主题解锁不能写得像订阅会员，也不能让用户以为基础玩法被锁住。购买卡片和商店说明都要明确：免费主题可完整游玩，付费解锁当前和后续的高级主题。

恢复购买、稍后再说、价格展示也要在同一界面里清楚出现。越是小产品，越不能靠模糊文案做转化，因为一旦用户误解，差评和审核风险都会回来。

第四步：提审前先对齐设备族和截图槽位

2026-05-19，Sumi Mahjong 的 build 1 已经上传并关联到 1.0 版本页，ASC 读回状态为 VALID，但 Add for Review 前提示必须补 13-inch iPad 截图。根因不是截图少，而是 build 1 的 UIDeviceFamily 声明为 iPhone + iPad。

这次修复没有硬凑 iPad 图。因为首发真实产品并不支持 iPad，所以工程改为 iPhone-only，构建号递增到 build 2，重新归档上传，ASC 读回 VALID 后替换到 1.0 版本页。这个动作比临时生成不真实的 iPad 截图更诚实。

第五步：把审核资料变成课程材料

这类上架过程很适合转成课程：从产品定位开始，到隐私政策、支持页、截图标题、IAP 说明、Review Notes，每一步都能展示一个独立开发者如何把 App 从代码带到商店。

对个人站来说，这些内容还能反向沉淀成产品页和开发日记。用户看到的是产品可信度，学习者看到的是完整落地流程，开发者自己也能复用下一款 App 的审核框架：Content Rights、China mainland / Vietnam、截图尺寸、IAP 和 Review Notes 都要读回。