Gus Mueller:
Acorn 8.3 is out and the big new feature is that it supports Liquid Glass for folks who are running macOS Tahoe (which is over 50% of Acorn 8 users at this point!).
[…]
But the UI was a ton of work! And I made it extra difficult on myself by making Liquid Glass optional.
[…]
The second option is “Display images edge-to-edge”. This one works on all versions of macOS that Acorn 8.3 runs on. This is the fancy look where the toolbar floats above the content as if it was a delicate and beautifully manicured piece of glass. It also removes the bottom toolbar, so there’s maximal room for your pixels to shine.
I also reworked the tool palette so that it no longer takes up the whole left side of the window and instead floats above the canvas and gives more space for your image to be viewed. (And every time I look at it, it makes me think of MacPaint and its tool palette. What a great app that was!)
That’s a good change, but I still question the premise of the new tool palette design. I kind like having the tool options and layers docked to the right side of the document window, but I don’t understand the desire to have the tool icons at the left displayed on top of the image. You save a little space but have to keep pressing Tab to see the whole image. I think the MacPaint and Acorn 6 way of having a separate tools palette worked just fine. Thankfully, Acorn still supports the Float inspector palettes in windows option.
Previously:
Acorn Design Liquid Glass Mac Mac App macOS Tahoe 26
Juli Clover (Hacker News):
The smarter, more capable version of Siri that Apple is developing will be powered by Google Gemini, reports Bloomberg. Apple will pay Google approximately $1 billion per year for a 1.2 trillion parameter artificial intelligence model that was developed by Google.
[…]
Apple will use Gemini for functions related to summarizing and multi-step task planning and execution, but Apple models will also be used for some Siri features. The AI model that Google is developing for Apple will run on Apple's Private Cloud Compute servers, so Google will not have access to Apple data.
John Gruber (Mastodon):
Nothing I’ve seen from kicking the tires with Anthropic’s own app and Google’s Gemini app (and my daily use of ChatGPT) suggests that Anthropic is significantly better than Gemini or ChatGPT (or vice versa). They’re all clearly near each other technically. Siri, and today’s Apple Intelligence, is at least two generations behind. Maybe worse.
[…]
So I don’t think there’s any reason to think that Apple partnering with Google for a version of Gemini that runs on Apple’s Private Cloud Compute infrastructure is “settling”. It’s more like choosing between a Mercedes and a BMW, and maybe you like the Mercedes a little more after test-driving both, but you’re getting a way, way better deal from the BMW dealer so that’s the one you buy.
Because if Gurman’s sources are right and this deal is for around $1 billion per year, that’s an amazing deal for Apple. Remember first that Google pays Apple over $20 billion per year for web search traffic acquisition fees from Safari users. So one way to look at it is that Apple is getting access to its own private instance of Gemini in exchange for a 5 percent reduction in the fees it collects from Google for Safari search queries. Another way of looking at it is that Google has reportedly invested over $100 billion developing its AI capabilities. Apple getting access to the fruits of that labor for $1 billion per year seems like such a steal that it makes me wonder why Google agreed to it.
This seems like a win-win as far as it goes, but I maintain that the main problem with Siri is the unreliability and slowness of its infrastructure, and it’s not clear that this would help with that.
M.G. Siegler:
While this news isn’t exactly new – it has been known for a while that Apple was doing a sort of “bake off” internally to potentially find a third-party partner to help fix their AI efforts – and we even knew that Google was likely in pole position, it’s still reassuring to read a report with actual numbers and potential timetables. That suggests a deal that is indeed at the finish line, if not already over it. And it makes a new Siri – an actually working Siri – possible in the Spring of 2026.
[…]
Apple may not have wanted to pay Anthropic $1.5B a year to use Claude but $1B a year to a partner that is paying you $20B+ for that Search deal? That can be just an in-kind deal! “Google, you know that $25B you owe us this year? Make it $24B, but we’ll take a custom build of Gemini. Deal?”
[…]
And while the “walled off” aspect is clearly a must for Apple here, you could also imagine that the company may be willing to share some data – fully anonymized, of course – back to help constantly improve the model. And that may speak to why Google would want to do this deal (well, that and the money).
I see speculation that both sides would want to keep the deal secret, but would that be permissible under the current privacy policy?
Apple service providers are obligated to handle personal data consistent with this Privacy Policy and according to our instructions. They cannot use the personal data we share for their own purposes and must delete or return the personal data once they’ve fulfilled our request.
They have this elaborate Private Cloud Compute system, but then they’re going to purposely break out of that box and it’s OK because everyone assumes that they properly anonymize the data?
Previously:
Apple Intelligence Google Gemini/Bard iOS iOS 26 Privacy Private Cloud Compute Rumor Siri
Tim Hardwick (Hacker News, Slashdot):
Apple on Tuesday released the first beta of iOS 26.2 to developers, and it appears that the software will allow users in Japan to install alternative app marketplaces on their devices when it is released to the public in December.
According to a post shared on X by @Tzzlala, iPhones running the beta in Japan are able to install alternative app stores like AltStore PAL and Epic Games, and download apps from them, though Fortnite in-app purchases are currently region-blocked by Epic.
I remain ambivalent about App Marketplaces. They’re certainly a step forward for the availability of apps, but they may end up forestalling better options. I would rather see full sideloading via the Web with notarization optional.
Juli Clover:
With iOS 26.2, Apple is adding a prompt that allows iPhone users in Japan to select a preferred search engine. As noted on Reddit, the option to choose a search engine comes up after installing iOS 26.2 for the first time.
iPhone users in Japan can select from Bing, Google, DuckDuckGo, Yahoo Japan, or Ecosia, the same options available globally in the Safari settings.
No Kagi and still no way to add true custom search engines.
Previously:
Antitrust App Marketplaces App Store iOS iOS 26 Japan Sideloading
Fatbobman:
As Swift 6 gradually gains adoption, this problem becomes increasingly prominent: developers want to benefit from the concurrency safety guarantees provided by the Swift compiler, while struggling with how to make their code meet compilation requirements. This article will demonstrate the clever use of MainActor.assumeIsolated in specific scenarios through an implementation case with NSTextAttachmentViewProvider.
[…]
We seem to be caught in a dilemma: we need to construct UIHostingController in MainActor, yet we cannot assign the constructed view (UIView) to self.view within MainActor.
[…]
Looking at MainActor.assumeIsolated’s signature, we can see that this API provides a MainActor context for its trailing closure. This means we can “synchronously” run code that can only execute in a MainActor context within a non-MainActor synchronous context, without creating an async environment, and return a Sendable result.
[…]
I still hope we can move past this somewhat “chaotic” transition period soon. Perhaps in a few years, when numerous official and third-party frameworks have completed their Swift 6 migration, we’ll finally enjoy a more relaxed safe concurrent programming experience.
Matt Massicotte:
I consistently find the @preconcurrency attribute to be confusing. But, I’m tired of that. Let’s just, once and for all, get a better handle how to use this thing.
[…]
It has three distinct uses. And while they all apply to definitions, the details are quite different.
Jesse Squires:
UIKit provides two diffable data source APIs, one for collections and one for tables.
Recently, while working on ReactiveCollectionKit, I noticed that the APIs were updated for Swift Concurrency in the iOS 18 SDK, but the annotations were inconsistent with the documentation.
[…]
I reached out to Tyler Fox from the UIKit team on Mastodon to ask if this was a mistake. As it turns out, it is not a mistake and his reply was incredibly helpful and insightful. For posterity and documentation purposes (and because social media is ephemeral and unreliable), I’m going to reproduce his entire response here[…]
Wade Tregaskis:
These might seem pretty similar – you’d be forgiven for assuming it’s just a convenience to put @MainActor on the protocol overall rather than having to repeat it for every member of the protocol. Less error-prone, too.
But, you generally shouldn’t do that. They are not equivalent.
The first form is not merely saying that all the members of the protocol require a certain isolation, but that the type that conforms to the protocol must have that isolation. The whole type.
Matt Massicotte:
Further, as far as the compiler is concerned, there is an actor boundary both going into and returning from assumeIsolated. This means you cannot work with non-Sendable data here and that can be an enormous pain.
[…]
Before Swift 6.0, dynamic isolation was the only option. And before Swift 6.2, I think that preconcurrency conformances were the best tool for handling protocol isolation mismatches. They address pretty much all of the weakness of the nonisolated-assumeIsolated thing. But they just feel funny.
[…]
Swift 6.2 allows us to express this idea directly, by constraining a conformance to be valid only for a particular global actor.
What we now have is exactly what we want. A MainActor type that is Equatable in that context only. This is not the same as a true, unconstrainted Equatable, because those work everywhere. It’s a little like defining a new, special variant of that protocol right in line at the conformance declaration site.
[…]
But remember, not all protocols are compatible. And making this entire thing implicit makes the problems even more surprising. Don’t get me wrong, I really like isolated conformances and am very happy to see them come to the language. But they are not a magic bullet (and neither is MainActor-by-default).
Lukas Valenta at mDevCamp (Mastodon):
The talk focuses - as the name suggests - to strategy to migrate the project from Swift 5 compilation mode to Swift 6. We will discuss several issues anyone will encounter to have project that compiles under Swift 6 mode, such as issues with Combine and Async publishers, DispatchQueue.main precondition queue checks, working with older APIs that predate the concurrency, as well as a debate whether it is all worth it. I will also mention the transition of not only the project itself but also a story of external dependencies, some of which written by me, and how did the migration in the libraries took place.
Previously:
Cocoa iOS iOS 26 Mac macOS Tahoe 26 Programming Swift Concurrency Swift Programming Language
