应用是什么#

TranscribeNote 是我写的一个 macOS 原生录音转写工具。核心功能是实时语音识别（ASR），用的是 macOS 26 的 SpeechAnalyzer + SpeechTranscriber，没有时间限制，支持 volatile/final results。

但光转写不够用。开了一个会，拿到一堆文字，还得自己看、自己整理。所以我在转写的基础上加了一整套 LLM 功能：

• 实时摘要：录音过程中每隔几分钟自动生成 chunk summary，录完后再合成 overall summary
• Action Items 提取：从转写文本中抽出待办事项、决策和跟进事项
• Chat Q&A：可以对着转写内容提问，比如”刚才谁提到了 deadline？”
• 自动标题生成：录完自动用 LLM 生成一个标题

为了灵活性，我做了一个 LLMEngine protocol，后面挂了 9 个 provider 实现——OpenAI、Anthropic、Ollama、DeepSeek、Moonshot AI、智谱、MiniMax、自定义 OpenAI 兼容 API（比如 LM Studio），以及 Apple Intelligence 端侧模型。用户在 Settings 里选 provider、填 API key、选模型，还可以给不同任务（live summary、overall summary、title、chat、action items）分配不同的 profile。

开发阶段一切顺利。本地跑 Ollama 做测试，切 OpenAI 跑一下看看效果，Apple Intelligence 作为 fallback。整个架构很灵活。

第一次上架：被拒#

v1.0.0 提交 App Store 审核，被拒了。

第一个问题是 Guideline 2.3.8——App Store 里显示的名字是 “TranscribeNote”，但安装到 macOS 上显示的是 “notetaker”（项目最早的名字，忘了改）。这个好修，改一下 INFOPLIST_KEY_CFBundleDisplayName 就行。

但改完重新提交的时候，我开始认真想另一个问题：LLM 功能到底能不能过审？

最初的想法：全功能上架#

我最初的想法很简单——“用户自带 key”模式。应用本身不提供 LLM 服务，只是一个客户端，用户自己去 OpenAI/Anthropic 注册账号、拿 API key、填进来。很多开源应用都是这么做的。

但仔细看了 App Store 审核指南之后，我意识到这里有坑。

思路演变：从”一刀切”到”分层”#

最开始我想的是最简单的方案：上 App Store 就把所有 LLM 功能全砍了，只留转写。一个编译标志搞定。

但转念一想，这太浪费了。全球版（除中国区）其实可以用 Apple Intelligence——完全端侧运行，不需要网络，不需要 API key，不涉及 IAP，不涉及第三方 AI 服务的法律问题。Apple 自己的技术，用在 Apple 的平台上，审核不会有任何争议。

虽然 Apple Intelligence 的效果确实一般（在我的评测中它是唯一表现不佳的模型），但有总比没有好。至少用户录完会能拿到一个基本的摘要，而不是对着一堆转写文字干瞪眼。

所以方案从”一刀切”变成了三层：

1. 开发版：全功能，9 个 provider 随便选
2. 全球 App Store 版：只有 Apple Intelligence 端侧模型，摘要功能保留
3. 中国区 App Store 版：纯转写，所有 LLM 功能砍掉

实现：条件编译#

用 Swift 的 #if 条件编译，通过 SWIFT_ACTIVE_COMPILATION_CONDITIONS 传入标志。不需要改 Xcode 项目配置，标志在构建命令里传。

关键是找对切入点。整个 LLM 子系统有几十个文件——5 个引擎实现、SummarizerService、BackgroundSummaryService、ChatService、PromptBuilder、ActionItemParser……不可能每个文件都加 #if。

1
static func create(from config: LLMConfig, session: URLSession = llmSession) -> any LLMEngine {
2
    #if CHINA_APPSTORE
3
    return NoopLLMEngine()
4
    #elseif APPSTORE
5
    return FoundationModelsEngine()
6
    #else
7
    switch config.provider {
8
    case .foundationModels: FoundationModelsEngine()
9
    case .ollama: OllamaEngine(session: session)
10
    case .openAI: OpenAIEngine(session: session)
11
    case .anthropic: AnthropicEngine(session: session)
12
    case .deepSeek, .moonshot, .zhipu, .minimax, .custom: OpenAIEngine(session: session)
13
    }
14
    #endif
15
}

1
static var availableProviders: [LLMProvider] {
2
    #if CHINA_APPSTORE
3
    []
4
    #elseif APPSTORE
5
    FoundationModelsEngine.isModelAvailable ? [.foundationModels] : []
6
    #else
7
    if isChineseStorefront {
8
        allCases.filter(\.isAvailableInChina)
9
    } else {
10
        allCases
11
    }
12
    #endif
13
}

1
#if !APPSTORE && !CHINA_APPSTORE
2
LLMAssignmentTab()
3
    .tabItem { Label("LLM", systemImage: "brain") }
4
#endif
5

6
#if !CHINA_APPSTORE
7
SummarizationSettingsTab()
8
    .tabItem { Label("Summarization", systemImage: "text.badge.star") }
9
#endif

1
#if CHINA_APPSTORE
2
transcriptTabContent
3
#else
4
Picker(selection: $selectedTab) {
5
    Text("Summary").tag(0)
6
    Text("Transcript").tag(1)
7
}
8
// ...
9
#endif

1
private var totalPages: Int { infoPages.count + modelConfigPageCount }
2
private let modelConfigPageCount: Int = {
3
    #if APPSTORE || CHINA_APPSTORE
4
    return 0
5
    #else
6
    return 1
7
    #endif
8
}()

踩坑：增量构建 + 条件编译 = 灾难#

第一次构建 CHINA_APPSTORE 版本，打开一看——Summary tab 还在，能看到之前生成的摘要。

原因是增量构建。xcodebuild build 只重新编译源码有改动的文件。SessionDetailView.swift 的源码没变（#if 分支的选择取决于编译标志，不是源码变化），所以编译器跳过了它，用的还是上一次（不带 CHINA_APPSTORE 标志时）编译的 .o 文件。

必须 clean build

切换编译标志时一定要 clean build。不然你会得到一个混合了不同标志的二进制——有些文件编译时带了 CHINA_APPSTORE，有些没带。这种 bug 极其诡异，因为部分功能正确隐藏了，部分没有。

为什么是条件编译，不是 Feature Flag#

最初考虑过运行时 feature flag：

1
// ❌ 运行时检查
2
if FeatureFlags.isLLMEnabled {
3
    // show LLM UI
4
}

放弃了，原因有三：

1. 二进制内容：#if 编译出来的二进制完全不包含被排除的代码路径。审核员做静态分析时不会看到 OpenAIEngine、AnthropicEngine 的任何痕迹。运行时 flag 只是不执行，代码还在。
2. Entitlements 是编译时绑定的：network.client 不能运行时开关。要么声明，要么不声明。
3. 不需要动态切换：这不是 A/B 测试，不需要运行时改变行为。构建目标在编译时就确定了，用编译时方案最干净。

也考虑过拆 target（三个 Xcode target，各自不同的源码文件列表），但太重了。这个项目用的是 PBXFileSystemSynchronizedRootGroup，文件系统自动同步到项目里，拆 target 意味着要手动管理每个 target 包含哪些文件。条件编译几行代码搞定的事，没必要上架构。

构建命令#

1
xcodebuild -scheme TranscribeNote -configuration Debug build

1
xcodebuild -scheme TranscribeNote -configuration Release \
2
  SWIFT_ACTIVE_COMPILATION_CONDITIONS='APPSTORE $(inherited)' \
3
  CODE_SIGN_ENTITLEMENTS='TranscribeNote/TranscribeNote.AppStore.entitlements' \
4
  -archivePath /tmp/TranscribeNote-AppStore.xcarchive \
5
  clean archive

1
xcodebuild -scheme TranscribeNote -configuration Release \
2
  SWIFT_ACTIVE_COMPILATION_CONDITIONS='CHINA_APPSTORE $(inherited)' \
3
  CODE_SIGN_ENTITLEMENTS='TranscribeNote/TranscribeNote.AppStore.entitlements' \
4
  clean build

标志通过命令行传入，不需要改 pbxproj 里的 build settings。$(inherited) 保留 Release 配置自带的默认值（比如优化级别），只追加自定义标志。

回头看#

整个方案最后的改动量出乎意料地小——7 个文件，120 行新增，17 行删除。核心思路就是找到 LLM 子系统的两个入口点（LLMEngineFactory.create() 和 LLMProvider.availableProviders），在那里加条件编译，然后在 UI 层做少量隐藏。

最花时间的不是写代码，是搞清楚三个版本各自需要什么、不需要什么。技术方案反而是最简单的部分。

一套代码库，三种产物，各自合规。