Post

Replies

Boosts

Views

Activity

XCUISiriService activation refused with “No network” in iOS 26.5 Simulator
I am seeking a supported public diagnostic or prerequisite for a standalone Siri UI test. Feedback: FB25377231. Developer Technical Support directed this question to the forums. Environment: Mac mini (2024), Apple M4, 32 GB, native arm64 macOS 26.7.2 (25G332) Xcode 26.6 (17F113), iOS Simulator SDK 26.5 iPhone 17 Pro Simulator; the original test's xcresult identifies iOS 26.5 (23F73) Classic Siri, en-GB A small test-host project compiled and ran one selected XCTest case. Its core public API call was: XCUIDevice.shared.siriService.activate( voiceRecognitionText: "What is two plus two?" )The exact recognition text reached the testing activation path, but SpringBoard logged: No network. Not starting the request for SASRequestSourceTestingNo arithmetic answer appeared during the configured 30-second wait. This was observed once; a repeatable frequency is not established. This reproducer has no product app, app-specific Siri intent, or CarPlay integration. In the original Simulator test runner, the first unconstrained NWPathMonitor callback was satisfied, with en0/wiredEthernet, but supportsIPv4, supportsIPv6, and supportsDNS were all false. Default-route SCNetworkReachability samples reported reachable. A separate, later diagnostic used the same simulated device with the installed iOS 26.5 (23F77) runtime. Identical public Foundation/Network helpers on the host and Simulator each issued one URLSession HEAD request to: https://www.apple.com/library/test/success.html Both received HTTP 200. The Simulator helper's initial path callback again reported satisfied with IPv4/IPv6/DNS capability flags false. This proves a response only for that helper/API/URL/time. It does not prove that the flags stayed false, that a fresh DNS lookup occurred, that Siri endpoints were reachable, or that the earlier 23F73 failure had the same cause. A setup confounder may matter: additional iOS platform support, including runtime 23F77, was installed while the original 23F73 Simulator remained booted. The arithmetic test ran afterward but still reported 23F73 in xcresult. The later HTTPS control ran separately on 23F77. There has been no further Siri activation. What supported Simulator/XCUISiriService prerequisite or public diagnostic can distinguish the cause of this specific request-start refusal? Is it expected for this configuration, a known issue, or evidence of an unmet prerequisite? The complete original results and a minimal test-host project are retained. Selected evidence and source are already attached to FB25377231; the same material can be supplied privately to DTS. I am seeking a supported approach rather than private preferences, service overrides, or repeated test requests.
0
0
21
3h
XCUISiriService activation refused with “No network” in iOS 26.5 Simulator
I am seeking a supported public diagnostic or prerequisite for a standalone Siri UI test. Feedback: FB25377231. Developer Technical Support directed this question to the forums. Environment: Mac mini (2024), Apple M4, 32 GB, native arm64 macOS 26.7.2 (25G332) Xcode 26.6 (17F113), iOS Simulator SDK 26.5 iPhone 17 Pro Simulator; the original test's xcresult identifies iOS 26.5 (23F73) Classic Siri, en-GB A small test-host project compiled and ran one selected XCTest case. Its core public API call was: XCUIDevice.shared.siriService.activate( voiceRecognitionText: "What is two plus two?" )The exact recognition text reached the testing activation path, but SpringBoard logged: No network. Not starting the request for SASRequestSourceTestingNo arithmetic answer appeared during the configured 30-second wait. This was observed once; a repeatable frequency is not established. This reproducer has no product app, app-specific Siri intent, or CarPlay integration. In the original Simulator test runner, the first unconstrained NWPathMonitor callback was satisfied, with en0/wiredEthernet, but supportsIPv4, supportsIPv6, and supportsDNS were all false. Default-route SCNetworkReachability samples reported reachable. A separate, later diagnostic used the same simulated device with the installed iOS 26.5 (23F77) runtime. Identical public Foundation/Network helpers on the host and Simulator each issued one URLSession HEAD request to: https://www.apple.com/library/test/success.html Both received HTTP 200. The Simulator helper's initial path callback again reported satisfied with IPv4/IPv6/DNS capability flags false. This proves a response only for that helper/API/URL/time. It does not prove that the flags stayed false, that a fresh DNS lookup occurred, that Siri endpoints were reachable, or that the earlier 23F73 failure had the same cause. A setup confounder may matter: additional iOS platform support, including runtime 23F77, was installed while the original 23F73 Simulator remained booted. The arithmetic test ran afterward but still reported 23F73 in xcresult. The later HTTPS control ran separately on 23F77. There has been no further Siri activation. What supported Simulator/XCUISiriService prerequisite or public diagnostic can distinguish the cause of this specific request-start refusal? Is it expected for this configuration, a known issue, or evidence of an unmet prerequisite? The complete original results and a minimal test-host project are retained. Selected evidence and source are already attached to FB25377231; the same material can be supplied privately to DTS. I am seeking a supported approach rather than private preferences, service overrides, or repeated test requests.
Replies
0
Boosts
0
Views
21
Activity
3h