According to the thread at https://developer.apple.com/forums/thread/787500?answerId=863361022#863361022, we should now be able to set VMs provisioning identifiers to run developer builds. However, the identifier check seems to be case-sensitive. I have an identifier from an old VM that was input (automatically via Xcode) to the portal as all-caps. However, now it's showing up as all lower-case (on the device). When I try to launch my application, the system logs report that the provisioning identifer doesn't match, so my application will not launch: # Error log error 13:41:36.173151-0600 taskgated-helper embedded provisioning profile not valid: file:///Applications/my-app.app/Contents/embedded.provisionprofile error: Error Domain=CPProfileManager Code=-212 "Provisioning profile does not allow this device." UserInfo={NSLocalizedDescription=Provisioning profile does not allow this device.} # Device's identifier $ system_profiler SPHardwareDataType Hardware: ... Provisioning UDID: 9d136dc4ae3ce80124756cc5bcb40cd1117c04b6 # Embedded provision (from developer portal) $ security cms -D -i /Applications/my-app.app/Contents/embedded.provisionprofile <key>ProvisionedDevices</key> <array> <string>9D136DC4AE3CE80124756CC5BCB40CD1117C04B6</string> </array> I have tried disabling the previous record and adding it again (with lower-case) on the developer portal - but all that does is reenable the previous (all-caps) record. Either the check needs to be case-insensitive, or there needs to be a way to change the registration on the developer portal to properly match.

I would like to specify "Connection: close" for a request that I load in WKWebView - which actually CAN be done by setting the value on the request that is loaded (and it actually works). However, the documentation at https://developer.apple.com/documentation/foundation/nsurlrequest#1776617 states that it shouldn't be used because the URL loading system handles persistent connections for you. So - my question is how can I indicate to the URL Loading System that I do NOT want to use persistent connections for this particular request? Or - am I safe to just set the header even though it's listed as reserved (because - as mentioned - it does work)?

In Monterey 12.3, I am no longer able to export a HAR file consistently. If I open the developer tools, and capture traffic, clicking on the "Export" button, or context-clicking and choosing "Export HAR" does nothing. I'm never prompted to save the file. At times, it does allow me to export a HAR file, but only about 1 in 10-20 page loads. It doesn't seem to be specific to a site, or specific to anything environmental...it just seems to not prompt. One other thing I've noted, when attempting to export the HAR file, Safari itself seems to freeze briefly (the spinning "beachball") - but after it starts responding again, there still is no prompt for saving the HAR file.

Within a Parallels VM (version 17.1.2) running Monterey 12.3, dynamic browser content is not updated until you resize the browser window. This is a new issue in Monterey 12.3 (it doesn't exist in Monterey 12.2.1 or earlier - even in the same VM). Running on the native hardware doesn't have the issue - only when running within the VM environment. A video of the behavior can be found at http://www.toonetown.com/nathan/projects/redraw.mov - in the video, text typed into the google search box doesn't display until the window is resized - causing the HTML content to reflow. Is there some setting or something that I should make in order to cause dynamic HTML content to rerender without needing to resize the window?

Is there an MDM payload that can be configured that will prevent delivery of signals (i.e. kill -1 <PID> or kill -SIGUSR1 <PID>) on macOS?

Since upgrading to Xcode 13.2, we are not getting the Base.lproj files (including Main.storyboardc) copied into our macOS output app bundles. The storyboard files are getting compiled in our intermediate build directory, but they are not being included in the final bundle (even though they are in the "Copy Bundle Resources" build phase). Is this something that has changed in 13.2? Is there something we need to update in our xcodeproj files to get working?

Our application requires MDMs to push down a trusted SSL intercept certificate to function properly. In releases prior to Monterey Beta 10, an MDM profile could install the correct certificate and trust it for the system. However, beginning in Monterey Beta 10, the certificate is pushed, but no longer trusted - the end user must go into Keychain Access and manually trust it. Additionally, certificates cannot any longer be trusted via: security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" "/path/to/ssl-intercept.crt" (Logged as FB9701844)

Beginning with Monterey beta 8, our NETransparentProxy is no longer functioning. Its handleNewFlow never gets called with any flows while it is loaded - but while loaded, the OS doesn't send any traffic out the network interface either. This is new (incorrect) behavior in beta 8 (or possibly beta 7...I don't have a system running it anymore to be able to check). It definitely is not happening on beta 6 (I do have a system running it still). I have logged FB9625030 with details and sysdiagnose from both beta 6 (working) and beta 8 (broken). I am wondering if there is something we are missing that needed to change in the recent betas, or if there is an unintended regression in the OS.

Given I run this command: $ defaults write com.example.encoding room -string "Baño" plutil shows that it is properly stored in UTF-8, and the character is correct: $ plutil -convert xml1 ~/Library/Preferences/com.example.encoding.plist -o - <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>room</key> <string>Baño</string> </dict> </plist> I can also get this value from PlistBuddy: $ /usr/libexec/PlistBuddy -c "Print :room" ~/Library/Preferences/com.example.encoding.plist Baño However - if I try using defaults read, the value comes back garbled - the special character (ñ) does not get returned correctly: $ defaults read com.example.encoding room Ba\361o Is there some way to set the encoding that defaults read uses?