Hi, I've been using Xcode with Codex. I have come to the conclusions that the only window I need open 99.8% of the time is the AI conversation window. After working with this setup for almost a month duration and 80 hours of actual work, I don't bother to look at any of the code. I look at the results and guide Codex to design and implement and help debug. The fact that the AI window acts like a standard coding window is a mistake on the Xcode designers part. That window should never be closed or replaced if you happen to try to look at a file. That window is not the main focus for Xcode in the hands of an expert iOS developer. Yes I will place myself in the category, even though I don't know everything about iOS development. The entire approach is a shocking change for me, as I assume it is for others. I'm in awe of how well Codex works with Xcode and/or the MacOS command line tools. This brings up another point, it seems the Codex does most of it's work via the command line. I'm not sure I like this, but the productivity benefits are overwhelming. Codex and likely other AIs need better Xcode support for file access. I'm not sure what that means, but I'll bet Xcode engineers and designers know exactly what I mean. I'm now 10x more productive, working on a full stack project. iOS with SwiftUI and SwiftData and a server component with Vapor and Swift. Working inside a workspace. Killer!!

Hi, This post is coming from frustration of working on using BGContinuedProcessingTask for almost 2 weeks, trying to get it to actually complete in the background after the app is backgrounded. My process will randomlly finish and not finish and have no idea why. I'm properly using and setting task?.progress.totalUnitCount = [some number] task?.progress.completedUnitCount = [increment as processed] I know this, because it all looks propler as long as the app insn't backgrounded. So it's not a progress issue. The task will ALWAYS complete. The device has full power, as it is plugged in as I run from within Xcode. So, it's not a power issue. Yes, the process will take a few minutes, but I thought that is BGContinuedProcessingTask purpose in iOS 26. For long running process that a user could place in the background and leave the app, assuming the process would actually finish. Why bother introducing a feature that only works with short tasks that don't actually need long running time in the first place.

I'm getting this error from inside the TestFlight tab in Appstore Connect. For a MacCatalyst app. This has worked for amost 4 years now I'm getting this error. I did update my version of Xcode to 26.0.1. And I migrated all the project settings it asked me to migrate. I ran the Validation in the Archive window of Xcode. No issues found there.

Hi, I have been building a MacCatalyst versions of an iOS app for years using a separate build that included a specific .entitlements file that excludes the com.apple.security.device.camera. Yet when I now build with Xcode 16.1 that entitlement is included. I have double checked my signing entitlement for my MacCatalyst build it is configured properly. I have check my .entitlement file to ensusre com.apple.security.device.camera is not there. All is as it should be. I have changed nothing, my build flow is the same. App Store Review has prevented the Mac build to be release becuse the com.apple.security.device.camera is set. What can I do to correct this?

I have the following function decleration: func validName<I:Hashable>(name: String, focusState: Binding<FocusState<I.Type>>, fieldToFocusNext: I.Type, fieldToFocusOnError: I.Type, showError: Binding<Bool> ) -> Bool { return true } I'm getting this error on the FocusState binding parameter: Type 'I.Type' does not conform to protocol 'Hashable' It sure seems I have declared it as a Hashable. What and I doing wrong?