Banktivity Document Model and Rewrite
Ian Gillespie (2025):
Banktivity has traditionally been what’s known as a document-based app. It lets you create and open independent files (or documents), each with its own data. In contrast, many modern apps—Music, Calendar, Photos—are library-based. These apps typically have a single window and a unified data set.
We’ve long appreciated the flexibility our document model provides. But in practice, most of our customers use only a single file. And more critically, this architecture makes it much harder to integrate Banktivity with the broader Apple ecosystem.
[…]
The shift from a document-based model to the new Organizer framework marks a major step forward for Banktivity. It simplifies how users interact with their data while laying the foundation for deeper system integration, background syncing, and a more seamless multi-device experience.
This follows MoneyWell also getting rid of the document model. From my perspective, it’s a shame. I prefer the flexibility of being able to have different accounts in different documents, choosing where to store the documents, and even splitting the same account across multiple documents for performance reasons.
Ian Gillespie (2025):
Ledgers contain an entire, independent set of accounts, categories, investments, goals, budget and so on. Many customers will only have one Ledger for the finances they manage. But we also know there is a good number of customers out there that manage finances across family members, non-profits and small businesses – for these customers, support for multiple Ledgers is crucial.
[…]
While UI is what you see, most of the hard work has been in the architecture. The Library framework — the backbone that replaces our old document system — is in place. That means we can now reliably connect your Banktivity User Account with all of your Ledgers, whether local or synced to the cloud.
Refactoring Banktivity from a document-based app into a library-style app was a significant undertaking. It changed some very fundamental assumptions in the code. Ledgers can now be opened and closed in the background, multiple windows and scenes can be active at once, and the Organizer has to coordinate local files, cloud sync, user accounts and application state in ways the old document architecture never had to.
Banktivity 10.0 laid the foundation for that transition. With Banktivity 10.1, a major focus has been strengthening that foundation. We’ve spent a lot of time simplifying the underlying architecture, eliminating race conditions and threading issues, and improving how ledgers are opened, closed and managed.
Previously:
10 Comments RSS · Twitter · Mastodon
It's interesting. For Cashculator I went from library-base to documents instead. Yes, perhaps many customers don't use multiple documents, but there are some do, and there are some benefits. It's easier even for me to try different cases, and easier for customers to send their documents for support. It was a little bit harder for Sync, which I'm planning to release soon, but there is a way to Sync multiple documents, I was inspired to how DEVONthink handles that.
@Jacob Yeah I don’t see it making sync particularly harder except for weird cases like if the user duplicates a document holding an internal sync ID.
Above all, this Banktivity update complicates creating a backup of your important financial data. Before the change, you could simply copy the ibank8 file anywhere as a backup. The new Banktivity 10 forces you to search through folders in the user library to locate the Banktivity data files to make a backup. Why would Igg Software omit such an important feature, a Backup option? I personally have many years of financial data
I emailed Igg Software, Ian specifically and his response was a link to a web page on how to get access to the hidden folder and access the new financial data to make a manual copy.
I am a fan of Banktivity but am sorely disappointed that IGG Software is not concerned with the safety of the users data and any type of encryption.
I have an older version and I prefer a document format because it allows me to segregate documents in their own encrypted disk images.
It's the type of data I silo off because I don't want LLMs (or random apps) potentially accessing it.
This is a good move. The document model doesn't apply well to library/shoebox apps, especially in the age of incremental fine-grained syncing.
I moved Moneydance away from a document model around 2015 and it was well worth it. It now has an incremental, encrypted, fine-grained transaction-log storage system which integrates with the incremental syncing system - none of which would've been feasible with the old document-based system.
The old document model was a great way to quickly bootstrap development of an app in Xcode (or Project Builder!), but far too limiting for bigger projects with incrementally changing data.
@Hammer a library-based app that lets you choose the library's location could be used the same way. Maybe newer versions of MoneyWell can do that?
@Sean What does it have to do with syncing?
Current MoneyWell lets you have multiple “documents,” but it manages the locations for you.
>I moved Moneydance away from a document model around 2015 and it was well worth it. It now has an incremental, encrypted, fine-grained transaction-log storage system which integrates with the incremental syncing system - none of which would've been feasible with the old document-based system.
I don't see how a bundle (the "document") couldn't do that.
I _do_ see how, for many users, a shoebox model is easier to grok than "you have to first create a document".
In Royal TSX, for example, they try to do merge those two worlds; it has a shoebox-like sidebar (a "library", if you will), but the sources of that sidebar are multiple documents which you can individually close, or you can open additional ones. So the _window_ is shoebox-like, but the _sections_ in the sidebar are different documents (a bit like connecting an iPod to iTunes, if you will). I get what they were going for, but I often find it confusing to understand which documents are open. A section header shows a document _title_, which doesn't necessarily match the file name, much less path. I get the thinking, but it's just another abstraction level, and only with "Show Document in Finder" do I truly understand _what_ the source document is.
Interesting discussion. I just want to be clear, each ledger is still tied back to a single document/file bundle on disk. We aren't putting everything in one massive database. Of course, the location of these files is in the blessed Group Containers directory on your Mac, which is easy to backup.
