Dave Teare (tweet, MacRumors, Reddit):
Categories now sit atop your item list as a simple dropdown filter, giving the sidebar plenty of room to show all your vaults and their accounts.
You’ll also notice an indicator next to each shared vault, making it easier to see which vaults are private and which are shared. No guesswork. And items show who they’re being shared with.
Throughout the app you’re in more control, with more contextual information available at all times. Try dragging-and-dropping an item from a personal vault to a shared vault. When you do, 1Password will show you who will gain access to the item so there’s no doubt about what’s happening.
[…]
I personally use Collections to hide family vaults that I only need access to in case of emergency and don’t want to see every day. It’s also great for hiding production work accounts until I explicitly require them.
[…]
[The] next generation of 1Password gives you more power to recover data, starting with item drafts, the ability to restore recently deleted items, as well as being able to revert to previous versions of an item.
Dave Teare (tweet):
What makes this [Linux] release even more amazing is it was created from scratch and developed using new languages and techniques most of our team never used before.
[…]
The backend is written in Rust, a true systems programming language known for its safety and performance. Rust compiles directly to native code and avoids the overhead associated with runtimes or garbage collection.
On the frontend side of things we used web technologies to allow us to create an entirely new design language for 1Password.
The new Mac app uses Electron, too, as you can immediately see from how the fonts and controls look. A two-person team can write a native AppKit app, but a team of 473 starting with a mature AppKit codebase has other priorities.
bgentry (also: Miguel de Icaza):
The most disturbing part about this is that their support team has been misleading people on Twitter all morning, not truthfully answering straightforward questions about whether the app is Electron
The language and compilation status of the backend are not relevant to whether the frontend is native.
Curtis Herbert (Hacker News):
The blog post screenshot had me all “yay, looks like it matches the new sidebar style in macOS, wonder if it is Catalyst or SwiftUI?”, then I opened the preference “window” … which is an Electron-style modal inside the main window.
Ben:
To minimize file size and maximize performance, we’re offering separate Apple silicon and Intel builds.
A hallmark of Electron.
Of course, you can see why a company would want a cross-platform solution to reduce the number of codebases that need to be developed and kept in sync. It’s interesting that, even though there’s already an iOS version, they decided not to go with Catalyst. As to Apple’s other cross-platform technology…
Roustem Karimov:
We have a large Apple dev team and had a parallel SwiftUI codebase being developed for about 6 months. It had some advantages but overall it underperformed on macOS and the UX was worse.
recursion_is_fun:
What’s more concerning is the shortcut change. ⌘\ is deep in my muscle memory, but more importantly it’s in my (less tech savvy) family’s muscle memory. I strongly urge you to consider retaining the default shortcut bindings in the final release.
Dave Teare:
1Password 8 has a new Quick Access feature that’s activated by ⌘⇧Space and supports Go & Fill.
Dave Teare (Hacker News):
Even though memberships won by a long shot, our existing apps already supported both so we continued to offer standalone licenses. This included support as well as new features and updates for license holders.
In our new apps, however, we needed to revisit this approach…
[…]
We’d like to thank you for supporting us all these years and provide a special trade-in discount for your license. Simply email us your license and enjoy 50% off your first 3 years.
The new version drops non-subscription licenses, standalone vaults, and support for Dropbox, iCloud, 1Password mini, and 1PasswordAnywhere.
I’m not sure what I’ll do from here. I’ve been using PasswordWallet myself since the writing was on the wall for standalone vaults and my favorite feature in 2017. But the rest of my family is still on 1Password/Dropbox. Much as I don’t like these changes, I’m not sure there’s a multi-user product that’s better.
Ricky Mondello:
No matter what anyone else does with their offerings, iOS and macOS have a built-in, free password manager. I love our new, Mac-native interface in macOS Monterey, which has clear, helpful security recommendations (including breach warnings!) and a verification code generator. :)
This is a temping option because it’s fully integrated and built on iCloud Keychain. Although it’s not inherently multi-user, you can configure a single Mac with separate accounts for different users.
Previously:
Update (2021-08-13): Kristoffer Forsgren:
Please stay native on macOS! 😬 (no electron)
1Password (in June):
Don’t worry, we’re all about the native apps. ❤️
Rui Carmo:
Having used 1Password since its very beginning, I grew increasingly distrustful of their product management and roadmap (the key point for me being that I will not subscribe to their cloud syncing service), so this is an attempt at putting together a systematic list of decent alternatives for my own use.
Jordan Rose:
[Someone] pointed out that Discord, League of Legends, Docker for Desktop, Epic Games client, and many bits of Steam are “basically Electron”, and we don’t hate them.
But all of those have /awful/ UX on a Mac (except LoL, I don’t know LoL).
I get why Electron is winning (won?). Signal Desktop is Electron too. But macOS had an actual design language and accessibility and interoperability between apps basically for free, and Electron apps lose 90% of that because it’s not how web pages work. So I’m gonna resent it.
(I also blame Apple for not placing value on this in their own apps. I miss Mac-assed Mac apps.)
texec:
This is a big step backwards. No native UI, no local vaults, no wifi sync, shortcuts not modifiable, no (fast) vault switching, quick access is much more restricted and shows less information.
[…]
Oh and the UI is not faster. Only a mess of different font sizes, too much whitespace and indistinguishable buttons :(
Francisco Tolmasky:
I find it really strange that people are way more concerned with
@1password
using Electron than dropping local vaults and going subscription-only. I care way more about owning my passwords that connect me to every service in my life than what framework the app is written in.
Oluseyi Sonaiya:
VC isn’t why 1Password switched to Electron, though. That’s a simplistic conclusion, and I’m someone who is deeply unimpressed by “Tech” VC.
Jeff Johnson:
It’s almost always the little indie devs who have native apps on Mac, iOS, and maybe even Windows and Android, almost always the BigCos who use ugly cross-platform frameworks.
Dominik Wagner:
Apple had the chance to solidify their dev-lead by unifying their situation. E.g. make catalyst really first class and evolve the APIs nicely.
Instead they tried inventing their own language (swift) and make the future dev landscape so confusing people go electron and x-platform.
JF Martin:
I don’t understand a company with a mature codebase built on AppKit since forever, turning to a cross-platform framework like Electron. I mean, it’s not like if they didn’t have a Mac app, right? They do, it’s already supporting Apple silicon too. I guess they didn’t like SwiftUI or Catalyst.
Ilja A. Iwas:
SwiftUI is too little, too late, if prime Mac apps are dropping it in favor of Electron. All the years it took to mature Swift(aka adding fancy language-geek features) might have been spent better elsewhere. Not sure if Apple cares, or what they should have done differently.
Stephan Michels:
All these years where we waited for a common base in AppKit and UIKit. And then we got this abysmal Marzipan thing. With SwiftUI it’s getting better.
Maximilian Mackh:
Downside to Catalyst is the lack of backwards compatibility - it only got really good in 10.15. 1PW probably needs to deploy much further back.
And SwiftUI itself is even rougher prior to macOS 11.
Roustem Karimov:
Seems like a good time to post a link to the presentation that
@mitchchn
did this year at
@NorthSec_io
conference about all the security problems with Electron apps[…]
See also: 1Password Community Discussions, Reddit.
Michael Fey (tweet):
However, with four full stacks of client implementations of our server APIs, any changes needed to be coordinated across four teams. Four teams that were still operating independently. Each time our server team lead would come to the client leads and ask us how long until we could support some new feature, each of us said the same thing: “Now’s not a good time, we’re busy. Maybe in a few weeks?” And that estimate of a few weeks was different for each team. We kept advancing our apps with cool new features, but we weren’t advancing our service-based features. We were paralyzed.
[…]
A small team, using existing pieces of various apps and projects, put together a proof of concept of a brand new 1Password app running on top of what we now call the 1Password Core.
[…]
On April 1st, 2020 we officially put our existing 1Password apps into maintenance mode, opened up our source code editors, and clicked File > New Project… on five new 1Password apps.
[…]
We could support as many versions of macOS as we wanted using Apple’s AppKit framework, but that meant adding another frontend toolkit to the mix. We could go all in on SwiftUI, but that meant reducing the number of operating system versions we could support. We could go all in on the same approach we were using for Linux and Windows, but that made it very difficult to create an app that looked and felt at home on macOS.
Ultimately we decided for a two-prong approach. We would build two Mac apps. One written in SwiftUI that targeted the latest operating systems and another using web UI that allowed us to cover older OSes.
[…]
However with a self-imposed ship date of September 2021, our timeline to bring these apps to stable was starting to look a bit tight.
[…]
Despite the fact that SwiftUI allowed us to share more code than ever between iOS and macOS, we still found ourselves building separate implementations of certain components and sometimes whole features to have them feel at home on their target OS.
Ultimately we made the painful decision to stop work on the SwiftUI Mac app and focus our SwiftUI efforts on iOS, allowing the Electron app to cover all of our supported Mac operating systems.
Steve Troughton-Smith:
This is exactly what I mean when I’ve said going SwiftUI-native leaves you little better off than before, still having to write distinct iOS & Mac apps and dividing your time & resources.
Jason Snell (tweet, Hacker News):
What’s really causing all this consternation, I think, isn’t 1Password moving to Electron. Electron is a bit of a bogeyman. The root problem is this: 1Password, originally a Mac-forward software developer, has simply decided that the Mac isn’t important enough.
[…]
Fey’s post clearly spells out AgileBits’s priorities. Android and iOS apps are built with native platform frameworks in order to create the best app experience possible on mobile. For iOS, AgileBits decided to use Apple’s new SwiftUI framework rather than the venerable UIKit, in order to skate “to where the puck was going.” Their plan was to use SwiftUI on the Mac, too. In doing so, AgileBits was buying into the vision Apple has for SwiftUI as a tool to build interfaces across all of Apple’s platforms. Unfortunately, it seems that SwiftUI didn’t measure up on the Mac[…]
[…]
I find AgileBits’s decision-making process incredibly sad. Because as Fey’s post makes clear, at no point did the company consider keeping the Mac-only version of 1Password alive. AgileBits, once a major Mac developer, decided (for legitimate business reasons, of course) that the Mac’s not a platform that deserves its own bespoke app.
Update (2021-08-18): Roustem Karimov:
I don’t agree with the title. Mac is super important to us, both
@dteare
and I rely on it. I just refuse to believe there is only One True Way of making great apps and everything else should be burned with 🔥
[…]
When we made the decision it was between having a subpar SwiftUI experience (many reasons) or an amazing but (scary!) Electron experience.
AppKit can’t be in the picture, sadly. We don’t want to go back developing 5 different frontends.
Josh Centers:
Apple marketed itself as the privacy company and is confused when customers are mad that they’re scanning photos.
Agilebits marketed itself as making quality native apps and is confused when customers are mad that they’re no longer making native apps.
Simone Manganelli:
If they think Electron is best, don’t have the support team lie to us that they’re native. Don’t say this is good for users. It’s neither. Own the decision.
Mario Guzman:
I was going to take a screenshot to show that
@1Password
8 beta doesn’t respect my “Double click an app’s titlebar to [minimize]” when I realized IT HIJACKS Shift+Cmd+4+Spacebar!
Max Seelemann:
1Password is still gonna be the best, despite going non-native on Mac.
The product is immensely strong - top-notch integration on all platforms, team accounts, shared vaults with access control, file storage, etc. I can even see the technical issues.
I’m just a liddle sad 😢
Drew McCormack:
Have to confess, I didn’t really understand the 1Password VC investment at the time. In hindsight, I missed that it isn’t really a password app anymore, but has pivoted to an account management proxy. In that context it makes much more sense. Clever pivot.
Daniel Jalkut:
Apple’s in a transitional period where it’s not at all obvious which of their THREE competing Mac frameworks any serious developer should choose.
It’s super-obvious to me as a long-time Mac developer that sticking with AppKit is the safe bet right now. But for everybody else, the people who should be flooding the ever-growing Mac customer base with new apps? It’s a shit show.
And yes, having any of your most passionate and experienced developers (i.e. me) choosing the most antiquated of your proposed frameworks is not a great place to be in.
Apple sort of “Osborned” AppKit, and it was probably a mistake.
Steve Troughton-Smith:
I’d add that the 1Password devs are competent, well-known devs who have participated in the native Apple developer community for over a decade. SwiftUI’s inability to back-deploy, something I think Apple should clearly reconsider, left them writing two apps for Mac — one too many
Russell Ivanovic:
Also proves what I’ve suspected for a while: SwiftUI is still writing cross platform cheques that the toolkit can’t quite cash. Especially on macOS.
[…]
The weirdest part of all this is that a stock SwiftUI app (where you don’t write custom UIKit or AppKit bits) feels non native to me
Helge Heß:
I found that part the most weird one, because “Write Once Run Anywhere” was openly communicated as a non-goal for SwiftUI. It was “Learn Once Apply Anywhere”. SwiftUI is not a cross platform framework and Apple was upfront about this part.
Rich Siegel:
Whether that meant speed, or compactness, or both. Because it mattered. It still does[…] So, when I download an app that I and a lot of my peers use in the ordinary course of getting work done, and I get info on it, and I see that it’s 180MB (Discord), or 400MB (Dropbox), or 200MB (Slack), or 280MB (Skype), and I know it’s a front-end to a web service, well honestly, I cringe, every time.
[…]
I am firmly of the opinion that “cross platform” means that users of each (desktop) platform that the product supports can enjoy a platform-optimized experience which is tuned in both performance/efficiency and UI behavior for the desktop platform on which it is running.
[…]
To me, a successful cross-platform product consists of three layers:
- The high-level UI/UX: platform-tuned, natively implemented using the platform-provided native framework.
- The “business logic” which is platform-portable by design and intent, and which implements the non-user-facing parts of the product’s feature set;
- The bare-metal interface between the business logic and the platform services (file I/O, networking, etc). As with #1 this is platform-tuned and natively implemented using code that is optimized to be as fast and as efficient as possible.
[…]
There’s no reason to buy a Mac if you don’t get to use the unique advantages of the platform (because Electron apps don’t expose them).
Rick Schaut:
As someone who hasn’t forgotten Mac Word 6, I wholly endorse this thread. There are a couple of things I would say differently. His “three layers,” for example. I talk about sandwiches. The OS is two slices of bread; your app is the meat, lettuce and tomato in between.
Erik Schwiebert:
Something like 80% of the size of the Office suite is due to the fact that we can no longer share common elements between related apps. All frameworks, fonts, proofing tools, must be duplicated N times for N apps. Not to mention being required to ship fat^H^H^Huniversal binaries.
And all that is due to policy.
Colin Cornaby:
So, in since I dabble in a lot of cross platform stuff, here’s my thread on all these cross platform framework things going on.
[…]
Management thinks these things look great. In a few weeks you go from nothing to a minimum-viable-product that runs everywhere! Amazing! Why would anyone ever do native development! These frameworks are so fast and economical! It’s amazing!
[…]
So the problem really is that teams can make amazing initial progress, and then have the cross platform tooling work against them more and more as the product grows. This cost isn’t obvious, and typically goes unmeasured by stakeholders who pushed cross platform to begin with.
Thaddeus Ternes:
Without a public platform roadmap that articulates where they’re going, UI toolkit decisions and development time become large risks for businesses.
On Apple platforms, new toolkit features are almost never back-ported. You concede platform capabilities by choosing to support older OSes. When you choose newer toolkits, target audience is limited, and you’re beholden to the grinding annual cadence of surprise changes.
If you choose Electron, you get support for old OSes, modern features, and a clear roadmap of what’s going to be supported when. Businesses need that predictability.
Electron is effectively a means to mitigate development risk (a service quite a few vendors have made good money on for decades).
One might argue that Apple is effectively forcing businesses to use Electron because of their secrecy.
Francisco Tolmasky:
I think the history of tabs serves as a fascinating case study of how Apple’s neglect for its own UI frameworks assisted the rise and acceptance of cross-platform frameworks like
@electronjs
and the corresponding decline in the importance of “nativeness” and “the HIG”.
[…]
Although Apple had shipped tabs in Safari, developers were left to their own devices to figure out tabs for the individual apps. Critically, this was true both in terms of implementation and behavior. With no AppKit component, there was no strong Apple direction for tabs.
[…]
Apple did eventually end up adding an API for tabs to AppKit, but not until 2017, 12 years after they shipped their first tabs in Safari! By that point, it was more of a pain to convert legacy code than anything, and it wasn’t helped by a woeful lack of documentation.
For a long time, the best resource on how to use AppKit’s tabs was a single WWDC video. And of course, being new, it lacked many of the features existing apps had already implemented. It was too late, now it was a “chore,” not a “feature”, and with little perceived benefit.
What’s important here is that there are two critical components in achieving a consistent OS: the vendor must offer both a strong vision of how things should work, and also provide an easy avenue for making things work that way. Apple has been failing at both on the Mac.
Adam Wiggins:
Developers end up choosing Electron partially because the Mac’s vendor isn’t offering up leadership on how or why you should build native apps for the platform.
Nick Heer:
Years ago, when I was a 1Password user, I remember it being among my favourite apps to use. Who knew that something as boring as a password manager could be fun and beautiful? If a company like 1Password feels like the Mac can share an Electron app with Windows and Linux, that seems like a concerning state of affairs.
[…]
The fact of the matter is that there has never been a good cross-platform framework — not when developers only had to worry about Windows and Mac OS X, and not now when they are trying to cover at least twice as many operating systems. Apple’s attempts — SwiftUI and Catalyst, the latter of which 1Password’s Fey does not mention — have not corrected that problem, and they only cover half of the platforms developers commonly support. When even premiere Mac developers think Electron is the best option they have, it makes me worried.
Colin Cornaby:
I just realized while others are moving to Electron, Apple released a native password manager for Windows [iCloud Keychain Password Manager]
See also:
Update (2021-08-21): Matt Birchler:
All of those are great native Mac apps, but they’re using custom UI elements all over the place. Things has custom everything, Reeder has an iPad-style interface, Craft’s preferences window does not follow macOS conventions, and iStat Menus has some native-ish things with plenty of custom stuff too.
On this week’s ATP episode, Casey Liss referred to 1Password 7 as a “Mac-assed Mac app,” but what part of this UI is using Mac conventions or stock UI? It’s all custom (something Marco did mention).
There are really two different levels here: using a native API and using native (vs. custom) controls and behaviors. Personally, I dislike a lot of the custom stuff, even in apps like 1Password 6 and iStat Menus that are overall good apps. Reeder, to me, looks and feels alien on macOS.
See also: TidBITS Talk.
Update (2021-09-07): Core Intuition (tweet):
Daniel and Manton talk about 1Password’s decision to use Electron for its next major update, and what that says about Apple’s confusing and conflicting platform frameworks. They talk about the continuing role of AppKit as a the only way to achieve many expected macOS behaviors, and wonder if the next-generation standard for desktop apps might actually be a “web technology.”
1Password App Subscriptions Apple Password Manager Catalyst (Marzipan) Cocoa Electron iOS iOS 14 iOS App Keyboard Shortcuts Mac Mac App macOS 11.0 Big Sur macOS 12 Monterey Passwords Rust Programming Language SwiftUI Top Posts
