Mac users can run unnotarized apps, but in macOS Sequoia there have been some changes that make it slightly more complex. Instead of control-clicking, you'd need to go to System Settings and allow the app to run. From what I know, you need to enroll in the developer program to notarize and distribute your apps (not necessarily via the App Store), but correct me if I'm wrong.

[quote='760976021, rene.lv.cs, /thread/760976, /profile/rene.lv.cs'] My guess I think when the transition to the next screen happens, the reference to some critical information for save password gets deallocated and then some Apple Api tries to show the action sheet but this does not work because some Information is missing. This seems to prevent the userinteraction and some code runs in an endless loop which would explain the memory raising quickly (our production build runs normally between 30 MB and 80 MB Memory). [/quote] I'm not sure, but that sounds pretty plausible, imo. Make sure to file a bug for this and link it here.

For anyone who stumbles upon this thread, the vulnerability has been fixed in macOS 14.6.

Regarding your first question: [quote='761970021, lhj0880, /thread/761970, /profile/lhj0880'] Does the Secure Enclave utilize its own independent memory for storing keys and other sensitive data? [/quote] As described in the Apple Platform Security guide: Although the Secure Enclave doesn’t include storage, it has a mechanism to store information securely on attached storage separate from the NAND flash storage that’s used by the Application Processor and operating system.

I think I figured why this happened, but I believe the UI/UX could be improved. It appears that I did not click the "Done" button and just closed the app, so the key did not get saved. I think it would make sense if this info was automatically saved, especially since there is a "delete" button on the exact same page. I think this behavior may confuse users.

I don't think there's any API for that, but I'm not entirely sure (sso don't count on this). But either way, the sensor fusion algorithms are there to improve it, so I'm not sure if you would get better results from that. and fails in low light conditions Do you think raw depth data would be better than the sensor fusion-processed data?

Hi @victoriapetrova, Sorry for the really late reply, I'm not sure why I didn't notice it. Hopefully you've fixed this by now already, but if not, have you tried running cleaning your build folder? Also, someone said this on the other thread, though I have not verified this myself: I assume you might have stored your mlmodel in a folder called 'Resources.' According to a stack overflow, having a folder named "resources" in the application bundle will cause code sign to fail.

Just checking, have you tried the solutions mentioned on this thread from last year? Also, this recent thread may be useful to you as well.

Well, the rules say this: Your app playground must be built with and run on Swift Playgrounds 4.5 or later, or Xcode 16 or later. You may incorporate the use of Apple Pencil. I think this doesn't stop you from using only up-to-Big Sur SDK features, and developing it in Xcode 13 (the latest one available for Big Sur machines). However, you'll need to find out a way to convert your Xcode project to the Xcode 16 format before submitting it (i.e., perhaps open it in Xcode 16 when you finish developing it, on a device that you can borrow, running macOS Sonoma 14.5 or later). I'm not sure if Xcode 13 had support for App Playgrounds (I think it did), but that needs to be checked. You can create an App Playground by going to File > New > Project > iOS > App Playground.

I just tested this; I've been able to register and I received an email. When successful, the page says "Registered", while also providing a cancellation button and a Webex link. Did you try registering again (and maybe sign out first)?

Thank you for your response, Quinn! [quote='820949022, DTS Engineer, /thread/772116?answerId=820949022#820949022'] I don’t see how that’d even be theoretically possible. [/quote] Perhaps something like signing with a public-private key common to all SEs. But that kind-of-diminishes the randomness of that specific P-256 key. Theoretically, if kept secret, the private key should be secure. [quote='820949022, DTS Engineer, /thread/772116?answerId=820949022#820949022'] I recommend that you explore App Attest. [/quote] That seems to address this, thanks! Since this is for the Swift Student Challenge, I think I won't be able to use it (my "demo" playground wouldn't have a specific app ID, and it also does not have internet access), but I think I can mention this as a further security enhancement in a real-world app.

That's odd. Maybe try to email swiftstudentchallenge@apple.com (found in the Swift Student Challenge Terms and Conditions) and see if they can help...

Somebody asked about PhD students, and the answer was yes.

let’s say if I explain my intention behind using the framework well in my submission video/essay would it still be considered? Quinn’s answer above explains it really well, I personally think it’s a good idea to think about how you want your judges to experience your app in those 3 minutes. I’d just like to add One More Thing™️: if you still have questions about the judging process, maybe it’s also a good idea to ask them in one of the Swift Student Challenge online sessions hosted by Apple. At least, that’s what I would do. In fact, I think I’ll actually do that.

I agree with Claude31. I would add that, even if exploring all features of your app may take more than 3 minutes, an idea would be to have a short onboarding that highlights the main features & what it can do. I intend to do this on my own submission as well, since I believe it contributes to a pleasant user experience. A similar context: think how a user may learn about a newly installed app's general idea & features quickly.