Apple Maps Guides

I can’t answer why questions. See tip 3 in Quinn’s Top Ten DevForums Tips. My advice here is that you file an enhancement request for a better screen saver API, one based on app extension technology. While we’ve seen similar requests many times before, a fresh bug report will allow you to express your needs in your own terms, and allow Apple engineering to gauge the level of demand. 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

Something like this perhaps: % security find-certificate -c Apple Development: Quinn Quinn (7XFU7D52S4) -p > cert.pem % certtool d cert.pem … Subject Name : Other name : UT376R4K29 Common Name : Apple Development: Quinn Quinn (7XFU7D52S4) OrgUnit : SKMME9E2Y8 Org : Quinn Quinn Country : US … Unfortunately it relies on the name. If you’re worried about duplicates, you can pass -a, which results in a PEM with multiple certificates. certtool won’t deal with that properly, but now that you’re in PEM format you can use openssl. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I am unsure if there has been any progress in this area. But I needed to resolve a recent Tahoe panic, so chatgpt cobbled together this: https://gist.github.com/lundman/54e633a850e7623aae5adab38a39f464 If we are allowed to share? Either way, output was: ./symbolicate_panic.py -p ~/ZFS.2.3.1rc1.kernel.panic.-.Tahoe.M4.Pro.Mac.Mini.txt -k /Library/Extensions/zfs.kext/Contents/MacOS/zfs --kernel --kdk-nearest --accept-mismatch === KEXT mapping === bundle: org.openzfsonosx.zfs arch: arm64e base@: 0xfffffe004400d840 file __TEXT vmaddr: 0x0 file __TEXT_EXEC vmaddr: 0x70000 delta=0x70000 chosen TEXT_LOAD: 0xfffffe0043f9d840 === Kernel mapping (via KDK) === checking for KDK build 25A354 ... nearest: /Library/Developer/KDKs/KDK_26.0_25A353.kdk build: 25A354 SoC: t6041 kernel: /Library/Developer/KDKs/KDK_26.0_25A353.kdk/System/Library/Kernels/kernel.release.t6041 panic Kernel UUID: E67CAF31-8F84-389C-BB27-7FAEC762FA14 KDK Kernel UUID: E67CAF31-8F84-389C-BB27-7FAEC762FA14 file __TEXT vmaddr: 0xfffffe00

What do you mean by “legitimate”? What are you hoping to achieve by poking around in the internals of WebKit? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I have a few resources to share with you: Placing content in a bundle explains how bundles should be structured. Creating distribution-signed code for macOS and Packaging Mac software for distribution explain how to manually sign code. Embedding nonstandard code structures in a bundle offers advice on how to deal with non-Apple code structures, like the ones used by Python. You have a couple of choices here: You can strictly follow the rules in Placing content in a bundle, which is a bunch of extra work right now but will likely work better in the long term. You can bend those rules by simply signing your code as it’s currently structured. Based on the script you included, it looks like you’re attempting the second approach. It’s likely you’ll be able to make that work, but that script will need significant enhancement. For example, Creating distribution-signed code for macOS explains that you need to sign code from the inside out from a dependency perspective, and your script is doing it from a file

Developer ID signing identities are precious. If you have one, you can sign code that’s indistinguishable from legitimate code created by your organisation. Given that, Apple has additional limits on such signing identities. I talk about that in gory detail in The Care and Feeding of Developer ID. One of those limits is that only an Account Holder can manually create Developer ID certificates. I suspect you’re not the Account Holder for your team, and that’s why you’re seeing this problem. You should talk to your Account Holder and discuss how to proceed. IMPORTANT Make sure you read the above-mentioned post because it’s easy to paint yourself into a corner with Developer ID. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

It’s hard to offer specific insight into this because I don’t maintain expertise in third-party tooling. I usually recommend that folks in your situation ask for help via the support channel for the tools they’re using. However, I can offer some general advice. My experience is that, when an app fails to launch like this, without generating a crash report, it’s usually because the third-party runtime has detected a problem and called exit. That’s fine during debugging, because you can get a breakpoint on exit and look at the backtrace. However, it’s problematic when the app is Distribution signed, because you can’t attach with the debugger. My usual advice here is to use Xcode to export a Development signed app from the same Xcode archive that you submitted to TestFlight. See Isolating Code Signing Problems from Build Problems. I’m not sure how well that’ll map to your third-party tooling. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 +

I also find that surprising. I’m gonna do some research and get back to you about this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='802495021, ssmith_c, /thread/802495, /profile/ssmith_c'] Is this a managed entitlement? [/quote] Yes. It’s certainly restricted, in the sense that it must be authorised by a profile. TN3125 Inside Code Signing: Provisioning Profiles talks about that. And given that it’s not listed under Capabilities in the App ID editor on the Developer website, you can’t assign it to to yourself, so it’s not simply restricted but also managed. Normally we have some sort of application form for managed capabilities, but I’m unable to track that down here. I’ve seen requests for this go by in the past, and I think I know the right process, but this is definitely more of a Kevin thing than a me thing. I’m gonna run this past him before I say anything definitive. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='860350022, Michael8619, /thread/802183?answerId=860350022#860350022, /profile/Michael8619'] after 3.5 days of waiting. [/quote] Blergh. Lemme know if you see such a long delay in your subsequent notarisation requests. Normally I see follow-up requests go through quickly, but that’s after a successful notarisation. I’m curious to see if your unsuccessful notarisation still allowed the system to ‘learn’. [quote='860350022, Michael8619, /thread/802183?answerId=860350022#860350022, /profile/Michael8619'] I must have missed some files in mine as I just received invalid on all my files [/quote] OK. If you’re unable to resolve this, I’d be happy to take a look. My only ask is that you start a new thread with the details, so we can leave this thread focused on the “in-depth analysis” issue. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

See my reply in the other thread that you waded in to. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Please don’t do this. I explain why it’s a bad idea in your other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Please please please don’t do this. The crash you’re seeing is caused by a memory management problem. The most common cause of such problems is an over-release bug. That is, some code has over-released an NSDate object, that same memory has been re-used as an NSString object, and then some other code has using the original object pointer thinking it’s date when it’s now actually a string, and hence this exception. You’re ‘fixing’ the crash by using an Objective-C category to add date methods to string objects, and string objects have no business having those methods. This is the wrong approach. Rather, you need to find the underlying memory management bug and resolve that. My advice is that your run your app under the standard memory debugging tools. Specifically, Zombies is the tool of choice when debugging over-release problems. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com