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…
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.
SpamSieve 3.3.1 is an update of my Mac e-mail spam filter that improves the filtering accuracy and includes various optimizations, fixes, and updates for macOS 27. Some interesting engineering issues were:
I’m still supporting macOS 10.13, but the app can now build with the macOS 12 deployment target in preparation for Xcode 27. The way Swift handles calling deprecated APIs remains annoying. You need workarounds like protocols to suppress a warning in a particular region of code. Often, I am updating to a newer API, but I want to continue using the old one on earlier versions of macOS. Right now I am heavily testing on macOS 26, so I would like to only deploy the new code there. Sometimes the initial versions of APIs are buggy, and I don’t want to have to retest every feature on every version. But Swift doesn’t like me to gate the calls to macOS 26 and later if the new API was actually introduced in, say, macOS 11.
The most risky update was probably switching to the Swift API for Scanner. This is tricky because the current scan position changes from being based on UTF-16 indexes to String.Index. And in some cases my code was intentionally scanning into the middle of a combining character. I was really glad to have extensive tests here.
Recent versions of Tahoe introduced a Core Data bug that broke save recovery (when invalid Unicode can’t be written to the database and we have to fix it up first). When the error comes in, SpamSieve looks under the NSDetailedErrorsKey key, but the value of this key is "NSDetailedErrorsKey" while the actual error info is under the key "NSDetailedErrors".
Database corruption combined with a Core Data bug and two Swift behaviors were causing crashes. The root problem, I think, is that in this situation Core Data neglects to set the error pointer for -[NSManagedObjectContext countForFetchRequest:error:]. Normally, Swift would detect this and throw a generic nilError. However, this method signals errors by returning NSNotFound instead of nil. It’s annotated as swift_error(nonnull_error), which I think means that Swift doesn’t even look at the return value, only the (unset) error. So my code was receiving NSNotFound on the non-error path, treating it as a real count, and doing some math with it, which (by default in Swift) leads to a crash if there’s overflow. Now my code checks for NSNotFound and uses Int.addingReportingOverflow().
I reimplemented Core Data batch fetching because of two problems with the fetchBatchSize option. First, it logs spurious errors when fetching from multiple stores at once. Second, it leads to high memory use. It will load objects in batches, but it never releases the earlier batches. You can manually refault objects that you no longer need, but it will still hold onto the full object shells, which can add up. My implementation only holds onto IDs, and it can fetch the IDs using a different context than the objects to push more work to background threads.
I’m now using String.makeContiguousUTF8() in various places to avoid slow iteration of bridged strings.
There was a regression where some menu code could crash on macOS 10.13. -[NSMenu setItemArray:] is only available on macOS 10.14 and later, whereas the getter is always available. With old Objective-C, the two methods could be annotated with separate availabilities. The Objective-C property syntax doesn’t allow this, so there’s no way for the compiler to flag calls where the setter is missing.
The AppleScript support works much better with large data sets. The key, I think, is to never return an array to Cocoa for a scripting property/element. First, if you give it a lazy array it will sometimes try to access all the elements even if it only needs a few. And, second, AppleScript will run out of memory if the array is too large. By using indexed accessors, you can maintain laziness and only convert one object to a descriptor at a time. By caching a batch-fetching collection, you can limit the number of fetches and respond quickly when AppleScript requests individual objects.
Bringing Swift Package Index to Apple allows us to build on its strong foundations while preserving its vision and expertise. Together, we’re building a comprehensive package registry to serve the Swift community’s evolving needs.
[…]
Swift Package Index will continue to operate as it does today. You can continue to rely on it to discover packages, check compatibility, and explore documentation. As we embark on this new phase, our goal is to accelerate development and introduce new features that make discovering and evaluating packages even better.
Discover the latest language advancements, including updates for everyday ergonomics, improved concurrency, and safer high-performance code. Explore workflow and language interoperability improvements and updates in embedded Swift.
Build engaging live experiences with gRPC in your Swift app and backend. gRPC is an open-source RPC framework designed for high-performance, bidirectional streaming APIs. Explore how the gRPC Swift package provides a modern, safe runtime built with Swift concurrency.
Bring NumPy-style computing natively to Swift with MLX Swift. Discover how to eliminate cross-language friction in your machine learning workflows by handling image processing, tensor operations, and neural network training in a single, type-safe environment. Explore the APIs that let you leverage GPU acceleration while enjoying the compiler, tooling, and debugging experience you already know.
Join us online for a deep dive into WWDC26 with Apple engineers and designers to ask questions, get advice, and follow the discussion about the week’s biggest Swift announcements.
There’s a voting system. And that means a number of questions weren’t selected. This time I copied those down and I thought it could be fun to take a shot at answering the ones that are more in my area.
The Swift dependency scanner has been optimized to avoid redundant setup work and header searches when looking up Clang modules during a single dependency-scan action, substantially improving scanning performance.
As a consequence of this change, every Clang module reachable from a single Swift dependency-scan action must have a unique module name. If two module maps visible to the same scan declare a Clang module with the same name, the scan may report an error.
[…]
System now provides Swift APIs for the C stat, lstat, fstat, and fstatat system calls. This includes a new Stat type with initializers from FilePath, FileDescriptor, or a C string; FilePath.stat() and FileDescriptor.stat() instance methods; and supporting types (FileType, FileMode, FileFlags, UserID, GroupID, DeviceID, and Inode).
The new isTriviallyIdentical(to:) method offers a guaranteed-fast way to check two objects for equality. It is essentially an optimised version of the existing equality condition provided by Equatable and the == operator. It’s useful because it guarantees O(1) time complexity, whereas == makes no formal guarantees at all (and for many types is O(N) or worse). But unlike the existing identity comparison operator === – also O(1) – it promises to do more than just tell if two objects are the exact same pointer, and it works on value types (not just reference types).
[…]
These new types generalise the existing patterns of borrowed and mutable references, that have previously existed in Swift in much more restricted forms (e.g. inout parameters are essentially MutableRef parameters, and Span & MutableSpan are array equivalents).
There’s now a built-in function for demangling Swift symbol names, in the Runtime module (that’s bundled with the Swift toolchain, alongside the stdlib etc).
As Apple has aligned OS version numbers across platforms, Swift 6.4 takes the next step by letting you collapse repetitive availability attributes into a single anyAppleOS token.
[…]
There are situations where you need to call a deprecated API while you plan a migration, or audit a critical function for unsafe usage, without letting those concerns bleed into the rest of the project. The new @diagnose attribute handles both cases.
[…]
Some work should complete even after a task is cancelled, like flushing a file to avoid corruption. withTaskCancellationShield wraps a region where Task.isCancelled always returns false.
Swift 6.4 improves error handling for unstructured tasks through SE-0520: Discardable result use in Task initializers. The change helps you catch a subtle bug: creating a throwing task and then ignoring its returned task handle.
I thought it would be a good time to detail some of the type checker performance improvements we worked on since I shared the type checker performance roadmap last year. I’m also going to outline a couple of things we plan on looking at next.
Update (2026-07-09): I was optimistic about improvements to the type checker making compilation faster, but I found that compiling my predominantly Swift project with Xcode 27 Beta 3 was only 0.3% faster than with Xcode 26.6. I wonder if there’s some extra setting I’m supposed to enable.
Swift 6.3 introduces the @c attribute, which lets you expose Swift functions and enums to C code in your project. […] @c also works together with @implementation. This lets you provide a Swift implementation for a function declared in a C header[…]
[…]
Swift 6.3 introduces module selectors to specify which imported module Swift should look in for an API used in your code. If you import more than one module that provides API with the same name, module selectors let you disambiguate which API to use[…]
[…]
Provide pre-specialized implementations of a generic API for common concrete types using @specialize.
[…]
Guarantee inlining — a compiler optimization that expands the body of a function at the call-site — for direct calls to a function with @inline(always).
[…]
Expose the implementation of a function in an ABI-stable library to clients with @export(implementation). This allows the function to participate in more compiler optimizations.
Discover the latest enhancements to SwiftData. We’ll show you how to persist custom and third-party types using Codable, and group fetched data into sections in your SwiftUI app. We’ll also explore how to observe data store changes anywhere else using ResultsObserver and HistoryObserver, giving you the flexibility to drive powerful state objects and react precisely to model updates.
Again, there seems to be nothing new in Core Data this year, nor any communication about it. There’s still no interoperability for object IDs. The SwiftData changes seem fine but don’t really address the new framework’s deficiencies relative to Core Data. It seems like there are still basic problems with threading. I just don’t understand how Apple is deciding what to prioritize with this framework.
With SwiftUI, the bones seem questionable, but at least we can see that Apple is full steam ahead, with substantial progress to address limitations and pain points. SwiftData seemed to have better bones and is much less ambitious. Getting it right seemed like just a matter of follow through. But, for some inexplicable reason, it seems to lack the resources and/or urgency to reach its potential. And even though SwiftUI is clearly the chosen one, AppKit remains in development. Meanwhile, Core Data seems to be abandoned, even though SwiftData feels more like a side quest than a genuine attempt to supplant it.
The implicit message, for those who have build the core of their app on top of Apple’s old persistence framework, seems to be that Apple is not looking out for their needs. Core Data will surely get maintenance to the extent that Apple’s own apps need it, but there’s no evidence of a future or even a migration plan. The answer, I guess, is third-party frameworks, but that’s not an easy migration, either, since none is even as close a match as SwiftData.
Experience SwiftData in action as we add persistence to an existing app. We’ll show you how to define your data models and seamlessly integrate persistent data with SwiftUI. You’ll also learn foundational skills for managing your app’s state using this expressive, declarative API.
Join us online for a deep dive into WWDC26 with Apple engineers and designers to ask questions, get advice, and follow the discussion about the week’s biggest SwiftData announcements.
SwiftData predicates can now work directly with enum values, resulting in cleaner models and simpler query code.
[…]
In iOS 27, Apple introduced support for compound predicates through the Predicate(all:) and Predicate(any:) initializers, making it easier to build queries dynamically based on user input.
I’m not sure why that took so long.
The framework is gradually moving beyond simple demos and becoming easier to use in larger, more sophisticated projects.
[…]
iOS 27 is the first release where many of the framework’s early rough edges have started to disappear.
Compared with @Query gaining support for section fetches, and ResultsObserver enabling observation of query result changes outside views, I am more interested in @Attribute(.codable). It provides a clearer storage intent and gives developers a way to avoid falling into the black box of composition.
Of course, @Attribute(.codable) is not a silver bullet. It is more like a clearly defined escape hatch SwiftData provides for opaque Codable types: suitable for storing external types that you cannot model yourself, but still genuinely need to persist. The cost is that this content cannot participate in SwiftData’s predicate, sort, or migration awareness. Precisely for this reason, its value lies not in being “more powerful,” but in being “more explicit.”
However, SwiftData still does not provide cloud syncing for public / shared data, nor have I seen a clearer signal of performance improvements. These issues will continue to limit its adoption. For many developers, SwiftData this year feels more like it is filling key gaps rather than making a leap significant enough to fundamentally change confidence in it.
Codable types in SwiftData seem pretty lame given that SQLite absolutely does have JSON support and does support queries on it?
But the funnier thing in the MKMapItem.Identifier example is that MKMapItem.Identifier is a RawRepresentable==String, so it could actually be stored as a String in the store.
AsyncImage now automatically caches downloaded images using HTTP caching protocols, allowing servers to control caching behavior via standard headers.
[…]
Xcode 27 introduces a new @State implementation that avoids this repeated evaluation. This new behavior back-deploys to iOS 17 aligned OSes. The new @State is implemented with a Swift macro. It is largely source compatible with the property wrapper version, with a few exceptions.
[…]
Text views now support TextRenderer.
[…]
In apps built with the 27.0 SDKs, the new ReadableDocument and WritableDocument protocols support asynchronous reading and writing, progress reporting, and direct access to document URLs. New DocumentGroup initializers that adopt these protocols let you disable document creation for editing-only apps and present custom UI before any document is opened.
[…]
TextField respects custom font and color styling applied to its prompt.
[…]
List accepts drops in two cases that previously didn’t work: drags with compatible transfer representations are accepted into reorderable content even when the .reorderableItem transfer type isn’t present, and a .dropDestination(…) modifier declared on a list item now performs the drop.
Build your project in Xcode 27 or later to construct type-agnostic content from closures that you mark with ContentBuilder, which serves as the unified replacement for type-specific builders like ToolbarContentBuilder and CommandsBuilder.
Use the visibilityPriority(_:) modifier to prioritize important toolbar actions so SwiftUI keeps them visible as space shrinks, moving lower-priority items to the overflow menu first.
[…]
Present an alert or confirmation dialog from an optional data item or error object, and use that data to produce the content and title[…]
Explore the latest additions to SwiftUI and discover how they can improve your apps. We’ll introduce a new Document protocol with direct disk access and snapshot-based diffing for building high-performance apps; new APIs for reordering content in lists, grids, and sections; and toolbar enhancements including visibility priority and auto-minimizing behavior. We’ll also cover expanded presentation APIs — including swipe actions on any view — plus AsyncImage caching improvements and lazy state initialization for Observable types.
Discover how to incrementally adopt SwiftUI in your existing AppKit or UIKit app. We’ll show you how to use the Observation framework to automatically update your views, integrate SwiftUI components into an existing view hierarchy, and bring gesture recognizers into SwiftUI. We’ll also explore how to add complete SwiftUI scenes to your app without changing your overall architecture.
Discover the inner workings of lazy stacks in SwiftUI. We’ll explore how LazyVStack and LazyHStack estimate sizes, lazily load subviews, and prefetch content to deliver smooth scrolling experiences. We’ll also cover advanced performance optimizations, state management best practices, and tips for precise programmatic scrolling. To get the most out of this session, we recommend basic familiarity with SwiftUI layout using stacks.
Discover how to craft rich, custom experiences by creatively composing SwiftUI layout and graphics APIs. We’ll show you how to break down complex designs and use a creative pipeline to chain simple building blocks together. Learn how to draw with layer shaders, animate with timelines, and anchor views with alignment guides.
Follow along as we build a game of Solitaire to explore the latest drag-and-drop capabilities in SwiftUI. We’ll show you how to use the new reordering API to let people arrange content, implement drag containers to move multiple items at once, and customize the drag-and-drop lifecycle to fit your app’s rules.
Up until now it was a property wrapper conforming to the DynamicProperty protocol, but in Xcode 27 it becomes a Swift macro. In this post we will look at what the change means for @Observable models stored in @State.
SwiftUI also introduces a new prominent tab role. You can use the prominent role for trailing-separated tabs, similar to search.
[…]
Document-based apps get a refreshed look and feel, along with a performance boost. It looks like Xcode has started using these improvements, which might explain why we see so much work around document-based apps this year. And finally, Xcode introduces SwiftUI Specialist and What’s New in SwiftUI skills for agentic coding in Xcode.
For me, the biggest change in SwiftUI comes from its comprehensive support for document-based apps. It not only adds a large number of new APIs, but also shifts the mental model toward “observable document objects + asynchronous snapshots + dedicated readers / writers.” This is clearly better suited to complex document apps, and it also aligns more closely with the overall evolution of modern Swift around Observation and Concurrency.
The sessions also mentioned that SwiftUI continues to optimize layout- and container-related implementations, bringing noticeable performance improvements in some scenarios. This is an improvement developers have urgently needed. However, SwiftUI still does not provide the ability to create custom Lazy containers, which remains a clear disappointment.
iOS 27 introduces new reordering APIs that work with any container. We can mark dynamic content with reorderable() and define the scope of the interaction with reorderContainer(for:). SwiftUI handles the drag preview, insertion placeholder, and drop animation, while our code applies the resulting change to the model.
SwiftUI’s drag container APIs are also now available on iPhone and iPad, after previously being limited to macOS. They let us make items in a collection draggable without making the collection reorderable, and include multiple selected items in the same drag. The APIs also support lazy generation of transferable values and drag-session observation.
I love the new #SwiftUI Text selection but without a way to make selection span multiple Texts in a group, it doesn’t really address our needs at Linear – here’s hoping we see an update in a later seed 🤞
The NavigationTransition protocol has been available in SwiftUI since iOS 18, letting us control how views animate when pushed onto a NavigationStack and when presenting sheets and full-screen covers. We specify the transition using the navigationTransition(_:) modifier on the destination or presented view, and SwiftUI uses it instead of the default animation for that context. Before iOS 27, SwiftUI provided two built-in conforming types: AutomaticNavigationTransition, used via the automatic static value, which defers to the system default for the current context, and ZoomNavigationTransition, used via zoom(sourceID:in:), which animates the presented view expanding from a source view marked with matchedTransitionSource(). iOS 27 introduces CrossFadeNavigationTransition, a new built-in transition that cross-fades between views without requiring a source, and adds AnyNavigationTransition, a type eraser that lets us select a transition at runtime.
The last few years watching WWDC has been a mixed experience for me, because I honestly believe Swift and SwiftUI are actively either bad or being made worst.
Yet every year, the problems I have with them are doubled down on, not improved.
The FB21333309 cache bug I submitted is now confirmed to be fixed on iOS 27.
Instead of introducing a new CacheKey like I suggested, SwiftUI team choose to move the intensity payload out of the FeedbackType enum to a new Payload enum and add a new payload var to SensoryFeedback storage.
A few weeks ago I realised that most iOS jobs require knowledge of SwiftUI. So I started to rebuild my Mastodon client in SwiftUI. Then I got an offer for a new job and accepted it.
This means I can get back to working on the ObjC version. Feels good. :)
iOS 27 adds new AsyncImage initializers that accept a URLRequest instead of a URL. We can now configure request headers, cache policy, and timeout interval while continuing to use the built-in loading and phase handling provided by AsyncImage. A new asyncImageURLSession(_:) modifier also lets us provide the URL session used by asynchronous images in a view hierarchy.
Seven years after its blockbuster 2019 announcement, SwiftUI was supposed to be the mature, production-grade future of cross-platform UI development on all Apple platforms. Instead, SwiftUI feels like a perpetual beta, even in 2026. In this deep dive, I break down why the initial excitement has given way to deep professional frustration for senior engineers. I analyze the systemic issues with performance and layout predictability, the chaotic state of SwiftUI’s ever-changing data flow, and the frustrating lack of backward compatibility that forces developers into a nightmare of shims and workarounds.
Through real-world examples—including Apple’s own SwiftUI tutorial (which is broken) and a head-to-head performance comparison with UIKit (guess who wins)—I demonstrate how SwiftUI trades precise engineering for an illusion of convenience.
Beyond the code, this video explores a broader, more concerning shift in Cupertino: a transition away from the uncompromising craftsmanship of the original era of Cocoa, Aqua, and Auto Layout toward a modern corporate culture of “good enough” products.
Login
