The call stack is followed: Incident Identifier: 5DBD18B5-29DD-48E1-8BE5-A648BD4E8CE3 CrashReporter Key: 4006fd6d63831c08be5068429b9892f633d41735 Hardware Model: iPhone12,5 Process: XXX Path: /private/var/containers/Bundle/Application/FD114B6F-9C45-4546-9924-082A2CF546B8/XXX.app/XXX Identifier: com.xxx.xxx Version: 2.0.0 (2.0.0.3) AppStoreTools: 13A227 AppVariant: 1:iPhone12,5:13 Code Type: ARM-64 (Native) Role: Unspecified Parent Process: launchd [1] Coalition: com.xxx.xxx [2761] Date/Time: 2021-09-28 14:24:03.8329 +0800 Launch Time: 2021-09-28 14:24:03.5890 +0800 OS Version: iPhone OS 15.0 (19A346) Release Type: User Baseband Version: 3.00.00 Report Version: 104 Exception Type: EXC_GUARD Exception Subtype: GUARD_TYPE_USER Exception Message: namespc 18 reason_code 0x0000000000000002 Exception Codes: 0x6000000000000012, 0x0000000000000002 Exception Note: SIMULATED (this is NOT a crash) Termination Reason: LIBSYSTEM; [2] Thread 3: Crashed 0 libsystem_kernel.dylib 0x1b80a2ae8 os_fault_with_payload + 7382641384 ((null)) 1 libsystem_trace.dylib 0x000000019bd941b4 _os_log_impl_flatten_and_send + 6909673908 ((null)) 2 libsystem_trace.dylib 0x000000019bd90b70 _os_log + 6909660016 ((null)) 3 libsystem_trace.dylib 0x000000019bd98cac _os_log_fault_impl + 6909693100 ((null)) 4 SyncedDefaults 0x1ad034c90 -[SYDRemotePreferencesSource initWithApplicationID:storeID:shared:additionalSource:containerPath:storeType:].cold.1 + 52 5 SyncedDefaults 0x1ad027210 -[SYDRemotePreferencesSource initWithApplicationID:storeID:shared:additionalSource:containerPath:storeType:] + 1400 6 Foundation 0x182ff5d58 -[NSUbiquitousKeyValueStore initWithBundleIdentifier:storeIdentifier:additionalStore:storeType:] + 348 7 Foundation 0x182fd8e84 __41+[NSUbiquitousKeyValueStore defaultStore]_block_invoke + 24 8 libdispatch.dylib 0x000000018140194c _dispatch_client_callout + 6463428940 ((null)) 9 libdispatch.dylib 0x00000001814031d4 _dispatch_once_callout + 6463435220 ((null)) 10 Foundation 0x182fe0668 +[NSUbiquitousKeyValueStore defaultStore] + 64 ... // omit insignificant call stack of the app 14 libdispatch.dylib 0x00000001813ffc00 _dispatch_call_block_and_release + 6463421440 ((null)) 15 libdispatch.dylib 0x000000018140194c _dispatch_client_callout + 6463428940 ((null)) 16 libdispatch.dylib 0x0000000181413064 _dispatch_root_queue_drain + 6463500388 ((null)) 17 libdispatch.dylib 0x0000000181413764 _dispatch_worker_thread2 + 6463502180 ((null)) 18 libsystem_pthread.dylib 0x00000001f12c5170 _pthread_wqthread + 8341180784 ((null)) 19 libsystem_pthread.dylib 0x00000001f12c4f4c start_wqthread + 8341180236 ((null)) What's mean the Exception Note: SIMULATED (this is NOT a crash)? It's not a crash? And then, is it possible a bug in iOS 15？because no crash reports before iOS 15. Thanks.

We are having a problem with customers who use Apple Private Relay not being able to reach our site. We have figured out that Apple uses various CDN's to relay traffic for their Private Relay service. Traffic through Akamai gets to us, but traffic through Cloudflare does not. In particular here are several IP addresses through which traffic cannot reach 72.51.60.65 (https://www.hushmail.com) 8.44.60.4 8.44.60.50 8.44.60.14 8.6.145.47 8.6.145.103 When I look them up they show as being Cloudflare IP addresses. Here's another one that doesn't work, that doesn't show as Cloudflare: 104.28.85.13 Does anyone have a suggestion for an avenue to pursue to get this resolved?

I have added SPF(TYPE DOMAIN) record in apple account , but the emails which users are getting are going in their spam folder through private relay. How can we resolve this , so that all emails will go in inbox instead of spam.

I am trying to receive a email from private relay email but it does not seem to work. I can send email to private relay email but person received this email cannot reply back. I have set up SPF and DKIM for the domain and registered the domain in apple developer account(email communication). Is there anything else I should do to debug this?

When will this be out of beta and stable enough to use?

Why content view is having gap with scroll view on right side despite its trailing constraint set to 0 and scroll view constraints also (0,0,0,0) ?

Process: Xcode [1587] Path: /Applications/Xcode.app/Contents/MacOS/Xcode Identifier: com.apple.dt.Xcode Version: 13.1 (19466) Build Info: IDEFrameworks-19466000000000000~20 (13A1030d) App Item ID: 497799835 App External ID: 844664792 Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: Xcode [1587] User ID: 501 Date/Time: 2022-03-29 10:23:49.635 +0800 OS Version: macOS 11.5.1 (20G80) Report Version: 12 Bridge OS Version: 5.5 (18P4759a) Anonymous UUID: C651A600-7A6C-460E-9CE3-2E55CF2ED3D6 Sleep/Wake UUID: C50EB53F-CBBF-4E86-9F83-66EE17220ABE Time Awake Since Boot: 3600 seconds Time Since Wake: 3000 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Application Specific Information:

Is there anyway to test the iCloud Private Relay for IP address security or DNS leaks? I use a router based VPN and when I enable the iCloud Private Relay with my router based VPN active, my IP address is not secured and there are DNS leaks. When I disable the iCloud Private Relay, then my IP address is secured and there are no DNS leaks, my IP address is secured and there are no DNS leaks. Apple claims All Safari web browsing and all DNS queries as users enter site names will be protected by the Private Relay. Apple states Private Really can be used alongside one's VPN. However, Apple also states traffic using a regular VPN will not be protected. Am I the only one who is confused by this statement?

I have a VPN app that uses a tunnel to route traffic, and I'm finding that port 80 traffic cannot be routed when Private Relay is enabled. Oddly, it's just port 80 traffic. HTTP traffic over 8080 or other ports still work fine. Specifically, connecting the socket using the connect() function for a port 80 address always returns the same error "No route to host". According to the Packet Tunnel Provider documentation (https://developer.apple.com/documentation/networkextension/packet_tunnel_provider?language=objc): When a VPN configuration is active, connections use the VPN instead of iCloud Private Relay. Network Extension providers also don’t use iCloud Private Relay. This is not the behavior that we are seeing. As soon as I disable Private Relay on the device, the port 80 traffic flows correctly and there's no more errors. We already tried excluding the Private Relay servers from the tunnel, but that didn't have any impact on this issue. Is there anything else we could try to work around this? So far we've tested with iOS 15 beta versions through beta 4. Also tested on developer versions as well as public beta.

Hello, I'm the administrator of the dns server. I am writing a question because I am curious about the resolver server used by Icloud Private Relay. If the ip is changed from Relay2 of Icloud Private Relay, which resolver server will you use to dns query? Do you use cloudflare,akmai,fastly resolver server? Or do you use Apple's own resolver server? Also, do you have official documents related to apple, cloudflare, akmai, and fastly? It doesn't matter if it's not related to the content of the post. If you know anything about this, please reply. I can't speak English or other foreign languages well. Thank you for your help. Thank you.

I'm working on building functionality for an app using the Network Extension to setup an EncryptedDNS resolver for certain domains relevant to my app. I need to detect whether the iphone user has Private Relay enabled in order to determine how my app behaves while setting up the encryptedDNS resolver. What APIs can I use to determine if Private Relay is active? Is it available as a preference? I can't find any documentation around this.

Dear Apple, I use Little Snitch (An application firewall) to manage exactly what websites/domains apps should be allowed internet access. And which sites shouldn't have any access. Like in Safari or Mail ... I don't grand access to hostnames that include anything that can be derived to have an association to "Tracking" ... say: Little Snitch works like a charm. Or to say: It works until you don't enable "iCloud Private Relay". With iCloud Private Relay turned on, it circumvents Little Snitch granting access to every site/hostname without checking with my "Application Firewall" - if it's allowed to have access to said site or not. I guess this is because iCPR is 1st in the hierarchy over Little Snitch. And it makes sense. If you don't have an Application Firewall running ... you want iCPR to be the 1st to intercept all connection activities. But for us who do have an Application Firewall ... it doesn't. I wish to go into "Set Service Order" and drag Little Snitch to be 1st in this list ... then iCPR ... and then Ethernet 1 ... etc etc. This way, I could 1st block any access to any "Tracking site" ... don't even let the app connect to it! Since, why should they even have my data? Any data about me?! ... Even if it "anonymised", it's best to not give them any data at all. Null ... zilch! :-) Could you please add/tweak this "Set Service Order" to allow/grant us, the users to choose how we would like to filter our connections. cheers, Daniel

I have a transactional welcome email sent to users. In testing users replying back to my sender address, I received a delivery error from one user via private email relay service - "550 Relay is not allowed". Can someone pleasee advise? Replies have worked for other users using Apple's same private email relay service...and domains have also already been registered/verified.

When Private Relay is on I get most of the time Akamai DNS servers, rarely Cloudflare. The problem is that those servers don't have DNSSEC. It is a server problem or a Private Relay "feature"? Tnx

In the user interface, Apple says: iCloud Private Relay keeps your internet activity private Private Relay hides your IP address and browsing activity in Safari and protects your unencrypted internet traffic so that no one-including Apple-can see both who you are and what sites you're visiting BUT when I look at the Apple IT support documentation the above is contradicted. Based on it, what would be true is: iCloud Private Relay keeps your WEB activity private Private Relay hides your IP address and browsing activity in Safari and protects your unencrypted WEB and UNENCRYPTED APP traffic. In addition to the corrections I made above, the rest of it (below) is just…terribly problematic! I’m not even sure how to correct it but it’s wrong. Agreed? I mean any aware user is (likely) going to know that if you tell a website like your bank) who you are, while using iCloud private relay (IPR), it will know who and where you are. But they’ll also know your IP, since Apple is saying only to us that encrypted internet traffic doesn’t go through IPR. This would include HTTPS, SMTPS, IMAPS, GOPHERS, … And even a fairly savvy user reading the following isn’t going to realize that Apple is not fixing the Panopticon problem, meaning that as is, the following part is generally false and de deceiving: …so that no one-including Apple-can see both who you are and what sites you're visiting. What’s a customer going to think when they realize that our apps aren’t delivering what Apple‘s promising because it’s inconsistent about what is promising to who? Is there already discussion going on about this? seems like a big issue… Fortunately, Apple is saying the product is in beta, so they will likely be extra open to and relatively responsive to feedback. But I wanted to talk with other developers about it so that’s why am bringing it up here. Maybe I’m misunderstanding stuff.

While working to use the iOS on an enterprise network, both the App Store and the Music app on iOS 15 do not connect to the Apple backend services if DoH access is unavailable. Restrictions were applied on a lab environment with a set of Cisco NGFW firewalls running FTD 7.0.1 and FTD 7.1. Restrictions on the DNS end, for restricting access to the iCloud Private Relay (as per "Allow for network audits" section) and to the DoH address (using the same methodology as above) were attempted, in a combination with the security appliance, to no avail. Tested on different devices running iOS 15.1, 15.1.1 and 15.2. Traffic inspection was not enabled on this lab. The test account is an active iCloud+ subscription. The security appliances were running with Snort3 IPS, however no IPS policies were present on any of the access control lists, nor configured on the appliances. While the DNS configuration at the iOS device states "DNS requests are being routed by iCloud Private Relay for this Wi-Fi network", ultimately there seems this option is not being respected. Although not thoroughly tested, it appears macOS 12.1 is also affected with at least the Music app, and a HomePod (15.1.1) is also unable to play songs with DoH restricted from the DNS view: Siri answers the request but doesn't play the requested songs.

Since enabling my iCloud Privacy Relay my encrypted traffic is suffering a DNS blockage caused by my Routers settings. This is stopping my private network connecting. I have remotely accessed my router and run through the Apple security prompts but all seems to be as stated but they is no reference to the issue caused by DNS? I see a load of similar issues but will someone post a relay in ‘stupid’ as I have no idea what they are going on about!!

For NETunnelProvider extension , In a device wide VPN scenarios, is it possible to make Private relay work.

How can I receive my emails sent to privaterelay.appleid.com because I signed with my Apple ID thinking it would be convenient

Is the egress list for Private relay also used by Mail Privacy protection?