Banktivity 放弃文档模型，转向库架构

伊恩·吉莱斯皮（2025年）：

传统上，Banktivity 属于所谓的基于文档的应用。它允许用户创建并打开彼此独立的文件（即文档），每个文件都拥有自己的数据。相比之下，许多现代应用——如音乐、日历、照片——则采用基于资源库的模式。这类应用通常只有一个窗口，并使用统一的数据集。我们一直很欣赏这种文档模型所带来的灵活性。但在实际使用中，大多数用户只处理单个文件；更为关键的是，这样的架构也使得 Banktivity 难以与更广泛的 Apple 生态系统实现深度整合。 从基于文档的模式转向全新的 Organizer 框架，标志着 Banktivity 迈出了重要一步。这一变革既简化了用户与数据的交互方式，也为更深层次的系统集成、后台同步以及更加流畅的多设备体验奠定了基础。

这紧随 MoneyWell也在取消文档模型 之后。在我看来，这未免有些遗憾。我更倾向于那种能够将不同账户分散存放在不同文档中的灵活性，既可以自由选择文档的存放位置，甚至还能出于性能考虑将同一个账户拆分到多个文档中。

伊恩·吉莱斯皮（2025年）：

分类账包含一套完整且相互独立的账户、类别、投资、目标、预算等信息。许多用户只需一个分类账来管理其财务即可。但我们也清楚，仍有相当一部分用户需要同时管理家庭成员、非营利组织及小型企业的财务——对他们而言，对多份分类账的支持至关重要。 虽然用户界面是直观可见的部分，但真正艰巨的工作主要集中在底层架构上。作为替代原有文档体系的支柱，资源库框架已经就位。这意味着我们现在可以可靠地将您的 Banktivity 用户账户与所有分类账关联起来，无论这些分类账是本地存储的，还是已同步至云端的。

伊恩·吉莱斯皮：

将 Banktivity 由一款基于文档的应用重构为资源库式的应用，是一项规模庞大的工程。它改变了代码中一些极为根本的假设。如今，分类账可以在后台灵活地打开与关闭，多个窗口和场景可同时处于活动状态，而 Organizer 则需以前所未有的方式协调本地文件、云端同步、用户账户以及应用状态——这是旧有文档架构从未面临过的挑战。Banktivity 10.0 为这一转型奠定了基础。在 Banktivity 10.1 中，我们的重点之一便是进一步夯实这一基础。我们投入大量精力简化底层架构，消除竞态条件与线程相关问题，并改进分类账的打开、关闭与管理工作。

此前：

• MoneyWell 2023.01