Hi all - figured I would kick off with a CloudKit question. Recently in development of a multi-device app I got into a state where all iOS devices could not write to the (production) CloudKit container - however macOS could still write (multi-device SwiftUI code). After ruling out a lot of other things it seemed like there had been some corruption in the production zone's PCS key chain. The only fix was deleting the zone from the CloudKit Console (safe for my pre-release beta data, but destructive). Is there a safer or developer-accessible recovery path for PCS chain corruption? Is this situation detectable earlier, or is there guidance on avoiding it during pre-release testing? The error in the logs in this scenario had "overallStatus":"USER_ERROR", "error":"BAD_REQUEST", "returnedRecordTypes":"_pcs_data".

I'm new to Xcode cloud - working with a Mac OS app, build is working great. Now I am trying to add a Test action; the testing target builds but won't run, and the error indicates it can't find the testing bundle in the expected build output. There's also mention of a code signing error, but I have automatic code signing enabled with the same settings on test target as the app. I am only running the unit test (XCTest) scheme, not the UI tests. When I run it locally from the IDE it works fine, either selecting the test scheme explicitly or as the test step of the app scheme. I notice the XCTest target's scheme setup uses Debug builds and expects the test output to be in the Debug .app bundle, I thought perhaps that was the problem (in case only the release app bundle actually gets built in the Xcode Cloud environment). So I created a duplicate scheme and set the build targets to Release - again I can run this fine locally (after creating a release build), but it fails with the same error in Xcode cloud. I also tried changing the code signing certificate from "Development" to "Sign to run locally" to see if that made a difference, but I get the same error. (It's using my developer account Team, and "Automatically manage signing".) Can anyone relate the proper way to set up an XCTest scheme so that the tests will actually run in a Mac OS Xcode Cloud workflow? I'm using Xcode 14.0.1. Here's the full error output, with [AppName] and [TestTargetName] substituted for the actual: [AppName] (....) encountered an error (Failed to load the test bundle. If you believe this error represents a bug, please attach the result bundle at /Volumes/workspace/resultbundle.xcresult. (Underlying Error: The bundle “[TestTargetName]” couldn’t be loaded. The bundle couldn’t be loaded. Try reinstalling the bundle. dlopen(/Volumes/workspace/TestProducts/Debug/[AppName].app/Contents/PlugIns/[TestTargetName].xctest/Contents/MacOS/[TestTargetName], 0x0109): tried: '/Volumes/workspace/TestProducts/Debug/[TestTargetName]' (no such file), '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/lib/[TestTargetName]' (no such file), '/Volumes/workspace/TestProducts/Debug/[AppName].app/Contents/PlugIns/[TestTargetName].xctest/Contents/MacOS/[TestTargetName]' (code signature in <....> '/Volumes/workspace/TestProducts/Debug/[AppName].app/Contents/PlugIns/[TestTargetName].xctest/Contents/MacOS/[TestTargetName]' not valid for use in process: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?)))) Thanks!

I'm getting an error building my Mac app for both Apple Silicon and Intel, related to a Swift package dependency. The dependency is a pure Swift package (SwiftyXMLParser), and I'm bringing it into my app with a package dependency from the git repository URL. My app is configured to build standard architectures to run natively on both Apple Silicon and Intel. The build fails because it looks like the package manager only provides the active architecture, not a universal library, when the latter is configured. It happens when I set "Build Active Architecture Only" to NO (if it's set to YES it succeeds, but then the app won't run on the other architecture). In particular, if I build on my M1 mini, the error is Could not find module 'SwiftyXMLParser' for target 'x86_64-apple-macos'; found: arm64, arm64-apple-macos If I build on my x86 MBP, same failure but the error is opposite (no arm64, found: x86_64). So clearly SPM+Xcode can provide either architecture - is it possible for it to provide a universal lib? Or do I need to download the source of the package and build it through a more manual process?

Customers of an app I work on are having some issues on MacBook Pros with external monitors, which don't occur if the Automatic Graphics Switching is turned off. This is on more recent OS versions (Big Sur, Monterey). Is there a reliable way to check programmatically if this preference setting is turned on, so the app could at least alert the user? I've looked at the com.apple.PowerManagement files in /Library/Preferences, however I don't see any key-values in those files changing when I change this setting (tried rebooting system after changing etc.). Online I've seen some reference to use of the pmset command-line tool to check this however I also do not see its output reflecting any change, and I see conflicting notes on what field might correspond to this setting. Is there any definitive answer or documentation around this setting? Thanks in advance!

As someone who learned to program on Mac OS 7.5.5, I don't mind the return of Clarus the dogcow! However others on my team are wondering if there will be a way for our app to still use the system Page Setup dialog, but not display Clarus (basically retain the appearance of Monterey's Page Setup). Anyone know what the plan is for Clarus in the official Ventura release? Will it be possible to hide the dogcow, or substitute a different preview graphic?

This is a fairly bizarre behavior and I wonder if anyone with deep knowledge of NSView layout internals has a clue. I have a view that hosts a number of toolbar-like buttons, some subclasses of NSButton and other subclasses of NSPopUpButton. The latter are used in pull-down mode and do not display a title (just a pull-down indicator and icon), they are similar in size and appearance to the NSButtons. When the app is switched between light mode and dark mode, some layout action is triggered which always adds 5 pixels of widths to the pull-down buttons. When I override setFrame and set a breakpoint, this is happening below NNAApplication nextEventMatchingMask in an undocumented function called NSViewActuallyUpdateFromLayoutEngine. This method always adds 5 pixels to width for repeated light/dark mode changes. It does so on a pull-down even if it has already done so before, so these controls just keep growing, and this does not seem to be related to any obvious intrinsic content. Some things I would note in trying to track it down: It only happens to the popup buttons, not the regular NSButtons in the same superviews I have some of these in a horizontal stack view and some positioned statically in a regular NSView - both scenarios get this 5-pixel-width-resize I've tried overriding both instrinsicContentSize and fittingSize to return the current frame size, as a way to tell the layout system not to change the size, and that didn't work There are no explicit constraints created for these views; they are created in code not in Interface Builder I've tried using the autolayout mask value NSViewNotSizable with the translates flag set to YES, that does not prevent the issue I've tried setting the superview autoresizesSubviews flag to false and also making sure translates flags were false to not create unwanted constraints, these also do not prevent the issue The only code values I had related to 5 pixels were a spacing setting and a left inset on the horizontal stack view - so I removed those as a check, but as I'd expect that did not change the behavior The only way I've been able to defeat it is to add a .sizeLocked property to my subclass and, if set, replace the incoming frame.size with the current one to prevent the resize while still allowing origin to change. Obviously that's not ideal but as a brute-force workaround it works for this specific issue. However I'm seeing other weird layout creep as well on repeated light/dark change. I wonder why this happens, and what the correct fix might be! Why is dark/light mode switching resizing anything in layout, when the size of windows and views have not changed?

My team is working on the arm64/universal conversion of a large application with lots of third-party dependencies, but while that work is in progress we are trying to support customers running the app under Rosetta on M1 macs. To that end it will be helpful if we can actually debug the x86&#92;&#95;64 build running under Rosetta on M1, but we see lots of instability when we try this. The app will not even launch if the thread sanitizer setting is turned off. Sometimes the app still fails to launch and/or the debugger fails to attach. It will sometimes show the error message "LLDB provided no error string". No breakpoints are hit during attempted debugging. Note the app is a plugin host, and we sometimes see a main queue crash on ImageLoader::recursiveInitialization when we attempt to debug. Is debugging a non-trivial x86&#92;&#95;64 app under Rosetta on an M1 machine supported by Xcode? Are there any special configuration steps to get it to work? (We can debug a trivial Hello World x86&#92;&#95;64 app fine this way so it seems to be related to more complex app architecture). Also FWIW we tried launching Xcode itself under Rosetta on the M1 machine as well to see if that would resolve any debugging conflicts, but it didn't correct these issues. Thanks for any guidance!

I'm implementing a horizontal NSStackView with child views of varying size. The stack view should resize horizontally with its parent view, which in turn resizes with the window. I expect the stack view's arranged distribution (fill proportionally) to adjust the distribution of child views as its width changes. I keep hitting the bizarre behavior where the window can't be resized horizontally at all - the vertical/diagonal resize cursors no longer appear, and the window can only be resized vertically. The problem is not that the child view doesn't resize with the window: the child view actually prevents resizing of the window! I first saw this creating an empty NSStackView and adding it to its parent view in code, with layout constraints (top, leading, trailing; also tried width). I tried messing with constraint priorities but that did not correct the issue. (With the stack view not there, its parent view resizes with the window just fine). When I created the NSStackView in the .xib this problem went away, the empty NSStackView resizes horizontally along with its parent, so that's what I'm doing now. However, now when I add a set of arranged subviews in code, it happens again - they are distributed perfectly, but the window again cannot be horizontally resized! The subviews are minimal NSView implementations (drawing their bounds); they do not have intrinsic size. They do each have child NSTextField labels, with autolayout constraints to horizontally resize along with their parents. There are no constraints besides those internal to each child view and its label subview. What am I not understanding about AutoLayout and NSStackView? I cannot imagine an intentional design that would break the user's ability to resize the window in one direction based on anything an NSStackView does, but that's exactly what happens.

I'm investigating some font/typography issues in a creative application. I am hoping for some information from Apple developers who know how font activation works in Core Text, and how/whether auto-activation is still supported. I'm running on Big Sur in an Obj-C Cocoa app. In applicationDidFinishLaunching the app calls CTFontManagerSetAutoActivationSetting(NULL, kCTFontManagerAutoActivationEnabled); After this, what is the correct API to request auto-activation of a font that may not be active but could be activated, e.g. by a third-party font manager? I have tried using CTFontCreateWithNameAndOptions. For options, I see there is an CTFontOption value kCTFontOptionsPreventAutoActivation - I assume that as long as I don't set this option, the call will attempt auto-activation. However, I don't see any auto-activation resulting, either from the third-party font manager or the OS. Instead CTFontCreateWithNameAndOptions always returns a substitute font (Helvetica). The font I am attempting to auto-activate is an OTF. It is stored in a third-party font manager, and I also have copies of it on the desktop. I have also tried having it present / disabled in FontBook, which also does not auto-activate it in this case. I've also cleaned font caches after making changes. How is the kCTFontManagerAutoActivationEnabled supposed to work in Big Sur? Is there a different Core Text call used to auto-activate a font, or is this behavior no longer supported? Thanks!