Not important enough: 1Password abandons its native Mac app(sixcolors.com) |
Not important enough: 1Password abandons its native Mac app(sixcolors.com) |
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)
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.
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.
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.
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).
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 still have sympathy for AgileBits, but these feelings have diminished somewhat now.
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?
Does it work with other browsers on the Mac?
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.
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.
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.
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.
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.
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.
That was mistake number 1.
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?
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).
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.
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...
That’s a good lesson. Extend deadlines if necessary. Use old boring technologies. Don’t surprise users with unnecessary changes. Is it so hard.
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.
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.
(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.
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.
As for performance: it's not horrible, but the memory usage is.
[1] https://blog.jetbrains.com/idea/2020/12/intellij-idea-2020-3...
Yeah, your tolerance for inconsistent UX is much higher than longtime macOS users.
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.
(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.)
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.
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.
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.
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 frustrating not being able to develop something for the 3 oses i use at once (windows, linux, android)
They've released a cross-platform Chrome extension, plus a native Windows client. No Firefox as far as I'm aware, sadly.
Also, many NeoVim plugins are using component from VSCode, and the other way around.
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.
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.
I can hear the AgileBits marketing department theme song / threnody... https://youtu.be/9yQKDj_V4Gk
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.
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.
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.
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.
It doesn’t take a lot of effort to switch password manager, there’s no significant lock-in.
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.
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.