“DTiPhoneSimulatorErrorDomain Code 2”

We are implementing a Platform SSO extension on macOS and are seeing repeated registration notifications from AppSSOAgent for the same unresolved registration state. We are trying to understand whether this is expected Platform SSO behavior, or whether our extension should be returning a different registration result for a cancelled user-registration flow. Scenario 1: Setup Assistant / preboot cancellation Device registration succeeds during setup. User registration starts. The user closes/cancels the registration web auth UI. Setup completes and the user reaches the desktop. Two “registration required” notifications are posted a few seconds apart, before the user clicks anything. In AppSSOAgent logs, we see two separate cycles like: resetRegistrationWithCompletion handleUserRegistrationForUser:repair:newPasswordUser:newSmartCardUser:notified:profile: Sending registration notification Adding notification request ... then again roughly 10–12 seconds later, before any user action. In some runs

1. Does the important description for silent notification in the documentation still valid? (Pushing background updates to your App) The system treats background notifications as low priority: you can use them to refresh your app’s content, but the system doesn’t guarantee their delivery. In addition, the system may throttle the delivery of background notifications if the total number becomes excessive. The number of background notifications allowed by the system depends on current conditions, but don’t try to send more than two or three per hour. I would like to implement notification that would wake up my application in all state to perform AVSpeechSynthesizer, but I am confused with the availability of the silent notification. I attempted to send silent notification to my ipad to see the exact behaviour, but it seems like it has not been throttle even after a few tens attempts within the same hour. { aps: { content-available: 1, alert: { title: Title, body: Content}, sound: default } } 2.

When FamilyActivityPicker is used as an embedded view (not via the .familyActivityPicker sheet modifier), the search bar that normally appears at the bottom is not rendered on iPad. The same code shows the search bar correctly on iPhone. Environment Frameworks: SwiftUI, FamilyControls Device: iPad (reproduces on multiple models / iPadOS versions — 26.2, 26.5) iPhone: search bar appears as expected Usage The picker is placed directly inside a SwiftUI view hierarchy: import SwiftUI import FamilyControls struct ContentView: View { @State private var selection = FamilyActivitySelection() var body: some View { FamilyActivityPicker(selection: $selection) } } Expected A search field is visible at the bottom of the sheet (same as iPhone), allowing the user to search for apps/categories/websites. Actual On iPad, no search field is rendered. The picker only shows the category/app list. There is no way to search. Notes I would like the embedded FamilyActivityPicker to show the same search affordance on iPad tha

I applied for the Apple Developer Program as an organization (Xentrix Code LLC) over a month ago. I have completed all requirements including D-U-N-S verification. The status is still showing “Pending Review” with no updates. I have already contacted support via email but received no response. Has anyone faced this issue or found a way to escalate it?

Cannot complete enrollment from Turkey — 2 weeks no response

All of a sudden both our development and production app stopped loading products for the subscription screens. Within our code I noticed that product.products is always returning 0 elements even after confirming product ids are correct and ensuring all agreements in App Store Connect are signed and active. What could be the issue?

For some reason since iOS 26.5, a ControlWidgetButton or a Button in a widget configured with an AppIntent conforming to OpenIntent fails to receive its AppEnum parameter correctly if the intent and enum are defined inside a shared Swift Package. Tapping the control widget button opens the main application, but it doesn't pass the AppEnum parameter value in, leaving the app on its default screen instead of navigating to the intended view. This was working perfectly in iOS 26.4, where the app would launch and receive the correct enum case from the intent. No code, configuration, or scheme changes were made between the two runs, only the simulator/OS version differs. Has anyone else run into what seems to be a regression on iOS 26.5? I filed feedback with a sample project: FB22848510

I’m implementing an Apple AssistiveTouch eye tracker accessory for iPad over USB-C using iAP2 plus native HID Gaze Point reports. Current state: iAP2 authentication succeeds identification succeeds StartNativeHID is received AssistiveTouchInformation(IsEnabled=true) is received iPadOS enumerates the HID interface and consumes the interrupt IN reports The remaining issue is that the gaze-point behavior is not interpreted as direct screen coordinates. Repeated fixed gaze inputs produce deterministic but incorrect cursor motion, often appearing like orbiting or projection around a locus rather than stable placement. I have tested: the 119-byte Apple example HID descriptor from the Accessory Interface Specification two report-1 layouts: timestamp + x + y status + timestamp + x + y normalized and physical coordinate scaling verified on the wire that the intended report bytes are sent and consumed iPad console logs show internal model point (HID r) values and multiple derived Pointer positions for a single