But iOS app icons (and iPadOS) were always in squircle shape. Why is and was this okay for you, but it’s not for macOS?

This is a good and fair question. But I not only have an answer, I have an answer that clarifies why this entire debate is important. That “design is how it works” applies even to something as seemingly superficial as icons.

There are all sorts of limitations and simplifications in iOS that would be bad ideas to bring to MacOS, which would range in effect from disappointing to frustrating to maddening to ruinous. Where squircle jail falls on that scale is subjective. It’s certainly not ruinous, but I’d say it’s maddening. (iOS baby-computer-isms that would be ruinous to bring to MacOS would include killing AppKit, removing the Unix terminal layer, or requiring all apps to come from the App Store.)

MacOS has suffered many such frustrating decisions before. E.g., it arguably makes sense for iOS to omit always-visible scroll bars because screen real estate is so limited. It makes no such sense on the Mac.

As for mandatory squircle shapes for app icons in particular:

(a) I don’t think this is a good mandate for iOS either;

(b) it was always so for iOS, though, so it’s not like Apple has ever taken away rich creative icon shapes on the platform;

(c) MacOS is a far richer and more precise environment than iOS.

App icons on the iOS home screen are effectively simple buttons. I think it’s rather obvious that’s why they have had that squircle/roundsquare shape ever since the iPhone was announced in January 2007 (source). They’re one-tap launchers. App icons in MacOS are not mere buttons. You can drag them, move them, and drop things on them. You click them to select, and double-click to launch. They are richer objects that deserve a richer visual vocabulary. iOS is a world meant for fat-tipped Magic Markers and blunt safety scissors. MacOS is a world meant to support fine-tipped drafting pens and precision razor-sharp X-ACTO knives.

Plus, Macintosh icons have four decades of glorious history. Style and fashion change over time. But limitations should not be imposed where freedom once reigned.

And shape as a differentiating factor is not mere decoration. We have long known this. We all knew this. And not only did Apple know it, the rest of us knew it because we learned it from Apple. Via the Internet Archive, here’s Apple’s Macintosh Human Interface Guidelines from 2018,¹ which is not that long ago:

Consider giving your app icon a realistic, unique shape. In macOS, app icons can have the shape of the objects they depict. A unique outline focuses attention on the object and makes it easy to recognize the icon at a glance. If necessary, you can use a circular shape to encapsulate a set of images. Avoid using the rounded rectangle shape that people associate with iOS app icons.

“A unique outline focuses attention on the object and makes it easy to recognize the icon at a glance.” Eight short years ago. That is not the description of a fad or fashion. It is a description of human perception. Our unchanging nature.

So much collective hard-earned wisdom has been ignored of late. But it’s not lost or forgotten. Chapter 11 of the 2002 Aqua Human Interface Guidelines is a good place to start remembering. There was tremendous thought, rigor, and logic behind those guidelines — all of it in the name of creating a visual language for icons that most people simply thought looked cool as fuck.

WorkOS Pipes handles it with one API call. Pre-built connectors for GitHub, Slack, Salesforce, Google Drive, and more. Pipes handles OAuth, token refresh, and credential storage. You call the real provider API with a fresh token, every time.

Connect to 100+ providers →

Apple’s prohibition on shapes is a step backward for both usability and creativity in app icons. Icons are now harder to distinguish because they’re no longer allowed to be distinctive. But there’s no technical reason for it. Apple could, and should, once again allow icons to take on a wide variety of shapes.

It’s clear that some people within Apple recognize that the transition to Liquid Glass introduced mistakes. They also appear to have the authority to fix those mistakes. Refinements to Apple’s own icons in Golden Gate are a welcome course correction, as is the much-celebrated Liquid Glass opacity slider. It’s time to correct the mistake of banning icon shapes as well.

Apple should stop forcing every icon into the same squircle.

The squircles, I will point out, are not in and of themselves the problem. The problem would be the same with any mandated shape, like, e.g., VisionOS’s circles.

John Siracusa:

Squircle Jail is the worst design-related thing Apple has ever done to Mac developers, and probably the worst icon-related thing it has ever done, period. Incredibly developer-hostile.

If squircled icons are actually better, then let that design win in the market. That’s how we transitioned from the classic Mac OS icon style to the more photorealistic Mac OS X icon style. Developers adopted it because they wanted to, and because users desired it.

John Siracusa has a long memory, cares deeply about Mac design, and is not prone to hyperbole (putting it mildly). I’m not sure I agree with him that this is “the worst design-related thing Apple has ever done to Mac developers”, but it’s certainly on the short list for consideration. And, like Siracusa, I can’t think of any other design crime Apple has ever foisted on Mac developers that I’d argue (with Siracusa) was worse.

It’s one thing for Apple to force all of its own app icons into the same identical shape. That would be bad enough, because Apple’s own Mac apps are numerous and popular, and as the platform owner Apple necessarily sets the direction that many third-party apps follow. But it’s just downright spiteful to enforce it platform-wide. Apple decided they’re no longer going to create nice icons with unique, interesting, and most importantly, distinctive shapes — but they no longer allow third-party apps to either. It’s like Apple decided every single one of its own apps must wear a stupid-looking hat, and they put those stupid-looking hats on third-party apps too, whether the developers of those apps want them or not. Scratch that. Not hats but helmets. The mandatory squircle makes identifying apps at a glance harder in the same way that it’s difficult to identify individual people if they’re all wearing same-shaped helmets. Real helmets at least serve an important safety purpose. The squircles are like stupid unnecessary helmets.

To that point, Jim Nielsen draws an even better analogy — traffic signs:

Consistency for traffic signs! Let’s start by redesigning them all to be the same shape.

Which was a sarcasm-dripping reply to his own previous post:

Shape isn’t everything, but it’s one tool to help provide differentiation and uniqueness in icons. But not anymore.

Just the mere silhouette of the old Keynote icon is more recognizable, and thus more iconic, than any icon on any platform from Apple today.

No civil engineer would ever suggest changing yield and stop signs from their iconic triangles and octagons to identical squircles. The human visual system evolved to be remarkably good and quick at identifying shapes. The primary element of an app icon is the semantic meaning of its illustration. Color and shape are secondary. With the squircle mandate, Apple has removed shape from the equation.¹ The purpose of icons is right there in their name: to be iconic. Shape was often the most iconic thing about an icon. Now it’s no part at all.

It makes no more sense than removing color. But Apple did that too! One of the purported reasons for the new icon guidelines across MacOS and iOS are the tinted and clear appearance options introduced last year with Liquid Glass and the OS 26 releases. These are both terrible ideas that remove color as a distinguishing factor, reducing ostensibly distinguishable icons into indistinguishable buttons. Adam Engst skewered the Clear and Tinted icon appearance options in a recent column at TidBITS, and ran a poll to see if anyone actually used them. Spoiler: nope.

App icons used to be exuberantly fun and so beautiful that they were the subject of two splendid coffee table books. This squircle shit is no fun at all, and ugly as sin.

Let’s go back.

ChatGPT’s native Mac app, on the other hand, is a truly native Mac app. It looks like a Mac app and feels like a Mac app because it really is a Mac app. I’ve liked it ever since it launched back in May, and it keeps getting better. And I keep using it more and more as my go-to resource for answering questions.

I asked Claude, “What is the best way to engineer a native Mac app? What frameworks and developer tools should one use if the goal is a great Mac experience?” Claude’s answer started by positing it as a decision between SwiftUI and AppKit. Perhaps Anthropic’s Mac engineers should have asked Claude this same question before they built this turd of an Electron app.

In March of this year, linking to Anthropic’s announcement that Claude Code and Claude Cowork can take control of your Mac to accomplish agentic tasks, I returned to the same question:

The Claude Mac client itself remains a lazy Electron clunker. If Claude Code is so good I don’t get why they don’t prove it by using it to make an even halfway decent native Mac app.

I’m not the only one who has pondered this. Drew Breunig wrote “Why is Claude an Electron App?” in February this year:

On the surface, this ability should render Electron’s benefits obsolete! Rather than write one web app and ship it to each platform, we should write one spec and test suite and use coding agents to ship native code to each platform. If this ability is real and adopted, users get snappy, performant, native apps from small, focused teams serving a broad market.

But we’re still leaning on Electron. Even Anthropic, one of the leaders in AI coding tools, who keeps publishing flashy agentic coding achievements, still uses Electron in the Claude desktop app. And it’s a slow, buggy, and bloated app.

So why are we still using Electron and not embracing the agent-powered, spec driven development future?

For one thing, coding agents are really good at the first 90% of dev. But that last bit — nailing down all the edge cases and continuing support once it meets the real world — remains hard, tedious, and requires plenty of agent hand-holding. [...]

For now, Electron still makes sense. Coding agents are amazing. But the last mile of dev and the support surface area remains a real concern.

I’m with Breunig up until the point where he accepts coding agents struggling with the final 10 percent as a justification for choosing Electron to create a Mac app. Plenty of people — individuals and teams alike — are using Claude Code to create terrific new native Mac apps. Just among my friends, Glenn Fleishman, Lex Friedman, and Jason Snellman, have all in recent months used not just AI coding assistants in general, but Claude Code specifically, to create genuinely native Mac apps that meet their own personal high standards for Mac-assedness, forged through decades of literally professional Mac snobbery. A comprehensive catalog of Mac-assed apps made with the assistance of Claude Code, would, I suspect, be remarkably long.

The struggle with the last 10 percent is unrelated to AI coding. It’s the nature of all software engineering. There’s a well-known adage that Wikipedia names the “Ninety-Ninety Rule”, attributed to Tom Cargill of Bell Labs:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

Cargill’s mathematically humorous formulation resonates because it not only explains why the final 10 percent consumes half the time, but also why software projects tend to take twice as long as expected. This universal truth holds whether the code is human-written, AI-generated, or a mix of both.

Breunig gets closer to the truth in a postscript, linking to the Hacker News thread discussing his post. The top-rated comment in the HN thread is from Boris Cherny, who works at Anthropic on the Claude Code team. Cherny wrote:

Boris from the Claude Code team here.

Some of the engineers working on the app worked on Electron back in the day, so preferred building non-natively. It’s also a nice way to share code so we’re guaranteed that features across web and desktop have the same look and feel. Finally, Claude is great at it.

That said, engineering is all about tradeoffs and this may change in the future!

I would rephrase the guarantee that “features across web and desktop have the same look and feel” as guaranteeing that the Mac app is restrained by the limits of the web and cut off from the breadth of idiomatically native functionality provided by the Mac’s native frameworks. Electron guarantees that an app feels just as wrong on all platforms. But the more relevant tidbit is this sentence: “Some of the engineers working on the app worked on Electron back in the day, so preferred building non-natively.” So it’s not that Claude somehow prefers Electron, but that “some of the engineers” at Anthropic do.

Some is doing some heavy lifting there, given that “some of the engineers” includes Felix Rieseberg, currently Anthropic’s engineering lead for Claude Cowork and Claude Code Desktop, and previously engineering lead for the Claude apps for MacOS and Windows. Rieseberg didn’t merely “work on Electron back in the day”. He is one of the principal people responsible for creating Electron, and remains today one of three members of the Electron project’s Administrative Working Group that “oversees the entire governance and project”. He literally wrote the book on Electron.

Felix Rieseberg, quite obviously, is the answer to the question why Claude is an Electron app. It’s like wondering why all the screws in a building were hammered into the walls, and then finding out that the guy who oversaw construction founded and co-owns the world’s biggest hammer manufacturer. Windows uses Philips head screws, Linux uses hex screws, and MacOS requires Torx (of course) — but a hammer works the same way with all screws. That’s Electron. That’s Rieseberg’s baby.

Rieseberg, it turns out, hasn’t only had a hand in Claude being an Electron app. Per both his personal home page and LinkedIn profile, before joining Anthropic he spent over two years as the engineering manager for the desktop team at Notion, whose client for Mac is a massive 518 MB Electron app and a notoriously non-native experience.¹ Before Notion, Rieseberg spent 2016–2021 “as a Senior Staff Engineer and Engineering Manager at Slack, where I got to support a team of amazing C++ engineers building the cross-platform desktop framework Electron — as well as Slack’s desktop apps for macOS, Windows, and Linux.”²

Finding out that one guy — who is a senior Electron maintainer — has led the teams for the desktop clients for Slack, Notion, and now Claude is like discovering that it was one guy — whose family business was a distillery — who helmed the Titanic, piloted the Hindenburg, and then served as air traffic controller for Amelia Earhart.

For the U.S. variant of the iPhone 18 Pro, which will feature mmWave compatibility, Apple seemingly plans to use Qualcomm modem hardware. Multiple Qualcomm components, including the SDX80M, SDR875, QDM8771, QDM8720, PMK75, PMX75, and QET7100A, are referenced in a bill of materials related to the iPhone 18 Pro model Apple plans to sell in the United States.

As for the iPhone 18 models which will be sold elsewhere, Tata documentation suggests these configurations will use Apple’s proprietary C2 modem. While this approach may sound unusual, there is at least one possible explanation.

Apple’s current in-house modems, the C1 and the C1X, do not support 5G mmWave, and it looks as though the C2 will continue this trend. Until Apple develops a modem compatible with mmWave, it looks as though the company will offer mmWave support to iPhone 18 Pro users by using Qualcomm hardware.

This immediately raises the question of which modem is “better”, and I suspect the answer requires nuance. Apple’s C1 and C1X modems are, by all accounts, noticeably more power efficient than Qualcomm’s. An iPhone with an Apple C-series modem should get longer battery life than an otherwise identical iPhone with a Qualcomm modem. The obvious advantage to the Qualcomm modems is support for 5G mmWave, the super high-speed 5G bands primarily offered by Verizon.

Personally, I don’t care about mmWave speeds. It literally makes no difference in my experience compared to regular 5G speeds. In fact, ever since WWDC a few weeks ago, I’ve had my iPhone 17 Pro set to use LTE instead of 5G. (Settings: Cellular: Cellular Data Options: Voice & Data.) I literally notice no difference in speed and I presume that battery life is improved. Battery life certainly isn’t worse. (I switched to LTE after a friend at WWDC suggested that LTE has better range/penetration in places like airports, especially when you’ve boarded a plane but haven’t taken off yet.)

Just now I used Ookla’s Speedtest app to test the difference here in my office. I got 80 Mbps down / 15 Mbps up on LTE; 320 Mbps down / 18 Mbps up on 5G. That’s on Verizon’s network (which does offer mmWave throughout center city Philly, but seemingly not here at my house), with my iPhone 17 Pro (which uses a Qualcomm modem). I tested again, minutes later, using an iPhone Air (which uses Apple’s C1X modem) and got 390 Mbps down / 21 Mbps up on 5G (and similar 80 Mbps down / 13 Mbps up on LTE).

So 5G is clearly faster than LTE here at home for me, using either iPhone model. But why should I care about that difference? Having a phone that can pull 320 Mbps down over cellular is like having a car that can go 320 MPH — an interesting technical feat, but of no practical value to me whatsoever. I never feel like I’m waiting for anything to load because I’m on LTE. LTE is fast enough, and regular 5G is more than fast enough. 5G mmWave is simply a waste of battery life as far as I’m concerned.

So Apple’s C-series modems win on battery life, and Qualcomm’s modems win for high-speed mmWave support. But Qualcomm’s speed edge is theoretical, not practical. Apple’s C1/C1X energy efficiency edge is very much practical. I’ve used both the 17 Pro and iPhone Air in a variety of places over the last year, and I’ve noticed no real difference in being able to get a decent signal in rural areas, either.

On the surface it sounds like a tradeoff — that Qualcomm’s modems consume more battery but deliver higher download speeds. But in practice that tradeoff only comes into play if you’re a Verizon user and happen to be within 50 meters or so of a mmWave-equipped cell tower, and that crazy high bandwidth doesn’t really make anything you do with your phone any faster than regular 5G (or LTE, I say). In reality I’d rather have an Apple C-series modem — I’d get better battery efficiency all the time, the same network performance almost all the time, and I don’t care at all about the rare times when I could get the crazy-high-speed mmWave bandwidth that Apple’s C1 and C1X modems don’t support (and perhaps still won’t support with the upcoming C2). Cellular download speed and reception is nearly a solved problem for my needs. Battery life is not.

So why wouldn’t Apple just use the C2 everywhere, including the U.S.? I suspect Apple is hoist not with their own, but with Verizon’s petard here. Faster-than-you-practically-need download speeds are a carrier bragging point. Longer battery life and plenty-fast-enough download speeds are an Apple bragging point. Verizon — and to a lesser extent, AT&T — spent a fortune building out mmWave networks. They don’t want to sell flagship phones that don’t support them. Apple’s flagship iPhones have supported those networks since 2020. Remember how many times Tim Cook and Verizon’s CEO uttered “5G” at the Covid era iPhone 12 event? If Zivkovic’s analysis of this stolen data from Tata is correct, and Apple is going to use Qualcomm’s models only in iPhone 18 Pro models sold in the U.S., I think the reason why is Verizon and AT&T bragging points, not any practical user benefit. And the result may be that U.S. iPhone 18 Pro models get somewhat worse battery life than those in the rest of the world.

Previously: Nicole Nguyen Tests 5G’s Effect on Battery Life on iPhones and iPads (March 2022).

The Supreme Court on Monday ruled that when law enforcement officials used a “geofence warrant” — a warrant that instructed Google to provide location data for cellphone users who were near a particular place during a specific time period — to obtain evidence used to convict a Virginia man of a 2019 bank robbery, they conducted a “search” for purposes of the Fourth Amendment. By a vote of 6-3, the justices sent Okello Chatrie’s case back to the lower court for it to consider whether, as the Fourth Amendment requires, the search was “reasonable.”

Writing for the majority, Justice Elena Kagan emphasized that “[a]n individual has a reasonable expectation of privacy in records about his cell phone’s location, and police intrude on that constitutionally protected interest when they demand the information — even though for only a limited time, and from a third-party tech company.” [...]

The issue at the center of Chatrie v. United States arose after a man armed with a gun entered a federal credit union outside Richmond, Virginia, and gave the teller a note demanding money. He made off with nearly $200,000, but law enforcement officials did not have any leads until they served Google with a geofence warrant, which directed the tech company to provide location data for cellphone users who were near the bank at the time of the robbery.

I agree, wholeheartedly, with the decision. Howe’s coverage, being at SCOTUSblog, is unsurprisingly concerned with the legal aspects. But I’m also fascinated by the technical aspects. It’s remarkable — and regrettable — that Google had this geofence information in the first place. The data was part of a grossly invasive and ill-conceived feature Google called “Location History”, and was used to power a feature called “Timeline” in Google Maps. The data was stored unencrypted by Google in the cloud, tied to your Google account, thus making it available to these geofence warrants.

Back in December 2023 Google announced that it was changing the way it stored this data, defaulting instead to on-device storage and using end-to-end encryption (that Google itself cannot decrypt) for location data it holds online. This change had long been advocated by the EFF, which celebrated Google’s policy change. (Notably, Chatrie robbed that credit union in 2019.)

Most people have an unshakeable belief in the widely-held misconception that “everything” we do — everywhere we go, even everything we say — in the presence of our phones is tracked and recorded, and traceable back to us individually. It’s not at all ridiculous that this belief is so common, given that it is technically feasible. Our phones are precise GPS devices, they do have good microphones, and they are (almost) always connected to cellular and/or Wi-Fi networks. And the surveillance advertising industrial complex — primarily Meta and Google — is so uncannily good at serving ads based on our recent personal interests that the most obvious explanation for how they do it is “they listen to us and track us and record everything we do”. That’s not how they do it. But “they listen to us and track us and record everything we do” is an explanation that everyone can easily understand. If that were how Meta and Google served targeted ads to us, everyone could understand how the ads are so often so uncannily and creepily accurate. The way it actually works is complex and complicated, and thus in the realm of Arthur C. Clarke’s maxim that “any sufficiently advanced technology is indistinguishable from magic”. Incorrect explanations that people understand resonate and take hold and become entrenched beliefs; correct explanations that people don’t understand are dismissed and are not believed. (Exhibit A: evolution.) This is why it is such a precious gift to be able to explain complex technical and scientific subject matter in ways that many people can understand.¹

And lo, now here’s a Supreme Court case showing that when the police asked for a list of people whose phones were near a particular bank at a particular time on a particular day, Google had that information and handed it over. Chatrie v. United States is not a particularly celebrated case, but this will only contribute to the entrenching of superstitious incorrect conspiracy theories about the data that “they” — big tech companies — collect about us.

But Google no longer collects this information in a way that is susceptible to geofence warrants, and, more importantly, Apple never did. From my own December 2023 post on Google’s decision to change how it collects this data to ensure privacy:

The reason these overly broad geofence warrants “almost always” were specific to Google is that Apple never collected location data that could be collected in the aggregate like this. From Apple’s most recent government transparency report (PDF), covering the first half of 2022:

Apple may also receive requests from government agencies seeking customer data related to specific latitude and longitudes coordinates (geofence) for a specified time period. Apple does not have any data to provide in response to geofence requests.

I checked with a source at Apple, and they believe they have never collected or stored geolocation data in a manner that can be linked to groups of individuals in a certain area or areas.

So the whole question of geofence-warrant fishing expeditions may have been obviated two years ago by Google for Android users, and was never an issue for iPhone users. Unless, perhaps, they used the Google Maps app on their iPhones and granted it the “always on” location access that it asks for. I suspect, but do not know, that iPhone users who granted “always on” location access to Google Maps (or any other Google iOS app that asked for it? — all of their iOS apps seem to ask for location permissions, but I don’t know how many other than Google Maps ask for always-on access) were just as susceptible to these geofence warrants as Android users.

This decision should still serve as good precedent for location data held by other companies, and I hope the decision serves as good precedent for any searchable Personally Identifiable Information susceptible to fishing-expedition warrants in general.

But the bottom line is: Apple has never held data tracking your location, and while Google did, they no longer do.

Early testers commented: “Day One’s new Daily Chat is a true game changer for my daily journaling. The AI-powered chat makes capturing thoughts effortless and inspires creativity like never before. Writing my diary has never been this intuitive and fun!”

Try it for yourself, it will change the way you think about journaling.

Corporate greed is Tim Cook, the billionaire Apple CEO, claiming that hiking prices on Apple products by over $200 is “unavoidable” after it made $112 billion in profits last year & spent $310 billion on stock buybacks.

These price hikes aren’t unavoidable. They’re unacceptable.

It boggles the mind how anyone could post this and not question the common sense napkin math of a company spending 3× its annual profit on stock buybacks. That’s theoretically possible, I suppose, but obviously unsustainable. A company would have to burn through a cash hoard or incur massive amounts of debt to spend 3× its profit on anything. It makes no sense. Someone who doesn’t consider the common sense of those numbers probably shouldn’t be spouting off on anything related to economics. And of course Apple files an annual report with the SEC, easily searchable via the web, which plainly shows that the company spent $89 billion on stock repurchases last year, and paid shareholders $15 billion in dividends. Those numbers make sense for a company that earned $112 billion in profit.

I suspect Sanders is so ignorant of basic economics that he sees the ampersand in his tweet as additive — that Apple made $112 billion in profit and spent $310 billion in buybacks and thus had something like $420 billion of money “in the black” with which they could eat the cost of rising RAM and SSD components. But they’re not additive. Stock repurchases are purchases. If Apple actually had spent $310 billion on stock buybacks last year — which, to repeat, they most certainly did not — even Karl Marx might excuse them for raising prices on their products this year, because they’d be in a $200 billion hole they needed to dig out of.

But such concerns, obvious to anyone who’s taken an Econ 101 course in college, seldom stop ideologues.

Putting aside Sanders’s factually incorrect and nonsensical $310 billion figure, let’s just consider this general scenario: A company makes a product that consists of essential components they must purchase from suppliers. Something happens — outside the company’s control — that causes those essential components to rise in price significantly. Therefore the cost of goods for the company’s product increases significantly. What should the company do? Raise prices and pass those increased costs on to their customers, maintaining the same level of profit for themselves? Or hold prices steady and eat those costs, accepting lower profits or even negative margins, so that customers remain unaffected?

One can hold logically consistent views at both extremes. At one end, the belief that business is business and higher costs naturally result in higher prices passed along to customers. At the other end, the belief that companies should put the welfare of their customers ahead of their own profit seeking. Perhaps you think the answer is somewhere in-between: somewhat higher prices and somewhat lower profit margins. What you cannot do is hold a philosophically consistent logically coherent view where your answer to how a company should respond in such a scenario is contingent on what the “something happens” is that caused component prices to rise.

When the “something happens” is a global RAM and SSD shortage resulting from the AI datacenter capex spending spree, Sanders’s tweet makes clear that he’s of the opinion that Apple should eat these costs.

But when the “something happens” was Trump’s tariffs, Sanders argued that (emphasis added) “Trump’s across-the-board tariffs are not the way to do it. We do not need a blanket and arbitrary sales tax on imported goods which will raise prices on products that the American people desperately need.” And again: “Trump’s blanket tariffs will just raise prices for American consumers and hurt our relationships with allies, undermining our global position.” Not “might” raise prices. “Will” raise prices.

Sanders arguing today that Apple should eat the entire cost of rising RAM and SSD components makes no more sense than this tweet from Donald Trump a year ago:

Walmart should STOP trying to blame Tariffs as the reason for raising prices throughout the chain. Walmart made BILLIONS OF DOLLARS last year, far more than expected. Between Walmart and China they should, as is said, “EAT THE TARIFFS,” and not charge valued customers ANYTHING. I’ll be watching, and so will your customers!!!

Sanders’s tweet is better punctuated and capitalized, but it’s the same illogic. Zero economic sense, 100 percent ideological wishful thinking. Yelling angrily doesn’t make your argument any more compelling or coherent.