Before Big Sur our application handled removing configured SSIDs by editing the com.apple.airport.preferences.plist file. Big Sur made this not possible any more so we moved to using terminal commands to accomplish this using the networksetup -removepreferredwirelessnetwork. This functioned without issues on intel machines but requires admin access on the new M1 machines. Is there a reason for this difference? We also tried providing sudo access using the AuthorizationExecuteWithPrivileges function on the .sh file with the command. Strangely this also does not work and still pops up a "Command requires admin privileges" error. We are aware that AuthorizationExecuteWithPrivileges is a deprecated function, but we have decided to go with it since it's a one off and saves us the hassle of programming with the Authorisation Services on top of the fact that ours is a runtime application. Is this functionality broken on the m1 processor and is there a "correct" way to handle removing SSIDs that does not involve plist files or terminal commands?

In our macOS Application I am trying to generate a keypair in the system keychain using SecKeyCreatePair for legacy reasons, but keep receive an error -61 (Write permission error). What is the best approach to making this work or is this simply not possible (anymore)? The End User running this Application is typically an Admin and we would normally use the SFAuthorization to grab sudo for this type of issue. This is not possible using Apple Security Framework functions as far as I can see, not even the latest function SecKeyCreateRandomKey.

FB12755685 Sent a feedback through feedback assistant and wanted to elaborate more over here. Our application configures and connects to wireless networks using CoreWLAN. We started seeing crashes while connecting with the latest Beta versions of Sonoma. The crashes showed EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) which led me to believe it might be a CPU architecture issue due to the mention of i386 but that was completely wrong. Turns out the error is due to: *** CFRetain() called with NULL *** CFRetain.cold.1 [CWInterface associateToEnterpriseNetwork:identity:username:password:error:] + 127 Sample code to consistently reproduce the crash on Sonoma CWInterface* interface = [CWInterface interfaceWithName:@“en0”]; NSError *scanError = nil; NSSet* testNetworks = [interface scanForNetworksWithName:@“SSIDName” error:&testScanError]; CWNetwork* network = [testNetworks anyObject]; NSError* connectionError = nil; BOOL connected = [interface associateToEnterpriseNetwork:network identity:identityRef username:nil password:nil error:&connectionError]; //<--crash here The associateToEnterpriseNetwork function expects a CWNetwork object. In the Beta versions of macOS Sonoma, the CWNetwork object has (null) values in the ssid field. This causes a cold CFRetain runtime error when trying to associate to the network. If we can detect a broadcasting "SSIDName" SSID and try to associate to it, we will always crash on the last line. The reason for the crash seems to be due to a difference in how the CWNetwork objects are handled in Sonoma. Sonoma: <CWNetwork: 0x6000036cb590> [ssid=(null), bssid=(null), security=WPA2 Enterprise, rssi=-53, channel=<CWChannel: 0x6000036fce90> [channelNumber=1(2GHz), channelWidth={20MHz}], ibss=0] Ventura: <CWNetwork: 0x6000010ffa60> [ssid=Chris640, bssid=(null), security=WPA2 Enterprise, rssi=-45, channel=<CWChannel: 0x6000010ffca0> [channelNumber=1(2GHz), channelWidth={20MHz}], ibss=0] Is my assumption that the crash is due to the (null) in the SSID field correct?

Our application used the profile -I command to install a wireless configuration profiles for the user. Starting with macOS Big Sur, terminal commands can no longer be used to install configuration profiles. Along with this, there are no APIs available to do the same. I get that Apple wants the user to be in control of any Configuration Profile installations, but the system notification that doesn't actually take you to the 'Profiles' section on click along not being very descriptive seems like something that may cause confusion among users. To make the installation process easier, we are triggering a file open of the .mobileconfig followed by opening System Preferences using terminal commands (open <path/to/mobileconfig and open "x-apple.systempreferences:com.apple.preference") and then waiting for the user to navigate to profiles and approve the profile to be installed. Opening the Profiles section was possible on older versions, is there a way to do the same on Big Sur? Is there anything else we could do to make the profile installation process a little more intuitive for the user?

We use a web page to distribute Configuration Profiles. To make the profile installation experience a little easier, we provide a button to open up the Settings application using function redirect() { try { window.location.href='App-prefs://prefs:root=Settings'; } catch (error) { alert(error); } } This has worked well till iOS 15.4, in which we get an 'Invalid URL' error. I understand that Apple does not permit using these URLs in an App Store applications but there is nothing against it for simple web URLs. Is this a bug or an intended change in having these URLs not work?