With the release of iOS 18 Developer Beta 5 and Public Beta 3, my team received reports from customers that all negative values in our app were showing as positives, which led to major confusion. We narrowed down the issue to a change to the initializer for Decimal: Decimal(sign:exponent:significand). Prior to Beta 5, the sign passed into the initializer would be the sign of the decimal. Passing plus would result in a positive decimal, and passing minus would result in a negative decimal. This is regardless of the sign of the significant. In Beta 5, it seems that the sign passed into the init, and the sign of the significand are now multiplied together. This means that passing .minus for sign and a negative Decimal for significand results in an unexpectedly positive Decimal value in Beta 5 alone. This behavior does not seem to be explicitly documented. I created a quick playground to illustrate the issue. Here's the code: // Expected Value: 20 // Actual Value: 20 let positiveDecimal = Decimal(sign: .plus, exponent: 1, significand: 2) // Expected Value: 20 // Actual Value (15.4.0, 16.0 Beta 4): 20 // Actual Value (16.0 Beta 5): -20 let positiveDecimalWithNegativeSignificand = Decimal(sign: .plus, exponent: 1, significand: -2) // Expected Value: -20 // Actual Value: -20 let negativeDecimal = Decimal(sign: .minus, exponent: 1, significand: 2) // Expected Value: -20 // Actual Value (15.4.0, 16.0 Beta 4): -20 // Actual Value (16.0 Beta 5): 20 let negativeDecimalWithNegativeSignificand = Decimal(sign: .minus, exponent: 1, significand: -2) Here is the result of running the playground in Xcode 16.0 Beta 4 (and 15.4.0): And here is the result of running it in Xcode 16.0 Beta 5: I've tracked down the issue to a PR in the swift-foundation repo from 3 weeks ago, which seems to pull a commit from the swift-corelibs-foundation repo. For anyone else who finds this thread looking for a solution, in the mean time you can wrap the significant in abs and this should ensure consistent behavior between iOS 18 Beta 5 and prior iOS versions.

My team is very interested in integrating the new automatic passkey upgrade functionality into our app. Our app does not currently use passwords, but instead to log in utilizes phone number and SMS code verification (along with email code verification if the device is unknown). While watching the session on automatic passkey upgrades, it is noted that the system/credential manager checks to ensure that a password was just autofilled for the same account before allowing an automatic passkey upgrade. Since our app does not use passwords, does this mean we are ineligible for taking advantage of automatic passkey upgrades? Or, is there something else we can do to ensure the upgrade goes through?

My team is currently working on implementing passkeys and wanted to better understand the various errors that can be thrown both when creating and logging in with a passkey. To my understanding, after invoking the passkey request via the authorization controller, if an error occurs, the authorizationController(controller:didCompleteWithError:) delegate method will be called. The error will be a ASAuthorizationError, and there are a few codes listed here. The docs are a bit vague about when each of these errors can occur and what the difference is between them, so I am posting this in the hopes of gaining more clarity. The errors for which we'd like some clarification are: failed This is pretty generic, how might this code be different than the other failure reasons, and what could cause it to be thrown either for creation or for authorization? invalidResponse Does this mean that the system received an invalid response from the Relying Party? notHandled What might cause the authorization request not to be handled? notInteractive What does it mean for the authorization request to not be interactive? Does this mean that none of the specified credentialIDs are available? Finally, is it possible for both creation and authorization to throw all of these errors, or are there some that are exclusive? Any help would be appreciated, thank you.