iOS app

[hanpurn]

When can I expect to have athens app in iOS?

[Limezy]

Not before Q3 https://github.com/athensresearch/athens/projects/12
I guess deploying a mobile app involves a lot of features to be already deployed and working well.

[neotyk]

Have we considered PWA approach for mobile app?
It wouldn't make sense to host DataScript on mobile device, so PWA approach would require self hosted instance.

[tangjeff0]

I actually think the most important things about mobile is quick capture and triage, not full on reading and writing. Two workflows I'm thinking of.

1. Quick Capture: User has an interesting thought while walking around. Current solution: Apple Notes / Google Keep / Drafts3, but user has to copy note back to Athens later.
2. System-level Share. User opens a link on Twitter or Reddit, but doesn't want to read entire thing now. User bookmarks with Instapaper or Pocket.

Difficult thing about 2 is that it's System-Level, meaning it's probably still separate even if we make a PWA. I looked into React-Native before and we would still have to drop into Xcode stuff because it's native, not JavaScript.

[neotyk]

Capture is very much possible with PWA: https://web.dev/web-share-target/

[tangjeff0]

Had a discussion on Figma with some people and we came to this point:

What is the MVP for a mobile app?

• React Native / re-natal (50% shared code)
• PWA (90% shared code)
• 1-Way Quick Capture, very low requirements, e.g. Drafts3 (0% shared code)

For a more featured app, the large components might be:

1. Input experience
   • slash menu
   • autocomplete
   • text replacement
   • fancy keyboard
   • low-level block
2. Render: making links look like links, bold/highlight
   embeds?
3. Data - latency, first-run load time
4. Navigation - How go up one block? down one block?

[alexandergunnarson]

React Native / re-natal (50% shared code)
PWA (90% shared code)

@tangjeff0 there could be quite a bit more shared code with React Native if Athens were to use react-native-web. However, this would require some rewriting, so understood that this is probably out of scope. Figured I'd put it out there FWIW.

[Limezy]

Hi, good to see discussions about iOS apps starting !

iPad or tablet ?

First of all, I think we should distinguish between the iPadOS app (or tablet app) and the iOS app (or phone app).
Because of the screen size and because now most of tablets (at least iPads) come with optional physical keyboards, it seems to me that both cases are very different and should be treated differently (from a product point of view, not a technical point of view)

The first question : where is the database ?

For me, this is the question we have to address even before we start talking about any technical detail and/or features coming with the app ! I can foresee four main use cases :

1. The database is locally stored "in-app" (standalone app)
2. The database is locally stored in the device's native filesystem (so it's a .transit file viewable and mangeable, shareable...)
3. The database is synchronized with an external cloud service (Google Drive, One Drive, Dropbox, Nextcloud...)
4. The database is in an Athens backend server - either Athens Research hosted (SaaS) either user's server hosted (self web hosted)

I have never used Androïd so please correct me if I'm wrong, but at least for iOS / iPadOS, my cases 2 and 3 are the same.
Indeed, since a few years all cloud providers have now integrated their solutions with the native filesystem - Files app.

Again, I'm not a technical (at least in the IT field 😄) but I can foresee a lot of problems for the use cases 2 and especially 3.
The most obvious one being that if you happen to have your mobile app opened at the same time as your desktop app, that will lead to cloud server conflicts. These would clearly not be the responsibility of Athens, but most users would blame Athens for it !

For the case one, it's quite silly for a phone, but it may make total sense for a tablet. I have some friends using quasi only iPads in their everyday life, and they may just want to take notes there. But if we build such an in-app storage, how do we deal with the backups in case of corrupted data ? We may at least allow these users to export their database and then share it using the native system (airdrop, send by email, send by whatsapp and so on...)

For the case four, I think it should be the priority for several reasons :

• It may help pushing users towards the SaaS service, which seems to me like totally legit
• Athens Research could provide with a free starting point including a number of pages or a size of database
• It would allow the user to use his mobile app and desktop app simultaneously
• It would allow the user to view or modify a multi-users database, which is obviously impossible with all other use cases

I can see a few difficulties, the biggest one being dealing with "airplane mode" (but I'll put things on that in the dedicated discussion)

Where is the database ?	In-app storage	In-device storage	External cloud service	Athens backend server
Phone	Sounds silly use case	We may face lots of sync issues Athens can't do anything about it but will be held responsible Maybe doable but shouldn't be the priority [RTC ❌]		Best experience use case Should be the priority How to deal with airplane mode ? [RTC ✅]
Tablet	Sounds legit use case How to deal with backup ? [RTC ❌]

The second question : what does the mobile app do ?

I can foresee four different use cases. They are not ordered

• Quick capture / system-level receiving integration (integrate a "send to Athens" action that would send the text or image or document to the daily note, or to a dedicated mobile inbox). Needs a deep look about how we deal with different documents, and may need the document attachements Athens feature to be ready first.
• View / navigate in the database
• Write / modify the database
• Export a page or text selection - system-level sending integration (send a page by email, whatsapp, send to apple notes and so on... )

For the phone app, the quick-capture one looks like the priority, whereas for the iPad app, the ability to write / modify the database sounds like more important than capturing.

Mobile use case	Quick capture at system level	View	Write / modify	Export at system level
Phone	Priority 1 Makes no sense without Athens backend	Priority 2 Needs some thinking about how to nicely integrate the multi-touch	Priority 3 Needs a paradigm change, special keyboard and so on...	Priority 4
Tablet	Priority 3 Makes no sense without Athens backend	Priority 1 Could be just a copy-paste of desktop interface (at least in the begining)	Priority 2 Could be just a copy-paste of desktop interface (at least in the begining)	Priority 4

[tangjeff0]

Great writeup again @Limezy. Few points

• I agree that mobile and iPad are actually quite different from product POV.
• I agree with your statements on how they differ.
• Note-taking purely on a tablet is probably more common these days.
• For "Where is DB" I agree with your prioritization. 2/3 not important, 1 is maybe important for iPad but that seems like a narrow use case. 4 makes the most sense for most users and Athens' business model.
• For "airplane mode", we believe this can be solved if/when we migrate to Datahike on the frontend. (We're partnering with them, will announce more soon hopefully, cc @whilo @smothers @rubinovitz for mobile use case.)

[Limezy]

Hi @tangjeff0, great if you agree with these points !
Good news about Datahike, sounds like hitchhiker trees are a promise of good speed improvements overall.
Curious though to understand how and why Datahike would be better than Datascript at handling offline mode.
Are there any other differences than the fact that Datahike uses more performant data trees ?
Waiting for your official announcement 👍

[becomingbabyman]

Hi @Limezy. Re why Datahike over Datascript I can share a few reasons that are top of mind for me.

1. Datahike supports pluggable persistence layers, so saving to disk is a first class concern and handled more idiomatically across platforms.
2. Datahike is “immutable”. It defaults to append-only transactions, preserving history similar to git and providing more options for offline -> online conflict resolution and reverting to old versions.
3. We are working on easier defaults for conflict resolution and joining data between databases; like universally unique :db/ids, a universally unique attribute namespace, and support for CRDTs.

Christian can probably speak more to this, but we are also looking to target the GraalVM. This will let Datahike run as a native binary rather than in the JS thread on iOS.

[Limezy]

Hi @smothers really interesting andd amazing work, thanks for the insights. Looking forward to testing datahike integration in Athens. Would you say there are speed improvements over Datascript (over the fact that it's based on hitchhiker trees) ?

[becomingbabyman]

There is probably no speed improvement at least for small data sets. Datascript is in memory, mutable and designed to be an alternative to other synchronous in memory data like JSON. It’s designed to be light weight so you can create Datascript DBs ad hoc.

Datahike is designed to be a durable DB, like an open source Datomic. It’s async at heart to deal with IO and the hitchhiker tree is more for immutability and scaling to larger datasets than competing with something like Datascript. However, as we make Datahike more local-first; replicating and persisting data on clients, it should feel a bit faster. In particular on app start, since most data does not need to be fetched from a server and the indexes leverage native persistence layers like IndexedDB on web.

@Limezy, if you have specific performance concerns with Datascript let us know. The Datahike team has done some work on transactions to significantly improve their performance and they’re working on improvements to the query engine. Lots being done here to make everything feel faster to end users while still making for a really nice developer experience.

[solarkraft]

While I appreciate the amount of thought going into building a good mobile experience, it really hurts my usage of Athens to not have anything available on my phone.

I don't think a pure web-app would even be that bad - it'd be the ultimate compatibility solution to access your database from anywhere without Athens installed and would massively alleviate the pain of not having a mobile app, while probably also being much easier to develop.

It doesn't have to be a permanent solution for mobile, but would probably be quite usable until a highly polished react native version comes along (Notion, Dynalist, Workflowy being web views aren't great experiences, but much, much, much better than nothing at all).

I'd like to see this topic receiving some love. (#1380)

[solarkraft]

I am not kidding. I can't be the only one experiencing this. I use Athens to store important stuff. I need that stuff on the go.

[jirutka]

You’re not the only one. This is a deal-breaker, a knowledge base that is not available also on my mobile phone is just useless for me. Fortunately, Logseq has a different priorities and mobile app for iOS and Android is already available.

[solarkraft]

FWIW: That's where I've moved. It also feels somewhat more solid.