Why not move to Catalyst?
At this point, it is pretty obvious that the community is not responding well to the move to Electron on the desktop side of things. I for one won’t even use VSCode because I can’t stand how it feels. I’ll also be staying on v7 for as long as possible. One thing I haven’t seen is reasoning for not using Catalyst for v8.
I understand the difficulty of maintaining 5 different code bases (Linux, Windows, macOS, iOS, and Android), but I truly do not think Electron is the way to go. macOS is where 1Password started and is most likely where most customers come from. As has already been said, the entire backend of the app is written in Rust. SwiftUI apparently didn’t do what it needed to. However, a native iOS app already exists that does work (and quite well) which could hook into that same Rust code.
I’m not going to explain what Catalyst is here, but it would take that same native experience found on iOS and move it to the Mac. Work would be required to make it run properly, but the main part of the code already exists.
There were serious issues with Catalyst in macOS 10.14. 10.15 improved it. 11.0 made it very usable as has been demonstrated many times. This would require dropping support for older OS’s (or working around issues on 10.14/10.15), however v7 already only targets back to 10.13. Most Mac users rapidly update anyways, and would likely take the minimum version requirement in stride.
I think it’s unfair to ask Agile Bits to write 3 native desktop apps. However, providing a significantly degraded experience to the majority of Mac users isn’t what anyone wants, especially when code already exists that could run on macOS. Plus, any new work done to improve the Mac app would likely improve the iPad app as well.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Comments
-
https://www.cultofmac.com/750203/dashlane-macos-password-manager-native-mac-catalyst-app/
News that just got released
0 -
Thank you for the link, @alex_taffe.
I think it is a good opportunity to compare them and see which one feels at home on Mac.
Off the top of my head, there are a few issues with Catalyst. I am not sure it is possible to implement all features that we want to see in 1Password 8: global keyboard shortcuts, Quick Access, launch services integration, native messaging to keep all browser extensions locked and unlocked with 1Password main app.
If you have a minute, try to compare both "very first alpha build" of 1Password 8 and a "release" of Dashlane catalyst app. I'd love to see what you think!
0 -
For example, we got a lot of people upset about the new look of the Preferences window in 1Password 8. Here is how it looks in Dashlane:
We spent the last 2 years trying to get the best user experience in 1Password 8. If anything, this screenshot looks to me like the laziest approach to developing Mac apps.
0 -
@roustem
You saytry to compare both "very first alpha build" of 1Password 8
Do you regard the current early access version of 1PW8 as a very first alpha build?
As someone said in another thread, "early access" can mean anything from an early alpha build to a pre-release that is coming out of beta. very soon. I don't think users are clear as to which 1PW8 is at present.
I think many of the objection vanish if this is the very first alpha build. In that case there is plenty of time for improvements, and even for a change to the UI.
Electron lets users on an older OS use 1PW8, so it should probably be kept as one option. Does SwiftUI not currently provide the needed functionality on newer OS versions? If so, is that likely to change? It does seem that abandoning Electron as far as newer OS version are concerned would be the best option, particularly if Swift UI works.
0 -
We spent the last 2 years trying to get the best user experience in 1Password 8.
Should have stuck with a native app, you might have succeeded.
0 -
@roustem It's true, preferences/settings dialogues are one of the big areas in which many Catalyst apps seem to fall short on OS X! But the various built-in MacOS apps that use Catalyst, like Messages, all manage to have a proper preferences window; also, Steve Troughton-Smith has put out some amazing examples of how he's been able to leverage various aspects of the Catalyst APIs in order to sand off various rough edges and to get things working in a platform-appropriate way. I'm not saying that it's necessarily ideal or simple, from an engineering standpoint, but then neither is the Electron-based path.
So yeah, lazy Catalyst development would also result in just as sub-par a MacOS experience as lazy Electron development- and you guys are not doing lazy Electron development. That much is clear- you really are trying to make it fit in with the OS. But I really do wonder:
a) how the amount of work involved in going from "lazy Catalyst" to "good Catalyst" compares to the amount of work you're having to do in order to go from "lazy Electron" to "good Electron"; and
b) whether the theoretical ceiling of "Mac-like-ness" is higher for Catalyst than it is for Electron.And that's not getting into resource usage, security, etc. Of course, this is just more "Monday-morning quarterbacking" from somebody who wasn't involved in the process at all! Just my $0.02. :-)
0 -
@roustem I disagree. Dashlane in specific didn’t take much time to make it more of a native Mac app. However, it is fully possible to inject AppKit where necessary to bring real settings windows, native messaging, etc. Steve Troughton-Smith has made this pretty evident over the past few years. Not only that, just take a look at iMessage on macOS Big Sur, unless you knew, you would think it’s a native AppKit app. No one has ever said the same of an Electron app.
0
