“eskimo”

It looks like you folks are all trying to use existing keyboards, rather than develop new ones. Given that, the Apple Developer Forums isn’t the right place for you. Our focus here is on folks creating products, mostly software but hardware too, for Apple platforms. If you’re seeing a regression on macOS 27 then I encourage you to file a bug about that using Feedback Assistant. If you’d like to discuss this with other folks who are hitting the same problem, I encourage you to bounce over to Apple Support Community, run by Apple Support. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

So, that error means that Gatekeeper failed to parse, or failed to validate, your notarised ticket. That raises two possibilities The ticket itself is corrupt. Something is causing trust evaluation on the ticket’s certificate chain to fail. I suspect it’s the latter, because the former would require the corruption to occur between the file on disk, which you know to be good, and the contents of that file in memory, and that sort of corruption is not exactly common. I recommend that you do the following: Reproduce the problem, and specifically the steps that generate that Unable to parse ticket log entry. Capture the system log. The easiest option for this is: % sudo log collect --last 5m You could also trigger a sysdiagnose log. That’d make sense if you were filing a bug, and we may get to that, but for the moment a simple snapshot is gonna be easier. Dig into that log and locate the Unable to parse ticket log entry. Look backwards from that for log entries related to trust evaluation. What do you see? Share

I don’t work for App Review and can’t give you definitive answers about their policies. So, focusing on the technical only… [quote='850111021, Rambler, /thread/850111, /profile/Rambler'] Would this method successfully keep the TCP connection alive in the background until the transfer finishes? [/quote] The issue here isn’t the TCP side of things. In general, TCP connections work in the background as long as your app doesn’t get suspended. So, if you’re set up to avoid that, think of something like a music streaming app, then TCP is fine. Rather, the issue here is Wi-Fi. iOS has a complex Wi-Fi lifecycle and it’s not clear how that will affect your product. If you think about a music streaming app, eventually iOS will leave the Wi-Fi network and the app will transition to using WWAN. That’s fine for it, but it’d be a showstopper for your app. I have a bunch of info about the iOS Wi-Fi lifecycle in the various posts hanging off Extra-ordinary Networking. And with that in mind, I have question about this: [quote

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