TrekReel 的一次拒审不是代码问题，而是 App Store Connect 字段理解问题。2026-04-01，Apple 按 Guideline 2.3.2 打回 1.0.4，原因是 IAP Promotional Image 使用了 App 内截图。
Apple 原文要点是：Your promotional image is a screenshot taken from the app。中文翻译就是：你的促销图是一张从 App 内截取的截图。
根因很朴素：我们把 App 内付费墙截图误上传到可选 Promotional Image，而不是只放在 Review Information 里。最后选择不公开推广这个 IAP，从 ASC 清除 Promotional Image，回复说明后继续审核。
开发细节补充：这篇记录放在 TrekReel 的产品日记里，不是为了把一个功能包装成故事，而是把“07 · 审核复盘：IAP 促销图不能误传付费墙截图”放回真实项目推进中看。它要同时回答三件事：用户为什么需要这个点，开发时哪些边界必须先定住，以及这个选择会怎样影响上架、推广和后续课程复盘。平台口径是 macOS / 3D / 地图，当前公开状态是 App Store / 创作者工具 / 本地优先，所以文案不能脱离真实发布进度。
对应的 docs 线索主要来自 三维地图故事版架构、MAS / Windows 打包记录、删除数据源说明、多语言 GitHub Pages 文档。公开页面不会照搬内部工作记录，而是把可公开、可学习、不会泄露私密路径和账号信息的事实整理出来。TrekReel 的 docs 覆盖架构、MAS 构建、Windows 打包、数据源删减和多语言 README，说明它从一开始就面向跨平台发布。 轨迹故事的难点不是读取 GPX/KML 文件，而是把轨迹、海拔、时间线、相机路径和导出素材组织成可分享叙事。 发布记录说明桌面创作者工具要同时处理安装信任、包体、平台差异、网站说明和素材表达。 2026-04-01 TrekReel 1.0.4 曾因把 App 内付费墙截图误传到 IAP Promotional Image 被 Guideline 2.3.2 打回，清除促销图元数据后通过。 公开文章应该把 3D、地图和视频能力转成创作者语言：路线为什么值得看，哪些信息应该出现，节奏怎样不打断故事。
从产品功能看，TrekReel 关联的能力包括：导入 GPX / KML 轨迹、生成 3D 地图路线故事、面向社交视频和旅行复盘、支持多语言产品页面和发布素材。写这类日记时，不能只说“做了什么”，还要说明为什么先做这些、为什么暂时不做另一些。比如一个按钮、一个导入流程、一个本地模型开关或一段截图文案，放在代码里只是小改动，放在产品里却会影响用户理解、审核员复现和后续推广素材。
从工程推进看，这篇日记对应的检查点是：视觉工具、地图数据和视频导出课程案例。真实开发最容易失真的是中间过程，因为最后页面看起来只有一个结果，但实际会经历方案取舍、权限确认、素材准备、测试设备、审核备注和发布节奏。把这些过程写下来，后面做同类产品时才不会重新踩同一个坑。
从隐私和合规看，当前约束是：轨迹文件处理优先在本地完成。这类信息必须前置到开发日记里，因为独立产品的可信度不是靠口号建立的，而是靠数据在哪里处理、用户能不能退出、功能是否离线可用、商店页怎么承诺、隐私政策是否与实现一致这些小事实积累出来的。
从课程和复用看，这篇内容可以沉淀到 地图可视化、GPX / KML、视频素材生成。它的价值不只是给访问者看一个产品，而是展示一个独立开发者怎样把想法转成可验证的产品：先收窄场景，再选技术路径，再做体验最小闭环，最后把审核、推广、运营数据和失败教训都纳入下一次迭代。
视觉工具要从数据入口讲到导出结果，用户购买的是可发布素材，不是中间预览。 这也是为什么每篇产品日记都要写到足够长：不是为了凑字数，而是为了把“证据、决策、实现、边界、复盘”都放在同一页，让读者看到一个判断是怎样被逐步验证出来的。最难的是把原始轨迹数据变成有镜头语言的路线故事，而不只是画一条线。
所以这篇日记的结论不是“功能已经写完”，而是把一个阶段的判断公开化：哪些证据足够支撑继续推进，哪些资料还需要回到源码、商店材料、公开文案或运营观察里补齐。这样的记录会比单纯的发布公告更慢，但也更真实，能让产品页、发布记录和课程内容保持同一条事实线。
验收时我会把它拆成四个层次：第一层是用户路径能不能走通，第二层是异常状态有没有被诚实处理，第三层是页面上的按钮、状态、截图和文案是否对应真实发布渠道，第四层是公开证据能否支撑这个判断。只要其中一层对不上，产品看起来再完整，也不能算真正进入下一个阶段。
交接时也要保留边界：源码、构建、测试、商店元数据、公开文案、平台反馈和运营观察分别保存原始资料。产品日记只把这些事实翻译成读者能理解的过程，不替任何私有记录保存原始材料。
把这些内容公开出来，还有一个很现实的原因：AI 教程如果只展示成功结果，很容易让人误以为产品是一次生成出来的。真实情况恰好相反，真正可学习的是一次次收窄、验证、失败、补证据和重新提交。日记越具体，后续读者越能看到判断的脉络，而不是只看到一个漂亮的截图。
Apple 原文要点
Guideline 2.3.2 - Accurate Metadata：Apple 认为要展示在 App Store 上的 promotional image 没有充分代表对应的 promoted In-App Purchase 或 win-back offer。
具体问题是促销图来自 App 内截图。审核设备是 MacBook Air (15-inch, M3, 2024)，具体提交编号留在内部归档。
中文翻译
Apple 不是说 IAP 不能有截图，也不是说付费墙不能给审核员看。它指出的是 Promotional Image 这个公开促销槽位不应该随便用 App 内截图充当。
Review Screenshot 是给审核员验证购买流程；Promotional Image 是给 App Store 产品页公开展示 IAP。两个字段看起来都和图片有关，但用途完全不同。
我们怎么解决
回复里直接承认是我们理解错字段：把内部 paywall screenshot 放进了 optional Promotional Image，而它本来只应该留在 Review Information。
因为当时不计划在 App Store 产品页直接推广该 IAP，所以最稳的修复不是重新设计促销图，而是完全移除 Promotional Image 元数据，请 Apple 继续审核 App 更新。
复用教训
IAP 上架资料要分三个层级：App 内真实购买路径、给审核员的 Review Screenshot、给用户看的 Promotional Image。不要因为都叫截图就混在一起。
如果产品还没准备好公开推广某个 IAP，宁可不填 Promotional Image。少填一个可选促销位，比上传错误素材后被 Accurate Metadata 打回更稳。