“eskimo”

I wouldn’t characterise this as a bug. If you set the atomic flag then the file wrapper will either work or, if something goes wrong, leave the destination unchanged. The system has to jump through extra hoops to provide this guarantee. OTOH, if you don’t set that flag then you’re telling the system that you don’t care about the state destination in the error case. The system is free to choose whatever writing techniques that it finds convenient. This is a valid choice if, for example, you’re writing to a temporary file, but it doesn’t look like that’s the case for you. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for filing FB22476701. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m gonna start you out with SecItem: Fundamentals. It explains how you should think about the keychain. Once you internalise that, a lot of its behaviour makes sense. As to what’s going on here, it’s hard to say without more context. My first question is: What platform are you on? This matters because, if you’re on the Mac, the keychain has a lot of additional complexity. TN3137 On Mac keychain APIs and implementations explains the details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Sadly, I can’t read Chinese, so I’m answering based on a machine translation. My understanding is that: The 511 limit is a default. The hard limit is 999. You can control this via sysctl with the kern.tty.ptmx_max selector, for example: % sudo sysctl kern.tty.ptmx_max=800 kern.tty.ptmx_max: 511 -> 800 Please try that out and let me know how you get along. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

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

[quote='884102022, StonedStudio, /thread/820986?answerId=884102022#884102022, /profile/StonedStudio'] I've seen BackgroundAssets also Simi-reguarly not install firstInstallation asset packs as well [/quote] In that the issue you’re talking about in this thread? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='823571022, DTS Engineer, /thread/773605?answerId=823571022#823571022'] The good news is that TSPL is open source, so you can get involved. [/quote] It looks like someone took that to to heart because, thanks to a volunteer effort [1], there’s a new book version of TSPL. See this thread on Swift Forums. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] As noted at the top of the thread: This project is not published by, endorsed by, or affiliated with Apple Inc. or the Swift.org open source project.

[quote='881054022, DTS Engineer, /thread/820017?answerId=881054022#881054022'] The [book version] of The Swift Programming Language (TSPL) you’re working from … is very old. [/quote] FYI, there’s a new book version of TSPL, thanks to a volunteer effort [1]. See this thread on Swift Forums. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] As noted at the top of the thread: This project is not published by, endorsed by, or affiliated with Apple Inc. or the Swift.org open source project.

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. does it take a long time to get approved? I’m not involved in the approval process, so I can’t give you any concrete numbers. But based on what I’ve seen reported by other folks in the forums, it seems to be more like weeks than days. I cannot find a way to see the status of my request. Yeah, that’s my understanding as well )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='883774022, oleksandr91, /thread/821894?answerId=883774022#883774022, /profile/oleksandr91'] We’re using SecKeychainChangePassword to change the keychain password. [/quote] To be clear, that’s not API, and thus not supported by DTS. There isn’t a good way to change the password for a file-based keychain. I’ve seen folks do it by spawning the security tool with the set-keychain-password command, but that’s problematic on at least two levels: Using command-line tools as API is usually a bad option. Especially in a case like this, where the tool was clearly designed to be used by a user. You either have to pass in the passwords as arguments or do the pseudo-TTY dance, neither of which is ideal. I discussed your issue with some folks internally and we couldn’t come up with any good suggestions for you. What you really want is an API to change the user’s password in all relevant contexts (OD, login keychain, data protection keychain, FileVault, and probably more than I’m forgetting). Such an API does not ex

i [want] to determine ip address of guest os without any cooperation from guest. Thanks for confirming that. This is a fundamentally tricky problem to solve, at least in the general case. The guest chooses how it’s going to assign IP addresses to an interface, and the host has no direct control over that choice. However, there may be an indirect way to do this: Virtualization framework lets you create a network that’s backed by a vmnet network (VZVmnetNetworkDeviceAttachment). vmnet framework lets your configure a network with a specific DHCP mapping (vmnet_network_configuration_add_dhcp_reservation). There are some significant caveats: The guest must default to using DHCP. You can’t support bridged mode (VMNET_BRIDGED_MODE), because in bridged mode the guest isn’t talking to the vmnet DHCP server. This is all new in macOS 26. But otherwise I think it’ll work. So please try it out and let me know how you get along. ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums

Lemme start you out with Understanding NEHotspotConfigurationErrorInternal. 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

I think you should file a bug about this. It’s hard to be sure exactly what’s going on, but your description certainly sounds like there’s an issue on the Apple side of the fence. Please post your bug number, just for the record. I have some general advice about filing Wi-Fi bug reports in… ah… Filing a Wi-Fi Bug Report. In this case, however, I recommend that you also install the Accessory Setup Kit for iOS/iPadOS debug profile, available from our Bug Reporting > Profiles and Logs page. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='822120021, AntonPastrevich, /thread/822120, /profile/AntonPastrevich'] We've filed FB22448572 for this [/quote] Thanks. That’s the best path forward for this. [quote='822120021, AntonPastrevich, /thread/822120, /profile/AntonPastrevich'] Is there a known issue with securityd’s keychain authentication after 26.4? [/quote] Well there is now that you’ve filed a bug about it (-: Seriously though, as I mentioned on that other thread you found, macOS 26.4 has significant changes to how we unlock the login keychain. In that thread, the developer is doing something unusual, and it’s not clear what the right path forward is. But in your case my understanding is that you’re doing something pedestrian — accessing a keychain item from early in your app’s lifecycle — and that makes the path forward clear: File a bug so that the keychain team can investigate. Which is what you’ve done (-: [quote='822120021, AntonPastrevich, /thread/822120, /profile/AntonPastrevich'] Would migrating to the data protection keychain …