With Siri AI and App Intents, we can surface content from apps. Can we add guardrails or configure what Siri can or cannot say when dictating content?

I am developing a navigation application. My goal is for this navigation app to also work in the background and provide the user with real-time directional updates. When apps request access to location services, users see a TCC (Transparency, Consent, and Control) prompt. This prompt allows the user to choose under what conditions the app can access location services (for example: “While Using the App”, “Always”, etc.). If the user selects the “While Using the App” option, can the navigation app still access location in the background and provide directional information to the user? Is something like this technically possible? Does Apple allow this behavior for navigation apps or similar use cases?

Hello everybody, in my React Native-Expo-Firebase app, I am trying to integrate Sign in with Apple, along with the related token revocation at user deletion. I did succeed in integrating the login, and the app correctly appears in the Apple Id list (the list of apps currently logged with Apple ID). The problem is that, if I select the app and press "Interrupt Apple login usage for this app", the app simply stays there, nothing happens. If I do the same with another app, this works fine. Either if I do this via my iPhone's settings, or via https://account.apple.com/account/manage -> Sign in with Apple, I get the same result, the app cannot be removed. I hope I managed to explain my situation clearly, I'd be happy to provide more info if necessary. Thank you in advance.

Hello Developers, I have ran into a problem while sending mail to apple private relay email. We have built a mobile application where user can sign up through apple and they can sign up using hide-my-email feature. Which provides private relay address for us. Now we want to communicate with them using private relay mail address. The technology we are using to send emails are amazon SES, have done SPF, DMIK, DMARC and added domains in apple identity services for mail communication, passed an SPF check as well. But still mail is not getting delivered what am i doing wrong or apple doesn't support third party apps for sending emails to private relay? Is there any other way to achieve this please let me know Using the same body as attached in image is working fine for rest emails.

As an iOS developer, what should I make sure of so users can clearly see that privacy is considered in my app?

in iOS26.4, after installing the app for the first time, opening the app and clicking on the UITextField input box will trigger the system to pop up the network permission application interface. This issue did not exist before iOS 26.3, only in iOS 26.4. This is a fatal bug where the network permission request box should not pop up when the developer has not called the network related API.

Hello Everyone I'm encountering a problem with the Apple Mail Private. I created a website with the possibility to log in with apple account and apple gives the possibility to privatize the mail address with xxxxx@privaterelay. appleid.com but also blocked the mail come from my server. In the log I get the error: relay=smtp3.privaterelay. appleid.com[17.56.9.14]:25, delay=2.4, delays=0.11/0/1.8/0.48, dsn=5.1.1, status=bounced (host smtp3.privaterelay. appleid.com[17.56.9.14] said: 550 5.1.1 mymail@mail. com: unauthorized sender (in reply to RCPT TO command)) How can I fix it ?

My app needs both Accessibility and Input Monitoring permissions. Accessibility works as expected - calling AXIsProcesstrusted() automatically adds the app to System Settings > Privacy & Security > Accessibility, and the user just needs to toggle it on. Input Monitoring doesn't behave the same way. I'm calling CGRequestListenEventAccess() and creating a CGEvent.tapCreate(.listenOnly), but the app doesn't reliably appear in the Input Monitoring list. The user opens the pane and sees nothing to enable. What I've tried: CGRequestListenEventAccess() — shows the system prompt once per install, but doesn't always add the app to the list CGEvet.tapCreate(tsp: .cgSessionEventTap, place: .headInsertEventTap, options: listenOnly, ...) — returns nil before Accessibility is granted; after Accessibility is granted, the tap succeeds but the app still may not appear in the Input Monitoring list Calling both after Accessibility is confirmed, with a delay before opening the Settings pane The flow: User grants Accessibility (app appears automatically via AXIsProcessTrusted()) App creates a listen-only CGEventTap (succeeds) App opens x-apple.systempreferences:com.apple.preferences.security?Privacy_ListenEvent User sees the Input Monitoring pane but the app is not listed Environment: macOS 15, signed and notarized app, correct bundle ID, Hardened Runtime with com.apple.security.device.audio-input-monitoring entitlement not set (not applicable). Is there an API equivalent to AXIsProcessTrusted() that reliably registers an app in the Input Monitoring list? Or is there a specific entitlement, Info.plist key, or sequence of calls required on macOS 14+/15 to ensure the app appears?

Hi, I'm the developer of Mail Signature (MAS, bundle ID: de.metaflash.mail-signature), a Mac app that uses iCloud Drive to sync email signatures. On macOS Tahoe, when a user denies the iCloud access permission dialog on first launch, there is absolutely no way to reverse that decision through System Settings. Regression from Sequoia: On Sequoia, after denying iCloud access, the app correctly appears under System Settings → Privacy & Security → Files and Folders where the user can toggle access back on. On Tahoe, the app does not appear anywhere in Privacy & Security after denial – not under Files and Folders, not under Apple ID → iCloud, nowhere. Technical details: Affected TCC services: kTCCServiceUbiquity + kTCCServiceLiverpool tccutil reset Ubiquity alone is insufficient Only tccutil reset All triggers the dialog again This suggests both services need to be reset simultaneously Impact: Normal users are permanently locked out with zero recovery path. The only workaround is Terminal: tccutil reset All de.metaflash.mail-signature ...which is completely inaccessible to average consumers. As a MAS developer we have no way to help users programmatically: exec/child_process → sandbox blocked NSUserUnixTask → designed for user-supplied scripts only, not reliable here Apple Events to Terminal → blocked or App Review risk Feedback submitted: FB22746525 Is anyone else seeing this? Would appreciate dups on the Feedback report. Any workaround suggestions from DTS welcome.

In iOS 18, requesting Contacts access via CNContactStore.requestAccess(for:) triggers a two-stage authorization flow: First stage: the standard "Allow / Don't Allow" alert Second stage: a sheet titled "How do you want to share contacts?" with two options — "Select Contacts" and "Share All [N] Contacts" My question is about the second-stage sheet specifically. It does not appear to have a Cancel or Close button, and swipe-down to dismiss does not work on the devices I've tested (iOS 18.x). If a user reaches this second prompt and decides they don't want to choose either option, how are they expected to dismiss it? Is this intentional behavior?

Hi everyone, We are working on an app that requires access to devices on the local network (Bonjour / LAN discovery + direct socket communication). We are currently struggling with the Local Network privacy permission flow introduced by Apple. From our understanding, there is no dedicated public API to explicitly request Local Network permission or to reliably determine the current authorization state before attempting network activity. We have tried several commonly suggested approaches to trigger the permission dialog, including: Bonjour browsing via NWBrowser Publishing/listening with NetService UDP/TCP socket attempts on local subnet NWConnection / NWListener Triggering discovery after app launch and after foreground transitions We already added the required entries in: NSLocalNetworkUsageDescription NSBonjourServices However, the behavior is inconsistent across devices and OS versions: Sometimes the popup appears immediately Sometimes it never appears Sometimes network operations silently fail without callback clarity In some cases callbacks are delayed or ambiguous Reinstalling/resetting permissions changes behavior unpredictably Our main challenges are: What is currently considered the most reliable Apple-approved method to trigger the Local Network permission prompt? Is there any officially recommended way to determine whether permission is: not determined denied granted Is there any reliable callback or state transition API developers should use? Are there known differences between: NWBrowser NetService BSD sockets NWConnection when it comes to triggering the permission dialog? Are there recommended retry/timing patterns to avoid race conditions during app launch? Is Apple planning to introduce a dedicated authorization API similar to: AVAuthorizationStatus CLAuthorizationStatus PHPhotoLibrary.authorizationStatus() Right now it feels difficult to provide a reliable UX because there is no deterministic way to: proactively request access observe authorization state recover gracefully when the prompt does not appear Any guidance, DTS references, WWDC sessions, or recommended implementation patterns would be greatly appreciated. Thanks!

I have an application that is a VOIP application of sorts that needs access to the microphone. I am using the Mac (Designed for iPad) support to not have to do huge amounts of conditional building and support for all the many iOS specific things my app includes. I never get prompted to allow microphone permissions and I never see my app name appear in Privacy & Security -> Microphone permissions setup. So is it that Mac is just a dead end for any form of an application that needs a microphone and is running under Mac (Designed for iPad) compatibility mode? Why doesn't TCC have some mechanism to notice and grant access to mic use?

Hi everyone, We are investigating a possible iOS permission state issue after a device previously installed our app through TestFlight and later installed the production version from the App Store using the same Bundle ID. Environment: Device: iPhone 15 iOS version: 26.2.1 App distribution history: The app was previously installed through TestFlight and later installed from the App Store Permissions involved: Camera / Photos Issue: When the user opens the App Store version of the app and tries to access a feature that requires Camera or Photos permission, the iOS permission prompt does not appear as expected. Also, the app does not appear under: Settings > Privacy & Security > Camera or: Settings > Privacy & Security > Photos Because of this, the user cannot manually enable the permission. Another user on iOS was able to grant the permissions normally, so the issue appears to be isolated to the device that previously used the TestFlight build. Expected behavior: When the App Store version requests Camera or Photos permission, iOS should display the permission prompt, or the app should appear under Settings > Privacy & Security > Camera/Photos so the user can manage the permission manually. Actual behavior: The permission prompt does not appear, and the app does not appear in the corresponding privacy permission list. Possible cause: It seems like the device may be preserving or reusing a stale privacy permission state from the previous TestFlight installation, since both the TestFlight build and the App Store build use the same Bundle ID. Steps to reproduce: Install the app through TestFlight. Open the app and trigger a Camera/Photos permission request. Grant or deny the permission. Stop testing or remove the TestFlight version. Install the production version from the App Store using the same Bundle ID. Open the App Store version. Trigger the same Camera/Photos permission request flow. Go to Settings > Privacy & Security > Camera/Photos. The app does not appear, or the permission prompt does not behave as expected. Workarounds attempted or suggested: Close and reopen the app. Restart the iPhone. Delete and reinstall the app from the App Store. Stop testing the app from TestFlight. Reset Location & Privacy settings. Question: Has anyone experienced a similar issue where iOS does not show the permission prompt or does not list the app under Privacy & Security after switching from a TestFlight build to the App Store version with the same Bundle ID? Is there a recommended way to fully clear the previous TestFlight permission state, or should this be reported as a possible iOS/TestFlight permission state bug?

Apps that try to access the contents of the pasteboard cause a system prompt to appear asking the user "AppName" would like to paste from "OtherAppName" Do you want to allow this? Don't Allow Paste Allow Paste This prompt does not appear if you implement a UIPasteControl and the user taps it to signal intent to paste, but this control cannot be placed into a UIMenu. I read this could be achieved with UIAction.Identifiers like .paste or .newFromPasteboard but the prompt still appears with the following code. What's the trick? override func viewDidLoad() { super.viewDidLoad() title = "TestPaste" view.backgroundColor = .systemBackground let imageView = UIImageView() imageView.translatesAutoresizingMaskIntoConstraints = false imageView.contentMode = .scaleAspectFit imageView.clipsToBounds = true view.addSubview(imageView) NSLayoutConstraint.activate([ imageView.topAnchor.constraint(equalTo: view.topAnchor), imageView.leadingAnchor.constraint(equalTo: view.leadingAnchor), imageView.trailingAnchor.constraint(equalTo: view.trailingAnchor), imageView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) navigationItem.rightBarButtonItem = UIBarButtonItem(title: "Add", image: UIImage(systemName: "plus"), menu: UIMenu(children: [ UIAction(identifier: .paste) { _ in imageView.image = UIPasteboard.general.image } ])) }

We use TeamCity as our Continuous Integration (CI) solution to build and run automated tests. These are integration tests executed through our 4D application, which is properly code‑signed and notarized. These CI machines are heavily used and build multiple versions per day, making them critical to our development workflow. However, we are experiencing an issue on some machines: after a certain period of time, network communication through our application stops working, while network communication remains fully functional when using third‑party tools (for example, LDAP clients). Based on our investigation, this issue appears to be related to Local Network Privacy management. We have followed the procedure described in Apple’s Technical Note: TN3179: Understanding local network privacy | Apple Developer Documentation to reset network authorizations, but this has not been sufficient to resolve the issue. In addition, our CI environment requires acknowledging a large number of Local Network access permission prompts. Given that these machines build multiple versions per day and are intended to run unattended, this is not practical in an automated CI context. We have around ten Macs dedicated to running these tests, and manually approving these pop‑ups is not a viable solution.

Dear TestFlight Team! I am observing an increasing misuse of TestFlight public and private invites to distribute scam, spam, and potentially malicious builds: I had reported this already in December last year via Feedback assistant, but since the malicious behavior has not stopped, I hope that you can forward my bug reports to the right team: FB21379977, FB21845307 In multiple cases, these builds impersonate well-known apps (e.g. ChatGPT, OpenAI, Meta) by changing the app name and icon after an initial TestFlight approval, misleading users into installing software from unrelated developer accounts. I believe this represents a systemic weakness in the TestFlight review and update flow, enabling targeted phishing or malware distribution outside the App Store review process. My bug reports have attached: TestFlight invitation emails (.eml) Screenshots from TestFlight documenting impersonation behavior ⸻ Steps to reproduce Create a new Apple Developer account. Upload an initial, benign app (e.g. a calculator) as version 1.0.0 and obtain TestFlight approval. Upload a second build: without changing the version number increase build number Change the app name to a well-known product (e.g. “ChatGPT”) Change the app icon to match the impersonated product Invite targeted email addresses to the TestFlight group. Recipients receive an official TestFlight invite and are prompted to install the impersonating app. ⸻ Expected results TestFlight builds that significantly change app identity (name, icon, branding) should: Require additional review, or Be blocked from distribution without re-approval. Developer accounts should not be able to impersonate well-known companies (e.g. “OpenAI Platforms LLC”) without verification. Users should be protected from installing TestFlight builds that materially differ from what was originally reviewed. ⸻ Actual results App name and icon can be changed between TestFlight builds without triggering additional review. TestFlight invites can convincingly impersonate trusted brands. Targeted users may reasonably believe they are installing a legitimate beta. This creates a credible vector for: Phishing (credentials, payment details) Data exfiltration Social engineering attacks I did not install the builds to avoid personal risk, but the attached artifacts should allow Apple’s internal teams to reproduce and analyze the behavior safely. Some more examples:

I was planning to add the Facebook SDK in one of the releases, and I had everything prepared (including changing the privacy policy to state that my app tracks users for advertising). I changed the privacy policy in the App Store connect, thinking that this wouldn't take effect until I sent the app to review. However, after careful consideration, I decided not to move on with the Facebook SDK. My app does not currently track users for advertising. Even though I sent a new release (UI improvements only), I still can't change the privacy policy to remove that my app "tracks" the user. I read multiple posts with people facing similar issues. For my binary, I have: No PrivacyInfo.xcprivacy file NSUserTrackingUsageDescription in Info.plist No tracking declarations in my app configuration I contacted support, and I was redirected here. My case number is 102778907920

Dear Screen Time Team! The Screen Time passcode can be brute-forced without rate limiting by repeatedly attempting guesses through the "Erase All Content and Settings" flow. This allows unlimited passcode attempts with no delay, lockout, or escalation, effectively defeating the purpose of the Screen Time passcode as a parental control mechanism. Impact: Children can bypass Screen Time protections by guessing the passcode No rate limiting enables trivial brute-force attacks (especially for 4-digit codes) Undermines trust in Screen Time as a parental control system Creates real-world safety risks for families relying on Screen Time restrictions Publicly shared methods (e.g. on TikTok) increase likelihood of widespread abuse Steps to Reproduce: Enable Screen Time and set a passcode Open Settings → General → Transfer or Reset iPhone → Erase All Content and Settings When prompted for the Screen Time passcode, enter an incorrect code Repeat the process with different guesses Expected Result: After a small number of incorrect attempts, the system should: enforce exponential backoff delays, or temporarily lock further attempts, or require Apple ID authentication Attempts should be rate-limited across system flows Actual Result: Unlimited passcode attempts are allowed No delay, lockout, or penalty is applied Enables rapid brute-force guessing of the Screen Time passcode Notes: This appears to bypass standard passcode protections that exist in other parts of iOS The issue is especially severe for 4-digit Screen Time passcodes (10,000 combinations) The attack surface is exposed through a system-level reset flow Suggested Fix: Introduce global rate limiting for Screen Time passcode attempts across all entry points Apply exponential backoff after failed attempts Require Apple ID authentication after multiple failures Consider enforcing 6-digit minimum passcodes for Screen Time Log and unify attempt counters across system components Severity: Critical (Security vulnerability enabling brute-force of parental control passcode) See TikTok: https://www.tiktok.com/@aldanaisthebest12170/video/7615053429500644621 Feedback request: FB22263276 – Frederik (one sec app)

I am doing my app for review to publish for the first time, and I did multiple fixes. I lastly got a generic response for the fixes already done. Now unable to figure out what exactly to fix. Can any help be provided by the reply below I received [Apple Reply] Guidelines 5.1.1(i) - Legal - Privacy - Data Collection and 5.1.2(i) - Legal - Privacy - Data Use Issue Description The app appears to share the user’s personal data with a third-party AI service but the app still does not clearly explain what data is sent, identify who the data is sent to, and ask the user’s permission before sharing the data. Apps may only use, transmit, or share personal data after they meet all of the following requirements: Disclose what data will be sent Specify who the data is sent to Obtain the user’s permission before sending data Identify in the privacy policy what data the app collects, how it collects that data, all uses of that data, and confirm any third party the app shares data with provides the same or equal protection Next Steps If the app sends user data to a third-party AI service, revise the app to explain what data is sent, identify who the data is sent to, and ask the user’s permission before sharing personal data with a third-party AI service. If it does not already, the app’s privacy policy must also identify what data the app collects, how it collects that data, and all uses of that data, including if it is shared with a third-party AI service. Note that only including this information in the app's Terms of Service or Privacy Policy is not sufficient. If the app does not send user data to a third-party AI service or does not include a third-party AI service, reply to this rejection to confirm and add this information to the App Review Information section of App Store Connect.

We’re having an iPad issue accessing the local network with iPadOS 26.3. We have an automation system that tests our app on an iPad using accessibility tags. the XCTest test code sends messages from the iPad via TCP/IP to setup external test equipment. The messages abruptly stopped transmitting across the iPad blood-brain barrier with iPadOS 26.3 (26.2.1 and earlier works fine). The technique that worked involved installing a helper app with the same bundleID as our app, allowing the helper app to access the network, and when our app runs it has network access through the helper. It’s clever and kludgey. Forums that we referenced in the past: https://developer.apple.com/forums/thread/663858 TN3179: Understanding local network privacy | Apple Developer Documentation I suspect that something was changed in 26.3 that closed our window. I need two things: ID what is different in 26.3 and fix the automation system. If there’s a new way for XCUITest code to access the local network I’m happy to try it out.