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?

Hello, For several versions, we have had a NetworkExtension registered to "FilterDataProvider" for content filtering reasons, with no issues about performance in 10Gigabit networks. In our latest version, we added registration to "FilterPacketProvider" for packet filtering purposes, and from that moment, we have observed that outgoing bandwidth dramatically decreases by 90% (from 883 MB/s to 140MB/s), simply due to being registered to "FilterPacketProvider," without any processing by us, just only registering and returning ALLOW: class FilterPacketProvider: { override func startFilter(completionHandler: @escaping (Error?) -> Void) { self.packetHandler = {(_pContext: NEFilterPacketContext, _pIface: OS_nw_interface, _pDirection: NETrafficDirection, _pRawData: UnsafeRawPointer, _pRawDataLength: Int) -> NEFilterPacketProvider.Verdict in return self.handleNewPacket(context: _pContext, interface: _pIface, direction: _pDirection, rawData: _pRawData, rawDataLength: _pRawDataLength) } }} func handleNewPacket(context: NEFilterPacketContext, interface: OS_nw_interface, direction: NETrafficDirection, rawData: UnsafeRawPointer, rawDataLength: Int) -> NEFilterPacketProvider.Verdict { return .allow } The most curious thing is that this behaviour only happens with outgoing traffic, while incoming traffic does not experience any performance penalty. Reviewing similar cases, we found a similar post here: https://developer.apple.com/forums/thread/741965 So, our questions are: 1. Could we be doing something wrong when registering to NEFilterPacketProvider? 2. Is there still any known performance bug with outgoing traffic in NEFilterPacketProvider as I read in the post I found and attached? 3. If this bug is confirmed, is there any estimated date for its correction? Best regards, Asier Gil.

A call to the API SecKeyGeneratePair in SecureEnclave for iOS18 returns an OSStatus 0 but the SecKeyRef is not present. Understand that this API is currently deprecated and there are plans to move to the new APIs, but I believe this API should still work in iOS18 as expected for now. The API works as expected on iPadOS 18. // Create SE key let sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault, kSecAttrAccessibleAfterFirstUnlock, .privateKeyUsage, nil)! let privKeyAttr = [ kSecAttrAccessControl: sacRef, kSecAttrIsPermanent: true, ] as NSDictionary os_log("Priv key params: %{public}@", log: osLogger, privKeyAttr) let keygenAttr = [ kSecAttrApplicationLabel: attrApplicationLabelSeKey, kSecAttrTokenID: kSecAttrTokenIDSecureEnclave, kSecPrivateKeyAttrs: privKeyAttr, kSecAttrKeyType: kSecAttrKeyTypeEC, kSecAttrKeySizeInBits: 256 ] as NSDictionary var error: Unmanaged<CFError>? os_log("keygen params: %{public}@", log: osLogger, keygenAttr) var keyRef: SecKey? let status = SecKeyGeneratePair(keygenAttr, &keyRef, nil) os_log("SecKeyGeneratePair osStatus: %{public}d, keyRef: %{public}@", log: osLogger, status, keyRef == nil ? "null" : "ref present")

Tuesday morning at 3am, a burglar broke into my house and stole my VisionPro (s/n MWFYJ49L0V) that was running VisionOS 2.0 Beta. Apple Support advised me to keep the device on my account to stop the crooks from activating it. Is keeping the VisionPro (running a 2.0 beta) active on my personal iCloud account indefinitely like this okay, or a risk to my private data and ID?

Hello, I have a fully functional webauthn relying party that uses passkeys and I am trying to implement an iOS sdk for it. On the server, the AASA file is valid and well served at /.well-known/assetlinks.json. I verified its validity with branch.io and that it is indeed cached by Apple's CDN (https://app-site-association.cdn-apple.com/a/v1/service.domain.com), but even will all these I still get the following error when installing the app on a device and starting the passkey ceremony: Passkey authorization failed. Error: The operation couldn’t be completed. Application with identifier TEAM.com.APP is not associated with domain service.domain.com So I then checked the system log when installing the app on my iPhone, and under the swcd process (which is apparently responsible of fetching the AASA file) I found the following error: swcd: Domain is invalid. Will not attempt a download. The issue that I have is that my domain is actually an IDN, it has a special character in it. But everywhere I have used it, I converted it to ASCII (punycode). With this conversion, Apple's CDN is able to fetch the AASA file, and the passkey ceremony works fine on a browser. So I don't understand how the device (both iPhone or Mac) finds this domain to be invalid? In the app's entitlements, I added the capability for an associated domain, with webcredentials:service.domain.com with the domain name converted to ASCII (punycode) and developer mode doesn't address this issue as it appears when the app is installed (and is not related to Apple's CDN). The last thing I tried was to add the domain with special characters in the app's entitlements (for webcredentials:) but then Xcode was unable to install the app on the device, and gave the following error: Failed to verify code signature (A valid provisioning profile for this executable was not found.) which happened only with a special character in the domain in the app's entitlements. All this leaves me kind of in a dead end, I understand Xcode or iOS/macOS has a hard time with IDNs and special characters (so do I), but I have no idea on how to solve this (without changing the domain name), so I would really appreciate any help. Thanks in advance. PS: I tested all this previously with another domain without special characters and it was working. It also had dashes ('-') in it and the new domain converted to ASCII is basically a regular domain with '-' in it so I suppose there is some kind of conversion made from ASCII back to special characters and that then, the domain is considered as invalid, but this doesn't really help me a lot... PS2: My devices are running on iOS 17.4.1 and macOS 14.4.1 with Xcode 15.2

I have a unique need here and hope there is someone out there that might be of help. There is a backend server that will send an x509 certificate and private key (as strings) after the mobile apps on-boarding process. Additionally, the app includes an AWS SDK that is used to talk to their IoT system. This SDK requires PKCS12 certificate format to pass authentication. (I believe the common method is to have bundled the cert into the app which is not an option for me here sadly) I suspect it may be possible to use some openSSL iOS framework to do this conversion at runtime but have not personally tried it yet as my go-to is usually trying things first with Apples APIs. So my question becomes is there a way to meet this requirement using any of the security APIs or other APIs that apple has like swift-nio-ssl? Thank you very much for your time. Best, Michael

Apple revealed the ContactsAccessButton in the WWDC24 session 10121: Meet the Contact Access Button. After watching the video, reading through the documentation as well as the sample code , I can only find a SwiftUI ContactsAccessButton. However, our code base is written largely in UIKit, and our team prefers to do complex work and customization with lists via UITableView as opposed to SwiftUI List. So we would greatly prefer to use a UIKit ContactAccessButton. Is there not a UIKit equivalent to ContactsAccessButton? If there is, where can we find it?

It seems there was a new security feature added to macOS 15 - and now it asks every time after reboot if user wishes to continue and allow access the app to record screen and audio, while capture is blocked. Which renders remote access apps useless, a specially for headless computers like my Mac mini.

We are currently using "Sign in with Apple for the web": https://developer.apple.com/help/account/configure-app-capabilities/configure-sign-in-with-apple-for-the-web/ but we do not publish apps on the App Store. Because of corporate re-structuring, we need to migrate to a new Apple Developer / App Store Connect account. So we are looking to migrate "Sign in with Apple" users to the new account. Apple does provide guides on how to do it: https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer but unfortunately, it only works if "Sign in with Apple" is used with an app published on the App Store (it requires app transfer). Who should we handle this case? Please help.

Anyone found a fix?

Great post https://security.apple.com/blog/private-cloud-compute/ and I'd love to get on the action to help as a security researcher. There is a call to action, but it seems to be postponed until "after PCC becomes available in beta". Who at Apple should I keep in touch with and what is the best way to communite with that team. Thanks, François Proulx Software Supply Chain Security Research Lead at BoostSecurity.io

How do I add a privacy policy URL to an app?

In the 'notes' app, users are allowed to set custom passwords to restrict other people who may know your device password from accessing it. However, in the 'lock and hide app', there is no support for custom passwords to prevent people who may know your device password from accessing your privacy. For example, your wife. Why is it necessary to allow certain places in the settings, such as permission settings and privacy reports, to still be able to view hidden apps after hiding them, instead of completely hiding them?

~5% of our users when downloading the iOS application from the Apple Store for the first time are unable to enrol a Passkey and experience an error saying the application is not associated with [DOMAIN]. The error message thrown by the iOS credentials API is "The operation couldn't be completed. Application with identifier [APPID] is not associated with domain [DOMAIN]" We have raised this via the developer support portal with case id: 102315543678 Question: Why does the AASA file fail to fetch on app install and is there anything that can be done to force the app to fetch the file? Can this bug be looked at urgently as it is impacting security critical functionality? Other Debugging Observations We have confirmed that our AASA file is correctly formatted and hosted on the Apple CDN. Under normal circumstances the association is created on install and Passkey enrolment works as intended. We have observed that when customers uninstall/reinstall the app this often, but not always, resolves the issue. We also know this issue can resolve itself overtime without any intervention. We have ruled out network (e.g VPN) issues and have reproduced the issue across a number of different network configurations. We have ruled out the Keychain provider and have reproduced it across a variety of different providers and combinations of. We observed this across multiple versions of the iOS operating system and iPhone hardware including the latest hardware and iOS version.

I have a bunch of certificate related things, along with a bunch of secure notes stored in the keychain. These, like previously in System Preferences, don’t show up in the new Passwords app (as tested in iOS). So before I risk losing all that information by installing Sequoia, I wonder if the KeychainAccess.app is still around, allowing me to access these items. In case Apple is listening: do NOT remove that app, until all the critical functionality is also in Passwords, or some other app….

The release notes state the following: To protect users’ privacy, app group containers (in ~/Library/Group Containers) are now protected by System Integrity Protection. This is similar to the protection added to app data containers in macOS Sonoma. An app that’s properly entitled for an app group continues to have access to the app group container. Specifically, the app must use FileManager to get the app group container path and meet one of the following requirements: the app is deployed through Mac App Store; the app group identifier is prefixed with the app’s Team ID; or the app group identifier is authorised by a provisioning profile embedded within the app. If the app doesn’t meet these requirements, the system might present the user a prompt to authorize the app’s use of the app group container. If granted, that consent applies only for the duration of that app instance. This restriction also applies to app extensions, although in that case the system won’t prompt the user for consent but will instead just deny the access. (114586798) We have a helper app which is not sandboxed (due to it requiring Accessibility access/permissions) that accesses our group container. I've tested our helper app with the current beta of macOS Sequoia 15 (24A5264n) and it still works correctly, however I'm not clear if these restrictions are actually enforced in the current beta. I've tried testing for this by accessing the group container via Terminal (with Full Disk Access disabled for Terminal), but did not get any alert mentioned in the notes (or been otherwise restricted). Are these restrictions currently enforced?