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.

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