❌

Normal view

SwiftUI Toolbars

8 September 2026 at 21:12

Natalia Panferova:

I thought it would be useful to have a single reference for the different ways we can style the toolbar in SwiftUI on macOS 26.

Phil Zakharchenko:

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:).

Majid Jabrayilov:

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.

Natalia Panferova:

iOS 27 includes a few smaller additions that make toolbar content easier to configure.

We can remove the default padding around an item whose content should extend to its edges with contentMarginsRemoved(_:)[…]

[…]

The status bar is now represented by ToolbarPlacement.statusBar, so its visibility can be controlled through the same toolbar API as other bars[…]

[…]

ForEach now conforms to ToolbarContent, which means we can generate toolbar items directly from a collection[…]

Natascha Fadeeva:

Together, the toolbar APIs let us express the importance of each action while SwiftUI continues to handle the toolbar’s layout across different sizes.

Previously:

The death of ‘hello’: how gen Z – and scammers – put paid to the greeting

7 September 2026 at 15:08

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?

Name: Hello.

Age: 200 years old.

Continue reading...

© Photograph: Posed by model Getty Images

© Photograph: Posed by model Getty Images

© Photograph: Posed by model Getty Images

Did Ancient Campfires “Reprogram” the Human Brain with Flickering Light and Red Wavelengths?

4 September 2026 at 14:03

A University of St. Andrews-led research team has proposed that the red wavelengths of flickering light emitted by early human ancestors’ campfires helped reprogram the human brain to boost social and verbal communication, leading to modern language and storytelling behaviors found only in humans.

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.

The paper “Firelight and the Origins of Spoken Language” was published in Proceedings of the Royal Society. 

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.

Women are giving their partners the ‘Illiterate Boyfriend’ test: ‘Do your best to pronounce these words’

3 September 2026 at 12:00

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”.

Continue reading...

© Illustration: Rita Liu/The Guardian

© Illustration: Rita Liu/The Guardian

© Illustration: Rita Liu/The Guardian

TipKit for the Real World

1 September 2026 at 21:09

Craig Hockenberry:

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.

[…]

Eventually I stumbled upon TipUIPopoverViewController which inherits from UIViewController. That should work! […] But it didn’t: the close button on the popover didn’t work.

[…]

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.

Fatbobman:

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.

Previously:

Swift 6.4: Warning for Weak Captures Within Nested Closures

1 September 2026 at 21:08

John Sundell:

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[…]

Previously:

Ending the Golden Era for Backward-Compatible Apps

1 September 2026 at 21:08

Matthias Gansrigler-Hrad:

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.

Ighor July:

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.

Previously:

Update (2026-09-07): Léo Natan:

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.

Previously:

Update (2026-09-11): Nick Lockwood:

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 😧

Mojo 1.0

19 August 2026 at 21:47

Modular (tweet, beta, Hacker News):

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.

Modular (Hacker News):

We are happy to announce that the Mojo🔥 language is now fully open source under the Apache 2.0 license (with LLVM exceptions)! The source code for the Mojo compiler, tooling, and everything else you need to build the language are now available in our modular GitHub repository.

[…]

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.

Abdul Dakkak, Chris Lattner, and Jeff Niu (2023):

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.

Gergely Orosz (2025, tweet):

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.

See also: LPython (Hacker News).

Previously:

❌