eskimo

Right. This is fallout from a known bug (r. 163294564) documented the macOS Tahoe 26.1 Release Notes. My understanding is that this is fixed in the current macOS 26.2 release candidate [1]. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] That’s not documented in the macOS Tahoe 26.2 RC Release Notes but I have a ‘call in’ to fixed that.

On macOS the traditional Unix-y directory APIs — things get getpwent — are implemented within libinfo. That delegates the work to the Open Directory API [1], which in turn defers to opendirectoryd [2]. That supports various back ends via a plug-in mechanism: Historically there was a Directory Service plug-in API. These days that’s been supplanted by Open Directory modules. My understanding is that it is possible to develop a third-party OD module to provide access to custom directory records. However, it’s not for the faint of heart. For example, the documentation for this, known as the Open Directory Plug-in Programming Guide, was only even available in the Documentation Archive and has now been removed in favour of platform SSO. You can, however, still find a copy of The Wayback Machine [3]. But that raises the question of whether you should go down this path at all. Open Directory modules were only ever supported on macOS, so they’ve never been available on iOS or any of its child platforms. In contrast, a

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

[quote='809339021, neha24, /thread/809339, /profile/neha24'] Can we reliably use this API … to detect a device restart? [/quote] No. You could probably make it work a lot of the time, but it definitely won’t be completely reliable. I explain a better option in this post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='868514022, JWWalker, /thread/809171?answerId=868514022#868514022, /profile/JWWalker'] Oh, now I see why I couldn't use iCloud Drive in a 26.1 VM. [/quote] I’m going to address this in the specific thread you created for it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

So… there’s a lot to unpack here. The reason why kSecRevocationRequirePositiveResponse is causing you grief is that: The server’s certificate was issued by Let’s Encrypt. Let’s Encrypt has stopped supporting OCSP. You can learn about that directly from them in “Ending OCSP Support in 2025” [1]. Apple client’s don’t support CRLs directly. Apple clients learn about revocation via a separate path. My understanding is that we don’t document this path in detail. We did talk about it in WWDC 2017 Session 701 Your Apps and Evolving Network Security Standards [2], and I encourage you to watch that (start around 17:40). There have also been third-party folks who’ve dug into this in more detail [3] [4]. Of course, from Apple’s perspective all of these are implementation details, and we encourage folks to rely on APIs instead. Now, the issue here is that the APIs aren’t doing what you want. Before I go there, however, I want to clarify this bit: [quote='808875021, dhoelzl, /thread/808875, /profile/dhoelzl'] On the same

[quote='868298022, bims, /thread/806594?answerId=868298022#868298022, /profile/bims'] Looking at the ips-file I found that it does not show the finding that Xcode show [/quote] Right. Xcode has MTE smarts beyond what the human readable crash report shows. To see the underlying data, open the JSON crash report and search for memoryErrorReport. With some reformatting you get this: memoryErrorReport : { faultAddress:0x0c00000d9de112c0, blamedAllocation: { size:48, allocationTrace:…, deallocationTrace:…, isFreed:true, address:0x0c00000d9de112c0 }, errorType:use-after-free }, The allocationTrace and deallocationTrace backtraces need further massaging. I did a hack-ish job of that and have included the results at the end of this post. I wanted the JSON crash report so that I could run it through some internal tools. I was able to do the first part of that today. I was hoping it might point me at some known bugs. It did, but those were resolved a while bug and thus are unlikely to be the cause of this issue. Unfortu

[quote='868299022, veer_dutta07, /thread/809007?answerId=868299022#868299022, /profile/veer_dutta07'] my understanding is that I do not need to wait. Is that correct? [/quote] I think it’s better to say that “nothing is the system requires you to wait”. You may want to wait for your own reasons, but Network framework doesn’t require it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='868358022, Apple_Fox, /thread/807599?answerId=868358022#868358022, /profile/Apple_Fox'] Is that something that would cause errors for downloading the documents … ? [/quote] It very much depends on the server. Given a URL for something downloadable, some servers allow you to download the resource directly and other require you to jump through hoops. You can see this even on Apple servers. For example, SF Symbols 7 is directly downloadable: https://devimages-cdn.apple.com/design/resources/download/SF-Symbols-7.dmg but Xcode 26.1.1 is not: https://download.developer.apple.com/Developer_Tools/Xcode_26.1.1/Xcode_26.1.1_Universal.xip In the Xcode case, the server redirect the download request to a login page. That login page assumes that the client is a person using a web browser, and it’s very hard to programmatically deal with the required authentication. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='809307021, Jordan, /thread/809307, /profile/Jordan'] I want to keep an eye on the App Store Connect release notes [/quote] The various tabs in Developer > News have RSS feeds, and I think that the one on the Upcoming Requirements is the droid you’re looking for. 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. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’ve definitely seen issues like this in the past, but I coulda sworn that we’d fixed them by now. Clearly that’s not the case )-: [quote='868314022, entbd, /thread/809241?answerId=868314022#868314022, /profile/entbd'] We've also submitted FB21256925 with more information about this. [/quote] Thanks. That’s definitely the best path forward with this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Is your app sandboxed? If so, this is not expected to work. The App Sandbox prevents apps from changing application bindings. You can see evidence for this if you dig into the error. The underlying error, -54, aka permErr, is being rendered as permissions error (on file open) but that’s just an accident of history. Launch Services is using it in the more generic sense of permission denied. And, yeah, please do file a bug against the docs. We should update both the NSWorkspace API documentation and the Review functionality that is incompatible with App Sandbox section of Protecting user data with App Sandbox. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This isn’t something we can help you with here on the forums. See my response here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

nslookup, being a test tool, has its own resolver, meaning it runs UDP flows and TCP connections directly on port 53. ISTR that DNS flows are treated specially by the transparent proxy subsystem. Now where is that… Right. Check out the doc comments in . If you want to intercept DNS flows, use a DNS proxy provider. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com