XCUISiriService activation refused with “No network” in iOS 26.5 Simulator

Question

Created 2d

Replies 1

Boosts 0

Participants 1

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 SASRequestSourceTesting

No 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.

Answer 1 · 2d

PlazaDelPradoSupport OP

2d

Follow-up: could Apple clarify the supported testing boundary before we change our test methodology?

In https://developer.apple.com/forums/thread/840302, the author reports receiving an October 24 Apple Feedback response saying "SFSpeechRecognizer is not supported on Simulator." I understand that SFSpeechRecognizer is a different API from our reproducer.

Our test instead calls XCUISiriService.activate(voiceRecognitionText:) with an already recognized text string. That string reached the testing activation path, after which SpringBoard logged:
"No network. Not starting the request for SASRequestSourceTesting"

Could Apple please clarify:

Is this public, text-driven XCUISiriService path supported for ordinary classic Siri requests on a native Apple silicon iOS 26.5 Simulator with Xcode 26.6? Our original environment and evidence are described above.
If it is supported, which documented prerequisite or public diagnostic distinguishes the cause of this specific request-start network refusal? The later, separate URLSession HTTPS success does not establish Siri endpoint reachability or the original failure's cause.
If it is unsupported or limited, what Apple-supported physical-device workflow and public automation APIs should we use for end-to-end Siri testing, and which parts can reliably remain Simulator tests?

Apple's CarPlay Simulator documentation separately excludes Siri testing:
https://developer.apple.com/documentation/carplay/using-the-carplay-simulator
We are keeping that CarPlay limitation distinct from support for the standalone XCUISiriService text call.

This distinction materially affects our testing methodology. We would appreciate an explicit support statement for the text-driven path rather than assuming that the SFSpeechRecognizer limitation also applies. No additional Siri activation has been performed.