Should there be separate intents to open each supported file type? Or a single intent, and my code sniffs out the format?

Hello, I have an AppIntent that uses the AudioPlaybackIntent to trigger my app to open and initiate an AVPlayer that plays back a media stream I control. When the phone is unlocked, everything works as I expect. The app opens and plays the audio. However, when the phone is locked, any attempt to invoke the intent causes a "Request Code" dialog to be displayed. This seems counter to what I would expect with the AudioPlaybackIntent usage. Am I able to accomplish what I'm after here with AppIntents? Does the fact that I'm using openAppWhenRun require me to have the phone unlocked somehow? import AppIntents import Foundation struct PlayStationAppIntent: AudioPlaybackIntent { static var title: LocalizedStringResource = "Play radio station" static var description: IntentDescription = .init("Play radio station") static var notification: Notification.Name = .init("playStation") static var openAppWhenRun: Bool = true init() {} func perform() async throws -> some IntentResult { AudioPlayerService.shared.play() return .result() } }

Hi Community, I'm new on Siri intents and I'm trying to introduce into my App a Siri Intent for Car Commands. The objective is to list into the Apple Maps the Car list of my App. Currently I've created my own target with its corresponding IntentHandlings, but in the .intentdefinition file of my App, I'm not able to find the List Car Intent. https://developer.apple.com/documentation/sirikit/car-commands Do I need some auth? Also I share my info.plist from the IntentExtension. Thank you very much, David.

Hi We have an AppleTV app that is used to continuously display information (digital signage). One of our clients reports that their AppleTV returns to the homescreen by morning. While our recommendation is to setup Mobile Device Management to lock the AppleTV into running only our app, not every client will have the IT knowledge to set this up. So we're trying to figure out possible causes for the app getting closed. We've not received any crash reports, nor does the device give any indication the app crashed. The energy saving settings are set to run continuously without sleep. The client is reporting this happens every night, so it seems unlikely to be caused by tvOS updates. Are there other things I could rule out to find the cause of this issue? Any ideas are welcome, thanks!

Hello, I’m developing a third-party VoIP app called Heyno and trying to support Siri-initiated calls so they behave like WhatsApp / FaceTime, especially from the lock screen. Target behavior From the locked device, the user says: “Hey Siri, call <contact> using Heyno” Expected result: • System CallKit audio-call UI appears. • No “continue in ” sheet, no forced unlock or foregrounding. • Our app handles the VoIP leg in the background via CXProviderDelegate. WhatsApp already does this with: “Hey Siri, call <contact> on WhatsApp” I’m trying to reproduce that behavior for Heyno using public APIs. I have followed the SiriKit + CallKit VoIP docs but cannot get a clean Siri → CallKit → app flow from the lock screen without either: Being forced into .continueInApp (unlock + foreground), or Hitting CallKit transaction errors when starting the call from the app in response to the intent. Current implementation Intents extension (INStartCallIntentHandling) • resolveContacts(for:with:) normalizes to E.164 and returns INPersonResolutionResult.success. • resolveDestinationType → .success(.normal). • resolveCallCapability → .success(.audioCall). Confirm / handle currently: func confirm(intent: INStartCallIntent, completion: @escaping (INStartCallIntentResponse) -> Void) { completion(INStartCallIntentResponse(code: .ready, userActivity: nil)) } func handle(intent: INStartCallIntent, completion: @escaping (INStartCallIntentResponse) -> Void) { completion(INStartCallIntentResponse(code: .ready, userActivity: nil)) } Earlier, I used .continueInApp with an NSUserActivity carrying the normalized number and metadata, but that always produced a “Continue in Heyno” sheet that requires unlock and foreground, which breaks the lock-screen Siri flow. App target – CallKit provider In the app I have CXProvider + CXProviderDelegate, which work correctly when calls are initiated from inside the app: func provider(_ provider: CXProvider, perform action: CXStartCallAction) { let handle = action.handle.value // Start VoIP / WebRTC / LiveKit / Asterisk call here provider.reportOutgoingCall(with: action.callUUID, startedConnectingAt: Date()) provider.reportOutgoingCall(with: action.callUUID, connectedAt: Date()) action.fulfill() } If I construct a CXStartCallAction and submit it via CXCallController.request(...) from the app, CallKit UI appears and our pipeline runs correctly. What I tried and what fails Starting CallKit from the Intents extension Calling CXCallController.request(...) directly from handle(intent:completion:) in the extension always yields: com.apple.CallKit.error.requesttransaction error 1 (unentitled) The extension does not have the CallKit entitlement, and the docs say not to initiate calls from the extension, so this path seems unsupported. Using .continueInApp + NSUserActivity Pattern: • handle(intent:) builds NSUserActivity (activityType = NSStringFromClass(INStartCallIntent.self), title = "Heyno Start Call", userInfo with E.164 handle, etc.). • Returns INStartCallIntentResponse(code: .continueInApp, userActivity: activity). • App receives the activity, then starts CallKit + VoIP. Functionally this works, but iOS always requires unlock + foreground (“Continue in Heyno”), which is not acceptable for a Siri lock-screen call. App group + Darwin notification (extension → app → CallKit) Experiment: • Extension writes the normalized number into an app-group UserDefaults. • Extension posts a Darwin notification. • App (if running) listens, reads the number, and initiates CXStartCallAction + VoIP. Observed: • Works only when the app is already running in the background; a killed app is not woken. • In some states I see CXErrorCodeRequestTransactionError.invalidAction (error 6) if I try to issue a CXStartCallAction while CallKit is already doing something as part of the Siri flow. • Siri sometimes replies “There was a problem with the app,” likely because CallKit rejects the transaction or sees duplicate/conflicting actions. My understanding so far • The Intents extension should resolve/confirm the intent but not start the call. • The source of truth for starting a call should be: Siri → CallKit → app’s CXProviderDelegate.provider(_:perform: CXStartCallAction) • The app then starts the VoIP leg, reports started/connected, and fulfills. Where I am stuck What is not clear is how Siri is supposed to route an INStartCallIntent into CallKit for a third-party VoIP app on a locked device without using .continueInApp. If my extension simply: • resolves the contact, • confirm → .ready, • handle → .ready (no NSUserActivity, no CallKit), I do not see a documented mechanism that causes: “Hey Siri, call <contact> using Heyno” on the lock screen to: • Present a CallKit audio call bound to Heyno, and • Deliver CXStartCallAction to my CXProviderDelegate while the app stays in the background. Questions For third-party VoIP apps today, is it recommended to implement INStartCallIntentHandling at all, or should we rely only on CallKit registration and Siri’s built-in support for “Call with ” (no SiriKit extension)? If an INStartCallIntentHandling extension is still the intended pattern: • Should confirm/handle simply return .ready and never start CallKit or set NSUserActivity? • In that case, is Siri expected to invoke CallKit on our behalf and create a CXStartCallAction targeting our provider, even when the device is locked and the app is not foreground? Is there any supported way for a Siri-triggered third-party VoIP call to start from the lock screen via CallKit without: • using .continueInApp (unlock + foreground), and • starting CallKit directly from the Intents extension (unentitled)? Is there any additional configuration, entitlement, provisioning profile flag, or Info.plist key required so that Siri can map “Call using Heyno” directly to our CallKit provider and background VoIP implementation? Current options: • .continueInApp + NSUserActivity → works, but always requires unlock + app UI. • Start CallKit from the extension → fails with “unentitled” and appears unsupported. • Extension → app-group + notification → app → CallKit → VoIP → fragile, with intermittent CXErrorCodeRequestTransactionError.invalidAction. • Remove the extension and hope Siri/CallKit auto-routes to our provider → unclear if this is supported for third-party VoIP apps or reserved for privileged apps. I would appreciate guidance on the intended architecture for this scenario, and whether the “Siri from lock screen → CallKit UI → background VoIP call” flow is achievable for an App Store VoIP app like Heyno using public APIs only.

The published "Next steps for apps distributed in Texas" says "A parent or guardian in Texas can withdraw consent for any app, which will block launching of the app on the child or teen’s device." My question is: will this also block notifications sent to that app from showing up on that device? Or will notifications still be delivered to the notification center, even though the app can't be launched? (Specifically, notifications sent from a server via Firebase topic/token). If notifications are not blocked automatically, what is the expected flow for this scenario? My app sends notifications from a server like this. I could implement client-side code to say "if consent is revoked, unsubscribe from notifications", but if the OS blocks launching of the app, this client-side code would never run. Similarly, I could subscribe to the server notifications for when consent is revoked, but my app is free & accountless, so I'm not aware of any information in the server notification that I could use to identify the specific user whose notifications should be stopped. (For example my users won't have an appAccountToken because they never made a purchase). Guidance would be much appreciated. I'm trying to comply with the law but I don't know how.

Hi everyone, I'm looking for a way to programmatically set the left/right audio balance to perfect center (50/50) using either a Terminal command or AppleScript. Background: The audio balance slider in System Settings &gt; Sound &gt; Output &amp; Input works functionally, but I have difficulty determining when it's positioned at the exact center point. The visual nature of the slider makes it challenging for me to achieve the precision I need, and I end up adjusting it repeatedly trying to get it perfectly centered. What I'm looking for: A Terminal command that can set the audio balance to exact center An AppleScript that accomplishes the same thing Any other programmatic method to ensure perfect 50/50 balance I've tried searching through the defaults command documentation and Core Audio frameworks but haven't found the right approach yet. Has anyone successfully automated this setting before? Any help would be greatly appreciated! Thanks in advance, Dylan

From https://developer.apple.com/forums/thread/803945?answerId=862153022#862153022, the testing of Age Range API was not available through xcode simulator back in Oct 2025. Is this available now? In particular: Is requestAgeRange testing available through simulator? Is requestAgeRange testing with sandbox account available through simulator? Is isEligibleForAgeFeatures available through simulator? Is isEligibleForAgeFeatures testing with sandbox account available through simulator? If the answer is "yes" to any of the above, which version of the xcode and ios version should I use? So far I didn't get any of the above working on the simulator, and I can't find any documentation on the answers above. Thank you!

Modern versions of macOS use a file system permission model that’s far more complex than the traditional BSD rwx model, and this post is my attempt at explaining that model. If you have a question about this, post it here on DevForums. Put your thread in the App & System Services > Core OS topic area and tag it with Files and Storage. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" On File System Permissions Modern versions of macOS have five different file system permission mechanisms: Traditional BSD permissions Access control lists (ACLs) App Sandbox Mandatory access control (MAC) Endpoint Security (ES) The first two were introduced a long time ago and rarely trip folks up. The second two are newer, more complex, and specific to macOS, and thus are the source of some confusion. Finally, Endpoint Security allows third-party developers to deny file system operations based on their own criteria. This post offers explanations and advice about all of these mechanisms. Error Codes App Sandbox and the mandatory access control system are both implemented using macOS’s sandboxing infrastructure. When a file system operation fails, check the error to see whether it was blocked by this sandboxing infrastructure. If an operation was blocked by BSD permissions or ACLs, it fails with EACCES (Permission denied, 13). If it was blocked by something else, it’ll fail with EPERM (Operation not permitted, 1). If you’re using Foundation’s FileManager, these error are both reported as Foundation errors, for example, the NSFileReadNoPermissionError error. To recover the underlying error, get the NSUnderlyingErrorKey property from the info dictionary. App Sandbox File system access within the App Sandbox is controlled by two factors. The first is the entitlements on the main executable. There are three relevant groups of entitlements: The com.apple.security.app-sandbox entitlement enables the App Sandbox. This denies access to all file system locations except those on a built-in allowlist (things like /System) or within the app’s containers. The various “standard location” entitlements extend the sandbox to include their corresponding locations. The various “file access temporary exceptions” entitlements extend the sandbox to include the items listed in the entitlement. Collectively this is known as your static sandbox. The second factor is dynamic sandbox extensions. The system issues these extensions to your sandbox based on user behaviour. For example, if the user selects a file in the open panel, the system issues a sandbox extension to your process so that it can access that file. The type of extension is determined by the main executable’s entitlements: com.apple.security.files.user-selected.read-only results in an extension that grants read-only access. com.apple.security.files.user-selected.read-write results in an extension that grants read/write access. Note There’s currently no way to get a dynamic sandbox extension that grants executable access. For all the gory details, see this post. These dynamic sandbox extensions are tied to your process; they go away when your process terminates. To maintain persistent access to an item, use a security-scoped bookmark. See Accessing files from the macOS App Sandbox. To pass access between processes, use an implicit security scoped bookmark, that is, a bookmark that was created without an explicit security scope (no .withSecurityScope flag) and without disabling the implicit security scope (no .withoutImplicitSecurityScope flag)). If you have access to a directory — regardless of whether that’s via an entitlement or a dynamic sandbox extension — then, in general, you have access to all items in the hierarchy rooted at that directory. This does not overrule the MAC protection discussed below. For example, if the user grants you access to ~/Library, that does not give you access to ~/Library/Mail because the latter is protected by MAC. Finally, the discussion above is focused on a new sandbox, the thing you get when you launch a sandboxed app from the Finder. If a sandboxed process starts a child process, that child process inherits its sandbox from its parent. For information on what happens in that case, see the Note box in Enabling App Sandbox Inheritance. IMPORTANT The child process inherits its parent process’s sandbox regardless of whether it has the com.apple.security.inherit entitlement. That entitlement exists primarily to act as a marker for App Review. App Review requires that all main executables have the com.apple.security.app-sandbox entitlement, and that entitlements starts a new sandbox by default. Thus, any helper tool inside your app needs the com.apple.security.inherit entitlement to trigger inheritance. However, if you’re not shipping on the Mac App Store you can leave off both of these entitlement and the helper process will inherit its parent’s sandbox just fine. The same applies if you run a built-in executable, like /bin/sh, as a child process. When the App Sandbox blocks something, it might generates a sandbox violation report. For information on how to view these reports, see Discovering and diagnosing App Sandbox violations. To learn more about the App Sandbox, see the various links in App Sandbox Resources. For information about how to embed a helper tool in a sandboxed app, see Embedding a Command-Line Tool in a Sandboxed App. Mandatory Access Control Mandatory access control (MAC) has been a feature of macOS for many releases, but it’s become a lot more prominent since macOS 10.14. There are many flavours of MAC but the ones you’re most likely to encounter are: Full Disk Access (macOS 10.14 and later) Files and Folders (macOS 10.15 and later) App bundle protection (macOS 13 and later) App container protection (macOS 14 and later) App group container protection (macOS 15 and later) Data Vaults (see below) and other internal techniques used by various macOS subsystems Mandatory access control, as the name suggests, is mandatory; it’s not an opt-in like the App Sandbox. Rather, all processes on the system, including those running as root, as subject to MAC. Data Vaults are not a third-party developer opportunity. See this post if you’re curious. In the Full Disk Access and Files and Folders cases, users grant a program a MAC privilege using System Settings > Privacy & Security. Some MAC privileges are per user (Files and Folders) and some are system wide (Full Disk Access). If you’re not sure, run this simple test: On a Mac with two users, log in as user A and enable the MAC privilege for a program. Now log in as user B. Does the program have the privilege? If a process tries to access an item restricted by MAC, the system may prompt the user to grant it access there and then. For example, if an app tries to access the desktop, you’ll see an alert like this: “AAA” would like to access files in your Desktop folder. [Don’t Allow] [OK] To customise this message, set Files and Folders properties in your Info.plist. This system only displays this alert once. It remembers the user’s initial choice and returns the same result thereafter. This relies on your code having a stable code signing identity. If your code is unsigned, or signed ad hoc (Signed to Run Locally in Xcode parlance), the system can’t tell that version N+1 of your code is the same as version N, and thus you’ll encounter excessive prompts. Note For information about how that works, see TN3127 Inside Code Signing: Requirements. The Files and Folders prompts only show up if the process is running in a GUI login session. If not, the operation is allowed or denied based on existing information. If there’s no existing information, the operation is denied by default. For more information about app and app group container protection, see the links in Trusted Execution Resources. For more information about app groups in general, see App Groups: macOS vs iOS: Working Towards Harmony On managed systems the site admin can use the com.apple.TCC.configuration-profile-policy payload to assign MAC privileges. For testing purposes you can reset parts of TCC using the tccutil command-line tool. For general information about that tool, see its man page. For a list of TCC service names, see the posts on this thread. Note TCC stands for transparency, consent, and control. It’s the subsystem within macOS that manages most of the privileges visible in System Settings > Privacy & Security. TCC has no API surface, but you see its name in various places, including the above-mentioned configuration profile payload and command-line tool, and the name of its accompanying daemon, tccd. While tccutil is an easy way to do basic TCC testing, the most reliable way to test TCC is in a VM, restoring to a fresh snapshot between each test. If you want to try this out, crib ideas from Testing a Notarised Product. The MAC privilege mechanism is heavily dependent on the concept of responsible code. For example, if an app contains a helper tool and the helper tool triggers a MAC prompt, we want: The app’s name and usage description to appear in the alert. The user’s decision to be recorded for the whole app, not that specific helper tool. That decision to show up in System Settings under the app’s name. For this to work the system must be able to tell that the app is the responsible code for the helper tool. The system has various heuristics to determine this and it works reasonably well in most cases. However, it’s possible to break this link. I haven’t fully research this but my experience is that this most often breaks when the child process does something ‘odd’ to break the link, such as trying to daemonise itself. If you’re building a launchd daemon or agent and you find that it’s not correctly attributed to your app, add the AssociatedBundleIdentifiers property to your launchd property list. See the launchd.plist man page for the details. Scripting MAC presents some serious challenges for scripting because scripts are run by interpreters and the system can’t distinguish file system operations done by the interpreter from those done by the script. For example, if you have a script that needs to manipulate files on your desktop, you wouldn’t want to give the interpreter that privilege because then any script could do that. The easiest solution to this problem is to package your script as a standalone program that MAC can use for its tracking. This may be easy or hard depending on the specific scripting environment. For example, AppleScript makes it easy to export a script as a signed app, but that’s not true for shell scripts. TCC and Main Executables TCC expects its bundled clients — apps, app extensions, and so on — to use a native main executable. That is, it expects the CFBundleExecutable property to be the name of a Mach-O executable. If your product uses a script as its main executable, you’re likely to encounter TCC problems. To resolve these, switch to using a Mach-O executable. For an example of how you might do that, see this post. Endpoint Security Endpoint Security (ES) is a general mechanism for third-party products to enforce custom security policies on the Mac. An ES client asks ES to send it events when specific security-relevant operations occur. These events can be notifications or authorisations. In the case of authorisation events, the ES client must either allow or deny the operation. As you might imagine, the set of security-relevant operations includes file system operations. For example, when you open a file using the open system call, ES delivers the ES_EVENT_TYPE_AUTH_OPEN event to any interested ES clients. If one of those ES client denies the operation, the open system call fails with EPERM. For more information about ES, see the Endpoint Security framework documentation. Revision History 2025-11-04 Added a discussion of Endpoint Security. Made numerous minor editorial changes. 2024-11-08 Added info about app group container protection. Clarified that Data Vaults are just one example of the techniques used internally by macOS. Made other editorial changes. 2023-06-13 Replaced two obsolete links with links to shiny new official documentation: Accessing files from the macOS App Sandbox and Discovering and diagnosing App Sandbox violations. Added a short discussion of app container protection and a link to WWDC 2023 Session 10053 What’s new in privacy. 2023-04-07 Added a link to my post about executable permissions. Fixed a broken link. 2023-02-10 In TCC and Main Executables, added a link to my native trampoline code. Introduced the concept of an implicit security scoped bookmark. Introduced AssociatedBundleIdentifiers. Made other minor editorial changes. 2022-04-26 Added an explanation of the TCC initialism. Added a link to Viewing Sandbox Violation Reports.  Added the TCC and Main Executables section. Made significant editorial changes. 2022-01-10 Added a discussion of the file system hierarchy. 2021-04-26 First posted.

Hello, I have a question about the default UI in an App Clip. I know that when App Clip launches, a system banner appears at the top for a few seconds, prompting the user to download the full app from the App Store. I'd like to confirm if this is the standard, default behavior for all App Clips. More importantly, is there any way to disable or hide this banner? We would prefer to manage the prompt to download the full app within our own UI. Thanks in advance for your help!

I regularly see questions, both here on the Apple Developer Forums and in my Day Job™ at DTS, that are caused by a fundamental misunderstanding of how background execution works on iOS. These come in many different variants, for example: How do I keep my app running continuously in the background? If I schedule a timer, how do I get it to fire when the screen is locked? How do I run code in the background every 15 minutes? How do I set up a network server that runs in the background? How can my app provide an IPC service to another one of my apps while it’s in the background? How can I resume my app in the background if it’s been ‘force quit’ by the user? The short answer to all of these is You can’t. iOS puts strict limits on background execution. Its default behaviour is to suspend your app shortly after the user has moved it to the background; this suspension prevents the process from running any code. There’s no general-purpose mechanism for: Running code continuously in the background Running code at some specific time in the background Running code periodically at a guaranteed interval Resuming in the background in response to a network or IPC request [1] However, iOS does provide a wide range of special-purpose mechanisms for accomplishing specific user goals. For example: If you’re building a music player, use the audio background mode to continue playing after the user has moved your app to the background. If you’re building a timer app, check out the AlarmKit framework. On older systems, use a local notification to notify the user when your timer has expired. If you’re building a video player app, use AVFoundation’s download support. Keep in mind that the above is just a short list of examples. There are many other special-purpose background execution mechanisms, so you should search the documentation for something appropriate to your needs. IMPORTANT Each of these mechanisms fulfils a specific purpose. Do not attempt to use them for some other purpose. Before using a background API, read clause 2.5.4 of the App Review Guidelines. Additionally, iOS provides some general-purpose mechanisms for background execution: To resume your app in the background in response to an event on your server, use a background notification (aka a ‘silent’ push). For more information, see Pushing background updates to your App. To request a small amount of background execution time to refresh your UI, use the BGAppRefreshTaskRequest class. To request extended background execution time, typically delivered overnight when the user is asleep, use the BGProcessingTaskRequest class. To continue user-visible work after the user has left your app, use the BGContinuedProcessingTask class. To prevent your app from being suspended for a short period of time so that you can complete some user task, use a UIApplication background task. For more information on this, see UIApplication Background Task Notes. To download or upload a large HTTP resource, use an URLSession background session. All of these mechanisms prevent you from abusing them to run arbitrary code in the background. As an example, consider the URLSession resume rate limiter. For more information about these limitations, and background execution in general, I strongly recommend that you watch WWDC 2020 Session 10063 Background execution demystified [2]. It’s an excellent resource. Specifically, this talk addresses a common misconception about the app refresh mechanism (BGAppRefreshTaskRequest and the older background fetch API). Folks assume that app refresh will provide regular background execution time. That’s not the case. The system applies a range of heuristics to decide which apps get app refresh time and when. This is a complex issue, one that I’m not going to try to summarise here, but the take-home message is that, if you expect that the app refresh mechanism will grant you background execution time, say, every 15 minutes, you’ll be disappointed. In fact, there are common scenarios where it won’t grant you any background execution time at all! Watch the talk for the details. [1] iOS 26 introduced support for general-purpose IPC, in the form of enhanced security helper extensions. However, these can only be invoked by the container app, and that means there’s no background execution benefit. [2] Sadly the video is currently not available from Apple. I’ve left the link in place just in case it comes back. When the user ‘force quits’ an app by swiping up in the multitasking UI, iOS interprets that to mean that the user doesn’t want the app running at all. So: If the app is running, iOS terminates it. iOS also sets a flag that prevents the app from being launched in the background. That flag gets cleared when the user next launches the app manually. This gesture is a clear statement of user intent; there’s no documented way for your app to override the user’s choice. Note In some circumstances iOS will not honour this flag. The exact cases where this happens are not documented and have changed over time. Finally, if you have questions about background execution that aren’t covered by the resources listed here, please open a new thread on the forums with the details. Put it in a reasonable subtopic and tag it appropriately for the technology you’re using; if nothing specific springs to mind, use Background Tasks. Also, make sure to include details about the specific problem you’re trying to solve because, when it comes to background execution, the devil really is in the details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Change history: 2026-01-09 Added a reference to AlarmKit. Added a reference to BGContinuedProcessingTask. Add a footnote about IPC and another one about WWDC 2020 Session 10063. Made other minor editorial changes. 2024-03-21 Added a discussion of ‘force quit’. 2023-05-11 Added a paragraph that explains a common misconception about the app refresh mechanism. Made other minor editorial changes. 2021-08-12 Added more entries to the common questions list, this time related to networking and IPC. Made minor editorial changes. 2021-07-26 Extended the statement about what’s not possible to include “running code periodically at a guaranteed interval”. 2021-07-22 First posted.

Are we planning to have some APIs or methods to know that status of Call blocking extension and message filter extension in future releases as currently it is not available.

Hi, I developed an iOS app which will do SMS filtering by following this documentation. https://developer.apple.com/documentation/identitylookup/sms-and-mms-message-filtering) I built the app and send Test Flights to different testers. All the Testers from Sri Lanka (an asian country) says filtering is working and they can see all the enabled categories on the Messages too (including iOS 26). But the testers from Mexico cannot see the categories and filtering is not working. On official documentation there is nothing about supported countries. But I found true caller article https://support.truecaller.com/support/solutions/articles/81000406341-how-do-i-enable-sms-filtering-on-iphone mentioning it support only few countries for SMS filtering. Currently available in the following countries: India, Nigeria, South Africa, Kenya, Bangladesh, Sri Lanka. Our previous Categories filtering are still available for: Australia, Bahrain, Canada, Ghana, Tanzania, United Kingdom, United Arab Emirates, United States of America, Zambia Following article https://clearstream.io/blog/ios-26-iphone-new-text-message-filtering is saying some categories are supported by only Brazil and India. Still I could not find any official documentations saying different country supports.

Both follow the same pattern: show the image that is being shared along with a CTA button about doing something with it in their app. When you tap the button, their app opens. Is there some kind of magic conditions that tapping the button creates that makes extensionContext.open(_ URL: URL, completionHandler: ((Bool) -> Void)?) accept a URL for opening the app? Or are they just using the "walk the responder chain" hack and using the user's intent to do something in their app as sufficient justification for using it? I've tried opening a registered URL scheme for my app synchronously with the button tap, but it still is refusing to open (callback returns false).

I'm soliciting you because I'm having a problem using the 3D short cut for my ios application in uikit in the AppDelegate file but it's impossible to redirect the route when the user has completely killed the application. It works as a background application. I'd like it to redirect to the searchPage search page when the application is fully closed and the user clicks on search with 3D touch. final class AppDelegate: UIResponder, UIApplicationDelegate { lazy var window: UIWindow? = { return UIWindow(frame: UIScreen.main.bounds) }() private let appDependencyContainer = Container() private let disposeBag = DisposeBag() var pendingDeeplink: String? private lazy var onboardingNavigationController: UINavigationController = { let navigationController = UINavigationController(nibName: nil, bundle: nil) navigationController.setNavigationBarHidden(true, animated: false) return navigationController }() private func handleShortcutItem(_ shortcutItem: UIApplicationShortcutItem) { guard let windowScene = UIApplication.shared.connectedScenes.first as? UIWindowScene, let window = windowScene.windows.first(where: { $0.isKeyWindow }), let rootVC = window.rootViewController else { DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { [weak self] in self?.handleShortcutItem(shortcutItem) } return } if let presentedVC = rootVC.presentedViewController { presentedVC.dismiss(animated: !UIAccessibility.isReduceMotionEnabled) { [weak self] in self?.executeShortcutNavigation(shortcutItem) } } else { executeShortcutNavigation(shortcutItem) } } private func executeShortcutNavigation(_ shortcutItem: UIApplicationShortcutItem) { DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) { [weak self] in guard let self = self else { return } switch shortcutItem.type { case ShortcutType.searchAction.rawValue: self.mainRouter.drive(to: .searchPage(.show), origin: AppRoutingOrigin()) case ShortcutType.playAction.rawValue: self.mainRouter.drive(to: .live(channel: Channel(), appTabOrigin: AppTabOrigin.navigation.rawValue), origin: AppRoutingOrigin()) case ShortcutType.myListHistoryAction.rawValue: self.mainRouter.drive(to: .myList(.history), origin: AppRoutingOrigin()) default: break } } } What I've tried: Adding delays with DispatchQueue.main.asyncAfter Checking for window availability and rootViewController Dismissing presented view controllers before navigation Environment: iOS 15+ Swift 6 Using custom router system (mainRouter) App supports both SwiftUI and UIKit Questions: What's the best practice for handling shortcuts on cold launch vs warm launch? How can I ensure the router is properly initialized before navigation?

Is it possible to develop for TelephonyMessagingKit on iOS 26 outside of the EU? If so, how is this accomplished? I have added the 'Default Carrier Messaging App' entitlement to my project, but I do not see an option to set my app as a default option in settings on my device. I am not located inside of the EU, but would like to test this functionality.

find my在添加配件是，持续一直卡在“即将完成设置”这一步.这是由于什么原因呢？而且一直保持很长时间，也不会退出，也不会提示任何错误信息。

Subject: Call Directory Extension Enable Failure for Individual User Dear Apple Developer Support, We are experiencing an issue with our Call Directory Extension where one specific user cannot enable it, while thousands of other users on the same iOS version can enable it successfully. Issue Details: App: 美信 (Midea Connect) Problem: Extension fails to enable with error: "请求'美信'的数据时失败" (Failed to request data from app) Affected: 1 user out of thousands iOS Version: 26.0.1 What Works: All other users can enable the extension normally Same iOS version, no issues App Group and Extension identifier are correctly configured User Has Tried: Reinstall app - No effect Toggle extension off/on - Still fails Restart device - No improvement

I have a question regarding CarKeyErrorCode in the CarKey framework. I plan to use the following methods in the CarKey framework: CarKeyRemoteControl.start CarKeyRemoteControlSession.vehicleReports CarKeyRemoteControlSession.perform RemoteKeylessEntryAction.ExecutionRequest.results Each of the above methods throws an Error. Are these different from CarKeyErrorCode? Is CarKeyErrorCode only used in CarKeyRemoteControlSessionDelegate.remoteControlSession(_:didInvalidateWithError:)? If methods 1-4 do not return CarKeyErrorCode, what kind of Error do they return? Thank you in advance.

Its possible to add the Declared Age Range entitlement to extensions, in particular I'm looking at a Notification Service Extension. However the DAR requestAgeRange() API takes a view controller as a parameter. Presumably therefore its not possible for a notification service extension to obtain the age range itself directly? Yes the extension can read it from shared groups if the app reads it and set it into the group. However the scenario I'm thinking of is this: App runs and gets the age range. Sets its functionality accordingly. The server sends pushes which are intercepted by the notification service extension, the extension adjusts its functionality based upon what the app wrote to shared groups The user changes the age range setting, but the app doesn't run. The extension keeps receiving pushes but its functionality is now out of sync with the age range as its not able to obtain it directly