Both view and modifier versions of the FamilyActivityPicker crash randomly when selecting some items (usually the other option) throwing these in the console: [com.apple.FamilyControls.ActivityPickerExtension(1150.1)] Connection to plugin invalidated while in use AX Lookup problem - errorCode:1100 error:Permission denied portName:'com.apple.iphone.axserver' PID:22091 ( 0 AXRuntime 0x00000001c603b0fc _AXGetPortFromCache + 800 1 AXRuntime 0x00000001c603cce0 AXUIElementPerformFencedActionWithValue + 700 2 UIKit 0x0000000230de3ec8 DDE6E0C5-2AC3-3C73-8CFE-BC88DE35BB5F + 1453768 3 libdispatch.dylib 0x0000000103ef0b98 _dispatch_call_block_and_release + 32 4 libdispatch.dylib 0x0000000103ef27bc _dispatch_client_callout + 20 5 libdispatch.dylib 0x0000000103efa66c _dispatch_lane_serial_drain + 832 6 libdispatch.dylib 0x0000000103efb408 _dispatch_lane_invoke + 408 7 libdispatch.dylib 0x0000000103f08404 _dispatch_root_queue_drain_deferred_wlh + 328 8 libdispatch.dylib 0x0000000103f07a38 _dispatch_workloop_worker_thread + 444 9 libsystem_pthread.dylib 0x00000001f0824f20 _pthread_wqthread + 288 10 libsystem_pthread.dylib 0x00000001f0824fc0 start_wqthread + 8 ) This also happens in production apps like the Opal. The questions are: At least how to detect it to be able to manually reload the sheet (like what Opal does and shows an alert when this happens) How to prevent it in the first place? I really appreciate any help you can provide.

Subject: iOS Fails to Fetch AASA File for Internationalized Domain Names (IDN) in Unicode or Punycode Format Dear Apple Developer Relations Team And Community Members, We are reporting a critical bug in the iOS Associated Domains feature that prevents Universal Links from working for apps using Internationalized Domain Names (IDN). Problem Description: The iOS operating system does not attempt to download the apple-app-site-association (AASA) file for domains containing non-ASCII characters (e.g., diacritics, Cyrillic). This failure occurs regardless of whether the domain is specified in the app's entitlements in its human-readable Unicode format (e.g., montréal.ca) or its encoded Punycode format (e.g., xn--montral-fya.ca, xn--e1afka0abm4b.xn--p1ai). Without fetching and validating this file, Universal Links are not activated, and the system fails to establish a connection between the website and our app. Steps to Reproduce: Create an app with the Associated Domains entitlement enabled. Add an IDN to the entitlement. We tested both formats: Format A (Unicode): applinks://montréal.ca Format B (Punycode): applinks://xn--montral-fya.ca Host a valid AASA file on our server at the correct, accessible well-known URLs for both domain representations: For montréal.ca: https://montréal.ca/.well-known/apple-app-site-association and https://xn--montral-fya.ca/.well-known/apple-app-site-association Install the app on a device running the latest iOS version. Monitor network traffic using a tool like Charles Proxy. Observed Result: No HTTP GET request is made to any of the AASA URLs for the domains montréal.ca (in either Unicode or Punycode format) upon app installation. The system does not initiate the domain validation process. In contrast, for a standard ASCII domain (e.g., applinks://example.com), the AASA fetch is triggered immediately and is observed in the network log. Expected Result: iOS should correctly resolve the Internationalized Domain Name (whether specified in Unicode or Punycode format in the entitlement) and perform an HTTP GET request to fetch the AASA file from the /.well-known path, identical to its behavior for ASCII domains. Evidence & Configuration: Our server is configured correctly: SSL certificates are valid, the AASA file is served with the correct application/json MIME type, and is directly accessible via a browser or curl. The AASA file's syntax has been validated and is correct. The issue is reproducible on the latest versions of iOS. Impact: This bug blocks a core platform feature for millions of users in regions that use non-Latin scripts (e.g., France, Russia, China, Arab states). It makes it impossible to use Universal Links with our primary domains, severely degrading the user experience and forcing us to seek suboptimal workarounds like registering separate ASCII domains. Request: We kindly request that you investigate and log this issue as a bug in iOS and forward it to the appropriate engineering team for a fix in an upcoming update. We are prepared to provide any additional information, demo projects, or server access to assist in diagnostics. Thank you for your attention to this serious matter.

Hi everyone, on iOS, when a VoIP call arrives and the user accepts it from the lock screen (after unlocking with Face ID/Touch ID), is there any way to automatically bring my app to the foreground and show the in-app call screen, instead of staying in the system CallKit UI?

In the documentation for the example Live Caller ID server (https://swiftpackageindex.com/apple/live-caller-id-lookup-example/main/documentation/pirservice/testinginstructions) there is an example service-config.json. file shown (without thorough documentation). That config file, and the whole of the instructions, center around there being two datasets of numbers: block and identity. My question is - is it possible for more than one dataset to be specified i.e. for block1 and block2 to be specified? The use case for this would be - suppose the Live Caller ID server has a set of numbers it has identified as being nuisance callers and so it lists these in the block section. However user A might want all these nuisance callers to be blocked but user B does not. Therefore the Live Caller ID extension on the handset would need to use a different dataset on the server so that user A's calls from a set of numbers is blocked, but user B's are not. Note that I'm not suggesting that the Caller ID server should be capable of storing individual user's preferences. All that would be required would be two data sets: one where blocked content is none and and one where blocked content is some. Then a user/app could switch between them as indicated by the user. Is that possible? If the database structure and service-config.json etc. is not configured to permit that, then could two different servers be set up to achieve this instead? i.e. so the server url specified in the app's extension can be set at run time and not at compile time?

I am requesting assistance with an issue involving my Advanced App Clip Experience, which has remained in the “Received” state for more than few months, preventing the App Clip from becoming available when invoked via QR code. App Details App Name: Yellow Label Verification App Store Bundle ID: com.acviss.demoindia App Clip Bundle ID: com.acviss.demoindia.Clip Team ID: F2RLQ4VV59 App Version (Live): 1.4 Domain: acviss.com Issue Summary My Advanced App Clip Experience is stuck in the “Received” status. The “Publish” and “Build Assignment” options never appear, even though: The updated AASA file is correctly published at: https://acviss.com/.well-known/apple-app-site-association It contains the correct appclips → appID and paths entries It is served with the correct application/json content type Domain validation in App Store Connect shows Validated The App Clip build is already approved and live on the App Store Safari-based App Clip invocation works as expected Despite this, the Advanced App Clip Experience has not transitioned from “Received” to “Processing” or “Published.” Because of this, QR-based invocation consistently shows “App Clip Unavailable”, indicating that the App Clip Experience has not yet been activated on Apple’s backend. Reproduction Steps Publish correct AASA file with appclips array and paths Validate domain (shows green “Validated” in App Store Connect) Open the Advanced App Clip Experience in App Store Connect Status stays as Received “Build Assignment” or “Publish” buttons never appear QR scanning of the App Clip URL continues to show App Clip Unavailable Request Could you please check the backend processing of my App Clip Experience and manually trigger the sync or processing It appears that the App Clip Experience is not being processed even though all configuration, AASA, and domain validations are correct. I would greatly appreciate your assistance in resolving this so the App Clip can be invoked successfully via QR. Thank you very much for your help and support.

app packged with Xcode16 crashed on iOS12 certainly. My question is: is it known issue for Apple team? to resolve this issue, what can we developers do? This is

Hello, I’m encountering an issue with Universal Links in my iOS app. After some investigation, I found that the root cause seems to be that Apple’s request through there CDN server to access the .well-known/apple-app-site-association file is blocked by our firewall, which enforces geographic access restrictions as part of our security policy. Because of this restriction, Apple’s validation or link verification requests are being denied, and the Universal Links are not working as expected. I’d like to get some guidance from the community or Apple engineers on the following: 1. Does Apple provide an official list of IP ranges or domains that need to be allowed through the firewall for Universal Link validation? 2. Are there alternative methods to handle Universal Link verification in environments with geographic restrictions? 3. Would whitelisting specific Apple services or endpoints be a recommended or safe solution? Any input or recommendations would be greatly appreciated. Environment Details: • iOS app using Universal Links • Server protected by a firewall with regional restrictions • AASA file hosted correctly and accessible via browser Thanks in advance for your help and insights.

I'm working with the Apple Watch's acceleration data and have referred to the document Identify the coordinate axes of the device. According to this document, the X-axis points to the right side of the watch, the Y-axis points towards the top side, and the Z-axis points towards the user. However, when I place the watch on a flat surface and move it horizontally to the right, I observe that the X-axis acceleration is negative. Similarly, when I move the watch vertically upwards, the Y-axis acceleration also shows a negative value. Is this expected behavior, or am I misunderstanding something about the coordinate system or acceleration readings?

I have downloaded the ShinyTV example to test simplified sign-in on tvOS since it is not working in my own app, and I am having the same issue there. After assigning my team to the sample app, the bundle ID updates with my team id. I copy the bundle ID into a file entitled "apple-app-site-association" with this format: { "webcredentials": { "apps": [ "{MyTeamID}.com.example.apple-samplecode.ShinyTV{MyTeamID}" ] } } I upload the file to my personal site, ensuring that the content type is application/json. I adjust the Associated Domain entitlement to: webcredentials:*.{personal-site.com}?mode=developer using the alternate mode to force it to load from my site, not the CDN. When I run the build on tvOS, and click the Sign In button, it fails with these errors: Failed to start session: Error Domain=com.apple.CompanionServices.CPSErrorDomain Code=205 "Failed to prepare authorization requests" UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=com.apple.CompanionServices.CPSErrorDomain Code=205 \"Missing associated web credentials domains\" UserInfo={NSLocalizedDescription=Missing associated web credentials domains}" ), NSLocalizedDescription=Failed to prepare authorization requests} Session failed: Error Domain=com.apple.CompanionServices.CPSErrorDomain Code=205 "Failed to prepare authorization requests" UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=com.apple.CompanionServices.CPSErrorDomain Code=205 \"Missing associated web credentials domains\" UserInfo={NSLocalizedDescription=Missing associated web credentials domains}" ), NSLocalizedDescription=Failed to prepare authorization requests} ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "(null)" UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=com.apple.CompanionServices.CPSErrorDomain Code=205 \"(null)\"" )} Failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Failed to prepare authorization requests" UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=com.apple.CompanionServices.CPSErrorDomain Code=205 \"Missing associated web credentials domains\" UserInfo={NSLocalizedDescription=Missing associated web credentials domains}" ), NSLocalizedDescription=Failed to prepare authorization requests} What am I missing here?

With the Live Caller ID example server, the caller lookup dataset is defined in an input.txtpd and processed by running a ConstructDatabase command which creates a block.binpb and an identity.binpb file. In other words, a static input file is being processed into static block and identity files. However, in the real world, the data content for identified and blocked numbers is something which is in a constant state of flux and evolution, as new numbers becoming available, old ones become stale, numbers which were initially considered safe change into being considered malicious etc. etc. Is the example server just that, merely an example using fixed datasets, and an actual production server is able to use live every changing data to formulate its response back to the iPhone OS query? Here's a concrete use case - suppose it's a requirement to permit US nanp numbers but to block anything else. The total number of non US nanp numbers is so large and ever changing that it would be unfeasible to attempt to capture them in an input.txtpd file and then process that, and then to re-capture and re-process it endlessly. Instead what would be required is the ability for the Live Caller ID server to evaluate at query time, using a regular expressions for example, if a number is nanp or not. Is this possible?

My ASA file is located here https://staging.docyt.com/apple-appsite-association It downloads fine. It does not have .json extension and neither does it reside inside the ./well-known folder. Should it work? Because opening the link https://staging.docyt.com/reset-password is not opening the app installed via TestFlight . Installing via XCode however works fine. Please help

I have an app using weatherkit and its currently live and up on the app store, recently I had some users report to me that they had been receiving errors loading weather data, I had error handling built in and it reported an issue with apples authentication server Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" I have not come across this during the development lifecycle of my project, there where no codebase changes, it just stopped functioning. The app entitlements are valid and correct, Weatherkit is enabled in both xcode and across my Certs, identifiers and profiles. I was not experiencing this issue until I reinstalled the app from the app store completly by first removing it and then re-installing fresh. Hard reboots do not help and I do not want to start suggesting to my users to factory reset their devices. We are using WeatherKit in both our main app and widget, relying entirely on Apple’s framework for authentication and token management. We do not generate or inject our own JWT tokens; all token handling is managed by WeatherKit. We have implemented a debug menu with the following actions: Clear WeatherKit JWT tokens from the keychain Clear all related UserDefaults key Clear all app group data and all UserDefaults. Perform a “nuclear” cache clear (removes all app data, keychain, and cached files). We log all WeatherKit fetch attempts and failures, including authentication errors, both in the app and widget and get nothing but code 2. We have attempted all of the above steps, but continue to experience issues with WeatherKit JWT authentication We would appreciate any guidance or insight into what else could be causing persistent WeatherKit JWT/authentication issues, or if there are any additional steps we should try. P.S. - Tested and experiencing the same issues on an iPhone 15 Pro Max and iPhone 15 The Pro Max is on the iOS 26 Beta // and the 15 is on the latest iOS 18

We have a subscription WeatherKit app which has been on the App Store since December 2023. I am getting intermittent JWT auth failures on customer devices. In the great majority of cases, the request succeeds, but sometimes it fails, and sometimes it fails and never recovers. I’m working with a customer right now who is unable to get any weather data at all, and the logs he sends me show WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors error 2 The app uses the WeatherKit SDK (we are not using the REST API directly). We know we have the project setup as it has been working since launch, and I can verify weatherkit using security cms -D -i embedded.mobileprovision It it not a problem with the specific query, since I can get data for the dates and locations they are requesting. I can’t replicate the problem on my test devices. In case there is a rate limit issue: this app is a bit unusual and downloads an unusual amount of data at once using multiple queries in parallel using a TaskGroup. When the user creates a location, the app downloads a 10 day block of weather (7 days in the past + 3 day forecast) using WeatherService.shared.weather( for: location, including: WeatherQuery.daily( startDate: startDate, endDate: endDate ), WeatherQuery.hourly( startDate: startDate, endDate: endDate ) ) It also downloads about 2 months of daily precipitation data using multiple parallel calls to dailySummary in 10 day blocks: WeatherService.shared.dailySummary( for: location, forDaysIn: DateInterval(start: startDate, end: endDate), including: .precipitation ) In almost every case, including on my test devices, this works. But some users get WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors error 2 on every request. The two users yesterday that had this problem were both on iOS 18.5 for what that's worth, though the app supports 17.2+ Is anyone else seeing this? And can anyone suggest anything else to explore? It's obviously a terrible experience for customers who pay for the service and are unable to get any data. I did submit this info to Apple as FB18276275

My app AirCompare has been in the app store and successfully using WeatherKit to fetch weather since it became available. Now some (not all) users are encountering the following errors: Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Encountered an error when fetching weather data subset; location=<+42.40865786,-88.96911526> +/- 0.00m (speed -1.00 mps / course -1.00) @ 6/23/25, 2:56:47 PM Central Daylight Time, error=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors 2 Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Others are reporting this same problem here in the forums. We need a solution!

The functionality of authorizationStatus and requestAuthorization is completely broken. I'm using Xcode 15.3 and iOS 17.4. Does anyone have a solution? authorizationStatus doesn't behave as promised Revoking authorization in the system-wide settings does not change the authorizationStatus while the app is not closed. Calls to center.authorizationStatus will still return .approved instead of .denied. Even closing and relaunching the app after revoking authorization does not work: authorizationStatus is then .notDetermined when it should be .denied. Tapping "Don't Allow" in the alert shown after an initial call to requestAuthorization leaves the authorizationStatus unchanged, i.e. at .notDetermined. This is contrary to the promised outcome .denied (defined as: "The user, parent, or guardian denied the request for authorization") and contrary to the definition of .notDetermined (defined as: "The app hasn’t requested authorization", when it just did). Same issue when first tapping "Continue" followed by "Don't Allow" on the next screen. As a consequence of authorizationStatus being broken, its publisher $authorizationStatus is worthless too. requestAuthorization doesn't behave as promised This is most likely a consequence of the corrupted authorizationStatus: when revoking authorization in the system-wide settings, a call to requestAuthorization opens the authorization dialogue instead of doing nothing. It is thus possible to repeatedly ask a user to authorize Family Controls. Code sample To reproduce, create a new SwiftUI app, add the "Family Controls" capability and a button executing the following task when tapped: let center = AuthorizationCenter.shared var status = center.authorizationStatus print(status) do { try await center.requestAuthorization(for: .individual) print("approved") } catch { print("denied") } status = center.authorizationStatus print(status)

In iOS 18, the requestValue method no longer works when the parameter it is called on is not included in the parameterSummary of an AppIntent. This issue causes the app to fail to present a prompt for the user to select a value, resulting in an error with the message: Domain=NSCocoaErrorDomain Code=4099 "The connection from pid 40685 on anonymousListener or serviceListener was interrupted, but the message was sent over an additional proxy and therefore this proxy has become invalid." Steps to Reproduce: Create a simple AppIntent with the following code: import AppIntents struct Intent: AppIntent { static let title: LocalizedStringResource = "Intent" static var parameterSummary: some ParameterSummary { Summary("Test \(\.$category)") {} } @Parameter(title: "Category") private var category: CategoryEntity? @Parameter(title: "Hidden Category") private var hidden: CategoryEntity? @MainActor func perform() async throws -> some ReturnsValue<CategoryEntity?> { var result: CategoryEntity? do { result = try await $hidden.requestValue("Select category") // Doesn't work since iOS 18 as $hidden is not set in parameterSummary } catch { print("\(error)") } return .result(value: result) } } Run the code on a device with iOS 18. Observe that the requestValue method fails to present the selection prompt and instead throws an error. Expected Results: The app should successfully present a prompt for the user to select a value for the hidden parameter using requestValue, even if the parameter is not included in the parameterSummary. Actual Results: The app fails to present the selection prompt and throws an error, making it impossible to use requestValue for parameters not included in parameterSummary. Version/Build: iOS 18.0 Configuration: Tested on various devices running iOS 18. Is there a change in the API that I might have missed?

We appreciate your suggestion to use the Apple Developer Forums. However, we must respectfully request further escalation of this issue beyond the forums for several critical reasons: Severity and Scope: This is not a general development discussion topic. We are facing a massive, reproducible performance issue on iOS 16 that renders devices unresponsive, requiring factory resets or DFU restores. This goes far beyond typical app bugs and points to a potential systemic issue in the OS's image handling. Insufficiency of Forum Support: While the forums are a valuable resource for community advice, they cannot provide the official, in-depth technical diagnosis from Apple engineers that this situation demands. Our users' devices are being bricked by an app update that passed App Review, and we require clarity on the root cause to prevent further damage and restore user trust. Code-Level Support Eligibility: As members of the Apple Developer Program, we believe our issue falls under the purview of Code-Level Support, as described on the Apple Developer website 9. Our problem involves "building or running software" and requires expertise in Apple's frameworks and hardware-level image rendering APIs. We request that our case be forwarded to that specialized team. To reiterate the core problem: Our update introduced 1024x1026 JPEG assets into the Asset Catalog. On iOS 16, this causes severe overheating, freezing, and device unresponsiveness. Replacing them with PNGs completely resolves the issue. This suggests a potentially serious regression in iOS 16's JPEG decoding or memory management pipeline. We prepared to provide a sample project that demonstrates the issue if required. Our case number is 102678393572. We urgently need to understand why this happens at the OS level to ensure our app is safe and to contribute to the stability of the iOS platform. Please escalate this case to the appropriate technical team for a detailed investigation. Sincerely,

I have installed the macOS 26 WWDC beta on a secondary volume, and set it up with two user accounts (both administrators). However, the options for switching users without fully logging out are nowhere to be found. The topic is still included in macOS Help and is shown when searching for “fast” in System Settings, however, the option is hidden/missing in the pref pane when selected. Filed FB18155517 (macOS 26 beta: No Fast User Switching?)

We have a problem in a scenario that SIM lock is disabled so after a phone reboots it has the Internet connection but it is still locked. When you call into the VOIP app the app is not being launched as the result (it seems reasonable because it wouldn't be able to access the keychain items etc...) but the OS still seem to enforce the rule that the app needs to report the new incoming call. When we then unlock the app we can see no more pushkit pushes are arriving (dropped on the floor in the console) but we get the three initial pushes that were send during the locked phase right after the app launch.

In my app, I implemented a screen recording functionality. But there was an unexpected crash. 0 CoreFoundation _CFRelease.cold.1 + 16 1 CoreFoundation ___CFTypeCollectionRelease 2 ReplayKit ___56-[RPScreenRecorder captureHandlerWithSample:timingData:]_block_invoke + 148 3 libdispatch.dylib __dispatch_call_block_and_release + 32 4 libdispatch.dylib __dispatch_client_callout + 16 5 libdispatch.dylib __dispatch_lane_serial_drain + 740 6 libdispatch.dylib __dispatch_lane_invoke + 388 7 libdispatch.dylib __dispatch_root_queue_drain_deferred_wlh + 292 8 libdispatch.dylib __dispatch_workloop_worker_thread + 540 9 libsystem_pthread.dylib __pthread_wqthread + 292