iPadOS 17.7.7

This has been fixed in iPadOS 26 beta 4.

Hey! Sorry to hear that this isn’t working, let’s see what we can do. Behaviour between Safari and third party browsers should generally be the same, but there may be instances of failure where the types used for values differ slightly from the specification (some browsers can be more lenient, or more strict, with unexpected types). Considering it’s failing around the payment request stage, I suspect a value within the payment request you’re providing isn’t the correct type per the specification. An example could be using a number of 0/1, instead of the expected Boolean false/true. If you’re able to replicate your payment request at https://applepaydemo.apple.com/apple-pay-js-api, the built in schema checker may pick up the fault. If logging from Chrome isn’t providing much information, it may be worth checking to see if the iPad is logging anything as well, which may provide some insight as to why it's failing. You can do this using Console on macOS with the device connected, and selecting it in the side men

This behavior continues to plague iOS and iPadOS 26 Beta 4. The List itself scrolls 100% smoothly, but the scroll indicator is choppy and jerky. This manifests even when each row element is given a fixed height. Once you scroll the List all the way down (in my example, I have about 30 rows), the indicator will then be smooth as you subsequently scroll around. It's almost as if the indicator is jumping around in reaction to new in-flight rows being added just outside the ScrollView's clipRect. As if the new rows are staged and ready to scroll into view and as they are added to the view hierarchy, the indicator size/position is recalculated based on their presence.

Forgot to update iPadOS. Solved.

My bugreport FB18336315 does include a test project. The bug is still present in iPadOS 26 Beta 4

In App Store Connect you create one app. Within that app you setup multiple platforms. Each platform gets its own binary, app description, app screenshots, etc. But all use the same app name. Though I don’t know if you can setup different binaries for iOS and IPadOS. My own app supports both iOS and IPadOS with one binary and then macOS with another.

We are listed for the MFI program as a licensed manufacturer. We have now started with the IAP3 sample code and the IAP chips to build up a USB communication between our accessory and an iOS device. We are looking for a sample project for the iOS part. Is there some available? No, I'm afraid that's the only sample that's currently available. I'll also note that there are integration issues with the External Accessory framework and our modern APIs, even on iOS 18. If you want to run on a broader set of system versions, then I'm afraid my recommendation would be that you build on UIKit and the older app (NOT scene) lifecycle. If you want to use SwiftUI and/or the scene-based lifecycle, then you may need to require iOS 26. Shifting to here: And how does this relate to IOKit since it is available for serial communication on iOS16 as well? Lots of clarifications here: On iPadOS, IOKit is specifically the user space API for DriverKit, not the more general purpose API it is on macOS. IOKit is really only av

I am assuming there is a bug in handling .intentdefinition files on watchOS vs iOS/iPadOS. I am going to migrate all my widget configuration to code-based WidgetConfigurationIntent.