Hey All, My company has submitted no less than four requests over the last couple months trying to get approved to use the advanced commerce API. We have an approved app version, provided the product ID for what we want to use it for, just have never heard back. Anytime we call apple support, they take the submission ID and escalate it, then its radio silence from there. Wanted to see if anyone ran into this issue and how they got around it. We have been waiting around 2 months to be approved. Have not received a rejection, update, or anything that could shed some light into whats going on. Any pointers/help on this would be greatly appreciated!

Hello, I'm working on a project for a file system using FSKit and I'm currently experiencing a strange issue on macOS 26 to which I updated recently. While testing, I'm doing incremental debug builds using Xcode. I'm very careful to make sure I only have a single instance of the built app (hosting the file system extension) anywhere on disk. I run the app, mount the file system, run some tests, unmount, kill the app, make changes, and repeat. Once in a while, however, mount would suddenly start failing with mount: Loading resource: The operation couldn’t be completed. (com.apple.extensionKit.errorDomain error 2.) mount: File system named MyFS not found This would consistently repeat until I clean the build folder, rebuild and run again. I would continue testing for a while, then at some point mount would start failing again. I looked at the system logs and found this message from extensionkitservice: Failed to initialize _EXExtensionIdentity: Error Domain=com.apple.extensionKit.errorDomain Code=5 "Failed to find extension: 24B7F729-5AD1-4486-92B4-1F57CACCA265" So I started going through the logs in more detail and found the following: lsd seems to unregister and register the file system extension occasionally, each time giving it a different UUID. I can see logs about "com.apple.LaunchServices.pluginsregistered" and "com.apple.LaunchServices.pluginsunregistered" notifications being sent with their data. What seems to be the problem is that sometimes after this happens, when I attempt to mount the file system, the extensionkitservice would fail to find the extension because it is referencing it using one of its previous UUIDs assigned by lsd, not its latest one, judging by the UUID in the log message. Am I doing something wrong here? I think I may be causing the constant unregister/register of the extension idirectly by rebuilding via Xcode. Or is it a problem with extensionkitservice? I've never had this happen on Sequoia. macOS 26.0.1 (25A362); Xcode 26.0.1 (17A400) Thank you

We have 1 renewable subscription and 1 nonrenewable subscription which, as of yesterday, are in the approved state. I'm not even sure how they were approved because the Product.products(for: Self.productIDs) call is returning an empty array in production. We have the paid agreement signed, a valid bank account added, and everything else that is required. The product IDs being passed are correct. But the API is still returning an empty array. Is there some sort of system issue happening right now?

Summary Our Share Extension works correctly on iOS 18 but silently fails on iOS 26. The app appears in the share sheet, the user taps it, the sheet dismisses — and nothing else happens. The containing app never opens. Environment App: com.yourcompany.app Extension: com.yourcompany.app.shareaudio (com.apple.share-services) Source app: Voice Memos Deployment target: iOS 17.0 iOS 18.x (TestFlight): ✅ works — extension runs, app opens, file imports iOS 26.x (same build): ❌ fails — share sheet closes, extension appears to terminate immediately What we've tried Activation rule — NSExtensionActivationRule with UTI-CONFORMS-TO covering com.apple.quicktime-audio, public.audio, public.mpeg-4-audio, com.apple.m4a-audio, public.file-url. Loading the file — tried loadFileRepresentation(forTypeIdentifier:), loadInPlaceFileRepresentation, and loadItem, with fallbacks prioritizing public.file-url and com.apple.quicktime-audio. Logged registeredTypeIdentifiers to confirm what the provider exposes. Opening the containing app — calling extensionContext?.open(url) before completeRequest. Also tested a secondary URL scheme. App Group is configured; we write a pending flag and check it in sceneDidBecomeActive. Voice Memos export modes — tested both Rendered (.m4a) and Editable (.qta). None of this changed the behavior on iOS 26. Specific questions What does NSItemProvider.registeredTypeIdentifiers return on iOS 26 for Voice Memos recordings, especially .qta files? Is com.apple.quicktime-audio still the correct UTI for .qta on iOS 26, or has it changed? Has the recommended API for loading shared audio changed in iOS 26 — loadFileRepresentation, loadInPlaceFileRepresentation, or loadItem? Is NSExtensionContext.open(_:completionHandler:) still the supported way to open the containing app from a Share Extension on iOS 26? Are there new entitlements or restrictions? Is there any WWDC25 session or updated documentation covering Share Extensions receiving Voice Memos exports (including AVFileType.qta)? Is this a known regression in iOS 26? Happy to share logs, a TestFlight build, or a minimal reproducible project if that helps.

High Power Mode setting is not applied by powerd (possibly related to migrateenergyprefs) Summary On a MacBook Pro (14-inch, M5 Max), enabling High Power Mode in System Settings has no effect on the actual power governor. The system continues to run at the default (Automatic-equivalent) power ceiling regardless of the High Power Mode setting. The same symptom has been reproduced on a different physical machine, a MacBook Pro (M4 Max), ruling out a single hardware defect. Environment Affected device: MacBook Pro 14-inch (Apple M5 Max, 12P+6S+40GPU, 128GB RAM) macOS version: macOS 26.5.1 (Build 25F80) Migration history: Intel Mac → MacBook Air (M2) → MacBook Pro (M4 Max) → MacBook Pro (M5 Max), using Migration Assistant at each step Same symptom also confirmed on the MacBook Pro (M4 Max), which had the same migration history Symptom Selecting "High Power" under System Settings → Battery → Power Mode has no effect on system_profiler SPPowerDataType, which always reports High Power Mode: No. pmset -g custom correctly shows powermode 2 (the High Power equivalent) for AC Power, confirming the user-facing setting is being written correctly. Low Power Mode in the same system_profiler output correctly toggles between Yes/No depending on the UI selection (Automatic / Low Power / High Power). Only High Power Mode fails to track the UI selection. Benchmarking with 3DMark Steel Nomad Stress Test (Metal API) reproduces the score pattern that third-party reviews report for High Power Mode OFF (stabilized score ~3100–3400), rather than the ON pattern reported for the same model (~3600+). This confirms the issue is not just cosmetic (a wrong status string) but reflects an actual difference in the power ceiling being enforced. Investigation steps taken 1. Preference file inspection Inspected /Library/Preferences/com.apple.PowerManagement.<UUID>.plist. Multiple UUID-keyed files exist, each corresponding to a previously used device (identified by battery serial number in the BatteryWarn key). All of them contained HighPowerMode = 0, including the file matching the current machine's serial number. The MacBook Air (M2) used earlier in this device's migration history does not support High Power Mode at all. It's suspected that HighPowerMode = 0 originated from that device and was carried forward through subsequent Migration Assistant transfers to devices that do support the feature, without ever being correctly re-evaluated. 2. Direct write test Used defaults write to directly set HighPowerMode = 1 in the relevant plist. system_profiler then reported High Power Mode: Yes, and this persisted across a reboot. However, a subsequent benchmark run showed no improvement — powermetrics Combined Power remained in the 27–30W range, and the Steel Nomad Stress Test stabilized score actually dropped slightly (~3134 average over the last 10 loops). This indicates the displayed value is decoupled from the actual power governor state. 3. File deletion / regeneration test Deleted the UUID-keyed plist (after backing it up) and let powerd regenerate it from scratch. The newly generated file still showed HighPowerMode stuck at No and unresponsive to UI changes, while LowPowerMode continued to track UI changes correctly. The same test was repeated with the non-UUID common file (com.apple.PowerManagement.plist), with no change in behavior. This rules out stale/corrupted preference data as the root cause. 4. Binary-level investigation Searched the system for files containing the string "HighPowerMode". Aside from unified logging symbol caches (uuidtext, not relevant), the following were found: /System/Library/CoreServices/powerd.bundle/powerd (Apple-signed, Signed Time: Apr 19, 2026, Platform identifier 26) /System/Library/CoreServices/powerd.bundle/migrateenergyprefs.bundle/ (com.apple.migrateenergyprefs, LSMinimumSystemVersion 26.5, built with Xcode 2630) /System/Library/SystemProfiler/SPPowerReporter.spreporter/ /System/Library/ExtensionKit/Extensions/BatterySettingsIntentsExtension.appex/ The presence of a dedicated com.apple.migrateenergyprefs component strongly suggests this is the code path responsible for carrying power preferences across device migrations. We suspect this migration logic fails to correctly initialize or re-evaluate HighPowerMode when migrating from a device that doesn't support the feature to one that does. Reproducibility Reproduced on two distinct physical machines (M4 Max and M5 Max), making a hardware fault unlikely. Reproduced after deleting and regenerating the preference files, ruling out simple cache corruption. Reproduced after a full reboot, ruling out a transient in-memory state issue alone. Impact Because High Power Mode is not actually engaged, sustained CPU/GPU performance under heavy load is capped at a lower power ceiling than intended, resulting in measurably lower benchmark scores and sustained performance compared to the documented behavior of the same hardware configuration. Questions for Apple Could the com.apple.migrateenergyprefs logic be reviewed for how it handles HighPowerMode when migrating from a device that does not support the feature (e.g., MacBook Air M2) to one that does? Is there a known issue with HighPowerMode specifically (as opposed to LowPowerMode, which behaves correctly) not being written back by powerd in response to UI changes? Are there other users with a similar multi-generation Migration Assistant history reporting the same symptom? Happy to provide a sysdiagnose or additional logs if useful.

We're experiencing an issue where push notifications are not being received on certain iOS devices, and we'd like help identifying the possible causes. What we've confirmed so far: Push notifications are sent from our own provider server to APNs. APNs returns a normal response (HTTP/2 200) The device tokens are valid and up to date. Affected users have confirmed that notifications are enabled for our app in Settings. Users report no network connectivity issues. We are sending with apns-priority: 10 and apns-push-type: alert. Scope: This is occurring for multiple users, not isolated to a single device. It happens intermittently — some notifications from the same campaign reach the device, while others don't. Critically, some affected users report that they only fail to receive notifications from our app during certain specific time windows, while notifications from other apps arrive normally during the same period. This suggests the issue is app-specific and time-correlated, rather than a device-wide or network-level problem. Questions we'd like help with: Given that APNs returns 200, are there known scenarios where the notification still doesn't reach the device? (e.g., Focus / Do Not Disturb, low power mode, high-frequency throttling, stored-then-discarded due to apns-expiration) Is there a recommended way to obtain per-notification delivery status in the production environment? Are there known limits on how many notifications can be sent to the same device within a short window before APNs starts throttling or coalescing them? Our server logs currently do not retain the apns-id returned by APNs. If we provide the affected device tokens along with the approximate send timestamps, would it be possible for Apple to help investigate the delivery status of those notifications on the APNs side? Any guidance or pointers to relevant documentation would be greatly appreciated. Thank you!

model : iphone 17 ios version: 26.2 app used: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps Here is our observation when we tried to make wifi aware connection between iphone and our wifi device. note : we used iphone as subscriber ( view simulation) 1.pairing & bootstrapping was successfully done 2.Data path was successfully established between iphone and our device. after data path establishment ,within few seconds , DATA PATH TERMINATION was sent from iphone which leads to pairing verification with new NMI address. Same behaviour is noticed even when we try to establish connection between two iphone devices. Here we have few questions. Once we establish data path , Why iphone initiates data path termination instead using the same service for data path exchange. 2.Why do we go for PAIRING VERIFICATION everytime.

Since July 25, multiple production users have been unable to load previously saved records from a CloudKit private database. The query uses CKQueryOperation with: Record type: UserAnLi Predicate: category_sub_id == "1401" Sort descriptor: creationDate descending Results limit: 20 The requests consistently fail after approximately 10 seconds with: Error domain: CKErrorDomain Error code: 15 (CKErrorServerRejectedRequest) Underlying error: CKInternalErrorDomain Code=2000 HTTP status: 500 CKErrorRetryAfterKey: absent CKErrorShouldThrottleClient: absent Examples from two different users/devices: iOS 18.3.2 RequestUUID: 67890D6B-8076-4135-9635-7DCCFF38D94F OperationID: A796C6799FA69D66 CloudKit partition: 233 Edge response time: 10024 ms iOS 26.6 RequestUUID: 1249FEAE-9D5A-40CB-9076-DAD2D8396BCF OperationID: CEC87546C31D61E2 CloudKit partition: 227 Edge response time: 10086 ms Users are signed in to iCloud, iCloud Drive is enabled, and general network access works normally. According to TN3162, documented CloudKit throttling normally returns CKErrorServiceUnavailable or CKErrorRequestRateLimited with a retry-after value. These failures instead return CKErrorServerRejectedRequest, HTTP 500, and no retry-after information. The issue has been reported through Feedback Assistant: FB24046201 Could this indicate a production CloudKit query/index problem, a server-side query timeout, or an undocumented/misreported throttle? Is there any client-side mitigation, or does this require investigation by the CloudKit backend team?

On the first connection after pairing, our accessory acts as an ANCS client over GATT over BR/EDR. After service discovery, we enable notifications by writing the CCCDs of both the Notification Source and Data Source characteristics. This succeeds, but the iPhone does not send notifications for existing unread notifications. It only sends Notification Source notifications for newly received notifications (for example, new instant messaging notifications), which is the behavior we expect. After disconnecting and reconnecting the BR/EDR connection, our accessory performs the same ANCS initialization sequence and enables the same CCCDs again. If there are a large number of unread notifications on the iPhone (approximately 30 or more), the iPhone immediately starts sending Notification Source notifications for many existing unread notifications. During this process, the GATT over BR/EDR connection becomes unresponsive. Our accessory sends an ATT Write Request to the ANCS Control Point characteristic to retrieve notification attributes. The iPhone HCI log shows that the Write Request is received by the iPhone, but no corresponding ATT Write Response is ever sent. About 30 seconds later, the iPhone disconnects the GATT over BR/EDR L2CAP channel. This issue is reproducible only when there are many unread notifications (approximately 30 or more). If there are only a few unread notifications, the problem does not occur. Expected Behavior The iPhone should continue processing ANCS requests normally regardless of the number of unread notifications. After receiving the ATT Write Request to the ANCS Control Point characteristic, it should return the corresponding ATT Write Response and continue sending Data Source notifications containing the requested notification attributes.

Has anyone run into an expired access grant on Apple Business Register for "Tap to Pay on iPhone for Payment Providers"? Context: I work on a Tap to Pay on iPhone integration at a payment service provider. I was granted access to the PSP section of Apple Business Register roughly six months ago and had been using it without issue. Steps to reproduce: Sign in to register.apple.com with the Apple Account that originally received access. Open the Tap to Pay on iPhone for Payment Providers section. A dialog appears: "Your access to the connection expired. Contact your organization admin to renew your access for Tap to Pay on iPhone for Payment Providers." The dialog only has an OK button. Dismissing it leaves a blank page — there is no renewal link or request option anywhere in the interface. What I've already ruled out: Signed in with the correct Apple Account (not a personal one) Full sign out and sign back in Tested in a different browser with extensions disabled Same result every time. What I'm hoping to learn from anyone who's been through this: Was your Account Holder able to re-grant access to a member directly inside Apple Business Register? If so, roughly where in the interface? Or did it require Apple to restore it on their side — and how long did that take? Is the access window a fixed six months for everyone, and does Apple send any warning before it lapses? I've opened a case with Apple Developer Support in parallel, but I'd like to hear whether others have hit the same wall and what actually resolved it. Thanks.

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.

Overview We are developing a BLE + UWB accessory. We need to initiate UWB ranging as quickly as possible after establishing a BLE connection with an iPhone. However, it consistently takes approximately 900–1000 ms from centralManager(_:didConnect:) until the notification subscription (setNotifyValue) reaches the accessory. Most of this delay does not appear to be caused by ATT throughput or accessory response times, but rather by internal iOS processing. Details (Observed Behavior and Measurements) We tested this by implementing code on the app side to delay calling discoverServices by 1 second, measuring the processing times for both scenarios (with vs. without delay). Elapsed time for each phase measured on the app side (CBPeripheralDelegate): Phase Calling discoverServices immediately after connection Delaying discoverServices by 1 second didConnect → discoverServices call 0.1 ms (1000 ms delay) discoverServices → didDiscoverServices 416 ms 26 ms didDiscoverServices → didDiscoverCharacteristics 90 ms 60 ms Key Observations: The most notable finding is that simply delaying the discoverServices call by 1 second reduces the discoverServices → didDiscoverServices duration from 416 ms to 26 ms. This suggests that iOS is performing some internal processing right after connection, during which ATT service discovery responses appear to be delayed/postponed. Pure ATT discovery (Services + Characteristics) completes in about 86 ms when delayed. The app calls setNotifyValue(true, for:) immediately without delay inside peripheral(_:didDiscoverCharacteristicsFor:error:). However, the accessory receives the CCCD write approximately 400 ms after discovery completes. (Note: This 400 ms is an estimate based on the difference with accessory-side measurements). On the accessory side, completion of the ATT MTU exchange was observed around 380 ms after connection. Hypothesis We hypothesize that during the "first ~1 second after connection," iOS is sequentially executing link-layer control procedures (e.g., Feature Exchange, Version Exchange, Data Length Update, PHY Update) as well as ATT MTU exchange. Because these procedures are processed sequentially, ATT service discovery responses may be deprioritized or queued behind them. We have isolated the issue on the accessory side: the peripheral responds immediately to all requests, confirming that accessory processing delays or ATT throughput limitations are not the cause. Questions Is taking several hundred milliseconds to ~1 second from connection establishment (didConnect) to the completion of service discovery and notification subscription expected behavior in iOS? Is our understanding correct that iOS (CoreBluetooth / Bluetooth Controller) is executing link-layer control procedures during this initial period? If not, what specifically is taking place? Are there any means to shorten this duration from the app side or via peripheral connection parameters? Given the significant difference in response time between calling discoverServices immediately vs. delaying it, is there any way to prioritize ATT traffic right after connection or accelerate these procedures? For accessories that need to begin ranging immediately after connecting, what are the recommended best practices to minimize latency before data communication can start?

Hello, I’m experiencing what appears to be an app-specific Sandbox catalog propagation issue. Environment: Bundle ID: com.auroradrama.app App Store Connect App ID: 6786937298 StoreKit 2 Testing with a Sandbox Apple Account on a physical device An older product can still be fetched successfully: com.heroon.aurora.vip.year However, all newly created products return an empty result from Product.products(for:). Examples: com.auroradrama.pay.en.a.vip.week com.auroradrama.pay.en.a.coin.t1 com.auroradrama.test.coin001 The last product was created manually in the App Store Connect web interface, while the others were created through the App Store Connect API. Therefore, this does not appear to be specific to API-created products. Example result: Bundle ID: com.auroradrama.app Requested products: com.auroradrama.pay.en.a.vip.week com.auroradrama.pay.en.a.coin.t1 Returned product count: 0 Missing product IDs: com.auroradrama.pay.en.a.vip.week com.auroradrama.pay.en.a.coin.t1 I also tested the new product IDs using: Settings → Developer → Sandbox Apple Account → Manage → Initiate Purchase The system reports that the new product IDs are invalid. Therefore, the issue can be reproduced outside of my application code. I have verified through the App Store Connect API that the new products have: READY_TO_SUBMIT state Product versions in PREPARE_FOR_SUBMISSION Localization metadata A price configured for the United States Availability in 175 territories availableInNewTerritories enabled Valid subscription groups and subscription periods where applicable The Paid Applications Agreement, banking information, and tax information are all active. The app has the In-App Purchase capability enabled. Since an older product still works with the same app, Bundle ID, signing configuration, device, Sandbox account, and StoreKit code, these settings appear to be correct. The new products have remained unavailable for more than eight hours, which is well beyond the documented Sandbox metadata propagation period. Has anyone experienced a situation where old products remain available but every newly created product fails to enter the Sandbox StoreKit catalog? Could an Apple engineer please check whether the device-facing Sandbox catalog/index for App ID 6786937298 needs to be reprocessed or re-propagated? I can provide the App Store Connect resource IDs, timestamps, StoreKit logs, and a sysdiagnose privately if needed. Thank you.

We have an iOS app (Alamofire 5.9+, backed by URLSession) that talks to a LAN dashcam: HTTP/1.1 TLS 1.2 The device runs an embedded C HTTPS server Responses commonly include Connection: close (a new TCP connection is opened for each request) From Wireshark, looking at Client Hello, we observe: First connection: full handshake; a Session ID is negotiated Next new TCP connection: Client Hello carries that Session ID and completes an abbreviated handshake (resumption succeeds) After that: the same Session ID is not reused again Questions we want to confirm For TLS 1.2 Session ID resumption (RFC 5246), does iOS / URLSession intentionally allow a cached session to be resumed at most once? Or can the same Session ID be resumed multiple times until it expires / is evicted from the cache? Without changing the overall LAN dashcam product model, how should the server be configured—e.g. moving to TLS 1.3 and/or HTTP/2—so that iOS clients can resume via Session Ticket and/or Session ID multiple times? What we have already ruled out / observed The client already uses a shared long-lived URLSession / Alamofire Session (we do not create a new session per request) The server often returns Connection: close, so each request uses a new TCP connection; we are discussing TLS session resumption across connections, not HTTP keep-alive We occasionally see TLS time of only ~10–20 ms, which suggests at least one successful session resumption has occurred

Hi, Overview I am trying to write a unit test case to buy a storekit product. SKTestSession.buyProduct(identifier: options:) throws the error StoreKit.StoreKitError.notEntitled Testcase Code @Test func example() async throws { let session = try SKTestSession(configurationFileNamed: "VehicleStore") session.disableDialogs = true session.clearTransactions() do { let transaction = try await session.buyProduct(identifier: "nonconsumable.car", options: []) print(transaction) } catch { // Throws StoreKit.StoreKitError.notEntitled print("Error: \(error)") } } Storekit configuration file Note In-App purchases capability is added StoreKit configuration file is used in testcase Environment: macOS 26.5.2 (25F84) Xcode 26.6 (17F113)

I am preparing to save CLLocation data to CloudKit. In the dashboard, when you create a location object, you only can specify lat/long. In the archived CloudKit web services reference, the location dictionary shows more than that is being saved. https://developer.apple.com/library/archive/documentation/DataManagement/Conceptual/CloudKitWebServicesReference/Types.html#//apple_ref/doc/uid/TP40015240-CH3-SW5 However, this is in the archive. I want to know via documentation if all of the current properties of a CLLocation are saved, and if it is reasonable to assume future fields would be too. The documentation was likely archived BEFORE properties like speedAccuracy, courseAccuracy, source, information floor, and ellipsoidal altitude. FB24049646 - CloudKit: Do all properties of CLLocation get persisted in CloudKit when setting a record value as CLLocation - CKWS archive reference Location Dictionary doesn't show new fields (speed/course accuracy, source info, floor, ellipsoidalAltitude)

userlog.txt We've run into some HTTP request errors, details as follows: We're currently at a loss because restarting the app doesn't help, only rebooting the phone restores things to normal. Based on tracking data, the occurrence rate for users is about 0.033%, and it's only happening on iOS, Android is fine. iOS operating system versions: 14-27 are all affected. The same issue appears in Rust, Flutter, and C/C++. Rust： 2026-07-11-19:39:22.252+0800|F4E26069-2D7E-4D5F-8B53-664E012B2CA7|UPLogDefaultLogger|DEBUG|测试模式|1023629905|[userdomain_rust/rust_userdomain/src/operator/device_ops/refresh_device_list_op.rs:61]query_device_list error: HttpRequstFaild(Reqwest(reqwest::Error { kind: Request, url: "https://zj.haier.net/api-gw/wisdomdevice/device/v11/family/devices?familyId=ALL&filterFlag=false", source: hyper_util::client::legacy::Error(Connect, ConnectError("tcp connect error", 36.156.179.34:443, Os { code: 49, kind: AddrNotAvailable, message: "Can't assign requested address" })) })) Flutter： 2026-07-11-15:29:02.718371+0800|b2257ae8-f7d8-41d0-8811-2ff1824f95d9|UpPlugins|ERROR|正常模式|1023629905|level:error tag:smart_home msg:getWholeHousePreferenceSetting err: DioException [unknown]: null Error: SocketException: Connection failed (OS Error: Can't assign requested address, errno = 49), address = zj.haier.net, port = 443 C/C++： 2026-07-11-19:39:15.247588+0800|a991af96-bf02-4b94-a437-d4f7efc249ff|uSDK|ERROR|正常模式|1023629905|[CAE][[cae_sock_no_ssl_last_err:869][connect fd 122 ret -1 err 49: Can't assign requested address] ] Native iOS HTTP interface requests work fine, for example when using AFNetworking. Looking for your help~

This post applies to Apple Virtualization framework feature to setup a user account during VM setup (VZMacGuestProvisioningOptions) introduced in macOS 27: Issue: Creating a user via VZMacGuestProvisioningOptions during VM setup, results in a user which is not returned by CSidentityQueryExecute(). Same code executed on a macOS 26 VM or a macOS 27 VM where the user was created by hand within the VM (so without VZMacGuestProvisioningOptions) returns the user. How to reproduce: Create an VM via the Apple Virtualization framework and use the VZMacGuestProvisioningOptions to create the user during VM setup. I actually used Virtual Buddy and Tart to do this. Then run the following code: internal enum MyLogger { static let info = Logger(subsystem: Bundle.main.bundleIdentifier!, category: "Utils-\(getuid())") } public struct Identity { public let posixUID: id_t public let posixName: String init?(posixUID: id_t, posixName: String) { self.posixUID = posixUID self.posixName = posixName } } class Utils { public static func userIdentities() -> [Identity] { let defaultAuthority = CSGetLocalIdentityAuthority().takeUnretainedValue() let query = CSIdentityQueryCreate(nil, kCSIdentityClassUser, defaultAuthority).takeRetainedValue() guard CSIdentityQueryExecute(query, 0, nil), let identities = CSIdentityQueryCopyResults(query).takeRetainedValue() as? [CSIdentity] else { return [] } for ident in identities { MyLogger.info.log("CSIdentity: \(ident.hashValue, privacy: .public)") } let idents = identities .compactMap { Identity( posixUID: CSIdentityGetPosixID($0), posixName: CSIdentityGetPosixName($0).takeUnretainedValue() as String ) } .sorted { $0.posixName.localizedStandardCompare($1.posixName) == .orderedAscending } for ident in idents { MyLogger.info.log("Identity: \(ident.posixName, privacy: .public), \(ident.posixUID, privacy: .public)") } return idents } } Expected behavior: The code returns the user account created via VZMacGuestProvisioningOptions. Actual behavior: I get no user account When you test the same on a macOS 27 VM where the user is created via the traditional way (Setup assistant), the app shows the account. This also applies to all additional user accounts created after VM setup via System Settings.app. The bug also still exists on a VM created with macOS 27 beta 4. Is anybody having the same issue? Is that a bug in macOS 27? I already created a Feedback for this: FB23716201

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.) Sometimes we have observed that on starting the transparent proxy extension, the startProxy overridden delegate method(override func startProxy(options: [String : Any]?, completionHandler: @escaping (Error?) -> Void) {) in our AppProxyProvider class which is derived from NETransparentProxyProvider being called more than once for the same extension(pid). This leads to Over-resume of an object crash as we invoke setTunnelNetworkSettings inside the startProxy delegate. As this is controlled by the system, we are not sure why this delegate being called more than once sometimes even if we call the start TransparentProxy only once. Note that, this issue is seen only in Mac OS Tahoe. Apple Feedback ticket: FB21464147 (startProxy delegate for NETransparentProxyProvider class is being called twice for the same pid extension sometimes)

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.