“eskimo”

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

Thank you very much Quinn The Eskimo. Not sure how I will ever be able to repay you back with all the knowledge you shared and all the work you do here. I managed to make a witched Swift <-> Rust bridge and can now use SE within my secure extension... Allowing me to store a secret (encrypted using SE) within a system keychain... Seems to work great... Hopefully I did well.. Learned also a lot about XPC... Sadly cannot make use of Swift Protocols, but I made something similar enough so I can still make use of Raw XPC at least... All working as well... Couldn't have done it without your resources. Will ship it now :) https://github.com/plabayo/rama/pull/875 And all thanks to you. Thank you thank you thank you so much.

[quote='885967022, boncor-cedh, /thread/824287?answerId=885967022#885967022, /profile/boncor-cedh'] It just doesn't work on physical devices for iPhone 16 series and up [/quote] All such devices? Or just a selection? If you have such a device and it shows the problem, what happens if you wipe it and retest? Does it continue to show the problem? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='886051022, MasterYourSelf, /thread/823729?answerId=886051022#886051022, /profile/MasterYourSelf'] Is it possible to downgrade … HTTPS traffic without loosing anything while doing so? [/quote] We’re straying from the Apple side of this equation to the topic of TLS inspection in general. The latter is a complex thing, and not something that I have a lot of expertise in. Rather, I recommend that you consult industry standard sources for advice on best practices. Keep in mind that it’s common for third-party macOS apps to not use Apple’s recommended networking APIs [1], but rather build their own networking stack on top of BSD Sockets. Such apps don’t use Apple’s TLS or HTTP implementations, so I can’t offer any insight into what they’ll do if you try to downgrade the HTTP protocol. So, even if you get things working with URLSession, there’s no guarantee it’ll work with, say, a third-party web browser. So, from the perspective of an NE transparent proxy, what we give you is the ability to: Configure which

[quote='885965022, kunal_a, /thread/817264?answerId=885965022#885965022, /profile/kunal_a'] I've submitted new FB22576068 [/quote] Thanks! I’m gonna ask you to retry on 26.5b4 (25F5068a). This isn’t just a random request. I followed a multi-step path from your bug to a bug from another third-party. We made changes based on that, and they’ve just reported that they can no longer reproduce the problem with the latest beta. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for checking. And, yeah, it was a long shot. Earlier I wrote: [quote='885912022, DTS Engineer, /thread/824361?answerId=885912022#885912022'] you should definitely file a bug about it. [/quote] Did you do that? What was the bug number? Also, I’d like to get more context on why you need to do this? Most folks using URLSession want to use the default proxy configuration because, if they don’t, then their app fails for that fraction of users who can only access the network via a proxy. So I’m curious why it’s important that you disable the proxy, even though it means that your app won’t work for those users. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I wouldn’t put to much stock in the Could not set up internal streams message. It’s very generic. However, the source of that error also logs more details into the system log. If you monitor the com.apple.sharing subsystem when you reproduce the error, what do you see? See Your Friend the System Log for lots of advice on how to use the system log. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

To learn more about this I need to see a full Apple crash report. Please post one, per the advice in Posting a Crash Report. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Are you interacting with Mail via some API? Or are you hitting this while working with the Mail app as a normal user might? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Please post a full Apple crash report, per the advice in Posting a Crash Report. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

stapler needs to be able to access Apple’s CloudKit servers. Clearly that’s failing in this case. My experience is that the CloudKit servers are pretty darned reliable, and most problems like this are caused by networking issues on the client side. However, if you’re automating this then there will inevitably some cases where the root cause is beyond your control. I don’t think there’s a one-size-fits-all approach for this. If I were in your shoes I’d probably do the following: Retry immediately, with the -v flag. And if that still fails, retry after some delay. The immediate retry has a couple of advantages: It’ll resolve any truly transient issues. If it fails, the -v will give you significantly more debug logging to investigate the problem. [quote='824494021, st-gab, /thread/824494, /profile/st-gab'] sometimes we observe exit code 68 in stapling via [/quote] How often is “sometimes”? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ +

Sorry I didn’t reply sooner; somehow I missed this )-: Anyway, I see two parts to this: What’s going on? What can you do about it in the short term? Reading through your report, I consider this to be a bug. I’m not aware of any documented restriction on non-admin users starting a tunnel. Given that, I recommend that you file a bug about this. As part of that: Make sure to enabled additional, per the VPN (Network Extension) for macOS instructions on our Bug Reporting > Profiles and Logs page. Verify that you see the problem on the latest public release of macOS. Check whether this is a regression. You don’t need to go too far here, but it’d be worth checking the latest public release of macOS 15, just in case this is macOS 26 specific. Please post your bug number, just for the record As to what you can do about it in the short term, nothing obvious springs to mind, so lemme start out by clarifying your user experience here. To call the startVPNTunnel() method you need an NEVPNConnection instance, and only t

Hey hey, it’s looks like I already responded to you over on Swift Forums. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don’t know the music playing side of iOS very well, so I can’t help you with that, but I wanted to wade in on this specific point: [quote='824511021, jamalif, /thread/824511, /profile/jamalif'] Background fetch … periodically wakes the app to log what's playing [/quote] While background fetch might help a bit, it’s not a good general solution this problem. I discuss this in some detail in iOS Background Execution Limits Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com