After upgrading to Xcode 16.3, whenever I open the Documentation window, Xcode started CPU hungry mode, forever. Does anyone else have the same experience as me? Is there any known remedy so far?

This question is related to this post (of mine). It seems default build settings do not include dSYM files needed when uploading embedding app package. But now Xcode issues new warnings about this. Now the question - how do I tell Xcode to create dSYM files for me, say when I build My.Framework? I asked AI chatbot which tells me that for release build I need to : set "Debug Information Format" to DWARF set "Strip Debug Symbols During Copy" to off I have item 1 turned on (which I believe is the default). But item 2 is on, maybe that's the reason I do not have dSYM files in final built My.Framework. Should I turn "Strip Debug Symbols During Copy" off?

I get many warnings like this when I build an old project. I asked AI chatbot which gave me several solutions, the recommended one is: var hashBag = [String: Int]() func updateHashBag() async { var tempHashBag = hashBag // make copy await withTaskGroup(of: Void.self) { group in group.addTask { tempHashBag["key1"] = 1 } group.addTask { tempHashBag["key2"] = 2 } } hashBag = tempHashBag // copy back? } My understanding is that in the task group, the concurrency engine ensures synchronized modifications on the temp copy in multiple tasks. I should not worry about this. My question is about performance. What if I want to put a lot of data into the bag? Does the compiler do some kind of magics to optimize low level memory allocations? For example, the temp copy actually is not a real copy, it is a special reference to the original hash bag; it is only grammar glue that I am modifying the copy.

I currently do not want to upgrade to macOS 26, but I still want to install the latest Xcode. Is it required to install macOS 26 if I were to get Xcode 26?

My app observes NSWorkspaceActiveSpaceDidChangeNotification and set wallpaper on the active screen. But I see there is no way to distinguish between spaces on a screen. I'm not sure if I have read the docs thoroughly. I would like to know if it is possible to tell which space is active for the active screen.

On my 27in monitor, the doc text is too small for reading. Is there any way to enlarge text size? Maybe I should file a ticket to request for a new feature for this?

I am a little hesitant to ask this question because it's been years, during which I hoped it's just a specific problem of my own computer or Xcode version. I'm not sure if it's only me alone with this problem. First time run of any playground project is extremely slow (after I open it); sometimes it just never runs with the build indicator circling forever). This is true for objc or swift playgrounds, or different machines, different Xcode versions, different OS versions. Can anyone help?

I have a need to integrate icu (https://formulae.brew.sh/formula/icu4c#default) into one of my store apps. I'd like to know if this approach is supported by the app submission policies. Thanks.

I once enabled locate (not location) service but now I want to disable/remove it. It's really not very helpful compared to spotlight. What is the correct commandline?

When I log in and start a Terminal window, a simple gcc command produces the following debug messages: 2022-07-15 13:52:41.470 xcodebuild[784:10833] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionSentinelHostApplications for extension Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in com.apple.dt.IDEWatchSupportCore 2022-07-15 13:52:41.470 xcodebuild[784:10833] Requested but did not find extension point with identifier Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in com.apple.dt.IDEWatchSupportCore Subsequent invoke of gcc does not produce these messages. How to avoid this small nuisance?

I have a custom view that acts as a container for many NSImageViews that will be created dynamically on the fly. When the container view is resized (by parent window), some new subviews may be created and added to the container view, or some subviews may be removed because they are not fit into a smaller view. I have two ways to handle the 'disappearing' subviews. One way is to hide them, the other is to remove them from the container view. My concern is that - Is there a (big) performance difference between the two methods? Which is better?

I did searches on the Internet but could not find a definitive answer. The best thing I get is CGImageSourceCreateThumbnailAtIndex API function. But I don't know how create CGImageSource out of an NSImage object. Thanks for any suggestions.

I am aware of the following approach: Add a custom view into a view in IB. Set the class of this custom view, say "MyDatePickerView". Now my datepicker view has a moderate complex UI, and I want to isolate its functionalities into a standalone XIB. Is it possible to do this in IB (I know I can do it in code)?

I really like to implement an overlay that is similar with what we have in NSDatePicker: I know most of the time, we just use what Apple gives us behind the curtain, but I really want to know if this even possible. Thanks!

I think I can do this by creating a custom view overriding the following 2 methods: @implementation MyTextField - (BOOL)becomeFirstResponder { NSLog(@"%s: %@", __func__, self); return [super becomeFirstResponder]; //return YES; } - (BOOL)resignFirstResponder { NSLog(@"%s: %@", __func__, self); return [super resignFirstResponder]; //return YES; } @end But there is a gotcha - I always get successive become/resign. That is when I get becomeFirstResponder, I also get resignFirstResponder immediately. Note - I only have one MyTextField instance on my window. Is there another safe way to achieve my goal?