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.
Apple now requires iOS and iPadOS apps uploaded to App Store Connect to target iOS 13 or later, a rule in effect since September 9, 2026. Apple’s submission page adds that starting April 2027, iOS and iPadOS apps must be built with the iOS & iPadOS 27 SDK or later and target iOS 15 or […]
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.
In the Duo dev video, they describe how text buttons can’t be moved to the new vertical sidebar, as opposed to icon buttons.
I wonder if that’s one of the reasons Liquid Glass pushed hard for icon buttons, even though these are harder to understand; they make the vertical layout possible at all.
I think the problem with the iPhone Duo for developers is mostly that it does not create any new opportunities in the form of a new market or a new audience.
On iPhone Duo, navigation controls, toolbar actions, and tabs can move into a shared vertical bar along the edge of the display, leaving more vertical space for content. Apps built with the iOS 27.1 SDK get this adaptation through standard containers such as NavigationStack, NavigationSplitView, and TabView. We continue to declare toolbar actions in their usual placements, and SwiftUI determines how to present them in the current context.
I was going through the iPhone Duo specs and realised the inner screen has a different pixel density to the outer screen. The inner 7.6-inch folding display runs at 1878×2670 and 430 ppi, while the outer 5.4-inch display runs at 1398×2034 and 460 ppi.
The iPhone Duo remains interesting, and is clearly a technical tour-de-force that is the outcome of deep thinking about what a foldable phone can be. But the things that sparkle in my mind when I consider it is just the details. They are very important details that yield a noticeably different product, but they are sprinkles on top of a downward slope in user interface design at Apple that does not care any longer about what users or developers want. All that's important is for this year's device to uproot fundamentals and demand that everyone conform to an arbitrary new intuition.
I don’t remember seeing this mentioned anywhere, but you have to be careful about where you place your safe area constraints.
My first pass moved the constraints on scroll/collection views from the superview leading/trailing to the safe area leading/trailing.
[…]
But if you look at Settings and Safari - our only two examples of “what’s right”, you’ll see the scroll indicators are “outside” the navigation bar and hug the edge of the device bezel.
Isso porque, a princípio, haverá muitos apps que não aproveitarão o novo tamanho de tela caso sejam antigos ou se os desenvolvedores tiverem optado por não seguir as diretrizes da Apple.
Na prática, as versões atuais dos aplicativos serão exibidas em tela cheia na parte frontal e em tela quase cheia na tela interna. No primeiro vídeo publicado pela empresa, por exemplo, ela demonstra que os aplicativos serão alinhados à esquerda para ocupar a maior parte da tela, evitando a área da câmera.
Eis os demais vídeos compartilhados pela empresa:
Ao recompilarem seus aplicativos usando o Xcode 27.1, que será disponibilizado ainda neste mês, os desenvolvedores passarão a contar com controles mais precisos. Seus aplicativos poderão aproveitar toda a largura da tela interna, além de incluir um módulo de pré-visualização que exibe como os apps ficarão nos quatro layouts — fechado em modo retrato, fechado em modo paisagem, aberto na horizontal (paisagem) e aberto na vertical (retrato).
Bezels dos iPhones 18 Pro/18 Pro Max e do iPhone Duo
Por fim, a empresa realizará os chamados iPhone Duo Group Labs, laboratórios que permitem aos desenvolvedores se juntar aos engenheiros e designers da Apple — de forma online — para fazer perguntas e obter orientações.
Microsoft has released Visual Studio Code 1.136, an update to the popular programming editor that previews an Agent Merge feature and introduces two experimental features for agentic coding.
Agent Merge, a preview feature, helps take a pull request across the finish line, Microsoft said. Agent Merge asks an agent to address review feedback, fix failed checks and merge conflicts, and rerun workflows until the pull request is ready to merge. To use Agent Merge, turn on the setting chat.agentMerge.enabled. Then you can enable Agent Merge for a session by running “Enable Agent Merge for Active Session” from the Agents window or selecting the “Agent Merge” button in the title bar.
VS Code 1.136 also introduces multi-root workspaces, an experimental feature that allows developers to work with GitHub Copilot and Claude agents across multiple project folders in the editor window chat view. Agent hooks remain scoped to a single workspace folder, Microsoft said. If hooks are detected in multiple folders, VS Code prompts the user to select the primary folder from which to load them.
Another experimental feature in VS Code 1.136 is chat backgrounds in the Agents window. This allows users to personalize the Agents window with a theme-aware pattern of built-in VS Code icons or an image of their own. Also new for chat are enterprise controls for dictation data. The new controls allow administrators to manage the dictation model and language-model transcript cleanup through enterprise policies. Microsoft said it was possible to require on-device transcription and disable language-model cleanup, so dictation remains available while preventing dictation data from being sent to cloud transcription or a Copilot model.
As those new models start shipping on 22 September, the window for the first public release of Golden Gate has narrowed to 15-22 September, with greatest likelihood on the same day as the arrival of those new Macs.
[…]
At the same time as the release of Golden Gate, we should get Tahoe 26.7 and Sequoia 15.8, but it looks increasingly likely that the final version of Sonoma has been 14.8.9, released on 6 August.
As we prepare to flee from the visual horrors of macOS Tahoe at last, this article is a reminder that it wasn’t the first major release of macOS that has had blatant bugs in its interface, although I suspect it may be unique in that those were intentional. While progress in Golden Gate has been limited, I hope you’ll find it rectifies some of the worst errors of Liquid Glass.
Many Macs will be left behind, as Golden Gate drops support for Intel.
Normally, I update around January. With Tahoe I waited until July. This time, I’m considering updating to Golden Gate soon after its release. The downside is that Xcode 26 doesn’t run on Golden Gate, so I would have to drop support for many older macOS versions (about 3% of my customers’ Macs). But it seems like Apple’s going to force that soon, anyway, as one of the next Xcode 27 updates will likely drop support for Tahoe. I want to get off Xcode 26, both to use the newer SDK and because there are various debugging/testing things that don’t work properly.
I am working on a new app. Right now, I am targeting back to macOS Sequoia. I think that would be a good OS to target but becoming quite old with Golden Gate just around the corner. […] I wonder if I should just target macOS Golden Gate and focus testing on that.
i’m in the exact same boat. i’d really like to stay on macOS 15 and whatever Xcode works there. it means i can still build things in the old UI and mostly Tahoe and GG respect it.
but recent bug reports from beta testers and the inability to see these bugs on my VM has made me feel very stuck here — like apple has purposefully made it difficult to move forward and support older versions too.
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 😧
Adam Engst looks back at HyperCard as an early tool that democratized software creation, then connects its legacy to today’s AI-assisted development. He outlines how Claude helped turn an idea for tracking macOS setting changes into a working Mac app, SetShot. Adam discusses Xcode, GitHub, rapid iteration, and the value of visual feedback in his development process, and how AI lowers programming barriers without eliminating the need for thought, judgment, and effort.
Login
