An update to Xcode 14 appeared in the Mac App store today 2022-11-12. After updating Xcode from the App store app on my M1 MacBook, and plugging in an iPad, also updated today 2022-11-12 to iOS 15.7, Xcode says: "Failed to prepare the device for development". A restart of both the Mac and the iPad doesn't fix this issue. Is there a way to get Xcode 14 to debug an 15.7 iPad? Or is a different build required? There also is no 15.7 directory inside Xcode's iPhoneOS DeviceSupport directory.

I am trying to run some very short simple TCP and UDP portable network socket code examples from various tutorials. The examples just try to send or receive one UDP or TCP packet. The example code run just fine on Raspberry Pi's, and can send 1 byte of data between two of them. When on macOS Big Sur I compile and run this code from the Terminal command line, clang send_1_byte_via_udp.c -lm ./a.out 192.168.1.125 1024 An error box pops up saying: Terminal via a.out wants to connect to 192.168.1.125 in the local network Warning The program "a.out" has been modified. The checksum of the program no longer matches ... There is a button to cancel, disable identity check, deny (in red), and accept the modification. Hitting disable identity check or accept does nothing, the box stays on top. Hit deny, and a.out quits without sending any network data. IIRC, code similar to these examples ran under Mohave without any pop-ups appearing. Is there way to run simple network socket code on Big Sur.

A macOS Catalyst app with an added extension was successfully built with Xcode 12.1, submitted to the Mac App Store, and approved 2 weeks ago. This macOS Catalyst app was originally built and distributed last year with an Xcode version prior to Xcode 11.4, when the maccatalyst prefix was automatically added to builds. When trying to rebuild and update the project, unchanged except for version and build numbering, using Xcode 12.2, so that Apple Silicon support can be added, codesigning the new archive from the Organizer fails. The error message when trying to Distribute to App Store Connect from the Organizer is: Code signing "rtl_tcp-SDR.app" failed. View distribution logs for more information. The end of the IDEDistributionPipeline.log has this message: 2020-11-16 21:03:11 +0000	Running /usr/bin/codesign '-vvv' '--force' '--sign' 'CD25FBC289AAC880348543822E408B045CD14EAC' '--entitlements' '/var/folders/96/wwd0fl953bg48jzn669wbg1m0000gp/T/XcodeDistPipeline.~~~YB05bp/entitlements~~~RoCzdR' '--preserve-metadata=identifier,flags,runtime' '/var/folders/96/wwd0fl953bg48jzn669wbg1m0000gp/T/XcodeDistPipeline.~~~YB05bp/Root/Applications/rtl_tcp-SDR.app' 2020-11-16 21:03:11 +0000	/var/folders/96/wwd0fl953bg48jzn669wbg1m0000gp/T/XcodeDistPipeline.~~~YB05bp/Root/Applications/rtl_tcp-SDR.app: replacing existing signature 2020-11-16 21:03:11 +0000	/var/folders/96/wwd0fl953bg48jzn669wbg1m0000gp/T/XcodeDistPipeline.~~~YB05bp/Root/Applications/rtl_tcp-SDR.app: code object is not signed at all 2020-11-16 21:03:11 +0000	/usr/bin/codesign exited with 1 There is a note in "About the Mac app built with Mac Catalyst bundle ID" saying: Configuring Projects Created Earlier Than Xcode 11.4 If you created the Mac app built with Mac Catalyst using an earlier Xcode release than 11.4, the Mac app and iPad app have different bundle IDs. The Mac app bundle ID has a maccatalyst prefix followed by the iPad app bundle ID by default. Use the Derive Mac Catalyst Product Bundle Identifier (DERIVE_MACCATALYST_PRODUCT_BUNDLE_IDENTIFIER) build setting to configure your project: If you add an app extension, set the app extension target Derive Mac Catalyst Product Bundle Identifier build setting to YES because the Mac App Store requires that every embedded executable bundle have a bundle ID that is prefixed with the parent bundle ID. But I get the same codesign failure with DERIVE_MACCATALYST_PRODUCT_BUNDLE_IDENTIFIER set to either Yes or No in Build Settings, for either the app or the extension (all 4 combinations tried). Is there an Xcode build setting or a manual codesigning sequence that will codesign an older Catalyst app with an extension so that it can be uploaded to the Mac App Store? Do I need to create an App Identifier for the extension in Certificates, Identifiers & Profiles? With or without a maccatalyst prefix? Etc.

Is the way macOS handles network or firewall rule changes for UDP broadcasts and UDP replies different between running command-line utilities in admin accounts, versus running them from user accounts that do not have admin privileges? If so, where is this documented? Also, the behavior of UDP from non-admin accounts appears to have changed somewhere between Mohave and the Big Sur betas. UDP broadcasts appear to work when sent from non-admin accounts under Mohave, but do not work under the Big Sur beta (packets are blocked or lost?), except from an admin account. A similar change occurred with the UDP broadcast code embedded into an iOS 14 app, which I assume enforces non-admin access rules. Receiving UDP replies (worked under iOS 12) stopped working.

In regards to answer to this question: https://developer.apple.com/forums/thread/660472 How do the new network privacy permissions apply to command-line apps that send and listen for UDP replies? I have 2 macOS command-line binaries that listen for a UDP reply to a UDP broadcast. They have identical file names but are in different directories. One binary broadcasts and receives a UDP reply, but the newer binary does not. The System Preferences : Security & Privacy : Firewall : Firewall options... pane shows all the instances of the command-line binary, all with "Allow incoming connections" set to green bubble (true?). Is there some other network privacy setting that affects UDP I/O, and is it possible to determine if that current network privacy permission settings for the two binaries are the same or different? Added: It appears that the iOS Simulator also shows this difference in behavior between iOS apps compiled and run with Xcode 11.0 on old versions of Catalina vs. with Xcode 12.0 on newly updated Catalina. Old works. New does not.

In this question https://developer.apple.com/forums/thread/660472 , I thought there was a problem on Big Sur beta with getifaddrs() or with UDP broadcasts. But the problem turns out to be something else. UDP broadcasts seem to work, The problem occurs, not with the UDP broadcasts, but with the UDP responses to the broadcasts, and not just on Big Sur (and iOS 14), but with the most current release of Catalina 10.15.7. And, the problem did *not* occur on previous releases of Catalina (from several months ago, maybe 10.15.4? and earlier). getifaddrs() is returning the IPV4 address 127.0.0.1, and that is the address being used for the UDP broadcast. On macOS 10.15.7, with code compiled with Xcode 12, the UDP broadcasts to 127.0.0.1 succeed. e.g. they are going out on the local network, as seen by a UDP sniffer running on a Raspberry Pi 4 on the local network. But, the new binaries never receives a UDP reply from the target responding device that is trying to respond to the UDP broadcast. However, on the same Mac and macOS 10.15.7, running a binary that was compiled months ago with Xcode 11 from the same source code, that old binary does receive UPD responses to the UDP broadcasts. Reliably. And the code also works just fine on Mohave. What could cause this difference? Is it intended? (new firewall rules?). Does it require a bug report? (If so, to where?) Or is there a way to turn it on/off, so that UDP responses to broadcast UDP packets can be received? Note that this UDP (broadcast and response) protocol is an open source protocol being used by likely multiple thousands of existing SDR radios from multiple hardware vendors, and dozens of open source software projects on multiple platforms. e.g. something not likely to change. And my iOS beta test SDR app did work a few months ago using this protocol, but can't be built with the current Xcode release and still work.

The BSD network call: getifaddrs() returns an IPV4 address for the WiFi network connection on Catalina and iOS 13, but appears to return only IPV6 addresses on Big Sur and iOS 14. Is this intended behavior? If so, where is this documented?

I am seeing the sending of broadcast packets, e.g. stuff which includes: destAddr.sinfamily      =  AFINET; destAddr.sinaddr.saddr =  INADDR_BROADCAST; sendto(...) which work just fine on Catalina and iOS 13, fail on Big Sur and/or iOS 14. This behavior causes discovery of local networked devices that respond to broadcast packets to ID themselves to fail. These device are then never found by apps that use this mechanism. Perhaps this is happening to some WiFi adapters, but other networked peripherals use this mechanism as well, such as openHPSDR radios. Is this intended behavior?

I have one iOS app that is an iPad touchscreen virtual musical instrument. I have another app that is an audio visualizer (36-th octave spectrum analyzer). I used to use inter-app audio to pipe audio samples from the first app to either the second app, or to GarageBand for recording. But inter-app audio has been deprecated. My question is what is Apple's suggested method (API's etc.) to get audio samples generated in one UI app to play and display in another UI app (say on an iPad, where both apps can be on the display) in performance-near-real-time without using inter-app audio?