Thanks for the bug report! It looks like this is due to the antique backend Beehaw is still running–we’ll have a compatibility patch out soon.
Dev lead for Mlem, the iOS Lemmy client.
Thanks for the bug report! It looks like this is due to the antique backend Beehaw is still running–we’ll have a compatibility patch out soon.
Thanks for the bug report! We’re working on it.
Thank you!
Haptic feedbacks aren’t in the current build, but we’ll have them in the next! That build should ship tomorrow.
Is there a way to preserve settings from the old version to the new?
Not right now. We’ve rewritten and reorganized the entire infrastructure that handles settings and configuration, and the new and old schemas are more or less alien. We’ve got an issue open to build a settings import/export tool which will allow things like easily migrating settings across platforms that should also make this possible.
Hmm, that’s strange. Have you tried manually opting out of testing (“Stop Testing” in the TestFlight app) and clicking the link again?
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.
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!
Progressing well! We’re hoping to have the next TestFlight build out soon.
That’s unfortunately not currently supported by the Lemmy backend. There is an issue open for it, though it doesn’t appear particularly active right now.
We have some major changes in development that might make this feasible to implement client-side–I’ve put up an issue for it, but can’t make any promises pending a more thorough technical investigation.
We don’t have a preference–we monitor both pretty actively so whatever is easiest.