As of Xcode 15, Apple supports adding Privacy Manifests to SDKs. We develop an SDK that consists of several components (frameworks) for which we would like to add a Privacy Manifest. That works fine for our local builds, but we distribute our SDK via CocoaPods, which generates a single framework with the sources of all our components. This single framework currently does not have a Privacy Manifest. How would we be able to provide Privacy Manifests when using CocoaPods for distribution?

Our Kotlin MPP code which compiled/linked fine using Xcode 15 Beta 2 no longer links using Xcode 15 Beta 3: ld: unknown options: -ios_simulator_version_min -sdk_version Is the option ios_simulator_version_min removed/renamed? (Intentionally?) Should Apple or JetBrains fix this? (also reported to JetBrains as KT-60238).

Our (company internal) SDK for connecting iPhones to accessories uses the SSID of the local network to determine whether local communication is possible, or remote communication (via our company's back-end) is required. Apps that use this functionality of our SDK need to have the "Access Wi-Fi Information" Entitlement and at run-time the user has to give permission to use the precise location (otherwise the SSID cannot be read). Does this mean we should add the data type "Precise Location" to the privacy manifest of our SDK? PS: We only use the SSID; not the precise location (coordinates), but an SSID can identify a precise location.

Upgraded to Xcode 15 Beta 2 (15A5161b) and iOS 17 Beta 2 (21A5268h) today (on an Intel Mac, running macOS 13.4.1). Now Xcode no longer finds any eligible connected devices, while Finder does show the iPhone. This iPhone 11 is connected via USB and Developer Mode is turned on. What could be wrong? How to fix it?

To check whether our SDK still works on iOS 17 I installed Xcode 15 (Beta 1) and iOS 17 (Beta 1), but I'm unable to run our SDK demo/test App on the iPhone running iOS 17. Xcode complains about the provisioning profile not supporting the "Access Wi-Fi Information and Hotspot Configuration capability", but com.apple.developer.networking.wifi-info is already set to true in the (development) provisioning profile. This profile worked fine with Xcode 14.3.1 and iOS 16.5. What changed? Or is this a bug in Xcode 15 Beta 1?

Our (legacy) code to communicate with peripherals on local IPv6 networks (LAN) adds the zone identifier / interface name ("%en0") to link-local IP addresses (FE80::/10) discovered via SSDP. SSDP is implemented using CocoaAsyncSocket - yes, that part of our code is old... (from before the introduction of the iOS 12+ Network framework). We use these modified IP addresses as the host component of a URL in a URLSession.dataTask. To insert the zone identifier we are using URLComponents (we modify the host and then request the string). This worked fine in iOS 15 and below, but no longer works in iOS 16 (Beta 1/2/3); the host is empty after inserting %en0 in the most recent beta. We have reported this via FB10549269, but from the answer it is unclear to me whether Apple is planning to fix this ("Resolution: Potential fix identified"), or we are doing it wrong. How should we handle IPv6 link-local addresses in iOS 16? (when using URLSession instead of Network) PS: We recently dropped support for iOS 12, but we still need to support iOS 13 and up

Software update On my Mac (running macOS Big Sur 11.6.1 - IT won't let me update to Monterey) Software Update now and then offers to install old Xcode Command Line Tools. I currently (only) have the latest released Xcode (13.1) and the latest beta (13.2 Beta 2) installed, but Software Update offers 12.4, 12.5 (twice, with different sizes) and 13.0 Command Line Tools... What's worse: if I let Software Update install them it immediately offers them again after all four have been installed(?). How can I fix this? Command line builds Additionally, when I try to build from the command line using xcodebuild I get this pop up that "instruments" requires the command line tools (every build again, no matter whether I choose Install or Cancel). (however, the build does succeed if I choose Cancel...)

We're trying to re-implement our proprietary SSDP implementation (currently using CocoaAsyncSocket) using Apple's Network framework for iOS 14, based on Apple's example - https://developer.apple.com/news/?id=0oi77447 on how to use multicast networking in an App. This is the code of our spike: guard let multicastGroup = try? NWMulticastGroup(for: [ .hostPort(host: "239.255.255.250", port: 1900) ]) else { 		fatalError("Failed to create multicast group") } let connectionGroup = NWConnectionGroup(with: multicastGroup, using: .udp) connectionGroup.setReceiveHandler(maximumMessageSize: 16384, rejectOversizedMessages: true) { message, content, isComplete in 		print("Received message from \(String(describing: message.remoteEndpoint))") 		if let content = content, let message = String(data: content, encoding: .utf8) { 				print("Message: \(message)") 		} } connectionGroup.stateUpdateHandler = { newState in 		print("Group entered state \(String(describing: newState))") } connectionGroup.start(queue: .main) let searchString = "M-SEARCH * HTTP/1.1\r\n" + 		"HOST: 239.255.255.250:1900\r\n" + 		"MAN: \"ssdp:discover\"\r\n" + 		"ST: ssdp:all\r\n" + 		"MX: 1\r\n\r\n" let groupSendContent = Data(searchString.utf8) Timer.scheduledTimer(withTimeInterval: 5, repeats: true) { _ in 		connectionGroup.send(content: groupSendContent) { error in 				print("Send complete with error \(String(describing: error))") 		} } While we see plenty of HTTP/1.1 200 OK responses to our M-SEARCH request in Wireshark, iOS 14 Beta 5 is hardly ever calling NWConnectionGroup's handler (line 6) for any received messages (sent from members of the group to the local endpoint). Do we need to use different NWParameters settings to make sure this handler is called for every response? Or is this a bug in iOS 14 Beta 5? Reported as FB8461681.