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).

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?

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

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.

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?

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.

One of the new features - https://www.apple.com/ios/ios-14/features/ in iOS 14 is the approximate location: Approximate location A new setting lets you choose to share your approximate location, rather than your precise location, with an app. We noticed that when a user selects approximate location instead of precise location CNCopyCurrentNetworkInfo("en0" as CFString) returns nil instead of the current SSID. We develop & maintain a proprietary library to communicate with devices on the network. Our library uses direct communication via LAN when possible, but falls back to remote communication via a back-end when not on the user's LAN (with additional costs). It compares the current SSID with the SSID used at device set-up to determine whether local communication over LAN can be used, or the more expensive back-end should be used. How can we detect whether the user is on his/her own network when (s)he has chosen approximate instead of precise location? (Note that a boolean indicating whether the phone is on the user's home network would be fine; we're not interested in the specific SSID per se, if such a boolean was available - the SSID check is only a workaround)

My team maintains a (proprietary) communication library that allows other developers in our company to write Apps that communicate with devices on the local network. To discover these devices we currently use SSDP, for which we use broadcasting on IPv4 and multicasting on IPv6. Thus, we expect that we will need the new com.apple.developer.networking.multicast entitlement on iOS 14 (for the short term; we consider migrating to Bonjour later - that requires rewriting the firmware for those devices). We have installed iOS 14.0 Beta 3 (18A5332f) on an iPhone XS (model A2097) and performed these two tests: Xcode 11.6 (11E708) / iOS 13 (Enterprise) build: we get the local network privacy dialog (with the default reason text) and after that discovery works, as expected - https://developer.apple.com/forums/thread/653139 Xcode 12.0 beta 3 (12A8169g) / iOS 14 (Debug) build, without the new entitlement: we again get the local network pricacy dialog (with the reason we put in Info.plist) and after that discovery still works, which we did not expect... Why does that iOS 14 specific build still work without the new entitlement? How should we test this instead to prepare for iOS 14's Local Network Privacy? (PS: We requested the entitlement, but we did not get it yet)

We're developing a connectivity library for IoT devices. It should support authentication using a variant of RFC 7235 (HTTP Authentication). From that specification: "A user agent that wishes to authenticate itself with an origin server can do so by including an Authorization header field with the request." To implement this feature we are executing (URLRequest's) setValue(..., forHTTPHeaderField: "Authorization") on our requests. While that seems to work we are worried about this text about "Reserved HTTP headers - https://developer.apple.com/documentation/foundation/nsurlrequest#1776617" (which include the "Authorization" header) in the Apple documentation: "If you set a value for one of these reserved headers, the system may ignore the value you set, or overwrite it with its own value, or simply not send it. Moreover, the exact behavior may change over time. To avoid confusing problems like this, do not set these headers directly." So our approach is wrong? How should we do this instead?

We're developing a connectivity library for IoT devices. It should support uploading (chunks of) firmware images to an IoT device over Wi-Fi. To implement this feature we are performing "PUT" requests to an embedded HTTP server using URLRequest, but we noticed that the URL Loading System automatically inserts several HTTP header fields that the IoT device does not care about. Since this particular device has a very small buffer having a large header means there's not much space left for data (a chunk of the firmware image). How can we minimise the headers of a request? Or, what technology should we be using instead? (While still using the embedded HTTP server of the IoT device)