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.
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.
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.
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.
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.
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.