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…
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.
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.
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.
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.
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.)
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 ¯\_(ツ)_/¯
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.
Hot take: they are doing their jobs.
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.
Can you elaborate on that? Bitwarden’s apps use Bitwarden public API, similar to how the Voyager app uses Lemmy’s public API.
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.
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.
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.
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 disagree. I’m just saying the distribution of workload has an impact on what looks a good idea or too hard.