Our app uses a UIView backed by a CATiledLayer that is embedded in a UIScrollView, to represent a large document viewer. (PDF data, actually.) It needs to be big - far too big to allocate a single layer, and it needs to be able to reveal more detail as you zoom in. This is the exact use case for a CATiledLayer. CATiledLayer does its drawing on a background thread, as you know, and we've always taken care to make our draw method thread-safe. It has worked great for us, for over a decade now. However, starting with iOS 26, we've been having some surprising crashes. It looks like our CATiledLayer (I think?) is trying to trigger a layout on the background thread as well. This is frustrating because it doesn't have any subviews or sublayers - there's no reason for it. I'm suspecting the CATiledLayer because it does its drawing on a thread, so maybe it would also do other things there, but honestly, I'm not sure - it's hard to tell. Here's the crash. Normally with a crash like this, the solution is to bounce your layout call out to the main thread, but in our case, I'm not the one calling the layout function. The system (Core Animation) is doing it, and I can't figure out what I might be doing that is triggering it. Everything I am doing is on the main thread, and there's none of my code in this stack trace. It's possible this may have something to do with the SwiftUI hosting view, as well? There's definitely one of those involved here - our custom PDF viewer is embedded in one. (That's another reason to suspect the CATiledLayer - whatever is crashing here is in a SwiftUI hosting view, and the PDF viewer is just about the only UIKit on the screen, here, embedded in a hosting view.) I also have a test app that is pure UIKit, where I have not been able to reproduce the crash. I've tried subclassing CATiledLayer and having an empty implementation of updateSublayers, and some other, similar hacks along those lines, but nothing I do seems to help. I'm tempted to try moving from CATiledLayer to simple UIViews, and tiling those myself, but that's a lot of work. I want to be sure there's not some other solution before I try something like that. Is CATiledLayer still a supported mechanism or should I be moving away from it? If it is something entirely different that is crashing here, I don't want to do a bunch of rework of the PDF viewer only to end up with the same results. It really smells like a UIKit bug to me, or at least UIKit making some concurrency assumptions that CATiledLayer is breaking. But all I can really do is guess. *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread.' *** First throw call stack: ( 0 CoreFoundation 0x00000001804f7348 __exceptionPreprocess + 172 1 libobjc.A.dylib 0x000000018009c094 objc_exception_throw + 72 2 CoreAutoLayout 0x000000022d3cc13c __36-[NSISEngine rebuildFromConstraints]_block_invoke + 0 3 CoreAutoLayout 0x000000022d3cbee0 -[NSISEngine _optimizeWithoutRebuilding] + 68 4 CoreAutoLayout 0x000000022d3cbe14 -[NSISEngine optimize] + 92 5 CoreAutoLayout 0x000000022d3c8744 -[NSISEngine performPendingChangeNotifications] + 100 6 UIKitCore 0x00000001869c7e7c -[UIView(Hierarchy) layoutSubviews] + 132 7 SwiftUI 0x00000001ddb40318 $s7SwiftUI14_UIHostingViewC14layoutSubviewsyyF + 68 8 SwiftUI 0x00000001ddb40358 $s7SwiftUI14_UIHostingViewC14layoutSubviewsyyFTo + 32 9 UIKitCore 0x0000000185642d34 block_destroy_helper.13 + 10136 10 UIKitCore 0x00000001856430c8 block_destroy_helper.13 + 11052 11 UIKitCore 0x00000001869d6ff4 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2656 12 QuartzCore 0x000000018c8fd194 _ZN2CA5Layer15perform_update_EPS0_P7CALayerjNS_17LayerUpdateReasonEPNS_11TransactionE + 452 13 QuartzCore 0x000000018c8fc9e4 _ZN2CA5Layer17update_if_needed_EPNS_11TransactionENS_17LayerUpdateReasonE + 600 14 QuartzCore 0x000000018c908674 _ZN2CA5Layer28layout_and_display_if_neededEPNS_11TransactionE + 152 15 QuartzCore 0x000000018c81d914 _ZN2CA7Context18commit_transactionEPNS_11TransactionEdPd + 544 16 QuartzCore 0x000000018c84da48 _ZN2CA11Transaction6commitEv + 636 17 QuartzCore 0x000000018c89ea8c _ZL21CAImageProviderThreadPjb + 1004 18 libdispatch.dylib 0x00000001033d59dc _dispatch_client_callout + 12 19 libdispatch.dylib 0x00000001033bf728 _dispatch_continuation_pop + 740 20 libdispatch.dylib 0x00000001033f3344 _dispatch_async_redirect_invoke + 700 21 libdispatch.dylib 0x00000001033cf470 _dispatch_root_queue_drain + 356 22 libdispatch.dylib 0x00000001033cffc4 _dispatch_worker_thread2 + 272 23 libsystem_pthread.dylib 0x0000000103276b50 _pthread_wqthread + 228 24 libsystem_pthread.dylib 0x000000010327598c start_wqthread + 8 ) libc++abi: terminating due to uncaught exception of type NSException

Our app, VitalSource Bookshelf, is an EPUB reader that uses a WKWebView to display book content. The EPUB content format is XHTML and uses namespaces (for the epub:type declaration). On beta 4, the webkit process repeatedly crashes when loading our content. The crash appears to be in the XML parser. Here's what's at the top of the stack trace: 0 WebCore 0x19166a878 WebCore::XMLDocumentParser::startElementNs(unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, int, unsigned char const**) + 4968 1 libxml2.2.dylib 0x19c5a2bd0 xmlParseStartTag2 + 3940 2 libxml2.2.dylib 0x19c59e730 xmlParseTryOrFinish + 2984 3 libxml2.2.dylib 0x19c59d8e4 xmlParseChunk + 708 4 WebCore 0x191668ec8 WebCore::XMLDocumentParser::doWrite(WTF::String const&) + 636 5 WebCore 0x191665b78 WebCore::XMLDocumentParser::append(WTF::RefPtr<WTF::StringImpl, WTF::RawPtrTraits<WTF::StringImpl>, WTF::DefaultRefDerefTraits<WTF::StringImpl>>&&) + 304 6 WebCore 0x190105db0 WebCore::DecodedDataDocumentParser::appendBytes(WebCore::DocumentWriter&, std::__1::span<unsigned char const, 18446744073709551615ul>) + 268 7 WebCore 0x190861c3c WebCore::DocumentLoader::commitData(WebCore::SharedBuffer const&) + 1488 8 WebKit 0x18e07ca3c WebKit::WebLocalFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, WebCore::SharedBuffer const&) + 52 9 WebCore 0x190869db4 WebCore::DocumentLoader::commitLoad(WebCore::SharedBuffer const&) + 228 10 WebCore 0x1909521e4 WebCore::CachedRawResource::notifyClientsDataWasReceived(WebCore::SharedBuffer const&) + 268 I was able to reproduce this in Safari on beta 4 just by opening the following trivial xhtml file from the file system - it does the same thing it does in our app, which is reloads and crashes several times, followed by the "A problem repeatedly occurred with..." error message. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" epub:prefix="vst: http://vitalsource.com/"><head></head><body class="dash" epub:type="chapter" data-begin-o="0" data-begin-o2="0" data-begin-o3="0" data-o="0" id="eid1844" data-end-o="14703" data-end-o2="14703" data-end-o3="14703"><h2 class="title" data-o="0" id="eid1845" data-out="33"><span class="label" data-o="0" id="eid1846"><span class="label-inner"><b data-o="0" id="eid1847">CHAPTER X</b> </span></span>THE SUBMARINE COAL-MINES</h2></body></html> I've also filed a feedback. But posting here just to raise the visibility - this is critical for us. I think it was introduced in beta 4; that's at least when we first noticed it. It was working in the earlier betas, I just don't remember if I tried beta 3 or not. It happens on iOS, macOS, and iPadOS. This has never been a problem in any earlier release of macOS / iOS.

I'm running into a seemingly unsolvable compile problem with the new Xcode 26 and Swift 6.2. Here's the issue. I've got this code that was working before: NSAnimationContext.runAnimationGroup({(context) -&gt; Void in context.duration = animated ? 0.5 : 0 clipView.animator().setBoundsOrigin(p) }, completionHandler: { self.endIgnoreFrameChangeEvents() }) It's very simple. The clipView is a scrollView.contentView, and "animated" is a bool, and p is an NSPoint It captures those things, scrolls the clip view (animating if needed) to the point, and then calls a method in self to signal that the animation has completed. I'm getting this error: Call to main actor-isolated instance method 'endIgnoreFrameChangeEvents()' in a synchronous nonisolated context So, I don't understand why so many of my callbacks are getting this error now, when they worked before, but it is easy to solve. There's also an async variation of runAnimationGroup. So let's use that instead: Task { await NSAnimationContext.runAnimationGroup({(context) -&gt; Void in context.duration = animated ? 0.5 : 0 clipView.animator().setBoundsOrigin(p) }) self.endIgnoreFrameChangeEvents() } So, when I do this, then I get a new error. Now it doesn't like the first enclosure. Which it was perfectly happy with before. Here's the error: Sending value of non-Sendable type '(NSAnimationContext) -&gt; Void' risks causing data races Here are the various overloaded definitions of runAnimationGroup: open class func runAnimationGroup(_ changes: (NSAnimationContext) -&gt; Void, completionHandler: (@Sendable () -&gt; Void)? = nil) @available(macOS 10.7, *) open class func runAnimationGroup(_ changes: (NSAnimationContext) -&gt; Void) async @available(macOS 10.12, *) open class func runAnimationGroup(_ changes: (NSAnimationContext) -&gt; Void) The middle one is the one that I'm trying to use. The closure in this overload isn't marked sendable. But, lets try making it sendable now to appease the compiler, since that seems to be what the error is asking for: Task { await NSAnimationContext.runAnimationGroup({ @Sendable (context) -&gt; Void in context.duration = animated ? 0.5 : 0 clipView.animator().setBoundsOrigin(p) }) self.endIgnoreFrameChangeEvents() } So now I get errors in the closure itself. There are 2 errors, only one of which is easy to get rid of. Call to main actor-isolated instance method 'animator()' in a synchronous nonisolated context Call to main actor-isolated instance method 'setBoundsOrigin' in a synchronous nonisolated context So I can get rid of that first error by capturing clipView.animator() outside of the closure and capturing the animator. But the second error, calling setBoundsOrigin(p) - I can't move that outside of the closure, because that is the thing I am animating! Further, any property you're going to me animating in runAnimationGroup is going to be isolated to the main actor. So now my code looks like this, and I'm stuck with this last error I can't eliminate: let animator = clipView.animator() Task { await NSAnimationContext.runAnimationGroup({ @Sendable (context) -&gt; Void in context.duration = animated ? 0.5 : 0 animator.setBoundsOrigin(p) }) self.endIgnoreFrameChangeEvents() } Call to main actor-isolated instance method 'setBoundsOrigin' in a synchronous nonisolated context There's something that I am not understanding here that has changed about how it is treating closures. This whole thing is running synchronously on the main thread anyway, isn't it? It's being called from a MainActor context in one of my NSViews. I would expect the closure in runAnimationGroup would need to be isolated to the main actor, anyway, since any animatable property is going to be marked MainActor. How do I accomplish what I am trying to do here? One last note: There were some new settings introduced at WWDC that supposedly make this stuff simpler - "Approchable Concurrency". In this example, I didn't have that turned on. Turning it on and setting the default to MainActor does not seem to have solved this problem. (All it does is cause hundreds of new concurrency errors in other parts of my code that weren't there before!) This is the last new error in my code (without those settings), but I can't see any way around this one. It's basically the same error as the others I was getting (in the callback closures), except with those I could eliminate the closures by changing APIs.

I noticed a change from previous betas when I attempted to compile my code with Xcode 16 beta 5. If I have a class that is MainActor isolated, and it overrides init(), it looks like this init is always considered nonisolated now, even for a MainActor isolated class. This was not the case before. For example, I have a class that inherits from NSScroller. It defines a default initializer init() which calls the designated initializer - super.init(frame:CGRect()). This is apparently not allowed right now. If that's the case, how can one even default-initialize a class??? It also doesn't let me initialize other properties, since everything is MainActor isolated. Here's an abbreviated example. class MyCustomScroller : NSScroller { init () { super.init(frame: CGRect()) scrollerStyle = .overlay alphaValue = 0 } } This was allowed in prior betas. However, in beta 5, all 3 lines of my init generates an error such as: Call to main actor-isolated initializer 'init(frame:)' in a synchronous nonisolated context or Main actor-isolated property 'scrollerStyle' can not be mutated from a nonisolated context Is it just no longer possible to default-initialize MainActor classes, such as NSViews, now? The first line is particularly problematic because if I change it to just call super.init() then I get this error instead: Must call a designated initializer of the superclass 'NSScroller' You must call the designated initializer ... oh wait, we won't let you. Too bad.

I am running into some Swift 6 concurrency errors that I think are due to an odd oversight in the UIAccessibility Swift interface. There are a number of constants defined in here for various things, most of which are marked "let" (appropriately). However, the constants for notifications in extension UIAccessibility.Notification are all marked as var for some reason. For example: public static var pageScrolled: UIAccessibility.Notification Because it is var, not let, anytime I try to access it, I get a concurrency violation. I am baffled as to how I am supposed to work around this. For example, this line of code: UIAccessibility.post(notification: .pageScrolled, argument: "test") gives the error: "Reference to static property 'pageScrolled' is not concurrency-safe because it involves shared mutable state" I can't for the life of me figure out how to work around this. I guess maybe define my own constant somewhere and suss out the rawValue somehow for now? This really needs to be fixed in the SDK.

I'm working on Swift 6 concurrency support for our app. I've always thought of NSAccessibilityElement as being like all of the other UI classes- only used (or usable) on the main thread. As far as I've seen, they are always called on the main thread. But in Xcode 16 beta 2, it's only marked as Sendable but not MainActor. Is that just an oversight or do we need to worry about these being used / called on threads? It's easy enough to do the async work (well, not that easy), but I don't want to do all that work if Xcode 16 beta 3 is just going to add a MainActor to it. I've already been burned by that once, in WebKit- the first beta was missing several MainActor declarations, in places where it was unclear from the documentation. I added a bunch of async fixes to my delegates, only to have to take it all out when the second Xcode beta shipped and the SDK headers changed. How complete are the async declarations in the Xcode 16 SDKs?

I need to be able to interpret the values in AVSpeechUtterance's rate parameter as words per minute. It looks like it is just an opaque 0.0 - 1.0 value with 0.5 as the default. The old NSSpeechSynthesizer API lets you specify a rate as words-per-minute, but there doesn't appear to be any mapping to the new values. Should I just file a Feedback request for this feature? I'd be fine if there was just some sort of API to return the WPM for a given rate value (or visa-versa), or even just document a multiplier equation I could use to do the mapping. Or maybe it ever varies depending on the voice? If we can't have words-per-minute, even just a way to figure out a multiplier (where 1x is the default speed, 2x is 2 times the default speed, etc) would be helpful. We just want some kind of text label describing the speed, in units that make logical sense to a user, and that can be exposed to accessibility. 0.0 / 0.5 / 1.0 just isn't terribly descriptive.

I'm working with UIScrollView and wishing I had more control over when the scroll indicator is visible. It looks like the scroll indicator's visibility is entirely controlled by the internals of the gesture handlers and there's very little customization available. We can hide the indicators entirely, so they don't show up when the user scrolls, and we can briefly flash them to indicate where they are when a view first appears. But neither of these things covers exactly what I need. My UI has 3 vertical UIScrollViews in a horizontal line. The middle one is actually a WKWebView. On either side of the web view, to the right and to the left of it, are the two UIScrollViews. These scroll views have buttons that are lined up with content in the web view. Whenever the user scrolls in any one of these three views, the other two are scrolled programmatially to match using setContentOffset(animated:false), to give the illusion of one single scroll area spanning the screen. For the most part, this works extremely well. What breaks this illusion is the scroll indicators in each scroll view. Whenever you scroll in a view, the scroll indicator appears to the right of that scroll view, which for the left and middle views appears to be in the middle of the screen. These get very distracting. What I'd really like is for there to be a single scroll indicator in the right-most UIScrollView that is visible whenever I am scrolling any of the three scroll views, and then just always hide the others. I can mostly accomplish this by setting showsVerticalScrollIndicator to false for the middle and left views, and then setting this property to true for the right one. The problem with this is, then I only see the scroll indicator when I am scrolling in the rightmost UIScrollView. I want to be able to programmatically tell the rightmost view to show its scroll indicator whenever I am scrolling in the other two views. The interesting thing is, if the scroll indicator is in the process of either showing, or fading in / out, then scrolling it programmatically does exactly what I want - it does keep the indicator visible and moves it like you'd expect. I just want to be able to programmatically kick it into that state without the user actually interacting with it. Flashing the scroll indicator whenever I programmatically scroll seemed like maybe an option, but it is not the same. It just ends up briefly flashing when I stop scrolling, or when I stop moving the scroller. It's more distracting than helpful. I have the same UI in AppKit using NSScrollViews. NSScrollView actually does exactly what I want, with its overlay scroller appearance. By default, the right view's scroller is hidden. When you scroll it programmatically, it shows the scroll indicator, scrolls it along, and then (after a brief period of not getting calls to move the scroller) it autohides again. This AppKit behavior fits my needs really well. I just want some way to do the same thing with UIScrollView. Building my own custom scroll indicator and drawing it myself is probably an option but that is probably a fair amount of work? Especially trying to match the system behavior exactly. I try to avoid custom UI when possible to avoid breaking with future OS updates.

I have "Show line numbers" turned off. But today Xcode 13 started randomly showing line numbers in the left sidebar even though I don't want it to. If I turn the preference to show line numbers on and then back off again, they go away. For a while. They ... keep ... coming ... back. I've tried quitting and relaunching Xcode but it doesn't seem to have helped. Any ideas? Seems like a bug. I may have to start learning to live with them. It seems like it might have started when I used the feature to compare a file with historical versions of it in git. I think it shows line numbers when you're in that view? But I'm not looking at that anymore and they are still randomly reappearing in my code files. (The new GUI for viewing that is much more confusing to find than the old one, too.) Sorry this is a minor thing but it is making me crazy.