Android is definitely on my list of things to try in the nearest future!
Yes, mobile will probably be the first place where it gets interesting.
Let's review: Don't overlook the older text file formats for your data file. Looking at some of my projects over the years, it appears as though I tend to go with the simplest, most efficient file format that meets the requirements. And the simpler text file formats are often the ones I go with, even if I'm storing data that might normally be stored in a binary format (eg, images as well-known-text).
20 years ago, lots of programs used .ini files. These are still useful, well supported by FPC RTL, although maybe not the best choice if you have non-ASCII data or record-oriented data.
Then came XML. Delphi and Lazarus both use XML for their project formats, probably because that's what was popular at the time. Mac OS X uses key-value "property list" files (.plist) in many places, but the actual file format is XML (although since you almost never work directly with the XML, it could very well be in any file format).
Then came JSON. Newer editors like Microsoft's cross-platform Visual Studio Code store just about everything as .json files. And of course JSON now threatens XML on the Web as the transport format of choice. Part of the success of JSON might just be that it fits so naturally into the conceptual containers that programmers already work with: objects, arrays, key-value pairs, etc.
For efficiency, if you have record-oriented data that can fit into a single table (eg, in Excel), then nothing beats CSV or, even better, tab-separated since you then don't need to put quotes around so many things. Compare the speed of sending the same data across the Web in various file formats and then parsing it: tab, CSV, JSON, XML - that's the order of fast to slow, as most XML parsers are pretty slow, as well as the order of compact to verbose.
An issue that you'll run into is that text formats are read-all, write-all, so with a large XML file, for example, most parsers read in the entire file before you can work with the parsed contents, even if you're only looking for a specific node. Same with writing: change one thing and the entire file is rewritten.
Why is this important? Aren't most computers very fast reading and writing text files? Yes, they are, surprisingly so. However, for an app like what you're describing, you'll probably want to be able to sync changes between the user's computers. For example, say you have a Windows app and a companion Android app. If you add a to-do item on either computer, users nowadays expect that change to show up automatically and almost immediately on all other computers that they have that app on. In other words, you need to create a cloud-aware app.
This is where it gets tricky, since there are various platform-specific ways of doing this, as well as various approaches that you can take. The goal, though, is to meet the user's modern expectations.
As an example, let's take Apple's built-in support for these things:
https://developer.apple.com/library/content/documentation/General/Conceptual/iCloudDesignGuide/Chapters/iCloudFundametals.html#//apple_ref/doc/uid/TP40012094-CH6-SW28- Key-value storage. Again, these are just .plist files, for app preferences and the like, limited to 1MB per app, probably to discourage developers from using them in ways that they weren't intended.
- Documents. In Apple terminology, just any INI, XML, JSON or SQLite (and many more) could be considered a "document".
- CloudKit. Data stored as individual records.
Earlier on this link's page, we see this example of the type of data to store in the cloud: "Change log files for a SQLite database (a SQLite database’s store file must never be stored in iCloud)".
Now you see what they're doing there. In syncing, the app only sends the change log, not the entire database. This is consistent with other cloud services, like Dropbox, where they've always discouraged working directly with databases in the sync folder, since any change, no matter how small, can trigger a sync of the entire file.
This is also consistent with the way Apple does it themselves in some of their apps. For example, in their Pages word processor and Numbers spreadsheet, the native format is actually a .zip file. Nothing new there. MS Office does the same thing with its .docx, .xlsx, etc. file formats. However, with Apple's apps, table data is stored in the .zip as separate files, one for each record / row. Again, why would they do that? Most likely, this is so if you modify or add a row to a table, only that row gets synced, not the entire .zip file.
So, can you work up a scheme around SQLite log files? Or something on top of the various platform services for this?
I know nothing of the mormot, but if it can be used for syncing partial content of files between computers, then that might be a good, high-level, platform independent option. If it can't, then eliminate it from consideration. (Looking at the github samples, offhand I don't see anything that resembles what I'm trying to describe.)
Like I said, lots of fun, interesting challenges ahead. I can't really recall much discussion here around this issue of syncing data between computers, so you're probably on the Lazarus frontier.