As of Xcode 15.4 (and possibly earlier), Xcode does does not build all architectures for a target when 'Build Active Architecture Only' (ONLY_ACTIVE_ARCH) is set to 'No'. Instead, the run destination ('My Mac' vs 'Any Mac') appears to completely override that setting. The help documentation blurb for ONLY_ACTIVE_ARCH states the run destination is only used when the build setting is enabled, and that was indeed the case in earlier versions of Xcode. Has the expected behaviour of that setting changed?

I'm implementing a non-consumable IAP for our app using StoreKit2. After making a purchase using a sandbox account, then revoking the purchase history for that account, Transaction.currentEntitlements still contains a valid purchase transaction. My understanding is that transactions should be updated in the background (via Transaction.updates), but is there something else that needs to happen to properly revoke the purchase?

Since the type identifiers in UTCoreTypes.h have been deprecated, what's the expected way to use the Core Graphics APIs that use those types, particularly in C code that doesn't have access to the UniformTypeIdentifiers framework? Using CFSTR( "public.jpeg" ) works, but is that the new best practice, or have the core type definitions been moved/renamed?

I have Mac OS application with several embedded frameworks. When debugging the application in recent versions of Xcode (comfirmed in 14.2) I am no longer able to inspect opaque C structs defined in a framework when the debugger has stopped in code belonging to the application or a different framework. The application and frameworks are all compiled by me as part of the application workspace, all have debugging enabled, and all are properly generating dSYM files. Does anyone know what might be going on? This is making debugging the framework code very difficult.

I'm seeing a strange rendering glitch with Metal rendering on (at least) two laptops, both are Intel MacBook Pro 13" 2020 with 4 Thunderbolt ports (my own is the i7 model). Thus far this is the only Mac model we've seen the issue on. The glitch results in a single-frame red pattern (see the attached image), but only when running full screen on the laptop display. It does not show when running in a window or in full screen on an external display. Even having an external display attached seems to prevent the problem. The glitch typically appears on frames where we do little to no rendering beyond clearing the color buffer, however I've been unable to isolate the glitch in a test application. The glitch also only happens when using the MTLPixelFormatRGBA8Unorm pixel format for the colour buffer. Switching to MTLPixelFormatRGBA16Float prevents it from happening. I've played around with the load/store states on the colour buffer, with various clear values, all with no success. Furthermore, I've managed to inspect the frame in a Metal GPU capture, and the color buffer in the capture is correct (cleared to black) even though the contents of the view are glitched. This leads me to think the problem may be in the CA compositing step, rather than in the Metal rendering itself. Any suggestions?

The application I'm working needs access to a shared network drive while in development. This nominally works, but every time the app is recompiled (so hundreds of times a day), I have to give it permission to access a network volume. For obvious reasons, that isn't helpful. Does anyone know how to grant network share access permanently? Barring that, is there a way to disable that security setting, preferably with a capability/entitlement, or at the system level as a last resort? (The app does have the proper credentials granted in System Preferences, but I presume its signature or something changes with each recompile.)

The Leaks instrument is suddenly giving me the error "Required kernel recording resources are in use by another document." I see this has come up with Xcode 12 on iOS, but now it's happening when profiling a Mac application on Monterey 12.3.1 and Xcode 13.3. I get the same behaviour on a debug or release build. The Allocations instrument on its own also gives the same error. The Time Profiler intrument launches without issue. Regardless of the (useless) error, it's possible this is a signing issue, since Intruments is also constantly asking for a password when launching the process. Does anyone have any insight into what is causing this?

I have a command line tool that zsh refuses to run when built for Apple Silicon or as a univerisal binary (the specific message is zsh: killed TOOL_NAME). I can only get it to run if I build it exclusively for Intel/Rosetta. Running/debugging from within Xcode works fine for any architecture. The tool is a very simple C/C++ unix command-line tool; it doesn't have any external dependencies beyond the C runtime and the C++ STL. I suspect something in code signing is going awry, but I've tried various team and certificate combinations without any luck. I've also tried enabling/disabling the app sandbox, also without any luck. (The app is not for distribution so it doesn't really need to be code signed at all.) Any suggestions?

I have two iMacs where MTLDevice.currentAllocatedSize is acting strange--the reported size keeps rising, despite periodically freeing resources to keep under MTLDevice.recommendedMaxWorkingSetSize. The affected iMacs are both late 2014 models running MacOS Big Sur 11.6, one with an AMD Radeon R9 M290X and the other with an AMD Radeon R9 M295X. So far none of our other Macs have shown this behaviour, which suggests this may be an API or driver problem. I do have the option of using my own resource size estimates, but that's likely not as accurate as what the system reports, assuming MTLDevice.currentAllocatedSize is working properly. Any suggestions?

I've run into two (possibly related) problems involving mipmaps in BC7 RGBA Unorm textures. The first, and more serious, is a crash when uploading the last mipmap level of a texture. Thus far this has only happened on two machines, both running Catalina. Also, only certain textures cause the crash, but there doesn't seem to be anything unusual about them. From the crash reports: MacOS 10.15.7 19H1519, Intel Graphics 4000 (this is from a debug, single-threaded build) Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.driver.AppleIntelHD4000GraphicsMTLDriver 0x00007fff25cff33d CpuSwizzleBlt + 11667 1 com.apple.driver.AppleIntelHD4000GraphicsMTLDriver 0x00007fff25ce7ca0 -[MTLIGAccelTexture replaceRegion:mipmapLevel:slice:withBytes:bytesPerRow:bytesPerImage:] + 1387 2 com.apple.driver.AppleIntelHD4000GraphicsMTLDriver 0x00007fff25ce7e2f -[MTLIGAccelTexture replaceRegion:mipmapLevel:withBytes:bytesPerRow:] + 74 MacOS 10.15.7 19H1419, Intel Graphics 5000 (this is from a release, multi-threaded build) Thread 9 Crashed: 0  com.apple.driver.AppleIntelHD5000GraphicsMTLDriver         0x00007fff2973b9c0 CpuSwizzleBlt + 9224 1  com.apple.driver.AppleIntelHD5000GraphicsMTLDriver         0x00007fff2972714b -[MTLIGAccelTexture replaceRegion:mipmapLevel:slice:withBytes:bytesPerRow:bytesPerImage:] + 1385 2  com.apple.driver.AppleIntelHD5000GraphicsMTLDriver         0x00007fff297272c3 -[MTLIGAccelTexture replaceRegion:mipmapLevel:withBytes:bytesPerRow:] + 64 I'll post the full crash reports to Feedback Assistant. The second problem only happens on Mojave, and results in what looks like garbled pixel data in the mipmaps (I don't have access to the machine to do a frame capture). I can work around this issue by disabling mipmaps in the texture sampler. There are no Metal validation errors, and neither problem happens on Big Sur (I don't yet have a Monterey machine). Uncompressed textures are fine, as well, although mipmaps for those are generated on-the-fly rather than uploaded. Padding the source pixel data doesn't help, so the seg fault likely isn't caused by a too-large or unaligned read. Has anyone else run into problems with mipmaps in BC7 compressed textures?

In Xcode 13, when pressing return on a line with a triple-slash comment, the editor automatically inserts another triple-slash on the new line. Also, it's still deleting both parentheses in a pair when I only delete the first one. Does anyone know how to turn this off? It's extremely disruptive.

I noticed the MTLDevice API for MacOS 11 includes an API to check for BC texture support (supportsBCTextureCompression), which suggests BC formats are not necessarily supported on some MacOS systems regardless of GPU family. This could obviously impact what textures need to be shipped with my application since I was planning on including only ASTC formats for iOS and BC formats for MacOS to help reduce the package size. I have a few questions around this: Under what circumstances are BC formats NOT supported on MacOS? What compressed formats are available on a MacOS system that doesn't support BC compression? Does a Catalyst app need different texture formats when running on iPadOS vs. MacOS? (This question is largely academic since I don't plan on shipping a Catalyst app.) Also, any links to documentation that outlines different scenarios would be greatly appreciated.

I have a strange problem affecting two iMacs (Retina 5K, 27", late 2014) running MacOS Mojave 10.14.6. After the compture has been running for a while, some textures can either appear pure blue (i.e. #0000ffff) or become garbled in other ways. While I don't have physical access to the affected computers, I do have GPU trace from one that confirms that the texture data itself is definitely the problem. The affected textures are all loaded from disk via CGImage. Not all textures are affected, and those that are do not always show this behaviour--it appears to be specific to certain situations. Reloading the affected textures will sometimes correct it. Rebooting the computer seems to temporarily fix the problem, which suggests this may be an issue with the video driver or GPU. This doesn't seem to affect any of our other Macs, including my 2020 Macbook Pro 13" (Big Sur) and 2012 Macbook Air (Catalina). Any thoughts on what could cause this, or suggestions on how to investigate further?

I've run into a weird problem trying to use an XBox One Wireless gamepad via the GameController SDK. The controller works fine on two different Macs running Big Sur (and previously worked under Catalina), but is reported as a GCMicroGamepad on an iMac running Mojave. I can't seem to find a list of devices supported by the GameController framework, but I assumed the XBox One controller was a safe bet. Is this device not supported on the older OS?

I have a C library that compiles to a framework for MacOS/iOS and to a static/shared library on other platforms. Since updating to Xcode 12 I've run into the warning about double-quoted headers in a framework umbrella header and I'd like to update the library to be more "correct", but doing so results in name/path conflicts for the library headers. When another project references the library, a header can be located via <framework/header.h>, yet when building the library that path is incorrect. That is, the path to the header within the project structure is not the same as when packaged as a framework (or, for instance, when installed to /usr/local/include). This is a problem with dependencies between library headers. Futhermore, when building, the project must use the version of the headers located within the project directory--not those previously installed in some system include path. According to the C spec, including via angle brackets is supposed to search for headers in the system include paths--not relative to the current directory--so how does using angle brackets in the umbrella header even work reliably in the first place? It feels like I'm missing something obvious, here.