Mlem in app browser is using an in app browser API that is secure by design. It doesn’t allow snooping or injecting anything. This article is talking about abusive apps like Facebook that roll their own in app browser.

Edit: although on iOS, the secure iOS in app browser api is always using safari engine, so the user choice argument is still valid.

It’s crazy that the in-app browser isn’t an OS-level overlay that the app can’t influence or look at what the user is doing in it.

Android and iOS both have apis for in app browsers that are secure by design. Voyager for Lemmy uses this. Mastodon uses this. Last I checked even Twitter used this. However Facebook does not.

these platforms also offer lower level APIs to build custom interface which are more powerful and flexible (but can be abused). This isn’t necessarily a problem. Custom browser apps need that functionality, and apps sometimes display their own content with web views.

The problem is that app stores allow slapping a skin on this more powerful API and treating it like an in app browser to connect to arbitrary sites. Dumb imo. If you offer an in app browser, it should be required to use the platforms secure in app browser API.

More powerful APIs should only be available to browser apps and displaying your own content in a web view.

I’m a monthly donor :)

That’s wizards chess

:( Best Buy has the best shuckable hdd deals

Meh. I’d rather make pixel perfect to designs than not have designs…

That’s not quite true - images are only shared if you attach the image to federated content, such as a post or comment. Then yes other instances will cache the image.

If you never do that, and just upload an image accidentally like OP then it will not be federated AFAIK.

That sucks. As a 3rd party Lemmy app developer, I’ve only had positive interactions with the Lemmy devs. They’re even being proactive in communications.

git: 'gud' is not a git command. See 'git --help'.

rekt

There are absolutely reasons where a native app is worth it - I just don’t think building your own backend or not factors into that decision much.

Maybe the point you are trying to make, is when you have enough resources/large enough company, having duplicate teams for each native app isn’t that big of a deal? I agree financially, although is is harder to technically coordinate two teams with dual releases and implementing features twice, with twice the bugs, and it slows things down. (Maybe not a big deal to Bitwarden - their app featureset may be quite stable, IDK)

(Disclaimer - I’ve been on teams building kotlin/swift apps and also cross platform apps professionally, so this is my firsthand anecdotal experience.)

I don’t really see how developing a backend or not has anything to do with the decision to build a native or cross platform app.

But for Bitwarden, the interface is a much smaller proportion.

Can you elaborate on that? Bitwarden’s apps use Bitwarden public API, similar to how the Voyager app uses Lemmy’s public API.

Everyone on this thread: I can recognize native apps when I see them 😤

Native apps when they see them:

React Native is just a fancy web browser wrapping with some helper APIs.

React native is not a browser. It uses native components.

So you’re going to maintain two separate code bases with two separate teams as a knee jerk reaction to using one of the worst cross platform frameworks out there…

For an app that does little more than display encrypted text in a list…

weird flex but ok ¯\_(ツ)_/¯

Is this real or am I eating the onion

Yeah, this. Remark, the markdown library Voyager uses, is very powerful but also extremely complex (it has to be, to deal with Markdown edge cases).

I made a bit of progress last week on a custom plugin but it’s a lot of work. There’s like 4 layers of parsing required.

I wish Lemmy used GFM spoilers, which just uses normal details and summary html tags. But alas.

It’s really annoying there’s no standard markdown syntax in common mark.

I fully expect GMail to be enshittified in the future.

“GMail through gmail.com and GMail App: Always Free”

“GMail Pro (IMAP/POP/Forwarding): Only $3.99 / mo”

Any service can implement this today, with activitypub. Being an enhancement proposal is just an attempt to standardize extensions to ActivityPub, lots of the time that services have already implemented.

https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md