build disappears

Can you try deleting the phyical one and rely only on the info.tab? I don't see how, since the NSExtension plist key contains a nested structure. Inversely, can you de select from build settings the 'generate info.plist' and handle that fully manually? Not sure what that should change. Should I simply copy the generated contents into the Info.plist file? The error doesn't happen at compile time, but at installation time. What happens if you deliberately make the NSExtensionPointIdentifier 'wrong' like making a typo - do you get same error message? Same error message, now mentioning the updated NSExtensionPointIdentifier value.

Ah, I thought might be the case. The simulator works a bit like macOS, where Xcode sets things up so that your app can load a framework from the build products directory. That won’t work on a real device, where the framework must be embedded in the app’s bundle. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

It looks like you’re using Xcode to build an Endpoint Security system extension. If so, the following should work: In Xcode, create a new app project by choosing File > New > Project and selecting the macOS > App template. Once that’s set up, create a new Endpoint Security system extension target by choosing File > New > Target and selecting the macOS > Endpoint Security Extension template. Then do this: In the Project navigator on the left, select your project. In the Project editor — the middle pane of the Xcode window — select your Endpoint Security system extension target on the left. At the top, select the General tab. In the Frameworks and Libraries list, you’ll see libEndpointSecurity.tbd. That’s the stub library necessary to resolve the linker error you’re reporting. If you’re not familiar with the concept of a stub library, I explain that in An Apple Library Primer. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + ap

Hi, yes your fully correct, its an app for tvOS We are media streaming VOD and live content. and only on the AppleTV A1625, we see thats there is an effect to the stream quality, and the only diffrent i can spot is the larger cpu usage(Other processes) and we have tried build on both the 26 and the 16.4. And we are using the AvPlayer to stream the content.

Hi, Any discrepancy in deployment target versions? I suppose not since you mentioned the fresh projects attempts. What happens if you modify manually the info.plist? Can you try deleting the phyical one and rely only on the info.tab? Inversely, can you de select from build settings the 'generate info.plist' and handle that fully manually? What happens if you deliberately make the NSExtensionPointIdentifier 'wrong' like making a typo - do you get same error message? Can you check the bundle identifiers?

Hey @DTS Engineer there isn't a sample code at this stage in the documentation. There is only the documentation explaining how to use Wi-Fi Aware on the Apple platform. Can you provide links to a real sample application to just run and test on our end. Would be happy to reproduce it with your sample code. Right now the documentation looks a bit unfinished with missing states between what you actually see in XCode and the way you need to build a real application. Even if that's the case i have been able to build one on my end and test the flow and the current API.

Forgot to include extra information: I'm currently building this out with native code as a part of an Expo Module

@pcfist Thanks for the link. Does that actually work? Some of the posts after the one you linked indicate that it still doesn't work in the end. Yesterday I took the plunge and updated my Mac to macOS 26.0.1 and added a dual boot of macOS 15.7.1. I need to get my app updated for macOS 26 and still support macOS 15 (and 14) and this was the only possible solution for now. Interestingly, both installs of macOS have the same Provisioning UUID. This actually helps some. I can boot into my main system (now macOS 26) and do a development build and test the app with macOS 26. When I want to verify things still work under macOS 15 I can copy the development build to a shared folder, reboot into the other partition with macOS 15, and run the development build from the shared folder. Since both systems have the same Provisioning UUID the app runs without complaint. No need to bother with Test Flight. It's still a giant pain to have to dual boot just to check on a quick change, but at least it

Jumping around a bit, partly from the bug, partly from your post. First off, on your provider: For USB2, this is IOSCSILogicalUnitNub, for USB 3 it is IOSCSIHierarchicalLogicalUnit. Basically, you're trying too hard. Both drivers are subclasses of IOSCSIPeripheralDeviceNub, which is what you should use as your provider. In USB 3 mode, macOS chooses alternate 1, the UAS protocol. My custom CDB is put on the bus, but no payload data is transferred. Is this expected behavior? No. This should either work or we shouldn't let your driver load. I'm not sure WHY it's not working, but I don't see any obvious failure. If so, is there a way to force the OS to choose alternate 0 even when on USB 3, perhaps with another dext? I haven't tried it, but yes, I think this is possible. For the future, the way to figure this out is to start by tracking down its match dictionary in the underlying KEXT. Its bundle id (from the registry snapshot) is com.apple.iokit.IOUSBMassStorageDriver, which is IOUSBMassStorageDriver.kext. Here

The 20 second limit is a hard limit, and there is no opportunities to extend it. Furthermore, you may need to plan for a cooldown period between sessions as well. My recommendation would be to reconsider if NFC is the correct tool for what you are trying to do. A typical NFC transaction takes a few seconds, and even reading complex documents take no longer than approximately 10 seconds. The time limits on the sessions have been determined based on common use cases, and as the 20 seconds limit cannot be extended, and you may have to require a hardware imposed cooldown period between sessions, your users may find this process inconvenient. But in the end, it is your business to decide if using NFC despite not satisfying your requirements is something to build upon.