missing package product

The only odd thing I'm seeing now is that it animates indeterminately until completedUnitCount is set to a new value. I believe this was basically an aesthetic design choice intended to minimize the fairly common issue where initial setup delays mean that progress stalls briefly at just starting, THEN starts moving at a steadier clip (as your app actually starts doing work). Any ideas to prevent the indeterminate state from always showing determinate progress? I'm not afraid of applying a bit of brute force, so I'd probably set it to 0 then set it to 1. You can also set totalUnitCount to 101 if you don't like how that loses a number. I'll also note that the correct value for totalUnitCount is often better determined by how well you can divide up your progress and what results in smooth looking progress, NOT the work your actually doing. This is very much a situation where everything is made up and the points don't matter. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Yes, this bug made me refrain from using ManipulationComponent so far in a production app. Surprised it made it into the release version.

Figured it out. For anyone who was following the instructions at the end of the WWDC 2025 video on App Intents: It appears AppIntentsPackage definitions are only required when you have an AppEntity conformances to define across package boundaries. AppIntents themselves are automatically discovered in any package or target, and defining AppIntentsPackage could result in duplicate metadata for AppIntents in the bundle, resulting in the OS being unable to resolve the AppIntent to use at runtime. So if all you have is AppIntents to share across the app bundle and a widget extension for example, you do not need to define AppIntentsPackage at all. This is a Xcode 26 compiler feature and is retroactive to at least iOS 18.

When I press the speaker button on the call screen displayed by CallKit and change it to ON, the speaker button display on the call screen reverts back to OFF after a few seconds. However, when the speaker button display reverts to OFF, the actual audio output route does not return to the earpiece - the audio continues to output from the speaker without any change. Could you please advise on what cases might cause the speaker button display to revert, and if there are any potential solutions? I can't tell you exactly what's gone wrong, but the basic answer is that there's an issue with how your audio code is managing your audio session. I suspect that you're not handling the initial route change properly, our Call UI updates based on that, then you complete the route change, which Call UI is missing. For reference, our Speakerbox sample app is a full CallKit implementation* and, if you experiment with it you'll find that it doesn't have any of these issues. Correct your audio implementation and the i

Just to let you know, FB19449747 has been fixed, so there is now a development-only entitlement for PCI DriverKit. For aesthetic reasons, we went with DriverKit PCI (development) instead of DriverKit PCI Transport (development)”, but other than that it should be exactly what you asked for. Two notes on the entitlement: (1) The configuration in your entitlement plist is a bit more complicated than the other development entitlements: com.apple.developer.driverkit.transport.pci IOPCIPrimaryMatch 0xFFFFFFFF&0x00000000 In IOPCIDevice, that translates to match any pid/vid. (2) By design, this entitlement will NOT match against Built In hardware. That won't have any effect on active product development, but if you try to match against our internal hardware for testing/experimental purposes, this is why*. *Ironically, we actually discovered this by accident while trying to verify the entitlement was doing what we wanted. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

We are missing something for getting the SDK for this framework integration with our software. So, one small detail that's easy to miss here is that, technically speaking, EndpointSecurity is actually a library*, NOT a framework. In the SDK, its tbd file is at /usr/lib/libEndpointSecurity.tbd and its include files are in /usr/include/EndpointSecurity/. Note that those header files are the canonical documentation for the framework and include far more detail than the class reference. Please give them a very thorough review. *For the technically curious, this is because the endpoint security operates at the very lowest layers of the system and cannot risk entangling itself with ANY higher level component of the system. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Hi @Mattreg, ShazamKit for android 2.1.1 does support 16KB memory page addresses. In branch fix-16k you have correctly imported the latest ShazamKit for android version. I checked this via md5:a6426940b80c4ec5f18a644e4f59193f. As good measure I have also explicitly verified your shazamKit .aar library for 16KB memory compatibility, and I confirm it's 16KB compatible. Steps: unzip the .aar, navigate to the jni folder run (adjust for your environment) ~/android-sdk/ndk/29.0.14033849/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p libsigx.so | grep LOAD LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14 LOAD off 0x000000000005afe0 vaddr 0x000000000005efe0 paddr 0x000000000005efe0 align 2**14 LOAD off 0x000000000005bca0 vaddr 0x0000000000063ca0 paddr 0x0000000000063ca0 align 2**14 2**14 is means it is supporting 16KB pages , see https://developer.android.com/guide/practices/page-sizes. I did also run ~/android-sdk/build-tools/36.0.0/zipalign -v -c -P 16 4 ~/Downlo

[quote='860800022, reglot, /thread/802423?answerId=860800022#860800022, /profile/reglot'] this fires when AVSpeechSynthesisVoice is initialized inside of an asynchronous context. [/quote] Yeah, that’s the sort of thing I saw expecting. And with that hint I was able to reproduce this trivially: Using Xcode 26.0 on macOS 26.0, create a new project from the macOS > App template, choosing SwiftUI as the UI. Add this code to the VStack in ContentView.swift: Button(Test) { Task { let voice = AVSpeechSynthesisVoice(language: nil) print(voice) } } Choose Product > Run. Click the Test button. I’m not sure whether I’d consider that a bug or not, but it definitely warrants deeper consideration from the engineering team responsible for that code. Please file a bug about this, making sure to include a reference to this forums thread and also attach a sysdiagnose log taken shortly after reproducing the issue. I’d appreciate you posting your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo

Well, that’s interesting. I again tried replicating this problem and everything worked for me. But then I tried again in an macOS > App target and I did see the problem. At that point I started digging… It turns out that I made a mistake in my previous post: [quote='860660022, DTS Engineer, /thread/802686?answerId=860660022#860660022'] I created a new project from the macOS > Command Line Tool template. [/quote] I didn’t use the macOS > Command Line Tool template, but rather I used my own personal template. Once I retesting with the built-in macOS > Command Line Tool template, I saw the problem immediately. And that give me a working and a non-working case to compare. And doing that I found that this behaviour is gated by the Member Import Visibility build setting. That’s set in the built-in template and not set in my personal template. And with it set I see the error compiling DataController and with it unset I don’t. This build setting is a product of a recent Swift Evolution change, na

My general advice on this front is to avoid temporary exception entitlements where you can. This is critical for App Store apps, but generally a good idea for products that you directly distribute using Developer ID signing. In this case there’s a standard way for sandboxed programs to use XPC without needing temporary exception entitlements, namely an app group. If you set up an app group, grant your app and your appex access to that group, and then have your daemon publish its named XPC endpoint ‘within’ that group, the sandboxed processes should be able to access that service without the need for a temporary exception entitlement. See App Groups Entitlement for info on how that works. Well, the app certainly will be able to. The situation with the appex is more nuanced, because appexen run in a custom sandbox that doesn’t always align with the standard App Sandbox used by apps. Which is probably the reason why your temporary exception entitlement is failing. I think the app group approach will hel