I am declaring a DatePicker in a SwiftUI view in my app as follows: DatePicker("Date Selected", selection: $selectedDate, displayedComponents: [.date]) .accessibilityIdentifier("DatePicker") .datePickerStyle(.compact) After many wasted hours, I have managed to write a UI test which taps on the DatePicker to reveal the calendar-style popup, chooses the desired date in the popup and then dismisses the popup, as follows: // 1. Show the DatePicker popup application.datePickers["DatePicker"].tap() // 2. Choose a date in the popup application.datePickers.collectionViews.buttons["Friday, January 14"].tap() // 3. Dismiss the DatePicker popup application.datePickers["DatePicker"].tap() This is working for me on iOS 15.2 devices. I have put together a minimal SwiftUI app which demonstrates this here.

I get this error when my Build Location Xcode preference is set to Custom -> Relative to Workspace. Changing my Build Location Xcode preference to Unique (i.e. the Build Location is in a unique subfolder of Xcode's Derived Data location) makes the error go away. I wish I could keep my Build Location as Relative to Workspace! In some projects, despite changing my Build Location Xcode preference, I had to do a one-time manual deletion of the old build directory before the clean started working in the new build directory.

I am grateful to MobileTen and eskimo for their suggestions and advice in this thread 🙏 MobileTen's three suggestions didn't quite fit my setup but the first one gave me confidence in the solution that I had been converging towards. The best solution that I have been able to come up with is as follows: Create a new dynamic framework DF. Link DF to StaticLibrary with the -all_load linker flag. Link App, DynamicFramework1 and DynamicFramework2 to DF instead of StaticLibrary. The linking structure, in pictorial form, of this solution is as follows: App |--> DF1 --> DF --> SL |--> DF2 --> DF --> SL |--> DF --> SL For a minimal but concrete Xcode project that demonstrates this setup, see here. If somebody can suggest a better solution which does not involve housing the static library's symbols within a dynamic framework, I am open to it.