eskimo

[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

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. The screenshot above is the iOS system's crash log Just clarify what we’re talking about here, this is an Apple crash report from iOS 26.1: Exception Type: EXC_BAD_ACCESS (SIGKILL) Exception Subtype: KERN_PROTECTION_FAILURE at 0x0000000000000000 … Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 ??? 0x0 ??? 1 Test808813 0x10058c128 -[MainViewController tableView:didSelectRowAtIndexPath:] + 100 2 UIKitCore 0x1a563bc98 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMult… 3 UIKitCore 0x1a563bfbc -[UITableView _userSelectRowAtPendingSelectionIndexPath:animatedSelection:] + 255 4 UIKitCore 0x1a563c0c8 -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 215 5 UIKitCore 0x1a407d878 -[_UIAfterCACommitBlock run] + 71 … You’re concern is with that SIGKILL, where prior to iOS 18 this was a SIGSEGV. That doesn’t strike me as a proble