When a VPN is active, RCS messaging does not work on iOS 18. I work on an iOS VPN app, and we were very appreciative of the excludeCellularServices network flag that was released during the iOS 16 cycle. It's a great solution to ensure the VPN doesn't interfere with cellular network features from the cellular provider. Separately - As a user, I'm excited that iOS 18 includes RCS messaging. Unfortunately, RCS messaging is not working when our VPN is active (when checking on the iOS 18 release candidate). My guess is that RCS is not excluded from the VPN tunnel, even when excludeCellularServices is true. It seems like RCS should be added in this situation, as it is a cell provider service. Can RCS be added as a service that is excluded from the VPN tunnel when excludeCellularServices is true? (I've also sent this via feedback assistant, as 15094270.)

iOS 17.4 added a new flag for VPNs: excludeDeviceCommunication. The documentation does not include any description of what it does (though an Apple engineer explained it during a WWDC labs session). Can the documentation be updated to add some explanation for this? Thank you!

I work on an app that includes a network extension. The app is essentially just to activate the extension, and the extension typically has long-running background sessions. Analyzing/monitoring metrics for the network extension is very important for us. However, in the Xcode Organizer screen, only the app itself is shown in the drop down menu - the associated network extension is not an option. For Xcode Organizer screens like Termination metrics and Battery Usage metrics, does the app's background metrics include the network extension, or just the app itself? If just the app, is there any way to get these metrics for the network extension?

All the steps within our Archive action complete as expected with green checkmarks (including all Prepare Build for App Store Connect steps), but the Archive action itself never completes. It keeps spinning and never passes it off to the post-action to release the build to TestFlight. The system status page says Xcode Cloud had issue for multiple days this week, but they resolved 14 hours ago. I've re-run our build several times today and keep running into this problem. Is this something server-side?

I'm really excited by the idea of the privacy manifests, and really all the work Apple is doing to keep users protected. I work on the Mozilla VPN, and Mozilla shares Apple's commitment to privacy. We use Adjust to determine referrals for new subscriptions. But because of our commitment to privacy: After a user subscribes, we never activate the Adjust SDK on future app runs. We proxy the Adjust network call through our app, and strip out most of the fields it was going to send to the Adjust server. We keep a small handful of fields that are necessary for attribution (and even publish the list of those fields). Further, we don't send the Adjust network request (which has been stripped down) directly to Adjust's servers, we proxy it through our own server first. This both keeps user IP addresses private, and allows us to further strip out payload values on the server (or stop sending data onto Adjust entirely) if ever needed. Ultimately, this means Adjust's future privacy manifest likely won't be accurate for our app, as we're significantly modifying the Adjust SDK behavior and data collection. Questions: Will we be able to note in Xcode that the listed privacy manifest doesn't apply in our case? If there are future plans to compare privacy manifests with app nutritional labels in the App Store Review process, is it possible to consider this use case in your planning? Thanks!

When testing our IAP subscription in a new locale, our QA team noticed that the amount displayed in our app (which came from a SKProduct, from Apple's IAP servers) differed significantly from what was shown in Apple's sandbox subscription confirmation modal. The amount in our app was correct, but the modal showed the wrong amount. I haven't seen this before, and can't come up with much of an explanation for why this happened. Is this a bug in Sandbox subscription testing for IAP?

I work on an iOS VPN app, and we're having some problems with the interaction between MMS and the includeAllNetworks flag. When the includeAllNetworks flag is on, MMS sending fails. I believe this is because iOS is trying to go outside the VPN tunnel and over cellular and is using the cellular network's default DNS lookup for the MMS server (in a sample case we've been using for testing, mms.msg.eng.t-mobile.com). (Logs seem to show the phone dropping back to cellular even when it has a strong WiFi connection.) I believe iOS also chooses the cellular connection when making the request where the MMS packets are sent. And thus with includeAllNetworks active, iOS does not permit these packets through, causing the MMS send to fail. Does this explanation above seem accurate, and seem like why MMS isn't working with the VPN active? We've been debugging via Console logs, and can see the DNS request fail, but have limited insight into the lower level parts of the networking stack. Does includeAllNetworks override any IP addresses in the excludedRoutes array, effectively neutering excludedRoutes when it is active? It seems like it does, but I haven't been able to find any documentation saying so. If so, is there any way to allow MMS to go outside the VPN while otherwise keeping includeAllNetworks active? We want to keep MMS working*, but prevent any other traffic leaks. We can't figure out a way to do this without turning off includeAllNetworks. `* While this is more philosophical, it seems like MMS going outside the tunnel isn't a giant security concern. Presumably the cell provider knows the phone's IP address already, and SMS messages already go clear over the wire.