Mood Button 的第一次审核不是顺利通过。2026-06-17，Apple 在 App Store Connect 里拒回了 iOS 1.0，审核设备是 iPad Air 11-inch (M3)，问题集中在三个方向：Guideline 4.0、Guidelines 5.1.1(i) / 5.1.2(i)、Guideline 2.1(b)。

这封拒审信很适合变成课程案例，因为它不是“苹果刁难”，而是把 AI 产品最容易含糊的地方全部点出来了：界面在 iPad 上是否真的可用，用户数据有没有给第三方 AI，内购入口审核员能不能按步骤找到。

开发细节补充：这篇记录放在 Mood Button 的产品日记里，不是为了把一个功能包装成故事，而是把“06 · 审核复盘：真实拒审、回应和重新提交”放回真实项目推进中看。它要同时回答三件事：用户为什么需要这个点，开发时哪些边界必须先定住，以及这个选择会怎样影响上架、推广和后续课程复盘。平台口径是 iPhone / MLX / Qwen3，当前公开状态是 App Review / 被拒后重提 / 本地 AI，所以文案不能脱离真实发布进度。

对应的 docs 线索主要来自 Mood Button 开发计划、模型验证记录、上架收尾盘点、App Review 修复记录。公开页面不会照搬内部工作记录，而是把可公开、可学习、不会泄露私密路径和账号信息的事实整理出来。Mood Button 的 docs 覆盖语音到多语日记、AI 线索生成、本地 AI 显性验证、MLX 真实模型测试和 iPad 原生适配。 上架记录包含上传前状态复核、TestFlight 收费墙、产品名称和 GitHub 重命名、App Review 拒回后的修复路径。 模型验证文档说明本地 AI 不是口号，需要验证模型边界、调度方式、设备能力和用户可见说明。 公开文章要谨慎处理情绪、语音和隐私，不渲染心理疗效，而是讲清低门槛记录、本地处理和审核沟通。

从产品功能看，Mood Button 关联的能力包括：语音情绪记录、Apple MLX 本地推理、Qwen3 轻量交互、低干扰日记体验。写这类日记时，不能只说“做了什么”，还要说明为什么先做这些、为什么暂时不做另一些。比如一个按钮、一个导入流程、一个本地模型开关或一段截图文案，放在代码里只是小改动，放在产品里却会影响用户理解、审核员复现和后续推广素材。

从工程推进看，这篇日记对应的检查点是：本地语音 AI 和情绪产品边界；2026-06-17 被 App Review 拒回，后续修复、审核回复和重提材料已进入发布记录。真实开发最容易失真的是中间过程，因为最后页面看起来只有一个结果，但实际会经历方案取舍、权限确认、素材准备、测试设备、审核备注和发布节奏。把这些过程写下来，后面做同类产品时才不会重新踩同一个坑。

从隐私和合规看，当前约束是：设计方向以本地语音和本地模型为核心，正式上架前需要逐项核对隐私标签。这类信息必须前置到开发日记里，因为独立产品的可信度不是靠口号建立的，而是靠数据在哪里处理、用户能不能退出、功能是否离线可用、商店页怎么承诺、隐私政策是否与实现一致这些小事实积累出来的。

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

敏感 AI 产品先讲数据流、边界和审核证据，再讲智能体验。 这也是为什么每篇产品日记都要写到足够长：不是为了凑字数，而是为了把“证据、决策、实现、边界、复盘”都放在同一页，让读者看到一个判断是怎样被逐步验证出来的。最难的是在私密情绪场景里同时满足本地 AI 可用性、隐私说明和 App Review 可验证性。

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

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

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

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

4.0：iPad 上菜单栏不可见

Apple 指出 iPad Air 11-inch (M3) 上有界面显示问题，尤其是菜单栏不可见。这个问题说明，哪怕产品主场景是 iPhone，只要包体允许下载到 iPad，就必须按 iPad 真实尺寸、方向和安全区域检查。

修复思路不是在回复里解释“我们主要面向 iPhone”，而是补 iPad 可见性证据：让首页菜单、底部 Tab、设置入口在 iPad 兼容窗口里保持可见，并保存验证截图。

5.1：把本地 AI 数据流说清楚

Apple 的判断是：App 看起来可能把用户个人数据发送给第三方 AI，但没有清楚说明发送什么、发给谁、是否先取得许可。对情绪日记来说，这个问题很敏感，因为录音、转写、日记文本、情绪标签都属于高度私密内容。

实际回应必须落到数据流：Qwen3 MLX 模型随 App 打包，在支持的实体 iPhone 上本地运行；App 不调用 OpenAI、Anthropic、Gemini、ChatGPT 或其他托管第三方 AI API。Apple Speech 和可选天气也要分别解释清楚，不能一句“本地 AI”带过。

2.1(b)：内购路径必须让审核员找到

Apple 说无法定位 `Unlock Home Skins` 内购。这个问题不一定是 StoreKit 坏了，也可能只是审核员在当前 UI 状态下找不到入口。

回应要给可复现步骤：打开 App，点右上角设置，进入 Skin Type，选择 Puppy Star、Kitten Cloud 或 Bear Bunny 这类锁定皮肤，出现 Unlock All Skins 购买页，并能看到价格、Not Now 和 Restore Purchases。

拒审记录要进入发布复盘

这次复盘最重要的不是把一封信处理完，而是把 Apple 的原始问题、修复映射、验证截图、回复草稿、重提状态都整理成发布复盘。下一个 AI、语音、情绪或 IAP 产品遇到类似问题时，可以直接复用这套检查表。

官网上不应该把这种状态藏起来。未上架就显示“App Store 即将上架”，开发日记则公开写清楚被拒原因和处理经验。真实进度本身就是产品信任的一部分。