“eskimo”

To be clear, this whole situation is caused by macOS’s mixed heritage: Traditional Mac OS used colon (:) as the path separator and thus slash (/) was allowed in file names. BSD uses slash as the path separator and thus colon is allowed in file names. Annoyingly, the canonical case where this crops up is dates and times, and neither of them support the most common English representations of both )-: Early versions of Mac OS X had to do something to resolve this conflict, and the current situation is largely where we landed back then. [quote='850144021, endecotp, /thread/850144, /profile/endecotp'] Can someone explain where this happens? [/quote] This is mostly at the UI layer. The most obvious example of that is, as Etresoft mentioned, the Finder, but there are others. For example, the standard save sheet accepts the name a/b, just like the Finder. There are also some APIs that treat colons as path separators, and hence slashes as valid characters, but those are all deprecated. Mostly they are officially depre

There’s a bunch of subtlety here… I presume you’re targeting iOS and one of its child platforms. The story is different for macOS. On iOS, you need an Apple Account to run any code on device. By default that account isn’t a member of any paid team, so you end up using free provisioning (Xcode shows this as a Personal Team). That has significant limitations, as described in Developer > Support > Choosing a Membership. If you want to distribute your app then you need to be a member of a paid team. You can pay for this yourself, resulting in an Individual team. That supports App Store distribution, TestFlight, and Ad Hoc distribution. Alternatively, a company (or other organisation) can set up an Organization team [1] and invite you to join. Those support the same types of distribution as an Individual team. And now your follow-up questions: [quote='908673022, DevTL8228, /thread/850133?answerId=908673022#908673022, /profile/DevTL8228'] Is there a way to sign my app for a longer time [/quote] That is one of

I have a bunch of advice about this error in Resolving errSecInternalComponent errors during code signing, and the related Fixing an untrusted code signing certificate. It looks like you’ve done a many of these tests already, so lemme ask you a question. If you do this, what do you see: % cp /usr/bin/true MyTrue % codesign -s Apple Development: TTT -f MyTrue MyTrue: replacing existing signature replace TTT with the details from your Apple Development signing identity. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’d like to clarify the problem here. My best guess is that it’s one of the following: You are trying to renew your Apple Developer Program membership. If that’s the case, forums isn’t the right place for help with that. Rather, reach out via Apple > Developer > Contact Us. You have an app that lets the user purchase subscriptions. If that’s the case, I recommend that you start a new thread, with all the details, in the App & System Services > StoreKit subtopic. Or if it’s something else, reply here an explanation and I’ll see if I can get you on the right path. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The Apple Developer Forums are primarily focused on helping developers with Apple APIs and tools. AFAICT the issues being discussed in this thread don’t fall into that remit. Given that, you might have better luck discussing this over in the Apple Support Community, run by Apple Support. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

My initial take on this would that it’d be quite straightforward: By the time you’re notified of the guest stopping, the disk image will be free to use. And by that I mean: If the guest stops of its own accord, when you’re notified of that via the guestDidStop(_:) delegate callback. If you force the guest to stop by calling stop(completionHandler:), when you’re notifier via the completion handler being called. But I’m glad I checked because it seems there are some wrinkles. Things should work as I expected on macOS 27 and later. On earlier systems it’s possible for you to receive the notification before the guess is fully done with the disk image. In that case you can avoid running into problems by trying to acquire a advisory lock (using flock) on the disk image. If the guest is still using it, that will wait (or fail if you set LOCK_NB). Oh, and one thing to be careful of. Stopping the guest by calling stop(completionHandler:) is a bit like pulling out the power cable. The guest doesn’t get to shut down cle

Fair enough. Personally I’d like to see us add a new entitlement that enables just es_new_descendants_client. We could then relax it access restrictions, making it either unrestricted and restricted but not managed (and thus available to all developers). We already have an ER on file for that (see here). However, there are both business and technical issues to be resolved with that, so I can’t make any promises. Which brings us back to what you can do right now, and the supported options are the ones we’ve discussed above: ES, App Sandbox, and Virtualization. ps 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. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

OK, so there are three parts to this: Is the code signature valid? Is it code you think it is? That is, checking the code’s identity. Would macOS let it run? That is, will it pass Gatekeeper? Check that the code signature is valid is pretty straightforward application of the codesign tool (with the --verify option) or the SecCode API. Alternatively, you can do the same thing with the SecCode API. Checking the code’s identity requires some policy choices on your part. Consider this: % codesign -d -vvv Python3.framework … Identifier=com.apple.python3 … CDHash=7ba32e264b885ea828d2175063de50fb97732acd … Authority=Software Signing Authority=Apple Code Signing Certification Authority Authority=Apple Root CA … TeamIdentifier=59GAB85EFG … There are various strategies you can apply: You can check for a specific instance of the code. You usually do that with a cdhash value. TN3126 Inside Code Signing: Hashes explains that concept in more detail. You can check the Team ID and code signing identity. This is the classic w

[quote='908312022, marucello, /thread/849002?answerId=908312022#908312022, /profile/marucello'] I have not been able to reproduce the delayed invalidation again since updating the host to macOS 26.7.1 (25G241). [/quote] OK. In that case I think we should draw a line under this. Lemme know if you see anything like this again [1]. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Keeping in mind the old saying that “Bugs that mysteriously disappear can just as easily mysteriously reappear.” |-:

Has anyone see this on a machine running xyzOS 27? The above-mentioned bug (r. 171639997) is reported as fixed in xyzOS 27, so I’m hoping that the answer here is “No” (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hmmmm, that wasn’t the answer I was expecting. It seems like you have two goals here: Check the app before you submit it to App Store Connect. If App Store Complains about an app you submitted, quickly diagnose the issue. Is that right? If so, the best tool for the pre-submission check is indeed the Xcode organiser’s Validate App option. You can also automate this using the --validate-app subcommand in altool. The nice thing about Validate App is that it runs a mini version of the same validation that’s done internally by App Store Connect [1], and thus it’s a solid predictor of success or failure. The best path forward for your second point is much less clear cut. I probably wouldn’t drop down to the SecCode API for this. You can achieve much the same results using the codesign tool, and that’s an easier and more flexible option for this sort of work. As a basic check I’d do this: % codesign -v --deep -strict -vvv /path/to/your.app You can also do this: % codesign -d --extract-certificates /path/to/your.app

Unfortunately I can’t help you with this, for reasons that I’m not going to discuss. Sorry. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m not sure what you’re actually asking here, so rather than guess I’m gonna drop in the core code of one of the test frameworks that I created. This parses DNS messages out of a TCP stream, where is DNS message starts with a two-byte length in network byte order. Sadly, I never created a line-based framer, and I’m unlikely to ever do that because these days I typically do this work outside of the networking stack, relying on Swift async functions for the I/O side of things. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com func handleInput(framer instance: NWProtocolFramer.Instance) -> Int { while true { var payloadLength: Int = 0 var success = instance.parseInput(minimumIncompleteLength: 2, maximumLength: 2) { buffer, _ in guard let buffer = buffer, buffer.count >= 2 else { return 0 } let length16 = buffer.reduce(0) { soFar, next in (soFar << 8) | UInt16(next) } payloadLength = Int(length16) // We return 0 here

Creating role accounts on macOS has always been a tricky issue. A key problem is that there are multiple layers of abstraction and many of the underlying layers have supported APIs. For example, the Open Directory framework is a supported way to read and write user records. However, that’s only part of the story. Using these APIs to achieve a high-level goal, like creating a role account, is tricky, to the point where I’m not sure it’s something you’d want to attempt. You might find that things work today but fail on older, or worse yet newer, systems. Given that, what your really need is a high-level ‘create a role account’ API. Sadly, we don’t have that. The best we have is the sysadminctl tool and its -roleAccount option. That’s not ideal — command-line tools aren’t really APIs — but it’s probably your best option as things currently stand. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

AFAIK Apple hasn’t announced any plans in this space and, given that, it’s not something we can discuss here on the forums. See tip 3 is Quinn’s Top Ten DevForums Tips for more my general thoughts about that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com