“eskimo”

So, some of the info you posted suggested that something weird might be going on, but it turns out that’s not the case. Rather, the submission just hit the additional analysis path. Pasted in below is my standard spiel about that. 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 additional 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.

AFAICT this wasn’t a case considered in the ManagedApp design, and I encourage you to file a bug (or is it an enhancement request :-) for such support. Please post your bug number, because I want to add my own internal comments to your bug. [quote='848196021, yingha, /thread/848196, /profile/yingha'] is there a supported way for the embedded User Service to access the same managed identity [/quote] Possibly, but it kinda depends on the details of your setup. XPC is unlikely to work here, for reasons I explain in XPC and App-to-App Communication. However, the container app could store the digital identity in a keychain access group that it shares with the login item. IMPORTANT Keychain access groups are a feature of the data protection keychain. If you’re not familiar with that term, review TN3137 On Mac keychain APIs and implementations. This approach certainly has some drawbacks: You’d have to run the main app at least once in order for it to copy the digital identity from ManagedApp to the keychain. And sim

Simulator builds are signed, they’re just signed with an ad hoc [1] signature: % codesign -d -vvv Test848739.app … CodeDirectory v=20400 size=315 flags=0x2(adhoc) … … You are right that Device Hub doesn’t support dragging in an app to install it. I think we already have a bug on file requesting such support (r. 179108532), but if you want to be sure you should feel free to file your own. One alternative is to install the app using simctl: % xcrun simctl install 'iPhone 17' Test848739.app Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] This is different from the Ad Hoc provisioning profile used for Ad Hoc distribution on iOS.

Sadly, I can’t read Chinese, so I’m answering based on a machine translation. There are a couple of issues here: When you pass options to the linker using the OTHER_LDFLAGS build setting, you have to escape them with -Xlinker. Without that the options are are interpreted by the compiler driver, and it doesn’t understand -ld64 (it think you’re trying to a link, using -l, to a library called d64). Additionally, the -ld64 linker option isn’t supported by the linker within Xcode 27. It always assumes ld_prime. I explain the history of this in An Apple Library Primer. So, my advice is that you simple remove -ld64 from that build setting. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

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

Hmmm, that wasn’t the answer I was expecting, but it’s good to know. The general rule here is that the app that invokes Virtualization framework is responsible for any VMs it creates. If the app terminates unexpectedly, the system should clean up its resources, and that includes killing any VMs that it might’ve left running. This is the expected behaviour on all versions of macOS. I’m not aware of any bugs that prevent this, but such bugs are always a possibility. The exact mechanics of this are considered implementation details. That includes the identities of any processes involved and the way that they were launched. For example, I ran a quick test on my Mac (running 26.6.1) and it seems that some of the processes spun up by Virtualization are closely associated with the specific Virtualization client but others are per user. For example, com.apple.Virtualization.VirtualMachine is the former group but com.apple.Virtualization.EventTap is in the latter. However, these processes and their relationships are m

[quote='907201022, JMartell, /thread/848507?answerId=907201022#907201022, /profile/JMartell'] the requirement is to deny all network access [/quote] Have you thoughts about achieving that by enabling App Sandbox? That is, have your top-level process enabled App Sandbox (claim com.apple.security.app-sandbox) and then not enable networking (that is, claim neither com.apple.security.network.client nor com.apple.security.network.server). This might be easier because blocking networking at the NE level requires you to accurately track responsibility, which can be quite challenging. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

langou, m.w.h., Do see these problems if you opt in to the new LAPACK? See m.w.h.’s other thread for more about this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I think I know what’s going on here. When you first log in to the forums [1] it presents a banner suggesting that you opt in to push notifications: If you click the Opt In button then Safari displays its push notification authorisation alert. From then on you’re in control via Safari > Preferences > Websites > Notifications. If you click the X button then forums doesn’t trigger the Safari alert, which is great. However, there’s no good way to force it to show the banner again, or otherwise prompt for permission. We have a bug on file about this limitation (r. 188688883). Note the emphases on good in the paragraph above. There is a not good way to do this (-; namely: Bring up Web Inspector for the forums page. In Web Inspector, switch to the Storage tab. On the left, select Local Storage. Select the apple-developer-hide-banner-en-10 and apple-developer-hashes-en-10 entries. Secondary click and choose the Delete menu item. Reload the page. Please try that out and let me know how you get along. Share an

So we’re not sure what’s going on here, and we’re gonna use your bug (FB24936489) to investigate further. Sadly, I’m unable to try this myself because none of the iPads I have easy access to are running iPadOS 27 (and I can’t update them for various reasons that I won’t discuss here). I’m working with some colleagues to try it out. However, it’s probably not a widespread issue because, if it were, we’d have seen a lot more complaints. So, yeah, a bit of a mystery right now. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='907199022, fix_parrot, /thread/848364?answerId=907199022#907199022, /profile/fix_parrot'] A sysdiagnose from a live reproduction … was attached to FB24933164 [/quote] Much appreciated. [quote='907199022, fix_parrot, /thread/848364?answerId=907199022#907199022, /profile/fix_parrot'] The Info.plist change is already in place on our side - the PIR endpoints are declared under NSPIRConfiguration. [/quote] Neat-o! Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You’re on very shaky compatibility ground here. What not doing anything wrong per se, but it’s quite unusual and thus I’m not surprised you’ve encountered some sharp edges. In your setup, where on disk is ? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This sounds very much like the second issue being discussed on this thread. I’ve made a note to come back to that thread later today. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

What high-level goal are you trying to achieve? Update your Developer ID signing identity because it’s about to expire? I’m asking because you have to be really careful when dealing with Developer ID signing identities because there’s a hard limit on how many you can create. I discuss this, and a lot more in The Care and Feeding of Developer ID. I presume you’re working for Team ID M________9 here. If so, how many Developer ID certificates do you see listed in the portal? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='848762021, marius, /thread/848762, /profile/marius'] I accidentally updated my main workstation from Sequoia to Golden Gate. [/quote] D’oh! [quote='848762021, marius, /thread/848762, /profile/marius'] Unfortunately, the Passwords App does not allow me to see a number of things that are stored in the Keychain Access App [/quote] Right. Passwords is very much focused on… well… passwords [1] and only deals with the data protection keychain. Keychain Access is the way to work with items in the file-based keychain, including secure notes. If you’re unfamiliar with these terms, they’re explained in TN3137 On Mac keychain APIs and implementations. As to why you can’t unlock your login keychain, I don’t have a definitive answer to that. My best guess is that it’s related to the protected entropy file stuff described in the most recent update to TN3137. However, to determine exactly what happened would require a lot more digging. Do you have a backup of this Mac before you upgraded? If so, you could try to rec