Post

Replies

Boosts

Views

Activity

Reply to iOS 27: print(to:) silently drops every job after the first
Same issue here on iPadOS 27.0, in a production app that prints in the background with printToPrinter:completionHandler: on [UIPrintInteractionController sharedPrintController], to a UIPrinter kept from UIPrinterPickerController. What we see in field logs from our users since 27.0 shipped: The first background print after launch completes. Every later one is accepted, but the completion handler never fires; some fail minutes later with a nil error. Relaunching the app gives exactly one more print. It happens on every kind of AirPrint printer our users have: DNP printers behind the DNP WCM Plus, Canon SELPHY CP1500 and CP1300 connected directly, CUPS on a Raspberry Pi, a Windows shared printer, and Aircast Pro print servers. Across thousands of background prints on iOS 26.x, nearly all complete. On 27.0 only about a third do, and every device that printed more than twice was affected. Users who roll back to 26.6.2 are fixed. We've seen this before. In iOS 13 the same pattern, a second printToPrinter: on sharedPrintController with the same picker-chosen UIPrinter, failed with Print-Job request failed: Printer "..." does not exist on printers from every manufacturer, and iOS 10 to 12 were fine. That's FB7559352 (January 2020). In 27.0 the second job fails silently instead of returning an error, but the trigger is the same. I've filed FB24894929 for iOS 27, referencing FB7559352.
Topic: UI Frameworks SubTopic: UIKit Tags:
3d
Reply to I requested "DirverKit UserClient Access" Entitlement, But I Distribute App failed.
Hi Kevin, We're hitting the exact same malformed encoding on our team (MZR5GHAQX4 / Lumasoft LLC) and would appreciate the same kind of manual fix. The DriverKit UserClient Access capability was granted on case CC3TUTNMR7 on 2026-05-05. The malformed array reproduces today (2026-05-10) on freshly regenerated provisioning profiles — single 77-character string with an embedded \n at offset 38: 'co.lumasoft.lumabooth.dnpprinterdriver\nco.lumasoft.lumashare.dnpprinterdriver' array.count == 1, type == str. Affected App IDs (the host-side ones — the DEXTs use allow-any-userclient-access and don't need this list): co.lumasoft.lumabooth co.lumasoft.dnpdriverhost co.lumasoft.lumashare The intended values (separate array entries): co.lumasoft.lumabooth.dnpprinterdriver co.lumasoft.lumashare.dnpprinterdriver Runtime consequence: IOServiceOpen() from the host returns kIOReturnNotPermitted (-536870174) because no valid bundle ID can match the malformed entry. The DEXT itself matches IOUSBHostInterface, opens it, and copies bulk pipes correctly — failure is strictly at the kernel-side host entitlement check. Confirmed not bypassable by running as root. Tier-1 support case 102887359854 was deflected to the forums, so following that direction here. Would you be able to re-enter the array on the affected App IDs the same way you did for the OP? Happy to provide our decoded profile or security cms -D -i output by DM / radar if helpful. Also filed Feedback Assistant feedback for the portal-side encoding so a permanent fix can land downstream. Thanks
Topic: App & System Services SubTopic: Drivers Tags:
May ’26
Reply to iOS 27: print(to:) silently drops every job after the first
Same issue here on iPadOS 27.0, in a production app that prints in the background with printToPrinter:completionHandler: on [UIPrintInteractionController sharedPrintController], to a UIPrinter kept from UIPrinterPickerController. What we see in field logs from our users since 27.0 shipped: The first background print after launch completes. Every later one is accepted, but the completion handler never fires; some fail minutes later with a nil error. Relaunching the app gives exactly one more print. It happens on every kind of AirPrint printer our users have: DNP printers behind the DNP WCM Plus, Canon SELPHY CP1500 and CP1300 connected directly, CUPS on a Raspberry Pi, a Windows shared printer, and Aircast Pro print servers. Across thousands of background prints on iOS 26.x, nearly all complete. On 27.0 only about a third do, and every device that printed more than twice was affected. Users who roll back to 26.6.2 are fixed. We've seen this before. In iOS 13 the same pattern, a second printToPrinter: on sharedPrintController with the same picker-chosen UIPrinter, failed with Print-Job request failed: Printer "..." does not exist on printers from every manufacturer, and iOS 10 to 12 were fine. That's FB7559352 (January 2020). In 27.0 the second job fails silently instead of returning an error, but the trigger is the same. I've filed FB24894929 for iOS 27, referencing FB7559352.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
Boosts
Views
Activity
3d
Reply to Additional Vendor ID Approval
To be clear, I need a single driver that can match two Vendor IDs at the same time.
Topic: App & System Services SubTopic: Drivers Tags:
Replies
Boosts
Views
Activity
May ’26
Reply to I requested "DirverKit UserClient Access" Entitlement, But I Distribute App failed.
Hi Kevin, We're hitting the exact same malformed encoding on our team (MZR5GHAQX4 / Lumasoft LLC) and would appreciate the same kind of manual fix. The DriverKit UserClient Access capability was granted on case CC3TUTNMR7 on 2026-05-05. The malformed array reproduces today (2026-05-10) on freshly regenerated provisioning profiles — single 77-character string with an embedded \n at offset 38: 'co.lumasoft.lumabooth.dnpprinterdriver\nco.lumasoft.lumashare.dnpprinterdriver' array.count == 1, type == str. Affected App IDs (the host-side ones — the DEXTs use allow-any-userclient-access and don't need this list): co.lumasoft.lumabooth co.lumasoft.dnpdriverhost co.lumasoft.lumashare The intended values (separate array entries): co.lumasoft.lumabooth.dnpprinterdriver co.lumasoft.lumashare.dnpprinterdriver Runtime consequence: IOServiceOpen() from the host returns kIOReturnNotPermitted (-536870174) because no valid bundle ID can match the malformed entry. The DEXT itself matches IOUSBHostInterface, opens it, and copies bulk pipes correctly — failure is strictly at the kernel-side host entitlement check. Confirmed not bypassable by running as root. Tier-1 support case 102887359854 was deflected to the forums, so following that direction here. Would you be able to re-enter the array on the affected App IDs the same way you did for the OP? Happy to provide our decoded profile or security cms -D -i output by DM / radar if helpful. Also filed Feedback Assistant feedback for the portal-side encoding so a permanent fix can land downstream. Thanks
Topic: App & System Services SubTopic: Drivers Tags:
Replies
Boosts
Views
Activity
May ’26