We are implementing just-in-time account creation using Platform Single Sign-on. After creating the account, we are registering the user with PSSO and we want to ensure that the IDP account used for account creation matches the IDP account used in the user registration flow. An easy way to do this appears to be using loginUsername on the ASAuthorizationProviderExtensionLoginManager object. loginUsername gets set during account creation and then we can check what the user is entering during registration. The documentation, however, marks this attribute as deprecated. There is no indication of what could be used instead. Is there some other value we could look at? Does Apple have a plan to introduce a preferred API option? Thanks!

I saw this sentence in the documentation at https://developer.apple.com/documentation/bundleresources/information_property_list/nsrequirescertificatetransparency: 'Don’t use this key. The current system enforces this behavior, and new certificates can’t meet the requirement on older systems.' I understand that new systems will enable CT (Certificate Transparency) verification by default. However, I created a new demo to verify this on an iOS 13 device, and CT verification was not actually enabled.

I’ve been trying to solve this for some time And wondering if anyone else has come across this. using att framework and receiving user consent to use IDFA. is It possible to know when a user has entered another app on the same device ? flow: user consents to att framework in App 1 on iPhone user opens app 2 on iphone will app 1 know that user has opened App 2?

I want to reset the permission state of location services to "notDetermined" (CLAuthorizationStatus) while developing. But using the command below gives me this error: $ tccutil reset CoreLocation tccutil: Failed to reset CoreLocation same goes for $ tccutil reset [my bundleId] tccutil: Failed to reset CoreLocation approval status for [my bunldeId Anyone know the reason for this?

Hi, My app features its own lock screen secured by Face ID or Touch ID. With the introduction of the locked app feature in iOS 18, I want to ensure that users do not experience duplicate lock screens. Could you please advise on how to detect if the locked app feature is enabled in iOS 18, so I can disable my app's internal lock screen when necessary? Thank you!

import AppleProvider from 'next-auth/providers/apple'; export const appleProvider = AppleProvider({ name: 'Apple', clientId: process.env.NEXT_PUBLIC_APPLE_CLIENT_ID as string, clientSecret: process.env.NEXT_PUBLIC_APPLE_CLIENT_SECRET as string, idToken: true, authorization: { url: 'https://appleid.apple.com/auth/authorize', params: { clientId: process.env.NEXT_PUBLIC_APPLE_CLIENT_ID as string, scope: 'openid email name', response_type: 'code', response_mode: 'form_post', }, }, token: { url: 'https://appleid.apple.com/auth/token', async request(context) { console.log('----context', { context }); const url = https://appleid.apple.com/auth/token + ?code=${context.params.code} + &client_id=${context.provider.clientId} + &client_secret=${context.provider.clientSecret} + &redirect_uri=${context.provider.callbackUrl} + &grant_type=authorization_code; const response = await fetch(url, { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', }, }); console.log('----response', { response }); const tokens = await response.json(); console.log('----tokens', { tokens }); return { tokens }; }, }, });

Hello, The man page for xpcservices.plist states that: Services embedded in an application bundle will only be visible to the containing application (...) What exactly "visible" means? Doest that mean that there is a mechanism to prevent other programs than the embedding application to access the XPCService's mach port or it just means that the XPCService is not listed (e.g. launchctl list) and if attacker can guess the mach port they can access it? I'm asking to understand if there is a security gain using the -[NSXPCConnection setCodeSigningRequirement:] for embedded XPCServices.

I know how to set up a parental gate to keep a child user away from a web portal for parents or guardians. But is it even OK with Apple (or just in general) to open a browser from inside a kids app? I can think of two ways to do this: Launch a browser with UIApplication.shared.open(). This takes the user (presumably an adult) out of the app. Will Apple object to this? Use an in-app browser with WKWebView. (Wrapped in UIViewRepresentable because I'm using SwiftUI.) Option 2 has some problems with Google SSO, which is a requirement for me. Some details in stackoverflow 2016 and stackoverflow 2019 and gitHub. I can't figure out how to apply the solutions in those posts to the SwiftUI architecture or even the UIViewRepresentable.

Is the method used to unlock an iOS device available to an app? We would like to require a step-up to MFA (in our app) if passcode was used and allow for single factor if Face ID was used.

Hi, Are there any samples that IdP vendors can use to add support for Platform SSO in their solutions? I found this link: https://developer.apple.com/documentation/authenticationservices/platform_single_sign-on_sso/creating_extensions_that_support_platform_sso, which explains how to implement the extension on a device. However, I am having trouble understanding what needs to be implemented on the IdP itself from this documentation. Does anyone have any links or resources that can help? Thank you, Bala

I am implementing passkeys for my Project. We hosted apple-app-site-association file in 2 different sites for my project maintenance. One is with ww.sitename.com and another is www3.sitename.com. In Xcode adding each of them and testing individually. It's working good at first site and throwing error for second one like below Application with identifier <> is not associated with domain <>

Hello, I need to verify my domain and email with spf I need to use Signin with apple with private relay service Here is my records of DNS Service(AWS Route53) My domain is metapocket.io DKIM record : sig1._domainkey.metapocket.io value : sig1.dkim.metapocket.io.at.icloudmailadmin.com. SPF "v=spf1 include:zoho.com ~all" "v=spf1 include:icloud.com ~all" "v=spf1 include:metapocket.io ~all" "v=spf1 include:amazonses.com ~all" TXT "zoho-verification=zb03635298.zmverify.zoho.com" "apple-domain-verification=RaNdOmLeTtErSaNdNuMbErS" "apple-domain=4oc6zwBOLpmdRGr9" Something wrong here?? Why i got failed spf verification.. Please help me

It is clearly stated here that automatically created passwords are 20 characters long, contain 2 hyphens and exactly one uppercase letter and one digit. I have only ever seen generated passwords where the arrangement is in 3 groups of 6 (separated by the hyphens). From the description in the page referred to above, it could be that the generated password might look like: nzomZhf-qnbqd-k8ibtt i.e., a 7-5-6 pattern This would comply with the definition (if that's what it is) on the aforementioned Support page. Is it guaranteed that auto generated passwords will conform to the 3 groups of 6 pattern?

Hello forums, I have a problem with Autofill multiply SecureFields. I created a SwiftUI view with 2 SecureFields, createPassword and confirmPassword. Does not matter how I change the textContentType, AutoFill will only fill the first SecureField. For testing, I set the first SecureField textContentType to .none / .userName/ .email, and second SecureField sets to .newPassword, but AutoFill still fills password in first SecureField. As I know Apple advises to put both SecureField textContentType to .newPassword but it seems only working in UIKit: Enabling Password AutoFill on a text input view struct ContentView: View { @State private var createPassword = "" @State private var confirmPassword = "" var body: some View { VStack { SecureField("Password", text: $createPassword) .textContentType(.newPassword) SecureField("Password confirmation", text: $confirmPassword) .textContentType(.newPassword) } .padding() } } Thank you!

Hi, It may be a stupid question, but we really wonder if there is a way for MDM to push a unique mTLS cert to our iOS application or if it can populate a client certificate in the iOS where our application can access it. Like browser app, how do browser mTLS certs get pushed? Thanks, Ying

Hi Apple Developer Community, I'm encountering a persistent issue with Passkey registration on certain iOS devices running iOS 17.5.1. Specifically, the registration process consistently fails with either ASAuthorizationError 1001 (ASAuthorizationErrorCanceled) or ASAuthorizationError 1004 (ASAuthorizationErrorNotHandled). Details: Devices: iPhone SE (2nd generation), iPhone 13 Pro OS: iOS 17.5.1 Errors: ASAuthorizationError 1001, ASAuthorizationError 1004 I've followed Apple's guidelines for implementing Passkeys and verified that the devices meet the necessary requirements PS: During Apple's App Review process, the reviewer has encountered a consistent issue with Passkey registration failing with ASAuthorizationError 1001 or 1004. However, in our extensive internal testing with 75 users, we have not been able to replicate this issue We are seeking assistance from the Apple Review team to investigate the cause of this issue, as it is currently blocking our app's approval

Hi, I just watched session "10203" on "Meet AccessorySetupKit". In 09:13, it was mentioned that there is special UI for entering PIN codes / passphrases. How exactly is this UI triggered? And is there any UI for setting a pin during initial setup? I couldn't find any further information about any of this in the documentation. Best, Klemens

Why is it that after hiding an app, it can still be seen in many places in the settings, such as: Settings -> General -> iPhone Storage Settings -> private and security -> Pemissions Settings -> Search Settings -> Siri -> Siri APp Access -> Apps Additionally, in the App Store, the hidden app still shows as downloaded. Moreover, global searching for the full name of the app in global search also reveals the app and allows it to be opened. Why isn't the hiding more thorough? Is this a bug or intentionally designed this way?

I'm a new app developer and I've read through most relevant posts on this topic here and elsewhere. Many of the forum posts here are specific to Objective-C, or old enough to be considered outdated in the fast-moving world of computing. Many of the posts elsewhere are about protecting authentication secrets, which doesn't apply in my case, and a lot are by someone with a product to sell, which I've ignored. My app is 99.9% Swift and I'm not going to store any authentication secrets in the IPA. What I'd like to protect is the core mechanism of my product, which has to be included in the binary and is small (&lt; 10k lines). I want to make it so it's harder to steal the source code than it is to recreate my functionality from scratch, which is difficult even with the app in front of them. From what I gathered, Swift code compiled by Xcode is protected from reverse engineering / decompilation by the following: Symbolization of the app Native builds from Xcode destroys names of variable, functions, etc. Swift code is compiled in such a way that makes stealing harder than Objective-C This should make me feel better, but the threat-level is increasing with the availability of free, commercial-grade decompilers (e.g. Ghidra) and machine learning. The fact that iOS 18 supports a checkm8 (i.e. jailbreakable) device means that decrypting the IPA from memory is still trivial. Questions People talk about stealing authentication secrets via reverse-engineering, but is the same true for mechanisms (i.e. code)? How common is the issue of source-code stealing in iOS apps? Can machine learning be leveraged to make decompilation/reverse engineering easier? Will I get rejected by App Review for obfuscating a small portion of my code?

Private Access Tokens (PATs) are headlined as something that can eliminate CAPTCHAs, but also includes app-to-server communications in its use cases. Because of this, they seem to perform a very similar function to DeviceCheck, since both aim to attest to the health of the device in question. I don't really understand the difference between the two and find this confusing. Since PATs are newer and more general, I'm more inclined to adopt them, but where does this leave DeviceCheck? Is it redundant? How does App Attest fit into all of this? If my goal is to minimize if not eliminiate fraudulent/malicious use of my app's APIs, should I use Private Access Tokens, DeviceCheck, and App Attest simultaneously to maximize my protection? If not, what is accepted to be the best practice? I admire Apple's dedication to privacy and security, but as a new developer I feel Apple could make it easier for their app developers to find out and implement the latest best practices.