Post not yet marked as solved
We're already doing that to include the privacy manifest (PrivacyInfo.xcprivacy) in the sources we provide.
However, Xcode does not add this manifest into the (aggregated) privacy report, so App developers will (unfortunately) have to check this privacy manifest themselves (manually).
We're looking for a way to get the privacy manifest included in the privacy report, when using CocoaPods.
Post not yet marked as solved
I'm not sure I understand your answer: is that a "Yes" or a "No"?
We don't use CoreLocation, but (from your link):
Information that describes the location of a user or device with the same or greater resolution as a latitude and longitude with three or more decimal places.
Does the SSID pinpoint a location with that high precision?
(If so, we should add this data type, according to this documentation)
This problem does not reproduce with Xcode 15 Beta 2.
Or is it because I now have to quit Cisco AnyConnect to see an iPhone?
After I quit Cisco AnyConnect Secure Mobility Client (which I have to use to connect to my company's network via VPN) Xcode does see that iPhone...
What kind of network access is required to connect over USB? (What could Cisco be blocking?)
Post not yet marked as solved
Two more colleagues are now suffering from this issue. Any updates?
Post not yet marked as solved
Several people on the internet suggest removing (relevant, com.apple.pkg.CLTools_*?) receipts from /Library/Apple/System/Library/Receipts, but that requires (temporarily) disabling SIP.
Might be a solution for some, but I'd rather have a cleaner one...
Post not yet marked as solved
Today I even had to re-install the certificate 3 times! (instead of once every day...)
Any fix for this?
(I already have all Apple certificates installed)
Post not yet marked as solved
I also got hit by this issue, even after re-installing Apple's root certificates.
My workaround is to delete my development certificate from the keychain, download it from the developer web site, and re-install it.
The developer certificate will then be trusted for the remainder of the day.
However, the next morning it is not trusted again!
So I have to apply this workaround every morning... Huh?
What's the proper fix?
Post not yet marked as solved
Apparently somebody else posted the same issue on Stack Overflow about two months ago:
https://stackoverflow.com/questions/63130232/cncopycurrentnetworkinfo-not-working-with-ios-14
I suppose this is intended behaviour to better protect the user's privacy, but how can we achieve our goal?
(We have no intention of invading privacy, we just want to prevent unnecessary costs for our users)
Post not yet marked as solved
Unfortunately this issue is still present in iOS 14 GM (18A373) with Xcode 12 GM (12A7208).
Post not yet marked as solved
Still present in iOS 14 Beta 8 (with Xcode 12 Beta 6 - there's again no Xcode update?):
all HTTP/1.1 200 OK replies are ignored
NOTIFY * HTTP/1.1 notifications are delivered
Post not yet marked as solved
Still present in iOS 14 Beta 7 (with Xcode 12 Beta 6 - there's no Xcode update, yet?).
Not sure whether this is true for previous beta's, but it currently seems to be like this: all HTTP/1.1 200 OK replies are ignored
the NOTIFY * HTTP/1.1 notifications are delivered to NWConnectionGroup's receive handler
Post not yet marked as solved
Unfortunately this issue is also present in iOS 14 Beta 6.
Post not yet marked as solved
Matt, we had the crash with iOS 14 Beta 4 and Xcode 12 Beta 4, but can't reproduce it with iOS 14 Beta 5 and Xcode 12 Beta 5 (released a few hours ago) so far.
However, SSDP is still failing for us due to an address already being in use, as discussed in this thread - https://developer.apple.com/forums/thread/652125?answerId=627943022#627943022.
Would be great if you could give us some assistance there!