My share extension accepts a shared location and I want to bring the user into the containing app at the corresponding map screen. I understandNSExtensionContext.open(_:completionHandler:) is restricted to Today widgets per the App Extension Programming Guide, and I observe it reporting success == false. The technique I am asking about is different: walking the extension's responder chain to obtain the UIApplication instance, then calling open(_:options:completionHandler:) on it. In a minimal sample this launches the containing app and the completion handler reports success == true, on both iOS 26 and iOS 27. What makes this worth asking rather than assuming: It never references UIApplication.shared, which is annotated NS_EXTENSION_UNAVAILABLE_IOS. open(_:options:completionHandler:) itself carries no extension-unavailable annotation in the SDK, so the call compiles cleanly even with APPLICATION_EXTENSION_API_ONLY = YES. I am aware of https://developer.apple.com/forums/thread/773342, where an Apple Frameworks Engineer wrote that "There's no supported way for you to launch your app directly from App Extensions, except Today and Widgets." That thread does not cover the responder chain specifically, which is why I am asking. My questions: a) Is this permitted? Is obtaining UIApplication via the responder chain from a Share Extension and calling open(_:options:completionHandler:) considered a violation of App Store Review Guideline 2.5.1 (public APIs used as intended), independent of whether it currently functions? b) If it is not permitted, what is the recommended way for a Share Extension to hand a location to its containing app such that the user arrives at the relevant screen? The code in question, in its entirety: @objc private func openUsingResponderChain() { var responder: UIResponder? = self while let currentResponder = responder { if let application = currentResponder as? UIApplication { application.open(targetURL, options: [:]) { [weak self] success in self?.report("UIApplication via responder chain -> success = \(success)") } return } responder = currentResponder.next } report("No UIApplication found in the responder chain") } Full sample project: https://github.com/valtermak-voya/share-extension-open-url-repro A containing app registering opensample:// plus a share extension target built with APPLICATION_EXTENSION_API_ONLY = YES. The method above is the whole of the extension's logic. Filed with DTS as Case-ID 22452440.

We ship a Live Caller ID Lookup extension (PIR-based) for spam call blocking. It works, and our PIR server is fast. But in practice, whether a call gets blocked depends on the quality of the user's internet connection at the moment the call arrives. The system waits only about 1 second for the blocking response. On a fast, stable connection it arrives in time. On an average or unstable connection it often doesn't, and the spam call rings through. So under the current platform limits we cannot guarantee blocking for every call. How we measured For each call we read the device syslog (CommCenter, CallDirectory, ciphermld, callservicesd) and our server logs. The extension cache was reset before each call, so every call triggered a real network lookup. All times are in ms and measured from addNewIncomingCall. Server-side processing of the PIR query was consistently 51–61 ms. The variance is almost entirely network transfer between the device and the server (or relay): In call D, HTTP/2 metrics show the ~28 KB request was handed to the network stack immediately (outbound_duration_ms=0), but response headers arrived only after 2216 ms. In call E, the device waited ~660 ms between finishing the upload to the relay and receiving the first byte of the response. Connection setup on a new connection cost 176–271 ms (DNS + TCP + TLS, or a QUIC handshake to the relay). Before the first byte was sent, the system spent another 54–225 ms after the call arrived. In the failing cases the syslog shows: CallDirectory: not all blocking fetches returned within 1 second(s) callservicesd: shouldBlock: NO shouldSilence NO The block response (shouldBlock=1) then arrives 100–1500 ms too late, and the call keeps ringing. What works: repeat calls After the first lookup the result is cached on the device. A repeat call from the same number is silenced without contacting the server, whatever the connection speed. In our logs, follow-up calls from the same number were silenced within ~65 ms of addNewIncomingCall, with no network request. So a user may get the first spam call from a number but not the next ones. The first call, though, is exactly the one users complain about. The problem with the 1-second budget Each blocking lookup has to: Send a PIR query Receive a response of ~22–25 KB. Often open a new TLS/QUIC connection through the OHTTP relay. All of this has to fit into about 1 second, together with the system's own overhead before the request is sent. On a good connection that takes about 250–650 ms. On an average mobile or congested Wi-Fi connection it easily goes past 1 second, and nothing the developer can optimize on the server helps. Our server already responds in about 50 ms.

I'm seeing an intermittent split between how different Now Playing surfaces reconcile with a RemoteMediaSessionExtension (the iOS 27 com.apple.nowplaying.remote-media extension point). Control Center and Apple Watch reliably show the current track. The Lock Screen and Dynamic Island occasionally get stuck on the previous track for the remainder of that track. They'll often self-correct once the next track change happens — but not always and never mid-track. The only way to fix it before the track ends is to bring the host app to the foreground. Setup: the extension receives APNs pushes carrying playback/metadata payloads from a third-party speaker system. Each push either resumes an already-alive extension process (update(:)) or cold-starts it (session(:)), which sets content/the Artwork provider closure and returns. All three surfaces read from that exact same synchronous content value — there is no code path in the extension that could serve them differently. Cleanest isolated repro on record (device log timestamps): one track was displaying correctly everywhere. The next track triggered a cold start; the extension decoded the push, resolved and prefetched real artwork, and had content fully populated within under a second. Moments later, that cached artwork was requested and served at Control Center's own request sizes, and Control Center updated correctly. Lock Screen and Dynamic Island made zero requests of any kind — no content query, no artwork fetch — for the entire remainder of that track. This doesn’t appear to be a problem with the apns pushes, I can see from my server that they are successfully sent and Control Center updates correctly but lockscreen and Dynamic Island do not. I tried reducing the artwork size as a test to see if this worked more reliably, but still faced similar issues. Apple Watch remains a consistently-correct surface alongside Control Center, reinforcing that this is isolated to whatever presentation machinery Lock Screen and Dynamic Island specifically share. Ruled out on my side: • Push delivery/decoding — the extension's own receive-time debug dump shows the correct decoded attributes before any surface renders. • Process suspension — this has been observed with the extension actively running throughout, proven by Control Center rendering fresh data from it during the same window. Questions: Is there a known issue where Lock Screen/Dynamic Island stop re-querying a RemoteMediaSessionExtension's content mid-track, after it's already been correctly delivered and rendered elsewhere (Control Center, Watch)? Is Lock Screen/Dynamic Island's own redraw path gated on the app process being foreground, similar to requestToBecomeSystemPrimary()'s documented foreground-only effect? If so, is there any supported way to trigger that reconciliation from a background extension update, short of the user opening the app? Is there a supported way to force-invalidate/redraw Lock Screen's and Dynamic Island's cached presentation for an existing session, without ending and restarting it (which would reset the user's Lock Screen state)?

Description: On iOS 27.0 (24A437) with Apple Intelligence enabled, sharing a Writing Tools result to a share extension fails as soon as the extension shows a keyboard. Steps: Safari (also Chrome, NAVER app): select a paragraph → Writing Tools → Proofread (or Rewrite / Summary). In the result panel tap Share → choose Notes (Apple) or any third-party extension whose sheet focuses a text view. In the extension's sheet, tap the text so the keyboard appears (for SLComposeServiceViewController-based extensions this happens automatically on presentation). Expected: the extension sheet stays open; the user edits and posts. Actual: about 0.3–1.0 s after the keyboard appears, the extension sheet, the share sheet and the Writing Tools panel are all dismissed. Nothing is saved. Apple Notes' own share extension shows the same behaviour when its text is tapped. Impact: no share extension can accept edits from the Writing Tools result panel; developers cannot detect the host or avoid the keyboard when the user wants to type. Device: iPhone 15 Pro (iPhone16,1), iOS 27.0 (24A437)

Hello, I am trying to package and distribute a Safari Web Extension using the web-based Safari Web Extension Packager in App Store Connect. My Apple Developer Program membership is active, and I have already completed the following: Created an explicit Bundle ID. Created an iOS app record in App Store Connect named Kuzey SGK. The app is currently in Prepare for Submission status. I can access the app's Xcode Cloud tab. I can also access Users and Access > Xcode Cloud. According to Apple's documentation: “After creating an app record, navigate to the Xcode Cloud tab. Under Safari Web Extension Packager, click Upload.” However, there is no “Safari Web Extension Packager” section at all under the Xcode Cloud tab for my app. The page only displays the standard Xcode Cloud information and “Get started in Xcode.” I am using App Store Connect from Windows in a web browser. My understanding from Apple's Safari Web Extension documentation is that the web-based packager should allow packaging an existing web extension without requiring a Mac or Xcode. I have not configured a standard Xcode Cloud workflow or connected a source repository, because the Safari Web Extension Packager documentation does not list those steps as prerequisites. Apple Developer Program Support reviewed my request and referred me to the Developer Forums because this appears to be a technical issue. My support case number is 102956602442. Could someone please clarify: Is there an additional step required to enable the Safari Web Extension Packager for a newly created developer account or app? Is a standard Xcode Cloud workflow required before the Packager becomes visible? Is the Packager currently available to all Apple Developer Program members? Thank you.

Somewhere since iOS 26, the LockedCameraCapture framework gets in an unpredictable state after opening the main app from the LockedCamera extension using LockedCameraCaptureSession.openApplication(for userActivity:). (Feedback with sample code to reproduce: FB21966835) Opening the extension from the lock screen again doesn’t open the extension but puts the lock screen in a state as if it has. Content updated from LockedCameraCaptureManager.shared.sessionContentUpdates comes in inconsistently, usually needs the app to be opened again or the extension to be opened. This makes using this extension impossible for me as I use it to record video files that manually need to be imported when the app is launched (so not through PhotoKit). Does anybody have a suggestion to circumvent this issue or how to get this fixed?

We have a macOS USBDriverKit DEXT for our own USB hardware and are currently blocked from production distribution while waiting for the required DriverKit managed capabilities. Team ID: 2H6U9GHYLR Correct request: Request ID: U577A4MPBB Submitted: July 10, 2026 Vendor ID: 0x39D3 (this is our official USB VID) Product IDs: 0x0011, 0x0012, 0x0101 Capabilities: DriverKit USB Transport - VendorID and DriverKit UserClient Access The request has now been pending for 10 weeks and 3 days. There is an unusual complication: we originally submitted request GTL6N6D8K9 on June 24, this request should have been disregarded, but Apple has approved it anyways, 10 weeks after submission. The corrected request (U577A4MPBB) is still not approved. Our implementation is complete and works in development. The production entitlement is now the only blocker preventing us from signing and distributing the driver. Is there any way to have someone check whether U577A4MPBB is correctly in the DriverKit entitlement review queue, or whether additional information is required from us? We can provide documentation confirming ownership of USB VID 0x39D3 if needed. Thank you Simon

I am developing an iOS application with a Location Push Service Extension and am trying to provide managed app configuration to the extension using Apple's ManagedAppConfigurationProvider and Declarative Device Management (DDM). The same managed configuration works correctly in the containing application, but the exact same API fails when called from the Location Push Service Extension. Environment: iOS: 26.2.1 Xcode: 16.4 Extension type: Location Push Service Extension The extension has the following entitlement in both the signed extension and provisioning profile: com.apple.developer.location.push The extension is configured through DDM using ExtensionConfigs: "ExtensionConfigs": { "bundleid (teamid)": { "DataAssetReference": "xxxxxxx" } } The Data Asset is successfully compiled by the MDM server and contains the managed configuration values. The device reports the following DDM status: "config-state": { "app-config-state": { "state": "valid" }, "extension-config-state": { "bundleidofextension": { "state": "unknown" } } } The main application can successfully retrieve the configuration using: let provider = ManagedAppConfigurationProvider() Task { for await configuration in await provider.configurations( ModelManagedAppConfiguration.self ) { print("APP CONFIG = (String(describing: configuration))") } } The same code and the same configuration type are used inside the Location Push Service Extension. Inside the extension, the provider is created successfully: LOCATION EXTENSION: creating ManagedAppConfigurationProvider LOCATION EXTENSION: provider created LOCATION EXTENSION: requesting configurations However, the request fails with: Failed to connect to managedappsd with error Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.devicemanagementclient.managedappsd was invalidated from this process." Failed to fetch managed app configuration. Returning nil. Error: XPC connection failed with error Optional("Couldn’t communicate with a helper application.") Failed to determine managed app configuration changed notification name. Unable to register for notifications. Failed to report configuration error state. Error: XPC connection failed with error Optional("Couldn’t communicate with a helper application.") LOCATION EXTENSION: CONFIG = nil The important observation is that the configuration works from the containing application but fails from the Location Push Service Extension before the configuration reaches the Decodable configuration type. I have also verified: The extension Bundle ID matches the ExtensionConfigs entry. The Team ID matches. com.apple.developer.location.push is present in the signed extension. com.apple.developer.location.push is also present in the provisioning profile. The DDM Data Asset is successfully compiled. The containing application's managed configuration state is valid. The same ManagedAppConfigurationProvider code works in the containing application. According to Apple's documentation, ManagedAppConfigurationProvider provides configurations for a managed app or extension, and ExtensionConfigs is the DDM mechanism for configuring extensions. My question is: Is ManagedAppConfigurationProvider fully supported from a Location Push Service Extension? If it is supported, what could cause managedappsd to reject/invalidate the XPC connection specifically when the request originates from a Location Push Service Extension? Could there be an additional entitlement, extension-specific configuration, or system restriction required for ManagedAppConfigurationProvider to communicate with managedappsd from this type of extension? Any guidance on how to further diagnose the NSCocoaErrorDomain Code=4099 / "Couldn’t communicate with a helper application" error would be appreciated.

For the new IOS 27.0 system on iPhone 18 pro demo, the camera app have a new feature to let users adjust camera focusing from AF to MF. This feature does not require the newest camera module. Therefore, all previous models should be able to have this feature, especially useful via camera control slider. How to get attention of apple camera software development team to work on this...

It is possible for an extension to an app (based on ExtensionFoundation) to declare its own extension point and host its own ExtensionFoundation extensions? Based on the documentation, I am guessing the answer is no, but worth double-checking. What would be the reason to prevent this? Every ExtensionFoundation extension runs in its own process, and may have need to be extended safely just as its host app does. Thank you!

Asking as an individual developer, before building further. Relevant guidelines: 2.5.14, 5.1.1, 5.1.2. Remote support apps are established on the App Store: the user starts a broadcast with RPSystemBroadcastPickerView and a Broadcast Upload Extension, and a human agent views their screen to help them. My design is identical except the frames go to an automated analysis service instead of a human. The results return only to the same user who started the session, to help with their own task on their own device. The design: sessions are started and ended by the user through the system picker, with the standard broadcast indicator visible throughout. Frames are transmitted transiently, never stored, and never seen by any person. There is no remote control or synthetic input of any kind. Captured data is used only for the in session assistance, with explicit consent and privacy policy disclosure per 5.1.2(i). Is swapping the human viewer for an automated analyzer acceptable under the guidelines? And does automated processing of screen content require any disclosures or consent beyond what human viewing requires? Thanks for any guidance.

I’m developing a keyboard extension and noticed this weird issue. When I switch from normal keyboard to custom keyboard there is a faint overlay duplicate of the custom keyboard that comes from the top which makes the switching not seamless and I can’t seem to find the cause of this issue. I initially thought it had to do with the fact that it’s communicating with my app to get the latest data and check for edits but it’s not the case here. when I screen record it doesn’t appear as faint overlay, it appears as the keyboard becoming taller than usual and then sizing down to expected height. iOS26.6.2

We are experiencing an issue when inviting a user to join our Apple Developer Program team through App Store Connect Users and Access. The purpose of adding this user is to include them as an internal TestFlight tester after the invitation is accepted. The invited user received the Apple Developer invitation email and clicked the "Accept invitation" link. The invitation link opens the following page: https://appstoreconnect.apple.com/activation_ds?key=... The page displays "Sign in to accept your invitation" and asks the user to sign in with an Apple Account. After the user signs in successfully, the page redirects back to the same sign-in page and asks the user to sign in again. The invitation cannot be accepted, and the user cannot join the Apple Developer Program team. Steps to reproduce: Go to Users and Access in App Store Connect. Add a new user and send an invitation to join the Apple Developer Program team. The invited user receives the Apple Developer invitation email. The invited user clicks the "Accept invitation" link. The page opens appstoreconnect.apple.com/activation_ds. The user signs in with an Apple Account. After signing in, the page redirects back to the same sign-in page. Repeating the sign-in process results in the same redirect loop. Expected result: The invitation should be accepted after the user signs in, and the user should be added to the Apple Developer Program team. Actual result: The page keeps redirecting back to the sign-in page, and the user cannot accept the invitation. Troubleshooting already tried: Safari and Chrome Private browsing mode Clearing browser cookies Signing out of Apple ID before opening the invitation link again Opening the link directly in the browser instead of an email app embedded browser The issue still occurs.

Feedback submitted: FB24460699 The sample projects are attached to the feedback report. Environment:iOS27 Beta6; iPhone 17Pro Problem:I have encountered a consistently reproducible third-party custom keyboard layout issue in iOS 27.0 beta 1 through beta 6. The custom keyboard initially appears correctly. If I switch apps while the text input remains focused and the keyboard remains visible, and then return to the host app, the system adds a 17-point area above the custom keyboard extension. Steps to reproduce Install and enable a third-party custom keyboard. Switch to the sample custom keyboard and open the host app so that the text editor in the center receives focus. Do not dismiss the keyboard or remove focus from the editor. Return to the Home Screen or switch to another app. Return to the host app. A new blank area now appears above the custom keyboard content. I tested both a system-determined extension view height and an extension view explicitly constrained to 180 points. Both configurations produce exactly the same change. After the foreground transition, the following extension-side values remain unchanged: view.bounds inputView.bounds extension.window.bounds view.safeAreaInsets, which remains {0, 0, 0, 0} The requested 180-point extension height Only the system keyboard frame received by the host app increases by 17 points. I also drew a rounded pink boundary inside the transparent extension root view. When the issue occurs, the new area appears outside that boundary. I tested several third-party keyboards and reproduced the issue with all of them. This suggests that the behavior is caused by iOS rather than by my app. Questions On iOS 27, is it expected behavior for a custom keyboard to gain a 17pt top area after its host app returns from the background? If this is a system issue, is there any workaround that can be used until it is fixed?

Hi team, Earlier, Apple’s documentation clearly mentioned that we needed to submit a request to Apple to obtain the Location Push Service Extension (com.apple.developer.location.push) entitlement. However, when I checked the Apple Developer Portal now, I don’t see an option to request this entitlement for my App ID. Could you please confirm whether this entitlement is still required to be requested from Apple, or if the process has changed and the request is no longer required? Thanks

Hi all! I am seeing the following problem while developing a Quick Look extension to preview Markdown files on iOS and macOS: On iOS 26, Quick Look invokes an installed data-based Quick Look preview extension for .md files resolved as net.daringfireball.markdown, and the extension renders the Markdown correctly. On iOS 27, the same document and the same installed extension no longer work. Quick Look still resolves the file as net.daringfireball.markdown, but it does not invoke the extension and instead displays the raw Markdown source using the generic plain-text preview. Also the same extension runs perfectly on macOS 26 and macOS 27. The extension subclasses QLPreviewProvider, has QLIsDataBasedPreview enabled, and includes net.daringfireball.markdown in QLSupportedContentTypes. As a control, the same installed extension correctly launches and renders equivalent document content when it is presented through a custom Uniform Type Identifier. This confirms that the extension is embedded, installed, and otherwise invocable; the failure is specific to Quick Look's provider selection for Markdown on iOS 27. Reproduction: Install an app containing the data-based preview extension described above. On iOS 26, open an .md document in Quick Look and observe that the extension is launched and renders the Markdown. On iOS 27, open the same document with the same extension installed. I reproduced this through Files, although the issue concerns Quick Look provider selection rather than Files-specific behavior. Observe that the extension is not launched and the raw Markdown source is shown. Open an equivalent document registered with a custom content type supported by the same extension. Observe that Quick Look launches the extension and displays the rendered preview. The attached screenshots show the same Markdown case rendered by QuickMark on iOS 26 and falling back to plain text on iOS 27. Is there a supported way for a third-party preview extension to handle net.daringfireball.markdown on iOS 27, or is this an unintended provider-selection regression? Tested with iOS 27.0 (24A5408d) on an iPhone 17 Pro Max Simulator using Xcode 27.0 (27A5237l). Feedback filed as FB24481377.

I am an individual developer enrolled in the Apple Developer Program. My account already holds the Family Controls (Distribution) entitlement. I am building a self-control app for adults who want to reduce their own compulsive pornography use. The user applies the restriction to themselves. There is no parent, partner, or accountability feature of any kind, and FamilyControls is used with .individual authorization. To detect adult sites outside Safari, I plan to use a NEPacketTunnelProvider that runs entirely on the device: it inspects the SNI locally, never routes traffic to any server, never changes the user's IP address, and transmits no data anywhere. It offers no VPN service to the user — it is only an on-device filter. Two questions about Guideline 5.4: Does the requirement that an app "may only be offered by developers enrolled as an organization" apply to a content blocking app of this kind, or only to apps offering a VPN service to their users? The second sentence of 5.4 states that "Parental control, content blocking, and security apps, among others, from approved providers may also use the NEVPNManager API", and I would like to know whether that category is subject to the same account requirement. What is an "approved provider" in the sense of Guideline 5.4? I could not find any definition, application form, or entitlement associated with this term. I would rather ask before building than submit and be rejected.

Product: Vozzy — custom keyboard + containing app for user-initiated dictation. Bundle: br.com.buddyapps.FlowType App Group: group.br.com.buddyapps.FlowType Flow: User selects our keyboard in a host app (Notes/Messages). Without Full Access, QWERTY input works locally. With Full Access, user taps Microphone to dictate. Containing app owns mic permission, AVAudioSession, capture, SpeechAnalyzer, Foundation Models. Keyboard never captures audio; it reflects shared state and inserts via textDocumentProxy. Already settled (do not re-ask): No public API to identify the host app. No public API to return to the host app. Feedback: FB22247647. Question (single issue): App Review Guideline 4.4.1 says keyboard extensions must not launch apps other than Settings. Is there any public, App-Review-compliant mechanism for a custom keyboard to request its containing app to activate audio capture for this user-initiated dictation flow? If yes: Which public API / App Intent surface? Is a visible switch to the containing app required? May the audio session continue while the user returns to the host app? May Stop/Cancel commands travel through an App Group while the containing app is backgrounded? Our current policy: Launch uses public NSExtensionContext.open (Debug only). Release has no keyboard path that opens the containing app. Release does allow in-place signaling when the app is already resident (App Group command + Darwin notification; launches nothing). We will not enable Release launch without a written answer naming an allowed public mechanism. App Group payload inventory + retention, Full Access-off QWERTY behavior, onboarding privacy copy. I do not have a focused Xcode sample because this is an API / App Review policy question, not a crash or incorrect return value. The keyboard extension never captures audio. Debug uses public NSExtensionContext.open; Release compiles that path out. I can attach flow diagrams and a device screen recording. Related: FB22247647 (return to host — already answered No; not re-asking).

We completed an App Store app transfer and the Notification Service Extension Filtering Entitlement (com.apple.developer.usernotifications.filtering) did not transfer with the app. App Apple ID: 6760007376 NSE Bundle ID: io.nolink.ios.nse New Team ID: M85WA8W78C Previous Team ID: V2E3A94DC9 The app, bundle IDs, and App Store presence all moved normally, but the entitlement is not available on the new team, so we cannot sign the NSE with the configuration the app previously shipped with. Our app is an encrypted messenger and this breaks incoming call handling for live users. Two questions: Is there an official process for re-associating a previously approved entitlement with the receiving team after a transfer, or does the new team always have to submit a fresh request? Could entitlements tied to a specific App ID move with the app during a transfer, the same way bundle IDs do? We have an open support case, but wanted to raise the general question here too.

TL;DR: looking for FileProvider Extension debugging suggestions... I am attempting to develop NSFileProviderReplicatedExtension. Against a real backing repository (~4TB), I've seen fileproviderd become heavily loaded, non-responsive (i.e. fileproviderctl dump has failed to complete within 60s on 8 tries) and (maybe?) re-enumerate the contents of the repository. The profiler says that it's spending most of its time doing sqlite work against the table for the domain from my extension. I hypothesize that my extension has telling fileproviderd occasionally inconsistent things and it is now making sure that the world is the way that it should be. So: is there a way to get it to log when it has received invalid info? (I did read its (terse 😊) man page. I'm running out of ideas of what more to check with responses from the extension.