Thank you!

@[email protected] deserves equal credit :)

I’ve created an issue to track this. I haven’t looked deeply into the technical feasibility–SwiftUI has some powerful tools for reversing layouts to accommodate languages that scan right-to-left, but I can’t promise this is a feature we can deliver without doing a bit more research.

We haven’t changed anything, but it’s possible your instance admins have made some configuration changes–there are some configuration settings that can mess with image proxying. The Voyager dev brought attention to this last week, plus put up a nice page about it–it’s possible that the sopuli admins fixed their config in response to that.

We’re also on the App Store, but every App Store release goes through TestFlight first.

This is correct. The GitHub releases feature doesn’t make a lot of sense for Mlem, since we primarily deliver through the App Store rather than via source downloads.

Today’s build is a bit delayed due to deployment pipeline issue—it should be up soon. I’ve updated the post with a notice.

The leaf indicates a new account (<30 days old). We also have an issue open for a setting to always display the age indicator, for which we’d probably need some new symbols :)

Mlem is written in SwiftUI, which unfortunately is not compatible with Android. There are some promising projects to port Swift apps to Android, but nothing mature enough that we could feasibly support both platforms, though we’d like to if/when the cross platform Swift ecosystem matures enough for that to be realistic.

Thanks for your kind words!

Scrubbing is actually next up on my todo list, so you shouldn’t have to wait too long for that one.

Thanks! I’ve tracked down the issue, it should be fixed in the next build.

Thanks for the bug report! There isn’t a setting–it should just work. Some questions to help us reproduce and debug:

• Are you on iOS or iPad?
• Which iOS/iPadOS version are you using?
• Can you dismiss images correctly with the X button?

TL;DR: Mlem v1 is not fast; Mlem 2.0 (announcements coming soon!) will be.

We’re aware of a number of performance issues with the current codebase, which all together result in the app not behaving as responsively as we’d like. Unfortunately these are largely due to design choices made during the hectic sprint to App Store release last summer, and so are infeasible to fix without rewriting the app from the ground up—which is why that’s precisely what we’re doing. Our 2.0 build should be significantly faster; we’ll have some announcements about that in the near future.

Sure! One of the big things we’re reworking for 2.0 is how we handle accounts, which includes changing the format of how we persist account information. The compatibility changes in this build add extra decoding logic to the account persistence system so that both v1 and v2 can load a saved account regardless of which version saved it.