Here are the problems I want to solve:

The same app everywhere

It will run as a website, iOS app (also on macOS), and Android app. It will be responsive, supporting phone, tablet, and computer screen sizes along with everything in between.

And I’m not talking about simply resizing the interface. Navigation (e.g. sidebar or on mobile bottom tab bar) will match what you would expect to see on the device size you’re using. But everything else (e.g. posts) will look the same, which I hope will make it really easy to jump from mobile to desktop.

Onboarding and configuration

The app will allow you to configure it to look like a typical Reddit or Lemmy app. During the onboarding process, I will prompt you, asking which style of interface you prefer. Consider these presets, which change a bunch of more granular configuration options. I will also give you the ability to fully customize each option instead of picking a preset.

Caching and offline support

This is where it starts to get more tricky. Caching is easy. If you launch the app, it will have everything you previously saw still loaded.

I would like to make it so upvoting, for example, can be done offline. The app will optimistically apply the upvote to the post or comment, then when you reconnect to the internet, it will actually apply the upvote. This is a difficult problem to solve, so I can’t promise this will work, and it would likely be the last feature I add.

I need your feedback

This is a big project to undertake. I really want a Lemmy client that checks those boxes for myself, but I’m curious if any of those resonate with you? Is there anything I missed that you would like to see? If I do build this, I will likely have to keep the project very focused as far as features go initially.

Just for context, I’m using Voyager on iOS currently. I really like it, but the “the same app everywhere” concept and making it easier to onboard Reddit users are my main motivations for creating my own app. My app will also be fully open source

  • technomad@slrpnk.net
    link
    fedilink
    English
    arrow-up
    10
    ·
    14 days ago

    Could you make a ‘save post as draft’ feature? I think that would make it stand out right now. I’m not sure if any other apps have this yet.

    • Troy@lemmy.ca
      link
      fedilink
      English
      arrow-up
      3
      ·
      14 days ago

      Connect saves drafts transparently as you move around the app.

    • moseschrute@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      14 days ago

      That would actually be easier than the offline upvote feature. The issue with offline interactions is if you upvote in one app, but downvote on another, who wins?

      Offline posts wouldn’t suffer from this problem. That’s my very roundabout way of saying, this shouldn’t be that hard to do.

      • snooggums@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        14 days ago

        That would actually be easier than the offline upvote feature. The issue with offline interactions is if you upvote in one app, but downvote on another, who wins?

        Whichever interaction is sent ‘last’ when connected. No, the user would not have any control over this in the example situation,but to be honest it is a pretty minor issue with no real solution. The same thing could happen in an arbitrary order if you clicked different options on two different browsers at approximately the same point in time because web calls are not instantaneous.

        • moseschrute@lemmy.worldOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          14 days ago

          Respectfully, I don’t think it’s that simple. I think it’s one of those problems that appears deceptively simple, but when you dive into it, it becomes a big headache. One big difference between truly offline first and arbitrary web requests is an offline first app imo should let you close and reopen the app without dropping those pending interactions. When you marry this with cross platform, you need a robust database solution on both native and web, which makes the stack more complicated. I will consider making aspects of the app offline first, but I have decided not to make fully offline first a core feature.

          • snooggums@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            ·
            14 days ago

            Requiring the app to be opened to sync would be annoying for someone who only uses the one app and just wants it to update in the background. Unless the two apps communicate with each other to sort out a priority, there isn’t a way to determine which one counts from the app side.

            • moseschrute@lemmy.worldOP
              link
              fedilink
              English
              arrow-up
              1
              ·
              14 days ago

              Apple is pretty stingy about how often tasks can run in the background. Offline first quickly spirals with complexity that isn’t immediately obvious imo. That’s why I don’t want to make fully local first as a core feature.