Some quick thoughts on the hardware prices Apple increased — and didn’t increase — today.

Heartbreaking news, shared by Om’s family:

Om Malik passed away on June 24, 2026, at Stanford Hospital after a long health journey with his heart. He was surrounded by family and friends.

We invite you to share your remembrances of Om in the comments below or by posting and tagging his accounts on X/Twitter, Instagram, Threads, or LinkedIn.

Om kept this battle very private, so this news comes as a terrible surprise for many, and an incomprehensible gut punch for everyone who knew and loved him. Rest in peace, my friend.

So it goes.

Rolfe Winkler, reporting for The Wall Street Journal (gift link):

The company briefly took down its Apple Online Store early this morning as it typically does when announcing new products. When it came back online, the price tags for Mac computers rose roughly 15% to 20% and iPad prices rose 15% to 25%.

Among the price increases, the base MacBook Air rose $200 to $1,299; the base MacBook Pro increased $300 to $1,999; the entry-level MacBook Neo increased $100 to $699. The iPad Air increased $150 to $749 and the iPad Pro increased $200 to $1,199.

iPhone prices were unchanged, though the company hinted at more increases in a statement.

“We have now reached a point where we need to begin raising prices,” it said in the statement. “We have never seen a component price increase this much, this quickly.”

MacRumors has a list of before/after prices. Christ, they even raised the price of the poor Vision Pro by 6 percent, from $3,500 to $3,700.

Anyone who purchased a MacBook Neo for $600 (or $500 with education discount) between March and this morning purchased the lowest-price MacBook Apple has ever sold — and perhaps the lowest-price MacBook they ever will sell.

Jeff Johnson:

Several weeks ago, John Gruber of Daring Fireball asked me whether I could reproduce an issue he was seeing in Safari: when a web page is focused, the Copy menu item in the main menu is always enabled, regardless of whether there’s anything selected in the web page. I could indeed reproduce that issue, and it turns out to be the fault of WebKit. The issue also occurs in Mail app, when an email message is focused.

On Apple platforms, WebKit is a public API, used by third-party apps in addition to Apple’s first-party apps. RSS readers such as NetNewsWire and Vienna, preferred by Gruber and myself, respectively, use WebKit to display articles from RSS feeds. And sure enough, both apps exhibit the same issue: the Copy menu item is always enabled when an article is focused.

What happens if you copy and paste from a WebKit WebView with no selection? Nothing happens, nothing is pasted. However, technically speaking, the clipboard is not empty.

In most Mac apps, since the dawn of time, if there is nothing selected to be copied, the Edit → Copy (and Cut) commands are disabled. If you invoke the ⌘C shortcut while the Copy command is disabled, you hear an alert sound, letting you know that whatever you thought you were copying could not be copied because it wasn’t selected. That beep is useful context. This is proper behavior for all menu items — if they’re not available to do something, they should be disabled, and invoking a disabled menu item keyboard shortcut should beep. In any app that uses WebKit, since early in 2025, the Copy command is always enabled when a WebKit view has focus — but if nothing is selected, you get useless clipboard data that can’t actually be pasted anywhere. (And whatever was on your clipboard is now gone, or pushed back if you use a clipboard history utility.)

This is clearly a bug. It cannot be acceptable that you can copy nothing, wiping out whatever was previously on the clipboard. (Or to be pedantic, to copy a useless inscrutable plist blob that can’t be pasted anywhere.)

Johnson reported this bug in WebKit’s Bugzilla system, but it was erroneously closed as “Won’t Fix”. There’s a conflation in the WebKit team’s closing of Johnson’s bug report between how the Edit → Copy command behaves in any WebKit-using app, and how JavaScript’s document.execCommand("copy") needs to be available even when there’s no selection in the WebKit view. WebKit engineers introduced the bug in application behavior when they attempted to fix the decade-old bug in the JavaScript behavior last year.

I was very glad to read on the WebKit blog, just this morning, that the WebKit team is encouraging the submission of bug reports. Here’s a bug that has already been reported, with copious details, that they merely need to look at again.

The WebKit blog (back during WWDC):

If you look through the lists of features and fixes in Safari 27, you’ll notice that, although there are 58 brand-new features and 525 fixes — the largest pile of fixes in any Safari release in recent memory — most of what is released is not about new things.

Most of this work has been about existing features behaving more correctly, handling more edge cases, and fitting together with other features the way you’d expect. We committed our time to increasing quality — that’s the story of this release and the year that led to it. [...]

If something has been bothering you, test it in Safari 27 beta. You might be pleasantly surprised. And if it hasn’t been fixed yet, file a bug report, or add a comment to an existing issue with a concrete scenario, a link to a real site, or a reduced test case. The more concrete the problem, the more helpful it is.

Sounds like it’s a bit of a Snow Leopard year for WebKit, too, not just the OSes.