eskimo

[quote='868809022, Mathias_, /thread/808401?answerId=868809022#868809022, /profile/Mathias_'] just fire off the request blindly and wait to see what happens? [/quote] Yes. And use an expiration handler to deal with the case where the network is super slow. That last bit is critical, because it crops up in practice. In most cases an immediate network request — that is, one without waitsForConnectivity set — will finish promptly. It’ll either succeed or it’ll fail immediately. But there are networks out there in the real world where such requests take a long time. Sometimes that’s caused by bad network conditions. The network is moving packets just fast enough to convince iOS to use it, but not fast enough to get anything useful done. But in other cases it’s caused by weird network configurations. For example, a Wi-Fi accessory might publish a network that goes out of its way to convince iOS that it has a path to the wider Internet when it actually doesn’t. Now, unless you have access to such a network then tes

[quote='868691022, swdev-sos, /thread/809359?answerId=868691022#868691022, /profile/swdev-sos'] Quite the head scratcher. [/quote] Indeed. Earlier you wrote: [quote='868691022, swdev-sos, /thread/809359?answerId=868691022#868691022, /profile/swdev-sos'] if my coworker creates the application … I can then use his application in my pkgbuild script and the installation succeeds. [/quote] So lemme summarise: Builder Packager Installer Result ------- -------- --------- ------ you you you NG them them them OK them you you NG Have you tried the following combination: Builder Packager Installer Result ------- -------- --------- ------ you you them ? What happened? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='868820022, AppDevVa , /thread/809565?answerId=868820022#868820022, /profile/AppDevVa+'] Could you please confirm this understanding? [/quote] That sounds right. Peer-to-peer Wi-Fi works in all of the following scenarios: If both devices are on the same infrastructure Wi-Fi network. If the two devices are on different infrastructure Wi-Fi networks. If neither device is on an infrastructure Wi-Fi network. Any combination of the above. But, yeah, I recommend that you create a tiny prototype and test this in your specific environment, because it certainly sounds weirder than most (-: [quote='868820022, AppDevVa , /thread/809565?answerId=868820022#868820022, /profile/AppDevVa+'] would a WebSocket-based connection be sufficient compared to a peer-to-peer Wi-Fi solution? [/quote] That question doesn’t make sense. Peer-to-peer Wi-Fi supports TCP connections [1] and WebSocket runs over TCP. So these don’t stand in opposition. You can use WebSocket over any TCP connection. If you set up a TCP connection over pe

[quote='868852022, hpux735, /thread/809562?answerId=868852022#868852022, /profile/hpux735'] What did that link go to? [/quote] It’s not a link but a footnote. Look at the bottom of my previous post. However, if you want links, I’ve got links (-: The obvious way to run Wasm code on Apple platforms is with the open source WasmKit runtime. But that’s not your only choice. There are lots of different Wasm runtimes out there. Oh, and I’d be remiss if I didn’t mention that there’s a standard way to compile Swift code to Wasm. See Getting Started with Swift SDKs for WebAssembly. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='868889022, jed.gyeong, /thread/808899?answerId=868889022#868889022, /profile/jed.gyeong'] Given this requirement, does this mean there is indeed a bug in the current Network framework WebSocket implementation? [/quote] Well, the one doesn’t follow from the other, but, yes, I believe that: WebSocket allows for empty ping and pong frameworks And thus this is a bug in Network framework We’ll use your bug (FB21240977) to track its resolution. If you need a workaround right now, you should try using the older NWConnection API. It lacks many of the smarts of NetworkConnection but I don’t think it’ll suffer from this problem. [quote='868889022, jed.gyeong, /thread/808899?answerId=868889022#868889022, /profile/jed.gyeong'] And could you also check whether this issue occurs with other opcodes besides ping/pong? [/quote] No, sorry. Running such a test would require more time than I have available right now. But there’s nothing stopping you from doing it (-: Share and Enjoy — Quinn “The Eskimo!” @ Devel

I can’t really speak to the MDM side of this but, in general, it’s not possible to change the ACL on a keychain item without user interaction [1]. The issue is that every keychain item starts out with a default ACL and that default ACL has an entry that requires user interaction to change the ACL. The only way to avoid this is to create the item with a non-default ACL, but if you’re sufficiently on the ball to do that then you might as well just create the item with the right ACL up front. On iOS you can avoid this entire issue by leaning into the ManagedApp framework. Unfortunately that’s not available on macOS )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] To be clear, ACLs are only relevant to file-based keychains, including the System keychain. macOS also supports the data protection keychain, and ACLs are irrelevant there. See TN3137 On Mac keychain APIs and implementations for more background on that.

You haven’t asked any questions here, which makes me think that you’re goal is to report this as a bug. If so, you should do that using Feedback Assistant. See Bug Reporting: How and Why? for lots of context on that. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m not sure I understand your questions so lemme you start you out with some ‘light’ reading. Check out the various posts linked to from Extra-ordinary Networking. These give a lot of background to this issue and, specifically, Working with a Wi-Fi Accessory defines terminology that you can use in any follow-up questions you have. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='809672021, SachinHk, /thread/809672, /profile/SachinHk'] I attempted the following approach [/quote] This approach won’t work in general. iOS devices regularly find themselves in situations where the traditional resolve-then-connect approach won’t work. I talk about this in general terms in the Connect by name section of TN3151 Choosing the right networking API Additionally, this is problematic: [quote='809672021, SachinHk, /thread/809672, /profile/SachinHk'] Set the original domain in the Host HTTP header [/quote] The Host header is ‘owned’ by URLSession and not something you can reliably set. See here. Fortunately, there’s an alternative approach that should work, namely to set a per-app DNS resolver. You can do this via Network framework’s privacy context mechanism. See this post for an example. ps It’s really hard to read your post. To avoid problems like that in the future, have a read of Quinn’s Top Ten DevForums Tips, and specifically the discussion of code blocks in tip 5. Share and Enjoy — Qu

[quote='809732021, Joe_Chou, /thread/809732, /profile/Joe_Chou'] Beyond these measures, are there any other strategies [to] help the device cool down? [/quote] It’s hard to answer that without knowing more about what your app does. The general answers is: Work out which operations in your app use a lot of power. When you receive a thermal state notification, stop or reduce those. For lots of good info on how to get started with step 1, watch WWDC 2025 Session 226 Profile and optimize power usage in your app. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='809639021, Suhyeon, /thread/809639, /profile/Suhyeon'] Has anyone else experienced this specific ASDErrorDomain error? [/quote] I don’t know much about App Clips but I can share a little insight into the error. The ASD in ASDErrorDomain stands for App Store daemon. That means pretty much what it says. Unfortunately the error code 507 is not helpful. It’s a generic error that has a wide variety of potential causes. My experience with generic errors like this is that they’re often reflected in the system log and the surrounding log entries can yield a clue as to what might’ve caused them. Finding stuff in the system log can be tricky though; I have a bunch of hints and tips on that in Your Friend the System Log. [quote='809639021, Suhyeon, /thread/809639, /profile/Suhyeon'] We have already submitted a report via Feedback Assistant [/quote] What was that bug number? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Let’s focus this discussion on your other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

As you’ve noticed, Swift Playground currently doesn’t support the iOS 26 SDK. We understand that there’s strong demand for that, but I can’t offer any advice as to when it’ll happen. If you need you use iOS 26 SDK features right now, your only real option is to create your playground with Xcode. Make sure to create an app playground, as explained on Developer > Swift Student Challenge > Get ready. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This came up in a different context, and I wanted to post the associated bug number (FB21271237) here, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

It might seem like the mechanism to build the list of cypher suites in the Client Hello is simple — you start out with some defaults and then every call to sec_protocol_options_append_tls_ciphersuite adds one to the end — but that’s not the case. Like pretty much everything in TLS, it’s ridiculously complicated, based on factors like TLS version, policy, hardware capabilities, and so on. You can get an inkling of this in the BoringSSL open source but the Apple version of that is significantly more complicated. After spending way too much time down that rabbit hole, I came to the conclusion that I was actually trying to describe the implementation, not the API, and that’s not good [1]. I think the only thing you can safely say about the sec_protocol_options_append_tls_ciphersuite API is that it adds the cypher suite to the list of cypher suites that the implementation might choose to use. Which brings me to a question: What’s your high-level goal here? Why do you need these specific cypher suites enabled? Shar