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.

Thanks for the bug report, we’re looking into it!

This is not possible in the current version, but our 2.0 rewrite gives us the level of granular color control required to effectively implement such a feature, so we’ll be sure to include it when that ships.

Gif support is still one of our major outstanding tasks. We are currently working on a 2.0 version of the app, and are hoping to ship it with full inline gif support.

It is our policy not to make features-for-donations transactions, as we feel that would compromise the spirit of the project and set a dangerous precedent that could lead to development becoming beholden to the wealthiest donors. We really appreciate your enthusiasm and your generosity, though–we’re going to be busy for a little while getting 2.0 up and running, but we can tentatively scope widgets for 2.1!

Mark read on scroll is coming in the next build!

As for searching within community, it’s in the plans but I can’t give a more precise delivery estimate.

Thanks for the bug report!

I’m not able to reproduce this behavior–would you mind sharing:

• Mlem version
• iOS version
• device
• a comment that produces this behavior

Thanks!

Thanks for the feedback! We’ll take it under consideration.

There are both technical and design reasons for the change.

Technically, it lets us rip out a lot of logic that handled the differences involved in loading and displaying your own profile vs someone else’s; from a design perspective, this makes your profile page a much more logical grouping: “content you created” instead of “content you created and also content you saved.” Feeds is already the root category for “content other users created,” with each item (All/Local/Subscribed/Community) displaying a filtered subset of that content, a grouping into which Saved fits much more naturally.

Saved posts have moved to Feeds—you can find them alongside All/Local/Subscribed.

My bad, forgot a piece of the path! It’s Settings -> General -> Open Links in Browser (first item in the list).

There are two options:

• In-app, which is basically Safari
• Your default system browser

You can pick which of these to use via Settings -> Open Links In Browser (on will use system browser, off will use in-app browser). Right now we don’t support opening in a third, non-system-default browser.

There were a few reasons behind the change:

• Saved was the odd man out in the profile page–everything else there is your own authored content
• Saved is a feed containing a subset of content generated by other users. Every other such feed was under Feeds; now all such feeds are under Feeds
• This way, what you see on your profile page is the same as what other users see on your profile page
• By extension, the code is much nicer this way because we don’t need to do as much conditional rendering and processing in the user page–we can use the same component with very little modification to display your own profile or somebody else’s
• This also lets us add the Saved feed to the app shortcuts menu without making that horribly inconsistent–the four shortcuts are the four header items in the Feeds tab

They’ve moved from the profile to the feeds tab–you can find them in the feed/community list or by navigating from the header within that tab.

Thanks for the bug reports! Looks like there’s an error in the refresh logic for save–posts should remain in the view when initially unsaved (to avoid losing them forever on accidental unsave), but should disappear when the view is refreshed (which does not appear to be happening).

As far as community blocking goes, that’s mostly handled server-side–once you block a community, the app should filter posts from that community out of the currently displayed feed, and relies on the server-side block functionality to keep those posts from appearing in subsequent loads. We load in pages of ~50 posts, so if you block a community from, say, the profile page, it won’t update that over on the Feeds tab (yet, we’re looking at ways to implement that behavior but it’s fairly involved) and so you’ll still see those posts in the feed until the next load. In theory, simply refreshing the feed will clear them out because it’ll fetch the page fresh from the server.

Thanks for the bug reports!

Highlighting new comments is a good idea! I’ll have to take a look at what support there is API-side for it.

We’d like to remember collapse state, though that one’s a little trickier technically–collapse state is client-side, so we have to do some caching tricks to make that work. We’re reworking our backend modeling for 1.3 to include, among other things, a caching system, so we’ll see if we can work that in.

Unfortunately the API doesn’t support that and it’s infeasible to do client-side, so not for now. They have an issue for it but it’s closed as not planned, though they’ll reopen it if anybody wants to work on it so hopefully we will be able to offer this feature in the future.

Unfortunately not–Mlem is written entirely in Swift and SwiftUI, which as of right now doesn’t work on Android.