Apple’s Xcode 27.2 RC requires a Mac running macOS Tahoe 26.6 or later and includes Swift 6.4 with SDKs for iOS 27.2, iPadOS 27.2, tvOS 27.2, watchOS 27.2, macOS 27.2 and visionOS 27.2. According to Apple’s release notes, the build also adds Simulate Shake, Simulate Fall and Simulate Memory Pressure to Device Hub, plus a […]
Xcode also ships two command-line tools for the new format:
xcprojformatter came with the format in beta 2. It’s a formatter for
project files, like swift-format for code: it checks that a
project.xcproj file is valid and rewrites it with sorted keys and
consistent layout.
xcodeproj arrived in beta 3. It reads and edits projects from the
terminal: targets, build phases, groups, build settings, xcconfig files,
and Swift packages.
Xcode 27.1 includes Swift 6.4 and SDKs for iOS 27.1, iPadOS 27, tvOS 27, watchOS 27, macOS 27, and visionOS 27. Xcode 27.1 supports on-device debugging in iOS 17 and later, tvOS 17 and later, watchOS 10 and later, and visionOS. Xcode 27.1 requires a Mac running macOS Tahoe 26.6 or later.
But something has changed: thanks to AI coding agents like Claude Code and Codex, even the most devoted GUI fans are now spending more and more time in the terminal. You kick off a task, the agent does its thing… and then you want to actually see what happened.
That’s where Tower shines, so we felt the path from the terminal to Tower deserved a serious upgrade. With Tower 18, the Tower Command Line Tool (gittower) is no longer just a way to open a repository — it takes you to exactly the place you want to look at.
I’ve been wanting this for 15 years or so. Thanks, AI! You still can’t open a file in Tower by dragging it onto the Dock icon. Nor can you just pass it to gittower and have it figure out which repo it belongs to. But if your working directory is already within the working copy, you can now use gittower to open the file history. I’ve written a script that finds the current file in the frontmost app (BBEdit, Xcode, or Finder) and opens it in Tower.
Today, on its developer blog, Apple announced plans to “…introduce additional controls to ensure that users who genuinely wish to grant an app this extraordinary level of access can only do so with very explicit user action.” The company says it’s doing so because of the dangers posed by AI agents.
Full Disk Access largely sidesteps these controls in order to allow backup apps to function properly on the Mac.
That’s nonsense. Looking at this MacBook Pro, only a handful of apps to which I’ve granted Full Disk Access are backup apps. Others include the Finder replacement Bloom, launchers like Alfred, the wonderful selection utility PopClip, Apple’s own Pixelmator Pro, Setapp, TestFlight, Supercharge, Madden NFL 27 Arcade Edition, Hazel, and many others. It’s a diverse selection of apps covering everything from Apple’s own apps to Mac utilities that are longtime favorites of MacStories readers, and even one Apple Arcade game.
What is valid is that AI agents pose risks if common-sense steps aren’t taken to limit their access to your data. So while the suggestion that Full Disk Access is just for backups doesn’t pass the smell test, Apple’s concerns about agents are well-founded.
The thing that bothers me about this post, though, is that it’s vague. On the one hand, it seems to suggest that users will simply have to jump through additional explicit hoops to grant Full Disk Access to their agents and other apps. On the other hand, claiming that Full Disk Access was designed solely for backup apps raises red flags that could signal that the company intends to restrict the kinds of apps that can use Full Disk Access. I sure hope not.
Even if you want nothing to do with AI agents, the changes that Apple is contemplating could impact a wide variety of the Mac apps you rely on every day. Apple needs to find a way enable reasonable customer protections without hamstringing the Mac’s utility.
macOS 27 broke several things with drag and drop out of Apple Mail. Simply trying to read a URL from the pasteboard will cause a hang while it waits forever for the pasteboard server (FB24803817). The same thing happens when using PasteboardSetPasteLocation() and reading kPasteboardTypeFileURLPromise directly, which I was doing (instead of using newer API) to work around bugs in older versions of macOS. EagleFiler now uses NSFilePromiseReceiver for drags from Mail on macOS 27, which works better, but I also had to work around a bug where Mail would promise superfluous files for which the reader callback was never invoked at all.
macOS 27 also seems to include various regressions when reading PDF and Word files, producing invalid strings containing NUL characters. Also, displaying certain PDF files worked fine on macOS 26 but now crashes.
I also ran into (and worked around) a bug where macOS 27’s NSTextView would get into an infinite layout loop when displaying an attributed string that included images.
Drag and drop from Airmail is still an issue. When using the newer drag APIs, it will often hang Airmail or not produce a file, and this also happens with other apps like Finder as the destination. EagleFiler works around this using older APIs with Airmail and tries to report a helpful error when there’s trouble. Single-message drags work best.
I’ve also been investigating a problem where saving a file with a colored tag in iCloud Drive will, a few seconds later, change the color to gray, but I don’t have a solution for this.
// "<a>" in UTF-16 LE + a single dangling byte
const UInt8 bytes[] = {'<', 0, 'a', 0, '>', 0, 'X'};
[…]
The whole bug is a confusion between bytes left versus UTF-16 characters left. The result is repeated buffer doubling until allocation fails, and a local process crash if the exception is uncaught.
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).
Apple just seeded the first beta of iOS 27.2 to developers for testing. Yes, you read that correctly: iOS 27.2, not iOS 27.1.
[…]
Apple previously announced that the iPhone Duo will ship with iOS 27.1, which means that software version will contain all sorts of references to the device hidden within the code. If an iOS 27.1 beta were to have been released today, it could have spoiled some smaller iPhone Duo details that did not make it into Apple’s event.
iPhone Duo being completely disconnected from the iOS update cycle is very likely why its software features didn’t leak — wouldn’t surprise me if iOS 27.1 is unique to that device, and the rest of the lineup skips it (or gets some security updates, iOS 27.1 in name only)
Developers wanted this SDK a week ago. And when day one preorder buyers start using their Duos on October 23, they’re going to wish Apple had shipped this SDK last week too.
What annoys me about Apple releasing Xcode 27.2 Beta 1 before they release Xcode 27.1 Beta 1 is that there was absolutely no need to release 27.2 Beta 1. They could just have postponed it. Nobody asked for 27.2 Beta 1. What version are we supposed to use? One for releasing, one for Duo, one for fun?
A ideia de rodar o iOS em um smartphone Android parece absurda, mas se tornou realidade com o projeto Hackios.
A proposta é do usuário do GitHub ios-sweet, que substituiu o kernel Linux dos smartphones Android pelo XNU, desenvolvido pela Apple para iOS, iPadOS, macOS, watchOS, tvOS e visionOS.
Quando o dispositivo Android é inicializado, o sistema reconhece o celular como um iPhone X — dispositivo que foi escolhido por não ter o código de autenticação de ponteiros (Pointer Authentication Code, ou PAC), assim como o Redmi Note 10 Pro, da Xiaomi, usado na adaptação inicial.
Já circulam vídeos do sistema adaptado ao Redmi Note 12 Pro, ainda com dificuldades notáveis de desempenho:
Embora o código do iOS permaneça fechado, o XNU do macOS foi liberado pela Apple. Pelos indícios nos documentos incluídos nos arquivos do projeto, o iOS foi adaptado com o auxílio de inteligência artificial (IA).
Depois de ligado, o celular carrega uma imagem intermediária no bootloader, que inicia o XNU em uma partição formatada para simular o armazenamento do iPhone X, com uma cópia do iOS 16.7 — a versão mais recente do sistema disponibilizada ao aparelho.
Alguns apps nativos são carregados junto com a Tela de Início, e os toques e gestos para alternar entre eles (além dos botões de volume e de liga/desliga) são reconhecidos, mas o celular não consegue ativar as câmeras, o som e a GPU 1Graphics processing unit, ou unidade de processamento gráfico., nem usar dados móveis, Bluetooth e Wi-Fi.
Além do Redmi Note 10 Pro, a adaptação já tem versões para o Redmi Note 12 Pro e o LG V60, enquanto outros aparelhos (como OnePlus 7T, Redmi 5 Plus e Galaxy S23 Ultra) foram listados, mas ainda não têm versões disponíveis para download.
Login
