App Store 通过了
两周前我写道:"还在做,还没完成。"今天,DIALØGUE(对话)已经在 App Store 正式上线。最后那 40% 到底是什么样的?
两周前,我在一篇博客文章结尾写道:"还在做。还没完成。还没想好怎么跟女儿解释。"
我当时承诺,等 app 上架 App Store 就来写个后续。或者被拒了也来写。我说,被拒的故事说不定比通过更有意思。
DIALØGUE(对话)- AI Podcast Studio 现已在 App Store 正式上线——这是一款原生 SwiftUI iOS 应用,能把任何话题或 PDF 转化成一集完整的播客节目,由一个从未写过 Swift 的人,借助 Claude Code 搭建完成。 现在就能下载。
但不是第一次提交就通过的。说实话,我一开始就预感被拒的故事可能比通过更精彩。我猜对了。
Apple 拒绝第一次提交后发生了什么?
第一次提交被拒了。Guideline 2.1——性能:App 完整性。内购功能有问题。
Apple 的审核反馈措辞很客气——他们注意到这是我第一次提交,还恭喜我加入了开发者计划,然后清楚地说明了问题所在:审核人员尝试购买时,内购商品报错了。
问题在这:我在自己这边测试,购买流程完全正常。问题出在 Apple 的沙盒环境里——那个环境的行为跟开发环境和生产环境都不一样。StoreKit 的配置必须和 App Store Connect 完全一致,而我的没有做到。我一直在用本地 StoreKit 配置文件测试,审核人员却在访问真实的沙盒。
我当天就修好了,重新提交,通过了。紧接着发布了 v1.0.1 的 bug 修复更新,也顺利过审。
总共提交三次,被拒一次。那次被拒给我上的课,比两次通过加起来还要多。这规律是不是很眼熟?失败永远比成功更能教给你东西。
"最后 40%"到底是什么样的?
在那篇原帖里,我说 AI 能帮你完成 60%,剩下 40% 完全靠人来完成。现在我想说得更具体一些,因为我有 git 日志为证。
16 次提交。57 个文件改动。新增 4,886 行代码。 App 从 69 个 Swift 文件增长到 88 个,从 7,568 行增长到 11,459 行。将近 4,000 行的"打磨"。
这 16 次提交的内容大致按时间顺序如下:
那套从一开始就该有的测试
原始脚手架代码有零个测试。一个都没有。Claude 写了 69 个生产代码文件,却没有写一行测试。那篇原帖发完后,我的第一个正式提交就加入了 176 个单元测试和 19 个集成测试,跑在本地 Supabase 实例上。
写测试的过程立刻暴露出了真实的 bug:Show 模型因数据库字段不存在导致解码失败;AudioPlayer 在曲目结束时没有重置;一个库重新加载的竞争条件;创建向导里缺少对 nil UUID 的保护。每一个都会在生产环境里造成崩溃。
我觉得这个现象值得被说清楚:AI 生成的代码没有测试基础设施。 不是因为它不会写测试——Claude 被要求写测试时写得很好——而是因为初始脚手架的提示词永远是"帮我做这个 app",不是"帮我做这个 app,并配上完整的测试"。测试是我自己决定加的,因为我不想在没有测试的情况下上线。
Studio:从一个空壳变成真正的功能
原来的"Studio"功能只是个占位符。两次提交之后,它变成了真正的产品:有模板网格的节目创建流程、带状态标签和操作按钮的单集管理、编辑/删除工作流、带时区选择器的排期配置,以及声音自定义面板。
然后是 Studio 第二阶段:节目详情页重新设计、单集重试/删除、手动生成单集并检查积分。还加了 8 个新的 XCUITest 来确保端到端流程正常。
这正是我说的"AI 构建了一个代码库,不是一个产品"的意思。Studio 功能编译通过了,也能渲染出一个界面。但你根本无法用它来管理一个定期更新的播客节目。
音频播放器的重新设计
我在原帖里说过我删掉了迷你播放器。结果我说错了——我最终做了一个更好的迷你播放器。最终版本是一个固定在 Tab 栏上方的迷你播放器条,带进度、快进/快退和播放/暂停控制。点击它会展开一个"正在播放"面板,里面有可拖拽进度条、倍速选择(0.5x 到 2x)、播放控制,以及一个声波动画封面。
最棘手的地方是 isSeeking 状态——没有它,进度条的位置和音频观察者会互相打架,出现抖动。就这一行状态代码,我花了一个小时才诊断出来。
我还加入了离线下载功能,带有贴心的视觉反馈:库里已下载的单集显示绿色图标,下载完成时弹出提示,"正在播放"界面显示"已下载"标签,还支持滑动手势删除下载。DownloadManager 里有一个临时文件的竞争条件,藏在 URLSession 的代理回调里,会导致无声失败——修复方法是在回调内部同步移动文件。这种 bug 不会在代码审查时被发现。
全栈安全加固
这部分让我挺触目惊心的。对整个技术栈做了安全审计——不只是 iOS app——发现了多层漏洞:权限过于宽泛的数据库函数、认证边界情况、Token 验证缺口,以及多个后端服务里的输入验证问题。
这些问题没有一个出现在 iOS Swift 代码里。它们全在 iOS app 所调用的后端。但上架 iOS app 意味着你的整个技术栈现在装进了用户的口袋。这把所有东西的风险等级都拉高了。以前对一个 Web App 来说"能跑就行"的代码,放到要经过 Apple 审核、被人随身携带的原生 app 里,感觉就完全不可接受了。
StoreKit:干掉第一次提交的那道坎
StoreKit 沙盒测试是一个独立的宇宙,而正是它让我的第一次提交被拒了。 沙盒环境和生产环境行为不同。交易有时会一直卡在"pending"状态。Xcode 的 StoreKit 配置文件需要手动同步。我花了整整一个晚上排查一个在代码里运行完全正常、在沙盒里却无声失败的购买流程——最后发现是 App Store Connect 里的商品 ID 末尾多了一个空格。就一个空格。
Apple 的审核人员遇到了沙盒错误,因为我的 StoreKit 配置和 App Store Connect 没有同步。购买流程在我本地测试时运行正常——但审核人员访问的是真实沙盒,不是我的本地 StoreKit 配置文件。我当天修好了,但这是"在我机器上能跑"和"在 Apple 环境里能跑"之间的差距的绝佳案例。
购买验证链本身就是一个独立项目:iOS app 把交易的 JWS(JSON Web Signature)格式发送给服务端函数,服务端对 Apple 签名的收据进行完整的加密链验证。不只是解码——是真正的签名校验。这部分花了两次专项提交才做对。
隐私与 App Store 合规
隐私和合规是需要填写的表格、要做的决定、要勾选的选项,每一个都有法律含义——这些事情 AI 帮不了你。 App 追踪透明度声明、隐私营养标签、加密出口合规(是的,HTTPS 也算)、内容版权、Turnstile 验证码集成。Claude Code 可以写 Swift,但它没办法告诉你你的数据收集行为是否需要标注"用于追踪您的数据"标签。
完整的 MFA 与本地化
原来的 MFA 实现只是一个残缺的占位符——空的 factor ID,只有验证流程。我把它重写成了一套完整的 TOTP 生命周期:注册、扫描二维码(原生 CoreImage 生成)、验证、查看状态、停用。这是一个 394 行的 MFAView.swift,之前根本不存在。
7 种语言的本地化意味着 253 条 UI 字符串,翻译成了英语、西班牙语、法语、日语、韩语、越南语和中文。翻译是 Claude 做的,大部分都不错。但日语"大部分不错"意味着你可能有一个按钮标签语法正确、读起来却像机器人写的。我通过把手机系统语言切换过去、真正使用这个 app 才发现了好几处这样的问题。这种测试是 AI 目前还做不到的。
DIALØGUE iOS App 能做什么?
如果你没看过原始构建故事,简单介绍一下 DIALØGUE 能做什么:
你给它一个话题——或者上传一个 PDF——它会生成一集有完整研究、有剧本、有声音的播客节目。两位 AI 主播围绕你的话题展开自然对话,有真实的研究支撑。不需要麦克风。
iOS App 包含:
- 5 步创建向导 — 话题、格式、自定义、大纲审核、剧本审核
- 7 种语言共 30 种 AI 声音 — 英语、西班牙语、法语、日语、韩语、越南语、中文
- 9 种播客格式 — 从科技新闻分析到调查喜剧
- 带锁屏控制的音频播放 — 后台播放开箱即用
- Apple 登录、Google OAuth 和邮箱注册
- 应用内购买 — 积分制,无订阅:4 积分 $4.99,9 积分 $9.99,18 积分 $19.99
- Studio — 设置定期节目,自动生成最新单集
- PDF 上传 — 研究论文、报告、书籍都可以作为素材
这是一个真正的原生 SwiftUI app。不是 Web 套壳。不是 React Native。从最初的 69 个 Swift 文件,到现在的 88 个文件和 11,459 行代码,有 195 个测试在背后撑着。我真的很自豪能把它发布出来。
我对"打磨阶段"的预估有多不准确?
我之前写说 app"还在开发中,处于最后的打磨阶段"。技术上没错,但我严重低估了"打磨阶段"里有多少是全新的工作。
现在翻看 git 日志,16 次提交听起来根本不像"打磨"。它更像是第二阶段的开发。光是测试套件——176 个单元测试和 19 个集成测试——本身就是一个完整的项目。Studio 从占位符变成了完整功能。音频播放器经历了两次重新设计。安全加固涉及 40 多个后端函数。MFA 从头重写。
我还说我删掉了迷你播放器。这也说错了——我最终做了一个更好的,带有"正在播放"面板、倍速控制和下载指示器。当初"删掉它"的直觉是对的——第一版迷你播放器确实很烂。但这个概念是对的,只是需要好好实现。
现在能看到全貌了,我觉得更诚实的拆分是:AI 构建地基(60%),人来构建产品(30%),App Store 提交过程再教你剩下的 10%。
DIALØGUE 在欧盟有吗?
DIALØGUE 在全球范围内提供,但欧盟区域还在 Apple 审核处理中。 欧盟的《数字市场法》要求额外的合规步骤——替代支付方式披露、特定隐私文档、企业注册信息。我已经提交了所有材料,Apple 正在审核。欧盟国家应该很快就能上线。
如果你在欧盟等不及,Web 版在任何地方都可以用,功能完全相同。
AI 辅助的 iOS 开发有多快?
DIALØGUE iOS App 从第一次提交到 App Store 批准大约花了两周——一个晚上的 AI 脚手架搭建,加上两周的人工产品打磨。 我一直在维护这张表格,因为它一直在教给我东西:
| 项目 | 复杂度 | 构建时间 |
|---|---|---|
| DIALØGUE v1 | MVP 播客生成器 | 约 6 个月 |
| STRAŦUM | 10 个 AI 智能体、11 个框架、多租户 | 75 天 |
| 网站重新设计 | WordPress 前端大改 | 3 天 |
| DIALØGUE v2 | 完整 Web App 重建 | 14 天 |
| 博客迁移 | WordPress → Next.js,490 篇文章,Sydney RAG | 4 天 |
| DIALØGUE iOS | 原生 iOS App,第一次写 Swift | 约 2 周(脚手架:一个晚上) |
DIALØGUE iOS 从脚手架到上架大约花了两周。脚手架本身只用了一个晚上。这个比例——一个晚上的 AI 工作,两周的人工工作——说明了我们现在在 AI 辅助开发上处于什么位置。
AI 的那部分一直在变快。人工的那部分基本保持不变。两周前我这么写,现在还是一样。
AI 帮你写代码,什么能力反而更重要?
在原帖里,我还没想清楚该给什么建议。"学会那个打开模拟器的人"是我当时能想到的最好答案。
现在真的把东西上线了,我觉得能说得更具体一些。
这个 App 之所以存在,来自三件 AI 做不到的事:
-
我在用这个产品。 不是测试它——是用它。我创建了播客,上下班途中在听。我注意到大纲审核界面需要显示研究来源,因为我想知道那些事实是从哪里来的。
-
我做了没有标准答案的判断。 删掉迷你播放器还是保留?创建向导里多少自定义选项算太多?Studio 功能该是一个 Tab 还是一个页面下的区域?这些不是工程决策,是品味决策。品味来自用过很多产品——优秀的和糟糕的——然后慢慢培养出一种对"感觉对"的直觉。
-
我在一个为人设计的系统里穿行。 App Store Connect、隐私声明、出口合规、截图规范——这些没有办法自动化。它需要阅读、理解上下文,以及对法律和商业含义做出判断。这种能力——在复杂的人类系统里找到路——不会消失。
所以也许更新后的建议是:深入地使用东西,通过在乎质量来培养品味,并且习惯在那些本来就不简单的系统里找到自己的方向。
这比"学会批判性思考"具体。我觉得更接近真相。我还是不确定这是否足够。
怎么下载 DIALØGUE?
App 免费,内购积分制。无订阅。
全球可用——欧盟区域正在 Apple 处理中,应该很快上线。Web 版在任何地方都可以使用。
常见问题
DIALØGUE 现在在 App Store 上架了吗?
上架了!DIALØGUE - AI Podcast Studio 已于 2026 年 3 月在 App Store 正式上线。免费下载,内购积分制(4 积分 $4.99,9 积分 $9.99,18 积分 $19.99)。全球可用——欧盟区域已提交,正在 Apple 处理中。
欧盟用户能用吗?
已提交,正在 Apple 处理中。欧盟的《数字市场法》要求额外的合规步骤,材料我已经全部提交,只等 Apple 审核。应该很快就能上线。在此期间,Web 版包括欧盟在内的任何地方都可以使用。
Apple 拒绝过吗?
是的——第一次提交因为内购功能有问题被拒了(Guideline 2.1:App 完整性)。StoreKit 沙盒配置和 App Store Connect 没有同步,导致审核期间购买报错。我当天修好了,重新提交,通过了。之后 v1.0.1 也顺利过审。总共三次提交,一次被拒。那次被拒给我的收获比两次通过加起来还多。
整个过程花了多长时间?
从原帖发布到 App Store 批准大约两周。Claude Code 在一个晚上搭建了 69 个 Swift 文件。后续 16 次提交新增了 4,886 行代码,涉及 57 个文件——测试、Studio 功能、音频播放器重设计、MFA 重写、安全加固、StoreKit 验证、本地化,以及 App Store 提交流程。最终上架时 88 个文件,11,459 行代码,195 个测试。
最后 40% 里最难的是什么?
StoreKit 沙盒测试。"代码里能跑"和"Apple 的交易系统里能跑"之间的差距非常大。沙盒交易的行为和生产环境不同,商品 ID 必须完全匹配(空格也算),而且反馈循环很慢——你没办法直接跑一个单元测试来验证。
还能用 Web 版吗?
当然可以。podcast.chandlernguyen.com 功能完全相同,任何设备都可以使用。iOS App 增加了一些原生体验——Apple 登录、锁屏控制、离线下载——但核心的播客生成体验是一样的。
还没想好怎么跟女儿解释。但至少现在有个上线的 App 可以指着说:"人来做的那部分,才是真正难的。"
祝好,Chandler








