Meta update

Since the summer time I’ve been a little up and down in terms of posting frequency. It seems like I do tend to post in bursts, sometimes having a streak of several days, only for this blog to go quiet.

I don’t think that’s necessarily a bad thing; I don’t think anyone actually is manually visiting the site to check for new stuff; if you’re interested, you’re subscribed somehow.

I write when I feel like I’ve got something to say, and I’ll usually queue it up to avoid clusters of posts.

I’ve had a bunch of Apple-centric posts lately, and that’s not even counting a handful I left as drafts. The company is huge; I could make entire blogs covering just specific topics of theirs. Plus, I’ve followed Apple for years, so I have a lot of context which allows me to make connections.

But this isn’t an Apple blog; it’s a blog about stuff I want to talk about, and I think Apple’s overrepresented here.

I continue to aim to have 100 posts by the end of this year. Some topics I want to explore:

  • How I got into urban planning YouTube and how cool that is
  • The radical utopian kinds of thinking I want to see in society
  • More on fasting mimicking diets (I’m starting to do them every month or so now)
  • Cooking (I’m gonna do the anti-recipe blog posts where I just tell the story but never actually get to the recipe, but I will work that much harder to make the writing entertaining)
  • Probably more Apple shit
  • The future of office work (particularly, remote work)
  • Good work culture (specifically for teams that are making software)

Digital Surveillance Isn’t an Inevitability

Last week, Apple announced that they are hitting pause on their initiative to implement a surveillance system to add software to users’ iPhones to perform client-side scanning for CSAM. Here’s hoping that the “pause” is mostly just Apple PR trying to save face and that they ultimately are going to quietly scrap the plans.

I continue to be disappointed in the lack of privacy advocacy among the tech press. An example from Nick Heer, of Pixel Envy

If you think Apple lacks the backbone to resist political pressure for expanding the CSAM matching database, you definitely cannot hope for wholly encrypted iCloud storage without any way of detecting abuse.

Why the hell shouldn’t we? Apple themselves know that when you create a tool that pokes a hole in a system that protects privacy, it’s hard not to abuse that. That’s the entire reason they refused to build a custom iOS image for the FBI to guess the San Bernardino suspect’s iPhone passcode. They knew the mere existence of that tool was dangerous because it would get abused. And now they’ve gone and built a tool that is just as abuse prone, they added extra steps of obfuscation to try to justify, and they are rolling it out on a scale several orders of magnitude larger than the San Bernardino suspect’s FBI request would have been.

On a similar note, I don’t know why this narrative has come up with tech journalists recently that we are going to get encrypted iCloud storage as some kind of exchange for CSAM monitoring. Sure, maybe there’s some tea leaf reading going on in there, but Apple has given no indication that they are building encrypted iCloud storage, and if they were and if they had any sense, they’d announce these both as a pair of features.

And even if we were being offered iCloud encryption with the caveat that your phone will monitor your content, that’s a fucking stupid tradeoff and it’s ridiculous that the tech press keeps telling the public it’s only fair we make that trade off.

When computers shipped with floppy disks there wasn’t an “abuse detection” mechanism on them.

The files stored on my hard drive aren’t subject to this. My hard drive is, in fact, fully encrypted at rest and I am the only person with the key.

The files on my hard drive are mine and mine alone. The photos in my photo library are mine and mine alone. The fact that an offsite server is involved doesn’t change that entitlement to privacy. We don’t casually allow police to thumb through our personal possessions in our homes on the off chance we’re doing something illegal. If a person (government or private) tried to enter every person’s home and demand to look through their photo albums, but with the reassurance that the person was only looking for CSAM, we’d be creeped out and we wouldn’t allow it. Why, then, should we allow it to happen to our digital photo albums in our digital homes?

I’ve said it before, and I’ll say it a million times: when you try to frame mass surveillance as something that’s inevitable, you’re just serving to make an invasion of your privacy look reasonable because “obviously we have to do something.” That is a false framing. Always has been.


OnlyFans and the Cautionary Tale of Scale

an illustration of porn being banned using emoji
It’s hard to look at OnlyFans’s announcement yesterday of their upcoming ban on sexually explicit content without seeing where scale, and companies’ pursuit of scale, played a part in seriously disrupting a lot of creators’ lives.

Follow the Money

First, and probably most pertinent, there’s the issue of credit card processors. There are only a couple, and they are massive. Because a substantial percentage of all internet commerce flows through them, processors like Visa and MasterCard are de facto governments, but without the accountability to voters that modern democracies have. OnlyFans has always been hinting that they wanted to grow beyond adult content, but they specifically cited their banking and payment partners in this policy change. OnlyFans got big enough that they ended up with a huge target on their backs, and they didn’t see a scenario where they could find payment partners that wouldn’t eventually start putting pressure on them.

I’m interested in what kind of pressure consumers can start putting on credit card networks and banks to reverse this trend of caving to evangelical pressure. As a society, we’ve grown increasingly to understand that sex work is work like any other, and that it’s bullshit to try to ban it just because some people don’t like its existence. I’m not sure what that kind of consumer pressure looks like yet, but I think it’s important.


But we also need to talk about the role platforms play on the internet today, and OnlyFans’s policy change is a prime example of the existential threat you face when you set up shop on someone else’s platform.

We love platforms for social content overall, both as users and as creators. I will spend hours browsing YouTube because YouTube hosts a truly massive amount of content and they can leverage that catalog to keep recommending me videos I just have to watch, easily turning my intended 11pm bedtime into more of a 12:30am “oh shit I really should sleep now.” And creators love that too! It means that if you put your content up on YouTube, YouTube might recommend your video to some viewer, and it makes it possible to grow your audience a lot faster than you could have with a totally independent site.

OnlyFans had the same network effects for adult content creators. If I have an OnlyFans account and I subscribe to one actor I’m interested in, it’s trivially easy for me to subscribe to more. OnlyFans can recommend me other relevant people based on who I’m currently subscribed to. Creators get more money. OnlyFans gets more money. I get more content and I get to support independent porn creators. Everyone wins!

But in this arrangement, one party ends up with a disproportionate amount of power: the platform. And these platforms have shown time and time again that they’re more than happy to grow on the backs of adult content and the people who create it, but as soon as it’s in any way difficult to stand up for them, these platforms immediately cave and leave the creators in the dust.

If you’re on OnlyFans and your reaction to this is “okay, time to set up shop on another platform,” you learned the wrong lesson from this. If your reaction is “I should set up my own independent site that I run myself and distribute my content in my own way with things like email and RSS feeds, independent of some other platform, and I’ll set up a presence on platforms as a funnel to my independently owned site,” then you’re on the right track.

And don’t get me wrong: when you’re indie, the audience is a lot harder to grow, because the platform isn’t there to lift you (seriously, if you’re reading this I appreciate it, but also I know you’re one of just a handful of people reading it). But that audience you build is yours, and it’s yours to keep. Vendors might come and go, but you will have a home.

Porn tends to be ahead of the curve on internet trends, and I hope that independent creators that previously were on OnlyFans adopt this trend and start to move toward a model where they own their destiny more.


Electron Has Its Place!

a screenshot of the Yubikey app, a simple app built with electron (or some similarly crappy web wrapper UI framework)
I love to rag on Electron, but like many things, it has its place.

For instance, Electron is perfect for stuff like the Docker desktop app, and not just because both are notorious for hogging system resources on my computer. I don’t need to interact with Docker’s GUI that often, and the UI is mostly a simple configuration interface that I can quickly pop into to see status and change settings. That’s reasonable!

There’s a Yubikey app I downloaded to update settings on my Yubikeys. They could have tried a little harder on the UI for this thing (it really is atrocious and looks like a webview) but I really don’t need the app that often, and when I do need it, it’s an in and out thing.

Like any tool, Electron has its place, and even a native macOS app purist like me won’t object to use cases like these.

And if you do decide to make your desktop app with Electron, be respectful of the platform you’re on! On a Mac, it should be possible to hide the app (looking at you, Docker Desktop). The preferences window (even if you fake it with a modal in the main window) should pop up when you hit ⌘,. Support keyboard shortcuts freely. And for heaven’s sake, your app should be made fully accessible (which Electron isn’t necessarily going to make easy).

But if you really are looking to make a full-fledged desktop application, making it with Electron just isn’t going to be as good, unless your definition of “good” is “easier and cheaper to develop.”


Tech Ennui

I’ve been feeling a little down about tech lately.

It’s nothing really big; it’s just a mixture of little things that have slowly been adding up to more papercuts in my digital life.

The world within my computers/devices is like home to me. In many ways, it is my home. I’ve moved from place to place over the years, but I’ve always resided digitally in roughly the same place. Sure, I make changes over the years, but I’ve been living in a fairly consistent environment since I was a high school student in rural Iowa.

The Apple world’s been tumultuous lately. I’m very excited about the Mac as a piece of hardware now that Apple is controlling its own destiny with its own chips, but software-wise things have been less rosy.

Increasingly in recent years a lot of major apps on the Mac aren’t really Mac apps, but Electron apps, and you know how I feel about them. Apple’s most complete toolkit for making Mac apps (AppKit) is also its oldest and is showing its signs of age, while some of its newer contemporaries (Catalyst and SwiftUI) are not yet ready for prime time. Good Mac apps are getting harder to come by, and I was sad last week to learn 1Password decided to abandon the native Mac route and go Electron (though I wouldn’t be surprised if that turned out to be temporary).

Apple’s been making moves recently that threaten the privacy of Apple platforms they have spent the last few years bragging about.

Not to get too into the weeds about work stuff, but I’ve personally seen my own workflow disrupted heavily as we abandoned our Mac-native dev environment in favor of using Docker-based devcontainers and Codespaces. As someone who isn’t a huge fan of VS Code and who likes using tools like Tower and Kaleidoscope locally, that’s been annoying because I previously had an environment that “just worked” and I’ve thrown hours at fighting with the new dev environments that supposedly should be better.

All of these complaints have serious “who moved my cheese” energy to them, and none of these are really serious problems. It feels silly to complain about my password manager being implemented with inferior technology when people in Afghanistan are desperately trying to flee their country. But I do feel like my tech home is changing, and it’s getting worse in a lot of ways. Overall I try to take a long view of the tech industry and keep myself optimistic. In 5–10 years this AppKit/Catalyst/SwiftUI thing will probably be settled and the Mac platform will be in a healthier place. Sucky tools like Docker for Mac will get better. People making dev tools I love will likely improve their compatibility with cloud-based dev environments.

But even taking that long view, I see trends I don’t like. More apps I use every day are becoming web apps, and they interoperate really poorly compared to well-made native desktop apps (seriously, I feel like we’ve unlearned all the advancements we made in the 90s, with simple things like drag and drop no longer being reliable). Every social network is on a proprietary platform now, some more open than others, and the idea of people doing things independently on the web feels like a dying concept (with occasional exceptions here and there). Governments around the world are tightening their grip on regulating the internet, but it’s getting weird because the internet transcends geopolitical boundaries. Some governments (okay, China) are going the opposite direction and are making their own internet that is under tight control of the government and uses Chinese web services.

I’m beginning to truly understand how Grampa Simpson felt.

an image from the simpsons with Grampa saying I used to be with it. But then they changed what it was.
Grampa Simpson: Now, what I'm with isn't it
Grampa Simpson: and what's it seems weird and scary to me.


Leaky Abstractions: When IFTTT Triggers Aren’t What They Seem

screenshot of my IFTTT recipe titled When I like a tweet, append its URL to a file in my Dropbox
As part of my ongoing initiative to always show up to internet arguments with receipts, I built a bespoke Rube Goldberg machine that can automatically download and archive tweets I like, turning them into Markdown files, complete with attached Twitter images and video downloaded.

Once I really get all the kinks worked out I promise I’ll write about it in full, but needless to say, it’s a fun system. I’m also in the habit of meticulously putting tags on the files for every liked tweet for easier lookup later, and it’s making me realize that I like a ton of tweets (over 500 tweets just this month alone, and the month is barely half over!).

Recently, I started getting the suspicion that some of my favorited tweets weren’t ending up in the archive at all. Eventually I caught my system in the act. I found a tweet from Andrew Cuomo that was hitting differently more recently (this one, if you’re wondering). I liked the tweet (well, I didn’t like it, but you know what I mean). But a Markdown file of the tweet never showed up.

As I mentioned, this whole system is a Rube Goldberg machine. A liked tweet starts its journey with an IFTTT recipe. That recipe is set up so that when I like a tweet, IFTTT takes that tweet’s URL and appends it to a text file in my Dropbox. I have a Hazel script that watches for changes to that file which will then pass the file into a Rake task that grabs the tweet URLs in that file, imports them, then deletes the file and marks the URLs as processed.

I checked my IFTTT logs, and there’s no sign of the recipe having fired for this particular tweet.

I contacted support, and they were baffled themselves, because they could like that tweet and there were no problems for them.

I noticed the age of this particular tweet, and started testing this out with other older tweets. None of them worked, but relatively new tweets were fine.

I asked IFTTT support if they had logs of any webhooks or other events coming in from Twitter. They responded that they aren’t doing anything event-based, but rather they are just polling Twitter.

And that was my “aha” moment.

You see, I have more Twitter likes than your average bear. I’ve been liking tweets for over a decade now, and I have accumulated tens of thousands of them.

When IFTTT polls Twitter, they’re just sending a request to Twitter saying “Twitter, give me Aaron’s likes.” Twitter, in their infinite wisdom designing this particular API, will give IFTTT back those liked tweets in reverse chronological order. But the tweets aren’t sorted by when I liked them; they’re sorted by the tweets’ own timestamps. In other words, if I have thousands of liked tweets and I like a tweet from five years ago and I ask Twitter for my most recent likes, Twitter will give me the most recently tweeted tweets that I liked, leaving the older tweet buried in the list.

IFTTT probably never anticipated people liking as many tweets as I do, and I’m sure they never ran into this issue when they were testing this feature. For a normal user who hasn’t liked a ton of tweets, the trigger works correctly; aka it will always fire when the user likes a tweet, because the number of liked tweets is reasonable and Twitter can send the whole list back. But when they poll my list of Twitter likes, they’re just getting the ones for the most recent tweets (probably the last 100 or so). So if I like a tweet from five years ago, even though I just liked it, IFTTT’s polling will never see it because they’re not paging through the hundreds of pages of my favorites every time they poll Twitter.

In other words, for me, this trigger is incapable of doing what it says it does, and I don’t think there’s an easy way for IFTTT to fix it because I don’t think Twitter actually offers an API that will notify IFTTT on newly liked tweets as they come in; it’s just a polling system.

However, not all hope is lost!

My little bespoke Ruby script doesn’t care whether I liked a tweet or not, it just takes a tweet’s URL and it dutifully downloads it. So, I built two simple solutions for myself:

For iOS, I made a Shortcuts app shortcut that is accessible from the iOS share sheet. When I pass it a URL, it will write a file to the same Dropbox folder as my IFTTT action and the file will contain the URL of the tweet. My Hazel script takes it from there.

For my Mac, I don’t have the Shortcuts app yet, but never fear; I built a simple Alfred workflow that runs a Ruby script that does the same thing.

The iOS shortcut required no code but interestingly enough it was more cumbersome to put together and required more trial and error; the Ruby script was kind of a one-and-done situation. Of course, I write Ruby for my day job, so it damn well better be easy for me to do that.

That’s all well and good from here on out, but what about all those previous old tweets I liked that are missing? Well, not to worry; one of these days I’ll download another archive of my Twitter account and run through a script to re-import what’s missing.

IFTTT’s trigger behavior here is an example of what we call a leaky abstraction. I shouldn’t care about how it’s built; if it worked perfectly I would have been able to count on it to always do what it says: fire when I like a new tweet. But because of how it was built, it doesn’t do that, and when I saw this bad behavior, the reality leaked through.


Electron Is Bad

Docker made their desktop app an Electron app which is really only fitting given how resource hungry both are on macOS

So I was discussing 1Password’s recent decision to switch to Electron, and I want to elaborate a little more on why I hate Electron so much.

You might not know what Electron is, but there’s a good chance you’ve got one running on your computer right now. Slack and Discord both use Electron, as does Facebook Messenger for desktop and several other popular apps. If you’re perfectly happy with these apps, I apologize in advance for the annoyances I’ll share with you that you no longer be able to un-see.

Your first clue that Electron is bad will come when you visit their home page and they proudly show a list of “Apps users love, built with Electron,” and Microsoft Teams is right there in that list:

nobody likes Microsoft Teams, stop lying, Electron!

Nobody loves Microsoft Teams except maybe some people at Microsoft.

Electron Apps make their way onto my Mac, acting like they’re regular old Mac apps, but then as soon as you start using them, you realize they are web applications in disguise. Developers love using Electron because developers are lazy and software companies are often cheapskates, and it’s less work to build an app using web technologies you already know.

They are using Chromium as their backend, so they hog a lot of memory, which some people care about. I bought an overpriced Mac Pro and loaded it up with enough memory that I don’t have to care about that. But I still manage to find other things to be annoyed about.

You look at Electron apps and you realize pretty quickly that they often don’t really look like an app for your Mac (or whatever platform you’re on). And that’s true! Unless the developer goes to painstaking lengths to make every UI element look platform-specific, the app just kind of has its own design language, independent from the rest of your computer. That kind of sucks. I bought a Mac because the apps on the Mac feel like Mac apps. If I’m going to load up with a bunch of platform-agnostic apps that don’t bother to fit in, what’s the point?

Electron apps occasionally will support multiple windows, but most don’t bother. They instead implement their own version of “window management” which will usually amount to a singleton window that is a bunch of tabs. Got two monitors and you want to have documents from the same Electron app open in both of them? Tough shit. Want to rearrange the inspectors? Nope! You’re stuck with them as side panes. Want to actually take advantage of your OS’s cool window management features like Expose? Well, you can’t, because the app is just one window.

Apps like Slack will nominally support drag and drop. I can drag a file into Slack and it will pick it up. But heaven help me if I want to drag an image from Chrome into Slack; it won’t do it. I can’t even drag images from the Photos app into Slack; Electron doesn’t support the intents that the Photos app provides. To work around these Electron apps that suck at drag and drop, I actually have installed an additional app on my Mac called Yoink. I will now drag and drop things in two steps: first I’ll drag and drop an item into Yoink, and then I can drag and drop from Yoink into Slack.

Oh, and copy and paste doesn’t quite work either; I can’t paste a gif into Slack; it will just paste a still image from the gif instead.

And of course, this week 1Password came along with their newly redesigned 1Password 8 and stealthily bragged about how all 1Password apps now share a unified Rust backend, while really quietly saying that they are using “web technologies” for their apps. In other words, Electron.

This is really disappointing because recently 1Password was bragging about their continued love of native apps (and I believed them because they even went to the effort of making their Linux app a GTK app).

When you look at 1Password 8 screenshots, they do indeed look pretty good. But being a good Mac app isn’t just about how you look, it’s about how you feel and how you work, and within a couple minutes of launching the new 1Password it’s obvious that no amount of care can work around the crappiness Electron causes your apps to have.

Scrolling lists kind of suck. AppKit apps have beautiful, buttery scrolling, and the scrolling acceleration feels consistent and just right, always. Scroll through a big list view in an Electron app and it’s… not quite right. Scrub through the list of logins in 1Password 8 by dragging the scrollbar and content just doesn’t render while you scroll. And of great annoyance: you scroll and hit the top of a list in an Electron app, and instead of getting that fun little “rubber band” bounce at the end, it just hits flat.

Here, I’ll show you. Here’s how it looks to scroll to the top of a list in a native AppKit app on macOS:

CleanShot 2021–08–13 at 11.52.04.gif

And this is what happens when you scroll to the top in an Electron app (in this case, VS Code):

CleanShot 2021–08–13 at 11.53.30.gif

“Aaron, you’re really getting nitpicky here!”

You’re goddamn right I’m getting nitpicky! This is my computer. You come into my house, and you want me to use your software on my Mac that I paid a premium for, you fucking play by the rules!

The Mac platform is full of hundreds of little tiny behaviors that make the Mac a Mac, and you tend to get them for free when you develop with AppKit, and it’s difficult staying on top of these behaviors. Now that I’ve seen 1Password try and fail to build a truly Mac-like Electron app, I don’t think it can be done.

It’s funny, too. Most of my favorite Mac apps are made by these really small software companies that care about the Mac. They tend to make only Mac apps, and they stay smaller because of that. But year in and year out, they keep making great Mac apps because that’s their focus.

That’s what 1Password used to be doing. They did branch out over the years, making a Windows app, then a Linux app, but for the most part they’ve been focused on gradual, organic growth. But then they took VC money, and now, despite being richer than they ever were before, they now are in this strange situation where they can’t afford to give these individual platforms the attention, so instead they are coalescing around Electron and offering a compromised experience across the board.


More on Apple’s “child protection” features

Regarding Apple’s upcoming feature to scan children’s Messages content for sexually explicit media, there’s a detail I had missed about how it worked: The “phone will rat on you to your parents” function is only going to happen when the child is under 12. For older children, the Messages app will just warn them in advance that the content is explicit, and they can dismiss the warning and nothing further will happen.

That does indeed make me a bit less concerned about this feature, and that age cutoff feels pretty reasonable.

However, the bigger problem remains here, and that is that Apple’s goal is to prevent child sexual assault, but the tool they’re deploying to do this is an image classifier that tries to detect sexually explicit material.

Even if you pretended for a second that this AI classifier is 100% accurate (and I promise you, it isn’t), it’s still an incredibly inaccurate tool for the job because the AI is incapable of understanding the full context behind something.

I think Apple’s reasoning here is that by having some on-device AI, it’s like your device has your back. In a world full of unsolicited dick pics, I can imagine this being a truly useful feature for both minors and adults alike.

But for that to be useful, it needs to materially be putting the user in control of their device. It would be one thing if I was 17 and my phone warned me that an incoming message from my boyfriend might be sexually explicit, and I could tell the phone not to warn me about further messages from this contact because I want those images, but the warnings remain on for other friends who I’m not expecting nudes from. That’s entirely reasonable!

But when the feature is just turned on for me by my parents, and I get a message with something sexually explicit, whether I wanted it or not, it’s a little unsettling to realize that my phone’s been looking at these messages and analyzing them the whole time, even if I do trust that the phone’s not going to tell my parents. Even if I’m 100% confident it’s just internal AI on my phone doing the scan and it’s not telling anyone, it still leaves me with the feeling that I’m not truly having a private conversation with someone on Messages.

I think for this feature we could meaningfully make it configurable in such a way that it truly does feel like it’s got your back. I think for younger children the defaults Apple has picked are reasonable.

But my larger concerns still remain. Well-intentioned or not, Apple has built out surveillance infrastructure, and they’re going to face pressure from less scrupulous governments to use it more abusively. Machine learning still isn’t amazing at what it does, and this will inevitably lead to some awkward situations when there is a false positive. And importantly, a nudity classifier doesn’t know the difference between consensual sharing of images between friends and someone trying to groom your child to be trafficked.

I said it before, and I’ll say it again: we expect our private conversations to be private when we’re in our homes talking to someone three feet away, and there’s no reason that we should expect any less just because we communicated using a messaging app (especially after a pandemic just forced our communications to be online). Surveillance is surveillance, even when it’s just your own phone doing it locally and not telling anyone.


Apple’s TV strategy

From a recent MacRumors post, Apple’s neglect of home/living room hardware has gotten even Apple’s own engineers concerned:

In his latest “Power On” newsletter, however, Bloomberg journalist Mark Gurman says that Apple engineers have personally expressed concerns to him about the direction of Apple’s living room hardware strategy.

The pundits are all suggesting that what Apple needs to do here is start making cheaper and simpler Apple TV hardware, similar to the sticks that Roku and Amazon make.

This has strong echos of how Apple really needed to make a netbook back in 2010 because so many PC makers were making them and they sold well.

I hope Apple stays in this business. Having iOS at the core is a really strong asset and the living room has lots of really interesting potential applications if Apple could just dedicate some resources to it.

But there’s no point in Apple making a $50 stick. You can already buy a $50 stick from Amazon or Roku, and you can watch Apple’s own TV content on both! I have trouble seeing Apple put out a device like that, especially given how much they love margins.

Apple should focus on making TV devices that are able to do things only Apple can realistically do. I’d love to see them really give gaming a shot on the TV, with good and interesting controllers (maybe even some motion-based ones in addition to a high-quality standard looking controller). A good camera would be great for family FaceTime calls!

There’s so much interesting stuff Apple can do in the living room still. Also, though, I’m happy to see that there are a few players in fierce competition with one another on making devices for the living room, and the stuff they’re making is… pretty good!


1Password’s New Apps

screenshot of 1Password 8 for Mac. Credit: 1Password's blog
Today 1Password announced a completely redesigned app in 1Password 8. But it has a dirty little secret.

It’s no longer a native Mac app; it uses Electron instead.

I strongly dislike Electron apps. Developers love making apps with Electron, mostly because it’s a lot less effort and you can use familiar web technologies to make desktop apps. But for all the reasons it’s great for the developer, it’s worse for users, because although you technically can get a macOS app with Electron, your app isn’t a macOS app; it’s a web app that’s wrapped in Electron.

You can build really impressive apps with Electron (because the web is a great platform), but it takes a lot of effort to build an Electron app that is truly a good citizen that fits in on every platform. And because the Mac platform is such a well-made platform with great attention to detail, Mac users snub their nose at Electron apps more than most.

That’s probably why 1Password decided to so heavily dance around the subject.

I’m trying out the app now. They clearly tried hard to style the app to look Mac-like, but no amount of styling is going to make it feel Mac-like, and indeed it doesn’t take long to start noticing the shortcomings. When you scroll through lists in an AppKit app, it’s buttery smooth. Scroll through lists in the new 1Password app and it drops frames on a Mac Pro. Drag the scroll bar and the items just won’t render while scrolling until you slow down. When you get to the end of a list in an AppKit app there’s a little “rubber band” effect with the scrolling; do the same in Electron 1Password and it’s flat and lifeless. The preferences panel was implemented as a modal that can’t be dragged. The Delete key doesn’t… actually delete things (though that one’s probably just an oversight that will be fixed).

They bragged a lot about how it’s using a new Rust backend (which is great) but it’s only after some prodding that they admit (in their forums) that it’s an Electron app behind the scenes.

Although I can appreciate their desire to maintain fewer codebases, this move really seems to scream “we’re a VC-backed company now!”, and I do appreciate the irony that 1Password has made native Mac apps for over a decade, but now that they’re backed by millions in VC funding, they can no longer afford to write native apps for multiple platforms.

And I get why. These investors poured millions into the company and are going to want to see growth, and that will only come when 1Password starts piling in new features at breakneck speed. They need a single platform to target so they can keep up. Never mind that in the year of our lord 2021 1Password still is hit-and-miss in terms of actually being able to fill in my password on every web site, and when it comes to auto filling account sign-up forms it’s more miss than hit; after all, core features aren’t getting 1Password any new customers; it’s all about the new features!

But if the new Electron app was truly one to be proud of, 1Password shouldn’t have had any trouble shouting it from the rooftops. So either 1Password knows Electron is worse in a lot of ways so they’re trying to downplay that part of it, or they do think it’s a great app but they don’t have enough respect for their users to be honest about it.

I don’t like either scenario.