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.

My app mostly rely on time sensitive local notifications (both critical and normal). If my app is hidden, no notifications are shown. Is there a way I can change it in iPhone settings or override it through Swift code even though the app is hidden.

Hello, I bought an iPhone 13 second hand. The previous owner does not remember the apple id information. The phone hangs on the welcome screen. please help. imei 35 561122 88892 1

We must to have a options to create different passwords to hide or lock app. its important and possíble , please check and introduce this

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.

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

We want to use AccessorySetupKit to pair our BLE accessories. However, currently all our products announce the same BLE service UUID. The manufacturer data is different for every product. I try to pair our products with ASK and create the ASDiscoveryDescriptor with the expected manufacturer data: let descriptorA = ASDiscoveryDescriptor() descriptorA.bluetoothServiceUUID = CBUUID("CE1EB45C-1BD2-45BE-8163-ACC88BE94CB2") // same descriptorA.bluetoothManufacturerDataBlob = Data([0xd2, 0x0a, 0x00, /* A */ 0x2a, 0x00, 0x00, 0x00]) // different descriptorA.bluetoothManufacturerDataMask = Data([0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff]) let descriptorB = ASDiscoveryDescriptor() descriptorB.bluetoothServiceUUID = CBUUID("CE1EB45C-1BD2-45BE-8163-ACC88BE94CB2") // same descriptorB.bluetoothManufacturerDataBlob = Data([0xd2, 0x0a, 0x00, /* B */ 0x2b, 0x00, 0x00, 0x00]) // different descriptorB.bluetoothManufacturerDataMask = Data([0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff]) However, it seems random which device is found, as if the service UUID is the primary key to handle things in ASK. My questions are: Is it possible to use only manufacturer data to distinguish between different products with the same service UUID? How do I use bluetoothManufacturerDataMask properly? I assume that internally some filtering like this is done: DataBlob & DataMask == ReceivedManufacturerData & DataMask. Because of that I have set all bits of the mask to 1. Should this e done differently?

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 developer who is looking to make my first app easier to manage on my end by staying in the Apple ecosystem. My ideal backend is just pure and simple CloudKit. This should help me cut down on costs and increase my security, or so I thought. The more I looked into the issue of mobile app security --more specifically, preventing fraudulent access to backend APIs-- the more it seems like CloudKit is a disaster waiting to happen. While data in transit is encrypted and there's even end-to-end encryption for private DBs, securing an app's public DB in the presence of modified apps is a daunting, if not impossible task. My assumption is that a modified app cannot be trusted to make honest assertions about itself, the device, or its iCloud account, and can potentially lie its way into restricted areas of the DB. If an app is compromised, CloudKit queries from that app can be used to make malicious queries or even changes to the databases. I'm hoping App Attest, even with its potentially circular logic, can at least make life harder for fraudsters, competitors, and vandals (when combined with other security measures like jailbreak, debugging, hooking, and tampering detections), but I have not found a single mention on how App Attest might be used to protect CloudKit. There doesn't even seem to be a verified way for me to build a third party server that can handle App Attest and then tell CloudKit to allow a user through (with all the security hazards a new developer faces when configuring an authentication server). The message seems to be: App Attest is important, but you can't use it with CloudKit, so build your own server. Questions Is my assumption that a compromised app can make malicious queries or changes to an app's CloudKit DB correct? Can App Attest be made to protect a CloudKit public DB, with or without the involvement of a third-party server to handle attestations?

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 (< 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.

Does anyone have recent experience of what App Review consider acceptable for location purpose strings these days? My map apps simply display a blue spot on the map showing your current location when you turn on the app's location button. That data doesn't leave the app; I'm not selling it to anyone, or doing anything nefarious. For years, I've had concise location purpose strings such as "Your location will be shown on the map". Now, App Review seem to find that inadequate. They say: "One or more purpose strings in the app do not sufficiently explain the use of protected resources. Purpose strings must clearly and completely describe the app's use of data and, in most cases, provide an example of how the data will be used. Next steps: Update the ... location purpose string to explain how the app will use the requested information and provide an example of how the data will be used. " I've just look at what Apple Maps uses as its purpose string, and it's just "Your location is used to show your position on the map, get directions, estimate travel times, and improve search results." I'm only doing the first of those things, so surely "Your location is used to show your position on the map" would get approved, right? Wrong! I have similar issues with the photos purpose string.

All these new privacy and security features are nice but but let's address the elephant in the room. When will text/email messages and phone calls get encryption ???

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?