“iPhone 16 pro”

How do I go about troubleshooting this? So, the place to start is actually with this log message: eventually ends with provider entitlements check failed The log message is the final, generic, error message printed by IOUserService when the entitlement check process fails. A few things to understand about what this tells you about what HASN'T gone wrong: Basic entitlement validation happens outside the kernel well before this point. So getting to this point means that your DEXT is at least somewhat coherently signed, even if it doesn't actually work. IOKit passive matching happens at the same time as entitlement checking (just before actually), so this message means that either your passive match failed or your entitlement configuration was wrong. So, the next step here is to actually take a closer look at this logging: In the logs I see the matching log entry for my driver, and it goes through some setup that mentions my driver and some entries that do not. Focusing on the entitlement checking side, each IOK

Hi @pnelson, this is Argun, Quinn's Bluetooth colleague (while I don't have a transceiver in my head, it is not for lack of trying) I have been discussing your issue with the Bluetooth team, and while we are not dismissing the possibility of a bug, it is possible that the pairing process in different app contexts are behaving differently. Except we are not able to understand what exactly the conditions are when your app works, and when it doesn't, and when it gets the one error, and when it gets the other. There are also other conditions that might effect the issue, like whether both the Mac and the phone are logged in to the same iCloud account or not (changes pairing details) To that end, we would like some more info with a sample app, and exact repro steps, and some logs. So, first please go to https://developer.apple.com/bug-reporting/profiles-and-logs/ and follow the instructions for Bluetooth for macOS and iOS to install a logging profile on each of your devices. Then, once the logging profile

I'm seeing a similar issue as well. Seems like the Foundation model is just not available for iPhone and iPad simulators anymore. To test it out I created a simple playground (similar to https://developer.apple.com/events/resources/code-along-205/) and just used basic code: import FoundationModels import Playgrounds #Playground { // Create a new session with the language model. let session = LanguageModelSession() // Asynchronously generate a response from a text prompt. let response = try await session.respond(to: Generate a 3-day itinerary to Paris.) } For macOS simulator it works, but for iPhone and iPad simulators it gives either error: Apple Intelligence is not enabled. The operation couldn’t be completed. (FoundationModels.LanguageModelSession.GenerationError error -1.) I've tried Xcode 26.2. 26.3, 26.4 beta 1 & 2 versions. iPhone Simulators 26.2, 26.3 and 26.4 beta and none of them works. This is on a M4 Macbook pro I also have an old M1 Macbook pro I ha

Has anyone encountered similar SoC watchdog reset issues on M4 Pro with macOS 15+? Any help would be appreciated.

The short answer is that I tried everything (I could think of) and everything I tried fails. in the Files app, simple tap on the file: opens QuickLook (iOS 16) or the Preview app (iOS 26) for files without diacritics in their name. Doesn't do anything for files with diacritics (it's like I didn't tap on the file at all). in the Files app, long press on the file to get the contextual menu, scroll to Quick Look (Coup d'œil since I'm still in a non-English language), I get a blank screen that says Document PDF. opening the file using the documents browser from the Preview app (iOS 26) or PDF Viewer (iOS 26, iOS 16): does not display the file (it's like I didn't tap at all). previewing the file from inside the app using UIDocumentInteractionController(url: url).presentPreview(animated: false): blank screen that says Document PDF. opening the file by calling another app from inside the app using an UIActivityViewController: nothing happens on iOS 26, I get the error message (You do not have permi

My initial thought right at the start were it a race condition in (my) code. While I was confident my JavaScript was correct the translation that ReactNative does is under-the-hood and I couldn't validate this directly. This is why I then added additional logging into production to dump the characteristics/values, which proved it was not a race issue (with my code or its translation) but what is coming back from the library or iOS/CoreBluetooth. I then moved onto it being an issue with the react-native library, which is still a possibility, but the odds have reduced somewhat by the behaviour below. What made me increasingly suspect it's an iOS issue is two iPhones, one a 13 and the other a SE (later model) running 26.3 running the same App at the same time try to connect to the peripheral (which supports multiple connections). One iPhone is successful, the other swaps the values between the two characteristics and so fails. I haven't been able to replicate this myself, it's an error in produ

I added @main to the AppDelegate and the situation changed; now I have: libswiftCore.dylib`swift_willThrow: -> 0x181cb27ec <+0>: pacibsp 0x181cb27f0 <+4>: str x19, [sp, #-0x20]! 0x181cb27f4 <+8>: stp x29, x30, [sp, #0x10] 0x181cb27f8 <+12>: add x29, sp, #0x10 0x181cb27fc <+16>: adrp x8, 429908 0x181cb2800 <+20>: add x8, x8, #0x660 ; _swift_willThrow 0x181cb2804 <+24>: ldapr x8, [x8] 0x181cb2808 <+28>: cbnz x8, 0x181cb2818 ; <+44> 0x181cb280c <+32>: ldp x29, x30, [sp, #0x10] 0x181cb2810 <+36>: ldr x19, [sp], #0x20 0x181cb2814 <+40>: retab 0x181cb2818 <+44>: mov x0, x21 0x181cb281c <+48>: mov x19, x21 0x181cb2820 <+52>: blraaz x8 0x181cb2824 <+56>: mov x21, x19 0x181cb2828 <+60>: b 0x181cb280c ; <+32>

Ok, I clarify myself a bit. There seems the code lacks an entry point, from another part of the crash log: iPuja`abort_could_not_find_entry_point___debug_dylib: 0x102ab1440 <+0>: stp x29, x30, [sp, #-0x10]! 0x102ab1444 <+4>: mov x29, sp 0x102ab1448 <+8>: bl 0x102ab1620 ; symbol stub for: abort Then it seems it keeps on finding a entry point until it crashes. iPuja`getDebugDylibEntryPoint: 0x102ab05d4 <+0>: sub sp, sp, #0x70 0x102ab05d8 <+4>: stp x26, x25, [sp, #0x20] 0x102ab05dc <+8>: stp x24, x23, [sp, #0x30] 0x102ab05e0 <+12>: stp x22, x21, [sp, #0x40] 0x102ab05e4 <+16>: stp x20, x19, [sp, #0x50] 0x102ab05e8 <+20>: stp x29, x30, [sp, #0x60] 0x102ab05ec <+24>: add x29, sp, #0x60 0x102ab05f0 <+28>: adrp x8, 8 0x102ab05f4 <+32>: ldr x8, [x8, #0x8] 0x102ab05f8 <+36>: ldr x8, [x8] 0x102ab05fc <+40>: str x8, [sp, #0x18] 0x102ab0600 <+44>: adrp x24, 12 0x102ab0604 <+48>: ldrb w8, [x24] 0x102ab0608 <+52>:

Hi, has this problem been resolved? I've encountered the same issue with debugging on iPhone 6P(iOS12.4.4), but the error messages aren't exactly the same. https://developer.apple.com/forums/thread/817661

We're seeing a high rate of providerDidReset callbacks in production across a large user base (iOS 16, 17, 18, and 26). How frequent is frequent? The documentation states that providerDidReset signals the provider has been reset and all calls should be considered terminated. Should we be calling CXProvider.invalidate() on the old instance before creating a new one? Or is assigning a new CXProvider to cxProvider (which releases the old instance) sufficient? My recommendation would be that you destroy all existing call infrastructure (both CXProvider and all other CallKit crashes), call invalidate as well, then recreate a new CXProvider and recreate all other call infrastructure. Having said that, the EXACT details of that process generally don't matter all that much. All existing CallKit objects will be non-functional; most VoIP apps don't persist long enough that issues like small amounts of leaked memory actually become relevant. What could be causing providerDidReset to fire so frequently, and how