“translate scheme”

Universal Links are generally preferred over custom URL schemes these days. — Ed Ford,  DTS Engineer

[quote='795547021, wangshixiong, /thread/795547, /profile/wangshixiong'] Why does NSURLSession with the multipath service type seamlessly use cellular when the Wi-Fi has no internet, but WKWebView does not exhibit the same fallback behavior? [/quote] Because Multipath TCP (MPTCP) is something you have to opt in to. You’re doing that with URLSession by setting the multipathServiceType property. You can’t do that with WKWebView because it doesn’t have the equivalent of that property, and thus it uses regular TCP. Regular TCP won’t do this sort of switching. The fundamental issue here is your Wi-Fi network. It seems like your accessory is publishing a network that claims to provide access to the Internet but doesn’t. This causes iOS to switch the default route, which then triggers this problem. The best solution to this problem is to change your accessory to not do that. There are other options, as I explain in Working with a Wi-Fi Accessory. That post in part of my Extra-ordinary Networking series, and the othe

However, I can't find info.plist in the project folder. Xcode moved much of what used to be in the Info.plist file into build settings for those that can be represented as simple key-value pairs several releases ago. As a result, some of the Xcode templates no longer create a file called Info.plist as part of the template when you start your app. However, if you need custom values in your Info.plist file, you can still add them through the Targets > Info tab — just click the + button on a row in the Custom Target Properties section and add your values, and Xcode will create an Info.plist file on disk that holds those custom values. Note that I'm not saying to do this in the URL Types section, unless you're specifically trying to create a custom URL scheme. Doing this configuration in the other section I name above could make the difference from the other info you found. — Ed Ford,  DTS Engineer

This project worked fine in visionOS 2.5 & Xcode 16.4. We do have a custom process to load the bundle though, we build our package with a custom script: #!/bin/sh rm -rf ./.build xcodebuild -scheme RealityKitContentPackage -destination 'generic/platform=visionOS' -configuration Release -derivedDataPath ./.build clean build rm -rf 'TGV INOUI/Assets/RealityKitContent/RealityKitContent.bundle' cp -rf .build/Build/Products/Release-xros/RealityKitContent_RealityKitContent.bundle/ 'TGV INOUI/Assets/RealityKitContent/RealityKitContent.bundle' rm -rf .build and load it this way: var realityKitContentBundle: Bundle { let bundleURL = Bundle.main.url(forResource: RealityKitContent, withExtension: bundle)! return Bundle(url: bundleURL)! } The scene is then loaded like this: environmentEntity = try! await Entity(named: TGVM, in: realityKitContentBundle) We discovered today that the issue is coming from the fact that our 3D files are in the .usdc format, when using .usdz things are working as inteded. But

Ah, right, this is one of those weird CFNetwork edge cases. You can actually see the root cause with your curl command: % curl https://ss3.at.docu-tools.com --cert-type P12 --cert client_full.p12 --pass 1234 --cacert ca.pem -v … * [HTTP/2] [1] OPENED stream for https://ss3.at.docu-tools.com/ * [HTTP/2] [1] [:method: GET] * [HTTP/2] [1] [:scheme: https] * [HTTP/2] [1] [:authority: ss3.at.docu-tools.com] * [HTTP/2] [1] [:path: /] * [HTTP/2] [1] [user-agent: curl/8.7.1] * [HTTP/2] [1] [accept: */*] > GET / HTTP/2 > Host: ss3.at.docu-tools.com > User-Agent: curl/8.7.1 > Accept: */* > * Request completely sent off < HTTP/2 403 … So the TLS handshake works, after which curl issues the GET command, and that fails with a 403. In curl that’s considered an HTTP error rather than a transport error. However, CFNetwork, for its own obscure reasons, translates an HTTP error 403 after a client certificate authentication challenge into a NSURLErrorClientCertificateRequired transport error.

When you build your app for release, what does the on-disk structure look like. For example, here’s what I see when I build a project I created rom one of Xcode’s built-in templates: % find Test795348 04-08-2025, 10.47.xcarchive/Products/Applications/Test795348.app …/Test795348.app …/Test795348.app/_CodeSignature …/Test795348.app/_CodeSignature/CodeResources …/Test795348.app/Test795348 …/Test795348.app/embedded.mobileprovision …/Test795348.app/Info.plist …/Test795348.app/PkgInfo Specifically, I’m interested in the final disposition of your Mach-O images. Feel free to elide anything that’s not directly related to that, such as your resources. Also feel free to redact any private info you don’t want to share. In Posting a Crash Report I describe a simple redaction scheme that I’ve found works well for artefacts. The reason I’m asking this is that iOS imposes some strict limits on how you can embed code within an iOS app. See Placing Content in a Bundle for info about that. And, quoting that doc: If you

Before I start, I want to be clear that I can’t help you with third-party tooling. If you need help translating my response to your third-party setup, I recommend that you seek assistance from that third-party’s support channel. On the Apple side of things, there are three common causes of the problems like this: App Transport Security Local network privacy Interface lifecycle For the first, I recommend that you temporarily use NSAllowsArbitraryLoads to disable ATS completely. Once you get things working reliably, you can go revisit that choice. Setting up secure communication with an accessory is tricky; see TLS For Accessory Developers for my advice on that front. For the second, see TN3179 Understanding local network privacy. For third, this is something I discuss in detail in various posts hanging off Extra-ordinary Networking. Specifically, Working with a Wi-Fi Accessory defines three categories of Wi-Fi based accessory, and it’s important to understand this category before you go further Share