xcode github

Hello, Thank you for your reply. Here are the details we observed: • iOS 18.6.2 (current release): authenticateHandler is invoked consistently — both when the Game Center sign-in UI appears and when the user taps Cancel. • iOS 26.0 beta 1 (first available build): Regression begins here. The Game Center sign-in UI is shown automatically, but pressing Cancel does not invoke authenticateHandler. The app receives no callback. • All subsequent iOS 26 betas (beta 2, beta 3, and the latest beta): Same behavior as beta 1. The issue has been reproducible across every iOS 26 beta so far. • Xcode versions used for testing: • Xcode 16.0 beta 1 with iOS 26.0 beta 1 • Xcode 16.0 beta 2 with iOS 26.0 beta 2 • Xcode 16.0 beta [latest] with iOS 26.0 beta [latest] So the regression is present from the very first iOS 26 beta through the latest beta. To help with investigation, I will provide a minimal sample project that sets GKLocalPlayer.local.authenticateHandler in viewDidAppear and logs w

Clearly Xcode 27 was a typo. My question is whether this behaviour was default or not for new Apps, If Apple expects developers to turn it on then its unlikely that it will end up using the second approach for the main app and any libraries that are overwhelmingly UI-focused.

Hi @RamiroDiaz-Latch, You wrote: In most cases, our code snippet works as expected, and the result is .success. However, we are also encountering other results, such as .denied, .alreadyPresenting, and .cancelled or .notSupported, which cause the Wallet to appear for users. [...] As @EtienneVTS mentioned, the API is intended to be used while an approved app is in the foreground. However, this requirement is indeed documented below: Use this method only in apps that must stay in the foreground when operating near NFC or other RF readers. This method prevents the device from automatically displaying the Apple Pay passes when it detects a compatible reader. This suppression occurs only while the app is in the foreground. The system automatically reenables the Apple Pay interface when the app goes to the background. If the app resumes, the system automatically suppresses the Apple Pay interface again. requestAutomaticPassPresentationSuppression(responseHandler:‍) https://developer.apple.com/documentation

Do devs realise they need to call stop access after resolving a bookmark? It's long been documented, but the reality is that: Most apps only interact with files in a limited/controlled way. Particularly on iOS, app lifetimes tend to be short enough that it hides most mistakes. Explicit start/stop makes it more obvious what to do, and the ideal API would be something like withAccess { callback } that would automatically stop access when the callback returns, or this: This works okay if/when file access is highly constrained, but it doesn't really work as well if you're working with a document over a very long period of time. More to the point, the APIs involved here are part of a LONG chain of evolution that keeps being expanded/tweaked/repurposed. For example, bookmarks weren't created to preserve security access; they were created to replace the Alias manager (from macOS Classic/Carbon). Similarly, security scoping in URLs is partially tied to file reference URLs (vs. file paths), but THOSE were really creat

Hi @haishu0, Please direct your code-level questions for this issue to DCloud—the third-party service and/or library presenting this payment error in your app. This error is not managed or generated by Apple. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.

Hello, This sounds like a regression in beta iOS 26. What version of the betas (iOS and Xcode) are you using and has this behavior changed between any other beta versions recently? To fully understand the request flow and configuration it would be helpful to have a sample project. Please provide one if you're able. Something in the documentation of note: GameKit calls the [authenticateHandler] handler, possibly several times, for the following cases ... so we'll need to check each case. All that said, please also file a bug report as this is still in beta.

Thank you for your help. I think this fixed it. Following your directions, Checked Xcode's Apple Accouts - Looked ok Set up a new project with a new AppID and CloudKit container. Worked. While in that new project, changed AppID and CloudKit container back to the problem values. FAILED. Logged in to Developer portal. No warnings or error messages and no pending agreements. Followed steps from TN3164. iCloud was checked. However, the option was Compatible with Xcode 5. Changed it to Include CloudKit support and saved. Forced a reprovisioning by unchecking and rechecking the Automatic Signing feature in Xcode. WORKED. (I believe I said previously that this was an OLD app...) Thank you for your help. (I'll copy this into a reply in the FB to complete your records.)

I followed @nachojackson's fix, and that allowed me to proceed with the submission. I miss some of the subtlety the blur gave, but for now, this will do. Going to try an Xcode Cloud archive later today.

I just caught this bug this morning with Xcode 26 beta 6. I promptly filed feedback with a sample project. FB19931677