eskimo

OK, I have the info from the DTS case. [quote='871895022, shabnamk, /thread/812271?answerId=871895022#871895022, /profile/shabnamk'] We do leverage Network Extensions for majority of our work flows [/quote] That’s not really the sort of answer I was looking for )-: Lemme explain the background to this. Historically VPN products on macOS used a variety of ad hoc techniques to get things working. DTS uses to support such things, but with the advent of Network Extension (NE) providers that’s no longer the case. We now only support VPN products based on NE. So, if your VPN product is solely based on NE, then that’s something we support. However, if this problem only crops up because you’re doing non-NE stuff — for example, I often see legacy VPN products modify the System Configuration dynamic store directly — then we don’t support that. So, is your VPN product playing by these rules? And more importantly, if you configure your product to play by these rules, can you reproduce this problem? If so, my advice is th

If your goal is report problem, DevForums isn’t the right place for that. I generally recommend that you file bug reports via Feedback Assistant. See Bug Reporting: How and Why? for more on that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='871669022, KayleeSC, /thread/791352?answerId=871669022#871669022, /profile/KayleeSC'] Should I take that to mean that the relay validation thing is happening, now? [/quote] There are two things in play here: Your request for relay support (r. 159656262) The App Store submission problem (FB19582905) My understanding is that the first is done with, that is, you are approved to use the relay. That leaves the second, which is what I was talking about in Friday’s post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='872194022, JayKib, /thread/812544?answerId=872194022#872194022, /profile/JayKib'] I replied to their email trying to clarify [/quote] Good. That’s the right thing to do. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='872181022, lilan, /thread/773414?answerId=872181022#872181022, /profile/lilan'] How about NEDNSProxyProvider … ? [/quote] That’s covered by the Deploying a DNS proxy provider section of TN3134 . [quote='872181022, lilan, /thread/773414?answerId=872181022#872181022, /profile/lilan'] How about … NEFilterDataProvider? [/quote] NEFilterDataProvider and NEFilterControlProvider always comes as a pair [1]. Collectively they form a content filter, which is what we’ve been discussing here. You can’t have just a data provider. [quote='872181022, lilan, /thread/773414?answerId=872181022#872181022, /profile/lilan'] The URL Filters only support iOS 26+ right? [/quote] Correct. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] On iOS. The rules for content filters on macOS are very different, and one of the key changes is that there’s data/control provider separation.

Thanks for those answers. [quote='872062022, disinghal, /thread/811887?answerId=872062022#872062022, /profile/disinghal'] 1. Yes, from within Packet tunnel provider process. [/quote] OK. I’d expect that to work. [quote='872062022, disinghal, /thread/811887?answerId=872062022#872062022, /profile/disinghal'] 2. URLSession [/quote] If you use a low-level API to make a connection to your server, does that go through? Specifically, I’d like you to try using Network framework for this, meaning NWConnection in Swift or nw_connection_t in C-based languages. Note that this is just a diagnostic test, not a suggested fix. The advantage of testing this with Network framework rather than URLSession is that it’s much simpler. URLSession adds a lot of value on top of Network framework, but that also means it has a lot of additional scope for failure. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='872112022, emilsp, /thread/811445?answerId=872112022#872112022, /profile/emilsp'] Given that it is the sigpipe handler that is giving us issues [/quote] I’m not sure that SIGPIPE is involved here. The thing that triggered the read in thread 0x73bb4 could be a SIGPIPE, but it could also be something else that just happens to trigger a read on a pipe. [quote='872112022, emilsp, /thread/811445?answerId=872112022#872112022, /profile/emilsp'] If it is a wonky interaction between the signal handlers, how come does this state reliably reproduce once the bug is hit? [/quote] That’s definitely a weak spot in my theory )-: I would’ve thought that restarting the device would clear this issue. Now, it’s possible that there’s some persistent state in play that gets broken when the job fails to stop as commanded, but I’ve no evidence for that [1]. It’s also possible that this failure to stop is a symptom rather than a cause, that is, something else is causing the problem and that results in this job being unstoppab

I’m a ‘guest’ on Swift Forums, just like you, so I don’t have a definitive answer. The options that spring to mind are: Evolution > Discussion Using Swift The first makes more sense if you think this change should go into Swift itself. See here for more info about the Swift Evolution process. OTOH, the later would be best if you’d like to explore ideas about how to use existing Swift infrastructure to improve the JavaScript experience. And keep in mind that Swift has a lot of existing Cool Tools™ that can aid in these efforts. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

If I’m reading FB21249476 correctly, there should be improvements in this space in Xcode 26.3b2 (25D5101c) [1]. I recommend that you re-test with that build. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] This only just started seeding, so Feedback Assistant hasn’t had time to notify you about it.

[quote='872058022, Youssef-Hammad, /thread/812425?answerId=872058022#872058022, /profile/Youssef-Hammad'] I tried changing the icon of the app after installation and it somehow breaks the signature. [/quote] Indeed. And that’s not a mystery at all. In general, changing content within an app’s bundle will break the seal on the code signature. If you’re curious how that all works, see TN3126 Inside Code Signing: Hashes. But a custom icon is special. You can apply a custom icon to an app without breaking its signature. To see this in action, go to Finder, select your app, choose File > Get Info, select the icon, and paste in an image. I regularly do this with older Xcode versions. For example, my main Xcode is currently Xcode 26.2, but I have Xcode 16.4 around for testing. I apply a custom icon to that older Xcode to help head of the confusion that inevitably occurs when you have multiple versions of Xcode running. If you dig into the on-disk results of this, you’ll see that it makes two changes: It sets the

First things first, for isolating issues like this I recommend that you disable peer-to-peer Wi-Fi, that is, comment out any code that sets includePeerToPeer. Peer-to-peer Wi-Fi is an added complexity that you don’t want to deal with when getting the basics to work. I’m not aware of any problem that causes the specific symptom you’ve described, but I have some general debugging tips. Error 61 is ECONNREFUSED, which usually means that you’re connecting to the right host but: You have the wrong port. Or no one is listening on that port. So, I recommend that you look at the port numbers in play. For example, if you’re using dynamic port assignment and start and stop the listener repeatedly — a common thing during debugging — then each listener gets its own port. If the client tries to connect based on stale information, you’ll see exactly this failure. Usually Bonjour goes a good job of keeping all of its caches coherent, but this is a distributed system and thus there are certain fundamental challenges in play.

Yeah, that’s a good idea. We’ve filed a request to track it internally [1]. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] I don’t have the bug number yet, but I’ll post it once I get it.

Notarisation is a read-only process, so notarising an app can’t cause it to stop working. Usually problems like this are caused by the hardened runtime. Notarisation requires that you enable the hardened runtime, so folks re-sign their app with that enabled and then it fails. There are two ways you can approach that: Run the Developer ID-signed build before you notarise it. This should hang in the same way. Enable the hardened runtime on your day-to-day development builds. This lets you debug this issue like you would any other hang. Resolving Trusted Execution Problems has a section on debugging hardened runtime issues, namely Resolving Hardened Runtime Incompatibilities. Oh, one more thing. This is problematic: codesign --force --deep --verify --verbose --option runtime --sign Developer ID Application: ORG NAME (ZZZZZZZZZ) path/to/app.app To start, you’re supplying both --verify and --sign, which is never a good idea. For any given invocation of codesign, you should do one or the other. Next, when signing,

[quote='812624021, joel2001k, /thread/812624, /profile/joel2001k'] My certificates expired and I created new ones. [/quote] How? Using the Developer website? Or using Xcode? Because… [quote='812624021, joel2001k, /thread/812624, /profile/joel2001k'] How to fix the missing private key? [/quote] The way that you create a signing certificate determines where your private key ends up. For most certificates it’s just to just revoke stuff and start again, and that’s often the easiest way to resolve issues like this. WARNING That’s not the case for Developer ID certificates. For those, see The Care and Feeding of Developer ID. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='812598021, yccheok, /thread/812598, /profile/yccheok'] Is nonisolated still an appropriate way to ensure code runs on a background thread? [/quote] Yes and no. There are a couple of Swift Evolution proposals that describe this change in detail: SE-0461 Run nonisolated async functions on the caller's actor by default SE-0466 Control default actor isolation inference And, as you’ve noticed, there are Xcode build settings that affect this stuff. So, you have a couple of options: You can tweak your build settings and leave your code as is. Or you can move forward to the new build settings and tweak your code. I generally favour the second option, but I can understand folks preferring the first option, especially when wrangling a large project. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com