iOS app
in progress
B
Ben Tang
Imported from GitHub feature request.
Source issue:
- #220 Plans for IOS — https://github.com/refactoringhq/tolaria/issues/220
Original context from GitHub:
Just curious if there are any plans for an ios app, or what do you currently use when you need to check/update on the go? Thank you!
Anita Hailey
Learn from Craft’s interaction experience
Rawvoid
Hi,
I’m really looking forward to an iOS version of Tolaria. As a suggestion, it would be great if the iOS app could initially provide a read-only or browsing mode. This way, users could view and navigate projects on mobile while keeping full editing on the desktop version.
This approach could allow early access to mobile usability without waiting for full editing functionality.
Thank you for considering this feature!
Luca Rossi
marked this post as
in progress
J
Jon Beckman
A git sync engine would be preferred. Keeps it git native and free.
From what I have seen from other markdown KB iOS apps, they usually require some type of external git app. Hopefully this can be built in instead.
Luca Rossi
Jon Beckman: yes it can, it's just hard!
c
cooaer
Luca Rossi Just a reminder, due to performance reasons, using the webview technology stack on mobile devices can lead to poor smoothness of the APP. Obsidian has switched from webview to the native compose technology stack.
Luca Rossi
cooaer the best pick for mobile is react native to me — good performance + some reuse from the desktop codebase
guilherme
How will this work? Tolaria is a local-first application.
Luca Rossi
guilherme: still local first, and sync via git
abstradamus
Luca Rossi Git sync is a great option, but I'd love to suggest an additional approach for a wider audience.
Obsidian has a plugin called Remotely Save that syncs vaults via Dropbox, S3, OneDrive, or WebDAV — no git knowledge required. It's still fully local-first (files live on your device), but with transparent sync through popular cloud storage providers.
It would be great if Tolaria supported a similar model — e.g., pointing to a Dropbox/iCloud/OneDrive folder and having it just work. This preserves the local-first philosophy while making sync accessible to non-technical users who don't use git day-to-day
Luca Rossi
marked this post as
planned