Sjmarf @ sjmarf @lemmy.ml

Hi! I’m a developer for the Mlem iOS client. Join us on !mlemapp@lemmy.ml!

---

Read more

Posts

0

Comments

170

Joined

2 yr. ago

I can't reproduce this issue at the moment; it seems to be working fine for me on an iOS 18 iPad simulator. Which part of it doesn't work - do the "Block Community" and "Block user" buttons not show up, or do they show up but not do anything when tapped? Thanks

Edit: it also seems to work correctly on iOS 17.5

Yeah, we'd love to have this but it's unfortunately very difficult to implement so is unlikely to happen anytime soon. We're tracking the issue here.

This is planned 👍 It may or may not be in 2.0; we'll see.

I'm glad you're looking forward to v2!

Voyager also seems to handle GIFs in comments better, is that something on the cards for Mlem?

It's something we'd like to add at some point; we're tracking the issue here. It may end up being in 2.0 or may not be.

Is there a plan to introduce swiping forward? I frequently accidentally swipe back to the community list and lose my place in the feed.

We'd love to have this feature but it is annoyingly very difficult to implement. The framework we're using doesn't natively support this, and neither does the framework that framework is built on. Apollo had this, but the code is of course closed-source so we can't get any insight into how they did it. We're tracking the issue here.

Are you using the beta or the App Store build?

We shut down the old TestFlight for Mlem v1, which you can read about here. You can find links to join the new TestFlight in this post.

Yep, it'll be back :)

This isn't directly possible. You can add an image to the body of the post using the ![alt text](https://example.com/image.png) formatting. Lemmy automatically chooses an image to display on link posts. You can't override this on Lemmy 0.18.4, which Beehaw uses (I believe it's possible on later Lemmy versions, but the official UI doesn't support it on those versions).

We did consider this in the past, but decided against it. Implementing this would mean that we - the Mlem developers - would have to decide who gets the flair and who doesn't. As the development teams of those projects change over time, we'd have to keep up with ensuring their current developers are correctly flaired. This would take time that could be spent developing new features for Mlem instead. There are also many Fediverse projects, and we don't want people asking "why don't the [XYZ] developers have flairs?" if we start giving out flairs to only the developers of certain projects. I hope that makes sense :)

Mlem dev here - we do not and will never run ads, sell data or lock functionality behind a paywall :)

Mlem 2.0 is missing a lot of features at the moment, which we'll be re-adding before the final 2.0 release. You can find a full list in the "Roadmap" section on the 2.0 release post :)

Thanks for the bug reports! We'll look into it :)

Also if more room could be added after the bottom response in a thread. Currently the up/down vote and reply buttons are so close to the nav bar at the bottom I click the nav bar by mistake sometimes.

Sure 👍 Mlem v1 had this; we'll be adding it back in

Thanks for the feedback!

Please add more breathing room/padding to posts — it’s stressful how close posts are to each other (could mostly be solved with just a few more pixels of negative space under the interaction bar before the divider).

Yeah, I'm not happy with the padding there either and we're experimenting with some ways to improve this.

Also, some text feels like it’s cropped by the edges of my iPhone. There is more than enough room to spare on the iPhone Pro Max for that additional comfort.

I'm not sure what you mean by this. Would you mind providing a screenshot?

The interaction bar customization doesn’t allow me to customize it the way I want because it doesn’t consider that I have more space for actions if I remove some readouts. Also, I’d like to reorganize readouts.

I'll look into allowing more space for actions if readouts are disabled. Reorganising readouts is planned in the future, though it may not be in v2.

Almost all settings should be specific to the account they were changed under, like settings of users on a pc. Currently, a change under one account is made to the other accounts.

We're considering applying this to certain settings, such as the "Blur NSFW" setting. We're hesitant to apply this for all settings, because we don't want the settings system to become too complicated for the user. Users might find it annoying if they have to go through all of their accounts to apply a setting change that they want to make globally.

Upon returning to my list of subscriptions (from my All feed for example), my subscribed feed may be highlighted, even though that’s not the page I’m on, coming from, or have selected.

We're looking into it 👍

We'll no longer be supporting iOS 16 from Mlem 2.0 onwards, I'm afraid. We're sorry if that means you can't use newer versions of Mlem. You can read more about our reasons for doing so here.

Thanks for the feedback! I've created issues for these features :)

Mlem dev here! Lemmy has a custom "flavor" of Markdown that is distinct from other social media platforms. Open-source markdown parsers and renderers exist for popular flavors of Markdown (e.g GitHub-flavor), but not for Lemmy-flavor. Most Lemmy clients choose to use an existing GitHub-flavor parser that is close enough to Lemmy's to be indistinguishable in most cases. Mlem uses swift-markdown-ui to render markdown, which uses cmark-gfm as its parser.

Lemmy's spoiler format is unique to Lemmy-flavor markdown, so that's one of the places where use of a third-party markdown parser is noticed by users. Other common parsing errors are _subscript and footnotes.

Adding spoiler support is not particularly easy, unfortunately. You can't really apply spoiler-parsing logic on-top of another markdown parser - it has to be integrated into the parser itself. This is because the app needs to ignore spoiler markdown in certain situations, such as inside of a code block. The only good option is to write a custom markdown parser from scratch, or modify an existing markdown parser to support Lemmy's markdown dialect. Both options can be difficult for developers for several reasons:

• cmark-gfm is written in C, which the developer of the Lemmy client may not be familiar with.
• If the app is using a third-party renderer, and not just a parser, that renderer also needs to be rewritten to support the new parsing logic.

This takes a significant amount of time for comparatively little value for users, so most client developers didn't prioritise it.

In an upcoming Mlem version, we're replacing our markdown parser renderer with a custom one that can render spoilers and subscripts, but we've got a way to go before we achieve full parity with Lemmy. If any developers of other apps are using cmark-gfm, you're welcome to use our code from that repo under the terms of the licence.

Sorry this is kinda long, I hope this answers your question

Footnotes^[Hello world!] are also undocumented.

Yeah, it's rather inconsistent. I opened an issue for it a while ago.

Mlem dev here. It shows strikethrough, but not superscript. Lemmy has got a unique dialect of Markdown - in the current version we're using an open-source Github-dialect parser, which is close to Lemmy's dialect but not perfect. In the next update we've written a custom parser that handles all of Lemmy's Markdown elements, including superscript and spoilers.