On iPadOS 26, PDFKit runs VNRecognizeDocumentsRequest over the pages of a PDFDocument when those pages are rendered. The analysis pipelines are never released. Measured on an iPad Pro 12.9-inch 4th gen (iPad8,11), iPadOS 26.6, with a 61-page image-only scanned score: each newly-created-and-rendered PDFDocument costs about 2.7 OS threads and 20 MB, permanently. Repeatedly loading the same file from disk reached 153 threads and 1519 MB in under seven minutes, then died of an allocation failure. Nothing releases it: not replacing PDFView.document, not deallocating the PDFView entirely, not releasing the PDFDocument, and not time. With every code path in the app stopped, the thread count does not fall — it continues to rise. The stack -[PDFView visiblePagesChanged:] → +[PDFPageAnalyzerV2 analyzePage:withBox:requestTypes:] → -[VNImageRequestHandler performRequests:gatheredForensics:error:] → -[VNRecognizeDocumentsRequest internalPerformRevision:inContext:error:] → -[VNDetector processUsingQualityOfServiceClass:options:regionOfInterest:…] → -[VNControlledCapacityTasksQueue dispatchSyncByPreservingQueueCapacity:] Thread census at 1519 MB — 153 threads total, after 66 document loads: 66 PDFKit.PDFDocument.formFillingQueue 64 com.apple.VNRecognizeDocumentsRequestRevision1 10 ANEServicesThread 66 orphaned pipelines for 66 loads, all blocked on Vision's capacity limiter. The console also emits Invalid permutation index when reordering subregions. Index N must be less than number of subregions 1 continuously, with N increasing — and these keep arriving after all application activity has stopped. Isolation Each row is a separate run on the same device and OS, one variable changed. Counts are OS threads; baseline is 13. Configuration Result Page-stepping only on a stable document (~1000 visiblePagesChanged: events) No growth; footprint declines Recreating PDFThumbnailView on every load No growth Creating a PDFDocument and never rendering it No growth Creating + rendering, assigned to a PDFView +2.0 to +2.7 threads / +20 MB per load Creating + rendering, never assigned to any PDFView Same growth Creating + rendering, entire PDFView destroyed and rebuilt per load Same growth Two points worth drawing out: The leak occurs with no PDFView involved at all — plain PDFPage.thumbnail(of:for:) or PDFPage.draw(with:to:) on a freshly created document is sufficient. Destroying the PDFView releases nothing. Whatever retains the analyses outlives every object the application can reach. Also, for anyone who arrives here from the other PDFPageAnalyzerV2 threads: the usePageViewController(true, withViewOptions: nil) workaround does not help this. It reduces visiblePagesChanged: frequency, and page changes on a stable document leak nothing. The variable is newly rendered documents, not new pages. The switch already exists PDFView implements -setDocumentAnalysisEnabled: and -isDocumentAnalysisEnabled, plus -handleAnalysisCompletionOfPage:resultTypes:. None of these appear in any public header. With document analysis disabled, the leak disappears completely — 28 consecutive document loads with zero thread growth, and after stopping, the process released down to 6 threads and 64 MB, below its own idle baseline. It also suppresses the leak for documents never assigned to that PDFView, so whatever the flag gates is not scoped to a single view. For completeness, the per-page -setCandidateForOCR: / -setDidPerformOCR: accessors do not help: the writes land and read back correctly, and the analysis runs anyway. They appear to be state rather than policy. Request Either: Fix the leak — cancel and release analyses when the document or the view goes away; or Make documentAnalysisEnabled public on PDFView (or add an equivalent on PDFDocument). Ideally, please do both. The second costs Apple nothing: the property exists, it works, and it is exactly the control that is needed. Applications that render sheet music, engineering drawings, or any other content where document understanding provides no value are currently paying for it with unbounded memory growth and no supported way to decline. Filed as FB24211659. Happy to share the isolation harness with anyone from the PDFKit team. Related: 825803 (crash in PDFPageAnalyzerV2, FB22409977), 827781 (deadlock in the same class), 838272 / 837282 (PDFTileSurface over-release), 107007 (CGContextDrawPDFPage thread safety, open since 2018).

I recently had my app Spark Matched: https://apps.apple.com/us/app/spark-matched/id6786071027 accepted to the Apple Store but when I try to launch promptly closes and the icon I added isn’t displaying

We're evaluating Apple-hosted Background Assets for an app distributed on App Store and would like to understand the security model behind it before adopting it. So far the public documentation only mentions the HTTPS requirement for asset transport. We'd appreciate any additional documentation or guidance covering: How asset downloads are authenticated (e.g., is access tied to the app's entitlement/provisioning, or is there a separate token/credential mechanism?) How access to specific assets is controlled/scoped Where Apple-hosted assets are physically/logically hosted (e.g., is this CDN-backed, and is there any control or visibility over hosting region?) Any other security considerations typically associated with cloud-hosted content (encryption in transit and at rest, integrity verification, etc.) Is there a more detailed security/architecture document beyond the public developer documentation, or can someone from the team point us in the right direction?

Question 1 (Return journey from containing app back to original host): Is there an alternative, supported method for a custom keyboard extension to launch its containing app such that when that containing app is later suspended/resigned, the system returns the user to the original host app (e.g., Notes) instead of the Home screen? Does iOS 26 provide any handoff/return APIs for the keyboard voice‑input scenario? Question 2 (Full‑access‑off persistence and settings navigation): (a) Is the shared app group container expected to be effectively read‑only (with EPERM) when Full Access is off? If so, is there any supported way to persist keyboard settings (that require writing to shared files) without Full Access? (b) What is the supported method for a keyboard extension to direct the user to Settings to enable Full Access on iOS 26, given that openURL via responder chain and extensionContext.open both fail? We are seeking a reliable, non‑private API approach.

I'm building a custom keyboard extension that offers voice dictation. Because keyboard extensions are constrained (memory cap ~30–48 MB, restricted audio session access), I delegate recording to my container app: User in a host app (e.g., Safari) taps the mic in my keyboard extension. The keyboard calls extensionContext.open(URL("myapp://dictation")) to launch the container app. The container app records audio via AVAudioEngine + SFSpeechRecognizer, writes the final transcript to the App Group, and signals completion via a Darwin notification. 4. The user is expected to be returned to the original host app (Safari) automatically so they can keep typing. The problem (step 4): On iOS 26.4 I can no longer identify which app was the host. Every previously-known path returns nil for the keyboard extension's host: parent.value(forKey: "_hostBundleID") → returns the literal string parent.value(forKey: "_hostApplicationBundleIdentifier") → returns NSNull xpc_connection_copy_bundle_id on the underlying XPC connection (via PKService.defaultService.personalities[…]) → returns NULL NSXPCConnection.processBundleIdentifier on extensionContext._extensionHostProxy._connection → returns nil proc_pidpath(hostPID, …) → EPERM from the keyboard sandbox LSApplicationWorkspace.frontmostApplication → selector unavailable from the extension RBSProcessHandle.handleForIdentifier:error: → returns an RBSServiceErrorDomain error Without the host's bundle ID, the container app has no way to call LSApplicationWorkspace.openApplicationWithBundleID: (the technique that worked on iOS 25 and earlier). UIApplication.suspend() correctly sends the container to background, but iOS treats us as a "fresh launch" — it returns the user to the Home Screen instead of Safari, because the container app was launched by an extension, not directly by Safari. KeyboardKit's maintainer reached the same conclusion (issue #1014) and shipped 10.4 without the feature. My questions: Is there a public, App-Store-safe API in iOS 26+ for a custom keyboard extension to identify its host application, or for the container app (launched via the extension's openURL) to identify which app initially hosted the extension that opened it? UIOpenURLContext.options.sourceApplication reports the extension's own container, not the actual host. 2. Is there a public mechanism for "return to source app" when the container app was launched by an extension's openURL? Equivalent to the ← Source affordance iOS shows for normal inter-app openURL, but triggered programmatically by the launched app. 3. Some popular keyboards (e.g., 微信输入法 / WeChat Keyboard) still appear to round-trip through their container app on iOS 26.4 and return the user to the original host — including the iOS ← WeChat back affordance in the host's status bar afterward. What's the recommended approach to achieve this? If it requires a specific scene-activation flow, NSUserActivity pattern, or extension-context configuration, please point at the relevant docs. 4. If there is no public path today, is FB22247647 (or a related radar) the right place to track this? Should developers in this position migrate to in-extension audio capture (which has its own significant constraints in keyboard extensions)? I'd much rather not rely on private APIs. Concrete guidance — or even an acknowledgment of which direction Apple intends — would help thousands of custom-keyboard developers who currently have a degraded voice-input experience on iOS 26.4+. Tested on iPhone 12 Pro Max running iOS 26.4.2 (build 23E261), Xcode 26.x, Swift 5. Thanks!

How does iOS handle Associated Domains and AASA files when switching between environments? I have an iOS application that supports multiple environments (test and production). Each environment has its own domain and its own AASA file. We have an SDK that requires a domain during initialization. Based on the selected environment, we initialize the SDK with either the test domain or the production domain. We have configured the Associated Domains capability in Xcode with the required domains. However, i'm unclear about how iOS manages the AASA association in this scenario. For example: test.example.com Has its own AASA file. Used when the SDK is initialized with the test domain. example.com Has its own AASA file. Used when the SDK is initialized with the production domain. The SDK receives the domain during initialization, and we dynamically select the domain based on the environment configuration. The question is: If multiple domains are configured in Associated Domains, does iOS fetch and cache the AASA file for all configured domains when the app is installed, or only for the domain currently being used by the application? If the application switches the SDK configuration from the test domain to the production domain (or vice versa) after installation, how does iOS know that it needs to fetch the AASA file for the new domain? Is there any supported way to force iOS to re-fetch the AASA file for a newly selected associated domain? Trying to understand the correct approach for supporting multiple environments when the SDK domain is selected dynamically at runtime. If both test and production domains are configured in Associated Domains, how does iOS determine which AASA file should be used when the SDK is initialized with a specific domain (for example, test)? Does iOS fetch and validate both AASA files upfront and then check only the matching domain at runtime, or does it dynamically fetch/check only the domain provided to the SDK?

We're seeing a behavior change with ILMessageFilterExtension on iOS 26 and would like to confirm whether this is expected or a regression. Environment iOS: 26.x Framework: IdentityLookup Extension type: ILMessageFilterExtension Behavior For a new sender: An incoming SMS arrives. handle(_:context:completion:) is invoked. The extension returns a classification. The conversation is moved to the Spam folder. Subsequent SMS messages in the same conversation are delivered to the Spam folder, but handle(_:context:completion:) is no longer invoked for any new messages. Expected behavior We expected the message filter extension to be invoked for every incoming SMS, regardless of the current conversation folder, allowing the extension to evaluate each message independently. Actual behavior Once the conversation is in the Spam folder, all subsequent messages bypass the extension completely. The extension receives no callback, making it impossible to: Re-evaluate new messages using updated filtering logic. Change the classification if sender reputation changes. Apply cloud-based or dynamic filtering policies on subsequent messages. Questions Is this behavior expected in iOS 26? Has the message filtering pipeline changed so that conversations already classified as Spam no longer invoke ILMessageFilterExtension? Is there any documented API or recommended approach to have the extension evaluate every incoming message for an existing Spam conversation? If this is not expected, is this a known issue? If anyone from Apple or other developers can confirm whether this is by design, it would be greatly appreciated.

WeatherKit consistently fails with the following error: WDSJWTAuthenticatorServiceListener.Errors Code=2 This happens on a physical device regardless of the troubleshooting steps I try. After the error occurs, the app uses a third-party fallback provider successfully. The issue appears similar to failures reported by other developers on iOS 26, even though the WeatherKit entitlement and signing configuration seem valid. I have verified the following: • The signed application binary contains the WeatherKit entitlement. • The embedded provisioning profile contains the WeatherKit entitlement. • The application identifier and team identifier match the provisioning profile. • The WeatherKit capability was disabled, saved, enabled again, and saved. • Xcode automatic signing generated a new provisioning profile after resetting the capability. • The project was cleaned and a fresh build was installed on the physical device. • Both the application and the device were restarted. • Location permission is granted and the app receives valid coordinates. • Network connectivity works correctly. • A non-Apple fallback weather provider successfully returns a forecast for the same coordinates. Despite this, every WeatherKit request still fails with WDSJWTAuthenticatorServiceListener.Errors Code=2. Has anyone identified the cause of this error on iOS 17 or 26 or found an additional signing, entitlement, App ID, or provisioning step required to resolve it? Environment: • iOS version: iOS: 26.6 (23G71) • Xcode version: 26.5 • Device: iPhone 14 Pro • WeatherKit API used: WeatherService.shared • Distribution method:TestFlight

See crash details here:- https://pastebin.com/i9u5PE4X There's a comprehensive thread here, folks! https://discussions.apple.com/thread/255651156?sortBy=oldest_first Thanks for any thoughts.

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

We’ve been implementing LiveCallerId using OHTTP and have hit a wall with the production environment. The setup works perfectly in TestFlight, but the release version of the app is consistently being rejected by the Apple OHTTP Relay when trying to tunnel traffic to our gateway. Timeline & Status: Applied via the form in September 2025. Received confirmation in November 2025 that our /.well-known/ohttp-keys endpoint was correctly configured. Since then, we've struggled to get a dialogue with Apple to confirm the final production whitelisting. Technical Observations: Our ohttp-keys endpoint is being polled frequently (every few minutes). Based on the traffic, this is clearly the Apple Relay infrastructure fetching/refreshing the keys, not the devices themselves. This suggests the Relay "sees" our configuration, yet it still refuses to tunnel traffic to our gateway in the production environment. Since everything is functional in TestFlight, our implementation seems correct. It feels like there is a configuration mismatch or a missing "production flip" on the Relay side for our Bundle ID. If anyone from the Apple engineering team could verify the status for this Bundle ID, it would be a huge help. We've been stuck in this "TestFlight-only" state for quite a while now.

Hi, As a company, we have several apps in the AppStore that contain AppClips. With the latest iOS18 it works without any problems. With all iOS26 betas so far, however, there is always the problem “ASDErrorDomain- Error 507” and the AppClip cannot be opened. You can easily test this by scanning the following QR code with the system camera: You only ever get this error instead of the option to open the AppClip. As the iOS26 beta phase is already at an advanced stage, we are naturally concerned as to whether the problem will be solved.

I am investigating premature DeviceActivityMonitor.eventDidReachThreshold callbacks on physical devices running iOS 26.x. I have also observed similar overcounting behavior on iOS 18.x. In one repeatable test, an all-activity event configured with a 10-minute threshold fired after approximately 5 minutes of actual unlocked usage. The event was created with: A single completion threshold. includesPastActivity: false. A nonrepeating DeviceActivitySchedule. A unique activity and event identity for each monitoring generation. However, eventDidReachThreshold could still arrive significantly earlier than expected. Defensive mitigation I have been testing a defensive mechanism that treats eventDidReachThreshold only as a wake-up signal, rather than authoritative proof that the configured usage duration has elapsed. When the callback arrives, the monitor extension independently validates the duration against locally persisted timing state. The flow is: Each logical work cycle has a unique cycle identifier and generation number. The app stores a local timing anchor when monitoring begins or resumes. When the threshold callback arrives, the extension verifies: The cycle identifier. The generation number. The activity name. The current application state. The extension calculates a locally trusted elapsed duration. If the local duration has not reached the configured duration: It does not send a notification. It does not apply any user-visible action. It persists only the locally trusted progress. It increments the generation number. It stops the previous monitor. It registers a new event for only the locally remaining duration. Completion is accepted only when the locally calculated duration is due. Delayed callbacks from previous generations are ignored. Simplified pseudocode: override func eventDidReachThreshold( _ event: DeviceActivityEvent.Name, activity: DeviceActivityName ) { let state = loadPersistedState() guard eventMatchesCurrentGeneration( event: event, activity: activity, state: state ) else { // Ignore stale or duplicated callbacks. return } let now = Date() let trustedElapsed = calculateLocallyAccountedElapsed( state: state, now: now ) let tolerance: TimeInterval = 3 if trustedElapsed + tolerance < state.configuredDuration { let remaining = state.configuredDuration - trustedElapsed var nextState = state nextState.confirmedElapsed = trustedElapsed nextState.generation += 1 // Persist the new generation before replacing the monitor. persistAtomically(nextState) center.stopMonitoring([activity]) let nextActivity = makeActivityName( cycleID: nextState.cycleID, generation: nextState.generation ) let completionEvent = DeviceActivityEvent( threshold: normalizedDateComponents(remaining), includesPastActivity: false ) do { try center.startMonitoring( nextActivity, during: makeNonRepeatingSchedule(), events: [ makeCompletionEventName(nextState): completionEvent ] ) } catch { // Persist a recoverable unavailable state. recordMonitoringFailure(error) } return } transitionToCompletedState() scheduleUserNotification() } Durations are normalized before creating the event: func normalizedDateComponents( _ duration: TimeInterval ) -> DateComponents { let seconds = max(1, Int(duration)) return DateComponents( minute: seconds / 60, second: seconds % 60 ) } This avoids using values such as second: 300. Example For a configured duration of 10 minutes: DeviceActivity incorrectly delivers the completion callback after approximately 5 minutes. Local accounting reports only approximately 5 minutes. No notification or other user-visible action is performed. The previous monitor is replaced with a new generation configured for the remaining approximately 5 minutes. Completion is accepted only after the locally trusted timing state is due. This mechanism has so far prevented premature DeviceActivity callbacks from producing premature notifications during my physical-device testing on iOS 26.x. Additional precautions The implementation also uses the following precautions: Only one completion event is registered instead of multiple minute checkpoints. includesPastActivity is explicitly set to false. Every replacement monitor has a new generation identity. Generation state is persisted before the old monitor is replaced. Callbacks from an old cycle, generation, or activity name are ignored. The extension performs only small, bounded state updates. User-visible actions occur only after local validation succeeds. Limitations This is a defensive workaround, not a fix for the underlying DeviceActivity or Screen Time accounting issue. Known limitations include: It cannot prevent iOS from delivering an incorrect callback. If the system never delivers another callback, completion may be delayed or missed. If every new event immediately fires, repeated re-registration may occur. startMonitoring may fail if the system considers the activities too numerous or too tightly scheduled. Local unlocked-time accounting depends on reliable lock and unlock observations. Wall-clock calculations must consider manual system-time changes. The approach cannot correct Screen Time’s internal activity data. For modes that intentionally count locked time, absolute local-notification scheduling may be more reliable and may avoid DeviceActivity thresholds entirely. All processing in this mitigation occurs on-device. It does not require uploading activity tokens, Screen Time data, user identifiers, or diagnostic logs. The implementation uses only public APIs. Questions for Apple Is treating eventDidReachThreshold as a wake-up signal and validating it against locally persisted timing state an acceptable design? Is stopping the current monitor and registering a new generation for only the locally remaining duration from the monitor extension considered a supported recovery pattern? Are there documented or recommended limits, rate controls, or backoff requirements for this type of defensive re-registration? Is there a more reliable supported API for usage-based completion when eventDidReachThreshold fires prematurely on iOS 26? I would appreciate confirmation from Apple engineers or feedback from other developers who have tested a similar approach.

We submitted Live Caller ID Lookup requests for two apps and both remain “In Review.” Our PIR server, Privacy Pass issuer and OHTTP gateway are deployed, DNS TXT records are published for both bundle identifiers, and the test number returns correctly. Is there a way to verify from our side that Apple’s automated endpoint validation passes? Any common misconfiguration that causes a request to sit without feedback?

Configuring a VPN with includeAllNetworks causes CarPlay / Netflix Cast. Even enabling excludeLocalNetworks does not resolve this issue. Is this a known issue and can we work around this?

Hi there, Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row. Feedback: FB21267341 There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC. DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://developer.apple.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.

Overview I would like to observe calendar changes using NotificationCenter.messages(of: for:) I want receive Sendable messages, not traditional Notification which is not Sendable Problem I can't seem to get the following code to compile import EventKit NotificationCenter.default.messages( of: EKEventStore.EventStoreChanged.Subject.self, for: .changed ) Reference https://developer.apple.com/documentation/foundation/notificationcenter/messageidentifier/changed-50yz5 Questions How can I use by using NotificationCenter.messages(of: for:) for Calendar changes?

Hello Apple Developer Forum, We have implemented the Declared Age Range API exactly as described in Apple's documentation. Our implementation checks isEligibleForAgeFeatures before calling requestAgeRange, as recommended. We have been testing with different users located in Texas (US) and Brazil. However, for all users, isEligibleForAgeFeatures consistently returns false, so the Declared Age Range prompt is never displayed. We would appreciate some clarification on the following: Under what conditions does isEligibleForAgeFeatures return true? When is the Declared Age Range prompt expected to be shown? Besides the user's region, are there any additional eligibility requirements, such as whether the Apple ID has a verified payment method (credit/debit card), verified identity or address, account age or a phased rollout? Since all of our test users are in supported regions (Texas and Brazil), we expected at least some users to be eligible. However, all four test accounts consistently return false. Could you please clarify how Apple determines eligibility for the Declared Age Range feature and when developers should expect the prompt to appear? Thank you for your guidance.

Hi Team, Our universal links were working fine but since last week we are facing issues and when tapping the links outside app it takes to browser and not the app. Apple CDN is returning 404 for our domain and not the contents of AASA file. https://app-site-association.cdn-apple.com/a/v1/app.ooredoo.om sudo swcutil dl -d app.ooredoo.om returns The operation couldn’t be completed. (SWCErrorDomain error 7.) Can we get the exact issue apple is facing to cache the AASA file in CDN. Any server config which we need to do for AASA bot to access the file. Thanks in advance.

We have a published, approved App Clip that works correctly via QR code and the Safari Smart App Banner, but URL-based invocation does not trigger the App Clip card in any context. Most notably, Apple's own default App Clip URL does not work either: https://appclip.apple.com/id?p=hazel-torus.Clip **Tapping this link in Messages or Notes does nothing. ** Long-pressing it shows a generic website link preview rather than the App Clip card, even though appclip.apple.com is Apple's domain and requires no configuration on our end. Setup details: App Clip bundle ID: hazel-torus.Clip Team ID: 2UNR2APH47 App Clip experience URL: https://passportreader.app/open AASA includes a correctly formatted appclips key with 2UNR2APH47.hazel-torus.Clip (confirmed via https://app-site-association.cdn-apple.com/a/v1/passportreader.app that AASA is correctly cached) Associated Domains entitlements (appclips:passportreader.app) are present on the App Clip target App and App Clip experience are both Approved / Ready for Sale Tested on two physical devices, neither with the full app installed Since QR and Safari banner invocation work, the App Clip itself and its entitlements appear correctly configured. The fact that even Apple's own appclip.apple.com URL fails, and is treated as an arbitrary website link, suggests this may be a backend indexing issue specific to this App Clip rather than a client-side configuration problem. Has anyone else encountered this, or know what could cause appclip.apple.com to not be recognized as an App Clip URL?