“eskimo”

Weird. On the machine with this problem, are you running your tests on a non-Apple file system? So, something like FAT32, rather than APFS or HFS Plus? That’s sometimes the cause of weird problems like this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='879668022, Richie_Wu, /thread/818409?answerId=879668022#879668022, /profile/Richie_Wu'] The crash is not on demand. [/quote] Well, that makes it harder. [quote='879668022, Richie_Wu, /thread/818409?answerId=879668022#879668022, /profile/Richie_Wu'] The code I post is very independent [/quote] It’s not as independent as you think. It relies on a huge chunk of shared mutable state, namely the objects allocated on the heap. It’s very common for problems like this to be caused by memory corruption in a completely different subsystem. For example, if one subsystem over-releases an object then some other completely different subsystem can crash in CFRelease. Such crashes are often very hard to reproduce, just like this one. OTOH, hard-to-reproduce crashes like this can also be caused by concurrency problems )- I want to reiterate my previous suggest: Put your code into a small test project and run it with the standard memory debugging tools. If this is a memory management issue within your code or System Co

It sounds like you’re making great progress. [quote='879776022, jblum2000, /thread/817268?answerId=879776022#879776022, /profile/jblum2000'] The surprise here is simply that the app worked [/quote] Such is the nature of the Mac. On iOS the trusted execution system would simply block your code from running in this case. That’s much easier to debug. The Mac, with its legacy stretching back 40+ years, has to be more flexible. That has its pros and cons, and you’ve just hit one of the cons )-: [quote='879776022, jblum2000, /thread/817268?answerId=879776022#879776022, /profile/jblum2000'] once I hear back from the employee running this on Sequoia … [/quote] *cross fingers* Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

lingyun1998 wrote: I have submitted it for review repeatedly for more than 30 times. Submitting the same request over and over again isn’t going to help. In my previous post I suggested you read Q&A with the Mac notary service team, which says: If your app [requires additional analysis], rest assured that we’ve received your file and will complete the analysis, though it may take longer than usual. and: In addition, if you’ve made changes to your app while a prior upload has been delayed, it’s fine to upload a new build. So, it’s fine to submit a new build if you’ve made meaningful changes to your product, but submitting the same build multiple times is pointless. 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

[quote='818622021, mobiusmoonglade, /thread/818622, /profile/mobiusmoonglade'] Is there a documented, MDM-compatible way to inject a specific binary path into the ACL of a private key? [/quote] No. Our direction in this space is the ManagedApp framework. It’s super cool. For a short intro, watch WWDC 2025 Session 203 Get to know the ManagedApp Framework. However, it won’t work for you because it’s not available on the Mac. Also note that its focus is on apps and app extensions, so it’s not clear how it would work for a launchd daemon. If you’d like to see ManagedApp support your use case, I recommend that you file an enhancement request describing your requirements. And if you do that, please post your bug number, just for the record. Beyond that, the only option that I’m aware for provisioning a daemon is via the super obscure mechanism [1]. However, that’s really meant for configuration settings rather than credentials. You could obviously jam a credential into it, but that has significant drawbacks. Anywa

[quote='818623021, JinhongPark, /thread/818623, /profile/JinhongPark'] Is there an official, complete list of all conditions that trigger expirationHandler? [/quote] No. It’s unlikely that we would ever publish such a list because it’s an implementation detail, one that we want to be able to change as the system evolves. [quote='818623021, JinhongPark, /thread/818623, /profile/JinhongPark'] What is the specific time limit before timeout? [/quote] Again, this is something we specifically don’t document. [quote='818623021, JinhongPark, /thread/818623, /profile/JinhongPark'] A way to distinguish the reason is needed. User stop and system expiration require completely different handling. [/quote] I was investigating this when I realised that I’m confused about the context here. You mention BGProcessingTask but those tasks don’t have a UI presence. Are you actually using BGContinuedProcessingTask? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1

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

[quote='818708021, wu_aaron, /thread/818708, /profile/wu_aaron'] breaking expected Wi-Fi Aware data transmission logic. [/quote] Breaking whose logic. Logic within the system frameworks? Or your own app’s logic? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Please post a full Apple crash report for this. See Posting a Crash Report for advice on how to do that. ps I also recommend that you read through Quinn’s Top Ten DevForums Tips, and particularly tip 5. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Right. That’s the Swift compiler crashing, which is something it should never do. I recommend that you file a bug about it. And as this is specific to Apple technologies, you’ll have to use Feedback Assistant rather than the Swift open source bug process. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This is likely fallout from Wi-Fi hardware changes, so the best path forward is for you to file a bug about it. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

macOS does not support unique App ID prefixes, because they’re a legacy feature that was deprecated before the advent of the Mac App Store. The fix here is to migrate your iOS app to use your Team ID as its App ID prefix. For more details, see the App ID prefix section of Code Signing Identifiers Explained. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m glad you’re making progress here. The strings you’re manipulating here are call code signing requirements. For more background on that, see TN3127 Inside Code Signing: Requirements and the various docs it links to. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

It’s quite hard to read your post. Quinn’s Top Ten DevForums Tips has a bunch of suggestions on how to use the forums effectively, and particularly tip 5. Anyway, it sounds like you are trying to notarise your Mac software and your requests are stuck in the In Progress state. If so, the most likely cause is that it’s been held for “in-depth analysis”. I’ve included my standard explanation of that at the end of this email (although I know you’ve seen it before because of the other threads your pinged about this). In the vast majority of cases this state clears by itself, usually within a couple of days. If you’re still stuck in this state after a week, reply back here with the request UUID and creation date of your oldest stuck request. 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 co

premak, I will respond in the your specific thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com