I just finished adding created/modified date tracking for rows in Bike 2.
At the same time, as you can probably guess from the preview release slowdown, I’ve gotten distracted as I think about iOS and sync. I’ve had two balls in the air over the last 8 months or so:
Bike 2.0 … fix everything from 1.0 that I’ve learned from. Add some big new features.
I want Bike 3.0 on iOS, but that means I need to figure out a good sync solution. And I need to relearn iOS development. It’s been a good 10 years since I did it in a big way.
Over the past two months all my playing with sync and iOS has finally started to get some good results. I’ve gotten excited by them, and so have been pushing that code forward. What I have working, though not extremely tested is:
A generic SwiftUI workspace app that runs on macOS and iOS
You have a list of documents.
Those documents sync incrementally between your devices (using iCloud).
You can also share documents with other iCloud users and changes are nicely synced.
This all works offline/online. You can get near realtime sync if two people are editing doc at same time, but it also works if someone is on a plane and then sync when they arrive.
The core data model that I’m using for sync is the Automerge CRDT structure. So this workspace is syncing generic data, as long as the app can store data in Automerge document, then sync should work.
I’ve built all the different parts multiple times. Now I’m trying to put everything together and am making a new version of the schedule interface from FoldingText:
My thinking is that this will be a low risk app to test the system on. Simple, but maybe useful to some people. I hope to get it out and start learning from it for a while before starting work on Bike 3… which will be Bike 2, but built on this syncing workspace.
So that’s what’s been keeping me happily distracted, and why I haven’t been updating Bike 2 preview much lately. The code will all come together someday I hope.
How far away am I from releasing a preview of this app? I’m not certain. I made a huge amount of progress this last two weeks, but we are just starting a few weeks of summer fun distractions.
Thanks for the update, Jesse. Just keep going. I’m looking forward to seeing your new releases when they are ready. Enjoy your “few weeks of summer fun distractions” and get some good rest!
Definitely slower and more memory use, but how much slower and how much more memory, I’m not sure. Still experimenting with how to integrate these syncing structures into macOS technologies such as CloudKit. Haven’t done much work on mapping Bike outline into Automerge.
My thought at this point is that Automerge will be an alternative file format. So when you use that format then you get the benefits (and costs), otherwise you could continue to use existing formats.
Automerge is usually used in contexts with many users editing the same document, often simultaneously. In a single user setting, it will be able to merge conflicts arising from devices getting out of sync, but imo you can find much lighter solutions for that.
Automerge is usually used in contexts with many users editing the same document, often simultaneously. In a single user setting, it will be able to merge conflicts arising from devices getting out of sync, but imo you can find much lighter solutions for that.
Of course it might all turn into a failed experiment, but I’m really sold on Automerge’s (actually trying Loro right now, but similar tradeoffs) properties and general direction going forward.
I do want to use it to support sharing and simultaneous editing through CloudKit, but full document history in a compact standardized format is also really appealing. Seems like a safe and flexible way to manage your own data going into the future.
Absolutely, I agree! Sorry, I didn’t want to come off as a sceptic of local-first software, it’s only that Bike’s performance is one of my favourite features. Looking forward to reading more about your experiments.