在开发 KinArchive 时，我们面临一个根本性的选择：使用跨平台框架以最快速度覆盖最广泛的受众，还是针对与我们价值观一致的单一生态系统进行原生开发。我们选择了 Apple——本文将解释原因。
KinArchive 100% 基于 Apple 技术构建。没有 React Native。没有 Flutter。没有 Electron web 视图。纯粹的 Swift、SwiftUI、CloudKit 以及 Apple 提供的原生 iOS 框架。以下是这一决策背后的技术和哲学原因。
隐私架构
家庭文档是人们拥有的最敏感数据之一。护照、医疗记录、保险单、遗嘱——这些不是照片或笔记。对这些数据的不当处理不仅仅是侵犯隐私，还可能导致身份盗窃、保险欺诈或更严重的后果。
我们需要一种架构，能够做到：
- 用户数据永远不会接触我们的服务器
- 即使我们想访问用户文档也无法做到
- 用户不必信任我们——他们只需要信任 Apple
CloudKit 私有数据库
CloudKit 工作原理
CloudKit 提供三种类型的数据库：
- 公共数据库：所有用户可见的数据（我们不使用此功能）
- 共享数据库：特定用户之间共享的数据
- 私有数据库：仅所有者可见的数据——使用其 Apple ID 加密
KinArchive 将所有文档存储在用户的私有数据库中。这意味着您的文档使用您的 Apple ID 凭证加密。即使是 Apple 也无法读取它们。我们当然更无法访问。
当您使用 KinArchive 时，您的文档存储在您的 iCloud 账户中，使用您的 iCloud 存储配额，使用您的 Apple ID 加密。我们没有存储您文档的服务器。我们没有您敏感文件的数据库备份。我们确实无法访问您的数据。
这不是政策选择——而是架构约束。私有数据库采用端到端加密，只有用户的已认证设备才能解密它。
无第三方分析
许多应用程序包含第三方分析 SDK，这些 SDK 会跟踪用户行为并将数据发送到外部服务。这些 SDK 收集的数据通常超出开发者的认知——设备标识符、位置数据、使用模式。
KinArchive 不包含任何第三方分析。我们不使用 Firebase Analytics、Mixpanel、Amplitude 或任何其他跟踪服务。我们收到的唯一分析数据是 Apple 提供的匿名化、聚合的 App Store 指标。
我们不知道的关于您的信息
- 我们不知道您有多少文档
- 我们不知道您存储什么类型的文档
- 我们不知道您的家庭成员是谁
- 我们不知道您何时使用应用程序
- 我们不知道您的位置、设备 ID 或浏览历史
生物识别安全：Face ID 和安全隔区
KinArchive 使用 Face ID（或旧设备上的 Touch ID）进行身份验证。但这在技术上实际意味着什么？
安全隔区
Apple 设备包含一个名为安全隔区的专用安全处理器。这是一个独立的芯片，拥有自己的加密内存，与主处理器隔离。您的生物识别数据——您面部或指纹的数学表示——永远不会离开安全隔区。
Face ID 认证工作原理
- KinArchive 通过 LocalAuthentication 框架请求身份验证
- iOS 提示用户使用 Face ID
- 安全隔区将扫描结果与存储的生物识别数据进行比较
- 如果匹配，安全隔区向 iOS 返回成功信号
- iOS 告知 KinArchive 身份验证成功
关键点：KinArchive 永远看不到您的生物识别数据。我们只从 iOS 收到是/否响应。您的面部扫描数据保留在安全隔区中，受到硬件加密保护。
这与实现自己生物识别扫描的应用程序根本不同。我们不处理、存储或传输任何生物识别信息。我们只是询问 iOS："这是授权用户吗？" iOS 告诉我们是或否。
支付处理：StoreKit 2
KinArchive 通过 App Store 提供订阅计划。我们使用 StoreKit 2，Apple 最新的应用内购买框架。
这对您的支付数据意味着什么
支付流程
- 用户在 KinArchive 中点击"订阅"
- StoreKit 显示 Apple 的支付界面
- 用户使用 Face ID 或 Apple ID 密码进行身份验证
- Apple 处理支付
- Apple 向 KinArchive 发送确认订阅的收据
注意缺少的内容：我们永远看不到您的信用卡号、账单地址或支付详情。Apple 处理整个交易。我们收到的是一个经过加密签名的收据，证明您拥有有效订阅——仅此而已。
这是 Apple 标准的 App Store 模式，但值得强调的是：对于处理敏感家庭文档的应用程序，永远不接触支付数据是一个重要的安全特性。
为什么原生开发很重要
像 React Native 和 Flutter 这样的跨平台框架允许开发者编写一次代码并部署到多个平台。它们受欢迎是有充分理由的——更快的开发速度、共享代码库、更低的成本。
但对于处理敏感文档的安全为先的应用程序，原生开发提供了关键优势：
直接访问安全 API
跨平台框架在抽象层中包装原生 API。这些层可能引入错误，落后于操作系统更新，有时会暴露原生代码中不存在的安全漏洞。
通过原生开发，我们可以直接访问：
- LocalAuthentication：具有完整安全隔区集成的 Face ID/Touch ID
- Security.framework：用于凭证存储的钥匙串服务
- CloudKit：与 iCloud 加密的直接集成
- CryptoKit：Apple 的原生加密库
无 JavaScript 桥接漏洞
React Native 应用程序通过"桥接"在 JavaScript 和原生代码之间进行通信。这个桥接历来是安全漏洞的来源——JavaScript 注入、桥接劫持、通过桥接层泄露数据。
KinArchive 没有 JavaScript，没有桥接，没有 web 视图。它是直接在设备上运行的编译 Swift 代码。
操作系统级优化
原生应用程序受益于跨平台应用程序无法完全利用的操作系统级优化：
- 后台应用刷新：与 iOS 电源管理的适当集成
- 内存管理：Swift 的 ARC 与 iOS 内存处理无缝协作
- 启动性能：无框架初始化开销
- 小组件集成：用于主屏幕到期提醒的原生 WidgetKit
SwiftUI 界面
KinArchive 的用户界面完全使用 SwiftUI 构建，这是 Apple 现代的声明式框架。这意味着：
- 自动无障碍功能：VoiceOver 支持、动态字体和其他无障碍功能开箱即用
- 原生外观和感觉：按钮、导航和交互符合 iOS 惯例
- 自动深色模式：自动遵循系统外观设置
- 性能：SwiftUI 针对 iOS 渲染管道进行了优化
我们做出的权衡
为 Apple 进行原生开发并非没有代价：
- 没有 Android 版本：我们无法服务 Android 用户（目前）
- 没有 web 应用：桌面用户无法从浏览器访问文档
- 更高的开发成本：原生开发比跨平台开发需要更长时间
- 更小的可触达市场：iOS 约占全球移动市场的 27%
我们有意识地做出了这些权衡。对于处理敏感家庭文档的应用程序，我们相信 Apple 生态系统的安全和隐私特性超过了跨平台方法的覆盖范围。
Apple 生态系统的价值观一致性
为 Apple 构建不仅仅关乎技术——更关乎价值观一致性。
Apple 将其品牌建立在隐私之上。"隐私是一项基本人权"不仅仅是营销口号，它体现在整个 iOS 的架构决策中：应用追踪透明度、隐私标签、Siri 和照片的设备端处理，以及安全隔区。
当您使用 KinArchive 时，您将信任扩展给两个实体：我们（应用逻辑）和 Apple（平台）。通过完全基于 Apple 技术构建，我们最小化了信任表面。您的数据保留在 Apple 的生态系统中，受 Apple 的安全模型保护，使用 Apple 的加密技术加密。
我们不要求您信任第三方云提供商、第三方分析公司或第三方支付处理器。我们只要求您信任 Apple——您使用 iPhone 时已经在信任的对象——以及我们在其之上运行的应用程序逻辑。
信任堆栈
硬件：Apple 的安全隔区
操作系统：带沙盒应用的 iOS
云存储：CloudKit 私有数据库（用户的 iCloud）
身份验证：Face ID / Apple ID
支付：App Store / StoreKit 2
应用程序：KinArchive（原生 Swift/SwiftUI）
面向未来
Apple 的平台持续演进。通过原生开发，我们可以在新技术发布时立即采用：
- 新的安全功能：随着 iOS 安全性的改进，KinArchive 会继承这些改进
- 新的 API：直接访问新框架，无需等待跨平台支持
- 性能改进：Swift 和 iOS 优化自动使我们受益
- 新设备：iPad、Mac（通过 Catalyst 或原生）、Apple Watch 集成
结论
为 Apple 构建 KinArchive 不是最快的路径，也不是最容易的路径。但对于受托管理家庭最敏感文档的应用程序，这是正确的路径。
当您在 KinArchive 中存储护照时，您不是将数据托付给未知的云提供商。您将其存储在自己的 iCloud 账户中，使用自己的 Apple ID 加密，由自己的 Face ID 保护。我们在 Apple 的安全基础之上构建了治理层——到期跟踪、权限管理、审计追踪。
这就是我们为 Apple 构建的原因。这就是您的数据安全的原因。