It’s looking like we’ll have the public 2.0 TestFlight launched within the next couple of weeks, though the error bars on that timeline are pretty wide because development speed is dependent on our free time. You can also check our roadmap post for a feature-by-feature list of what’s left; we’re expecting to merge a couple of the outstanding items in the next few days.

It looks like the biggest domain count driver by far is image fetching for link posts, since rendering a website preview involves fetching both the preview image from the linked website and the favicon from Google (favicons account for all those t1.gstatic calls). Disabling website previews and the associated image fetching code cut the domain list down to just Lemmy instances. Mastodon appears to proxy image requests through the instance, which prevents that high domain count. Lemmy has recently added that feature, but right now only instances running the very latest Lemmy code perform image proxying.

We’re looking into adding enhanced privacy features to 2.0; we’ll include one to disable fetching favicons and image thumbnails, since favicons especially are a known tracking/fingerprinting vector.

Hmm, that’s interesting. I’m looking into it!

If you want to keep using Mlem while the TestFlight is down, you can just download it from the App Store–the current release build is identical to the TestFlight, and should keep all your preferences.

Should be pretty straightforward, we’ll look into it for 2.0

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.

This is a known issue, and one that has us completely stumped–we don’t have a single line of code that touches anything related to audio. We’re monitoring it closely as we bring our 2.0 codebase online to try to figure out what’s causing it, and aim to have it fixed in 2.0.

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.

Thanks for the feedback! We’re aware that the iPad version isn’t up to the standards of the iPhone app–we’re a very small team, and so lean hard on Swift’s automatic multi-platform features to make the iPad app even feasible within our development bandwidth. We’re looking into ways we can improve the iPad experience without introducing unsustainable technical overhead as part of our ongoing 2.0 overhaul, and we’ll be sure to take your suggestions into consideration.

deleted by creator

This behavior can be customized under Settings -> Links -> Tappable Links. By default it uses “contextual,” which will display the full link in large contexts and just the title in compact contexts (e.g., comments if you have comment display set to “compact”). Setting it to “large” will always display the full link regardless of context.

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!

It’s currently live on the TestFlight beta! We’re planning to roll it out to the App Store in the next few days.

1. Yes! We aren’t happy with the current state of our media viewer. 2.0 is a backend-focused rewrite, so probably won’t have a new media viewer on launch, but it’s without a doubt high on our list of important features.
2. Hard to say. Our iOS compatibility policy guarantees compatibility until iOS18 reaches 75% market share; after that, I can’t make any promises. We take the decision to drop compatibility very seriously, and try to only do so when the features offered by the newer iOS are valuable enough that we would be compromising the potential quality of the app by ignoring them.
3. Yes. We’re still working out some UX concerns stemming from the fact that it’s very slow to search posts and comments compared to communities, but it’s in the plans.

We’re reluctant to give concrete time estimates since our development time is constrained by our day jobs and other responsibilities, but we hope to have 2.0 in early TestFlight on a schedule roughly in line with our release cadence (~2mo).

We don’t plan to release any new features to the 1.x codebase after 1.3, but we will continue to fix major bugs and maintain compatibility against changes to the Lemmy API while we bring 2.0 up.

We maintain a client-side list of instances supported by lemmy-status.org. Looks like we just forgot to add toast.ooo–should be fixed in the next build.

Update to Sjmarf’s earlier comment: I have finally tracked down the source of the slowdown, and the fix should be out in the next TestFlight build.