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!

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?

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!

Our Mac app targets 10.13 and later. A number of minor but hard to fix appearance issues showed up in an NSOutlineView after we updated to Xcode 12 and the latest SDK. The outline view is created in code (not from .xib) and is view-based. When the outline view has top-level parents toggled open and you scroll down, the topmost parent will 'freeze' in place in the first row of the table to show what container you are in. This still functions properly, however under 10.15.x and earlier our outline view apparently no longer draws an opaque control background on the table row, so you see the child item view contents scrolling up behind the frozen parent row, making it illegible. This bug does not occur on Big Sur, where it still appears correctly. It also appeared correct on older OS's right up until we updated to the latest Xcode / SDK. There have been a few other appearance changes in NSOutlineView that were solely caused by this update, so this makes me think that this is due to some change in the NSOutlineView implementation. The Big Sur release notes mention only a change in default row height (which we did see and were able to fix easily). Can anyone offer guidance on how to make a table row (not cell) explicitly opaque in the latest SDK's NSOutlineView, and have it work properly on earlier OS's? Also is there any release note on this granularity of change in the SDK that might offer guidance, apart from the Big Sur release notes? Thank you!

I'm working getting a large app to Universal Binary, which uses a number of libraries and frameworks with third-party dependencies, a few of which are not yet available as arm64. If a framework is marked as Optional in the app's build settings, the app will still link when it is absent. I expected that if the framework only had one architecture needed for UB (e.g. just x86_64), we should be able to optionally link it successfully, and it would not matter if one architecture was missing. However this isn't how Xcode handles it, we get a linker error for the missing architecture even if the framework is optional. Is there a way to do what I'm expecting? Include an optional framework with only one architecture in a UB app, with the app taking responsibility for correct handling of the framework at runtime (just as it would for a missing optional framework in a single-architecture app)?

I'm working on a substantial Mac AppKit app that has a large number of third-party libraries and frameworks, mostly C++. I'm getting a crash on initialization of some boost::asio code that I'm fairly sure indicates different versions of boost referenced by one or more linked libs. However I can't tell from the stack trace exactly which library is causing the issue - the caller of the boost code is just ::__cxx_global_var_init.10(). I see some other forum threads about crashes in ImageLoaderMachO but they tend to focus on fixing a specific crash - I have a slightly more general question. Are there some advanced techniques for debugging and analyzing the pre-main() work done by ImaeLoaderMachO()? I'd like to fix this crash (which I'll explore through some trial and error) but more than that I'd like to have a deterministic way to see - ideally, even breakpoint - all code that gets executed before main() to understand this app's startup/load behaviors. Thanks for any wizardry!

Is anyone able to view the Platforms SOTU 2021 video? In both the Developer app and online it just shows a static image. (Keynote video works fine). In the Developer app it says Monday 2 - 3:30 PM, it's now 4: 34 PM... is it not available for replay? Also FWIW, even though it hasn't shown the video, the Developer app actually now says "Rewatch SOTU" under the link. Online, link with no video: https://developer.apple.com/videos/play/wwdc2021/102/

I'm working on migrating some image-drawing code away from NSImage lockFocus() to a bitmap CGContext. This is intended to compose image content for export to formats that support alpha like PNG and TIFF, with precise control over raster resolution etc. (not solely or primarily for window/device content). I'm trying to create a generic 32-bit RGBA color space for the bitmap, which I thought would be straightforward, but Core Graphics rejects the CGImageAlphaInfo.last info value for a generic RGB color space (it only allows none, or premultiplied options). There is no generic "RGBA" color space constant/name. Is there a way to do this? Attempt: if let colorspace = CGColorSpace(name: CGColorSpace.genericRGBLinear) {       if let cgc = CGContext(data: nil,                     width: Int(pixelWidth),                     height: Int(pixelHeight),                     bitsPerComponent: 8,                     bytesPerRow: 0,                     space: colorspace,                     bitmapInfo: CGImageAlphaInfo.last.rawValue) { // use cgc... } Error logged by Core Graphics: CGBitmapContextCreate: unsupported parameter combination:   8 bits/component; integer;   32 bits/pixel; RGB color space model; kCGImageAlphaLast; default byte order; 320 bytes/row. Valid parameters for RGB color space model are: 16 bits per pixel, 5 bits per component, kCGImageAlphaNoneSkipFirst 32 bits per pixel, 8 bits per component, kCGImageAlphaNoneSkipFirst 32 bits per pixel, 8 bits per component, kCGImageAlphaNoneSkipLast 32 bits per pixel, 8 bits per component, kCGImageAlphaPremultipliedFirst 32 bits per pixel, 8 bits per component, kCGImageAlphaPremultipliedLast 32 bits per pixel, 10 bits per component, kCGImageAlphaNone|kCGImagePixelFormatRGBCIF10 64 bits per pixel, 16 bits per component, kCGImageAlphaPremultipliedLast 64 bits per pixel, 16 bits per component, kCGImageAlphaNoneSkipLast 64 bits per pixel, 16 bits per component, kCGImageAlphaPremultipliedLast|kCGBitmapFloatComponents|kCGImageByteOrder16Little 64 bits per pixel, 16 bits per component, kCGImageAlphaNoneSkipLast|kCGBitmapFloatComponents|kCGImageByteOrder16Little 128 bits per pixel, 32 bits per component, kCGImageAlphaPremultipliedLast|kCGBitmapFloatComponents 128 bits per pixel, 32 bits per component, kCGImageAlphaNoneSkipLast|kCGBitmapFloatComponents  See Quartz 2D Programming Guide (available online) for more information. TIA, Christopher

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 have an app in Swift that does a lot of numerical processing on ordered pairs and vectors, so I'm looking into some ways to improve performance including adopting SIMD from the Accelerate framework for some calculations, but I'm not seeing performance improve. There are some related posts on the forums that seem inconclusive and also a bit more complex. I pared my testing down to a couple of brief XCTests with self.measure blocks on repeated add and multiply operations of two double values. The tests set random initial values to ensure there's no compiler optimization of loop calculations based on constants. There's also no big collection of fixture data, so there's no chance allocations or vector index dereference or similar issues could be involved. The regular multiple-instruction code runs an order of magnitude faster than the SIMD code! I don't understand why this is - would the SIMD code be faster in C++, could it be some Swift conversion? Or is there some aspect of my SIMD code that is incurring some known penalty? Curious if anyone out there is using SIMD in Swift in production and if you see anything in my test code that explains the difference. func testPerformance_double() { var xL = Double.random(in: 0.0...1.0) var yL = Double.random(in: 0.0...1.0) let xR = Double.random(in: 0.0...1.0) let yR = Double.random(in: 0.0...1.0) let increment = Double.random(in: 0.0...0.1) &#9;&#9;Swift.print("xL: \(xL), xR: \(xR), increment: \(increment)") var result: Double = 0.0 self.measure { for _ in 0..<100000 { result = xL + xR result = yL + yR result = xL * xR result = yL * yR xL += increment yL += increment } } Swift.print("last result: \(result)") // read from result } func testPerformance_simd() { var vL = simd_double2(Double.random(in: 0.0...1.0), Double.random(in: 0.0...1.0)) let vR = simd_double2(Double.random(in: 0.0...1.0), Double.random(in: 0.0...1.0)) let increment = Double.random(in: 0.0...0.1) let vIncrement = simd_double2(increment, increment) var result = simd_double2(0.0, 0.0) Swift.print("vL.x: \(vL.x), vL.y: \(vL.y), increment: \(increment)") self.measure { for _ in 0..<100000 { result = vL + vR result = vL * vR vL = vL + vIncrement } } Swift.print("last result: \(String(describing: result))") } The measurements show the block with SIMD operations taking an order of magnitude more time than the multiple operations! ...testPerformance&#92;&#95;double measured [Time, seconds] average: 0.049, relative standard deviation: 3.059%, values: [0.049262, 0.049617, 0.048499, 0.047859, 0.048270, 0.048564, 0.047529, 0.052578, 0.047267, 0.047432], performanceMetricID:com.apple.XCTPerformanceMetric&#92;&#95;WallClockTime, baselineName: "", baselineAverage: , maxPercentRegression: 10.000%, maxPercentRelativeStandardDeviation: 10.000%, maxRegression: 0.100, maxStandardDeviation: 0.100 ...testPerformance&#92;&#95;simd measured [Time, seconds] average: 0.579, relative standard deviation: 5.932%, values: [0.626196, 0.605790, 0.635180, 0.611197, 0.553179, 0.548163, 0.552648, 0.549264, 0.552745, 0.551465], performanceMetricID:com.apple.XCTPerformanceMetric&#92;&#95;WallClockTime, baselineName: "", baselineAverage: , maxPercentRegression: 10.000%, maxPercentRelativeStandardDeviation: 10.000%, maxRegression: 0.100, maxStandardDeviation: 0.100

This is mainly a Mac app issue, though it's perhaps related to a similar issue with iOS app receipt validation on App Store review testing. I'm stuck in app store rejections because they are seeing a 'damaged app' error trying to launch my app on some of their test environments. I cannot reproduce in numerous attempts. Has anyone else been stuck this way (esp. recently) and if so what did you do to resolve? My app runs perfectly if I compile without app store code and notarize it myself, on a variety of systems. It's universal (M1 and intel), tested on all the above, both admin and standard accounts, so that makes me think the issue is only in the StoreKit / receipt-validation code. The app does local receipt validation in a very standard way, requesting the receipt if it's absent. I've tested this with the exact app submitted (and rejected) to app store review, exported from the Xcode organizer, and in my testing the app successfully refreshes or validates the receipt. At worst (e.g. if offline) it prompts to log in with the apple ID. I'm using a sandbox App Store account to test. I've never seen a 'damaged app' error happen even when I manually delete the receipt. The worst I've seen is a notarization error if I copy the app to a different machine (since app store archived build is not notarized, docs state that App Store will notarize it). Since there's no Mac TestFlight I can't download the actual binary that App Store review is testing which presumably has modifications (at least, notarization). And their error reports are very vague, just a screenshot of the error and generic testing advice. I can't be the only one who has been in this situation, and although I've used a DTS support ticket I don't know how soon they'll get back to me. Any helpful knowledge is appreciated!

I've got an iOS app with an add-on non-consumable. In sandbox testing, the purchase attempt *always* shows an extra Buy prompt, and then fails if the sandbox account is new. Then, it always succeeds if you just try again. Is this normal? Details: Test begins with a brand new Sandbox tester account, in USA region and verified via email invitation. Device iTunes & App Store SANDBOX ACCOUNT is logged in with this new account. App is completely deleted from device, then build/deployed with Xcode. Note that launching the app initially always prompts to enter the password if this is the first time I've used this sandbox test account. This prompt doesn't say anything about sandbox, but it uses the sandbox email as Apple ID and sandbox login works. Receipt retrieval and local validation works in the app, as does initial retrieval of the add-on product information with SKProductsRequest Requesting purchase of add-on with SKPaymentQueue.add() correctly puts up the "Confirm Your In-App Purchase" modal, showing [Environment: Sandbox]. A paymentQueue:upatedTransactions invocation happens, with transactionState .purchasing. After entering correct password and clicking Buy, there's a brief pause, then a second purchase confirmation modal appears exactly the same way, again with [Environment: Sandbox] and again requiring password When I enter the password and click Buy again, the transaction fails. I get a .failed transaction paymentQueue update and the failure alert comes up saying try again later. At this point, however, all I have to do is try again - immediately, or after quitting the app and restarting - and everything works perfectly and the purchase succeeds. The success in the second case makes me think that the code is correct, and the problem with the first attempt is just some known sandbox or configuration issue. The double prompt seems especially weird since there's no transaction update between them. Do others see this behavior? Is there any way to make a sandbox purchase attempt succeed on the first attempt in this kind of environment? Xcode 12.2, running on Intel 11.0.1; device running iOS 13.7.