Our application currently supports Live Activities. We’re working on adding a new Widget and are weighing some architectural decisions regarding whether we should add it to the same extension target that our Live Activity lives in or create a new extension that would expose it and other widgets we plan to create in the future. In the Add Support for Live Activities documentation, it suggests adding Live Activity code to the existing widget extension to facilitate code reuse. Beyond code sharing, we’re trying to determine if there are downsides to isolating new Widget(s) into their own extension. Specifically, we are concerned about process isolation and how a failure/crash in one might impact the other. Assuming they did live in the same extension, we’re hoping to better understand some of the finer details as presented by the following questions: If a Widget (e.g., via the TimelineProvider) causes the extension process to crash, what is the guaranteed behavior for a currently running Live Activity? Is the relaunch and restoration of a Live Activity after an extension crash guaranteed, or is it best-effort? Is there a distinction in crash isolation between a TimelineProvider failure and a View rendering crash? Are there any known scenarios where a Widget crash could cause a Live Activity to be permanently dropped? Does keeping them in the same extension affect the memory budget, or does each 'instance' receive its own allocation? In short: we're looking to ensure that an issue with a Widget doesn't inadvertently affect a Live Activity (or vice-versa) when they live in the same WidgetsBundle within the same extension and are seeking guidance on whether it makes sense to keep them together or continue down the path of separate extensions in the interest of process safety. Any pointers to other documentation or known behavior would be greatly appreciated!

I inherit from a protocol that implements in its extension those functions, that should not be required by the adopting class and instead I get those errors. Could someone explain why those errors appear and how to fix it.

I’m building a macOS app with a MailKit extension. The containing app needs to show whether the Mail extension is enabled and actually being invoked. Currently the extension writes a “last seen” timestamp to app group defaults when Mail invokes it. The containing app reads that timestamp and shows a waiting/active state. During App Review, this behaviour was challenged: enabling the MailKit extension in Mail Settings does not immediately change the state reported in the containing app. The extension is only invoked when Mail receives or reloads messages, so the main app cannot confirm it is active at the moment the user enables it. The review challenge is that App Review may enable the extension, open Mail, select existing messages, and still see the containing app stuck in a waiting state. From what I can tell, selecting old messages does not reliably cause Mail to invoke the extension. I looked for a direct API like: let isEnabled = try await MEExtensionManager.shared().isEnabled But I do not see any public MailKit API that reports whether the extension is enabled in Mail Settings. MEExtensionManager seems limited to reload-style APIs such as reloadVisibleMessages. Questions: Is there a supported way to check whether a MailKit extension is enabled? Is “first extension invocation” the expected confirmation signal? Can reloadVisibleMessages be relied on during review, or can Mail skip/throttle old messages? Is the right App Review instruction: enable the extension, quit/reopen Mail if needed, then send a new test email? If possible, I want the app to report that the extension has been enabled as soon as the user turns it on in Mail Settings, even if Mail has not invoked the extension yet, but I do not see a public API that exposes that enabled state.

We’re building an iOS app that uses an ILMessageFilterExtension to classify unwanted property-related SMS messages. Our goal is for filtered/junk messages to trigger an automatic scan/classification flow so the main app can show the user useful stats like “X messages blocked since your last check-in,” and ideally categorize them by type such as likely wholesaler, investor, realtor, scam, or unclear. The bottleneck we’re running into is understanding the correct architecture and limits of the Message Filter Extension. We know the extension can inspect sender/message content and return allow/junk, and we understand that network requests are limited to Apple’s deferred query flow. What we’re trying to clarify is whether there is an Apple-compliant way for the extension to persist lightweight scan results or aggregate counts that the containing app can later read, without violating privacy or extension restrictions. We do not need to export a full copy of message bodies into the app; what we want is a compliant way to keep counters/summary metadata such as blocked count, blocked since last app open, and maybe category counts. Questions we’re trying to answer: Is it acceptable for an ILMessageFilterExtension to persist aggregate scan stats for later display in the main app? If so, what is the recommended storage pattern for lightweight counters/metadata? Can extension-side classification results be surfaced to the app only as summary data, not raw message content? If using deferred network classification, what is the best way to reflect those results back into user-facing counts like “messages blocked since last check-in”? Our desired user experience is: unwanted message hits the filter filter classifies it locally or via deferred server lookup message is junked if appropriate aggregate counters are updated when the user opens the app, they see something like: 12 messages blocked since your last check-in 8 likely wholesalers 3 scams 1 unclear We’re mainly looking for guidance on the correct Apple-supported architecture here, especially around what data can be retained/shared between the extension and the containing app.

I'm creating a custom keyboard extension. So as a result, there are buttons which are pinned to the left edge of the keyboard. (Think of q key as an example). The logic of the key presses go something like this: Button detects a touchDown event and shows the magnified text which you normally see in system keyboard when tapping a key. Button detects a touchUpInside/touchDragOutside event and the magnified text disappears, again very similar to the system keyboard. This logic worked for all the buttons which were not pinned to the left edge of the keyboard. But for the buttons that were pinned to the left edge, the touchDown events were being detected after a second. So you can see this is obviously bad because I want to see the magnified text right after I place my finger on the button. WHAT I TRIED AS AN ALTERNATIVE: I removed all the touchDown, touchUpInside and touchDragOutside events from the button and disabled all their user interaction. Then I implemented to touches functions(touchesBegan, touchesEnded, etc.) and observed the touch locations on the background view. Surprisingly, even in this case, the touchesBegan function was called after a second after I placed my finger on the left edge of the screen and as usual, the touchesBegan function called just fine in the rest of the screen. Here's the code for the touches function: override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) { 		guard let touch = event?.allTouches?.first else { return } 		let location = touch.location(in: self.touchView) 				 		print(location) } What exactly is happening here? And what can I do to avoid this problem? NOTE: It works fine in simulator for some reason but has a problem with real devices.

Hello Apple Developer Forums, We are building an iOS app that needs to receive images and PDFs shared from the system share sheet. The sources include Screenshots, Photos, Files, and third-party apps. The desired user experience is similar to apps such as ChatGPT or Claude: when the user taps our app in the share sheet, the main containing app opens and starts importing or uploading the shared image or PDF. We are trying to understand the supported public API for this behavior. Why opening the containing app is important For our use case, it is important that the containing app opens during the share flow. The import/upload operation depends on the user’s authenticated session. If the Share Extension attempts to upload the file directly, the auth token available to the extension could be missing, expired, or invalid. We would prefer not to make the Share Extension responsible for authentication-dependent behavior such as: validating the user session refreshing tokens handling expired credentials presenting login or re-authentication UI owning upload retry logic tied to auth state In our architecture, authentication and token refresh are owned by the containing app. The Share Extension should ideally only receive the shared file, persist it in an app group container, and hand off to the main app. The main app would then validate auth state, refresh tokens if needed, and perform the import/upload. So the desired flow is: Share Extension receives image/PDF → Share Extension stores file in app group container → Containing app opens → Containing app validates auth/session state → Containing app imports/uploads the file The alternative flow is problematic for us: Share Extension receives image/PDF → Share Extension attempts upload directly → Upload may fail if auth token is expired or unavailable → Share Extension would need auth/session responsibilities We are trying to avoid having an authentication dependency inside the Share Extension implementation. What we have tried CFBundleDocumentTypes We added document type support for: public.image public.png public.jpeg public.heic public.heif com.adobe.pdf This works for some document-open flows, such as opening files from Files or Photos in certain cases. However, it does not make the app appear reliably as a share target from Screenshot Share or from some third-party app share sheets. App Intents We tried using App Intents with IntentFile and: static var openAppWhenRun: Bool = true However, this does not seem to create a general-purpose share-sheet receiver for arbitrary image or PDF NSItemProvider payloads. Share Extension We also implemented a Share Extension that: Receives the shared NSItemProvider. Stores the image or PDF in an app group container. Attempts to open the containing app. However: NSExtensionContext.open(_:completionHandler:) does not appear to foreground the containing app from a Share Extension in the way we need. We also tested responder-chain openURL: trampoline approaches, but those do not work reliably and appear to be unsupported as a public API contract. Questions Is there a supported public API for an iOS app to appear as a share target for arbitrary image/PDF NSItemProvider payloads and then directly open the containing app? If apps such as ChatGPT or Claude appear to switch directly into the main app from the share sheet, is that behavior achievable using public APIs available to third-party developers? If directly opening the containing app is not supported, what is the recommended architecture when the import/upload depends on authenticated app state? Is Apple’s recommended design that the Share Extension itself must perform the full import/upload operation, even when that operation depends on auth validation or token refresh? Is there a supported handoff mechanism where the Share Extension can persist the file in an app group container and then ask the system to open the containing app to continue the flow? Are App Intents intended to support this kind of share-sheet attachment import flow, either currently or in a future iOS version? Reproduction Steps We created a focused sample project to reproduce the issue. Build and run the app on a physical iPhone. Leave the app installed. Capture a screenshot. Tap the screenshot thumbnail. Tap the Share button. Choose the app’s Share Extension from the share sheet. Observe that the Share Extension receives the image payload. Attempt to open the containing app from the extension. Expected Result The Share Extension receives the shared image or PDF, stores it in an app group container, and the containing app foregrounds. The containing app then validates the user’s authenticated session, refreshes tokens if needed, and performs the import/upload. Actual Result The Share Extension receives the image payload and logs the provider type identifiers, but the containing app does not reliably foreground. NSExtensionContext.open does not provide the desired transition, and responder-chain URL-opening workarounds do not appear to be supported or reliable. Minimal Question For image/PDF imports from the iOS share sheet, where upload/import requires authenticated app state, what is the supported implementation? Is it expected to be: Share Extension receives the file → Share Extension performs auth-dependent upload/import itself or is there a supported way to implement: Share Extension receives the file → Share Extension stores the file in app group container → Share Extension opens or hands off to containing app → Main app performs auth validation and upload/import Any guidance on the supported architecture would be appreciated. Thank you.

I'm trying to make an FSKit module for NTFS read-write filesystem and at the stage where everything is more or less working fine as long as I mount the volume via mount -F and that volume is a RAM disk. However, since the default NTFS read-only driver is already present in macOS, this introduces an additional challenge. Judging by the DiskArbitration sources, it looks like all FSKit modules are allowed to probe anything only after all kext modules. So, in this situation, any third-party NTFS FSKit module is effectively blocked from using DiskArbitration mechanisms at all because it's always masked during the probing by the system's read-only kext. This leaves mount -F as the only means to mount the NTFS volume via FSKit. However, even that doesn't work for volumes on real (non-RAM) disks due to permission issues. The logs in Console.app hint that the FSKit extension is running; however, it looks like the fskitd itself doesn't have permissions to access real disks if it's initiated from the mount utility? default 16:42:41.939498+0200 fskitd New module list <private> default 16:42:41.939531+0200 fskitd Old modules (null) default 16:42:41.939578+0200 fskitd Added 2 identifiers: <private> default 16:42:41.939651+0200 fskitd [0x7fc58020bf00] activating connection: mach=true listener=true peer=false name=com.apple.filesystems.fskitd debug 16:42:41.939768+0200 fskitd main:RunLoopRun debug 16:42:41.939811+0200 fskitd -[liveFilesMountServiceDelegate listener:shouldAcceptNewConnection:]: start default 16:42:41.939870+0200 fskitd Incomming connection, entitled 0 debug 16:42:41.940021+0200 fskitd -[liveFilesMountServiceDelegate listener:shouldAcceptNewConnection:]: accepting connection default 16:42:41.940048+0200 fskitd [0x7fc580006120] activating connection: mach=false listener=false peer=true name=com.apple.filesystems.fskitd.peer[1816].0x7fc580006120 default 16:42:41.940325+0200 fskitd Hello FSClient! entitlement no default 16:42:41.940977+0200 fskitd About to get current agent for 503 default 16:42:41.941104+0200 fskitd [0x7fc580015480] activating connection: mach=true listener=false peer=false name=com.apple.fskit.fskit_agent info 16:42:41.941227+0200 fskitd About to call to fskit_agent debug 16:42:42.004630+0200 fskitd -[fskitdAgentManager currentExtensionForShortName:auditToken:replyHandler:]_block_invoke: Found extension for fsShortName (<private>) info 16:42:42.005409+0200 fskitd Probe starting on <private> debug 16:42:42.005480+0200 fskitd -[FSResourceManager getResourceState:]:not_found:<private> debug 16:42:42.005528+0200 fskitd -[FSResourceManager addTaskUUID:resource:]:<private>: Adding task (<private>) debug 16:42:42.005583+0200 fskitd applyResource starting with resource <private> kind 1 default 16:42:42.005609+0200 fskitd About to get current agent for 503 info 16:42:42.005629+0200 fskitd About to call to fskit_agent debug 16:42:42.006700+0200 fskitd -[fskitdXPCServer getExtensionModuleFromID:forToken:]_block_invoke: Found extension <private>, attrs <private> default 16:42:42.006829+0200 fskitd About to get current agent for 503 info 16:42:42.006858+0200 fskitd About to call to fskit_agent, bundle ID <private>, instanceUUID <private> default 16:42:42.070923+0200 fskitd About to grab assertion on pid 1820 default 16:42:42.071058+0200 fskitd Initializing connection default 16:42:42.071141+0200 fskitd Removing all cached process handles default 16:42:42.071185+0200 fskitd Sending handshake request attempt #1 to server default 16:42:42.071223+0200 fskitd Creating connection to com.apple.runningboard info 16:42:42.071224+0200 fskitd Acquiring assertion: <RBSAssertionDescriptor| "com.apple.extension.session" ID:(null) target:1820> default 16:42:42.071258+0200 fskitd [0x7fc58001cdc0] activating connection: mach=true listener=false peer=false name=com.apple.runningboard default 16:42:42.075617+0200 fskitd Handshake succeeded default 16:42:42.075660+0200 fskitd Identity resolved as osservice<com.apple.filesystems.fskitd> debug 16:42:42.076337+0200 fskitd Adding assertion 183-1817-1669 to dictionary debug 16:42:42.076385+0200 fskitd +[FSBlockDeviceResource(Project) openWithBSDName:writable:auditToken:replyHandler:]:bsdName:<private> default 16:42:42.076457+0200 fskitd [0x7fc5801092e0] activating connection: mach=true listener=false peer=false name=com.apple.fskit.fskit_helper default 16:42:42.077706+0200 fskitd +[FSBlockDeviceResource(Project) openWithBSDName:writable:auditToken:replyHandler:]_block_invoke: Open device returned error Error Domain=NSPOSIXErrorDomain Code=13 info 16:42:42.077760+0200 fskitd +[FSBlockDeviceResource(Project) openWithBSDName:writable:auditToken:replyHandler:]: failed to open device <private>, Error Domain=NSPOSIXErrorDomain Code=13 default 16:42:42.077805+0200 fskitd [0x7fc5801092e0] invalidated because the current process cancelled the connection by calling xpc_connection_cancel() debug 16:42:42.077830+0200 fskitd +[FSBlockDeviceResource(Project) openWithBSDName:writable:auditToken:replyHandler:]:end info 16:42:42.078459+0200 fskitd openWith returned err Error Domain=NSPOSIXErrorDomain Code=13 dev (null) error 16:42:42.078501+0200 fskitd -[fskitdXPCServer getRealResource:auditToken:reply:]: Unable to convert proxy FSBlockDeviceResource into open resource error 16:42:42.078538+0200 fskitd -[fskitdXPCServer applyResource:targetBundle:instanceID:initiatorAuditToken:authorizingAuditToken:isProbe:usingBlock:]: Can't get the real resource of <private> default 16:42:42.105443+0200 fskitd [0x7fc580006120] invalidated because the client process (pid 1816) either cancelled the connection or exited The mount utility call I use is the same for RAM and real disks with the only difference being the device argument and this permission error is only relevant for real disks case. So, the proper solution (using DiskArbitration) seems to be blocked architecturally in this use case due to FSKit modules being relegated to the fallback role. Is this subject to change in the future? The remaining workaround with using the mount directly doesn't work for unclear reasons. Is that permission error a bug? Or am I missing something?

Here’s a polished Apple Developer Forums post you can use. I removed personal identifiers such as email, Person ID, Team ID, and DTS Case ID because the forums are public. The post is based on your DTS request and Apple’s response directing you to ask in the Developer Forums.  ⸻ Title Supported public API to open containing iOS app from Share Extension for image/PDF share sheet imports Tags iOS Share Extension UIKit App Intents Uniform Type Identifiers Post Body Hello Apple Developer Forums, We are building an iOS app that needs to receive images and PDFs shared from the system share sheet. The sources include Screenshots, Photos, Files, and third-party apps. The desired user experience is similar to apps such as ChatGPT or Claude: when the user taps our app in the share sheet, the main containing app opens and starts importing or uploading the shared image or PDF. We are trying to understand the supported public API for this behavior. What we have tried CFBundleDocumentTypes We added document type support for: public.image public.png public.jpeg public.heic public.heif com.adobe.pdf This works for some document-open flows, such as opening files from Files or Photos in certain cases. However, it does not make the app appear reliably as a share target from Screenshot Share or from some third-party app share sheets. App Intents We tried using App Intents with IntentFile and: static var openAppWhenRun: Bool = true However, this does not seem to create a general-purpose share-sheet receiver for arbitrary image or PDF NSItemProvider payloads. Share Extension We also implemented a Share Extension that: Receives the shared NSItemProvider. Stores the image or PDF in an app group container. Attempts to open the containing app. However: NSExtensionContext.open(_:completionHandler:) does not appear to foreground the containing app from a Share Extension in the way we need. We also tested responder-chain openURL: trampoline approaches, but those do not work reliably and appear to be unsupported as a public API contract. Questions Is there a supported public API for an iOS app to appear as a share target for arbitrary image/PDF NSItemProvider payloads and then directly open the containing app? If apps such as ChatGPT or Claude appear to switch directly into the main app from the share sheet, is that behavior achievable using public APIs available to third-party developers? If directly opening the containing app is not supported, is the recommended design to perform all upload/import work inside the Share Extension itself? Are App Intents intended to support this kind of share-sheet attachment import flow, either currently or in a future iOS version? Reproduction Steps We created a focused sample project to reproduce the issue. Build and run the app on a physical iPhone. Leave the app installed. Capture a screenshot. Tap the screenshot thumbnail. Tap the Share button. Choose the app’s Share Extension from the share sheet. Observe that the Share Extension receives the image payload. Attempt to open the containing app from the extension. Expected Result The containing app should foreground and receive a URL or other handoff signal indicating that a shared file is available for import. Actual Result The Share Extension receives the image payload and logs the provider type identifiers, but the containing app does not reliably foreground. NSExtensionContext.open does not provide the desired transition, and responder-chain URL-opening workarounds do not appear to be supported or reliable. Minimal Question For image/PDF imports from the iOS share sheet, should the supported implementation be: Share Extension receives the file → Share Extension performs the upload/import itself rather than: Share Extension receives the file → Share Extension opens containing app → Main app performs upload/import Any guidance on the supported architecture would be appreciated. Thank you.

If the extension uses manifest v3 and a background script in the form of a service worker, then in Safari it is not possible to open the background script debugging window. If I expand the Developer menu in Safari, there is nothing under Web Extension Background Data (or disappear after click), which is an error. In other browsers (Edge, Chrome, Opera, Firefox) this works correctly. If I switch the background script back to non-persistent script mode, everything works fine and from the Developer menu and the Web Extension Background Data submenu I am able to open the background script debugging window for the extension. Am I doing something wrong?

Hi all, I'm building an iOS app extension using ExtensionKit that works exclusively with its containing host app, presenting UI via EXHostViewController. I'd like the extension to have read-only access to the host's task for process introspection purposes. I'm aware this would almost certainly require a special entitlement. I know get-task-allow and the debugger entitlement exist, but those aren't shippable to the App Store. I'm looking for something that could realistically be distributed to end users. My questions: Does an entitlement exist (or is one planned) that would grant an extension limited, read-only access to its host's task—given the extension is already tightly coupled to the host? If not, is this something Apple would consider adding? The use case is an extension that needs to inspect host process state without the ability to modify it. Is there a path to request such an entitlement through the provisioning profile process, or is this fundamentally off the table for App Store distribution? It seems like a reasonable trust boundary given the extension already lives inside the host's app bundle, but I understand the security implications. Any insight appreciated. Thanks!

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?

Hello Apple team, We would like to access the user's available purchases from the keyboard extension. Making purchases directly from the keyboard is a great benefit, but we assume it is intentionally disabled to prevent abuse or fraudulent purchase attempts. What we care about the most is determining if the user has an item that contains a discount or a free trial to personalize messaging when we suggest the user go to the app and make a purchase. We hope you'd consider revising your policy around StoreKit usage.

Hi everyone, I'm building an iOS app that uses a DeviceActivityMonitor app extension as part of the Screen Time / Family Controls API. Every time I try to upload my IPA to App Store Connect, the validation fails with this error: "Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.deviceactivity.monitor, in the Info.plist of 'Alexandria.app/PlugIns/AlexandriaActivityMonitor.appex' is invalid." Error Domain=IrisAPI Code=-19241, iris-code=STATE_ERROR.VALIDATION_ERROR What I have verified (everything looks correct): NSExtensionPointIdentifier = com.apple.deviceactivity.monitor NSExtensionPrincipalClass = AlexandriaActivityMonitor.AlexandriaActivityMonitorExtension (correctly resolved in the compiled binary, verified with plutil -p) The Swift class correctly subclasses DeviceActivityMonitor CFBundleShortVersionString matches the main app Both the main app and extension provisioning profiles explicitly contain com.apple.developer.family-controls = true (verified by inspecting embedded.mobileprovision inside the IPA) The binary code signature itself contains com.apple.developer.family-controls = true (verified with codesign -d --entitlements :-) Family Controls entitlement was requested and approved in the Developer Portal for both App IDs Tested with both Xcode 26.2 (iOS 26 SDK) and Xcode 16.4 (iOS 18 SDK) — same error in both cases The IPA is structurally correct. The error comes purely from Apple's server-side IrisAPI validator and does not correspond to anything I can identify or fix in the code or configuration. Has anyone successfully submitted an app with a DeviceActivityMonitor extension to App Store Connect recently? Is there a backend approval requirement for com.apple.deviceactivity.monitor beyond the standard Family Controls entitlement approval? Could this be a known validator bug for this specific extension type? Any help appreciated.

Hello, I’ve noticed an issue with custom keyboard extensions in iOS 26 that seems specific to native apps. When a custom keyboard is opened in apps like Messages, Notes, or Safari, there’s an extra strip of native grey space around the left, right, and top edges of the keyboard. This extra margin cannot be rendered over by the keyboard’s own views. Interestingly, this behaviour does not occur in third-party apps like Instagram. It also wasn’t present in earlier iOS versions. The result is that keyboards with custom or non-grey backgrounds look visually inconsistent (they appear framed by unwanted grey). Has anyone else run into this? Is this a known change in iOS 26, or could it be a bug? Any guidance or official clarification would be appreciated. Thanks!

Are there some requirements to use Notification Content Extensions other than including the target to my iOS app? I have done it, configured it to match a certain category of notifications, but my custom interface doesn’t show up. is there anything I need to configure on my main app? Is that anything that should be changed there, such as disabking its botifications handling? is there any requirement concerning the payload? I tried to disable time sensitive and content-available notifications, but it didn’t help.

When developing a custom keyboard on iOS, even after enabling Full Access (RequestsOpenAccess = true), it is still not possible to record audio — the recording simply does not start. This is despite the fact that: the user is explicitly warned the user provides informed consent by enabling Full Access According to Apple’s documentation: https://developer.apple.com/documentation/uikit/configuring-open-access-for-a-custom-keyboard “However, with RequestsOpenAccess set to true, the keyboard has all the capabilities in the preceding list.” At the same time, the preceding list includes: “No access to microphone and speaker” This creates ambiguity. The wording suggests that enabling Full Access should lift prior restrictions, yet in practice, microphone access remains unavailable to third-party keyboards. Why this is concerning With Full Access enabled, a keyboard already has: network access the ability to transmit user input From a privacy standpoint, this is already highly sensitive. Preventing microphone access while allowing these capabilities appears inconsistent. Meanwhile, Apple’s own system keyboard supports voice dictation, which creates a functional gap between first-party and third-party keyboards. Competition perspective This raises a broader question about equal access to platform capabilities. Restricting third-party keyboards from using the microphone — while first-party solutions can — may be seen as: unequal treatment of developers a limitation of competition in input methods Such differences are increasingly scrutinized under EU regulations like the Digital Markets Act and Article 102 TFEU, which emphasize fair access to platform features and prohibit self-preferencing by dominant platforms. Request for clarification Is microphone access intentionally restricted for all third-party keyboards, even with Full Access enabled? If so, what is the technical or policy justification? Are there plans to provide a secure and user-consented way to enable audio input for custom keyboards? Clarification on this would help developers better understand platform limitations and design decisions.

Hello, I have a critical issue regarding the "Family Controls (Distribution)" entitlement. My app "FocusPact" was approved for the entitlement, but there is a technical mismatch in the Bundle IDs that prevents distribution via TestFlight. [Current Situation] Parent App ID: com.hayashikento.FocusPact (Approved / Capitalized) Approved Extension ID: com.hayashikento.focuspact.ShieldConfigurationExtension (Approved / Lowercase) [The Issue] Due to the case-sensitivity difference (FocusPact vs focuspact), Xcode throws a "Bundle identifier prefix mismatch" error. Since the parent app identifier is already established as capitalized, I cannot change it to lowercase without breaking the existing configuration. [Request] I have submitted a new entitlement request with the corrected capitalized Bundle ID: Corrected Extension ID: com.hayashikento.FocusPact.ShieldConfigurationExtension Could a DTS engineer please help me synchronize the approved status to this capitalized ID? This is purely a technical correction of an already authorized functionality. Team ID: UHG4J7F7NH App Apple ID: 67591326449 Thank you for your assistance. I am a student developer eager to start MVP testing as soon as this is resolved.

Hello, I have implemented a URL Filter using the sample provided here: Filtering Traffic by URL. I am also using an App Group to dynamically manage the Bloom filter and block list data. However, when I update my block list URLs and create a new Bloom filter plist in the App Group, the extension does not seem to use the updated Bloom filter even after the prefetch interval expires. Also for testing purpose can I keep this interval to 10 mins or below ?

I am implementing an Unwanted Communication Reporting Extension (IdentityLookupUI) to allow users to report spam messages to our backend. The extension works perfectly in terms of data collection and network reporting (using ILClassificationExtensionNetworkReportDestination). However, I’ve encountered an issue with the message lifecycle: whenever the user taps "Done" and I return a response, the system automatically moves the reported message to the Recently Deleted folder. I want to report the data but keep the message in its current folder (especially when the user classifies it as "Safe"). I have tried varying the ILClassificationAction, but it seems the system ignores the action in favor of "cleaning up" the thread. Example of my current implementation: override func classificationResponse(for request: ILClassificationRequest) -> ILClassificationResponse { // Even when returning .none or .reportNotJunk let action: ILClassificationAction = (self.type == "spam") ? .reportJunk : .none let response = ILClassificationResponse(action: action) response.userInfo = ["type": self.taggedType, "sender": self.sender] return response } My Questions: Is there a specific ILClassificationAction or userInfo key that tells iOS not to move the message? Is this movement a mandatory "post-report cleanup" behavior of the IdentityLookup framework that cannot be overridden? Does anyone know a workaround to report the communication while maintaining its original location in the Messages app?

Hello, I have a critical issue regarding the "Family Controls (Distribution)" entitlement. My app "FocusPact" was approved for the entitlement, but there is a technical mismatch in the Bundle IDs that prevents distribution via TestFlight. [Current Situation] Parent App ID: com.hayashikento.FocusPact (Approved / Capitalized) Approved Extension ID: com.hayashikento.focuspact.ShieldConfigurationExtension (Approved / Lowercase) [The Issue] Due to the case-sensitivity difference (FocusPact vs focuspact), Xcode throws a "Bundle identifier prefix mismatch" error. Since the parent app identifier is already established as capitalized, I cannot change it to lowercase without breaking the existing configuration. [Request] I have submitted a new entitlement request with the corrected capitalized Bundle ID: Corrected Extension ID: com.hayashikento.FocusPact.ShieldConfigurationExtension Could a DTS engineer please help me synchronize the approved status to this capitalized ID? This is purely a technical correction of an already authorized functionality. Team ID: UHG4J7F7NH App Apple ID: 67591326449 Thank you for your assistance. I am a student developer eager to start MVP testing as soon as this is resolved.