I’m migrating some XCTest cases to Swift Testing and hit a runtime error when using tuple arguments within the CI. I don't have an issue when running locally. [2025-08-21 14:22:13.493] [unit_tests] [WARNING] Could not find test status list for -[FooManagerTests testEndpoint(region:enforce:expectedEndpoint:)] [2025-08-21 14:22:18.054] [unit_tests] [ERROR] not enough values to unpack (expected 2, got 1) ##[error]Failed to complete Unit Tests -> not enough values to unpack (expected @Test("Telemetry endpoint routing", arguments: [ (TelemetryRegion.value1, false, Foo.someValue1), (TelemetryRegion.value2, false, Foo.someValue2), (TelemetryRegion.value3, true, Foo.someValue3), (TelemetryRegion.value4, false, Foo.someValue4), ]) func testEndpoint(region: enforce: expectedEndpoint: ) { ... }

Hello. I was working on a Unity game for iPhone, but Apple said that it is impossible to prohibit downloading to iPad. They tested it on iPad Air 5, and for some reason the game did not work correctly - nothing happened when launched, although everything was fine in the iPad Air 5 simulator and in the real iPhone. Please tell me what to do?

Dear Apple Developer Support Team, I recently registered a personal Apple Developer account successfully and submitted an app for TestFlight beta review with the App ID 6748887468. However, the status has remained in "Waiting for Review" for quite a long time. I’ve read that TestFlight beta app reviews are usually completed within 24 hours. Given the extended delay, I’m concerned there might be an issue with my submission, or that my developer account might be missing some required documentation. Could you kindly help me verify if there is any issue preventing the review process from moving forward? Thank you very much for your support.

Hello Apple Developer Community and Apple Engineers, I'm working on a CoreBluetooth-based iOS application and struggling to find clear, official guidance on best practices for unit testing CoreBluetooth functionality. I'd appreciate any insights from the community and especially from Apple engineers on the recommended approaches. Background & Challenges: Our team has encountered several challenges when trying to implement comprehensive testing for our CoreBluetooth code: Subclassing Restrictions: Apple's documentation explicitly states "Don't subclass any of the classes of the Core Bluetooth framework. Overriding these classes isn't supported and results in undefined behavior." This makes traditional mocking approaches (creating mock subclasses of CBCentralManager, CBPeripheral, etc.) problematic for unit testing. Integration vs Unit Testing Dilemma: We currently use integration tests with third-party libraries like Nordic Semiconductor's CoreBluetoothMock, which work well for end-to-end testing but aren't true unit tests. They test the interaction between our code and the (mocked) CoreBluetooth stack rather than testing individual methods in isolation. Delegate Method Testing: Our code implements CBCentralManagerDelegate and CBPeripheralDelegate protocols. Testing these delegate methods in isolation is challenging because: The methods receive CBCentralManager/CBPeripheral parameters that we can't mock via subclassing Using third-party mocking frameworks makes them integration tests, not unit tests Testing the business logic within these methods requires the actual CoreBluetooth objects Simulator Limitations: The only official Apple documentation we found about CoreBluetooth testing is Technical Note TN2295, which is marked as "retired" and from 2012. It describes a complex simulator setup requiring physical USB adapters, suggesting simulator-only testing isn't fully supported. Specific Questions: What are Apple's current official recommendations for testing CoreBluetooth applications? Should we focus on device testing, integration testing with mocking libraries, or are there other approaches we should consider? For unit testing: How can we test individual delegate methods and business logic without violating the "no subclassing" restriction? Are there patterns or architectures that make CoreBluetooth code more unit-testable? Testing strategy: Should CoreBluetooth applications primarily rely on integration tests rather than traditional unit tests? Is this an acceptable trade-off given the hardware-dependent nature of Bluetooth? Simulator support: Is there current, supported functionality for testing CoreBluetooth applications in the simulator, or should all testing be done on physical devices? Current Approach: We're currently using: Integration tests with CoreBluetoothMock for comprehensive workflow testing Limited unit tests for business logic that we can extract from delegate methods Physical device testing for final validation This works but feels incomplete compared to the unit testing coverage we achieve in other parts of our application. Request: Any guidance from Apple engineers on the intended/recommended approach for testing CoreBluetooth applications would be incredibly valuable. Even confirmation that "integration testing with physical devices is the primary recommended approach" would help clarify our testing strategy. Thank you for any insights you can share! Environment: iOS 17+ Xcode 15+ Swift 5.9+

We all know that the feature “Always On Display” is available only on pro models. I checked in iPhone 14 Plus, that feature became visible in “Search” menu under “Settings”. If a user types “Displa”, then the search results show “Always On Display” as a result. When I click on that, it navigates inside “Display and Brightness” and we found no toggle for “Always On Display”. So, displaying the same on search result is a big bug which needs immediate attention from Apple. Users are getting confused whether iPhone 14 plus has that feature or not.. **Possible reason: ** I believe Apple releases iPhone OS versions in a single release each time and must be applying any kind of feature flagging to enable / disable a feature in a version or for a model. The feature flagging might not be working with Settings menu’s Search service or the code is not properly modular.

I want to load images from my bundle, which works fine when running the main app. However this does not work when running UI Tests. I read that the test bundle is not the main bundle when running tests. I try loading the bundle via this snippet: let bundle = Bundle(for: Frames_HoerspielUITests.self) This is my test class wrapped these the canImport statements so it can be added to the main app target and used for getting the correct bundle: #if canImport(XCTest) import XCTest final class Frames_HoerspielUITests: XCTestCase { override func setUpWithError() throws { continueAfterFailure = false } override func tearDownWithError() throws { } @MainActor func testExample() throws { let app = XCUIApplication() app.launch() } @MainActor func testLaunchPerformance() throws { measure(metrics: [XCTApplicationLaunchMetric()]) { XCUIApplication().launch() } } } #else final class Frames_HoerspielUITests { } #endif However while this works when running the main app, it still fails in the UI tests. It is a SwiftUI only app. and I can't add the images to the asset catalog because they are referenced from another location. Any ideas? Thank you

Hi, we are using xctest UI tests integrated into a Jenkins CI pipeline. However, after upgrading the machine running automated tests to macOS Sequoia, we’re experiencing an issue: before each UI test, the system displays a popup asking for a password to allow XCTest to enable UI automation. Is there any known workaround for this, please? I’ve tried disabling SIP and modifying the TCC database, but nothing has worked so far. Thank you in advance. I’ve attached a screenshot of the popup.

Hello! I am writing UI tests for an app with OAuth authentication and want to avoid the login screen. I want each developer to store the password and username locally on their machines. The bash script will get the token. I need to access that token from my test target somehow. The idea was to write them to a temporary file that git ignores and access this file from the bundle. But I can't add the file from the build script to the target and make it accessible from the code.

I have developed a Swift macro called @CodableInit in the SwiftCodableMacro module, and I’m able to use it successfully in my main project. Here’s an example usage: import SwiftCodableMacro @CodableInit // This is for Codable macros public class ErrorMonitoringWebPlugin { public var identifier: UUID = UUID() // MARK: - Codable required public init(from decoder:Decoder) throws { let values = try decoder.container(keyedBy: CodingKeys.self) identifier = try values.decode(UUID.self, forKey: .identifier) } } However, when I try to write a unit test for the ErrorMonitoringWebPlugin class, I encounter an issue. Here's the test case: func testCodableSubjectIdentifierShouldEqualDecodedSubjectIdentifier() { self.measure { let encoder = JSONEncoder() let data = try? encoder.encode(subject) //Here I am getting this error Class 'JSONEncoder' requires that 'ErrorMonitoringWebPlugin' conform to 'Encodable' let decoder = JSONDecoder() let decodedSubject = try? decoder.decode(ErrorMonitoringWebPlugin.self, from: data!) XCTAssertEqual(subject.identifier, decodedSubject?.identifier) } } The compiler throws an error saying: Class 'JSONEncoder' requires that 'ErrorMonitoringWebPlugin' conform to 'Encodable' Even though the @CodableInit macro is supposed to generate conformance, it seems that this macro-generated code is not visible or active inside the test target. How can I ensure that the @CodableInit macro (from SwiftCodableMacro) is correctly applied and recognized within the XCTest target of my main project?

Hello there! I have developed a website (https://finnia.ch). Now I have transformed it to an app (with webview). If anyone would like to check it out and test it here is the link: https://testflight.apple.com/join/hmyDw74t It is a administration tool (not a game). Simon

"UITests recording reports 'The capability "Create Service Socket" is not supported by this device.' on M1 chip, but works normally on Intel chip."

We using below command to run unit test and collect coverage: xcodebuild -workspace Demo.xcworkspace -scheme VideoTests -configuration Debug -derivedDataPath ../build/derivedData -destination 'platform=iOS Simulator,id=E6630007-570B-4DEB-A023-2BCE91116A8D' -resultBundlePath './fastlane/test_output/VideoTests.xcresult' -enableCodeCoverage YES -testPlan 'Video' test-without-building | tee '/Users/rcadmin/Library/Logs/scan/VideoTests.log' | xcbeautify -q --is-ci and using xcrun llvm-cov show command to generate coverage report: xcrun llvm-cov show /build/unit-test/coverage/libraries/merged/video.o -instr-profile=/app/ios/build/derivedData/Build//ProfileData/E6630007-570B-4DEB-A023-2BCE91116A8D/video.profdata -show-branches count -show-expansions -show-line-counts -use-color -format=html -output-dir coverage and the html report does not include branch coverage: how to generate the branch coverage?

My app is approved for the Web Browser Public Key Credential Request managed capability and has it added to its App ID Configuration: It has been added to my entitlements file: I am able to build and run unit tests in Xcode locally using my managed profile. When I push changes and Xcode Cloud tries to build and run the app, I get the following error: Mirrai encountered an error (Failed to install or launch the test runner. (Underlying Error: Could not launch “MirraiTests”. Runningboard has returned error 5. Please check the system logs for the underlying cause of the error. (Underlying Error: The operation couldn’t be completed. Launch failed. (Underlying Error: Launchd job spawn failed)))) Removing just the com.apple.developer.web-browser.public-key-credential entitlement, with no other changes, results in all tests passing on Xcode Cloud. Some thoughts: In project settings, the test target has a different bundle id (appending Tests to the app bundle id). Under "Certificates, Identifiers & Profiles," the managed capability is added to the bundle id but it is an explicit bundle id and not a wildcard. Do I need to apply for the managed capability for the test bundle id as well? Or for a wildcard bundle id? xcodebuild-test-without-building.log

Xcode Cloud is unable to run unit tests for a MacOS target after adding a restricted capability (keychain-access-groups). Have tried setting both manual and automatic signing (with a Mac OS development profile). The tests run on my locally fine, but when pushed to Xcode Cloud the crash report indicates a Code Signing Issue, downloading the Artifact for Test Products for AppTests and viewing the app contents I noted that when built locally embedded.provisionprofile appears within the App/Contents that doesn't appear in Xcode Cloud. To reproduce, create a new MacOS app with a test plan, run a Test job (successfully runs) then add the capability for Keychain Sharing: <array> <string>$(AppIdentifierPrefix)com.transmedics.RemoteView.group</string> </array> to the entitlements. Run the job again and tests with the project fails in Xcode Cloud, with code signing issues in the crash report.

In the app I'm working on, I have a SwiftUI View embedded in a UIKit Storyboard. The SwiftUI View holds a menu with a list of payment tools, and the ForEach loop looks like this: ForEach(self.paymentToolsVM.paymentToolsItems, id: \.self) { paymentTool in Button { navigationCallback(paymentTool.segueID) } label: { PaymentToolsRow(paymentToolName: paymentTool.title, imageName: paymentTool.imageName) .accessibilityElement() .accessibilityIdentifier("Billing_\(paymentTool.title.replacingOccurrences(of: " ", with: ""))") } if paymentTool != self.paymentToolsVM.paymentToolsItems.last { Divider() } } So you can see the accessibility ID is there, and it shows up properly when I open up Accessibility Inspector with the simulator, but the testing script isn't picking up on it, and it doesn't show up when the view is inspected in Appium. I have other SwiftUI views embedded in the UIKit view, and the script picks up the buttons on those, so I'm not sure what's different about this one. If it helps, the script is written in Java with the BDD framework. I can try to get the relevant part of the script if anyone thinks that would be helpful. Otherwise, is there anything else I can try?

Is anybody able to save the autocreated testplan successfully with Xcode 16.3? I get a crash no matter what (different filenames, locations, machines, ...). Now created a template project: same thing. Xcode Version 16.3 (16E140) on macOS 15.5 (24F74) Known issue, or am I holding it wrong?

I am encountering an issue where code coverage data is not showing for my main app in Xcode when running tests for the iOS simulator. However, code coverage is being reported correctly for some modules. Enable Code Coverage Support: YES Xcode 16.2 macOS: 15.3.1 Macbook Pro M1 14-inch, 2021 Despite these configurations, Xcode fails to show code coverage for the main app. Can anyone suggest what might be causing this issue and how to ensure code coverage is correctly reported for the main app during simulator builds?

I am running Appium tests on an iOS 18 simulator, and I am encountering an intermittent issue where the device screen gets locked unexpectedly during the tests. The Appium logs show no errors or unusual activity, and all commands appear to be executed successfully. However, upon reviewing the device logs, I see entries related to the lock event, but the exact cause remains unclear. SpringBoard: (SpringBoard) [com.apple.SpringBoard:Common] lockUIFromSource:Boot options:{ SBUILockOptionsLockAutomaticallyKey: 1, SBUILockOptionsForceLockKey: 1, SBUILockOptionsUseScreenOffModeKey: 0 } SpringBoard: (SpringBoard) [com.apple.SpringBoard:Common] -[SBTelephonyManager inCall] 0 SpringBoard: (SpringBoard) [com.apple.SpringBoard:Common] LockUI from source: Now locking Has anyone experienced similar behavior with Appium on iOS 18, or could there be a setting or configuration in the simulator that is causing this issue?

At the last place I worked it took roughly 5 minutes to do an application build. Which in turn made doing any sort of TDD or ever just regular Unit Tests extremely painful to do as the cycle time was simply too long. But that got me thinking. In recent versions of Xcode, Apple added Previews for SwiftUI Views that basically showed code changes to the View in real time. And Previews were made possible by extremely targeted compilation of the view in question. So... what if instead of a Preview pane in the Xcode IDE there was a Test pane the could be displayed such that Tests for a piece of code could be created and run almost immediately? Perhaps by adding a #Testing section to your code #Testing(MyService.self) // Define the entity to be tested. If you could drop the turnaround time AND provide a test playground for service level code that could speed development of such code greatly... and encourage interactive test development at the same time. What do you think?

Hi all, I’ve run into a frustrating issue with the FamilyControls and DeviceActivityMonitor APIs. I’ve received official approval from Apple to use the com.apple.developer.family-controls entitlement (distribution), and I’ve added the entitlement to both my main app and the DeviceActivityMonitor extension. I’ve also ensured the correct App Group is configured for both targets. Everything works perfectly when I install the app on my own device as an internal TestFlight tester. App blocking works, the DeviceActivityMonitor extension runs as expected, and the apps selected by the user are correctly shielded. However, for external TestFlight testers, while they do receive the Screen Time permission prompt, and can select apps to block, nothing actually gets blocked. It appears that the DeviceActivityMonitor extension is not being triggered at all on their devices. I’ve verified the following: The entitlement is approved and visible in App Store Connect The build is approved for external testing Testers are running iOS 16+ Shielding logic works properly on internal tester devices Clean installs have been tested on external devices Has anyone gotten FamilyControls + DeviceActivityMonitor working successfully for external testers via TestFlight? If this is a known limitation or if there are any additional steps required to enable extension execution for external users, I’d really appreciate any clarification. Thanks in advance for your help.