Significant Test-time Overhead in isSwiftUI()

[jshier]

Description

In apps where backtraces take more time, perception checks when accessing ObservableState properties can take significant time. In our large production app, each access of an @ObservationStateTracked property takes about 0.08s, due entirely to isSwiftUI(). For States with many properties, this can lead to significant execution time for tests.

Disabling perception checking for the test fixes the performance issue.

Checklist

• I have determined that this bug is not reproducible using Swift's observation tools. If the bug is reproducible using the @Observable macro or another tool from the Observation framework, please file it directly with Apple.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

I would expect perception checks to be off by default for tests, or for isSwiftUI() to otherwise short circuit, as there's no way for SwiftUI symbols to be in the backtrace.

Actual behavior

Significant time is spent in isSwiftUI through the registrars access method.

Steps to reproduce

You can observe this work in any test that accesses tracked state, but it seems to be more noticeable the slower the backtrace call becomes.

Perception version information

2.0.6

Destination operating system

iOS 18.5 Simulator

Xcode version information

16.4

Swift Compiler version information

swift-driver version: 1.120.5 Apple Swift version 6.1.2 (swiftlang-6.1.2.1.2 clang-1700.0.13.5)
Target: arm64-apple-macosx15.0

[mbrandonw]

Hi @jshier, we would be open to disabling the perception checks in tests. Would you like to PR that?

But for the time being I am going to convert this to a discussion because you can always disable these checks in your own tests.

[mbrandonw]

Well we do have extensive tests that show that perception checking works in a variety of situations, and we would want to keep those tests. So this change would need to be made in a way that allows us to keep those tests while letting all other tests skip the checks.

[jshier]

Sure, my issue is that the test suite doesn't currently pass, unless I'm missing something. Until that's fixed I can't really design an API to keep them passing. In fact, the failures seem to be the same regardless of whether or not I add the isTesting check.

On a related note, any preference for ways to force check on, even in tests? I suppose that should be generally possible, not just for the framework itself. I could add another @TaskLocal that could be combined into a (!isTesting || _PerceptionLocals.checkDuringTesting) condition.

[mbrandonw]

The tests should be run on iOS, not macOS. There is a bug in Swift or Xcode where availability checks do not work properly when building tests for macOS.

And yeah, I guess a new task local would be the way to go.

[jshier]

Testing in the iOS sim fails as well. I thought maybe I'd need to test in iOS 16, but Xcode won't even present that as a destination. I see the Makefile uses 18.5, so I'm not sure why mine would be failing as well.

Test swift-perception-Package_2025-09-08T18-32-04.xcresult.zip

[jshier]

Looking at ci.yml, it doesn't look like the unit tests are run in CI, just the example app build.

[pomozoff]

Hi, guys.

Probably I have the same issue - the app hangs a lot when I run it in debug configuration.
The instruments points to func isSwiftUI() -> Bool.

The project I'm working on is a fork of CopilotForXcode.
There are tons of WithPerceptionTracking, so I have no idea where to start fixing the issue.

Could you help me find the source of the bug?

[mbrandonw]

Hi @pomozoff, this is not considered a bug in the library. There is room for improvement, and we'd happily accept help to improve things, but it's not a bug. If you rather not have any perception checking in your app you can always disable it entirely.

Also, this issue is specifically about disabling perception checking in tests. If you'd like to discuss the performance of perception checking in general you should start a new discussion.

And @jshier, did you still want to submit a PR to disable perception checking in tests? I'm realizing there's a simpler approach than what we discussed earlier. You could have the default be based off of !isTesting, and then use a test scope trait to re-enable perception checking for all tests.

[pyrtsa]

You could have the default be based off of !isTesting, and then use a test scope trait to re-enable perception checking for all tests.

A PR with that very change would be most welcome! Keep forgetting to disable perception checks in new tests and wondering the slowdown every time. 😅

[pomozoff]

Ok, thanks

I'll try to investigate the issue, and then start a new discussion if needed

[stephencelis]

@pomozoff Want to give #165 a try and see if it helps?

[pomozoff]

@stephencelis, sorry for the delay. I have solved my issues just setting as same dependencies versions as they are in the original repo. There are no more unexpected freezes in my project since then.
But, thank you pointed me to the optimization, I'll keep it in mind in case of next deps updates.