I created a camera extension project that required interaction via custom properties. I originally coded it on macOS 14.x. In the camera extension code, receiving and returning NSNumber values as shown in the code at the bottom. The app was working perfectly until I went to test on mac 12.7.6. Under that version of macOS, the custom properties weren't working at all. I also saw lines in the logs like this: CMIO_DAL_CMIOExtension_Stream.mm:1165:GetPropertyData 50 wrong 4cc format for key 4cc_back_glob_0000 which was totally perplexiing, because it was clear that the 4cc codes were fine under 13.x, especially given that the documentation for CMIOExtensionPropertyState clearly says that NSNumbers should be OK. On a hunch, I changed the code to use NSString instead of NSNumber, and it started working again under 12.7.6. So, my experience is that macOS 12.x doesn't allow you to use NSNumbers, but it happy with NSStrings. Hope that saves someone else some time. And here is is the code that worked on 14.x, but not on 12.x. // 4cc constant const CMIOExtensionProperty CMIOExtensionPropertyCustomPropertyData_BackgroundOption = @"4cc_back_glob_0000"; - (nullable CMIOExtensionDeviceProperties *)devicePropertiesForProperties:(NSSet<CMIOExtensionProperty> *)properties error:(NSError * _Nullable *)outError { // doesn't work on macOS 12.x, works on 14.x CMIOExtensionDeviceProperties *deviceProperties = [CMIOExtensionDeviceProperties devicePropertiesWithDictionary:@{}]; if ([properties containsObject:CMIOExtensionPropertyCustomPropertyData_BackgroundOption]) { NSNumber* nsBackgroundOption = [NSNumber numberWithUnsignedInt:(unsigned int)_backgroundOption]; CMIOExtensionPropertyState* state = [CMIOExtensionPropertyState propertyStateWithValue:nsBackgroundOption]; [deviceProperties setPropertyState:state forProperty:CMIOExtensionPropertyCustomPropertyData_BackgroundOption]; } return deviceProperties; } - (BOOL)setDeviceProperties:(CMIOExtensionDeviceProperties *)deviceProperties error:(NSError * _Nullable *)outError { // doesn't work on macOS 12.x, works on 14.x NSDictionary* devicePropertiesDict = [deviceProperties propertiesDictionary]; CMIOExtensionPropertyState* propState = nil; propState = [devicePropertiesDict objectForKey:CMIOExtensionPropertyCustomPropertyData_BackgroundOption]; if (propState != NULL) { NSNumber* nsBackgroundOption = [propState value]; if (nsBackgroundOption != NULL) { uint32_t newBackgroundOption = [nsBackgroundOption unsignedIntValue]; if (newBackgroundOption != _backgroundOption) { log_info(@"##### Set Background Option to %d", (int) newBackgroundOption); } _backgroundOption = newBackgroundOption; } } return YES; }

I am developing a camera extension as described here Creating a camera extension as described in Creating a camera extension with Core Media I/O. To ensure this wasn't some issue with my code, I reverted to the sample code added when you choose File &gt; New &gt; Target &gt; Camera Extension in Xcode, in other words, I am using the example code provided by Apple. I am able to install the camera extension and see it in QuickTime Player, where I choose it as the video input. In QuickTime Player I see the white line generated by the sample code moving up and down. For some period of time, it works. But eventually, the video in QuickTime Player freezes. The thing that's really weird is if I add some NSLog() statements at the point in the code where it returns the newly created sample: [self-&gt;_streamSource.stream sendSampleBuffer:sbuf discontinuity:CMIOExtensionStreamDiscontinuityFlagNone hostTimeInNanoseconds:(uint64_t)(CMTimeGetSeconds(timingInfo.presentationTimeStamp) * NSEC_PER_SEC)]; the samples are still being generated and sent to the stream. But the apparently QuickTime Player has decided to stop consuming them. I thought maybe setting the discontinuity parameter to CMIOExtensionStreamDiscontinuityFlagTime or CMIOExtensionStreamDiscontinuityFlagSampleDropped if the delta time since the last sample was generated was off by a tiny bit, but this did not improve the situation. Finally, could this have something to do with frequently installing and uninstalling my camera extension as part of the debugging and testing process? Thanks in advance for any advice you might have!

Our app Isadora is a "fat-binary" for Intel and ARM. When running our installer I am presented with a dialog that says "To Install Isadora 3- Standard Version (Intel/ARM) you need to install Rosetta. Do you want to install it now?" I tried saying "Not Now" but then the installation failed because macOS says our app requires Rosetta support. By no means does are app require Rosetta; it is compiled for both ARM and Intel and runs natively on an Apple Silicon (ARM/M1) machine. Why is this dialog appearing? What can I do to prevent it?

I have have created an installer that installs an application using pkgbuild and this all works fine. However, there are some supporting GLSL Shader text files that need to go in a special folder, because we sometimes we update these shaders and users can download a new version and install them manually. Clearly, for a text file, there is no version number like an app or bundle because there is no associated embedded plist. Is it possible with Apple's pkgbuild tool to install the text files included with the installer only if their timestamp is greater than the ones already on disk? One workaround would be to install the files from the installer in a temporary location, and then run a bash postinstall script to copy the newer files into the special folder. But I can prepare the installer so that it does this automatically that would be great. Thanks in advance.

Dear Apple, When any audio is being captured, there is a new security feature in MacOS Monterey that shows and orange dot to alert the user; in of itself this is no big deal. But, this orange dot is rendered on top of any video output sent to a video projector. This happens not just in my app Isadora, but in numerous others including such notable softwares as QLab, Touch Designer, Resolume, and ZoomOSC. (There are dozens more.) This security "enhancement" renders MacOS Monterey unusable for anyone using apps like those listed above to present video to a live audience – you can't just have a random orange dot appearing in a video projection behind a bunch of opera singers because you also happen to be capturing audio on the same machine. This security feature must be made optional. Otherwise, the tens of thousands of users will have spent a lot of money on Apple hardware that will be rendered worthless for live-performance work. Apple, you made a mistake on this one. Please pay attention to this and fix it. Sincerely, Mark Coniglio Creator of Isdora (and all users who use macOS software to do live projections.)

I have a miniMac M1 for M1 testing and development. I had set it up for dual boot with the original Big Sur partition that came with the machine and a new partition for Monterey. I've been using this for some months. Summary: After the steps taken below, and the subsequent steps to attempt to fix the problem, it became impossible to boot into the Big Sur partition. It seems that the System volume and the Data Volume had become disassociated making the partition unbootable. I do see there might have been user error here; I had not gone into the Recovery mode on Monterey and enabled the possibility to boot from an external drive. Now, strictly speaking, both the Big Sur and Monterey partitions were internal since they were on the main hard drive. But could it have been that Monterey would not allow me to boot into Big Sur because I had not enabled the external boot possibility? Detail: I had always had the beta of Monterey installed, but because I needed to test a crash agains the release version of Monterey, I did the following: Set the startup disk to Monterey (something I'd never done before; I usually shutdown and hold the power button to select the boot drive.) I disabled the beta program in the System Preferences. System Update then showed the 12.0.1. I install that version and performed my tests. I then went to the System preferences to set Big Sur as the startup disk. I was surprised to see it wasn't listed (as it always had shown up there before). I ran Disk Utility / First Aid on the Big Sur partition, and then on the entire disk that holds both Big Sur and Monterey. They reported no problems. Then I then went into Recovery mode, and when I selected the Big Sur disk, it said "no users available for recovery". In other words, it couldn't see the data partition with the users on it. This seeming separation of System and Data partitions was confirmed whe I returned to the Finder after a reboot. I double-clicked the Big Sur partition, it only showed the System folder. It did not show "Users" or "Applications" or "Library" I went back to Disk Utility. It in fact showed the Big Sur data partition. When I chose File > Show In Finder the data partition showed up, with the "Users" or "Applications" or "Library" intact. So the Data volume was still there, but somehow the link between it and the System Volume seems to have been broken. Finally, I went to the Terminal, entered "cd /Volumes" and "ls -al". It showed the Monterey partition as a single directory. But the Apple M1 drive and it's Data partition were listed separately I sadly don't have a copy and paste, but something like this: drwxr-xr-x   5 root  wheel  160 Nov 18 07:58 . drwxr-xr-x  20 root  wheel  640 Jan  1  2020 .. lrwxr-xr-x   1 root  wheel    1 Nov 18 07:00 Monterey-> / drwxr-xr-x  21 root  wheel  672 Nov 18 00:10 BigSur drwxr-xr-x@ 19 root  wheel  608 Nov 18 00:08 Data Any ideas what could have happened and how I can prevent it in the future? Sincerely, Mark

In addition to my primary Intel computer used to code sign and notarized all apps released to the public, I have a second mini-Mac M1 for testing. This machine is set up for dual-boot into either Big Sur (latest release) or Monterey 12.1 beta 3. I strongly suspect that Monterey corrupted my Big Sur partition making it impossible to boot from it. Regardless of the reason, I ended up with little choice except to do a fresh install of Big Sur and Monterey. However, I did not back up the public and private keys for my Developer ID Certificate before I reinstalled both operating systems. I've been developing on macOS for 30 years, but I really don't get some of the ins and outs of certificates. So I'm a bit embarrassed to ask these newbie-esque questions: When I open Xcode 12.5.1 I and go to Preferences > Accounts > Manage Certificates, see the certificate for the old Big Sur partition prior to the fresh install. It's listed there in grey with the old name of the computer. But I don't see any way to get it. Is there a way? (I changed the computer name to match the old name, btw.) I did actually export my Developer ID Certificate from the old Big Sur partition to a .p12 file so that I could add it to the keychain on the Monterey partition. (Is this the public key, the private key, or both?) Should I try to import that into the Keychain on the freshly installed Big Sur and Monterey partitions? Or should I just generate and import a new certificate for the Big Sur partition from my developer account? (I would also then export it to a .p12 and import it into the Monterey partition as I did before.) Finally, what actually is the best practice here? I thought that the certificates generated from my developer account were related to the hardware (computer) on for which I generated them, and they couldn't be used on a different piece of hardware Is that true? If not, could I export the public and private keys for the Developer ID Application certificate from my main development machine (Intel Mac), and install those on every development system I use (e.g., the miniMac M1)? Thanks for any expertise and wisdom you can share. Best Wishes, Mark

I am creating an installer with pkgbuild + productbuild that uses a background image aligned to the top left with scaling turned off, e.g.,   I've designed the background image so that there is a white area near the top to ensure messages shown there are easily seen. (For example, "Standard Install on "Macintosh HD" in the first image below.) The problem is that the installer window changes its size just after the password is entered, which leaves a white area on the right which is purely cosmetic but does not look very professional. Here's the window before the password is entered: and here's the window just after the password is entered: Note that white area in the middle has become wider and there is now a grey area on the right since the image is set to not scale. I sort of worked around this by making the width of the image bigger, but it's still weird because the window size jumps after you enter the password. Why is the installer window changing it size at all? Is that a known bug? Is there anything I can do to prevent this? Best Wishes, Mark

A simple example project I've placed on GitHub demonstrates a strange problem I'm having with a non-editable NSTextField (i.e., static text) when compiling for an SDK earlier than 10.14. If you compile the main branch has the deployment target set to 10.14, the text displays as one would expect. But if you switch the branch to 10.13SDK, where the deployment target has been set to 10.13, you'll see that extra space (3 pixels) has been added to the above the text and it is now cut off by the 11 pixel high frame. What do I need to do to consistently display the text within the 11 pixel high frame, regardless of the deployment target? I've tried every manner of subclassing NSTextField and NSTextFieldCell, referencing solutions like this one as an inspiration. But to no avail. Thanks in advance for your help.

I have tried to wade through the "Apple Developer Program License Agreement" but I'm still not sure about this. Monterey is publicly announced but not publicly available. I just tested my software with it and -- happily -- it seems to run without issue. Am I allowed to mention this on social media, e.g, "Just ran my software under Monterey and it is running well!" or is that breaking a confidentiality clause? Thanks for the guidance.

I am the sole programmer for my very small company (4 people) and I have a developer account for my macOS software. What is the policy on distributing beta versions of macOS that are only available via my individual developer account? (I'm speaking at this moment about Monterey.) Can I let the the two people on my team who test my software install it on their machines too? Or do I need to acquire developer accounts for both of them so they can download it directly. (We continue to be separated geographically because of the pandemic.) I don't meet the requirements listed under "Enrolling as an Organization" listed on this page: https://developer.apple.com/programs/enroll/ I assume this means I cannot add team members as described on this page: https://help.apple.com/developer-account/#/dev3e8818774 Thanks for your guidance.

In my app, I have a few dialogs that display alerts with long messages, usually in the form of instructions to the user on how to change a system setting. Because Big Sur's dialogs are vertically oriented and reduced in size, those main message and the informational message in those alerts would be cut off and thus unreadable by the user. NSCustomAlert implements a direct replacement for NSAlert. that mimics the appearance and behavior of alerts on macOS Catalina and earlier. Furthermore, the code will decide whether to use a native NSAlert or NSCustomAlert based on the length of the text to be displayed. MIT License. Git Hub repro is: https://github.com/TroikaTronix/NSCustomAlert

I have submitted this via Feedback Assistant but am posting this here to ensure this bug gets some attention. On previous versions of macOS, when you invalidated an area using setNeedsDisplayInRect:, calling the getRectsBeingDrawn:count: method in the drawRect: method for a view would correctly return the invalidated area. Under Big Sur Beta 9, calling getRectsBeingDrawn:count: to determine the invalid area always returns the entire frame of the view. This is bad because routines that rely on getRectsBeingDrawn:count: to optimize drawing are getting the wrong information, and will draw more than they need to draw. But even more serious is this: even getRectsBeingDrawn:count: reports the entire view as being invalid, you cannot successfully to draw into the area that has not been invalidated. A sample demonstrating the problem can be found at https://github.com/TroikaTronix/BigSurDrawingTest The READ ME gives further details about the bug and how the sample code reproduces the problem.

In updating my app for Big Sur, I discovered the new look for a standard NSAlert. I have no issue with the default button, which is clearly important because of the color applied to it. Not only does the grey background and light grey text of the non-default buttons make these buttons look less important than the default button, but they actually look DISABLED -- at least for anyone who has used macOS previously. This terrible UX decision is going to create user confusion and prevent users from making the right choice because they will see those grey buttons and assume they are not even clickable. This forum won't let me post a link to an example image, but put https:// in front of the URL below to see what I mean troikatronix.com/files-temp/big-sur-nsalert.png This really needs to be changed!