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

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.

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.

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

Thanks for the bug report! We're looking into it.

Does this happen on all sort modes, or only specific ones?

Is it affected by toggling "show unread?"

Progressing well! We're hoping to have the next TestFlight build out soon.

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.

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.

As Sjmarf mentioned, we're in bugfix mode for the upcoming 1.2 update. 1.3 is now properly scoped, and will focus on admin and mod tools--we plan to add support for mod actions and build a nice mod tool page to centralize moderation activities.

Yes. As soon as we know that a pending update is going to break compatibility, we’ll put a post up announcing it.

Reporting here works well! You can also directly open GitHub issues, but there's not much to choose between the two.

Thanks for the bug report! We've got a PR open to fix this, should be working in the next build.

We'll look a little deeper into whether that's a feasible toggle--if it can be done without introducing too much technical overhead, I can see the use case justifying the added complexity.

Sorry it took so long, but this feature is live in the latest App Store build!

Thanks for the feedback! We're always trying to balance efficient engineering and streamlined design with a rich feature set--which features have you wish were more immediately available? For engineering reasons, the sheet is here to stay, but we can look into extracting key features up to the top level.

We unfortunately can’t make long press the collapse post gesture, since that is already taken by the system context menu behavior. We can, however, add an option to disable tap-to-collapse, since we already have the alternative of swiping very far to the left to collapse a comment implemented.

Swipe actions on expanded posts should be feasible, but I’m not going to promise it until I’ve reviewed our other planned features and verified that there aren’t other uses for that gesture under discussion.

Sure, we can add that! 1.1.1 is in bugfix-only development at this point, but we'll be sure to include it in the next version.

In the meantime, our app does respect the system-wide 'increase contrast' accessibility option, which is a pretty aggressive workaround will make the instance name much more legible.

Yep, that is actually from the same change! Both should be fixed soon, we’re just testing the new build internally before we release it to TF.