To clarify, I think completionHandler on runAnimationGroup should specify that the closure is sendable. It seems like that would fix the problem. But regardless, the above code will work and is backwards compatible.

Try this instead: Task { await withCheckedContinuation { continuation in NSAnimationContext.runAnimationGroup { [self] context in context.duration = animated ? 0.5 : 0 clipView.animator().setBoundsOrigin(p) } completionHandler: { continuation.resume() } } endIgnoreFrameChangeEvents() }

Please don't use the Comment feature here in the forums. It's very annoying. Don't worry about those kinds of security issues. If your app reaches any level of popularity, then yes, it will absolutely be hacked. But at that point, you should consider the hackers to be an unpaid marketing team. Then, if your app continues to be successful enough so that the hackers are a noticeable detriment to your income, you'll have the resources to improve security and lock it down.

I think you misunderstood. This is most definitely not the forum for your users or testers. As an individual developer, it's important to remember that you're not Apple. Nor are you any other company with employees and a user experience budget. If you want people to test your app and give you feedback, you'll have to go looking for them. For many developers, the closest thing to real-world, end-user testing that they ever get is App Review.

There is some "code" associated with that video. If you want the SceneKit original, you might try the archives. I see examples about a voxelpanda, a badger, and two foxes.

Never reply via comment. Your reply most likely won't be noticed. And there is no point in asking questions about new features a few hours before WWDC kicks off.

When Apple, or anyone else, publishes source code on the internet, it is automatically copyrighted. Sometimes that copyrighted content includes an open source license. If so, then you can then use that code under the terms of that license. In theory, said license could say anything. But they typically conform to one of a number of standard open source licenses. Usually, you can continue to use and re-distribute the source even if the original content is removed. Just make sure to confirm that with the license itself. Apple's licenses are typically very unobtrusive. But licenses from other sources can be very restrictive. Unfortunately, Apple is well-known for deleting documentation, videos, and especially sample code. If they publish anything during this week's WWDC that seems like it might be useful, download and archive it. Never assume that anything Apple publishes will be available forever.

That's too much of an open-ended question. Just pick one of the 5000 methods to accomplish this. Or perhaps recognize the inherent constraints of the platform and re-think how you display data to be more readable and useful on a small-screen platform.

Apple always e-mails receipts. Developers have no control over that. Apple has some requirements for user information and consent with respect to purchases, but I'm not aware of any rules against developers going beyond the bare minimum.

Thanks!

Maybe you should include some code showing how you are doing this. As far as I'm aware, the default is to preserve whitespace. And maybe explain what platforms you're targeting. Apple provides a couple of higher-level XML wrappers, depending on your platform.

launchd agents can publish named XPC endpoints. I know enough about that to stay away from it. the system is able to relaunch a launchd agent that crashes. That might be useful. However, there is one important distinction. Can a Launch Agent be used in the Mac App Store? Login Items are explicitly allowed in the "retired" Mac App Store documentation. The current App Review guidelines only mention user consent. Is there a modern replacement for the old "Submitting o the Mac App Store" documentation?

I don't think "SharedSupport" is the appropriate place. The legacy documentation says that this location is for "additional non-critical resources that do not impact the ability of the application to run". Unfortunately, I think the legacy migration documentation is wrong because it explicitly says to use the "Resources" folder for executable code. Don't do that. Here is the current documentation. None of that is really what you're asking about, but I think it leads up to it. Typically, launch agents are single-file executables. I'm not familiar with the taskinfo tool or its output. But what it says makes sense. A Launch Agent would run with a user space UI role. That's how Launch Agents work. That's not the same as a Launch Daemon that runs as root and does not require a login session. When I look at how most other apps handle these things, what you're describing sounds more like a Login Item. A login item would live in "Contents/Library/LoginItems". Of all the apps I have installed that contain items in "Contents/Library", virtually all that contain bundled apps have them as Login Items. So I recommend you treat this thing as a Login Item. (Note that I mean a newer Service Management Login Item, not the really old school Login Items meant for end users). It's only recently that Apple added the ability to bundle Launch Agents and Daemons inside an app bundle. In a modern app, I'm not really sure what the difference between a Login Item and a Launch Agent would be. They seem to perform very similar roles. I guess a Launch Agent would be able to use some of the plist config file tricks that a Login Item would probably have to code manually. I can tell you that I have a couple of apps in development that will contain some background functionality and I plan to use Login Items rather than Launch Agents.

What are those compiler issues? There is very little difference between Xcode 15 and Xcode 16. It shouldn't cause that kind of problem. Plus, Apple now requires Xcode 16 and building against the current SDKs for submission to the App Store. So unless you are distributing this project through some other means, then you have no choice. Otherwise, you can always install a VM, or roll back to an earlier OS version.

Is there a way to package the Java code to work on iOS and mani macOS without having to complicate the project to the point where it would be easier to rewrite the Java code in Swift and have to work harder to update the app on each platform separately? No, there is not. Perhaps this would be an opportunity to try an AI solution to translate from Java to Swift.