Hi. I'm a feature developer for 1Password, and I want to clarify a few things. I've already posted this elsewhere, but I've seen multiple threads spreading misinformation that our technical decisions are being driven by VC funding. This could not be farther from the truth. We have been working on these changes long before we received any form of outside investments.
Over the past few years, we've been working on consolidating 1Password's business logic into a single Rust-powered core that could be shared across all our apps. This has many advantages: feature consistency across platforms, faster development cycles, and better security. When building the front-end for the desktop platforms that would take advantage of this new core, Electron suited us perfectly, since we could write our UI code once and make it consistent across Linux, Windows, and Mac. We actually did build a native Mac app initially alongside the cross-platform Electron app, but we eventually decided that having two separate versions of the macOS app (one in Electron, one in SwiftUI) would cause a lot of needless development churn and hassle for both customers and our support team.
I can understand your frustrations about Electron and our subscription-based model, but I hope you find my explanation reasonable. Please stop spreading misinformation.
Hi, long-time user, customer, and word-of-mouth recommender of 1Password for the nine years my Hacker News account has been active (give or take a few months). This is a big announcement that I'll have to chew on to understand what this means.
Can you quantify the "needless development churn and hassle for both customers and our support team" in some way? Presumably, 1Password 7 and its ancestors used native macOS APIs, which meant some degree of that given you had to do something different on Windows and/or Linux. I don't know what your support team has had to endure, but as a long-time sample size of 1, I've been incredibly satisfied with the way you've designed and engineered the macOS application (and the iOS app too!) to date; I'd be hopeful that whatever tradeoffs y'all will be making moving to Electron, the "native" feel of the macOS client wouldn't be sacrificed. Is there anything you can speak to there that I should prepare for with 1Password 8?
> Can you quantify the "needless development churn and hassle for both customers and our support team" in some way?
Sure, happy to elaborate on that! Since we were rebuilding our app from the ground up, it was a significant slow-down on development to create a user interface for both Electron and SwiftUI, requiring two separate teams of platform developers for every feature we needed to implement. There were also concerns by the documentation and support teams that we would need two separate sets of instructions for many common tasks, due to small differences in layout and look between the applications. Eventually, we had to make the tough decision to focus on a single common framework for desktop. This will allow us to ship features across every single platform far quicker than we could before.
> I'd be hopeful that whatever tradeoffs y'all will be making moving to Electron, the "native" feel of the macOS client wouldn't be sacrificed.
We've tried our very best to keep the experience the same so that the transition from 7 to 8 is smooth, and from my point of view 1Password 8 feels right at home on macOS - I especially love our new translucent sidebar. That being said, this is still in an early access stage, so there are bound to be hiccups and UI issues that need to be resolved. Please let us know if you run into any problems or have suggestions on how we can improve. And thank you for being a long-time user!
This is such nonsense that I can't let it go unremarked. I can count on the fingers of zero hands the number of times 1Password has shipped a "new feature" between major releases. There are no new features needed, it's a password manager. However, I would need to borrow some extra hands to count the number of features you've removed, features that loyal paying customers of many years depend on. 1P7 doesn't even let you keyboard navigate to the Generate Password button for goodness sake - something that I was able to do in every version up to that point.
Absolutely nothing about any decision AgileBits has made in the last 4 years has had anything to do with what customers (that's us, the people that used to give you money) want, and everything to do with nickle and diming the suckers dry.
UI consistency between different operating systems is NOT a user-focussed feature. When I'm on a Mac, I want my apps to behave like a Mac app. When I'm on Linux, I want my apps to behave like a Linux app. If you _actually_ believed that all apps should look and behave the same on any OS, why does the Android version look and behave nothing like the Mac app?
You've removed features with every major release, and this is just smashing the final nail into 1Password's coffin. You've ruined what used to be the best password manager on any platform.
I mean looking at this I can see why people came to the conclusion that this was primarily a move that VC funding caused even though AgileBits seem to vehemently deny this.
The funny thing is, they were doing just fine for years with just their own money. Now that they have sooo much more money, they suddenly can't afford separate developers for different platforms... they should be able to hire 10x more people now.
The primary issue with having two separate teams for the same platform was not money, it was time. To be clear: we wanted to build a native app in parallel with our cross-platform Electron solution, and we had the developers to do it. But unfortunately, having an additional team that needed to implement the UI for every single new feature was a significant slow-down, and we collectively realized that we could not meet our deadlines nor maintain this long term.
I'm sorry for not being more clear earlier as to why we couldn't support two separate teams for the same platform. Hopefully this clears up any confusion.
I don’t understand why two teams means slower. Are you keeping the total number of engineers the same? If you are saying 2x engineers on electron complete tasks faster than 1x on electron and 1x on native, you are basically agreeing with OPs take.
You take money to provide software. But then you become lazy and greedy and want 1 size fits all. End result is your users having clunky, high latency experience.
I think he’s saying 1x on both Electron and Swift UI was making it too hard to ship either version to an acceptable standard because each was slowing the other down due to inconsistencies, difficulty staying in parity and double communication.
Unfortunately, it’s normal in software development for multiple platforms to increase development complexity when feature and UX parity is prioritized.
Maybe I'm missing something, but i pay for those teams with my client purchases. I have a mixed computing environment and have purchased versions 3, 4, 5, 6 & 7 for three platforms.
I'd like to believe this isn't primarily profit motive. What gives me pause is how I write regularly asking for separate vaults for trivial passwords and passwords that could lead to financial ruin. The profit motive wants to keep 1Password simple to use, at the expense of security. I've been forced to buy a second password manager for sensitive passwords.
I'm sorry you feel that way. I'd love to know more about your issues with our current vault implementation in more detail, so I can pass along your feedback to the rest of the development team.
> What gives me pause is how I write regularly asking for separate vaults for trivial passwords and passwords that could lead to financial ruin.
Just to clarify, what solution are you asking for? Do you want a local vault option to store sensitive passwords? Or something else?
I am very unhappy that 1P is moving to Electron for macOS for the reasons people here have reiterated a million times. I am actively looking for alternatives now.
As much as I'm "meh" on Electron, I rarely use the actual 1Password App. On the other hand, I use the Firefox extension 30+ times a day, and that's about as far from a native app as you can get. So I think I'm fairly unlikely to notice a huge issue, and will instead be pleased that consolidating on Electron gives them greater feature velocity.
On the other side, I use the 1Password app extensively and make heavy use of all the different categories (secure notes, Windows MSDN licenses, etc). I’m extremely disappointed to see this turn into yet another sub-native browser-in-a-window experience.
You'd get rid of a working solution because of an implementation decision? I _love_ 1P, and I use it on Mac, Windows, Linux, and iOS, and it makes perfect sense that they standardize on Electron.
> You'd get rid of a working solution because of an implementation decision?
Yes, because the implementation decision has implications for both performance and UX. I’ve used 1Password since version 3 (2013!) and gotten friends and family to do the same, but I think I’m done when 7 stops working.
> I've already posted this elsewhere, but I'm seeing some misinformation that our technical decisions are being driven by VC funding. This could not be farther from the truth. We have been working on these changes long before we received any form of outside investments.
That's worse, not better.
At least being forced to by investors makes sense. The current direction of travel being voluntary means you've just got a bad nose for building security.
>would cause a lot of needless development churn and hassle
The hassle of doing what your users are paying you to do? Any child can hack a UI together in HTML but there's a reason no one (usually) pays for that.
Over the past few years, we've been working on consolidating 1Password's business logic into a single Rust-powered core that could be shared across all our apps. This has many advantages: feature consistency across platforms, faster development cycles, and better security. When building the front-end for the desktop platforms that would take advantage of this new core, Electron suited us perfectly, since we could write our UI code once and make it consistent across Linux, Windows, and Mac. We actually did build a native Mac app initially alongside the cross-platform Electron app, but we eventually decided that having two separate versions of the macOS app (one in Electron, one in SwiftUI) would cause a lot of needless development churn and hassle for both customers and our support team.
I can understand your frustrations about Electron and our subscription-based model, but I hope you find my explanation reasonable. Please stop spreading misinformation.