show when run

Thank you for your guidance on focusing on the packaging rather than the certificate! Following your recommendation, I ran systematic tests and identified the exact root cause. Summary The Developer ID Application certificate works perfectly. The Developer ID Installer certificate has a broken chain. Test Results I created an automated diagnostic that tested 5 different combinations: Test Executable Packaging Result 1 Compiled Swift binary ditto (.zip) ✅ Accepted 2 Compiled C binary pkgbuild (.pkg) ❌ Invalid 3 Shell script ditto (.zip) ✅ Accepted 4 Shell script pkgbuild (.pkg) ❌ Invalid 5 Compiled C binary productbuild (.pkg) ❌ Invalid Pattern: Every .zip passes. Every .pkg fails. The Issue When signing with the Installer certificate, this warning appears: Warning: unable to build chain to self-signed root for signer Developer ID Installer: Matthew Seymour Greer (W2AT7M9482) This warning does NOT appear when signing .app bundles with the Application certificate. The Installer certificate can sign locally, but

[quote='869254022, Ionnier, /thread/809951?answerId=869254022#869254022, /profile/Ionnier'] I have to add that the daemon is a NSApplication. [/quote] Hmmm, that’s not good. A launchd daemon runs in the global execution context. Code running in that context cannot safely use GUI frameworks like AppKit. It’s only safe to use GUI frameworks from a GUI user login context. There’s a detailed description of this architecture in TN2083 Daemons and Agents. It’s super old, and there are a few areas where it’s suffering from bit rot, but the big picture stuff is still completely valid. If you break these rules you will run into all sorts of weird problems. Some of them show up immediately, and some of them lurk, waiting to cause you grief as the system evolves. Given that, I strongly recommend that you move away from this design. Coming back to System Extensions framework, it’s intended to be used by a GUI app to load and unload system extensions in response to user actions. Calling

The Supported capabilities article shows what is available for each type of program membership. Push notifications and iCloud capabilities are part of Apple Developer Program membership.

Once you clarify the question please include a code snippet that run and compiles. That way we're able to reproduce the issue.

I see, thank you for pointing this out. So it is not a percentage, but an actual number of pages. Could you expand a little on how to interpret in your previous answer? So, stepping back for a moment, the basic issue here is deciding when should the kernel stop just blindly backing memory. It COULD (and, historically, did) just limit that to total available storage; however, in practice, that just means the machine grinds itself into a useless state without actually failing. So, what macOS does is artificially limit the VM system to ensure that the machine remains always in a functional state. The next question then becomes how to implement that limit. There are lots of places you COULD limit the VM system, but the problem is that the VM system is complicated enough that many obvious metrics don't really work. For example, purgable memory[1] means that simply dirty pages doesn't necessarily work“ - a process could have a very large number of dirty pages, but if they're all purgable, they shouldn't really coun

The following code segments run when building and running the app, or after going home and re-opening the app, but now when quitting the app and re-opening it again. What code can do that? Please be more precise in explaining the use case and what they mean exactly after going home and re-opening: what do you do exactly when you quit: what do you do precisely ? What do you get ? What did you expect ? explain what you get printed for each of the cases. Note: you should have more discriminant print: init() { print(init test) } .onAppear { print(onAppear test) } .onChange(of: scenePhase) { _, newValue in print(onChange (newValue)) }

Thank you for the post and providing detailed information. I am curious about how you are handling Live Activity events in code as you didn’t provide any focused sample. I recommend reviewing our samples to see how it works well to dismiss Live Activities. Handling Live Activities with AlarmKit and ensuring they behave correctly with the Dynamic Island can be tricky, especially concerning state management and user interactions. Make sure that when your app dismisses the Live Activity, it explicitly ends the activity using the APIs. Before dismissing, ensure the Live Activity’s state is updated to reflect that it is no longer active or relevant. Ensure that your logic for starting a Live Activity does not inadvertently create multiple instances. Use unique identifiers and conditions to check if an activity for a particular alarm is already running before starting a new one. As an interim measure, clearly communicate to users the intended method to dismiss Live Activities (using the X button) through U

The hashing logic you showed look correct, the only thing I would double check is all numbers must be 32-bits. The next sample app/server project will be published fairly soon which includes code and tools that will help you work with the Bloom filter bit.

Thank you, this has been helpful! If you don't mind, could you collect one more piece of data for us? Add the following to your ~/.lldbinit: log enable gdb-remote packets --timestamp -f /tmp/log_packets.txt Like before, make sure Xcode is closed. Then, launch the app to experience the slow startup, stop the application, and attach /tmp/log_packets.txt to the bug reported you opened. Please make sure you only do the experiment once, so that the log doesn't contain more than one run. Thank you for assisting us!

There’s a lot to unpack here but I’m still grinding through the holiday backlog so I’m going to focus on the critical bits. First, don’t test stuff like this on your day-to-day development machine, because cached state can confuse you. Rather, run tests like this on a fresh Mac, one that’s never seen your app before. I generally do this in a VM, where I can restore to a fresh snapshot between each test. Second, there is a supported way for a sandboxed app to achieve this goal on modern systems [1], namely, via the CGEventTap mechanism. See CGPreflightListenEventAccess, CGRequestListenEventAccess, and CGEventTapCreate in . This relies on the Input Monitoring privilege, rather than the Accessibility privilege, and that’s available to sandboxed apps. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] macOS 10.15 and later, IIRC.