I have a Swift package with a test suite that contains some tests implemented with Swift Testing. Locally, they run quickly, but when I run them on Semaphore CI (https://semaphore.io), the first Swift Testing test to execute incurs a performance penalty. I'm running the tests with xcodebuild on iOS Simulator: xcodebuild test \ -scheme "Scheme" \ -workspace Workspace.xcworkspace \ -destination "platform=iOS Simulator,name=iPhone 16,OS=18.2" The scheme is configured to use a test plan that has parallelization disabled. Here's an excerpt from the output showing what I'm seeing: Test Suite 'All tests' started at 2025-04-03 07:47:37.328. ◇ Test run started. ↳ Testing Library Version: 102 (arm64-apple-ios13.0-simulator) ◇ Iteration 1 started. ◇ Suite <redacted> started. ◇ Test foo() started. ✔ Test foo() passed after 23.063 seconds. When foo() is not the first test it runs in under 100 ms. The reason that I have parallelization disabled is that I was initially seeing all of the tests in this suite incur a performance hit. But now it's clear that there must be some startup cost. Things I'm wondering: What is this startup penalty? Why don't I encounter it locally? Why is it attributed to the first test? (this seems like a bug) My wild guesses around 1 so far have been… maybe some simulator clone is booting. I've tried to rule that out by disabling parallelization, but maybe there's still something there. maybe swift testing is getting loaded lazily and there's some kind of dynamic linking cost Thoughts on 2… maybe there's some one-time penalty when using swift testing that I've already incurred locally but that has not yet been incurred in the CI image Guidance welcome! x-posted: FB17102970 (Unexpected performance penalty attributed to first Swift Testing test) https://forums.swift.org/t/first-swifttesting-test-always-slow/79066

We've seen a recent increase in background terminations: blue - System Pressure orange - Task Timeout I'm trying to understand the increase in system-pressure terminations, since there's no corresponding increase in memory at suspension. Are there other system resources for which iOS will terminate an app?

We have crash reports as shown below that we haven't yet been able to repro and could use some help deubgging. My guess is that the app is giving a label or text view an attributed string with an invalid attribute range, but attributed strings are used in many places throughout the app, and I don't know an efficient way to track this down. I'm posting the stack trace here in hopes that someone more familiar with the internals of the system frameworks mentioned will be able to provide a clue to help narrow where I should look. Fatal Exception: NSRangeException NSMutableRLEArray objectAtIndex:effectiveRange:: Out of bounds 0 CoreFoundation 0x2d5fc __exceptionPreprocess 1 libobjc.A.dylib 0x31244 objc_exception_throw 2 Foundation 0x47130 blockForLocation 3 UIFoundation 0x2589c -[NSTextLineFragment _defaultRenderingAttributesAtCharacterIndex:effectiveRange:] 4 UIFoundation 0x25778 __53-[NSTextLineFragment initWithAttributedString:range:]_block_invoke 5 CoreText 0x58964 TLine::DrawGlyphsWithAttributeOverrides(TLineDrawContext const&, __CFDictionary const* (long, CFRange*) block_pointer, TDecoratorObserver*) const 6 CoreText 0x58400 CTLineDrawWithAttributeOverrides 7 UIFoundation 0x25320 _NSCoreTypesetterRenderLine 8 UIFoundation 0x24b10 -[NSTextLineFragment drawAtPoint:graphicsContext:] 9 UIFoundation 0x3e634 -[NSTextLineFragment drawAtPoint:inContext:] 10 UIFoundation 0x3e450 -[NSTextLayoutFragment drawAtPoint:inContext:] 11 UIKitCore 0x3e3098 __38-[_UITextLayoutFragmentView drawRect:]_block_invoke 12 UIKitCore 0x3e31cc _UITextCanvasDrawWithFadedEdgesInContext 13 UIKitCore 0x3e3040 -[_UITextLayoutFragmentView drawRect:] 14 UIKitCore 0xd7a98 -[UIView(CALayerDelegate) drawLayer:inContext:] 15 QuartzCore 0x109340 CABackingStoreUpdate_ 16 QuartzCore 0x109224 invocation function for block in CA::Layer::display_() 17 QuartzCore 0x917f0 -[CALayer _display] 18 QuartzCore 0x90130 CA::Layer::layout_and_display_if_needed(CA::Transaction*) 19 QuartzCore 0xe50c4 CA::Context::commit_transaction(CA::Transaction*, double, double*) 20 QuartzCore 0x5bd8c CA::Transaction::commit() 21 UIKitCore 0x9f3f0 _UIApplicationFlushCATransaction 22 UIKitCore 0x9c89c __setupUpdateSequence_block_invoke_2 23 UIKitCore 0x9c710 _UIUpdateSequenceRun 24 UIKitCore 0x9f040 schedulerStepScheduledMainSection 25 UIKitCore 0x9cc5c runloopSourceCallback 26 CoreFoundation 0x73f4c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 27 CoreFoundation 0x73ee0 __CFRunLoopDoSource0 28 CoreFoundation 0x76b40 __CFRunLoopDoSources0 29 CoreFoundation 0x75d3c __CFRunLoopRun 30 CoreFoundation 0xc8284 CFRunLoopRunSpecific 31 GraphicsServices 0x14c0 GSEventRunModal 32 UIKitCore 0x3ee674 -[UIApplication _run] 33 UIKitCore 0x14e88 UIApplicationMain also filed as FB16905066

I work on an app that has the com.apple.developer.mail-client entitlement. We're interested in trying out Xcode Cloud, and one of the project and workspace requirements is to use automatic code signing. We do not do this at the moment because it's not compatible with the additional entitlement. My understanding is that we can migrate to automatic code signing if we migrate the additional entitlement to a capability and that to accomplish this our account holder needs to submit a request (see the last section of that page). We submitted the request a little over 3 weeks ago, but so far we haven't heard any updates. We also tried reaching out directly to the email address linked in the com.apple.developer.mail-client docs, but have not heard back. We're now posting here to see if anyone can provide some guidance on whether there are other steps to complete or contacts to whom we should reach out. Thanks!

The following behavior seems like a bug in the swift compiler that ships with Xcode 16 beta 6. Add the following code snippet to a new iOS app project using Xcode 16 beta 6 and observe the error an warning called out in the comments within the itemProvider() method: import WebKit extension WKWebView { func allowInspectionForDebugBuilds() { // commenting out the following line makes it so that the completion closure argument of the trailing closure // passed to NSItemProvider.registerDataRepresentation(forTypeIdentifier:visibility:loadHandler:) is no longer // isolated to the main actor, thus resolving the build issues. It is unexpected that the presence or absence of // the following line would have this kind of impact. isInspectable = true } } class Foo { func itemProvider() -> NSItemProvider? { let itemProvider = NSItemProvider() itemProvider.registerDataRepresentation(forTypeIdentifier: "", visibility: .all) { completion in Task.detached { guard let url = URL(string: "") else { completion(nil, NSError()) // error: Expression is 'async' but is not marked with 'await' return } let task = URLSession.shared.dataTask(with: url) { data, _, error in completion(data, error) // warning: Call to main actor-isolated parameter 'completion' in a synchronous nonisolated context; this is an error in the Swift 6 language mode } task.resume() } return Progress() } return itemProvider } } Now, comment out the line isInspectable = true and observe that the error and warning disappear. Also filed as FB14783405 and https://github.com/swiftlang/swift/issues/76171 Hoping to see this fixed before Xcode 16 stable.

Platform and Version iOS Development environment: Xcode 16.0 beta 5 (16A5221g), macOS 14.6.1 (23G93) Run-time configuration: iOS 18.0 beta 5 (22A5326g) Description of Problem Starting with iOS 18 SDK, test bundles containing a +load method that accesses UIScreen.mainScreen result in deadlock during test bundle injection. Also filed as FB14703057 I'm looking for clarity on whether this behavior is considered a bug in iOS or whether we will need to change the implementation of our app. Steps to Reproduce Create a new iOS app project using Objective-C and including unit tests Add the following code snippet to any .m file in the test target: @interface Foo: NSObject @end @implementation Foo + (void)load { UIScreen * const mainScreen = UIScreen.mainScreen; NSLog(@"%@", mainScreen); } @end Run the tests Expected Behavior As with iOS 17 & Xcode 15, the tests run to completion. Actual Behavior With iOS 18 & Xcode 16, deadlock during test bundle injection. stack_trace.txt

I just read Quinn "The Eskimo!"'s great post on UIApplication Background Task Notes. A couple further points of clarification that would be useful: Is it guaranteed that the expiration handler will only be invoked after beginBackgroundTask(expirationHandler:) returns? Is it safe to invoke endBackgroundTask(_:) more than once for a given identifier?

We've recently increased our use of SPM in our iOS app's Xcode project. However, we've noticed that if the Xcode project is open when we switch to a different git branch using another tool (e.g. git on the command line or in a 3rd-party GUI), the Package.resolved file is modified unexpectedly. We've received some conflicting advice about the purpose and appropriate treatment of the Package.resolved file. Some say to add it to .gitignore. On the other hand, the docs say: …be sure to commit your project’s Package.resolved file to your Git repository. This ensures a reliable CI workflow that always uses the expected version of a package dependency. For now, our workaround is to use Xcode to switch git branches, but this seems like an unusual limitation. We're on Xcode 15.3/15.4. There is discussion on the Swift Forums of potentially related problems: https://forums.swift.org/t/xcode-automatically-updating-package-resolved/41900

Are mergeable libraries compatible with digital signatures and privacy manifests? If so, what happens to the privacy manifests from each merged library? Do they get merged?

Relevant background: WWDC23: Get started with privacy manifests WWDC23: Verify app dependencies with digital signatures Upcoming third-party SDK requirements Many of the SDKs that will require privacy manifests and signatures are distributed as source and integrated via Swift Package Manager. I recently studied the progress made by ~10 of the listed SDKs and it seems like there's a growing consensus that the solution to including a privacy manifest when distributing via source is to list the manifest as a bundled resource. However, I've seen little discussion of the signing requirement. This is understandable since, as the forum post Digital signatures available for Swift Packages? points out, the dependency signing talk was focused on binaries. Yet, I'm curious whether signing of some kind will actually be required for SDKs distributed as source (e.g. to enable validating the authenticity of the privacy manifest). Clarification on this point would help tremendously as we work to ensure we'll be compliant as soon as the new requirement begins to be enforced.