“eskimo”

[quote='911175022, Pokpong, /thread/852783?answerId=911175022#911175022, /profile/Pokpong'] I do not believe there is a public iOS API for shaping or rate-limiting traffic forwarded by Personal Hotspot. [/quote] Right. In fact, Personal Hotspot has no API at all. It’s a user-facing feature only. I’ve been warning folks about this for almost a decade. IMPORTANT BSD interface names are not considered API on our platforms (something I talk about in the various posts linked to from Extra-ordinary Networking). Don’t build a product that assumes that tries to identify a Personal Hotspot interface based on its name. Those details have changed in the past and may well change again in the future. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

I don’t think you’ll find a way around this limit. However, I think it’s worth trying com.apple.developer.kernel.increased-memory-limit before giving up on this completely. You’ll need to add it to the appex, not the app. And hey, it seems like we’ve fixed all the bugs that made it hard to use (-: Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

[quote='852828021, RFAGermany, /thread/852828, /profile/RFAGermany'] the script needs to check that it is looking at the correct mounted backup volume. [/quote] What sort of script are we talking about here? This matters because some scripting languages give you ready access to native APIs and some don’t, and the best answer for at least some of question question involves native APIs. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

I need to clarify what you mean by “restrictive sandbox profiles”. If you’re talking about a custom sandbox profile based on SBPL, we can’t help you because that’s not something we support. See my responses on this thread for more details. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

The answer here is going to depend on exactly what you mean by export: If you want to guarantee that the key bits never show up in your process, and thus it’s impossible for your app to accidentally export them, then there’s no way to achieve this goal [1]. The only way to meet that exportability constraint is with an SE-protected key, and the SE has no RSA support. If you’re OK with the key bits being present in your process then you can use a standard data protection keychain item. If you use your App ID as its keychain access group, which is the default, then only your app can access it (because using a keychain access group is authorised by your provisioning profile and your App ID is registered to your team). Of course, that second point assumes that SIP is enable. If SIP is disabled then all bets are off because some other process can reach into your address space and grab the key bits from there. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo

I don’t really understand your question here. The host app controls which resources get shared with the guest VM. For example, if your host app configures the VM with a boot disk image and no shared directory, the guest VM shouldn’t be able to access anything on the host file system other than the contents of the boot disk image. Now, this is a complex system and that means that there’s always gonna be a chance that some bug might undermine that policy, but if you find something like that then that’d be Apple’s bug to fix. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

The only documentation you’re gonna find about this is in man pages, and I believe you’ve found the relevant bits in the launchd.plist man page. If you need more constraints to be documentation, I encourage you to file an ER against that man page. As to what will happen in practice: I suspect that F will be killed via a SIGTERM, with no backoff to SIGKILL. This is a best effort operation because, as we discussed in your other thread [1], the process can avoid being killed simply by changing its process group. It doesn’t matter how the job stopped. ExitTimeOut isn’t relevant to F. There are no real-time guarantees. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com [1] Well, I’m presuming that’s use operating under a different account. It seems unlikely that multiple folks would be independently asking about the same dusty corner of macOS in the same week.

Glad to hear that you’re making progress. [quote='910871022, benchman_acc, /thread/850182?answerId=910871022#910871022, /profile/benchman_acc'] Is it intended that syspolicyd refuses a ticket whose signing chain is trusted through a trust-settings override (Proceed) instead of the system anchor? [/quote] Yes [1]. In general, you shouldn’t be monkeying with trust settings for system certificates, and doing so can cause all sorts of weird problems. [quote='910871022, benchman_acc, /thread/850182?answerId=910871022#910871022, /profile/benchman_acc'] 2. Could anything other than admin or user trust settings make this chain evaluate to Proceed … ? [/quote] Not that I can think of. In my experience a .proceed trust result is always generated by trust settings. [quote='910871022, benchman_acc, /thread/850182?answerId=910871022#910871022, /profile/benchman_acc'] 3. If the behaviour is intended, Unable to parse ticket with a -1 error makes it hard to diagnose. Would a bug report asking for a clearer message be useful?

[quote='910925022, MineaVoiceDev, /thread/851802?answerId=910925022#910925022, /profile/MineaVoiceDev'] What simple approach … would you recommend for these two issues? [/quote] If I were setting this up I’d lean into SSH. If you enable SSH on the VM, you can use it to: Copy files to and from the VM using scp. Start and stop work on the VM. That last one is a bit tricky depending on the nature of the work. When you log in to a Mac via SSH, your shell runs in a non-GUI login context. If the code you’re trying to test expects a GUI login context, you’re testing an app say, then you can’t run it directly. One way around this is to: Enable autologin on the VM, so that it logs in as a GUI user on boot. Configure the system so it starts a launchd agent in every GUI login context. From the SSH session, communicate with your launchd agent to have it start and stop your work. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

[quote='910864022, hlmdprm, /thread/852321?answerId=910864022#910864022, /profile/hlmdprm'] Our team has verified this behavior across various iPhone models and iOS versions. [/quote] OK. Unfortunately, I don’t think there’s much that I can do to help you out here. The Apple Developer Forums are primarily focused on helping folks to use Apple APIs and tools to build products for Apple platforms. We’re not really set up to deal with on-the-wire interoperability issues like this one. My general advice for folks in your situation is to file a bug about the issue you’re seeing. That way our network engineering team can investigating. For detailed advice on how to file such a bug in Filing a Wi-Fi Bug Report. Please post your bug number, just for the record. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

Thanks for the confirmation. I can understand how NE gets itself into this state, but the final behaviour is less than helpful so I think a bug report is called for. So, thanks for filing FB25176278. Having said that, I’m not sure if there’s an easy way to fix this. When you set enforceRoutes the system actually catches the flow at the socket level, rather than down at the IP level. If the tunnel gets reconfigured then there’s gonna be a window where things are in an inconsistent state and hence ‘poking’ the flow at that time will result in the disconnect. Hmmmm, I guess we could do some sort of atomic NECP update… but… yeah, that’s just idle speculation on my part. The NE team needs to look at this properly, and that’s what your bug report is for. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

[quote='852737021, veer_dutta07, /thread/852737, /profile/veer_dutta07'] Is .failed guaranteed to be delivered at most once during the lifetime of an instance? [/quote] Yes. [quote='852737021, veer_dutta07, /thread/852737, /profile/veer_dutta07'] If the object enters .failed, can I call cancel() on that same instance? [/quote] Yes. [quote='852737021, veer_dutta07, /thread/852737, /profile/veer_dutta07'] If so, will the state-update handler subsequently receive .cancelled? [/quote] Yes. [quote='852737021, veer_dutta07, /thread/852737, /profile/veer_dutta07'] Is .cancelled guaranteed to be delivered at most once per instance, even if cancel() is called multiple times? [/quote] Yes. [quote='852737021, veer_dutta07, /thread/852737, /profile/veer_dutta07'] If the object is in the .waiting state and I call cancel(), causing it to transition to .cancelled, is it guaranteed that .failed will not subsequently be delivered for that instance? [/quote] Yes, but you have to be careful here. Calls to your state update hand

See here. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

I’d like to get a better understanding of how reproducible this is. In the other thread you referenced, the developer only saw it during VPP installs. Is that the case for you too? Or are you seeing it in other circumstances? Specifically, do you see it with developer builds? What about with TestFlight installations? Also, you specifically call out watchOS 26.2 and 26.3. Those are old, even by watchOS 26 standards. Are you seeing it on later versions of watchOS 26? Or on watchOS 27? Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com

Just to be clear, the bug you filed was FB21140246, right? I didn’t see your thread when it first went by — I was probably out of the office at the time — but another developer has reported what looks like the same issue in a new thread. Share and Enjoy—Quinn “The Eskimo!” @ Developer Technical Support @ Applelet myEmail = eskimo + 1 + @ + apple.com