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?

I have an environment variable set in an xctestplan for a set of unit tests that I access like so: let testType = ProcessInfo.processInfo.environment[TARGET_TEST_TYPE_KEY] This is always is always returning nil when I run my unit tests in Xcode 26, but seems to work as expected in Xcode 16.4. Were there any changes in Xcode 26 that changes how this works? Thanks in advance.

Hi *, I'm trying to add a build for external testers. Everything work fine up to the point where I have to provide the information about the contact person. Entring the phone number always results in an error message that the phone number can only consits of numbers (what it really does). Has anyone a hint how to fix this problem? Peter

Summary While parallel testing Core Location on the new iOS 26.1 beta (23B5044i), I observed what I believe to be a regression of the issue described here: https://developer.apple.com/forums/thread/779192 Specifically, user positioning underground subway stations is noticeably inaccurate on the beta, whereas the same scenarios remain accurate on the unupgraded device below. I work with the MTA (New York City) and work with the OP of that thread. Happy to provide additional testing or details if helpful. Please let me know what else you need. Test Info Riding NYCT from Wall St to 34th St Penn Station on the 2 train carrying two iphones Recording: https://limewire.com/d/dpTWi#pDC3GRYIdE Expected: Consistent underground positioning comparable to prior releases. Actual: Degraded/inaccurate underground positioning on iOS 26.1 beta. Test Devices Left Screen: iPhone 15 Pro Max - iOS 26.1 beta (23B5044i) Right Screen: iPhone 11 - iOS 18.6.2 (22G100) Blue dots show location set by CoreLocation. Red dot on iphone 11 shows the actual location of both devices as I was able to manually place while travelling through a station. Placement through tunnels is not easy to verify and not usually indicated. Timestamps Comparison of when train was actually observed in a station vs when 26.1 and 18.6.2 CoreLocation updated to the station Fulton St 1:48 iOS 26.1 correctly updates (correctly) 2:16 iOS 18.6.2 updates (28sec late) Park Place 4:12 train arrives 4:15 iOS 18.6.2 updates to ~near Park Place 5:04 iOS 18.6.2 updates to Park Place (correctly) 6:07 iOS 26.1 update to ~near Park Place (over 2 mins late) Chambers St 6:02 train arrives / iOS 18.6.2 updates (correctly) 6:14 iOS 26.1 updates to ~near Chambers 6:18 iOS 26.1 update to Chambers (correctly) Franklin St 6:52 train arrives 6:55 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Canal St: 7:16 train arrives 7:18 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Houston St 7:54 train arrives 8:00 iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update Christopher St 8:37 iOS 26.1 presumably between Houston St and Christopher St 8:40 train arrives / iOS 18.6.2 updates (correctly) x:xx iOS 26.1 does not update 14 St 9:22 train arrives 9:28 iOS 18.6.2 updates (correctly) 11:01 as train departs station iOS 26.1 updates (1.5 mins late)

I'm trying to write performance tests with Xcode 15, but it's not working: even though setting a baseline seems to work (baseline data files are created), Xcode seems to ignore that baseline altogether whenever the test is run. As a result, performance tests never fail, no matter how bad performance gets. The source editor persistently displays a “No baseline average for Time” message. Has anyone else encountered this? Figured out how to sidestep the issue? Of note, the issue is easily reproduced: create a new (macOS in my case) app project with tests, add a dummy performance test; run the test once and save its baseline, and despite this subsequent tests will always succeed, even if you significantly slow the dummy test down. (I've filed this as FB13330139)

I have a project inside the project structure. I have around 300 unit tests in the project. I see that for some of the subprojects, the coverage numbers show up correctly, but for other subprojects and the main project, the coverage number shows zero, even though the tests are running successfully. The log I get is: Aggregation tool emitted warnings: warning: /Users/ABC/Library/Developer/Xcode/DerivedData/projectABC-hfzmkbdgpiswoxfvvnvhrafaiqyb/Build/ProfileData/A8EEC1FB-1699-4C29-A88C-D3DDA226DBC0/0A416494-A393-4319-AA47-502D72084C9C-43351.profraw: raw profile version mismatch: Profile uses raw profile format version = 8; expected version = 10 PLEASE update this tool to the version in the raw profile, or regenerate the raw profile with the expected version. I only have one Xcode (26.0.1) on my machine. I tried cleaning the derived data, the cleaning project, and rerunning the tests, but it hasn't helped. Please help me get the coverage number back. Thank you.

New Apple Developer here, I've built my first iOS app in Xcode and wants to get it onto some friends' iPhones to do some external testing and give me some feedback. I've read the Apple Developer documentation on how to use TestFlight, but it's not understandable since step 1 is entering information about the app in App Store Connect and step 2 is uploading the app to App Store Connect? Can someone please write some easy step-by-step directions on how to get an iOS app from Xcode onto external testers' iPhones for a first-timer in 2024? Thank you so much!

I have a strange problem. My code works perfectly on my iPhone, i.e. on a real iPhone, but when I upload the build version to TestFlight, it no longer works. I use React Native. The issue is as follows: I have created a code for Grid View that runs automatically when another person joins the stream. It works locally without any problems, but unfortunately the public version does not work. What could be the reason for this?

While preparing automated screenshots with Xcode UI tests for the iOS 26 release, I noticed that this simple line of code app.buttons["myTabItem"].tap() doesn't always work, both on iPhone and iPad Simulator. In fact, it rarely works. Even when repeating the same test, mostly it fails on that line, but a few times it works and I can see the tab item change in the simulator. My main view looks like this: TabView { MyTab1() .tag(tag1) .tabItem { Label("label1", systemImage: "image1") } MyTab2() .tag(tag2) .tabItem { Label("label2", systemImage: "image2") .accessibilityIdentifier("myTabItem") } The error I get is Failed to tap "myTabItem" Button: No matches found for Elements matching predicate '"myTabItem" IN identifiers' from input In the given list of buttons, I see the tab items with their labels, but none of them seem to have an identifier, while other buttons have the correct identifier. I wonder how this can only sometimes work. I tried isolating the issue by iteratively commenting out parts of the SwiftUI code, but unfortunately the behaviour seems erratic. When a change results in the issue not happening anymore, undoing the last X changes often causes the issue to stay away, even with configurations that previously had the issue. I've already spent almost a whole day trying to find the root cause, but with such apparently random behaviour it has proven impossible. Of course, I cannot reproduce the issue with a fresh test project, so the only way to reproduce it with 95% probability is running my original project. Has anyone had the same issue, or does anyone know how I could debug this to find out what causes my UI test to not be able to tap another tab item?

We have a simple workflow that just runs the Test action on my unit_tests scheme (see Xcode Cloud workflow configuration screenshot). The workflow is configured to use Xcode 16.4 (Latest Release), macOS Sequoia 15.6 (Latest Release), and iOS 18.0 simulators. Today, this workflow has been consistently running indefinitely. The Xcode cloud runner tries to launch the simulator to execute the tests, but it fails. See the error message in the screenshot from Xcode Cloud logs. Link to corresponding build is in my Feedback Assistant ticket. It continues to retry this operation for a very long time — I had one job that ran for over 90 minutes. Link to corresponding build also in that same Feedback Assistant ticket. Are Xcode Cloud runners perhaps currently undergoing maintenance? Or is something else going on. I would appreciate if Xcode Cloud usage from today could be refunded to my team’s account. Feedback Assistant ticket #FB20195292. Error message: MyApp encountered an error (Failed to prepare device 'iPhone 16' for impending launch. (Underlying Error: Unable to boot the Simulator. launchd failed to respond. (Underlying Error: Failed to start launchd_sim: could not bind to session, launchd_sim may have crashed or quit responding)))

Hello, Anytime I try to send an app to the store, and specifically to test flight Then I add an individual user it shows me: "No build available" Is that normal? why? What's happening here? Please enlighten me?

Hello, I'm unable to run any test cases in Xcode 16 with the iOS 18 simulator. Steps to Reproduce: Create a new iOS project in Xcode 16 using the default iOS app template with the testing option checked. Run any test or UI test case by clicking the "Play" icon in the Test navigator. Xcode gets stuck at the "Testing" state indefinitely. Environment: macOS 15 beta 8 Xcode 16 beta 6 iOS 18 beta 7 simulator

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?

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+

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.

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.

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