missing package product

Approach 1 is deeply unsupported. Don’t do that. Approach 2 is the one I recommend. Indeed, as things currently stand it’s the only way to ship a daemon that uses restricted entitlements. See Signing a daemon with a restricted entitlement. IMPORTANT Apps and daemons are different things. In some situations it makes sense to bundle a daemon in an app-like wrapper, but that doesn’t make it an app. You cannot, for example, call AppKit from a daemon, regardless of how it’s packaged. An variant of approach 2 is to install your daemon using SMAppService. You still have to do that MyDaemon/Content/MacOS/MyDaemon dance, but you can use BundleProgram and do it relative to the root of the containing app’s bundle. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I am looking more closely at the ARHumanBodyManager Skript and the following event: public event Action humanBodiesChanged; The way I figure is - after a body is found the script should stop looking for new bodies. Only when the body is lost, should the script search for new ones.

@aababc For that issue, please reference my initial reply. You should be calling production first and falling back to sandbox if you receive the noted error.

We want to give the user the ability to clear document and data. We first try to calculate the size by summing the size of all the files in that directory FileManager.default.urls(for: .cachesDirectory, in: .userDomainMask).first. First off, I have two strong recommendations when it comes to calculating/displaying file/directory sizes to the user: Whenever possible, try to avoid doing so. If you must show sizes to the users, design you interface such that direct comparisons between the systems size and your size are difficult/impossible. For example, showing an approximate value (~500 MB) instead of a specific one (531.25 MB) or presenting the sizes of specific files without providing a total size. The issues here are that, in practice: -Calculating the size of a directory is much trickier than it sounds. For example, simply summing all file sizes will double count symbolic links and clone files, both of which are difficult to properly account for. -File summations don't account for metadata overhead, which m

@darkpaw the question is when is it called, but how many times it is called. both task and onAppear are called every time the view appears, like for example when the user navigated to another tab of the app and then comes back to it. viewDidLoad on the other hand was called only once. It can be achieved with a modifier holding a boolean to flag if the action ran already. But I am sure that the fact viewDidLoad is missing in SwiftUI is by design. And I would love to understand why is that.

Your question is about product performance. Sio that's not a question for the developers forum. You'd better ask on Apple Support Community https://discussions.apple.com/welcome or file a bug report.

If the app is built correctly, including the NSE in the build, archiving the main app should also properly archive the extension. So, what you would want to check first would be that your build settings are such that, the release builds are also including the NSE in the built app. You can check the app's Build Settings and Build Phases, and also the build logs to make sure that something is not failing while compiling and embedding the extension. That said, failing to modify the notification does not automatically mean that the extension has not been archived. There could be a number of reasons, like: the notification payload for the production build is missing the mutable-content entry the NSE is crashing at launch, or failing while processing the notification the code path in the NSE is failing to call the completion handler the NSE is taking more than the allowed memory or time limits (24MB and 30 seconds, as of this writing) and eventually being terminated before it can finish So, if you