“xcode github”

If you use your intent phrase inside of the Xcode scheme settings (there is a place called Siri Intent Query where you can type it in), does the same thing happen? If that's still giving you trouble, then the next thing I'd do is create a brand new test project in Xcode, give it an app name that's pretty unique, and bring in the basic outline of your Siri intent code, and make sure everything is working there. The goal of that is so that you review all of the integration steps again from a clean slate to make sure you didn't miss anything, as well as validating that once the code does run, you have a basic functional outline you can build upon for exploring the API as you build out the feature for your real app. Jumping ahead a step, one additional thing that trips people up when debugging their intent extension is a misunderstanding of when the code runs — it is in a separate process, and so depending how you launch it, breakpoints you set for debugging may or may not be activated. A good r

Thanks again for reporting the issue. It seems that the issue is impacting the community, but I haven't seen any feedback report ID posted here. Do folks have any feedback report yet? If not, would you mind to file one and share your report ID here? I understand that filing an actionable feedback report takes time, but that will help. I am trying to capture the issue, and yet, my current configuration, Xcode 26.2 (17C52) + iPhone 17 Pro with iOS 26.3 (23D127) + Apple Watch series 10 with watchOS 26.3 (23S620), does work for me. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thanks for your post as it seems very well written explaining the issue with the code in the end, but following your code as you just looking at a subscription is difficult to understand what is the cause of the issue. I’m not an expert in subscriptions but I wonder looking at your code if could be a Swift's concurrency issue as you are not setting the for await result in Transaction.updates ? I think the problem may b3e that your current handler, though running on @MainActor, processes transactions sequentially within that single loop. If processing takes even a few milliseconds, new updates can arrive and pile up behind the currently processing one, potentially leading to them being handled more than once if logic isn't airtight? I do believe by encapsulating your logic within an actor and using a set for deduplication, you create a predictable and thread-safe environment for handling StoreKit's asynchronous transaction updates, effectively solving the duplicate problem you've encountered. Something like th

It is not fixed on macOS 26.4 beta or Xcode 26.4 beta. I believe I have found a workaround however: Set this value in Terminal and then restart Xcode and run Update to latest package versions. defaults write com.apple.dt.Xcode IDEPackageSupportUseBuiltinSCM 1 I have verified this works for me with Xcode 26.3 and 26.4 on macOS 26.4 beta after previously having the issue above.

[quote='876690022, ZKK640, /thread/806582?answerId=876690022#876690022, /profile/ZKK640'] What are the consequences of using Xcode15? [/quote] There are a couple that spring to mind: Xcode 15 doesn’t include the iOS 26 SDK, so you won’t be able to use the latest iOS features. You won’t be able to test your submission properly, because it will ultimately be reviewed on Xcode 26. While Xcode is generally good about working with projects from older versions, the only way to be sure that it’ll work is to try it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m not an expert on the App Store Connect API, but I can speak to this part of your question: [quote='816166021, Misko_, /thread/816166, /profile/Misko_'] there is a possibility to set Entitlements, which is I understand also called as Template. [/quote] The entitlement template feature is very much an old school path. These days most access to managed entitlements is via additional capabilities. Like any other capability, you set these on your App ID and they flow through to every provisioning profile [1] you create for that App ID. These capabilities have a bunch of advantages, including Xcode integration, compatibility with automatic signing, and the ability to add any combination of the capabilities to a given profile. Given that, the template mechanism is largely deprecated. If you have existing templates you can request that they be migrated to additional capabilities. See Developer Account Help > Reference > Provisioning with capabilities > Migrating additional entitlements to capabi

@fpiovezan Thank you for joining the conversation. You have requested for me to: validate the state of Accessibility options run an experiment and file a new FB with logs attached After gathering our bearings, it's clear to me that I will not be able to provide anything new that was not already provided in FB20359822 . Can you please consult that FB ticket as it has all the extensive info and logs of using Xcode 26.2 with iOS 26.2, and what's also important, a project that reproduces the issue. As for the accessibility options, we are certain that we do not really enable anything on by hand, never. We are going to attach a video recording of our accessibility options to the same FB20359822.

After the initial setup worked for regular builds, three edge cases needed fixing. Early exit on clean (BuildPkgTestCMD.sh) The pre-action runs even when cleaning, but there’s nothing to build and nothing to clean manually — PkgTestCMD lives inside the parent’s BUILD_DIR, so Xcode cleans it automatically. We just exit early. OBJROOT isolation (BuildPkgTestCMD.sh) We were already setting SYMROOT to keep build products inside the parent’s BUILD_DIR. Turned out OBJROOT (intermediates) also needed to be isolated, otherwise building PkgTestCMD standalone would conflict and produce “entitlements modified during build” errors. TARGET_BUILD_DIR (CopyPkgTestCMD.sh + outputPaths) During archive, Xcode always creates a temporary .app directory and copies the bundle there itself — it knows exactly what files it’s putting in. Copying our binary to BUILT_PRODUCTS_DIR meant injecting a file into that directory after Xcode had already done its packaging, so Xcode had no awareness of it. TA

I hadn't checked for a while, but when updating the corresponding app with macOS / Xcode 26.2 I found this issue fixed - nothing stated in any release note I browsed.