Not important enough: 1Password abandons its native Mac app(sixcolors.com)
sixcolors.com
Not important enough: 1Password abandons its native Mac app
https://sixcolors.com/post/2021/08/not-important-enough-1password-abandons-its-native-mac-app/
90 comments
Arguably, Agilebits just focuses more on enterprise customers now. The interesting thing about enterprise users is that you don’t care that much about UX anymore. Your users have no choice and software is bought by management based on some metrics and marketing demos. We, macOS users, are just not the target audience anymore.
I would argue, that the current company is only a shell of the former Agilebits, which honestly cared about users and their needs. But such is the nature of big business, it appears.
I would argue, that the current company is only a shell of the former Agilebits, which honestly cared about users and their needs. But such is the nature of big business, it appears.
We’ve been a 1Password for Business customer for about 3 years. But we’re looking at moving to something like BitWarden because it has true SSO support, while 1Password doesn’t.
1Password has been very clear this is a feature they’re not interested in supporting, and our users have been very clear that remembering a second password and secret key for their password manager is too difficult.
AgileBits is presenting itself as Enterprise friendly, but isn’t. It has its own vision on how the enterprise should work.
1Password has been very clear this is a feature they’re not interested in supporting, and our users have been very clear that remembering a second password and secret key for their password manager is too difficult.
AgileBits is presenting itself as Enterprise friendly, but isn’t. It has its own vision on how the enterprise should work.
>But we’re looking at moving to something like BitWarden because it has true SSO support, while 1Password doesn’t.
That is what I am curious about, too: starting the the v8 of 1Password I just can't justify paying premium for 1Password anymore as a mac user who has a family account. Both have Electron clients and cloud-only vaults, but Bitwarden subscription is 40USD/yr., and 1Password charges 60USD/yr.
In my opinion 1PW just lost any advantage it had, at least for non-business users.
That is what I am curious about, too: starting the the v8 of 1Password I just can't justify paying premium for 1Password anymore as a mac user who has a family account. Both have Electron clients and cloud-only vaults, but Bitwarden subscription is 40USD/yr., and 1Password charges 60USD/yr.
In my opinion 1PW just lost any advantage it had, at least for non-business users.
That’s fair enough, but being Electron or not isn’t the only criteria to judge a UI. Personally after testing both (on Linux) I found 1Password’s UI to be better enough compared to Bitwarden to warrant the price difference.
SSO for unlocking the password vault?
We use 1P for our business and honestly, I’m not sure how fit for purpose it is in the enterprise domain. We only have about 20 people using it and it’s a not that great from an admin perspective.
Simple things like sharing a single password between teams mean you need to create a shared vault that both teams have access to and put the pw in there. Or you send a copy, but now you have 2 copies that aren’t linked.
You can add files but they’re weirdly half linked to passwords, floating about without anyway to see which passwords they’re linked to. Sure, it’s not a file store, but you have to live with the crappy ui or use some other tooling for other metadata.
When I last checked, there was no obvious way to audit which accounts had accessed a given pw. Or to see all the passwords that an account had accessed.
Maybe people manage to make it work for them but as our company grows, I’m going to be pushing harder and harder to remove it from the organisation (and I’ve been using it since 2010).
Simple things like sharing a single password between teams mean you need to create a shared vault that both teams have access to and put the pw in there. Or you send a copy, but now you have 2 copies that aren’t linked.
You can add files but they’re weirdly half linked to passwords, floating about without anyway to see which passwords they’re linked to. Sure, it’s not a file store, but you have to live with the crappy ui or use some other tooling for other metadata.
When I last checked, there was no obvious way to audit which accounts had accessed a given pw. Or to see all the passwords that an account had accessed.
Maybe people manage to make it work for them but as our company grows, I’m going to be pushing harder and harder to remove it from the organisation (and I’ve been using it since 2010).
You should give a try to bitwarden.
I've been using Lastpass for, what, 10 years (met the founders at a conference/fair by then) and dumped it for bitwarden after having had a closer look.
They are missing one thing which I have not seen elsewhere either: accounts where all saved creds automatically go into a shared vault.
I've been using Lastpass for, what, 10 years (met the founders at a conference/fair by then) and dumped it for bitwarden after having had a closer look.
They are missing one thing which I have not seen elsewhere either: accounts where all saved creds automatically go into a shared vault.
When Apple announced their significant upgrades to iCloud Keychain a few months ago, I immediately thought that it was unfair "Sherlocking" of 1Password. AgileBits had been out there offering a first class macOS/iOS password manager experience for a long time and it seemed rude of Apple to step on their turf so blatantly.
I still have sympathy for AgileBits, but these feelings have diminished somewhat now.
I still have sympathy for AgileBits, but these feelings have diminished somewhat now.
If their Mac app has been sherlocked to death, why wouldn’t this make you feel more sympathy?
Do you think Apple knew AgileBits was dropping their Mac version and stepped into the opening? Or did AgileBits step back once it became pointless to compete with an upcoming OS feature?
Do you think Apple knew AgileBits was dropping their Mac version and stepped into the opening? Or did AgileBits step back once it became pointless to compete with an upcoming OS feature?
These significant upgrades to iCloud Keychain are still in beta (macOS Monterey and iOS 15). If AgileBits' announcement represents their response to a competitor that hasn't even released yet, if it means they're diminishing their own product before the competition has even arrived, then I would have zero sympathy for them.
Quite frankly that seems an absurd hypothesis. In the face of competition from Apple, the correct response by AgileBits should have been to double down on product quality and pushing feature depth.
Quite frankly that seems an absurd hypothesis. In the face of competition from Apple, the correct response by AgileBits should have been to double down on product quality and pushing feature depth.
Wellll... Apple is something more than a competitor in this situation. Their own OS; world’s most valuable and profitable company; and so forth.
I can hear the AgileBits marketing department theme song / threnody... https://youtu.be/9yQKDj_V4Gk
I can hear the AgileBits marketing department theme song / threnody... https://youtu.be/9yQKDj_V4Gk
What upgrades are you referring to? I’m looking to migrate from 1Password but maybe keychain will be good enough.
Does it work with other browsers on the Mac?
Does it work with other browsers on the Mac?
https://www.macrumors.com/2021/06/11/macos-monterey-password...
They've released a cross-platform Chrome extension, plus a native Windows client. No Firefox as far as I'm aware, sadly.
They've released a cross-platform Chrome extension, plus a native Windows client. No Firefox as far as I'm aware, sadly.
>We, macOS users, are just not the target audience anymore.
I'm not entirely sure this is indicative of that, I mean what were they supposed to do? SwiftUI is clearly the right choice for iOS, but if they use it on Mac they would have to develop a separate implementation for older Macs, and anyway they hit problems where SwiftUI just flat out isn't mature enough on Mac anyway.
The only other alternative would have been to rewrite the native client again in ObjC, knowing that they would have to rewrite it again in the near future anyway. All of these options suck really badly. I think it's just unfortunate timing given the current state of development of SwiftUI. do you really see a better pragmatic way forward?
This way hopefully in future when older Macs cease being an issue, and SwiftUI on Mac matures, hopefully they will port the iOS code base to Mac. At least the fact they went with SwitfUI on iOS instead of a cross platform framework is a good sign.
I'm not entirely sure this is indicative of that, I mean what were they supposed to do? SwiftUI is clearly the right choice for iOS, but if they use it on Mac they would have to develop a separate implementation for older Macs, and anyway they hit problems where SwiftUI just flat out isn't mature enough on Mac anyway.
The only other alternative would have been to rewrite the native client again in ObjC, knowing that they would have to rewrite it again in the near future anyway. All of these options suck really badly. I think it's just unfortunate timing given the current state of development of SwiftUI. do you really see a better pragmatic way forward?
This way hopefully in future when older Macs cease being an issue, and SwiftUI on Mac matures, hopefully they will port the iOS code base to Mac. At least the fact they went with SwitfUI on iOS instead of a cross platform framework is a good sign.
> The only other alternative would have been to rewrite the native client again in ObjC
They had a macOS native client that was running beautifully and was a reference example of high-quality Mac software. I can understand wanting to improve the backend but the rewriting of the UI was an entirely unforced error.
And it’s made extra clear that they’ll expend effort for a native app on a platform their business is worried about losing, so this really does feel like quite the slight. I’m certainly done with them when v7 stops working.
They had a macOS native client that was running beautifully and was a reference example of high-quality Mac software. I can understand wanting to improve the backend but the rewriting of the UI was an entirely unforced error.
And it’s made extra clear that they’ll expend effort for a native app on a platform their business is worried about losing, so this really does feel like quite the slight. I’m certainly done with them when v7 stops working.
It looks like they're doing a pretty comprehensive rewrite, so sticking with the legacy client isn't an option.
Swift code runs on older macs so no need to go objc
SwiftUI only runs on MacOS 10.15 or later.
Yeah but you can do appkit with swift without having to use objc
That's still a big chunk of new code you need to write only to throw it away a few years later. Even with just a handful of developers for a year or two that's still millions your throwing away, meanwhile you're developing this Electron thing for the Mac anyway so using that for a few years instead has zero cost.
Appkit isn't going anywhere and you can migrate piece by piece to swiftui
I’ll be interested to see how React Native on desktop progresses.
The developer productivity and consistency gains of working on one codebase rather than 2 or 3 cannot be argued with, and I’m confident more and more software will be moving in this direction regardless of the opinion of (what is probably) a fairly small number of hardcore users.
However, I do agree that Electron can give a sub-optimal experience compared to a native app in many cases. React Native could potentially provide a good compromise - write your app in JS but it renders using native UI widgets, resource usage is lower because it’s just using a JS engine rather than a full browser.
It would probably be more work than Electon because each platform will have differences in how it renders, but much less work than building separate native apps.
Last time I checked on RN on MacOS (well over a year ago) it was quite immature, but with Microsoft pushing it on both Windows and Mac, it could become a realistic option soon (if it’s not already).
Not sure if there’s anything on Linux? You could maybe fall back to Electron, with the the UI rendered via react-native-web to turn it back to HTML.
The developer productivity and consistency gains of working on one codebase rather than 2 or 3 cannot be argued with, and I’m confident more and more software will be moving in this direction regardless of the opinion of (what is probably) a fairly small number of hardcore users.
However, I do agree that Electron can give a sub-optimal experience compared to a native app in many cases. React Native could potentially provide a good compromise - write your app in JS but it renders using native UI widgets, resource usage is lower because it’s just using a JS engine rather than a full browser.
It would probably be more work than Electon because each platform will have differences in how it renders, but much less work than building separate native apps.
Last time I checked on RN on MacOS (well over a year ago) it was quite immature, but with Microsoft pushing it on both Windows and Mac, it could become a realistic option soon (if it’s not already).
Not sure if there’s anything on Linux? You could maybe fall back to Electron, with the the UI rendered via react-native-web to turn it back to HTML.
Native will always give the richest user experience, and deliver the most up-to-date tech.
That said, most applications are really windows onto server-based algorithms, so the need for a “pure native” UX is a lot less, these days, than it used to be.
The one big skunk at the hybrid picnic is that we are “dancing with a gorilla.” That means that we don’t get to change the step, or stop, until the gorilla says so.
If we are dependent on any external framework (not just ones like Electron or RN), then we are at their mercy, wrt to adapting to platform and environmental changes.
I know folks that have written code that won’t run on current versions of the OS, because an SDK they use, has not been updated.
That said, most applications are really windows onto server-based algorithms, so the need for a “pure native” UX is a lot less, these days, than it used to be.
The one big skunk at the hybrid picnic is that we are “dancing with a gorilla.” That means that we don’t get to change the step, or stop, until the gorilla says so.
If we are dependent on any external framework (not just ones like Electron or RN), then we are at their mercy, wrt to adapting to platform and environmental changes.
I know folks that have written code that won’t run on current versions of the OS, because an SDK they use, has not been updated.
> Native will always give the richest user experience, and deliver the most up-to-date tech.
No. It could, but when there's only one developer working on that app for three platforms and they prioritize Windows, you gain nothing.
Native will, of course, be a bit faster and have more features, but for that you need to have a dedicated developer that knows the specialities and can make use of them. But if you want to have a mostly up-to-date app with a small developer team, cross-platform apps will be a better experience.
No. It could, but when there's only one developer working on that app for three platforms and they prioritize Windows, you gain nothing.
Native will, of course, be a bit faster and have more features, but for that you need to have a dedicated developer that knows the specialities and can make use of them. But if you want to have a mostly up-to-date app with a small developer team, cross-platform apps will be a better experience.
Native will, of course, be a bit faster and have more features, but for that you need to have a dedicated developer that knows the specialities and can make use of them.
This is why a lot of people are upset. AgileBit was that dedicated developer that developed top-tier macOS apps (like OmniGroup). Many people have poured hundreds of dollars into their product because it was such a great Mac app.
And now that people are locked into cloud storage and a subscription [1] and AgileBits suddenly morphs from an independent Mac developer into a VC-funded Electron developer, a lot of people feel betrayed. Of course, perhaps people shouldn't be surprised, AgileBits is a business after all. But the AgileBits founders always projected this image of being a community and of them cherishing their users.
Who knows, maybe they still care and genuinely think this is the best choice for their Mac users, in which case there is a serious disconnect. Or perhaps, they are not that nice, warm company anymore and this is just a cold business choice.
[1] Which adds to the irony, because one of the main arguments for subscriptions is always that it brings in continuous funding for development, allowing continuous roll-out of new features to users.
Turns out that before subscriptions, Mac users would just not buy the new Electron version and it would hurt AgileBits. With subscriptions, Mac users can hate the Electron version and they will pay for it anyway.
This is why a lot of people are upset. AgileBit was that dedicated developer that developed top-tier macOS apps (like OmniGroup). Many people have poured hundreds of dollars into their product because it was such a great Mac app.
And now that people are locked into cloud storage and a subscription [1] and AgileBits suddenly morphs from an independent Mac developer into a VC-funded Electron developer, a lot of people feel betrayed. Of course, perhaps people shouldn't be surprised, AgileBits is a business after all. But the AgileBits founders always projected this image of being a community and of them cherishing their users.
Who knows, maybe they still care and genuinely think this is the best choice for their Mac users, in which case there is a serious disconnect. Or perhaps, they are not that nice, warm company anymore and this is just a cold business choice.
[1] Which adds to the irony, because one of the main arguments for subscriptions is always that it brings in continuous funding for development, allowing continuous roll-out of new features to users.
Turns out that before subscriptions, Mac users would just not buy the new Electron version and it would hurt AgileBits. With subscriptions, Mac users can hate the Electron version and they will pay for it anyway.
> And now that people are locked into
It doesn’t take a lot of effort to switch password manager, there’s no significant lock-in.
It doesn’t take a lot of effort to switch password manager, there’s no significant lock-in.
> when there's only one developer working on that app for three platforms and they prioritize Windows, you gain nothing.
Which is why hybrid is so popular. It’s not a good idea, generally, to have one developer, working native, on all platforms. You need a team. A fairly expensive team.
I ran a team that provided “engine” code (C++) for native apps (on a couple of platforms) for decades.
I’m fairly familiar with the trade-offs.
Which is why hybrid is so popular. It’s not a good idea, generally, to have one developer, working native, on all platforms. You need a team. A fairly expensive team.
I ran a team that provided “engine” code (C++) for native apps (on a couple of platforms) for decades.
I’m fairly familiar with the trade-offs.
> I ran a team that provided “engine” code (C++) for native apps (on a couple of platforms) for decades.
Same here. The best approach I’ve seen is code is 80-95% C++ business logic, plus a small platform-specific GUI shim in the native language to keep the nice platform look and feel. All the major PC and mobile platforms still can call into and out of C and C++. This is the way! It has been tried and true for years.
Same here. The best approach I’ve seen is code is 80-95% C++ business logic, plus a small platform-specific GUI shim in the native language to keep the nice platform look and feel. All the major PC and mobile platforms still can call into and out of C and C++. This is the way! It has been tried and true for years.
Yup.
> Native will always give the richest user experience, and deliver the most up-to-date tech.
Oh yeah, not arguing with that at all. But I think the commercial reality is a lot of companies will think the trade off of using a cross platform framework like Electron is worthwhile, the UX is “good enough” for most users and the development process is much more efficient.
Of course, users might vote with their feet and go to other apps which are native, but I suspect this trend is here to stay and so it’s good to consider what the “least bad” hybrid option is.
Oh yeah, not arguing with that at all. But I think the commercial reality is a lot of companies will think the trade off of using a cross platform framework like Electron is worthwhile, the UX is “good enough” for most users and the development process is much more efficient.
Of course, users might vote with their feet and go to other apps which are native, but I suspect this trend is here to stay and so it’s good to consider what the “least bad” hybrid option is.
It’s not a new trend at all.
Cross-platform app frameworks have been around for decades.
One of the nice things about writing native on Apple, is plugging into the latest tech. Not always a big deal, but there are some apps that use that as their biggest selling point.
Also, if we are doing low-level stuff (like Bluetooth connectivity), the app framework can be a very stubborn gorilla.
Cross-platform app frameworks have been around for decades.
One of the nice things about writing native on Apple, is plugging into the latest tech. Not always a big deal, but there are some apps that use that as their biggest selling point.
Also, if we are doing low-level stuff (like Bluetooth connectivity), the app framework can be a very stubborn gorilla.
All great points.
One thing I’d say in regard to low-level stuff is React Native allows you to fairly easily call into native code with its native modules functionality.
I work on a iOS/Android music learning app with a C++ audio engine and React Native UI (and Unity for the interactive parts) and it works quite well, for example we call into native code for connecting to Bluetooth hardware.
But you are right, given enough developers and time, native is probably always going to deliver an end result which feels more “right” on the platform.
One thing I’d say in regard to low-level stuff is React Native allows you to fairly easily call into native code with its native modules functionality.
I work on a iOS/Android music learning app with a C++ audio engine and React Native UI (and Unity for the interactive parts) and it works quite well, for example we call into native code for connecting to Bluetooth hardware.
But you are right, given enough developers and time, native is probably always going to deliver an end result which feels more “right” on the platform.
> Native will always give the richest user experience, and deliver the most up-to-date tech.
Really? Hoping your user has updated their OS to ger the latest version of the toolkit/SDK/etc. to be able to "deliver the most up-to-date tech" vs being completely dependent on tooling you fully control ( framework, Chromium/Electron version, etc.). I forget the name of Apple's latest UI kit, but it doesn't work on macOS versions below the latest/latest-1. How can you deliver the latest tech then?
Really? Hoping your user has updated their OS to ger the latest version of the toolkit/SDK/etc. to be able to "deliver the most up-to-date tech" vs being completely dependent on tooling you fully control ( framework, Chromium/Electron version, etc.). I forget the name of Apple's latest UI kit, but it doesn't work on macOS versions below the latest/latest-1. How can you deliver the latest tech then?
It’s always a trade-off; regardless of the infrastructure that we choose.
The #1 imperative, is that the app must work on the current shipping OS. It doesn’t have to be “studly,” but it needs to work, and work well. On Mac and iOS, that’s a lot more important than on Android/Windows.
The #1 imperative, is that the app must work on the current shipping OS. It doesn’t have to be “studly,” but it needs to work, and work well. On Mac and iOS, that’s a lot more important than on Android/Windows.
React Native on Windows and macOS works decently well these days. The macOS port is lagging behind the Windows one, but only by one major version. There are still some third party modules that don’t work on the desktop ports, but the support is getting better by the day. I have one small app in production that supports Android/iOS/Windows/macOS and web, all in one code base. Definitely a game changer, especially with how magically good React Native Web works. I’m using RNWeb for web-only projects, it’s that good!
Nice. I will have to give it another try. One thing that was a blocker for me at the time was no react-native-svg on Mac for rendering custom UI widgets. Doesn’t look like this has been resolved yet but that was quite a specific use case I had.
It seems that macOS support was added to react-native-svg in version 12.1.1 (which is the latest version), it appears they just haven't updated the docs/README yet to reflect that. See https://github.com/react-native-svg/react-native-svg/release...
Oh this is super cool! Thanks so much for sharing :D
Any news about it for linux (gnome or kde?)
It's frustrating not being able to develop something for the 3 oses i use at once (windows, linux, android)
It's frustrating not being able to develop something for the 3 oses i use at once (windows, linux, android)
There are a few half-finished and seemingly abandoned ports to linux. React-native for Windows/macOS is being developed by Microsoft to support their Office teams (afaik, some screens in Office for mobile are react-native, and they want to use it on the real desktop version as well). Unfortunately since Office isn't available for linux, Microsoft isn't doing a port as well.
That's sad, but I can see that making sense.
A fallback option for Linux could be to render the React Native app to HTML/CSS/JS using react-native-web, then package it in an Electron app. Depending on the level of native integration this could be tricky though.
This is an incredibly dumb move that ensures I'll be uninstalling 1Password and moving my business elsewhere. 1Password is one of the only "resident" apps that I've allowed to run persistently on my machine, specifically because it's written in native code. If I wanted something using a non-optimized web container, I wouldn't bother paying the native app premium for 1Password.
And no, this isn't because it's "too difficult" or whatever people want to parrot here. It's because creepy VCs like Accel have pumped tons of money into 1Password, and want to keep the expenses low, and thus the margins high, and thus the earnings as high as possible, so they can eventually float the company at a nosebleed P/E ration on those severely trimmed expenses and hyper-engineered earnings. Great for everyone except the customer, as always. The "enterprise customer" is as annoyed about this as anyone else.
Thankfully, we still live in a free market, so... Yeah, have fun trying to get renewal dollars from me while optimizing for your experience over mine, Agilebits.
And no, this isn't because it's "too difficult" or whatever people want to parrot here. It's because creepy VCs like Accel have pumped tons of money into 1Password, and want to keep the expenses low, and thus the margins high, and thus the earnings as high as possible, so they can eventually float the company at a nosebleed P/E ration on those severely trimmed expenses and hyper-engineered earnings. Great for everyone except the customer, as always. The "enterprise customer" is as annoyed about this as anyone else.
Thankfully, we still live in a free market, so... Yeah, have fun trying to get renewal dollars from me while optimizing for your experience over mine, Agilebits.
As a strategic decisionmaker at a successful tiny company that has never taken outside money, I’m acutely aware of how “annoying” it is when my meticulously crafted, honed and balanced system loses customers to creepy VC crap. Fortunately, we have a base of users who understand the value, but it ain’t a mass-market thing, TFFS.
The indictment here that Agilebits was willing to go above and beyond to maintain native code on both iOS and macOS yet couldn’t justify it even after going all-in on SwiftUI for iOS is striking. It demonstrates just how hard cross-platform is and how far off Apple are with getting SwiftUI to ubiquity.
It's not cross platform if all it does is IOS and mac. Apple doesn't want cross platform on any other platforms than their own. However, many app developers have to worry about windows, Android, IOS, Mac, Web. Very few organizations are willing to have dedicated platform specific teams and want to deal with keeping multiple such teams aligned.
Apple's strategy of raising the walls around their walled garden ever higher might at some point backfire. There's a bit of a vacuum in the market currently with react native and flutter being the main incumbents for cross platform. However both have their limitations.
The holy grail here is something that works on all platforms that does not require huge efforts to tailor to any specific platform. WASM is potentially shaking up this space in the next few years with applications like Figma offering a very slick experience that is mostly not based on DOM trees or other traditional web stuff. Other factors are the weakening of the Android platform in e.g. China where several phone manufacturers are locked out of that ecosystem. Many app developers need to cover all these bases.
I kind of like what Jetbrains is doing here with their multi platform Kotlin strategy. There are a lot of pieces coming together to target cross platform UI development in the next few years. They already took Jetpack Compose and made web and desktop versions of that available recently. Really all that's missing now is an IOS version (they already do mac desktop). And since it's all Kotlin, the ecosystem overlaps with the Android one in terms of libraries and skills needed. They are also working on a WASM backend for the Kotlin compiler.
Apple's strategy of raising the walls around their walled garden ever higher might at some point backfire. There's a bit of a vacuum in the market currently with react native and flutter being the main incumbents for cross platform. However both have their limitations.
The holy grail here is something that works on all platforms that does not require huge efforts to tailor to any specific platform. WASM is potentially shaking up this space in the next few years with applications like Figma offering a very slick experience that is mostly not based on DOM trees or other traditional web stuff. Other factors are the weakening of the Android platform in e.g. China where several phone manufacturers are locked out of that ecosystem. Many app developers need to cover all these bases.
I kind of like what Jetbrains is doing here with their multi platform Kotlin strategy. There are a lot of pieces coming together to target cross platform UI development in the next few years. They already took Jetpack Compose and made web and desktop versions of that available recently. Really all that's missing now is an IOS version (they already do mac desktop). And since it's all Kotlin, the ecosystem overlaps with the Android one in terms of libraries and skills needed. They are also working on a WASM backend for the Kotlin compiler.
'Cross-platform' in the sense that it has to accommodate mobile and desktop which is certainly one of the hardest bits of cross-platform. I know true cross-platform is infinitely harder because the differences go all the way through the OS and down to CPU architecture.
I too would like to see where WASM can go. I think that combined with cross-platform "cores" like Agilebit's use of Rust could be a very viable solution longterm.
I too would like to see where WASM can go. I think that combined with cross-platform "cores" like Agilebit's use of Rust could be a very viable solution longterm.
>going all-in on SwiftUI
That was mistake number 1.
That was mistake number 1.
Well, I guess it's hard to care about (platform-)native apps and toolkits when cross-platform apps are generally winning these days (VSCode, Figma etc.) over native Mac apps, even on macOS itself.
Plus most new apps by Apple these days are horribly bad. People say native toolkits result in better performance and features etc., but I'd take all electron apps of this world instead of Apple's absolutely garbage Music app for example. The buggiest, slowest & and least performant app I've ever seen. Worse than pretty much any cross-platform app.
But hey, at least it uses native controls?
Plus most new apps by Apple these days are horribly bad. People say native toolkits result in better performance and features etc., but I'd take all electron apps of this world instead of Apple's absolutely garbage Music app for example. The buggiest, slowest & and least performant app I've ever seen. Worse than pretty much any cross-platform app.
But hey, at least it uses native controls?
A lot of the worst parts of Music.app, including the Apple Music and iTunes Store UIs are actually rendered in a web view, at least last I checked. So it’s closer to being an “Electron” app (despite not using Electron itself) than a true native app in many ways.
You are right; this app is even worse than iTunes, which was widely considered the worst app Apple ever shipped.
However, this app is almost like "Apple's home-made Electron". It uses web views for the majority of its UI, and doesn't even pre-fetch things either, so each new tab is an exercise of stoicism, and usually underperforms the actual web-page version of Apple Music (https://music.apple.com).
However, this app is almost like "Apple's home-made Electron". It uses web views for the majority of its UI, and doesn't even pre-fetch things either, so each new tab is an exercise of stoicism, and usually underperforms the actual web-page version of Apple Music (https://music.apple.com).
1Password was reading too much Internet, they thought they have their backend written in Rust would get all the attention and hit the jackpot.
Turns out the hate against Electron is far greater than the hype on Rust. And to the specific Mac User group, anything not written in Swift and SwiftUI are just junk.
To be fair, this is one of the best electron Apps out there in terms of resource usage. Most likely due to it being purely used as UI and nothing more. The old 1Password uses 50-60MB of memory, the new one uses ~120MB. I would argue the old one wasn't actually that memory efficient in the first place.
Turns out the hate against Electron is far greater than the hype on Rust. And to the specific Mac User group, anything not written in Swift and SwiftUI are just junk.
To be fair, this is one of the best electron Apps out there in terms of resource usage. Most likely due to it being purely used as UI and nothing more. The old 1Password uses 50-60MB of memory, the new one uses ~120MB. I would argue the old one wasn't actually that memory efficient in the first place.
SwiftUI is terribly immature, the moment they decided to pit it against Electron, they had already lost.
We're pretty much just beta testing it for Apple.
One of the more important features of 1Password, to me, is its cross-platform nature.
Being able to use it on an iPhone, Mac, Android device, or Windows box, is beyond valuable. It’s a huge selling point.
So I am not that concerned about them using a hybrid app.
The biggest concern that I have, is that the poster child for Electron apps is Slack; which I consider to be … non-optimal. I dread firing up my Slack client on Mac.
https://twitter.com/iamdevloper/status/1072503943790497798?s...
Being able to use it on an iPhone, Mac, Android device, or Windows box, is beyond valuable. It’s a huge selling point.
So I am not that concerned about them using a hybrid app.
The biggest concern that I have, is that the poster child for Electron apps is Slack; which I consider to be … non-optimal. I dread firing up my Slack client on Mac.
https://twitter.com/iamdevloper/status/1072503943790497798?s...
I thought VSCode has been the poster child for Electron apps for years now. No one cites Slack as a good example for an app
Good point. VSCode isn’t bad.
VSCode is only fast by IDE standards whereas functionality-wise it’s more an extensible text editor. It lags even at the modest task of resizing its own window, where the UI just freezes at its original rectangle and waits until you release the window. No native app I use behaves like this. This is even before mentioning the innumerate pop-up <div>s that all have different, inconsistent styling. As an application it’s absolutely alien on the system.
I'm in the process of adding "lipstick to the pig," so to speak, on the app I've been developing for quite some time, now.
It's not done, but we are at the point where we can start trotting it out to people from whom we are begging money, so I want it as polished and refined as possible.
This means lots of "little" things, like smooth transitional animations, fast operations, threaded behavior, etc.
Native is good for that. It's lookin' pretty good. No compromises.
It's not done, but we are at the point where we can start trotting it out to people from whom we are begging money, so I want it as polished and refined as possible.
This means lots of "little" things, like smooth transitional animations, fast operations, threaded behavior, etc.
Native is good for that. It's lookin' pretty good. No compromises.
The KeePass database format has clients for every platform… and the best part is you don’t pay for yet another subscription.
Basically they put some arbitrary deadlines which mean nothing but for some reason had to be enforced. They equipped most hipster tools like Rust, SwiftUI, Electron. And they failed miserably.
That’s a good lesson. Extend deadlines if necessary. Use old boring technologies. Don’t surprise users with unnecessary changes. Is it so hard.
That’s a good lesson. Extend deadlines if necessary. Use old boring technologies. Don’t surprise users with unnecessary changes. Is it so hard.
I think using native UI components is the least of 1password's UX problems. I'm a long term user of 1password on Windows and Android and I find the user interface to be incredibly unintuitive. Things that should be simple such as moving passwords and creating new vaults seem needlessly complex to do. The new vault button is in a different place to everything else and at the bottom of the list of vaults. For me, it's one of my least favourite apps to use.
1Password is going after the enterprise market, and an Electron app makes it easier for them to support multiple platforms as well as chasing that market.
https://support.1password.com/secrets-automation/
https://support.1password.com/events-reporting-splunk/
https://support.1password.com/secrets-automation/
https://support.1password.com/events-reporting-splunk/
For some products wide platform support may be more valuable than what simple metrics show.
Why? Core utilities such as file sharing and password management simply need to work all my devices. If I have to use one password manager on Mac and another on Linux, there is no point in having a password manager. It gets even more absurd with file sharing. Should I use iCloud on Mac, and OneDrive on Windows, and Samba for the Linux machine? Absolutely not! Dropbox is the clear winner as it supports all three platforms. I'm an Office 365 customer, and yet I have no use for OneDrive, since there is no reliable first-party Linux client. After getting burnt with a flaky third-party OneDrive Linux client I decided to fork over money for Dropbox.
For products like Dropbox or KeePass wide platform support has wider impact than number of computers connected from that platform. In an organization with 3 people on Linux and everyone else on Windows, support for both platforms is a strong differentiator over competing products.
Why? Core utilities such as file sharing and password management simply need to work all my devices. If I have to use one password manager on Mac and another on Linux, there is no point in having a password manager. It gets even more absurd with file sharing. Should I use iCloud on Mac, and OneDrive on Windows, and Samba for the Linux machine? Absolutely not! Dropbox is the clear winner as it supports all three platforms. I'm an Office 365 customer, and yet I have no use for OneDrive, since there is no reliable first-party Linux client. After getting burnt with a flaky third-party OneDrive Linux client I decided to fork over money for Dropbox.
For products like Dropbox or KeePass wide platform support has wider impact than number of computers connected from that platform. In an organization with 3 people on Linux and everyone else on Windows, support for both platforms is a strong differentiator over competing products.
I wish they'd just offer the great current Mac app. It's there, it's fully functional and works great.
This really is a shame. Electron apps are slowly becoming the bane of my existence. 1Password was the only native thing I still used somehow. Android Studio and Terminal are only other non-Chrome/Electron things I use. Even with 64GB of RAM it's a pain. The rendering of everything just gets slow if you have too much open on a high res monitor. Bleh.
This really is a shame. Electron apps are slowly becoming the bane of my existence. 1Password was the only native thing I still used somehow. Android Studio and Terminal are only other non-Chrome/Electron things I use. Even with 64GB of RAM it's a pain. The rendering of everything just gets slow if you have too much open on a high res monitor. Bleh.
Electron is fine. While you find it "offensive" when an app "fails to behave like proper, 'native' apps on whatever platform they operate", I find it offensive when those various platforms create the expectation that apps should behave differently on their platform (and people blindly follow that).
(maybe offensive is too strong word... but I think it is not a positive)
Can you imagine if the various browsers ... Firefox, Chrome, Safari, ... had the expectation that web pages would be custom tailored to behave differently in their browser? Even worse, what if they expected you to code them from scratch, poosibly in a different language, just so they could be optimal? Would that be a positive?
Or how about if different car makers thought that in all cars of their brand, the turn signal or gear shifter must be in a special position, just to differentiate the look and feel of the cars from that of other car makers? How would that be a positive for drivers?
To me, we are past the point where it should feel different to be on a different platform. I go back and forth between Windows and Mac all the time, and apps that behave identically (or nearly identically) on both are my favorites. Visual Studio Code, while far from perfect (but certainly better than the last editor I used, which was native), works identically on all of them and I like that.
The desire for things to "feel native to the platform" seems to be either 1) something that comes from the platform makers themselves, for marketing reasons, or 2) simple tribal thinking.
Electron isn't perfect (I wish it didn't require downloading an entire browser engine, but simply used the one that is already installed), but the more apps that use it, the better it will get. Browser engines themselves are getting really really good, which means that many of these electron apps can also run as a simple web page for those that don't want to install them.... and again, they work the same, which is a big plus.
(maybe offensive is too strong word... but I think it is not a positive)
Can you imagine if the various browsers ... Firefox, Chrome, Safari, ... had the expectation that web pages would be custom tailored to behave differently in their browser? Even worse, what if they expected you to code them from scratch, poosibly in a different language, just so they could be optimal? Would that be a positive?
Or how about if different car makers thought that in all cars of their brand, the turn signal or gear shifter must be in a special position, just to differentiate the look and feel of the cars from that of other car makers? How would that be a positive for drivers?
To me, we are past the point where it should feel different to be on a different platform. I go back and forth between Windows and Mac all the time, and apps that behave identically (or nearly identically) on both are my favorites. Visual Studio Code, while far from perfect (but certainly better than the last editor I used, which was native), works identically on all of them and I like that.
The desire for things to "feel native to the platform" seems to be either 1) something that comes from the platform makers themselves, for marketing reasons, or 2) simple tribal thinking.
Electron isn't perfect (I wish it didn't require downloading an entire browser engine, but simply used the one that is already installed), but the more apps that use it, the better it will get. Browser engines themselves are getting really really good, which means that many of these electron apps can also run as a simple web page for those that don't want to install them.... and again, they work the same, which is a big plus.
Well, OK then. Time to get something else and stop paying that subscription fee.
I made the jump to self hosted Bitwarden and not missing 1P. But what really made me switch was Dropbox (I had my vault there and they limited the amount of linked devices to 3 on the free accounts).
I still don't understand what people's hate for electron is. As someone who uses Windows, Linux and on occasion a mac it generally means you get a fairly consistent experience across all platforms and often it also means the linux version doesn't actually suck or you actually get linux support in the first place. Which is always a big plus for me.
Also I feel like the performance is decent at this point. For a fully featured app the difference to other frameworks is not that large any more.
Also I feel like the performance is decent at this point. For a fully featured app the difference to other frameworks is not that large any more.
I'm sure it's great for someone who uses multiple platforms. But if you use only one platform, the apps will feel off.
As for performance: it's not horrible, but the memory usage is.
As for performance: it's not horrible, but the memory usage is.
Recently switched to VSCode from Jetbrains IDEs on MacBook Air M1, amazed at how much faster my editor boots up, and generally also more responsive. Haven't noticed any memory issues either, I only have 8GB RAM
Just when you thought the cycle of slower software gobbling up the gains of faster CPUs couldn't possibly continue forever...
Maybe, but I regularly go two days on battery now. That's something I've never experienced with a laptop before. Notwithstanding inefficient software
How recently? If you installed IntelliJ during 2020 it didn't have native ARM support yet[1], and had to be reinstalled to get it, so it would have been running in emulation.
[1] https://blog.jetbrains.com/idea/2020/12/intellij-idea-2020-3...
[1] https://blog.jetbrains.com/idea/2020/12/intellij-idea-2020-3...
I was using the ARM version, by slow I mean I can see the splash screen for a couple of seconds. Whereas VSCode starts up instantly. I've got `alias c='code .'`, typically I open the editor from iTerm2 the same way I would use vi. IntelliJ is still more advanced in many ways. I guess the point I was trying to make is that Electron looks like a better platform for cross platform apps compared to JVM.
Also, many NeoVim plugins are using component from VSCode, and the other way around.
Also, many NeoVim plugins are using component from VSCode, and the other way around.
I’ve got two macs, one from 2016 with 8gb of ram. Running a single electron app on that computer results in the rest of the system becoming totally unresponsive making any sort of multitasking impossible.
It's generally just a tiny portion of hard core Mac fans. The vast, vast majority of users (most of which use Windows) doesn't care at all.
>As someone who uses Windows, Linux
Yeah, your tolerance for inconsistent UX is much higher than longtime macOS users.
Yeah, your tolerance for inconsistent UX is much higher than longtime macOS users.
Mac has lots and lots of inconsistencies too. Some apps, like Music.app, is also pretty much an Apple version of electron. The inconsistencies aren't better on Mac, just different ones.
Long time macOS users haven't tolerated Music.app well either.
I'm disappointed that this article doesn't mention any specific performance problems. Sure, Electron can be slower than a native app, and less secure too. But the core functionality of 1Password's UI is pretty basic. Is there any perceptual difference in performance? Or any concerning compromise in security? If not, then this complaint is purely ideological.
> If you can’t move the preferences window because it’s fake, you might be running an Electron app
Funny. Because by that definition Mac OS's preference app is an Electron app. Go to Keyboard -> Modifier keys. Opens a dialog window that cannot be moved.
Funny. Because by that definition Mac OS's preference app is an Electron app. Go to Keyboard -> Modifier keys. Opens a dialog window that cannot be moved.
macOS used to present that modifier keys dialog as a sheet, visibly attached to the parent window and not in any way shaped or decorated like an independent window, so there were no false signals indicating that it might not be a modal dialog box. The newer trend of shadowing everything except the modal dialog does a better job of indicating that the main window content is temporarily unavailable for interaction, but making the dialog itself appear but not function like a separate window is a step backwards in usability.
(And of course, modal dialog boxes of all kinds are used far more often than they should be. They're not always the wrong choice, but more often than not they're a symptom of poorly thought-out UI design.)
(And of course, modal dialog boxes of all kinds are used far more often than they should be. They're not always the wrong choice, but more often than not they're a symptom of poorly thought-out UI design.)
"you might be" does not mean "you are"
Why would anyone want a password manager to have a desktop app at all? I use Bitwarden on the desktop exclusively through the Firefox extension – nearly all the time specifically through the tiny popover window in the corner of the browser. Can't say I ever want it to have more UI.
We store a lot more than just passwords in there. Credit Card Numbers, RSA/ED25519 keys, and it even connects to our Azure Key Vaults. Having a full non-browser UX is advantageous.
I store things like security questions along with the username/password for a specific site.
1Password for Mac Moving to Electron – https://news.ycombinator.com/item?id=28143563 (174 points/193 comments)
1Password 8 will be subscription only and won’t support local vaults – https://news.ycombinator.com/item?id=28145247 (569 points/661 comments)
1password is considering a self-hosted option to store vaults – https://news.ycombinator.com/item?id=28104134 (296 points/223 comments)