![](https://lemmy.ml/pictrs/image/fad2ed1e-69c2-4111-adcb-45f7fb00a1b9.png)
![](https://lemmy.ml/pictrs/image/d3d059e3-fa3d-45af-ac93-ac894beba378.png)
I’m one of the Mlem devs. We don’t have it yet, but it’s on our roadmap–its planned to be implemented within the next couple of weeks.
Dev lead for Mlem, the iOS Lemmy client.
I’m one of the Mlem devs. We don’t have it yet, but it’s on our roadmap–its planned to be implemented within the next couple of weeks.
Posts are marked as read when you interact with them (vote/save/reply/etc) or tap them to view the comments.
We have an issue open for marking read on scroll. The trouble with that feature is that the API only supports marking a single post as read at a time, so we either have to fake it locally or spam the API. The former is problematic because it either introduces what amounts to a memory leak as we track every read post or results in posts being displayed as read and then popping back up when the cache evicts that info. The latter is obviously unacceptable and constitutes extremely poor API citizenship.
We’re currently working with the Lemmy devs to get a batch mark read endpoint, which will let us implement this feature without either of those problems.
It’s on the way! That feature is currently being tested in the beta, and will definitely be out in the next App Store release.
If you’re on the beta and it’s not working, please let me know so I can open a bug fix issue.
I’ve added it to the issue tracker.
Here’s the link if you want to watch its progress–we’ve got a ton of work already planned, so it probably won’t be scoped for a couple weeks at least.
There are plans, but they’re way in the backlog.
Right now we have a draft implementation–it’s currently very rough (not even in the dev build yet), but progress is definitely being made. It is not scoped for the next TestFlight release (Oct 1), but we are hoping to have it in the following one (Oct ~15). That being said, these are estimates and not promises–it’s a complex, sophisticated piece of code and delays do happen.
We are! We haven’t scoped it concretely yet, but it should make it into one of the next few development cycles.
Edit for clarity: we already have a feature to hide read posts in the ellipsis menu at the top right of the feed page; we’ve got work scoped to add a button that floats like the jump button which can be bound to that functionality as well.
It doesn’t work because we’re currently using the native QuickLook image viewer, which is fairly limited in what it can do. We’ve got a much nicer image viewer in the works–it should be in TestFlight within the next few weeks.
Added to our bug tracker, thanks for the report!
That’s him! He founded Mlem a couple years ago as a pet project and is responsible for basically all of our alpha code. When Lemmy took off, he stepped away from the project for personal reasons largely driven by the scope of the app suddenly exploding from “hobby project” to “production app.” He handed ownership of the codebase over to one of the current team members, and it is now maintained collectively by the Mlem Group.
Yeah, we’re working on it. It’s unfortunately shockingly hard to find good designers who are willing to volunteer their time, but we’re working on it.
I’m really sorry that happened to you! We’re refining that UX to make that much harder to accidentally do in the future.
The App Store requirements are extremely clear that if you have an option to create an account in-app, you need to also offer the option to delete it. According to our app reviewer (and, I reluctantly admit, the text of the requirements), even just linking to a sign-up site like join-lemmy is sufficient to require in-app deletion.
We’re looking into it, thanks for letting us know!
Added to the bug tracker, thanks!
Are you on the App Store or the beta build? That particular behavior should be fixed on the beta, but the change hasn’t gone to the App Store yet.
Either way, as sjmarf said, an option to disable that gesture altogether is planned.
Hmm, yeah, that’s not supposed to do that. Thanks!
We’re working on it! We’ve got some nice new search stuff in early development, still working out the ux but it should be out in the next build or two
Yes! You can find it in Settings -> Content Filtering. We’ve got plans for more robust filtering in the works as well.