build disappears

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.

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

So while the first one took 3.5days, the two additional jobs that I submitted during that time all finished at the same time. So it was clearly doing some sort of batch processing. I messed up internal signing so had to restart. New submission took roughly 6 hours. I also submitted a tiny test file which also took the same 6 hours. So again - supports the batch processing theory. Anyways, new build for Intel only took 15 minutes or less. I walked away so the times are definitely improving for me. Just posting the update for others looking into this.