My take: If your app needs to update and preserve state (using SQLite or any other DB), it is probably not something you want to pass around as a bundled file.
Or at least, it's extremely limiting, compared with hosting it somewhere on the web, which is not that hard to do these days.
Think of the workflow: Any time the state changes, you need to email a new Capsule file to whoever else is using the app. And one would think the state would change at least occasionally, because otherwise there's little reason to use a DB.
Alternatively, you can just host it on the web, the DB state dynamically updates, and it's automatically available to anyone with app access. Isn't that a lot simpler?
Or the copies can go their own way. I could send someone an itinerary and they could change the dates or drop half the stops and add their own notes without needing to send an updated copy. Getting them to install another app just to open it might be a problem, especially if they only want to use it once.
> Isn't that a lot simpler?
You’re glossing over the recurring cost and annoyance of dealing with the hosting and having to secure the data. This way you just share and it’s local.
Sure, if you have to share data between people, your points are valid. But this seems like a way to build apps geared for individual users, like a notes or recipes app.
Why not on a shared drive like dropbox?
Concurrent editing wouldn't work, though.
Beyond "not working", concurrent editing is likely to silently lose data, or corrupt data, or possibly just fill up your drive with lots of "conflicted copies" that you have to manually reconcile.
When I read about this project, it doesn’t seem like concurrency is much of a concern. I think it’s _supposed_ to be treated like sharing a document with someone else.
If a capsule is a recipe, like in one of the examples, that’s pretty cool. If a capsule is a recipe _manager_, then I think it would get messy.