“eskimo”

I general, I recommend that you enable automatic code signing in Xcode and it’ll take care of all this for you. However, let’s assume you want to take the hard road, in which case the answer is… Probably all three. That is, each app-like think has its own App ID and thus needs its own provisioning profile. That’s certainly true on iOS and its child platforms. On macOS an app-like thing only needs a provisioning profile if it uses restricted entitlements, as defined in TN3125 Inside Code Signing: Provisioning Profiles. So, you might be able to skip this step in your Finder extension and you helper. For the app itself, it always needs restricted entitlements if you’re going to use TestFlight, and you should always use TestFlight (-: See TestFlight, Provisioning Profiles, and the Mac App Store. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Right. If an App ID has been seen by App Store Connect, you can’t remove it. See Developer Account Help > Identifiers > Delete an App ID. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I presume you’re talking about the puzzle piece and gear icons in the screenshot you included. If so, they don’t really mean anything. Having said that, the fact that you have multiple is both interesting and confusing. I believe you have different capabilities that select different USB vendor ID combinations. You might be able to get some insight by clicking the little info (i) button, as shown in Finding a Capability’s Distribution Restrictions. If that’s not sufficient detail — and I suspect that’s the case — then you’ll need to apply the capability to a test App ID and see what entitlements end up a profile generated from that App ID. 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 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. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks Eskimo, I filed feedback through the Feedback Assistant, the ticket number is FB22953329. What might be more helpful than posting the link to cppreference's compiler support page, it to post a snapshot of what was on the page at the time of writing this. That can be found here: https://web.archive.org/web/20260605081835/https://en.cppreference.com/cpp/compiler_support Thanks for the help, Sean

For URL filter, there’s one specific gotcha I’m aware of, namely, the trailing URL problem. If that’s not it, I have a few suggestions that I’ll come back to in a sec. But first: [quote='890176022, RomainDropB, /thread/827228?answerId=890176022#890176022, /profile/RomainDropB'] does the entitlement require an additional approval step even for development testing? [/quote] No. There’s no approval process required for development. Any member of any paid development team should be able to play around with this stuff at their desk. So, anyway, suggestions: Review the above-mentioned thread, and other threads here on the forums related to URL filter, because there’s a bunch of folks who’ve been down this path and have shared their experience here. Make sure that both your app and appex are signed with the com.apple.developer.networking.networkextension entitlement, with an array value containing url-filter-provider. Look in the system log for log entries related to this failure. The configurationInvalid error you’

[quote='829401021, mobydoyle, /thread/829401, /profile/mobydoyle'] Apple developer forums won't let me share a link to this page [/quote] It will, but you have to do it in the clear. See tip 14 in Quinn’s Top Ten DevForums Tips. [quote='829401021, mobydoyle, /thread/829401, /profile/mobydoyle'] Is the planned support for Xcode/libc++ published anywhere? [/quote] Apple generally don’t discuss its future plans [1], and AFAIK we haven’t said anything about this. My advice is to check with what’s released at WWDC on Monday [2]. And if things haven’t changed, you should file an enhancement request for the features you’re looking for. If you do file an ER, please post the bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] See tip 3 in Quinn’s Top Ten DevForums Tips (-: [2] I’m not making any promises here. I genuinely have no idea whether this issue will be addressed there.

[quote='829273021, steve-songcage, /thread/829273, /profile/steve-songcage'] It has now been more than 7 days. [/quote] Well, that’s not good. I’ll do some research and get back to you. Note It’s WWDC next week, so it might take me a few days to get traction on this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

My advice here is that try to replicate the steps that the user took. That is: Ask them what OS version their old Mac was running. Set that up in a VM. And then set up another VM with 26.5.1. Start the old Mac VM. Install your app with its login item. Start the new Mac VM. Migrate the state from the old one. See how you app behaves. This will either replicate the problem or it won’t. If it does, you can start investigating potential workarounds. If it doesn’t, there something about this user’s environment that’s triggering the issue, and at that point you have to decide how much user support you want to do. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Problems like this are usually caused by a malformed bundle, either in the bundle structure itself or in the Info.plist. For the bundle structure we have good docs: Placing content in a bundle. Review your bundle structure to ensure that it follows those rules. For the Info.plist things are trickier. While there’s good documentation about each Info.plist key, there isn’t a good reference for exactly what keys are expected in each product type. My standard approach to problems like this is: In Xcode, create a test project with the same name and bundle ID. Build it. Move it to the Applications folder. Check that System Information shows the right result. You can now diff the Info.plist that Xcode created with the Info.plist that you have, apply any relevant changes, and retest. Let us know how you get along. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for filing FB22905515. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for those crash reports. All of them show signs of a third-party crash reporter — actually, a couple of different third-party crash reports — which is not great. The problem with third-party crash reporters is that they often fail to preserve the state of the Apple crash report, which makes it hard to trust what you see )-: I have a much more detailed explanation of this in Implementing Your Own Crash Reporter. Having said that, this set of crash reports certainly suggest you’re running out of virtual address space. Lemme go through each one. For FMOD.crash, consider this in the crash threading backtrace: 2 UnityFramework … MemoryManager::OutOfMemoryError(unsigned long, unsigned long, MemLabelId, char const*, int) + 640 (MemoryManager.cpp:1504) 3 UnityFramework … MemoryManager::Allocate(unsigned long, unsigned long, MemLabelId, AllocateOptions, char const*, int) + 384 (MemoryManager.cpp:1743) It’s hard to be sure what’s going on here without knowing what MemoryManager::Allocate(…) does, but it’s a reas

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth 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. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

So, error 120 in the PKInstallErrorDomain domains basically means ‘something went wrong trying to install a file’. The error 1 is EPERM, obviously. The _relinkFile bit is interesting. You can think of it a bit like a rename system call. It’s responsible for actually putting the file where it needs to be. So, it’s likely that this failure is happening because the installer went to move a file into position and got a EPERM back from the file system. If a machine encounters this problem, does it happen every time? Or if, say, you retry the install, does it then works? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi Quinn “The Eskimo!”, Thanks for checking in with the VZ team and letting me know about general advice. To be clear I wasn't complaining or suspecting the VZ framework or think it has any bug, but I was simply asking for tips and tricks to investigate and instrument when the specific VZ actions are called (I did ask for any undocumented tricks which you've advised are not available implicitly). ... I went ahead to instrument and add debug logging. I found the save/restore operations were done at measly 30-40MB/s, my app architecture is such that the VM runner can run as a background app which may/may not have a GUI. On further debbuging I found a solution by setting NSAppSleepDisabled=true in the VM runner app's plist. I also wrapped the restoreMachineStateFrom and saveMachineStateTo code in a wrapper that starts a ProcessInfo acitivity with flags like .userInitiated, .latencyCritical, and .idleSystemSleepDisabled and raises the disk I/O policy (within the critical code) to IOPOL_IMPORTANT. This re