Xcode

You do not need to plug your iPhone in to use it with Xcode. Debugging will likely be slower, but Xcode can communicate with your iOS device wirelessly.

This happens for me too - iPhone Air iOS 26.1 Device. Built with both Xcode 26.0 & 26.1.1. Simulators too.

Same here. All other platform archives work except macOS. No project changes since the last successful archive. A typical Xcode Cloud -> App Store issue, but they're usually fixed sooner than this, or at least acknowledged on Developer System Status

Earlier I wrote: But, honestly, it sounds like a fun weekend project And indeed it was (-: Pasted below is some iOS code that is able to detect how your code is signed using only public APIs. To do this, it uses a sneaky combination of XPC loopback and XPC peer requirement checking. This code comes with a bunch of caveats. Read the doc comment before you use it [1]. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] By my count the doc comments represent well over half the total number of lines (-: import Foundation extension CheckSelfEntitlement { /// Checks whether the current process claims the get-task-allow /// entitlement. /// /// - warning: As explained below, you shouldn’t use this routine but /// instead should use ``isGetTaskAllowTrue()``. This routine exists solely /// to illustrate the following point. /// /// This routine checks for the presence of the entitlement, rather than /// checking for it being present with a particular

I'm afraid you'll have to provide a bit more context. Do you have a specific question that someone could answer? Are you talking about building or installing? For building, the standard process is simple. Xcode > Product > Archive. There is no step two. For distribution, you can choose the Mac App Store or direct distribution. If you choose the Mac App Store, you're done with the installer package at that point. For direct distribution, you'll still need to zip the resulting app. You can do that in the Finder with control-click or double-click and choose Compress. Of course, if you're more of a masochist, there are many, many suggestions from the internet on how to make the process more difficult. You're correct that those procedures can get Kafkaesque in no time. But you don't have to do it that way if you don't want. And if you don't like those procedures, then I don't see the point of attempting them.

I have exactly the same issue without any code changes. Even compiled with Xcode 16.4

Thank you for sharing your post. Have you attempted using the latest Xcode beta? What version of Xcode are you using? The warnings you are receiving indicate that Auto Layout is attempting to resolve conflicting constraints. Since you have not explicitly used Auto Layout in your code previously, it is likely that Auto Layout is relying on implicit constraints generated from the frames and autoresizing masks of your views. When you create views programmatically and do not intend to set constraints manually, such as in the following example: toolbar.translatesAutoresizingMaskIntoConstraints = false

 https://developer.apple.com/documentation/uikit/uiview/translatesautoresizingmaskintoconstraints If your toolbar is embedded in or interactIn contrast to other views, ensure that those views also have the translatesAutoresizingMaskIntoConstraints property set to false and appropriate constraints added. By adopting explicit Auto Layout usage, you will not only eliminate these warnings but also gain