438

Bitwarden will be switching to native apps for both Android and iOS (www.reddit.com)

submitted 1 year ago* (last edited 1 year ago) by mahavir@lemmy.world to c/opensource@lemmy.ml

52 comments fedilink hide all child comments

Libredit link: https://reddit.invak.id/r/Bitwarden/comments/1b32bbz/going_native_the_future_of_the_bitwarden_mobile/

top 50 comments

sorted by: hot top controversial new old

[-] Chewy7324@discuss.tchncs.de 83 points 1 year ago

Our Xamarin app is a bit sluggish and uses a lot more resources on your device than you might expect.

Especially on my slower phone, the Bitwarden UI feels like it would shortly freeze. And some actions take longer than expected.

The new native apps with a new UI look great and should be better to use.

[-] DharmaCurious@startrek.website 11 points 1 year ago

Question. I am a computer dumb. Is this scary for me? Lol.

[-] faintwhenfree@lemmus.org 25 points 1 year ago

No, you should ignore these types of posts though.

[-] Chewy7324@discuss.tchncs.de 19 points 1 year ago

No, this is mainly cosmetic changes and changes not visible to the user. It's a result of a small team growing and thus having more time for making their apps better to use.

[-] noodlejetski@lemm.ee 6 points 1 year ago

the apps will look a bit different but will be faster.

[-] Dumbkid@lemmy.dbzer0.com 37 points 1 year ago

I didn't even notice the app was sluggish, but this is still great news!

[-] linearchaos@lemmy.world 2 points 1 year ago

Yeah I mean we use the app for like 3 seconds here and 3 seconds there. I'm not saying that if it was twice as fast it wouldn't make a meaningful impact but I still might not notice.

[-] Timely_Jellyfish_2077@programming.dev 32 points 1 year ago

Much needed change.

[-] merthyr1831@lemmy.world 30 points 1 year ago* (last edited 1 year ago)

Eh. Crossplatform isnt the problem here; Xamirin is. There's a host of next gen cross platform frameworks like Flutter, React Native, Blazor that save you having to maintain two distinct apps; something that's only going to add a bunch of developer burden

[-] moritz@l.deltaa.xyz 15 points 1 year ago

I always recognize Flutter apps on Android as being non-native and avoid them because of this.

I think it is because they seem to never use the system font but Quicksand instead and all the animations feel slightly off.

[-] merthyr1831@lemmy.world 5 points 1 year ago

Personally, beyond a few material-like components I always prefer it when an app goes for its own system-agnostic design language like Spotify does. On desktop I'm definitely more picky if I can get away with it; Qt dor KDE and GTK for GNOME etc

[-] Blisterexe@lemmy.zip 1 points 1 year ago

i love having all my apps match my system, gtk or qt for desktop mui for android

load more comments (1 replies)

[-] deadcream@sopuli.xyz 2 points 1 year ago

Same with Compose even though it's ironically considered native in the Android dev community.

The easiest way to tell that the app is not native is tooltips (those that appear when you long press on a button in a toolbar). For some reason UI frameworks just can't agree to display them in the same way, even if they use material design. Compose's ones are especially bad (some apps like Play store actually have different kinds of tooltips on different screens, meaning they use multiple UI frameworks in the same app).

[-] moritz@l.deltaa.xyz 1 points 1 year ago

With Compose apps I actually never had this problems yet.

load more comments (1 replies)

[-] fmstrat@lemmy.nowsci.com 14 points 1 year ago* (last edited 1 year ago)

Agree. Will it be as performant as native? No. But will it be plenty performant for a password manager, yes.

The only thing I wish RN and Flutter would figure out is bloat. File sizes are huge compared to native. A shame there can't be a shared model in mobile apps for the core system.

[-] AMDIsOurLord@lemmy.ml 10 points 1 year ago

Flutter is native. It gets compiled to an executable, it just takes a render plane from the underlying OS and renders everything in it's own engine. They're working on a new render system that will make it go even faster.

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

[-] aeharding@lemmy.world 6 points 1 year ago

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

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

[-] merthyr1831@lemmy.world 3 points 1 year ago

RN is native too I think, at least it advertises itself as a way to compile some kind of XML syntax into native widgets on either platform. An improvement to PWAs even if I despise typescript

[-] hruzgar@feddit.de 2 points 1 year ago

yeah, it displays native widgets but there is still a js engine (browser) running in the background. So the basically made a layer between native components and Javascript. But the code which is running is js and js is slow.

[-] merthyr1831@lemmy.world 2 points 1 year ago

yeah the JS/TS was always a killer for me ngl

[-] deadcream@sopuli.xyz 2 points 1 year ago

JS by itself is very fast (it's one of the fastest dynamic languages). It's interop with platforms APIs that is slow, at the fact that each React app spins up its own instance of Chromium also doesn't help.

[-] merthyr1831@lemmy.world 1 points 1 year ago

I guess smaller apps would be nice but that's also a thing that can be helped - I have a handful of flutter apps on my phone right now (that i know of) and they run in at:

18MB - Nextcloud recipes client

50MB - Spotube (Youtube music client with spotify integration)

100MB - My job - a savings and investments app, with half a dozen third party API integrations.

So depending on your scope and stuff you can really build an app to whatever size. Cant account for react native or blazor but the idea is usually just abstract native graphics APIs instead of using a browser runtime.

[-] ARNiM@lemmy.world 15 points 1 year ago

Man that looks sleek. I can’t wait for this update to roll out.

[-] SiblingNoah@lemmy.world 15 points 1 year ago

Your turn, 1Password. Native apps are just plain better.

[-] avidamoeba@lemmy.ca 14 points 1 year ago

1P has native apps.

[-] aeharding@lemmy.world 3 points 1 year ago

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

Native apps when they see them:

[-] SiblingNoah@lemmy.world 1 points 1 year ago

They switched to Electron.

[-] avidamoeba@lemmy.ca 1 points 1 year ago

Sorry I thought the context was Android and iOS. Yes, the desktop apps are Electron.

[-] preasket@lemy.lol 2 points 1 year ago

1password should just open source its apps. IMHO, security and infrastructure software has no business being closed source.

[-] noodlejetski@lemm.ee 14 points 1 year ago

gosh, I wish Tuta were next.

[-] DerpDerpingtonIsHere@lemmy.world 2 points 1 year ago

If only.

[-] noodlejetski@lemm.ee 3 points 1 year ago

their UI is the only thing that makes me consider switching to Proton Mail from time to time, but in the end it's just too much hassle to do it all over again.

[-] LunchEnjoyer@lemmy.world 13 points 1 year ago

Happy to hear!

[-] pineapplelover@lemm.ee 10 points 1 year ago* (last edited 1 year ago)

Wait so what have we been using?

Edit: ah ok the post explained everything well

[-] aeharding@lemmy.world 9 points 1 year ago

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 ¯\_(ツ)_/¯

[-] NeatNit@discuss.tchncs.de 27 points 1 year ago

I don't get what you're saying. It's not a knee-jerk reaction for one thing, it's a thought-out conclusion. They already maintain multiple codebases (server, browser extensions, mobile client...), they're big enough that it's not a bad idea, aren't they? And it does do more than display encrypted text, notably implementing auto-fill and eventually passkeys.

I also don't see this as a 'flex' in any way, just transparency and sharing their process and conclusions with the community.

[-] wuphysics87@lemmy.ml 5 points 1 year ago

Hot take: they are doing their jobs.

[-] theherk@lemmy.world 2 points 1 year ago

Recognizing you as a PWA developer; and a damn fine one, I get your take. But surely you are aware there are limitations to using PWA’s or other cross platform libraries. Sometimes maintaining multiple UI’s is the right choice. Especially if very little of your code is actually the front end. For you, Voyager is pretty much 100% front end, so that’s 100% of your code. But for Bitwarden, the interface is a much smaller proportion.

[-] aeharding@lemmy.world 1 points 1 year ago

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.

[-] theherk@lemmy.world 1 points 1 year ago

Sure. Bitwarden provides its own backend. So that backend represents some portion of their code base. In the case of Voyager, Lemmy provides the backend. So that backend isn’t a portion of your code. So Voyager is 100% frontend. Bitwarden is < 100% frontend.

[-] aeharding@lemmy.world 1 points 1 year ago

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.

[-] theherk@lemmy.world 1 points 1 year ago

Because it changes the risk benefit profile of the choice. Imagine that your backend is 70k hours of work and your interface is 1k hours. Managing two interfaces isn’t going to seem like nearly as big an ask so other variables may get a higher weight. Of course those numbers are contrived for the sake of explanation, but if you still don’t think there are any circumstances in which others may value the benefits of native applications over cross platform applications, that’s fine. My point is simply that it may not seem like the trouble of managing two frontends is as insurmountable as you may think.

But I have a hard time believing you don’t think it is possible that there are any situations where one might reasonably believe it worth it.

[-] aeharding@lemmy.world 1 points 1 year ago

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

[-] theherk@lemmy.world 2 points 1 year ago

I don’t disagree. I’m just saying the distribution of workload has an impact on what looks a good idea or too hard.

[-] ggnoredo@lemm.ee 5 points 1 year ago

They are using mssql and xamarin. Very poor decisions

[-] glibg10b@lemmy.ml 47 points 1 year ago

I chose Xamarin in the early days of Bitwarden because it was a technology that I was proficient at (.NET and C#) and it afforded me the time to maintain a mobile app along with all the other apps I was building for Bitwarden. Xamarin is a real time saver, for sure and it has served us well over the past 8 years, but it comes with some downsides as well: ...

[-] kogasa@programming.dev 1 points 1 year ago

What's wrong with mssql besides licensing? It's fast

[-] subtext@lemmy.world 4 points 1 year ago

Very exciting news… I’m the tech support for the family and I just can’t yet recommend argon as the hashing algorithm for everyone yet because they’ve said there’s a few potential hiccups. Looking forward to something snappier.