I am facing an issue with my app. It works perfectly on TestFlight, and I have tested it on several devices, where it also runs without any problems. However, when the app is tested in the Apple testing facility, it shows an unexpected server error message. I have tested the app using multiple VPNs and different locations in Sri Lanka, and it works perfectly in all cases. It also works correctly when distributed through third-party app stores. At this point, I am not sure what is causing this issue. I have already submitted more than 10 app versions, each with different fixes that I thought might solve the problem, but the issue still persists. Could someone please help me understand what might be causing this problem? (the above provided screenshot from apple)

Hi Apple Developer Support, We are reaching out to request guidance on a testing constraint we have encountered related to iOS Universal Links and Associated Domains entitlements. As part of aligning with updated recommendations from our authentication provider, we have transitioned our mobile apps to use HTTPS redirect callbacks (Universal Links) instead of custom URI schemes. This works as expected in production and on real physical devices. However, we are encountering a significant issue in our cloud-based device testing environment. When our testing platform re-signs the app to run it on their infrastructure, the re-signing process strips the Associated Domains entitlement from the app bundle. As a result, iOS no longer honors our Universal Links, which breaks the authentication redirect flow — the callback cannot route back into the app after the user authenticates. We have identified a potential workaround that would involve disabling app re-signing in the testing platform, but this requires provisioning under an Apple Enterprise Developer account. This introduces considerable operational complexity, as it would require us to maintain separate signing and distribution paths alongside our existing Apple Developer Program membership. Before pursuing that path, we wanted to understand Apple's perspective on the following: Is there a supported or recommended approach for preserving Associated Domains entitlements when an app is re-signed by a third party (e.g., a cloud testing platform)? Are there any provisioning or entitlement configurations that would allow Universal Links to function correctly in re-signed builds without requiring an Enterprise Developer account? Does Apple have documented best practices for validating Universal Link–based flows in automated or cloud-based testing environments? Are there any alternative deep linking patterns that would be more resilient to re-signing while still meeting App Store and platform security requirements? Any guidance or recommendations from Apple on how to handle this within the bounds of the standard Apple Developer Program would be greatly appreciated. Thank you for your time.

Summary: After upgrading to Xcode 26.4, app-hosted XCTest execution on physical devices running iOS 16 fails at test-planning time with "Logic Testing Unavailable." The same project and same device work under Xcode 26.2. The failure reproduces with a standalone minimal Xcode project, which suggests this is an Xcode regression rather than a project-configuration issue. Environment: Xcode: 26.4 (17E192) macOS: Tahoe 26.4 Failing device: iPhone 11 (iPhone12,1), iOS 16.0.3 Working comparisons: Xcode 26.2 + same iPhone 11 (iOS 16.0.3): works Xcode 26.4 + iPad Pro 11-inch (4th generation) on iOS 26.3: works Regression: Yes. Works on Xcode 26.2. Fails on Xcode 26.4. Same project, same signing setup, same physical iOS 16 device. Minimal reproduction: A minimal sample project with: one iOS app target one app-hosted unit-test target one UI-test target (for comparison; not required to reproduce) Steps for the unit-test repro on a physical device running iOS 16: Build for testing: xcodebuild -project TestProject.xcodeproj \ -scheme TestProject-UnitTests \ -sdk iphoneos \ -destination 'platform=iOS,id=<DEVICE_UDID>' \ -derivedDataPath DerivedData-Device-Unit \ -resultBundlePath Results-Device-Unit-Build.xcresult \ DEVELOPMENT_TEAM=<TEAM_ID> \ CODE_SIGN_STYLE=Automatic \ build-for-testing Run tests without building: xcodebuild -project TestProject.xcodeproj \ -scheme TestProject-UnitTests \ -sdk iphoneos \ -destination 'platform=iOS,id=<DEVICE_UDID>' \ -derivedDataPath DerivedData-Device-Unit \ -resultBundlePath Results-Device-Unit-Test.xcresult \ DEVELOPMENT_TEAM=<TEAM_ID> \ CODE_SIGN_STYLE=Automatic \ test-without-building Note: xcodebuild test (combined build and test) also fails with the same error. Expected result: The hosted unit tests run successfully on the connected physical device, as they do under Xcode 26.2. Actual result: Step 1 (build-for-testing) succeeds. Step 2 (test-without-building) fails immediately (within ~1 second) with: 2026-03-26 11:23:28.683 xcodebuild[51930:731004] DVTDeviceOperation: Encountered a build number "" that is incompatible with DVTBuildVersion. 2026-03-26 11:23:28.725 xcodebuild[51930:730966] [MT] DVTDeviceOperation: Encountered a build number "" that is incompatible with DVTBuildVersion. 2026-03-26 11:23:29.239 xcodebuild[51930:730966] Writing error result bundle to /var/folders/jl/knmkq18x4cg_3w087zgpfldm0000gn/T/ResultBundle_2026-26-03_11-23-0029.xcresult xcodebuild: error: Failed to build project TestProject with scheme TestProject-UnitTests.: Cannot test target “redacted” on “redacted”: Logic Testing Unavailable Logic Testing on iOS devices is not supported. You can run logic tests on the Simulator. Why this looks like an Xcode regression: The same project and same physical iOS 16.0.3 device work under Xcode 26.2. Under Xcode 26.4, build-for-testing still succeeds, so signing, provisioning, and bundle construction appear valid. The failure happens only when Xcode plans or launches the on-device test run. Before the failure, Xcode 26.4 logs: DVTDeviceOperation: Encountered a build number "" that is incompatible with DVTBuildVersion. A newer physical device running iOS 26.3 works under Xcode 26.4 without this warning. The issue also reproduces with a minimal standalone Xcode project, which makes a project-specific configuration problem unlikely. The Xcode-generated .xctestrun files for the passing Xcode 26.2 case and failing Xcode 26.4 case are structurally equivalent, making an .xctestrun format difference unlikely to be the cause.

I have an old Xcode project that I am adding tests to, and at a high level I see the code coverage percent (the 2.2% number). However, in the detail view, code coverage only shows on the testing bundle, not in the main app bundle. Anyone have any tips on how to fix this?

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.

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

I'm working on moving XCTests to Swift Testing and trying to understand why it shows Testing Library Version: 102 (arm64-apple-ios13.0-simulator) when running. Why iOS 13?

Hi everyone, I’ve been facing an issue with TestFlight external builds that I haven't encountered before, and I’d appreciate any insights. Background: I have an iOS app that was recently approved and released to the App Store. Prior to this, I’ve regularly submitted TestFlight builds (with updated version and build numbers) to both internal and external tester groups. Internal builds would appear instantly, as expected. External builds were also available almost immediately after selecting “Ready to Submit.” This was consistent for many iterations. Current Issue: After pushing the latest version to the App Store (which went through the standard review process and was approved), I prepared a new version for TestFlight testing. Here’s what happened: Uploaded a new build with a new version number and build number. It appeared instantly for internal testing as usual. When I tried adding it to the external tester group, the build got stuck in the “Waiting for Review” state. I uploaded this on Saturday night, and as of Monday noon, the status has not changed. I also cancelled that build and uploaded a fresh one with an incremented build number — still stuck in the same status. Additional Notes: The app’s ITSAppUsesNonExemptEncryption key is set to false in Info.plist. There is no missing export compliance warning on App Store Connect. The changes in the new build are minor — a few small updates, nothing significant. I tried decreasing the build number temporarily (which caused an error), then increased it again. No changes were made to permissions, app capabilities, or metadata that would typically trigger a longer review. Questions: Is this expected after an App Store release? Has anyone else experienced delays like this recently for TestFlight external builds? Is there anything I can do to expedite the review? Thanks in advance for any help!

Hi, We are facing issues on ios simulators os version 18, "Simulator device failed to install the application. Failed to create promise. Underlying error (domain=IXErrorDomain, code=2):" Due to this error simulator is unable to install the application. we are facing this intermittently. xcode version : Xcode.16.0.0.16A242d.app ios simulator runtime : com.apple.CoreSimulator.SimRuntime.iOS-18-0 ios simulator : com.apple.CoreSimulator.SimDeviceType.iPhone-16 mac os version : macOS 15.4 we have tried upgrading to xcode Xcode.16.1.0.16B40.app and ios simulator runtime to 18.1 but its not working. Also we have rebooted xcode, not helping. *Exact error message : ** org.openqa.selenium.SessionNotCreatedException: Could not start a new session. Response code 500. Message: An unknown server-side error occurred while processing the command. Original error: Error running 'install': An error was encountered processing the command (domain=IXErrorDomain, code=2): Simulator device failed to install the application. Failed to create promise. Underlying error (domain=IXErrorDomain, code=2): Failed to set icon resources promise for com.yyyy.xxxx Failed to create promise. Host info: host: 'uci-macmini-019lab3b.local', ip: 'fe80:0:0:0:1caf:6627:141d:f464%en0' Build info: version: '4.30.0', revision: '509c7f17cc' System info: os.name: 'Mac OS X', os.arch: 'aarch64', os.version: '15.3.1', java.version: '11.0.25' Driver info: com.mypackage.common.drivers.CustomIosDriver$ByteBuddy$g865VfU3 Command: [null, newSession {capabilities=[{appium:webviewConnectTimeout=120000, appium:autoAcceptAlerts=true, appium:app=/Users/mobileci/.buildkite-agent/builds/uci-macmini-019lab3b/mypackage/e2e-test-ios-simulator/8155f349-18b9-413c-9d17-dcb064986154/test_artifacts/target.app, appium:includeSafariInWebviews=true, appium:locale=US, appium:mjpegServerPort=52715, appium:newCommandTimeout=600000, appium:waitForIdleTimeout=3, appium:derivedDataPath=/Users/mobileci/.buildkite-agent/builds/uci-macmini-019lab3b/mypackage/e2e-test-ios-simulator/8155f349-18b9-413c-9d17-dcb064986154/appium_wda_ios/, appium:wdaConnectionTimeout=300000, appium:wdaLaunchTimeout=300000, appium:processArguments={env={E2E_TESTING=YES, RUN_UUID=8155f349-18b9-413c-9d17-dcb064986154}}, appium:automationName=XCUITest, appium:fullReset=true, appium:udid=F266ECC3-FD23-464D-B0C3-576EB48B2FF5, appium:deviceName=E2ESimulator, appium:wdaLocalPort=52714, appium:showXcodeLog=true, appium:webkitDebugProxyPort=52716, appium:noReset=false, appium:language=en, platformName=IOS, appium:simpleIsVisibleCheck=true}], desiredCapabilities=Capabilities {app: /Users/mobileci/.buildkite-..., autoAcceptAlerts: true, automationName: XCUITest, derivedDataPath: /Users/mobileci/.buildkite-..., deviceName: E2ESimulator, fullReset: true, includeSafariInWebviews: true, language: en, locale: US, mjpegServerPort: 52715, newCommandTimeout: 600000, noReset: false, platformName: IOS, processArguments: {env: {E2E_TESTING: YES, RUN_UUID: 8155f349-18b9-413c-9d17-dcb...}}, showXcodeLog: true, simpleIsVisibleCheck: true, udid: F266ECC3-FD23-464D-B0C3-576..., waitForIdleTimeout: 3, wdaConnectionTimeout: 300000, wdaLaunchTimeout: 300000, wdaLocalPort: 52714, webkitDebugProxyPort: 52716, webviewConnectTimeout: 120000}}] Capabilities {app: /Users/mobileci/.buildkite-..., autoAcceptAlerts: true, automationName: XCUITest, derivedDataPath: /Users/mobileci/.buildkite-..., deviceName: E2ESimulator, fullReset: true, includeSafariInWebviews: true, language: en, locale: US, mjpegServerPort: 52715, newCommandTimeout: 600000, noReset: false, platformName: IOS, processArguments: {env: {E2E_TESTING: YES, RUN_UUID: 8155f349-18b9-413c-9d17-dcb...}}, showXcodeLog: true, simpleIsVisibleCheck: true, udid: F266ECC3-FD23-464D-B0C3-576..., waitForIdleTimeout: 3, wdaConnectionTimeout: 300000, wdaLaunchTimeout: 300000, wdaLocalPort: 52714, webkitDebugProxyPort: 52716, webviewConnectTimeout: 120000} at

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.

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?

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?

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?

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?

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?

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

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?

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

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