Description The Shortcut Automation Trigger Transaction frequently times out, ultimately causing the shortcut automation to fail. Please see the attached trace for details. Additionally, the Trigger is activated even when the Transaction is declined. Details In the trace I see the error: [WFWalletTransactionProvider observeForUpdatesWithInitialTransactionIfNeeded:transactionIdentifier:completion:]_block_invoke Hit timeout waiting for transaction with identifier: <private>, finishing. Open bug report: FB14035016

My app is in the final stages of testing for release in two days. We did a preorder campaign, and implemented a preorder bonus by checking the preorderDate field returned from the verification result returned by the AppTransaction.shared. This worked well at the time of implementation and initial testing. Now, our QA team is reporting that the preorder bonus is not popping up for them, and we have confirmed it on the developer side that the StoreKit back end is no longer returning a valid preorderDate even though the app is clearly preordered when you check it on the app store. The developer accounts are in the US and App Store Connect clearly shows the US status as preorder. Are there any circumstances where preorderDate might be nil even if the user's app store shows preorder? Any other way we can proceed here? We can message our users that we are going to have to delay a preorder bonus on iOS, but eventually we need to get to a solution that doesn't involve us entering in all our iOS preorders by hand to give them a bonus item.

I'm building out a live activity that has a button which is meant to update the content state of the Live Activity. It calls a LiveActivityIntent that runs in the app process. The push server starts my live activity and the buttons work just fine. I pass the push token back to the server for further updates and when the next update is pushed by the server the buttons no longer work. With the debugger I'm able to verify the app intent code runs and passes the updated state to the activity. However the activity never updates or re-renders. There are no logs in Xcode or Console.app that indicates what the issue could be or that the update is ignored. I have also tried adding the frequent updates key to my plist with no change. I'm updating the live activity in the LiveActivityIntent like this: public func perform() async throws -> some IntentResult { let activities = Activity<WidgetExtensionAttributes>.activities for activity in activities { let currentState = activity.content.state let currentIndex = currentState.pageIndex ?? 0 let maxIndex = max(0, currentState.items.count - 1) let newIndex: Int if forward { newIndex = min(currentIndex + 1, maxIndex) } else { newIndex = max(currentIndex - 1, 0) } var newState = currentState newState.pageIndex = newIndex await activity.update( ActivityContent( state: newState, staleDate: nil ), alertConfiguration: nil, timestamp: Date() ) } return .result() } To sum up: Push to start -> tap button on activity -> All good! Push to start -> push update -> tap button -> No good...

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.

I've encountered an issue where we need multiple domain associations with separate Apple Pay implementations. Briefly, we have a /.well-known/apple-developer-merchantid-domain-association already setup with Stripe, and now we need another, different version of the file to get setup with FreedomPay. FreedomPay insists this file represents a three-way relationship between all parties and I have no reason to disbelieve them. I'm wondering if anyone has encountered this or if there is a standard procedure. I'm currently trying to find documentation on the exact way Apple Pay verification interacts with this file to see if we can produce it dynamically.

Some of the users of my app reported that, the widgets cannot be loaded, event after restarts and re-installs. It seems that it is not rare, I have tens of reports on this (and probably much more who didn't report). It seems the widget is blank even on the gallery screen while you are first adding it: struct SingleWidgetProvider: AppIntentTimelineProvider { @Environment(\.widgetFamily) var family private let viewModel: WidgetViewModel = WidgetViewModel() func placeholder(in context: Context) -> SingleEntry { SingleEntry(date: Date(), habit: .singleSample) } func snapshot(for configuration: SingleWidgetConfigurationIntent, in context: Context) async -> SingleEntry { guard let habit = Array(PersistenceManager.shared.retrieveHabitList().habits).first else { return SingleEntry(date: Date(), habit: .singleSample) } let displayable = viewModel.displayableFromHabit(habit, separateComponents: true, secondOffset: 0) return SingleEntry(date: Date(), habit: displayable) } func timeline(for configuration: SingleWidgetConfigurationIntent, in context: Context) async -> Timeline<SingleEntry> { var entries: [SingleEntry] = [] guard let counter = configuration.currentCounter else { return Timeline(entries: [SingleEntry(date: Date(), habit: .singleSample)], policy: .atEnd) } guard let habit = PersistenceManager.shared.retrieveHabit(habitKey: counter.id) else { return Timeline(entries: [SingleEntry(date: Date(), habit: .singleSample)], policy: .atEnd) } let currentDate = Date() for secondOffset in 0 ..< 100 { let displayable = viewModel.displayableFromHabit( habit, separateComponents: true, secondOffset: secondOffset, symbolName: habit.habitSymbol?.name ?? "", overrideColor: configuration.currentColor.color, overrideButtonVisibility: configuration.currentButtonVisibility, overrideDisplayOption: configuration.currentDisplayOption ) let entryDate = Calendar.current.date(byAdding: .second, value: secondOffset, to: currentDate)! let entry = SingleEntry(date: entryDate, habit: displayable) entries.append(entry) } return Timeline(entries: entries, policy: .atEnd) } } struct SingleEntry: TimelineEntry { let date: Date let habit: HabitDisplayable } static var singleSample: HabitDisplayable { return HabitDisplayable(habitKey: nil, title: LS("sampleWidgetHabitTitle"), dates: [Date(timeIntervalSince1970: 1507158360)], displayOption: .dayMonthYear, secondOffset: 0, separateComponents: true) } func displayableFromHabit( _ habit: Habit, separateComponents: Bool, secondOffset: Int, symbolName: String = "", overrideColor: Color? = nil, overrideButtonVisibility: WidgetButtonVisibility? = nil, overrideDisplayOption: WidgetDisplayOption? = nil ) -> HabitDisplayable { let latestDates: [HabitDate] let displayOption: DisplayOption if let overrideDisplayOption { if overrideDisplayOption == .sameAsCounter { displayOption = habit.settings?.toValue.displayOption ?? .dayMonthYear } else { displayOption = DisplayOption(rawValue: overrideDisplayOption.rawValue - 1) ?? .dayMonthYear } } else { displayOption = habit.settings?.toValue.displayOption ?? .dayMonthYear } let displayMode = displayOption.mode switch displayMode { case .timePassed, .date: latestDates = PersistenceManager.shared.latestDate(habit: habit).map { [$0] } ?? [] case .activity: latestDates = PersistenceManager.shared.retrieveHabitDates(habit: habit, limitDate: displayOption.limitDate()) } let displayButton: Bool if let overrideButtonVisibility { if overrideButtonVisibility == .sameAsCounter { displayButton = habit.settings?.toValue.buttonType == .onRow } else { displayButton = overrideButtonVisibility == .show } } else { displayButton = false } return HabitDisplayable( habitKey: habit.habitKey, title: habit.title, dates: latestDates.map { $0.date }, displayOption: displayOption, secondOffset: secondOffset, separateComponents: separateComponents, color: overrideColor ?? habit.habitColor?.color ?? .appPrimary, symbolName: symbolName, displayButton: displayButton ) } I provided a large portion of my code, let me know if you need more. The strange thing here is, even if the DB connection is broken somehow, it should have shown the default option (singleSample). I am not able to reproduce/fix this for months now, so any help is very appreciated.

Since January 28, 2026, we’ve noticed an increase in StoreKit-related errors during purchase flows. Specifically, we’re seeing a spike in errors reported as “Unable to Complete Request”, categorized as unknown StoreKit errors. This correlates with a noticeable drop in the overall purchase success rate. A few observations: The issue is not limited to the latest app version, it also affects older versions. It appears to occur only on iOS 17+. The impact seems country-specific: some regions are affected more heavily, while others show no significant change compared to previous days. At the moment, there are no related incidents reported on Apple’s System Status page. Given these symptoms, this looks like a potential StoreKit / Apple API issue, but we haven’t found any official confirmation yet. Has anyone else observed similar StoreKit behavior recently on iOS 17+? Any insights or known issues would be greatly appreciated.

Description Our NETransparentProxyProvider system extension maintains a persistent TLS/DTLS control channel to a security gateway. To maintain this stateful connection the extension sends application-level "Keep Alive" packets every few seconds (example : 20 seconds). The Issue: When the macOS device enters a sleep state, the Network Extension process is suspended, causing our application-level heartbeat to cease. Consequently, our backend gateway—detecting no activity—terminates the session via Dead Peer Detection (DPD). The problem is exacerbated by macOS Dark Wake cycles. We observe the extension's wake() callback being triggered periodically (approx. every 15 minutes) while the device remains in a sleep state (lid closed). During these brief windows: The extension attempts to use the existing socket, finds it terminated by the backend, and initiates a full re-handshake. Shortly after the connection is re-established, the OS triggers the sleep() callback and suspends the process again. This creates a "connection churn" cycle that generates excessive telemetry noise and misleading "Session Disconnected" alerts for our enterprise customers. Steps to Reproduce Activate Proxy: Start the NETransparentProxyProvider and establish a TLS session to a gateway. Apply Settings: Configure NETransparentProxyNetworkSettings to intercept outbound TCP/UDP traffic. Initialize Heartbeat: Start a 20-second timer (DispatchSourceTimer) to log and send keep-alive packets. Induce Sleep: Put the Mac to sleep (Apple Menu > Sleep). Observe Logs: Monitor the system via sysdiagnose or the macOS Console. Observation: Logs stop entirely during sleep, indicating process suspension. Observation: wake() and sleep() callbacks are triggered repeatedly during Dark Wake intervals, causing a cycle of re-connections. Expected Behavior We seek to minimize connection turnover during maintenance wakes and maintain session stability while the device is technically in a sleep state. Questions for Apple Is it possible to suppress the sleep and wake callback methods of NETransparentProxyProvider when the device is performing a maintenance/Dark Wake, only triggering them for a full user-initiated wake? Is it possible to prevent the NETransparentProxyProvider process from being suspended during sleep, or at least grant it a high-priority background execution slot to maintain the heartbeat? If suspension is mandatory, is there a recommended way to utilize TCP_KEEPALIVE socket options that the kernel can handle on behalf of the suspended extension? How can the extension programmatically identify if a wake() call is a "Dark Wake" versus a "Full User Wake" to avoid unnecessary re-connection logic?

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.