… which simply returns tool, because the URL returned is relative to a base URL.
[…]
I’ve always found it not-completely-obvious to newcomers how to get a standard file path string from a file URL and this only makes it more confusing.
There are at least three issues here:
url.path returns an absolute path, but url.path(percentEncoded: false) returned a relative path as of his writing. I tested this on macOS 26, and now it returns an absolute path. The documentation now says, “This function will resolve against the base URL.” It seems the behavior of the method changed without it being documented when, so be careful if you’re deploying to a mix of OS versions.
percentEncoded has a default value of true, whereas path did not return an encoded string. In other words, url.path() and url.path are completely different. So this is another case where Apple updated the API but flipped the default—a good way to introduce bugs.
It’s not obvious how to get the full file system path out of a URL. With NSURL, url.path was natural and did the right thing. Now, the URL equivalent is deprecated.
The natural replacement, url.path(), is wrong. So is Xcode’s recommendation of url.(percentEncoded: false).
url.absoluteURL.path(percentEncoded: false) is correct but verbose.
url.absoluteURL.standardizedFileURL.path(percentEncoded: false) is possibly better but even more verbose.
FilePath(url)?.string uses a newer API but gives you an optional, even though for a file URL it should never fail.
This seems like such basic functionality, but there’s no API that’s the obvious right choice, concise, and ergonomic.
In a dramatic turn of events, the Chromium team has reversed its Obsolete tag, and has decided to support the format in Blink (the engine behind Chrome/Chromium/Edge). Given Chrome’s position in the browser market share, I predict the format will become a de factor standard for images in the near future.
[…]
I’ve been following JPEG XL since its experimental support in Blink. What started as a promising feature was quickly axed by the team in a bizarre and ridiculous manner. First, they asked the community for feedback on the format. Then, the community responded very positively. And I don’t only mean a couple of guys in their basement. Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips, Krita, and many more. After that came the infamous comment[…]
[…]
To top it off, a couple of weeks ago, the PDF Association announced their intent to adopt JPEG XL as a preferred image format in their PDF specification.
JPEG-XL image support is back in the very latest Google Chrome/Chromium codebase. Back in December they merged jxl-rs as a pure Rust-based JPEG-XL image decoder from the official libjxl organization. At the end of December they did more JPEG-XL plumbing with the enums and build flags for the support.
We’re excited to announce that Chrome is shipping decoding support for the JPEG
XL (.jxl) image format starting from Chrome 155. JPEG XL is a next-generation
image format designed to meet the needs of modern web developers and
photographers. It offers 30-50% better compression than JPEG, lossless
compression, built-in HDR support, lossless JPEG transcoding, and more.
In general, we recommend trying both AVIF and JPEG XL to get the best results.
We expect that JPEG XL is most helpful for high-fidelity or lossless
compression, especially of photographic images or in cases in which fine-grained
progressive decoding is preferred.
The type systems provided by mainstream languages have grown vastly more sophisticated, but how much value does that complexity actually provide programmers in practice? I would like to make the case that it is somewhat less than one might think. While at times convenient, invariants can be captured in the type system using a small set of simple tools applied in principled fashion, and while fancy type systems may be convenient, they have misled many programmers by obscuring what is possible to model without built-in type system support. This talk aims to provide a simple shift in perspective, plus a set of concrete design principles, to make modeling invariants in types feel accessible to the working programmer without fancy language support.
I can improve the process of removing backwards compatibility shims by using conditional compilation to remind me when they’re no longer necessary!
[…]
This does mean that the first time we change our deployment target, we’ll get a bunch of compilation errors. But given the nature of how Backport is implemented, this should be a relatively quick process to move past. (And of course, you’re welcome to use #warning instead of #error).
SwiftUIBackports mirrors Apple’s SwiftUI API names, shapes, behavior, documentation, and availability where practical. This keeps app code familiar today, and easy to migrate away from once your deployment target reaches the native API.
Backports are discovered through .backport, the Backport namespace, or backport-prefixed environment values.
Usually, we don’t see many new APIs in intermediate releases like 27.1, but this time is different. Apple introduced several new iPhone Duo-related APIs in the 27.1 release. This week, we will learn how to use all of these new APIs without bumping your project’s target version.
[…]
Here we introduced the toolbarVerticalBehavior function on the Backport type that handles availability checks and calls the new APIs if available or returns a plain view when it is not available.
SpamSieve 3.3.2 is an update of my Mac e-mail spam filter that improves remote training, can export more rule information, and improves uninstallation, help, and more. The most significant news is that Microsoft has changed plans again. They will no longer be preventing users from continuing to use Legacy Outlook and in fact will keep it available for download as part of the combined Outlook app. This gives more time to adapt to their change in plans for AppleScript. Exchange (EWS) support remains an issue. Microsoft is still planning to cut off Legacy Outlook users, and Apple has yet to announce when Mail will support Graph. So far, I’ve not heard that it’s enabled in the macOS 27.2 beta.
We’re participating in a seasonal festival of artisanal software called SummerFest. For a limited time, you can get a 25% discount on new purchases of SpamSieve, EagleFiler, and other top Mac apps from our indie developer friends.
Some interesting engineering issues were:
Updating NSWorkspace APIs introduced a problem because with the old launchApplication(at:options:), the .withErrorPresentation option is off by default, whereas with the newer openApplication(at:configuration:completionHandler:), the promptsUserIfNeeded option is on by default.
Previously, Core Data would strip leading BOMs from NSStrings when saving to a SQLite database. With macOS 27, this happens for Swift Strings, too.
I have lots of unit tests that check for memory leaks. These caught a change where addPersistentStore(type:configuration:at:options:) now seems to return an autoreleased store. Without adding a pool, it looked like there was a leak.
Also, the tests were finding lots of “leaks” because KVO was retaining NSTabView, which retains a controller. Previously, XCTestCase.waitForExpectations(timeout:) would spin the run loop, and everything would get cleaned up. With Xcode 27 and macOS 27, I need to manually spin the run loop before waiting for the expectations.
During a software update, macOS may decide to reload the Dock icon. The application package no longer exists because it’s been replaced with a new version. This wasn’t a problem before because SpamSieve had been drawing to an image in memory and setting that as the Dock icon. Now, with the Liquid Glass–imposed removal of custom Dock icons, macOS tries to load the icon from disk, and rather than handling errors gracefully it will crash. I fixed this by setting an image with a memory representation before starting a software update.
SpamSieve 3.3.1 introduced a crash affecting a small but significant number of users when doing a Core Data fetch of a large number of objects. The private [_PFManagedObjectReferenceQueue _processReferenceQueue:] method was seemingly releasing an object that had already been released. What’s odd is that, as far as I can tell, none of the related app code had changed since the previous version, yet suddenly crashes started happening all the way from macOS 12 through macOS 27. If I had to guess, this was triggered by upgrading from Xcode 26.2 to Xcode 26.6. Maybe Swift’s ARC optimizations are doing something subtly different?
The crash was triggered by an autorelease pool that I had inserted to promptly clean up any temporary objects after a fetch. (The actual fetched objects were returned and used outside of the pool.) Interestingly, both Gemini and ChatGPT were convinced that this is a well-known exception to standard memory management rules. They said it’s never safe to use managed objects outside of a pool they were fetched in because they depend on internal Core Data objects that the pool will have released. I was not able to find any basis for this “belief,” but it was easy enough to test. As expected, removing the pools (during the beta cycle) just made the same crashes happen slightly later.
I think there’s probably something wrong in Core Data’s internal bookkeeping, but this does not seem to be a popular crash (and I’ve never seen it on any of my Macs), so my code must be doing something uncommon to trigger it. My current best guess is that it was related to calling refreshAllObjects() after saving. (I bet there’s some fancy bookkeeping to make that efficient.) I was doing this throughout the app to break retain cycles so that unused objects could be deallocated. But it wasn’t necessary in this particular case because the entity being fetched has no relationships. So far, removing the refresh seems to have stopped the crashes, but I won’t know for sure until more people have been using this version for a while.
Xcode now supports a JSON-based project format (.xcproj) that’s more readable, merge-friendly, and easier for coding agents to edit. Enable it in the file inspector. Projects using .xcproj also open in earlier versions of Xcode 27. Learn more in Updating your Xcode project configuration file format.
[The] new project.xcproj caught my eye. What it replaces is project.pbxproj, the build graph inside the .xcodeproj bundle, not the bundle itself.
[…]
In the age of agents, the drawbacks of pbxproj are amplified further. A great many IDs carry both object identity and cross-references, so an agent modifying a project usually has to locate the right object in a flat table, then update several mutually referencing places in step, all while trying to keep the serialized output faithful to Xcode’s conventions.
[…]
From a flat ID table to a tree that mirrors the UI: instead of dumping everything into objects, it unfolds into structures like files / targets / build-settings, so diffs look closer to the operations you actually performed in the interface;
The direction of relationships is reversed: a file can declare which targets it belongs to via target-membership, so adding a file no longer means editing several mutually referencing places at once;
It does feel like another case of “we’ve quickly done a thing to help AI that we’ve been unwilling to do for years to help humans.” I’m seeing that happen across the industry.
It is very welcome and appreciated, and lots of thanks to the teams involved. It’s also frustrating that it took “it can help AI” to make it happen.
xcode-project-format is a Swift library for reading, writing, and manipulating Xcode’s JSON-based project.xcproj format. It models the format as a rich set of value types nested under a single namespace, XCSchema, so consumers get precise, typed access to a project’s structure instead of hand-parsing JSON.
The goal is to give the ecosystem a shared, accurate model of the Xcode project format — so tools like generators, linters, verifiers, and validators don’t each have to reverse-engineer the format from scratch.
What the community has actually been waiting years for is a project manifest along the lines of Package.swift: something written by people, read by people, and reviewed by people, rather than a more modern encoding of the IDE’s internal database.
The old .pbxproj project format was not XML; it was an old NeXT-style “ASCII” property list — a file format that is surprisingly JSON-like considering that it predates not only JSON, but JavaScript (JSON = JavaScript Object Notation).
Xcode 27 includes Swift 6.4 and SDKs for iOS 27, iPadOS 27, tvOS 27, watchOS 27, macOS 27, and visionOS 27. Xcode 27 supports on-device debugging in iOS 17 and later, tvOS 17 and later, watchOS 10 and later, and visionOS. Xcode 27 requires a Mac running macOS Tahoe 26.6 or later.
Building with Xcode 27 doesn’t work because of some intransparent XCStrings error… and I even can’t check with Xcode 26 anymore because Apple decided to not let me run it on macOS 27…
AI code completion was such a nothingburger, for all of that investment. I don’t even have it turned on in Xcode anymore. If you’re into code completion, you’re into using Codex and Claude, so why would you ever use it now.
The built-in Xcode stuff has pretty much never worked at all for me. I either get errors or it does nothing.
The toolbar id creates a stable customization domain, and each item id gives the framework something stable to persist when the user adds, removes, or reorders controls. This identifiability of toolbar items is a requirement for customization. Under the hood, when SwiftUI inevitably bridges your toolbar contents to NSToolbar, these identifiers will be directly translated to the NSToolbarItem’s itemIdentifiers.
As we continue the migration to a customizable toolbar, we are likely to encounter a few surprises related to this model.
[…]
After a closer inspection, and perhaps a few minutes of digging through the documentation, we come to the bleak realization: there is no customizable ToolbarItemGroup API.
[…]
The regular toolbar model and the customizable toolbar model overlap, but they are not interchangeable. You cannot give a ToolbarItemGroup an id, and you cannot place one directly inside toolbar(id:content:).
Let’s take a look at another example. This one is a bit tricky, because on macOS, you will get Action 1 in the top trailing position and the whole group of actions centered in the navigation bar. On iOS, you will get Action 1 pinned to trailing and all other items collapsed.
[…]
The final addition to the Toolbar API is the toolbarMinimizeBehavior view modifier allowing us to minimize toolbars while scrolling up or down. You can minimize tab, bottom, window and navigation bars with it.
With new modifiers SwiftUI gives us a much better balance between system-driven adaptation and explicit control. We can now decide which actions are more important, which items should always stay visible, which groups should intentionally live in the overflow menu, and how toolbars should react to scrolling.
If you’re called by an unidentified number, the advice is to remain silent until you’re sure there’s a human being on the line. Is this the end of an era?
The team, which included researchers from Dartmouth College, said the study builds on earlier theories linking fire and language to the extra hours it added to the day.
However, their findings suggest that the biological changes caused by fire use may have enabled complex language as much as fire-associated behavioral changes, accelerating the evolution of verbal communication away from the ape-like systems still used by modern apes toward more complex, “uniquely human” interactions.
Researchers Wondered if Firelight Reprogrammed the Human Brain
Catherine Hobaiter, a Professor of the School of Psychology and Neuroscience at the University of St Andrews and the lead author of a paper detailing the team’s idea, said she has always been fascinated by the origins of language.
“What was the first word?” the professor asked. “The first story?”
Unfortunately, Professor Hobaiter noted, many questions about the origin of humanity’s complex and diverse forms of verbal communication remain unanswered.
Some earlier research has explored a possible link between the first spoken words and the advent of controlled fire use. However, the team notes that most studies have focused primarily on the extra hours of practical light added to the end of each day.
Curious whether other biological mechanisms also contributed to the evolution of language and complex storytelling behavior, Professor Hobaiter and colleagues examined the effects of sitting around a campfire to see whether the emitted light could reprogram the human brain.
Potential Effects of Red Wavelengths and Flickering Lights
First, the team noted that one potential catalyst emitted by firelight that could help reprogram the human brain for complex language is the color of the light wavelengths emitted by campfires. Specifically, Hobaiter and colleagues noted that campfire light emits almost no blue wavelengths but instead mostly in the visible red spectrum.
Many modern studies have focused on the potentially adverse effects of exposure to blue light wavelengths from modern technology on sleep patterns and overall health. Conversely, the paper’s authors described the red wavelengths emitted from fire as ‘uniquely suited’ for human socializing, “allowing an extension to the day without negatively impacting sleep.”
Another component of firelight the study authors suggest could have reprogrammed the human brain for speech is the way a campfire behaves. Unlike a modern, steady light source, the authors noted that firelight “flickers.”
Hobaiter and colleagues said that neurons in the human brain synchronize firing patterns with external flickering lights. For example, flickering lights in movies and TV shows often come with warnings against possible neurological effects on vulnerable viewers. The research team said this mechanism might also help synchronize the behavior of those seated around the campfire, resulting in a much deeper feeling of connection.
Finally, the researchers noted that firelight emits infrared wavelengths, which may have also contributed to helping firelight reprogram the human brain for complex verbal communication.
Are We the Storytelling Ape?
When discussing the potential impact of their proposal, study co-author Nathaniel Dominy, the Charles Hansen Professor of Anthropology at Dartmouth College, said many of the chemical properties have been well researched. However, Professor Dominy also notes that understanding the properties of light that capture our attention and focus, thereby instilling “harmony and cooperation,” has received far less attention.
“Measuring these features is an exciting part of this project,” the study author added.
Professor Hobaiter agreed, while also noting the conundrum scientists face when explaining why humans speak, when “decades of research with other species has shown us that you don’t need language to learn from each other, to organize where and when to forage, to learn cultural knowledge about tools and songs, to co-ordinate hunting, or navigate social politics.”
“While other species share all these skills, there is a fundamental puzzle: we struggle to find evidence of key differences between human and ape communication,” Professor Hobaiter explained. “And yet, we are surrounded by evidence of human distinctiveness. For all their incredible, rich communication and cultures, no other ape is inventing algebra, writing King Lear, or heading out into interstellar space.”
“So, it’s especially exciting to be able to generate testable predictions, to be able to ask if, at the end of the day, we are the storytelling ape,” the professor added.
Christopher Plain has spent the last six years as Associate News Editor and Head Science Reporter at The Debrief. Follow and connect with him on X, learn about his novels at plainfiction.com, or email him at christopher@thedebrief.org.
People online are distressed at men butchering words such as ‘hyperbole’ and ‘hors d’oeuvres’ – highlighting a gender reversal in ‘intelligence gaps’
There are common non-negotiables we look for in a prospective partner. They should be kind, caring and thoughtful. Having a shared interest helps. So does remembering important dates and anniversaries. But how much does it matter if they know how to pronounce the word “gnocchi”?
Turns out that’s a potential dealbreaker, at least according to a (rather judgy) cohort on TikTok. See: the “Illiterate Boyfriend” trend, which is testing some couples on the app. Users have compiled a list of what are essentially SAT words for women to ask their male partners to read. Many of these men – this is an overwhelmingly heterosexual activity – fail to finish the list unscathed. They trip over entries such as “hyperbole”, “cynicism”, “diaphragmatic” and the oft-butchered French term, “hors d’oeuvres”.
Then, when you look at the sample code, it’s all SwiftUI. At least the sample compiles and runs because it uses a completely different syntax than what was shown at WWDC.
Until you realize that any changes you make are stored in a SQLite database, debugging is very confusing. It’s also easy for your own state to get out-of-sync with the Tip state: there is not a single source of truth.
[…]
Unfortunately, that sample code doesn’t scale well. If you have a view with multiple tips, you’re going to be littering your code with tip instances, observation tasks, and popover controllers. It’s a mess and a clear sign that the TipKit developers didn’t think much about UIKit.
In the previous article, we introduced the basic usage of TipKit. In this article, we will discuss some advanced topics related to TipKit, such as how to fully customize Tip views (not using TipView and popoverTip), how to use TipKit with UIKit, and how TipKit can share data across different applications, as well as how to reuse Tip declaration code. Additionally, we will attempt to address some common questions and concerns about TipKit.
New in Swift 6.4 […] is a warning which is emitted when a nested closure performs a weak capture while the parent closure implicitly captures that object as a strong reference.
At first glance, that new diagnostic could be a bit puzzling, since it might seem unnecessary to have to specify such a weak capture twice (or, alternatively, move it to the parent closure’s capture list), but it turns out that it’s an incredibly useful new warning that can help us avoid a quite common kind of memory management bug.
[…]
Finally, in situations where capturing self strongly doesn’t actually lead to a retain cycle, we can silence the new warning for nested weak captures by explicitly adding self to the outer closure’s capture list, such as when creating a Task within the following example[…]
I don’t appreciate being forced by Xcode 27 to drop support for macOS 10.13-11.0. It’s my decision which OSes I want to support, not Apple’s. Yes, I can keep Xcode 26 around until submissions require Xcode 27, but what then?
Originally, Xcode 27 was documented as supporting Big Sur on Intel Macs, but now the earliest is Monterey.
I’m frustrated, too, but it’s more honest than the recent releases that claimed to support deployment on older macOS versions when Apple clearly hadn’t tested that it actually worked. I filed bugs, and Apple kept responding that they’d fixed it, when they hadn’t.
Using old versions of Xcode isn’t a great solution because they aren’t supported on Golden Gate. Swift also makes it more difficult to call newer APIs when using an older SDK. You can’t just copy/paste a method prototype or constant value and conditionally use it when running on a newer OS.
I eventually found a hidden workaround that changes the errors back into warnings. That is good news, but it does not make the concern disappear. The setting is undocumented, absent from the normal Xcode interface, and currently being tested only in a beta toolchain. The larger question is what Apple intends to enforce when Xcode 27 is final and, later, when App Store submission requirements move to its SDKs.
[…]
Apple’s current Xcode system requirements list Xcode 26 with deployment targets beginning at iOS 15 and macOS 11. Yet developers have been able to enter older targets manually. In an Apple Developer Forums discussion about Xcode 26, an Apple product manager explained that the published deployment target range is aligned with simulator support and on-device debugging. The accepted answer confirms that an iOS 13 target can still build even though it falls below the range in Apple’s table.
My own tests went further. Xcode 26.5 compiled a project targeting iOS 9.0. It warned that the target was older than the supported range, but the build succeeded. On macOS, I have compiled current apps with deployment targets as old as macOS 10.9. Xcode warned me, but it still produced working applications.
[…]
For iOS and iPadOS, staying on Xcode 26 is not a lasting option. Apple has repeatedly made a current Xcode and SDK mandatory for new App Store submissions. […] If any one of those conditions fails, iOS and iPadOS developers will have no normal App Store path for publishing new updates that still support versions older than 15.
Just want to remind you guys that if you move to Xcode 27, the only “officially” supported and sanction Xcode for GG, UIDesignRequiresCompatibility is no longer respected across the 27 OSes (apps built with older Xcodes still are). So you might suddenly find out you have a lot of work ahead of you, adding support for the dreaded Glass. And 27 Glass is not the same as 26 Glass. That can be an issue if you skipped 26 altogether but still want to support it.
I mostly ignored the Xcode 27 betas (mainly due to the barely-usable Device Hub) so I didn’t realize the passive-aggressive prompts to drop support for iOS < 15 that you get when submitting apps is being backed up by Xcode 27 refusing to compile apps at all unless you bump the deployment target 😧
Today, the Mojo language officially reaches 1.0: a milestone the language has been building toward since its first release in 2023. Mojo has grown into a general-purpose language with a vibrant developer community writing their own libraries, tools, and applications on top of it. With Mojo 1.0, developers can now build for the long-term on a stable, production-ready language foundation.
[…]
Importantly, Mojo 1.0 does not mark the end of the language’s evolution, but it is an important milestone on a longer journey. During the 1.x timeframe, changes should primarily be additive, giving developers confidence that the language will not continually shift beneath them. Breaking changes may still be made, but will be managed with care, following the standards of how mature languages (e.g. C++) evolve over time.
The Mojo standard library has been accepting contributions since 2024, and we’re grateful for everyone that has helped advance the language. One learning (particularly in today’s era of AI coding) is that we need to be deliberate about how we handle contributions. As such, we aren’t ready to take contributions to the compiler and tooling. We aim to accept contributions to the compiler and tooling by the end of this year, and we’ll share more details when we can.
This talk will give an overview of Mojo 🔥, a new programming language in the Python family built on MLIR and LLVM. Mojo aims to bridge the programmability and performance gap in systems programming by combining Python’s ergonomics and ecosystem with C++ and CUDA-level performance into a single language. We will describe how Mojo leverages the MLIR and LLVM infrastructures to provide meta-programming, user-defined code transformations, hardware backends, adaptive compilation, and auto-tuning to enable developers to achieve performance without sacrificing programmability.
Chris Lattner is one of the most influential engineers of the past two decades. He created the LLVM compiler infrastructure and the Swift programming language – and Swift opened iOS development to a broader group of engineers. With Mojo, he’s now aiming to do the same for AI, by lowering the barrier to programming AI applications.
I sat down with Chris in San Francisco, to talk language design, lessons on designing Swift and Mojo, and – of course! – compilers.
EagleFiler 1.9.21 is a maintenance release of my Mac digital filing cabinet and e-mail archiving app. It can now capture the selected messages from MailMaven, including all their metadata, and can link back to the original message. The capture key now works with the Helium browser, and importing from Mariner Paperless and Microsoft Outlook is improved as well.
There was an interesting regression caused by the fact that macOS now implements pop-up menus using separate windows (NSPopupMenuWindow) that post their own notifications for becoming key and for resigning key status.
Encrypted libraries need to be converted to APFS, since a future version of macOS will drop support for CoreStorage. You can do this now, or it’s possible that we’ll be able to offer an automatic converter in a future version.
There were more problems with PyObjC importing symbols, this time generic Swift classes that have angle brackets in their names. I had previously added more precise imports to skip over these symbols, which aren’t needed anyway, so it’s a mystery why a few users were still seeing this problem despite using the same macOS versions as everyone else. In any case, I adjusted the PyObjC importer to hopefully avoid problems with all such symbols, even if Apple adds more in future versions.
macOS Tahoe introduced a bug displaying custom folder icons, which was finally fixed in macOS 26.4.1.
Author: Marta Sánchez López, Postdoctoral researcher at Research Centre for Basque Language and Texts (CNRS-IKER) – Université Bordeaux Montaigne. She also collaborates with the The Bilingual Mind Research Group (Gogo Elebiduna), University of the Basque Country.
In our daily life, we perceive many different events around us with different participants involved, such as a woman dancing in a theater, or a man enjoying an ice cream. To produce and understand the sentences that express these events, it is crucial to identify the number of participants involved and the role that each one plays. As in a drama, we have to identify the role that each character has to understand the story.
Agents, patients and experiencers
In some events, there are two characters involved, as in the girl kicks the ball, with the girl and the ball; in others, instead, there is only one, as in the woman dances or the man falls down, with the woman or the man. Each of these participants has a different role. For example, the woman is an agent, because she is doing the action, just the opposite of the man, who is a patient, because he is the one affected. In the case of the girl has fun, this participant has the role of experiencer, the one who experiences the enjoyment.
In psycholinguistics, the mechanisms involved in the processing of agent, patient, and experiencer roles have been investigated through different experiments such as reading sentences while participants’ brain activity or eye-movements are recorded. In these studies, it has been found that agent and patient categories play a crucial role in language comprehension and production. These two roles are used when reading, listening to, and producing sentences, and different mechanisms are involved in their processing (e.g., 12345). Therefore, they form two different categories within the event role repertoire 6. They are two different characters within the drama. However, as I will discuss, there is no experimental evidence for a third character, the experiencer role.
One well-established result regarding the processing of agents and patients comes from experiments where participants are asked to read sentences while their brain activity is recorded by means of electrodes, known as EEG studies. Results of these studies show that the processing of patients elicited an N400 component (a negative brain response that occurs around 400 milliseconds after a stimulus is processed) compared to the processing of agents. This effect is associated with the processing of unexpected elements. For example, when processing the day was breezy so the boy went outside to fly, it is expected to read next a kite based on the preceding context; hence, if an airplane is read instead, as this is unexpected, then an N400 effect appears 7. Something similar happens with the processing of agents and patients: agents are expected, whereas patients unexpected.
Across languages, speakers tend to interpret the first ambiguous noun phrase of a sentence as an agent instead of as a patient, due to the agent preference 8: agents are preferred and are cognitively more salient than patients. Imagine that someone reads the sentence Mary falls down. Before encountering the verb, the reader cannot know whether Mary is an agent or a patient. However, as agents are preferred over patients, the reader interprets that it is an agent by default. Once the verb is reached, there are two options: confirm that Mary is an agent (the expected role) or recategorize it as a patient (the unexpected role). In Mary falls down, it is the second option, Mary is categorized as a patient, because the verb selects this role. This recategorization is reflected in an N400 component. This result shows that agents and patients have different processing mechanisms and that they form two different categories. Furthermore, this effect has been largely found in different languages such as, Basque (Isasi-Isasmendi et al., 2024), Spanish 9, German (Haupt et al., 2008), Hindi (Bickel et al., 2015), or Aïwoo (Sauppe et al., 2023), supporting its robustness.
Therefore, these experimental findings show that there is a preference toward agents over patients. The agent is the protagonist of the show, while the patient plays a secondary role.
What about experiencers?
Linguists have proposed that there are other roles within the event role repertoire, for example, the experiencer role 10.This role corresponds to the participant who experiences a mental state denoted by the verb. Participants of events like loving someone or enjoying an ice cream have this role. The experiencer is the participant who loves or enjoys.
But does experimental evidence show that the experiencer role is a specific role category within the event role repertoire, as agent and patient roles do?
In Sánchez-López (2026), I addressed this question. I investigated whether speakers use a third category, the experiencer role, when processing language. In three reading eye-tracking experiments and in one EEG experiment, I asked Spanish native speakers to read sentences, while their eye-movements and their brain activity were recorded.
In the first two eye-tracking experiments, I compared de processing of sentences with two participants with different combinations of agent, experiencer, and patient roles: (i) María golpea a Juan “Mary hits John”, with an agent (María) and a patient (Juan); (ii) María asusta a Juan “Mary frightens John”, with an agent (María) and an experiencer (Juan); and (iii) María ama a Juan “Mary loves John”, with an experiencer (María) and a patient (Juan).
These two experiments revealed that Spanish native speakers produced higher fixation times on verbs selecting agent-experiencer roles (ii), than on the other two sentence types (i, iii), independently of whether the subject was animate or inanimate (e.g., María/La situación asusta a Juan “Mary/The situation frightens John”). Interestingly, no processing differences were found between sentences selecting agent-patient (i) and experiencer-patient (iii). These findings show that the combination of agent-experiencer involves higher processing cost than other combinations.
But why is the agent-experiencer combination costlier than the others?
A possible explanation could be that the experiencer role is not a specific category within the event role repertoire. As Dowty 11 proposed, agents and experiencers are both grouped within the same category, the one of the proto-agent. Based on this proposal, there are only two roles in the event role repertoire, proto-agent and proto-patient, and proto-agents always become subjects. Hence, in sentences like Mary frightens John, both participants are proto-agents. Since they are both possible candidates to become subject, a competition for subject assignment appears. This competition is reflected in higher processing cost compared to those sentences without competition, sentences with only one proto-agent participant (e.g., Mary hits John or Mary loves John).
To better understand this competition effect, imagine that the proto-agent is the hero of the story and the proto-patient is the villain. In a drama, if there is a hero, there is also a villain. If there are two heroes and no villain in the story, it would be unusual, and probably, it would take more time to understand the story, since this is not expected. Hence, the same happens with sentences like Mary frightens John, which have two proto-agents; this combination is unexpected and it entails higher processing cost than when there is only one proto-agent and one proto-patient.
In another reading experiment using both eye-tracking and EEG techniques, I compared the processing of the three roles, agent, experiencer, and patient again to determine whether this experiencer role behaves like the agent role or not. In these experiments, I used sentences with only one participant involved: (iv) María baila “Mary dances” with an agent, (v) María disfruta “Mary has fun” with an experiencer, and (vi) María se cae “Mary falls down” with a patient. The use of these sentences allowed a more direct comparison of the processing of these roles, since the three roles are subjects. The structure of all sentences is the same (one participant and the verb), and only the event role category changes.
Results revealed that participant looked more at sentences with agents and experiencers than at sentences with patients. Moreover, I found that participants exhibited a preference to interpret the first ambiguous noun phrase (i.e., María) as an agent/experiencer; hence, when they realized that it was a patient instead, an N400 component appeared. But this effect only appeared with patients, not with experiencers, showing that participants processed similarly agents and experiencers, and both different from patients.
What does this evidence show?
These results align with the hypothesis that there are only two role categories within the event role repertoire (Dowty, 1991): proto-agent and proto-patient. Therefore, when the sentences Mary dances or Mary has fun are processed, in both cases, Mary is interpreted as a proto-agent, whereas in Mary falls down, she is interpreted as a patient instead.
All in all, this evidence suggests that agents and experiencers belong to the same role category, the one of the proto-agent. Therefore, when we process language, it seems that we do not differentiate between agents and experiencers, rather we process them similarly. Experiencers are grouped together with agents, being the same character in the event, both proto-agents.
So, proto-agents are the protagonists of the story, the ones that spectators prefer to pay attention to, whereas proto-patients are the secondary characters who complement the story. Regarding experiencers, they do not play a different character in the story, instead, they are also the protagonists.
References
Bickel, B., Witzlack-Makarevich, A., Choudhary, K. K., Schlesewsky, M., & Bornkessel-Schlesewsky, I. (2015). The neurophysiology of language processing shapes the evolution of grammar: Evidence from case marking. PLOS ONE, 10(8), e0132819. https://doi.org/10.1371/journal.pone.0132819 ↩
Gómez-Vidal, B., Arantzeta, M., Laka, J. P., & Laka, I. (2022). Subjects are not all alike: Eye-tracking the agent preference in Spanish. PLOS ONE, 17(8). doi: 10.1371/journal.pone.0272211↩
Haupt, F. S., Schlesewsky, M., Roehm, D., Friederici, A. D., & Bornkessel-Schlesewsky, I. (2008). The status of subject–object reanalyses in the language comprehension architecture. Journal of Memory and Language, 59(1), 54–96. https://doi.org/10.1016/j.jml.2008.02.003 ↩
Isasi-Isasmendi, A., Sauppe, S., Andrews, C., Laka, I., Meyer, M., & Bickel, B. (2024). Incremental sentence processing is guided by a preference for agents: EEG evidence from Basque. Language, Cognition and Neuroscience, 39(1), 76–97. https://doi.org/10.1080/23273798.2023.2250023 ↩
Sauppe, S., Næss, Å., Roversi, G., Meyer, M., Bornkessel-Schlesewsky, I., & Bickel, B. (2023). An agent-first preference in a patient-first language during sentence comprehension. Cognitive Science, 47(9), Article 9. https://doi.org/10.1111/cogs.13340 ↩
Rissman, L., & Majid, A. (2019). Thematic roles: Core knowledge or linguistic construct? Psychonomic Bulletin & Review, 26(6), 1850–1869. https://doi.org/10.3758/s13423-019-01634-5 ↩
DeLong, K. A., Urbach, T. P., & Kutas, M. (2005). Probabilistic word pre-activation during language comprehension inferred from electrical brain activity. Nature Neuroscience, 8(8), 1117–1121. https://doi.org/10.1038/nn1504 ↩
Bornkessel‐Schlesewsky, I., & Schlesewsky, M. (2009). The role of prominence information in the real‐time comprehension of transitive constructions: A cross‐linguistic approach. Language and Linguistics Compass, 3(1), 19–58. https://doi.org/10.1111/j.1749-818X.2008.00099.x ↩
Sánchez-López, M. (2026). Processing proto-agents and proto-patients: Eye-tracking and EEG evidence in Spanish [University of the Basque Country]. 10.17605/OSF.IO/WNAR8↩
Fillmore, C. J. (1971). Some problems for case grammar. In R. J. O’Brien (Ed.), Report of the 22nd annual round table meeting on linguistics and language studies (pp. 35–56). Georgetown University Press. ↩
Dowty, D. (1991). Thematic proto-roles and argument selection. Language, 67(3), 547–619. https://doi.org/10.1353/lan.1991.0021 ↩
Today, humans speak or use signs in approximately 7,500 different languages. However, this figure, impressive as it may seem, represents only a snapshot of a constantly changing history, and questions about the evolution of linguistic diversity have remained among the most elusive for science for decades. How many languages existed before the appearance of written […]
Siri Wolfram Alpha integration helped create one of the defining moments in the early history of consumer artificial intelligence. When Apple introduced Siri with iPhone 4S in October 2011, users were not merely given another form of voice control. They could ask a spoken question and receive a calculated answer rather than a page of search results.
Questions involving mathematics, measurements, dates, nutrition, astronomy and factual comparisons could be routed to Wolfram Alpha, a computational knowledge engine launched in 2009. Siri handled the conversation, while Wolfram Alpha supplied structured information and calculations behind many of the responses.
The experience could feel remarkably advanced for its time. Asking how many days remained before a holiday, comparing the populations of two cities or converting miles into kilometers no longer required opening Safari, entering a query and selecting a website.
That direct path from natural language to a useful answer established an expectation that continues shaping AI products today.
Its technological roots extend to research conducted at SRI International, including work associated with the DARPA-funded CALO project. The objective was to develop systems capable of learning, organizing information and helping people complete everyday tasks.
SRI later spun the technology into Siri Inc., founded by a team including Dag Kittlaus, Adam Cheyer and Tom Gruber. The company released a standalone Siri app for iPhone in early 2010.
The original product was designed around actions rather than ordinary web search. A user could ask for a restaurant reservation, request a taxi, check entertainment listings or search for local services. Siri attempted to understand the intent and connect the request with an appropriate online provider.
This approach was ambitious because the assistant needed to coordinate several different systems. Speech had to be converted into text, the request had to be interpreted, context had to be considered and an external service had to return something useful.
Apple acquired Siri in April 2010. Steve Jobs had personally recognized the potential of moving beyond a collection of apps toward a conversational layer capable of reaching them on behalf of the user.
When the assistant returned as an integrated feature of iPhone 4S, Apple had narrowed some aspects of the original startup vision while making the technology accessible to a much larger audience.
Siri could send messages, create reminders, place calls, manage calendar events, check weather conditions and answer questions. Apple initially labeled the feature as a beta, an unusual decision for a prominent part of a new iPhone launch.
The beta label acknowledged that natural-language interaction remained unpredictable. Accents, ambiguous phrasing, network conditions and external data providers could all influence whether a request succeeded.
Image Source: Google
Siri Wolfram Alpha Made Answers Feel Immediate
Siri Wolfram Alpha became especially memorable because it showed the difference between retrieving information and computing an answer.
A conventional search engine could locate pages containing a formula. Wolfram Alpha could apply that formula to the values supplied by the user. It could interpret units, compare quantities, calculate probabilities and organize factual data into a structured response.
That distinction allowed Siri to appear more knowledgeable than a voice interface simply reading search results aloud.
A request such as “What is 15% of $86?” could return the calculation directly. A question about the distance between planets could produce a value without requiring the user to inspect several websites. Wolfram Alpha could also answer unusually specific requests, including information about aircraft flying overhead when the necessary location and aviation data were available.
The system was not a large language model. It did not generate open-ended prose in the way current AI assistants do. Wolfram Alpha relied on curated data, symbolic computation, algorithms and formal representations of knowledge.
That structure provided an advantage that remains relevant: many answers could be calculated and traced through defined information rather than improvised statistically.
Early Siri combined several specialized capabilities instead of depending on one system to do everything. One provider might supply restaurant information, another could handle maps and Wolfram Alpha could process computational questions.
The assistant acted as the conversational coordinator.
This architecture made Siri seem like one intelligence even though the response could come from a network of separate services. Modern AI platforms have returned to a similar idea through tools, agents and external data connections. A language model may manage the conversation while calling a calculator, calendar, search engine or business system when a task requires reliable external action.
Siri demonstrated that model on a consumer smartphone more than a decade earlier.
A Small Integration Created a Large Expectation
The Wolfram Alpha partnership influenced how people began judging digital assistants.
Before Siri, voice features on phones were commonly associated with rigid commands such as calling a contact or selecting music. Siri invited users to speak more naturally and attempt questions that would previously have been typed into a browser.
The results were inconsistent, but successful interactions changed perceptions immediately. The iPhone appeared capable of understanding intent, reaching into a knowledge system and returning a concise answer through one conversational interface.
That apparent simplicity concealed substantial infrastructure. Speech recognition, language interpretation, location, personal context and external databases all had to work together quickly enough to preserve the feeling of a conversation.
Wolfram Alpha also gave Apple access to expertise that would have taken years to reproduce internally. Stephen Wolfram had spent decades building Mathematica and computational systems before launching the public knowledge engine.
Following the Siri announcement, Wolfram described the integration as a characteristically direct Steve Jobs decision: users wanted access to knowledge and actions without unnecessary intermediate steps.
That idea became more influential than any individual answer Siri provided.
The assistant did not need to show how many services had participated. It needed to understand the request and return the result.
Early Siri Also Revealed the Limits of the Model
The first version of Siri could feel futuristic one moment and frustrating the next.
Some questions reached Wolfram Alpha correctly, while similar wording could trigger a web search or an unrelated response. Siri occasionally struggled to determine whether the user wanted a calculation, a local result or an action inside the phone.
Wolfram Alpha responses were also better suited to some subjects than others. Mathematical and scientific questions matched its computational structure, while casual conversation, current events and subjective requests required different sources.
Network dependence created another weakness. Early Siri processing relied heavily on remote servers, so delays or outages could make a basic request fail even when the iPhone itself was functioning normally.
Those limitations foreshadowed the central challenge surrounding modern assistants. A convincing interface encourages people to ask almost anything, but no single technical system performs equally well across every type of request.
Current generative AI can produce more natural language and handle a wider range of topics. It can also create confident errors when factual grounding is weak. The computational approach represented by Wolfram Alpha remains valuable precisely because some questions require verified data and exact calculation rather than fluent speculation.
The story behind the first Siri steps is therefore not only about an old iPhone feature. It shows that a powerful assistant needs more than a conversational personality. It requires access to dependable tools, structured knowledge and the ability to recognize when another system should provide the answer.
Siri Wolfram Alpha offered that lesson in 2011, long before AI assistants became capable of writing essays, interpreting screens and acting across apps.
Login
