Background Information In the macOS operating system environment, Program A uses libusb to access USB devices that comply with the USB Mass Storage protocol. To enable Program A to start automatically after macOS boots, its corresponding plist file has been placed in the /Library/LaunchDaemons directory. Problem and Phenomenon Description Program A works well on macOS versions prior to 15.3, and it can access USB devices normally. However, on macOS 15.3, the following abnormal situations have occurred: A. Program A launched by launchd cannot access the USB device. Checking the logs reveals that the IOCreatePlugInInterfaceForService call in the darwin_claim_interface function returns the error code e00002be. B. Program A launched from the terminal command line with sudo privileges can access the USB device normally, and the return value of the IOCreatePlugInInterfaceForService call is 0.

Im having issue with OneDrive that is affected our company iPads. User are able to drag and drop any folder or files over and now they cant. they are on the latest update for OneDrive and the IOS. Can someone look at this and also i reach to Microsoft and they said that nothing have change on there end.

When are you guys going to fix the CarPlay issues with this new update? I use this for work and it’s really an issue. Nothing is working and it takes up entirely too much space.

Since tvOS 18.4 beta (22L5218l) i have the issue that When I turn off an Apple TV, the Apple TV and the connected TV turn off, but after a few seconds the devices start again. This never happened before. But now it is happening with 3 different Apple TV generations on 2 LG and 1 Telefunken TVs. All 3 Apple TV devices have been updated to tvOS 18.4 beta (22L5218l) and since then show this error.

We are experiencing problems with the USB port on iPad Pro 11 inch (M4) model number MVW13NF/A. Our custom peripheral device (based on Raspberry Pi Pico + tinyUSB stack, is configured as a network adapter class and has communication with our App over UDP protocol. Our device also acts as a DHCP server, providing the IP address for iPad. The problem can be described as a “bus stall” or "bus hold" after sleep mode. To reproduce it we just send the iPad into sleep mode using a power button, the USB bus on M4 goes to the suspended state and won’t resume anymore when we wake the iPad up. The problem has occurred since the upgrade to iOS 18.2.1 and has not been observed before on the previously installed iOS 17 on the same iPad Pro M4. Also, the problem does not happen on the iPad Pro 11 inch (3rd gen with M1) model number MHW73FD/A, with the same iOS 18.2.1 installed. The problem also does not arise, if we connect our device via USB hub to the same iPad Pro M4. We have tested different versions of tinyUSB stack (either included in RPi Pico SDK or native unpatched). The problem is independent of the library version. It occurs always if our device is connected directly to the USB port of iPad Pro (M4) with iOS 18. It also stays after upgrading to the latest iOS 18.3 (beta) In the attached logs is (reduced for clarity) debug output from tinyUSB library about events on the USB bus. These logs were captured via RTT debugging output, using Segger J-Link debugger, so logging process does not affect the timings on the USB bus. There are three logs attached, for cases 1: "iPad Pro M4 + iOS18" (i.e. problematic case), 2: "iPad Pro M1 + iOS18", and 3: "iPad Pro M4 + iOS18 + external USB hub" (they are non-problematic cases). case1_usbd_log.txt case2_usbd_log.txt case3_usbd_log.txt This was already posted as feedback with id FB16366509

As of iOS 18.1 being released we are having issues with our users experiencing issues with our app that relies on strobing the device torch. We have narrowed this down to being caused on devices with adaptive true-tone flash and have submitted a radar: FB15787160. The issue seems to be caused by ambient light levels. If run in a dark room, the torch strobes exactly as effectively as in previous iOS versions, if run in a light room, or outdoors, or near a window, the strobe will run for ~1s and then the torch will get stuck on for half a second or so (less frequently it gets stuck off) and then it will strobe again for ~1s and this behaviour repeats indefinitely. If we go to a darker environment, and background and then foreground the app (this is required) the issue is resolved, until moving to an area with higher ambient light levels again. We have done a lot of debugging, and also discovered that turning off "Auto-Brightness" from Settings -> Accessibility -> Display & Text Size resolves the issue. We have also viewed logs from Console.app at the time of the issue occurring and it seems to be that there are quite sporadic ambient light level readings at the time at which the issue occurs. The light readings transition from ~100 Lux to ~8000 Lux at the point that the issue starts occurring (seemingly caused by the rear sensor being affected by the torch). With "Auto-Brightness" turned off, it seems these readings stay at lower levels. This is rendering the primary use case of our app essentially useless, would be great to get to the bottom of it! We can't even really detect it in-app as I believe using SensorKit is restricted to research applications and requires a review process with Apple before accessing? Edit: It's worth noting this is also affecting other apps with strobe functionality in the exact same way

Is there any way to use AccessorySetupKit in the background to discover BLE devices?

After updating to ios18.4, 3d scanning function, including AR function in apple clips, cannot be used. Does anyone else have the same problem?

I downloaded "Dockkit ADK 1.0" and trying to compile, and some openssl include .h files are missing, for example in HAPBoringSSL.c, the below files can't found: #include <openssl/bn.h> #include <openssl/evp.h> #include <openssl/hkdf.h> #include <openssl/hmac.h> #include <openssl/rand.h> where can I get these .h files? I'm worrying about the version conformance if I fetch these files from internet.

I'm looking for technical documentation on Apple's IEEE 754 implementation on the M1 - M4 chips. Specifically, I'd like to know how NaN payloads are handled in arithmetic operations. Does anyone know where this information is available? Thank you!

** Every time after I downloaded an app this window opens and never closes how to close it?**

I have a command line utility I wrote that has been working great up until Sequoia that reads the macro keys from a Logitech G600 gaming mouse and turns it in to custom commands. it was using the following code, checking if usage was 0x80: IOHIDManagerRegisterInputValueCallback( g600HIDManager, { _, returnResult, callbackSender, valueRef in let elem = IOHIDValueGetElement(valueRef) let usage = IOHIDElementGetUsage(elem) let pressed = IOHIDValueGetIntegerValue(valueRef) Now i'm having issues with opening the HID manager: IOHIDManagerOpen(g600HIDManager, IOOptionBits.zero) After changing the system security from permissive to restrictive, It's giving the error code 0xE00002E2, or no permission. I can't easily add the sandbox entitlements as this is just a simple CLI application, not a bundled app, and even after setting back to csrutil disable, i'm still getting this error. So now i'm trying to turn it in to a bundled app and use CoreHID instead. Unfortunately I'm not getting any notifications that aren't the mouse itself. From the above code that was working before, i was looking for usage values of 0x80. I'm guessing that directly corresponds to the usage 0x80 in the HID descriptor. I am receiving notifications via await deviceClient!.monitorNotifications(reportIDsToMonitor: [] , elementsToMonitor: [] ) which should pick up everything for the device. I know the usage i'm looking for is referenced in the device client because it's in the deviceClient.elements collection. So is there something in CoreHID that specifically blocks Vendor specified Usage pages from being picked up by notifications? I've also tried just requesting the elements using let elemToMon = await deviceClient?.elements.filter({ ele in return ele.usage.page == 0xFF80 && ele.usage.usage == 0x80 }) let request = HIDDeviceClient.RequestElementUpdate(elements: elemToMon!) let results = await deviceClient!.updateElements([request]) but that call errors (still trying to figure out exactly how it errors). Any help would be appreciated, either in figuring out why i'm not getting the HID reports in question using CoreHID, or even what has changed that is causing me to not be able to use IOKit.hid anymore. Thanks in advance! For reference, here's the decoded HID descriptor: 0x05, 0x01, // Usage Page (Generic Desktop Ctrls) 0x09, 0x06, // Usage (Keyboard) 0xA1, 0x01, // Collection (Application) 0x85, 0x01, // Report ID (1) 0x05, 0x07, // Usage Page (Kbrd/Keypad) 0x19, 0xE0, // Usage Minimum (0xE0) 0x29, 0xE7, // Usage Maximum (0xE7) 0x15, 0x00, // Logical Minimum (0) 0x25, 0x01, // Logical Maximum (1) 0x75, 0x01, // Report Size (1) 0x95, 0x08, // Report Count (8) 0x81, 0x02, // Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position) 0x75, 0x08, // Report Size (8) 0x95, 0x05, // Report Count (5) 0x15, 0x00, // Logical Minimum (0) 0x26, 0xA4, 0x00, // Logical Maximum (164) 0x19, 0x00, // Usage Minimum (0x00) 0x2A, 0xA4, 0x00, // Usage Maximum (0xA4) 0x81, 0x00, // Input (Data,Array,Abs,No Wrap,Linear,Preferred State,No Null Position) 0xC0, // End Collection 0x06, 0x80, 0xFF, // Usage Page (Vendor Defined 0xFF80) 0x09, 0x80, // Usage (0x80) 0xA1, 0x01, // Collection (Application) 0x85, 0x80, // Report ID (-128) 0x09, 0x80, // Usage (0x80) 0x75, 0x08, // Report Size (8) 0x95, 0x05, // Report Count (5) 0x81, 0x02, // Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position) 0x85, 0xF6, // Report ID (-10) 0x09, 0xF6, // Usage (0xF6) 0x75, 0x08, // Report Size (8) 0x95, 0x07, // Report Count (7) 0x81, 0x02, // Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position) 0x85, 0xF0, // Report ID (-16) 0x09, 0xF0, // Usage (0xF0) 0x95, 0x03, // Report Count (3) 0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) 0x85, 0xF1, // Report ID (-15) 0x09, 0xF1, // Usage (0xF1) 0x95, 0x07, // Report Count (7) 0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) 0x85, 0xF2, // Report ID (-14) 0x09, 0xF2, // Usage (0xF2) 0x95, 0x04, // Report Count (4) 0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) 0x85, 0xF3, // Report ID (-13) 0x09, 0xF3, // Usage (0xF3) 0x95, 0x99, // Report Count (-103) 0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) 0x85, 0xF4, // Report ID (-12) 0x09, 0xF4, // Usage (0xF4) 0x95, 0x99, // Report Count (-103) 0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) 0x85, 0xF5, // Report ID (-11) 0x09, 0xF5, // Usage (0xF5) 0x95, 0x99, // Report Count (-103) 0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) 0x85, 0xF6, // Report ID (-10) 0x09, 0xF6, // Usage (0xF6) 0x95, 0x07, // Report Count (7) 0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile) 0x85, 0xF7, // Report ID (-9) 0x09, 0xF7, // Usage (0xF7) 0x75, 0x08, // Report Size (8) 0x95, 0x1F, // Report Count (31) 0x81, 0x02, // Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position) 0xC0, // End Collection

My audio and MIDI sequencer application consumes about 600 % of CPU power with 10 different instruments during playback. While idle approximately 100%. What is the maximum of CPU power that an application can consume? Are there any limits and could they be modified? I am asking because if I add more instruments the real-time behaviour gets bad at 700 % of CPU power. I have got following HW: MacBook Pro 14-inch, Nov 2024 Apple M4 Pro 24 GB

Hello, Since updating to iOS 18.3.1, the rear camera on my iPhone 13 Pro Max has not been functioning properly. The Camera app displays a black screen and becomes unresponsive. I analyzed the crash logs and found that the issue is related to the cameracaptured process, which handles image and video capture on iOS. Here are the key details from the crash log: 📌 Memory Error: "Address size fault" 📌 Impacted Thread: com.apple.coremedia.capturesession.workerQueue The "Address size fault" error suggests a memory access issue, likely causing the cameracaptured process to crash. This could be due to a bug in the video capture thread management introduced in the update. What do you think? name":"cameracaptured","timestamp":"2025-03-12 10:37:31.00 +0100","app_version":"1.0","slice_uuid":"cc45251e-92fc-329d-a3e9-d1c8c019e59e","build_version":"587.82.13","platform":2,"share_with_app_devs":0,"is_first_party":1,"bug_type":"309","os_version":"iPhone OS 18.3.2 (22D82)","roots_installed":0,"incident_id":"E97F5B3A-345F-42A6-97E8-28D175C8C5A9","name":"cameracaptured"} { "uptime" : 820, "procRole" : "Unspecified", "version" : 2, "userID" : 501, "deployVersion" : 210, "modelCode" : "iPhone14,3", "coalitionID" : 75, "osVersion" : { "isEmbedded" : true, "train" : "iPhone OS 18.3.2", "releaseType" : "User", "build" : "22D82" }, "captureTime" : "2025-03-12 10:37:30.1093 +0100", "codeSigningMonitor" : 2, "incident" : "E97F5B3A-345F-42A6-97E8-28D175C8C5A9", "pid" : 68, "translated" : false, "cpuType" : "ARM-64", "roots_installed" : 0, "bug_type" : "309", "procLaunch" : "2025-03-12 10:04:03.7137 +0100", "procStartAbsTime" : 225890551, "procExitAbsTime" : 19918403953, "procName" : "cameracaptured", "procPath" : "/usr/libexec/cameracaptured", "bundleInfo" : {"CFBundleVersion":"587.82.13","CFBundleShortVersionString":"1.0"}, "parentProc" : "launchd", "parentPid" : 1, "coalitionName" : "com.apple.cameracaptured", "crashReporterKey" : "137125638e43c62173057ae3dc983089b1f083cf", "appleIntelligenceStatus" : {"state":"unavailable","reasons":["siriAssetIsNotReady","selectedLanguageIneligible","selectedLanguageDoesNotMatchSelectedSiriLanguage","notOptedIn","deviceNotCapable","selectedSiriLanguageIneligible","countryLocationIneligible","unableToFetchAvailability","assetIsNotReady"]}, "wasUnlockedSinceBoot" : 1, "isLocked" : 0, "throttleTimeout" : 5, "codeSigningID" : "com.apple.cameracaptured", "codeSigningTeamID" : "", "codeSigningFlags" : 570434305, "codeSigningValidationCategory" : 1, "codeSigningTrustLevel" : 7, "instructionByteStream" : {"beforePC":"BgCA0hUnFpTgAxOqIaSGUiFLu3KJJBaU4AMTqqfYDZTozSGQAFEC+Q==","atPC":"IAAg1KiDW/jJkB+QKd1B+SkBQPk/AQjrAQEAVP17Uqn0T1Gp9ldQqQ=="}, "bootSessionUUID" : "33672FC1-99EC-48FC-8BCD-2B96DF170CC3", "basebandVersion" : "4.20.03", "exception" : {"codes":"0x0000000000000001, 0x00000001a93909f0","rawCodes":[1,7134054896],"type":"EXC_BREAKPOINT","signal":"SIGTRAP"}, "termination" : {"flags":0,"code":5,"namespace":"SIGNAL","indicator":"Trace/BPT trap: 5","byProc":"exc handler","byPid":68}, "os_fault" : {"process":"cameracaptured"}, "faultingThread" : 4, "threads" : [{"id":1699,"threadState":{"x":[{"value":268451845},{"value":21592279046},{"value":8589934592},{"value":28600187224064},{"value":0},{"value":28600187224064},{"value":2},{"value":4294967295},{"value":18446744073709550527},{"value":2},{"value":0},{"value":0},{"value":0},{"value":6659},{"value":0},{"value":0},{"value":18446744073709551569},{"value":6677212688,"symbolLocation":56,"symbol":"clock_gettime"},{"value":0},{"value":4294967295},{"value":2},{"value":28600187224064},{"value":0},{"value":28600187224064},{"value":6126594600},{"value":8589934592},{"value":21592279046},{"value":21592279046},{"value":4412409862}],"flavor":"ARM_THREAD_STATE64","lr":{"value":7911718552},"cpsr":{"value":4096},"fp":{"value":6126594448},"sp":{"value":6126594368},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":7911704456},pc":{"value":7911704456},"far":{"value":0}},"queue":"com.apple.main-thread","frames":[{"imageOffset":6024,"symbol":"mach_msg2_trap","symbolLocation":8,"imageIndex":10},{"imageOffset":20120,"symbol":"mach_msg2_internal","symbolLocation":80,"imageIndex":10},{"imageOffset":19888,"symbol":"mach_msg_overwrite","symbolLocation":424,"imageIndex":10},{"imageOffset":19452,"symbol":"mach_msg","symbolL

Ever since the last update i have issues with my camera app. Sometimes when I open the app the forward facing cameras don’t work and it’s just a Black screen. I also get a warning that I may not have genuine iPhone parts installed. I have to reboot the phone every time just to have it app function again. It’s annoying. Please fix this. I never had any issues with the camera or its app up until after the update.

I am developing a virtual Bluetooth HID keyboard device on my Win desktop that connects to my iPad over bluetooth and advertises itself as a keyboard to control the iPad. It works very well already on Android, but not on iOS. I can see in Packet Logger that it reads well as a HID device, reads the report map and HID information correctly, which data is all valid. It doesn't subscribe to the report's Client Characteristic Configuration, just silently quitting and the keyboard does not work. I can post more information if needed, but my question in short is what are the requirements for iOS to accept a HID over GATT as a keyboard peripheral. I feel like I am close.

We just updated our ATS to the latest 8.3.0 version and tried to run the iAP2 Session Test via BPA100 Bluetooth Analyzer and we are experiencing this EXC_BAD_INSTRUCTION. This same test still seems to work on ATS version 6. Please advise. Process: ATS [1782] Path: /private/var/folders/*/ATS.app/Contents/MacOS/ATS Identifier: com.apple.ATSMacApp Version: 8.3.0 (1826) Build Info: ATSMacApp-1826000000000000~2 (1A613) Code Type: X86-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2025-01-27 11:05:21.1334 -0800 OS Version: macOS 15.2 (24C101) Report Version: 12 Bridge OS Version: 9.2 (22P2093) Anonymous UUID: 098E2BB5-CB98-CA1C-CEFE-188AF6EFE8CF Time Awake Since Boot: 9700 seconds System Integrity Protection: enabled Crashed Thread: 2 com.apple.ATSMacApp.FrontlineFrameworkInterface Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [1782]

I'm developing a ticket app with Host card emulation. The session starts correctly the first time, but when trying to emulate a second ticket, after the first one has been read by the reader, or after the emulation has been canceled by the user, it doesn't work correctly for a while. This is my CardSessionManager: import CoreNFC @available(iOS 17.4, *) class CardSessionManager { private static var cardSession: CardSession? = nil private static var presentmentIntent: NFCPresentmentIntentAssertion? = nil static func initCardSession(_ accessCode: String) { cardSession?.invalidate() cardSession = nil let ProcessAPDU: (_: Data) -> Data = { capdu in var response = Data(accessCode.utf8) response.append(0x90) response.append(0x00) return response } Task { guard NFCReaderSession.readingAvailable, CardSession.isSupported, await CardSession.isEligible else { return } do { presentmentIntent = try await NFCPresentmentIntentAssertion.acquire() cardSession = try await CardSession() } catch { return } if let cardSession { for try await event in cardSession.eventStream { switch event { case .sessionStarted: cardSession.alertMessage = String(localized: "Searching reader...") try await cardSession.startEmulation() case .readerDetected: cardSession.alertMessage = String(localized: "Reading...") case .readerDeselected: cardSession.alertMessage = String(localized: "Successful reading!") await cardSession.stopEmulation(status: .success) case .received(let cardAPDU): cardSession.alertMessage = String(localized: "Communicating with reader.") do { try await cardAPDU.respond(response: ProcessAPDU(cardAPDU.payload)) } catch { cardSession.alertMessage = error.localizedDescription } case .sessionInvalidated(reason: _): cardSession.alertMessage = String(localized: "Ending communication with reader.") presentmentIntent = nil @unknown default: break } } } } } }

你好，有个问题想请教一下： 我们的app是一款与CGM实时血糖相关的app，app支持在后台通过蓝牙跟CGM血糖设备保持连接。 现在遇到一个问题： 首先，app在后台运行期间，蓝牙是开启状态的，跟CGM设备也是连接的状态。 某个时刻，监听到蓝牙的状态突然从 poweredOn 变为了 resetting ，然后蓝牙又恢复了，状态变为了 poweredOn 这时候，问题出现了：之前连接的那个CGM血糖设备一直无法扫描到了！！ 我想问一下： 什么情况下，蓝牙状态会变为resetting 蓝牙状态恢复为poweredOn后，之前连接的那个CGM血糖设备一直无法扫描到了，为什么？我要怎么做才能恢复，重新扫描到之前连接的这个设备？

My iPhone 16 pro max when on the magnetic charger at home or in my car. My phone just powers down and reboots on its own. This has happened several times a day since updating to iOS 18.4. Anyone else having this problem ?