When I've tried to use UIDevice on my Mac running my Catalyst application, testing code UIDevice *d=UIDevice.currentDevice; for (NSString *k in @[@"name", @"systemName", @"systemVersion", @"model", @"localizedModel"]) NSLog(@"%@ -> %@", k, [d valueForKey:k]); to my great surprise I am getting name -> iPad systemName -> iPadOS systemVersion -> 26.3 model -> iPad localizedModel -> iPad What the. How do I determine the real values? Thanks!

Our app supports UIScene. As a result, launchOptions in application(_:didFinishLaunchingWithOptions:) is always nil. However, the documentation mentions that UIApplication.LaunchOptionsKey.location should be present when the app is launched due to a location event. Given that our app is scene-based: How can we reliably determine whether the app was launched due to a location update, geofence, or significant location change? Is there a recommended pattern or API to detect this scenario in a Scene-based app lifecycle? This information is critical for us to correctly initialize location-related logic on launch. Relevant documentation: https://developer.apple.com/documentation/corelocation/cllocationmanager/startmonitoringsignificantlocationchanges()

Hello Apple Developer Technical Support, I’m following up on case #102807413324 and submitting this as a code-level support request. We are integrating iOS Live Activities (ActivityKit + WidgetKit extension written in SwiftUI) into an Expo/React Native app. We’re seeing behavior where the Live Activity UI shown on the Lock Screen appears to “stick” to an older layout and ignores updated SwiftUI code and/or bundled assets, even after rebuilding, reinstalling, and removing existing Live Activities before testing again. Environment Device: iPhone 13 iOS: 26.2 macOS: 15.7.3 (24G419) Xcode: 16.4 (16F6) Expo SDK: 52 React Native: 0.76.9 expo-live-activity: ^0.4.2 Build type: Ad-Hoc signed IPA (EAS local build) Summary We have a WidgetKit extension target (LiveActivity.appex, bundle id: stimul8.LiveActivity) using ActivityConfiguration(for: LiveActivityAttributes.self). The extension contains multiple SwiftUI views selected via a “route” (derived from deepLinkUrl / title / subtitle), and uses images/backgrounds from the extension asset catalog (Assets.xcassets). We also support loading images from an App Group container with a fallback to the asset catalog. After shipping updates, the Live Activity UI shown on the Lock Screen continues to resemble an older/default layout (example: a progress-bar-like element remains visible even after removing ProgressView usage from LiveActivityView.swift). Some custom backgrounds/images also fail to display as expected. Routing (examples) /streak -> StreakLiveActivityView /streak-urgent -> StreakUrgentLiveActivityView /lesson/create -> AILessonLiveActivityView1 /lesson/reminder -> AILessonLiveActivityView2 default -> LiveActivityView Steps to reproduce (high-level) Install/build and trigger a Live Activity. Modify the SwiftUI layout in the extension (e.g., remove ProgressView and change obvious UI elements), rebuild, and reinstall. Remove any existing Live Activities from the Lock Screen, then trigger a new Live Activity again. Observed: Lock Screen Live Activity still renders the prior/older-looking UI and/or ignores updated assets. Troubleshooting already done Verified the extension (LiveActivity.appex) is included in the IPA and properly signed. Verified Assets.car is present in the extension and PNG assets are present in the build artifacts. Ensured SwiftUI source files used by the extension are overwritten during prebuild so the intended versions are present in ios/LiveActivity. Cleared DerivedData related to LiveActivity builds. Reinstalled the app and removed existing Live Activities from the Lock Screen before re-triggering new ones. Questions Is there any known caching behavior where Live Activities can continue to display a previous UI layout after an app/extension update, even when the activity is re-created? Are there recommended steps to force the system to load the newest widget extension binary/UI beyond reinstalling and removing existing Live Activities? What’s the recommended way to confirm which exact extension binary/UI version is being rendered on-device (e.g., specific Console logs, sysdiagnose signals, or other indicators)? Are there any known constraints with Assets.xcassets usage for Live Activities that could cause bundled assets not to render even when present? We can provide A minimal reproduction Xcode project (preferred) The IPA build Build logs (Xcode/EAS) Screenshots/video and a sysdiagnose captured after reproduction Thank you for your guidance. Best regards

Hello, We are using a Message Filter Extension (ILMessageFilterExtension) to classify SMS/iMessage content (junk vs allow) in our app. After testing on iOS 26.1, we want to confirm whether there are any behavioral, performance, or API-level changes that impact message filtering, such as: Changes in how often the filter extension is invoked Differences in classification accuracy or system overrides New privacy, entitlement, or permission-related restrictions Execution time limits or memory constraints Any changes specific to iMessage vs SMS filtering We did not find any explicit mention of Message Filter Extensions in the iOS 26.1 release notes and would like to confirm whether the existing behavior from previous iOS versions remains unchanged. Has Apple introduced any known or undocumented changes in iOS 26.1 that developers should be aware of when supporting Message Filter Extensions? Sometime I also found unpredictable behaviour on iOS version 18.5 or below, like sometime it works but sometimes starts working. Thanks in advance for any guidance.

Hi DTS / Apple engineers, We’re attempting to extending our screen time app target to Mac Catalyst. On iOS, FamilyControls works as expected (AuthorizationCenter + FamilyActivityPicker, then ManagedSettings shields + DeviceActivity monitoring/reporting). On Mac Catalyst: The project builds with FamilyControls/DeviceActivity/ManagedSettings capabilities enabled. But attempting to request FamilyControls authorization (or present FamilyActivityPicker) fails at runtime. We see errors similar to: Failed to get service proxy: The connection to service named com.apple.FamilyControlsAgent was invalidated: failed at lookup with error 159 - Sandbox restriction. And our app stays authorizationStatus == .notDetermined, with the request failing. We saw an Apple engineer suggestion to “disable App Sandbox”, but Mac Catalyst apps appear to always be sandboxed, so we can’t disable it. Questions: Is FamilyControls authorization supported on Mac Catalyst today? If so, what entitlement/capability is required specifically for Catalyst/macOS? If FamilyControls auth cannot succeed on Catalyst, does that mean ManagedSettings shields and DeviceActivity monitoring/reporting are effectively unusable on Catalyst (since they depend on that authorization)? Is there an Apple‑recommended approach for a Catalyst “portal” app that mirrors an iOS child device’s restrictions, or is local enforcement on Catalyst intentionally unsupported? Any guidance (and any official docs that clarify current platform support) would be hugely appreciated.

Reference: FB21797091 / Related to thread 807695 Hello, I have already submitted a report regarding this issue via Feedback Assistant (FB21797091), but I would like to share the technical details here to seek further insights or potential workarounds. We are experiencing a technical regression where Universal Links and Shared Web Credentials fail to resolve for Internationalized Domain Names (IDN) specifically on iOS 16 and later. This issue appears to be identical to the one discussed in thread 807695 (https://developer.apple.com/forums/thread/807695). Technical Contrast: What works vs. What fails On the exact same app build and iOS 16+ devices, we observe a clear distinction: Standard ASCII Domain (onelink.me): Works perfectly. (Proves App ID and Entitlements are correct) Internal Development Domain (Standard ASCII): Works perfectly. (Proves our server-side AASA hosting and HTTPS configuration are correct) Japanese IDN Domain (xn--[punycode].com): Fails completely. (Status: "unspecified") Note: This IDN setup was last confirmed to work correctly on iOS 15 in April 2025. Currently, we are unable to install the app on iOS 15 devices for live comparison, but the regression starting from iOS 16 is consistent. This "Triple Proof" clearly isolates the issue: the failure is strictly tied to the swcd daemon's handling of IDN/Punycode domains. Validation & Diagnostics: Validation: Our Punycode domain passes all technical checks on the http://Branch.io AASA Validator (Valid HTTPS, valid JSON structure, and Content-Type: application/json). sysdiagnose: Running swcutil on affected iOS 16+ devices shows the status as "unspecified" for the IDN domain. Symptoms: Universal Links consistently open in Safari instead of the app, the Smart App Banner is not displayed, and Shared Web Credentials for AutoFill do not function. Request for Resolution: We request a fix for this regression in the swcd daemon. If this behavior is a specification for security reasons, please provide developers with a supported method or workaround to ensure IDN domains function correctly. We have sysdiagnose logs available for further investigation. Thank you.

I tried making a concurrency-safe data queue. It was going well, until memory check tests crashed. It's part of an unadvertised git project. Its location is: https://github.com/CTMacUser/SynchronizedQueue/commit/84a476e8f719506cbd4cc6ef513313e4e489cae3 It's the blocked-off method "`memorySafetyReferenceTypes'" in "SynchronizedQueueTests.swift." Note that the file and its tests were originally AI slop.

Greetings, According to Apple's Wi-Fi Aware documentation (https://developer.apple.com/documentation/wifiaware) the Wi-Fi Aware APIs can be used only with peer devices that have been paired. Pairing can be performed using AccessorySetupKit or DeviceDiscoveryUI. Unfortunately, the sample code for Wi-Fi Aware doesn't include either of these APIs. (https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps) Looking at the sample code for AccessorySetupKit (https://developer.apple.com/documentation/accessorysetupkit/setting-up-and-authorizing-a-bluetooth-accessory) there is only an example using Bluetooth. And the AccessorySetupKit APIs don't yet document how Wi-Fi Aware is used or how one sets up the Info.plist with the appropriate keys. Can Apple update its example code to fill in these gaps or point me to documentation that can fill in these gaps? It is hard to develop an understanding of the capabilities of these APIs when they are so poorly documented. Thanks for any help, Smith

We have an application which is written in Swift, which activates Transparent Proxy network extension. Our Transparent Proxy module is a system extension, which is exposing an app proxy provider interface (We are using NETransparentProxyProvider class and in extension’s Info.plist we use com.apple.networkextension.app-proxy key.) We are using JamF MDM profile with VPN payload for deployment. With this MDM profile, we are observing an issue, ie TransparentProxy extension is not enabled when user performs logout and login and only in Sonoma. By analyzing it further we are noticing that in Sonoma some times, the system invokes NETransparentProxyProvider's stopProxy delegate once or twice with NEProviderStopReason as 12 ie userLogout. Due to this after login the system extension is not activated.

I have to continuously disable Limit IP Tracking on my local Wi-Fi network. When it's enable I am not able to access some services on the same subnet that falls under rfc1918. Accessing remote network, over site to site vpn, is not affected, just my local network. I opened FB21483619 for this. I would expect to see rfc1918 subnets not included. Also would expect all DNS queries to be sent to the servers provided in DHCP.

As part of iOS 26, we get X25519MLKEM768 key exchange group support, but SecP256r1MLKEM768 and SecP384r1MLKEM1024 are not supported. Is there any way to enable these key exchange groups on iOS 26? We need them for WKWebView and NSURLSession. STEPS TO REPRODUCE On iOS 26, connect to the PQC server using Safari. The key exchange group is limited to X25519MLKEM768.

Hey! I'm working on enabling remotely started live activities. I'm running into 2 crashes: Upon initializing ActivityAuthorizationInfo Upon calling Activity<...>.activities array Both stack traces look like this: 0 libsystem_kernel.dylib +0xce0 _mach_msg2_trap 1 libsystem_kernel.dylib +0x4398 _mach_msg2_internal 2 libsystem_kernel.dylib +0x42b4 _mach_msg_overwrite 3 libsystem_kernel.dylib +0x40fc _mach_msg 4 libdispatch.dylib +0x1cc04 __dispatch_mach_send_and_wait_for_reply 5 libdispatch.dylib +0x1cfa4 _dispatch_mach_send_with_result_and_wait_for_reply 6 libxpc.dylib +0x107ec _xpc_connection_send_message_with_reply_sync 7 BoardServices +0xaea8 -[BSXPCServiceConnectionMessage _sendWithMode:] 8 BoardServices +0x17938 -[BSXPCServiceConnectionMessage sendSynchronouslyWithError:] 9 BoardServices +0xeef0 ___71+[BSXPCServiceConnectionProxy createImplementationOfProtocol:forClass:]_block_invoke They happen to a limited number of users, but not insignificant. Most are on iOS 18.6.2 and iOS 26.1, but there are others in the mix. I don't have a repro myself. It looks like the main thread gets blocked after we receive no response from these ActivityKit APIs. Both of these are called inside application:didFinishLaunchingWithOptions:. For ActivityAuthorizationInfo, we need the app to communicate with the server whether the user has live activities enabled; hence, calling this object's init as early as possible in the app. For activities array, I'd like to do some logging whenever the live activity is started or ended (for example, if activities array no longer contains any activities, we can log the activity as dismissed). For this logging to happen, as far as I understand, it has to happen inside didFinishLaunchingWithOptions since this is the only method being called upon the terminated app receiving background runtime when the live activity starts/ends remotely. After some research, one potential reason is ActivityKit APIs are just not ready to return values via xpc connection at app startup, so moving these methods to applicationDidBecomeActive could resolve the problem. That's fine for ActivityAuthorizationInfo init, but for accessing activities, there is no other place in the lifecycle to see if an activity has been dismissed (especially in the scenario where app is terminated, so we get only 30 seconds ish of background runtime). Curious if anyone has run into this or has any insights into ActivityKit API behavior.

I've spent a few months writing an app that uses SwiftData with inheritance. Everything worked well until I tried adding CloudKit support. To do so, I had to make all relationships optional, which exposed what appears to be a bug. Note that this isn't a CloudKit issue -- it happens even when CloudKit is disabled -- but it's due to the requirement for optional relationships. In the code below, I get the following error on the second call to modelContext.save() when the button is clicked: Could not cast value of type 'SwiftData.PersistentIdentifier' (0x1ef510b68) to 'SimplePersistenceIdentifierTest.Computer' (0x1025884e0). I was surprised to find zero hit when Googling "Could not cast value of type 'SwiftData.PersistentIdentifier'". Some things to note: Calling teacher.computers?.append(computer) instead of computer.teacher = teacher results in the same error. It only happens when Teacher inherits Person. It only happens if modelContext.save() is called both times. It works if the first modelContext.save() is commented out. If the second modelContext.save()is commented out, the error occurs the second time the model context is saved (whether explicitly or implicitly). Keep in mind this is a super simple repro written to generate on demand the error I'm seeing in a normal app. In my app, modelContext.save() must be called in some places to update the UI immediately, sometimes resulting in the error seconds later when the model context is saved automatically. Not calling modelContext.save() doesn't appear to be an option. To be sure, I'm new to this ecosystem so I'd be thrilled if I've missed something obvious! Any thoughts are appreciated. import Foundation import SwiftData import SwiftUI struct ContentView: View { @Environment(\.modelContext) var modelContext var body: some View { VStack { Button("Do it") { let teacher = Teacher() let computer = Computer() modelContext.insert(teacher) modelContext.insert(computer) try! modelContext.save() computer.teacher = teacher try! modelContext.save() } } } } @Model class Computer { @Relationship(deleteRule: .nullify) var teacher: Teacher? init() {} } @Model class Person { init() {} } @available(iOS 26.0, macOS 26.0, *) @Model class Teacher: Person { @Relationship(deleteRule: .nullify, inverse: \Computer.teacher) public var computers: [Computer]? = [] override init() { super.init() } }

Hi! I have defined the following app intent. It returns a result with a dialog to confirm that the intent has been executed. Naturally, that dialog needs to be localized properly. But the String interpolation with the provided format doesn't do that. I specified wide for the width parameter and expect spelled-out unit names. However, in the textual output, Siri always uses the abbreviated unit (e.g. "min" or "s"), in all languages I tested. In the audio output, Siri says "minutes" in English where the textual representation is "min". In German, Siri says "min", so it basically reads the textual representation aloud and that's not quite understandable to the user. struct StartTimerIntent: AppIntent { static let title: LocalizedStringResource = "Start New Timer" static var description = IntentDescription("Starts a timer with a custom duration.") @Parameter(title: "Duration", description: "The duration of the timer.") var duration: Measurement<UnitDuration> func perform() async throws -> some IntentResult & ProvidesDialog { // [code to execute intent goes here] return .result( dialog: .init( full: "\(duration, format: .measurement(width: .wide, usage: .asProvided)) timer started.", systemImageName: "timer" ) ) } } As this SwiftUI-style formatter doesn't seem to work with localization, I tried a different approach with a MeasurementFormatter: extension Measurement where UnitType == UnitDuration { func localized() -> String { let formatter = MeasurementFormatter() formatter.locale = .autoupdatingCurrent formatter.unitOptions = .providedUnit formatter.unitStyle = .long return formatter.string(from: self) } } Usage with String interpolation: "\(duration.localized()) timer started." This works great as long as these two languages are set to the same language on the user's device: [UI language] Settings → General → Language & Region → Preferred Language [Siri langauge] Settings → Apple Intelligence & Siri → Language However, when they differ, even this method doesn't yield correct results. For example, I have my general (UI) language set to English, but my Siri language set to German. Then Siri replies in German, but the unit is formatted in English and Siri speaks it in English, so the result is a messed up sentence that's half German, half English. What is the proper way to localize parameters in dialogs for Siri? How can I make sure that parameters are localized to match Siri's language?

Excited for AlarmKit! I have found two concerns that I cannot find answers for though. The volume of my alarms seems to be very quite relative to the full volume capability of the device. For example, if I turn the volume all the way up and play the audio file, the sound is very loud. However then, if I set the alarm using alarm kit with the same audio, the track played during the alerting phase is not that loud. I am afraid that it will not be loud enough in real life. Will there be future support to set the volume level of the alarm to maximum settings? When I press the volume buttons (with the app open) during an active alarm, the audio stops, but the alarm manager does not clear these events. The alarm manager does clear the alarm event if the alarm is stopped through a live activity.

Hello Apple Developer Technical Support / Core Location Team, I’m requesting clarification on the effective timing of the Info.plist key NSLocationDefaultAccuracyReduced. We shipped Version A with NSLocationDefaultAccuracyReduced = YES (reduced accuracy by default). In Version B we changed it to NO. After updating to Version B, on devices/users that have not previously granted location authorization for our app, the first authorization flow still behaves as if reduced accuracy is the default (i.e., the same behavior as Version A). Could you please confirm: When iOS evaluates/caches NSLocationDefaultAccuracyReduced (install time, app launch, or at first authorization prompt)? After an update changes this key from YES to NO, should the new value apply to users who have never authorized location for the app? Environment: Iphone 16 (IOS 26.0) I can provide a sysdiagnose and additional logs if needed. Thank you, Jack

Does our app need to check the location or can we fully reply on this API to decide whether we wanna comply for the law of places that requires age range information? Looks like it's only covering Texas now..? would it add other places by apple..? And also this API is really hard to test a user in other places, Iike I don't know a user in Brazil gonna return true for false now, but the law in Brazil also requires the age information.

It's quite common for app bundles to be distributed in .zip files, and to be stored on-disk as filesystem-compressed files. However, having them both appears to be an edge case that's broken for at least two major releases! (FB19048357, FB19329524) I'd expect a simple ditto -x -k appbundle.zip ~/Applications (-x: extract, -k: work on a zip file) to work. Instead it spits out countless errors and leaves 0 Byte files in the aftermath 😭 Please fix.

Hi, You're here because you've had issues with your implementation of In-App Provisioning Extensions for Apple Pay In-App Provisioning or In-App Verification. To prevent sending sensitive credentials in plain text, create a new report in Feedback Assistant to share the details requested below with the appropriate log profiles installed. Gathering Required Information for Troubleshooting Apple Pay In-App Provisioning or In-App Verification Issues While troubleshooting Apple Pay In-App Provisioning or In-App Verification, it is essential that the issuer is able to collect logs on their device and check those logs for error message. This is also essential when reporting issues to Apple. To gather the required data for your own debugging as well as reporting issues, please perform the following steps on the test device: Install the Apple Pay and Wallet profiles on your iOS or watchOS device. If the issue occurs on Mac, continue to Step 2. Reproduce the issue and make a note of the timestamp when the issue occurred, while optionally capturing screenshots or video. Gather a sysdiagnose on the same iOS or watchOS device, or on macOS. Create a Feedback Assistant report with the following information: The bundle IDs App bundle ID Non-UI app extension bundle ID (if applicable) UI app extension bundle ID (if applicable) The serial number of the device. For iOS and watchOS: Open Settings > General > About > Serial Number (tap and hold to copy). For macOS: Open the Apple () menu > About This Mac > Serial Number. The SEID (Secure Element Identifier) of the device, represented as a HEX encoded string. For iOS and watchOS: Open Settings > General > About > SEID (tap and hold to copy). For macOS: Open the Apple () menu > About This Mac > System Report > NVMExpress > Serial Number. The sysdiagnose gathered after reproducing the issue. The timestamp (including timezone) of when the issue was reproduced. The type of provisioning failure (e.g., error at Terms & Conditions, error when adding a card, etc.) The issuer/network/country of the provisioned card (e.g., Mastercard – US) Last 4 digits of the FPAN Last 4 digits of the DPAN (if available) Was this test initiated from the Issuer App? (e.g., yes or no) The type of environment (e.g., sandbox or production) Screenshots or videos of errors and unexpected behaviors (optional). Important: From the logs gathered above, you should be able to determine the cause of the failure from PassbookUIService, PassKit or PassKitCore, and by filtering for your SEID or bundle ID of your app or app extensions in the Console app. Submitting your feedback Before you submit to Feedback Assistant, please confirm the requested information above is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Apple Pay client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

We’re sending PTT notifications from our server and are receiving HTTP 403 from APNs for certain phones with the reason field BadEnvironmentKeyInToken. I can’t find this reason documented in Apple’s public error list. I’d like to confirm what this error specifically means and how to resolve it. Any guidance or clarification would be greatly appreciated. Thank you. Here is the document I was referring to. https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html