To whomever this may concern, We are investigating a BLE firmware-update compatibility issue affecting a legacy Nordic nRF51 DFU bootloader on a subset of iPads. We are seeking guidance on whether there are known CoreBluetooth or Bluetooth-controller differences across recent iPad hardware that could affect reconnection to Bluetooth LE connectable directed advertisements. Background Our accessory uses a legacy Nordic nRF51 DFU flow: The iPad is connected to the accessory’s normal application firmware. The app requests entry into DFU mode. The accessory disconnects normally. The accessory restarts into its bootloader. The bootloader sends connectable directed advertisements targeted at the iPad that initiated DFU. The iPad is expected to reconnect, after which the firmware transfer begins. Observed behavior On working iPads, the BLE trace shows: Application disconnect → accessory begins connectable directed advertising → iPad sends BLE connection indication → bootloader connection succeeds → DFU begins On affected iPads, the trace shows: Application disconnect → accessory begins the same connectable directed advertising → no connection indication from the iPad → DFU cannot proceed The accessory is advertising to the current resolvable address of the connected iPad. The bootloader starts directed advertising at nearly identical timing in both working and failing traces, approximately 456 ms after disconnect. The initial disconnect is normal in both cases: LL_TERMINATE_IND / Remote User Terminated Connection / reason 0x13 The problem occurs only after the accessory begins directed advertising. It seems like the iPad might be able to receive and listen to directed advertisement, however it seems to be unable to send back a connection indication. Hardware correlation observed so far We observed a correlation with Bluetooth controller vendor information visible in our BLE captures: FORMAT FOR FOLLOWING LINES Result -> Example device -> Observed controller vendor DFU succeeds -> iPad Air, 5th generation -> Broadcom DFU succeeds -> Other tested iPads, including one iPad with an A16-class platform -> Broadcom DFU fails -> One affected iPad with an A16-class platform -> MediaTek We want to be careful not to overstate this result: We have tested only one affected MediaTek-based iPad so far. The model string is MD3Y4LL/A and its current iOS version 26.6.1. The functioning Broadcomm iPads A16 we have tested that did not fail DFU process have model string MD7F4KN/A. The other iPad models we tested DFU on (which were all successful, albeit none of them were MediaTek chips, they were all Broadcomm) were: MRJN2KN/A, MM9C3KN/A, MQ6J3KN/A, MM6T3KN/A (the latter with iOS 26.6.1 as well, suggesting it is not necessarily an iPad OS version issue) We have not found a second MediaTek-based iPad to determine whether the behavior reproduces across that hardware. We initially suspected that recent non-cellular iPads might consistently use MediaTek, but this was disproved by the iPad Air, 5th generation we tested (MM9C3KN/A): it had no cellular connection and used Broadcom, and DFU worked normally. Therefore, we do not conclude that the issue is caused by MediaTek hardware. We only see a correlation worth investigating. What we have ruled out The target firmware image is not involved; failure occurs before any firmware data is transferred. The accessory reaches bootloader mode and sends directed advertisements at the expected time. The iOS Nordic DFU library already calls CoreBluetooth’s normal reconnect API: centralManager.connect(peripheral, options: nil) iOS does not expose an API allowing an app to create or send a raw Link Layer CONNECT_IND; therefore the application cannot directly work around controller-level connection behavior. The affected iPad does not provide a normal scanner/discovery callback for this directed bootloader advertisement, so matching by name or service UUID is not available as an application-layer workaround. Questions . Are there known CoreBluetooth, iPadOS, or Bluetooth-controller differences that can affect handling of BLE connectable directed advertisements, particularly when an accessory directs advertisements to a central using a resolvable private address? . Is there a recommended CoreBluetooth pattern for reconnecting to a known peripheral after it restarts into a legacy bootloader that uses directed advertising? . Does CBCentralManager.connect(_:options:) queue a pending connection request that should be serviced when a matching directed advertisement is received? If so, are there circumstances in which this behavior differs by iPad hardware or controller implementation? . Is there any public diagnostic information, entitlement, or supported API that could help us determine why a pending CoreBluetooth connection request does not result in a connection attempt in this scenario? . Does Apple recommend a specific compatibility approach for legacy BLE DFU bootloaders that use directed advertising, beyond updating the accessory firmware to use ordinary undirected advertising? . We can provide packet captures from both the working and failing cases, including timestamps, directed-advertisement target addresses, and the absence/presence of the subsequent connection indication. Thank you for any guidance on whether this is expected behavior, a known compatibility limitation, or if there is anything we could try on our end to hopefully resolve this issue.

Hello, Since I upgraded my iPad (iPad Pro 11" 2nd generation / A12z) to iPadOS 27 I have the following issue with SwiftPlayground. The preview no longer works and gets stuck on "Preview paused / Restart to continue". If I click on the refresh button, the button becomes disabled a few seconds but preview still remains on "Preview paused". It is quite easy to reproduce : Start SwiftPlayground Click "New playground" Click "App" When "My App n" appears on playground browser click on it I already tried to uninstall / reinstall SwiftPlayground and rebooting my iPad but it didn't help. Thanks for any help

The Problem When a user toggles radio buttons or checkboxes in a PDF using Preview, the widgets disappear following subsequent interactions after the file is saved and reopened. This renders the form fields unusable. Steps to Reproduce the Problem Open a PDF with radio buttons or checkboxes in Preview. Toggle a radio button or checkbox. Save and close the file. Re-open the PDF in Preview. Toggle the same button again. The button (and any others with the same field name) will disappear. Expected Results Toggling a radio button or checkbox should update the field value without causing the button (or related buttons) to disappear. This behavior is consistent with previous versions of PDFKit. What is Happening In Preview, interacting with radio buttons and checkboxes correctly updates their appearance as expected. Saving the PDF, however, causes the appearance dictionary to reference a new N entry that is a single appearance stream unassociated with any state. The annotation's AS entry is not updated. The original N entry remains but is no longer referenced. Subsequent interactions fail to update the visual presentation because the appearance stream is missing. Impact on User Experience Radio buttons and checkboxes may disappear and become unusable when toggled. PDF documents become irreparably altered after a button is toggled and the file is saved. PDF file size significantly increases when the file is saved. Users may believe they have successfully completed a form, only for the data to become inaccessible or invisible to recipients. Forms may need to be completely restarted or recreated from scratch if the original becomes unusable. The corrupted PDF structure might cause the file to render incorrectly or crash in third-party PDF viewers. Affected Apps/OSs Tested with Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). This problem also affects PDFKit on iOS 27.0 and iPadOS 27.0. Feedback/bug report: FB24866826 Related Sample Output Original PDF File Checkbox widget annotation (6 0 obj), its appearance dictionary (17 0 obj), and normal appearance dictionary (18 0 obj). Button is not checked. 6 0 obj << /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /F 4 /Subtype /Widget /DA (/.AppleSystemUIFont 13 Tf 0 g) /MK 16 0 R /C [ 0 ] /AP 17 0 R /V /Off /M (D:20260919225320Z00'00') /AS /Off /FT /Btn /Type /Annot /Ff 0 >> endobj 17 0 obj << /N 18 0 R >> endobj 18 0 obj << /Yes 20 0 R /Off 22 0 R >> endobj PDF File after Save Checkbox widget annotation object (6 0 obj), its new appearance dictionary object (8 0 obj), a new normal appearance stream object (20 0 obj), and the original appearance stream dictionary (now 21 0 obj). File saved after user checked button. 6 0 obj << /Ff 0 /Type /Annot /AS /Off /AP 8 0 R /MK 9 0 R /C [ 0 ] /FT /Btn /M (D:20260919225320Z00'00') /DA (/.AppleSystemUIFont 13 Tf 0 g) /Subtype /Widget /F 4 /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /V (Yes) >> endobj 8 0 obj << /N 20 0 R >> endobj 20 0 obj << /Filter /FlateDecode /Resources << /ColorSpace << /CS1 [ /ICCBased 29 0 R ] /CS2 [ /ICCBased 30 0 R ] >> >> /BBox [ 0 0 20 20 ] /Type /XObject /Subtype /Form /Length 123 >> stream x UéA ¬0 Ô}≈|†≈nà¢úÛÇ* —SA =}Ïr(»ñµ≤w◊€YËà’|ÙÎŒç'óRï∂#SäÏÌü∞¢S‰Ì§ôRÌX }–É•åY Éçˆ BŒ H " *â´8™ˆZø6z⁄ÿ ”ú6ɀ੠"∫t˘‹;'¬ endstream endobj 21 0 obj << /Off 22 0 R /Yes 23 0 R >> endobj Note: No object references 21 0 obj in the PDF.

I’m investigating an issue with simultaneous Apple Pencil and finger input on iPad. Apple Pencil + finger input works correctly while the Pencil user’s hand/palm is off the display. However, when drawing naturally with Apple Pencil with the palm resting on the display, an existing finger drawing contact elsewhere on the screen can be cancelled and then stop receiving input for several seconds. Pencil input continues normally throughout. Initially I suspected PencilKit, but I’ve reproduced the underlying behaviour below PencilKit/SwiftUI. Instrumenting UIKit at UIApplication.sendEvent shows the finger touch being cancelled and, in some cases, no further events for that finger for ~4–5 seconds while Pencil MOVED events continue to arrive normally. Everything delivered to the application is accounted for, so this appears to occur before our drawing/rendering code. Is this expected behaviour from the iPad’s Pencil/palm rejection? More specifically: Is there any supported way to tell UIKit that an existing finger contact should remain intentional while Pencil + palm contact is present? Is palm rejection configurable at this level? Is there another public input API we should be using for this scenario? We’re currently testing UIEvent.coalescedTouches(for:) to determine whether additional genuine finger samples are available during these apparent gaps, but haven’t completed that test yet. Any guidance on whether this interaction is expected to be supportable through public UIKit APIs would be appreciated.

We have a complete iPadOS DriverKit USB extension for a Stripe Reader M2 (USB-C, M-series iPad). Development builds sign and run. We cannot ship Ad Hoc, App Store, or Enterprise builds because the distribution DriverKit entitlements are either not granted or not present in the provisioning profile Apple generates. Stripe’s iOS USB instructions say to request the entitlement at developer.apple.com/system-extensions: select HID and USB Transport, and enter USB vendor ID 11369. Platform is iPadOS. The extension also needs com.apple.developer.driverkit. The host app uses com.apple.developer.driverkit.communicates-with-drivers. We have two teams. The driver bundle ID is prefixed with the host app bundle ID and signed with the same team. Inc — Team ID HPL6Q4V5TF (Development, Ad Hoc, App Store) Host app Driver extension com.atxinnovation.union.development com.atxinnovation.union.development.usbDriver com.atxinnovation.union.qa com.atxinnovation.union.qa.usbDriver com.atxinnovation.union.production com.atxinnovation.union.production.usbDriver These are not granted. Latest submission is system-extensions request 39WL64S3LR (September 3, 2026). That form has no status page, and we have received no email. LLC — Team ID 3MAPQA4NZ6 (Enterprise in-house) Host app Driver extension com.atxinnovation.union.enterprise com.atxinnovation.union.enterprise.usbDriver Capability request ACL9VQ3BA4. The portal shows DriverKit and DriverKit USB Transport – VendorID granted and enabled on com.atxinnovation.union.enterprise.usbDriver. The Universal Distribution profile POS Prod USB Driver (platform iOS, active, expires 2027/01/22, UUID a3627c1e-451d-4d62-b871-1cb6fe21431e, created 2026-09-02 16:05:20 UTC) lists those capabilities as enabled on the Review Provisioning Profile page. The downloaded profile does not contain them. Decoding it yields only: application-identifier com.apple.developer.team-identifier get-task-allow keychain-access-groups The string driverkit does not appear in the profile. We regenerated it five times, including deleting and recreating the profile, with the same result. DriverKit development profiles for the corresponding development App ID do contain com.apple.developer.driverkit and com.apple.developer.driverkit.transport.usb. Xcode then fails the archive: Provisioning profile "POS Prod USB Driver" doesn't include the com.apple.developer.driverkit entitlement. We also do not know which idVendor values the VendorID grant assigned. The extension must match them exactly. We need 11369. What we already tried July 30: Account Holder submitted DriverKit and DriverKit USB Transport for both teams through the system-extension Contact Us form. No confirmation email. That form does not collect bundle IDs. Those July requests later showed up on the host App ID com.atxinnovation.union.enterprise, not on the usbDriver App IDs. August 12: Resubmitted on each usbDriver App ID under Certificates, Identifiers & Profiles → Capability Requests. Enterprise request ACL9VQ3BA4. August 27: Developer Support case 20000149322724. The reply pointed us back at the capability status page. September 2: Enterprise grant appeared. Enabling it on the App ID and regenerating the distribution profile still produced a profile with no DriverKit entitlements. Developer Support case 102951939894. No resolution. September 3: Resubmitted the Inc team via the system-extensions form (39WL64S3LR). The form would not accept another LLC submission because that App ID is already granted. No status since. What we are Requesting Grant DriverKit, HID, and USB Transport (vendor ID 11369) for iPadOS — Development, Ad Hoc, and App Store — on the three Inc driver App IDs above. Assistance debugging the issue of failing to embed the already-granted DriverKit entitlements in the LLC Enterprise distribution profile for com.atxinnovation.union.enterprise.usbDriver, and confirmation of the assigned idVendor values.

The Problem On opening a PDF document in the Preview app, PDF widget annotations appear pixelated/rasterized. This problem exists with button, text, and choice widget subtypes. The pixelation becomes more apparent when zoomed in. Expected Results PDF widgets should appear sharp and smooth, without pixelation. In previous versions of the Preview app, widgets appear vector-based as expected. Impact on User Experience PDF widgets appear pixelated and inconsistent with text content in the same PDF document. Widgets do not look like elements of an interactive form but, instead, resemble low-quality embedded images. Affected Apps/OSs: Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). A similar problem appears to affect PDFKit on iOS 27.0 and iPadOS 27.0 as well. Feedback/bug report: FB24843022

I’ve retested Sidecar after updating both my MacBook Pro to the current macOS 27 release and my iPad to the current iPadOS 27 release. When the iPad is connected through Sidecar and set to Use As → Extended Display, macOS does not offer a Rotation control for that display. Compatible conventional external displays do expose rotation options in System Settings → Displays. Physically rotating the iPad by 90° also leaves the Sidecar display in landscape orientation. This is consistently reproducible for me: Connect the iPad to the Mac using Sidecar. Select Use As → Extended Display. Open System Settings → Displays and select the iPad. Observe that no Rotation control is available. Physically rotate the iPad 90° into portrait orientation. Actual result: Sidecar remains connected and otherwise functions normally, but the iPad display remains landscape. No 90°/270° Rotation option is available, and physically rotating the iPad does not change the extended-display orientation. Expected result: An iPad used as an extended Sidecar display should be able to operate in portrait orientation, either automatically using the iPad’s orientation sensor or through 90°/270° Rotation controls in macOS Displays. I’ve filed the current issue through Feedback Assistant as FB24897273. I also previously filed the related portrait/full-screen limitation as FB22051066. Given that iPad natively supports portrait orientation, macOS already supports 90°/270° rotation for external displays, and Sidecar presents the iPad as an extended Mac display, the absence of any portrait option seems like a significant and increasingly conspicuous limitation rather than an inherent hardware constraint. This is particularly difficult to understand now that macOS/iPadOS 27 have substantially expanded Sidecar interaction. Is there any technical or platform constraint that prevents Sidecar from supporting the iPad’s native portrait orientation? If not, I hope FB24897273 can be considered for the appropriate Sidecar/display engineering team. I’m happy to provide additional reproduction details or diagnostics if useful.

Using iPad as sidecar for Mac, how to make full use of iPad keyboard? What I meant by that is, right now if I press Cmd+Tab or Cmd+Space for example, the shortcuts are intercepted by the iPad itself instead of passed to the Mac through sidecar. Can I turn off these iPad shortcuts while using sidecar somehow?

Since the beta releases of iPadOS 26 we have been having some crashes about Invalid parameter not satisfying: parentEnvironment != nil We got to contact a couple of users and we found out that the crash appears when entering a screen in a UINavigationController with the iPad device connected to a Magic Keyboard. If the device is not connected to the keyboard then nothing happens and everything works ok. From our end we haven't managed to reproduce the crash so I am pasting part of the stacktrace if it can be of any help. 3 UIKitCore 0x19dfd2e14 -[_UIFocusContainerGuideFallbackItemsContainer initWithParentEnvironment:childItems:] + 224 (_UIFocusContainerGuideFallbackItemsContainer.m:23) 4 UIKitCore 0x19dae3108 -[_UIFocusContainerGuideImpl _searchForFocusRegionsInContext:] + 368 (_UIFocusGuideImpl.m:246) 5 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 6 UIKitCore 0x19db28900 -[_UIFocusMapSnapshot addRegionsInContainers:] + 160 (_UIFocusMapSnapshot.m:545) 7 UIKitCore 0x19d1313dc _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 632 (_UIFocusRegion.m:143) 8 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 9 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 10 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 11 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 12 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 13 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 14 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 15 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 16 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 17 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 18 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 19 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 20 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 21 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 22 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 23 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 24 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 25 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 26 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 27 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 28 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 29 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 30 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 31 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 32 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 33 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 34 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 35 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 36 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 37 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 38 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 39 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 40 UIKitCore 0x19d132e08 -[_UIFocusMapSnapshot _capture] + 424 (_UIFocusMapSnapshot.m:403) 41 UIKitCore 0x19db2675c -[_UIFocusMapSnapshot _initWithSnapshotter:mapArea:searchArea:] + 476 (_UIFocusMapSnapshot.m:171) 42 UIKitCore 0x19d130dcc -[_UIFocusMapSnapshotter captureSnapshot] + 192 (_UIFocusMapSnapshotter.m:137) 43 UIKitCore 0x19db2045c -[_UIFocusMap _inferredDefaultFocusItemInEnvironment:] + 136 (_UIFocusMap.m:168) 44 UIKitCore 0x19daffd2c -[_UIFocusEnvironmentPreferenceEnumerationContext _inferPreferencesForEnvironment:] + 140 (_UIFocusEnvironmentPreferenceEnumerator.m:313) 45 UIKitCore 0x19d127ab4 -[_UIFocusEnvironmentPreferenceEnumerationContext _resolvePreferredFocusEnvironments] + 104 (_UIFocusEnvironmentPreferenceEnumerator.m:250) 46 UIKitCore 0x19d127394 -[_UIFocusEnvironmentPreferenceEnumerationContext preferredEnvironments] + 36 (_UIFocusEnvironmentPreferenceEnumerator.m:184) 47 UIKitCore 0x19d126e94 _enumeratePreferredFocusEnvironments + 400 (_UIFocusEnvironmentPreferenceEnumerator.m:503)

Hello, I found a difference in application lifecycle behavior between iPadOS 26.5 and iPadOS 27 beta when the app is running in the foreground and the iPad top button is pressed to put the device into sleep. Test condition Device: iPad App state: app is running in foreground (active) Action: press the top button once to put the device to sleep Observed via UIApplicationDelegate lifecycle callbacks Observed behavior iPadOS 26.5 The following callbacks are called in this order: applicationWillResignActive applicationDidEnterBackground iPadOS 27 beta The following callbacks are called in this order: applicationWillResignActive applicationDidBecomeActive applicationWillResignActive applicationDidEnterBackground Expected behavior I expected the lifecycle sequence on iPadOS 27 beta to be the same as, or at least consistent with, iPadOS 26.5 when the device is put to sleep from the foreground app state. In particular, I did not expect applicationDidBecomeActive to be called during the transition to sleep/background. Question Is this changed behavior expected in iPadOS 27 beta, or could this be a bug in the beta? If this is expected, could you clarify the intended lifecycle behavior when the top button is pressed and the device transitions to sleep? Thank you.

In iOS 26, the mini keyboard bar does not consistently appear when typing with a hardware keyboard. This behavior differs from iOS 18, where the bar was always visible. See screenshots:

I am developing an iPhone-only app with TARGETED_DEVICE_FAMILY set to iPhone only. The app supports Portrait orientation only by specifying UIInterfaceOrientationPortrait in UISupportedInterfaceOrientations. When I build the app with Xcode 27 RC and run it on an iPadOS 27 Simulator, the layout becomes incorrect when the iPad is rotated to an orientation other than Portrait. While investigating this issue, I found that adding UISupportedInterfaceOrientations~ipad to Info.plist and specifying all four orientations resolves the problem: UIInterfaceOrientationPortrait UIInterfaceOrientationPortraitUpsideDown UIInterfaceOrientationLandscapeLeft UIInterfaceOrientationLandscapeRight With this configuration, the app displays correctly when the iPad is rotated. However, since this is an iPhone-only app and TARGETED_DEVICE_FAMILY does not include iPad, I am unsure whether using UISupportedInterfaceOrientations~ipad in this situation is an appropriate and supported solution. My questions are: Is it valid to specify UISupportedInterfaceOrientations~ipad for an iPhone-only app? Is this key expected to affect an iPhone-only app when it runs on an iPad? Is the behavior I am seeing on iPadOS 27 expected, or should an iPhone-only Portrait app handle this situation differently? Adding UISupportedInterfaceOrientations~ipad resolves the issue in my testing, but I would like to confirm whether this is an appropriate configuration to use in a production app. Thank you.

Bug: Software Update UI state desync on iPadOS 27.0 RC (build 24A435) Reproduction Steps Complete downloading OTA system update, Software Update page shows Chinese localized button "现在更新" (Update Now). Go to iPad Storage and delete the downloaded OTA package. Navigate back to Software Update page immediately, NO reboot and NO manual page refresh. Expected Behavior The UI should detect that the local update file was removed, and switch the button to "下载" (Download). Actual Behavior The interface keeps displaying the "现在更新" button. The UI state is out of sync with the real existence of the downloaded OTA file. I did NOT tap the update button to prevent potential system risk; the state inconsistency itself is the bug. Full screen recording and sysdiagnose logs were submitted in Feedback Assistant report: FB24741350 I want to check whether other developers have encountered the same bug on iPadOS 27.0 RC. This UI inconsistency may confuse end users and bring potential safety misunderstanding, so I hope this issue can be prioritized and fixed before the official 27.0 release.

I’m testing simultaneous finger and Apple Pencil input with PencilKit and have reduced the behaviour to a minimal PKCanvasView. import SwiftUI struct ContentView: View { var body: some View { PencilCanvas() .ignoresSafeArea() } } struct PencilCanvas: UIViewRepresentable { func makeUIView(context: Context) -> PKCanvasView { let canvas = PKCanvasView() canvas.drawingPolicy = .anyInput return canvas } func updateUIView(_ canvas: PKCanvasView, context: Context) {} } On a physical iPad with Apple Pencil, I consistently see this behaviour: Start drawing with a finger and keep the finger moving. Touch the canvas with Apple Pencil. The active finger stroke immediately stops, while the Pencil can draw. The reverse order behaves differently: Start drawing with Apple Pencil and keep it moving. Touch/draw with a finger. The Pencil stroke continues rather than being cancelled. I’ve also confirmed that a newly created PKCanvasView reports isMultipleTouchEnabled == true, and explicitly setting it to true does not change the behaviour. Is simultaneous independent Apple Pencil and finger drawing supported by PKCanvasView when using .drawingPolicy = .anyInput? If so, is there a supported configuration or gesture-recognizer setting required to prevent the Pencil from cancelling an active finger stroke? Or is Pencil taking priority over an active finger drawing gesture expected behaviour in PencilKit?

I am using an 11-inch M4 iPad Pro. I first noticed severe battery drain while the iPad was idle. After checking the device, I found that several unrelated functions had stopped working at the same time: Front and rear cameras show a black screen Face ID does not work LiDAR does not work Flashlight does not work Apple Pencil is not detected, paired, or charged through the magnetic charging area Apple Diagnostics at the Genius Bar also reported failures involving the front camera, rear camera, Face ID, and LiDAR. I was told at the Genius Bar that, because the device is outside the standard warranty period, it would be treated as an out-of-warranty hardware failure and would not qualify for free repair. There has been no drop or liquid damage. I have already performed multiple force restarts, updated iPadOS, and factory-reset the device several times, but the symptoms remain unchanged. What seems unusual is that several functionally separate systems became unavailable at nearly the same time, together with severe standby battery drain. Because of that, I am wondering whether this could be related to embedded software, firmware, power management, or low-level hardware control rather than several independent hardware components coincidentally failing at once. Has anyone seen a similar issue on an M4 iPad Pro, or is there any known firmware or system-level failure that could cause this pattern?

I'm encountering an issue with front camera video recordings via browser (Safari/Chrome) on devices running iOS/iPadOS 18 and above: On iPad, the recorded video appears upside down. On iPhone, the recorded video is rotated 90 degrees. The rear camera functions correctly without orientation issues. This problem seems specific to browser-based recordings, as the native Camera app records videos with the correct orientation. Has anyone else experienced this behavior? Is there a known workaround or fix? The preview while recording is fine, the recorded video is oriented incorrectly.

Summary: Starting from iPadOS 26.4, the maximum memory available to a single app has been reduced from approximately 6GB to 3GB on an 8GB iPad. This change persists in iPadOS 26.5 and has not been addressed. This breaks core functionality of memory-intensive applications such as 3D scanning apps that require large amounts of RAM to process models. Device: iPad with 8GB RAM Affected versions: iPadOS 26.4, iPadOS 26.5 Working version: iPadOS 26.0 / 26.1 / 26.2 / 26.3 Measured Data: iPadOS 26.0–26.3: App available memory ≈ 6GB (75% of total RAM) iPadOS 26.4–26.5: App available memory ≈ 3GB (37.5% of total RAM) Measurement method: Apple system API Impact: This is a regression, not expected behavior. The available memory per app has been cut by 50% without any official documentation or release notes mentioning this change. As a result, our 3D scanning application crashes immediately when attempting to process 3D models on iPadOS 26.4 and later. The app requires substantial RAM to load and process 3D model data. With only 3GB available, memory allocation fails during model processing, causing the app to crash (EXC_RESOURCE / OOM kill). This core functionality was working correctly on iPadOS 26.3 and earlier with the same device and same app binary. This regression makes our app's primary feature completely unusable for all users on iPadOS 26.4+. Steps to Reproduce: On an 8GB iPad, install iPadOS 26.0 Measure available app memory using Apple system API Upgrade to iPadOS 26.4 or 26.5 Measure available app memory again Observe: available memory drops from ~6GB to ~3GB Expected Result: Available memory per app should remain consistent across minor OS updates, or any changes should be documented. Actual Result: Available memory per app dropped by 50% starting in iPadOS 26.4, with no documentation of this change. Additional Notes: Disabling Apple Intelligence does not resolve the issue This issue was not fixed in iPadOS 26.5 Other developers have reported increased crash rates starting in iPadOS 26.4 (Apple Developer Forums)

Hello, I am investigating an intermittent In-App Purchase failure that occurred during App Review for the first release of my app. Environment Review device: iPad Air 11-inch (M3) OS: iPadOS 26.6 Environment: App Review sandbox Product type: Consumable StoreKit integration: RevenueCat through react-native-purchases 10.4.3 Observed behavior StoreKit successfully returned the products, localized names, and prices. The reviewer could see the credit packs and initiate the native purchase flow. My diagnostics show this sequence: Purchase initiated PURCHASE_CANCELLED; no transaction evidence Purchase initiated again RevenueCat code 2: STORE_PROBLEM elapsed: 9.4 seconds no transaction evidence Purchase initiated again RevenueCat code 5: PRODUCT_NOT_AVAILABLE_FOR_PURCHASE no transaction evidence Purchase initiated again RevenueCat code 5: PRODUCT_NOT_AVAILABLE_FOR_PURCHASE elapsed: 0.6 seconds no transaction evidence code-block The relevant sanitized logs are: { "occurredAt": "2026-08-25T12:52:59.733Z", "platform": "ios", "appVersion": "1.0.0", "build": "14", "productId": "HIDDEN_FOR_DISPLAY", "stage": "STORE_CHECKOUT", "providerCode": "2", "providerReadableCode": "STORE_PROBLEM", "transactionEvidence": false, "elapsedMs": 9417 } code-block { "occurredAt": "2026-08-25T12:55:42.752Z", "platform": "ios", "appVersion": "1.0.0", "build": "14", "productId": "HIDDEN_FOR_DISPLAY", "stage": "STORE_CHECKOUT", "providerCode": "5", "providerReadableCode": "PRODUCT_NOT_AVAILABLE_FOR_PURCHASE", "transactionEvidence": false, "elapsedMs": 637 } code-block No App Store transaction was created, and therefore RevenueCat received no transaction or webhook for these attempts. Configuration verified I confirmed that: The affected product and the other consumable products are attached to the App Review submission. Product IDs match between the app, App Store Connect, and RevenueCat. Prices and localizations are configured. The products are available in the relevant storefronts. The Paid Apps Agreement is active. Banking and tax information are active. The In-App Purchase capability is present. The distribution build does not use a local StoreKit configuration file. The same build and affected product completed successfully afterward on a physical device using Apple Sandbox. The native purchase sheet opened, the transaction completed, and the consumable content was delivered successfully in my reproduction. The product metadata clearly remained available because its localized name and price were displayed. However, after the initial STORE_PROBLEM, subsequent purchase requests were rejected almost immediately as PRODUCT_NOT_AVAILABLE_FOR_PURCHASE. I do not have the underlying Apple NSError, such as an ASDServerErrorDomain or AMSErrorDomain value, because it was not exposed in my remote diagnostic record. Questions Can a failed sandbox transaction leave the StoreKit account/session or commerce-catalog state temporarily inconsistent, causing subsequent requests for an otherwise loaded product to return storeProductNotAvailable? Does StoreKit use separate metadata and transaction-eligibility services, allowing product information to load while the same product is rejected during purchase()? Are there known sandbox or StoreKit issues on iPadOS 26.6 that could produce this sequence? Could a stale App Review sandbox account token or storefront session explain the transition from STORE_PROBLEM to PRODUCT_NOT_AVAILABLE_FOR_PURCHASE? Is there any developer-side configuration that could explain this when the same product and binary complete successfully using another sandbox session? What additional logging should I capture from RevenueCat’s React Native SDK to preserve the complete underlying Apple error chain?

We have an app which uses a DriverKit-based driver to communicate with an external device. In multiple iPadOS versions, users have been facing this issue where the option/toggle to enable/disable the Driver is not appearing in the App Settings. As a result, users have to uninstall/install the app to get the option again. Ideally, the option should always appear in the App Settings so that users can freely toggle it according to their needs. Due to this, the external devices connected to the iPad will not be detected. I have not seen this happen during development or in any of the iPad(s) that I have tested the app on. Has anyone seen this happen with their apps and if so, what is the issue/workaround? Is this a known bug only in some specific versions of iPadOS? Also, I have raised a feedback for the same here but there has been no reply. Thanks, Abishek.

When you use .navigationTransition(.zoom(sourceID: "placeholder", in: placehoder)) for navigation animation, going back using the swipe gesture is still very buggy on IOS26. I know it has been mentioned in other places like here: https://developer.apple.com/forums/thread/796805?answerId=856846022#856846022 but nothing seems to have been done to fix this issue. Here is a video showing the bug comparing when the back button is used vs swipe to go back: https://imgur.com/a/JgEusRH I wish there was a way to at least disable the swipe back gesture until this bug is fixed.