“swiftui”

For the hosting view, use SpriteKit's SwiftUI SpriteView, which renders an SKScene and works on both iOS and watchOS — so you avoid the platform-specific SKView (iOS) vs. WKInterfaceSKScene (watchOS) split. For input, SwiftUI supports the same basic tap/drag gestures on watchOS as on iOS, though you'll often wire them to different in-game actions per platform. There are also inputs unique to watchOS — most notably the Digital Crown via. digitalCrownRotation. To support both cleanly, keep the game logic platform-agnostic and feed it semantic intents rather than raw input. The shared engine never references a touch or the crown — each platform translates its own input into the same intents. e.g. /// The platform-agnostic input vocabulary. Every platform maps its own /// hardware (touches, drags, Digital Crown) onto these cases. public enum GameIntent { case aim(at: CGPoint) // a scene-space point (e.g. iOS drag/tap location) case moveHorizontal(Double) // a relative nudge (e.g. watchOS Digital

Hi CatastropheZero, For the hosting view, use SpriteKit's SwiftUI SpriteView, which renders an SKScene and works on both iOS and watchOS — so you avoid the platform-specific SKView (iOS) vs. WKInterfaceSKScene (watchOS) split. For input, SwiftUI supports the same basic tap/drag gestures on watchOS as on iOS, though you'll often wire them to different in-game actions per platform. There are also inputs unique to watchOS — most notably the Digital Crown via. digitalCrownRotation. To support both cleanly, keep the game logic platform-agnostic and feed it semantic intents rather than raw input. The shared engine never references a touch or the crown — each platform translates its own input into the same intents. /// hardware (touches, drags, Digital Crown) onto these cases. public enum GameIntent { case aim(at: CGPoint) // a scene-space point (e.g. iOS drag/tap location) case moveHorizontal(Double) // a relative nudge (e.g. watchOS Digital Crown delta) case primaryAction // fire / jump / select

Hi dfabulich The Game Controller framework enables your application to receive inputs from connected physical game controllers, as well as from touch controllers built with the Touch Controller framework. The inputs the Game Controller framework delivers to your application reflect the button presses, thumbstick movements, etc of the physical game controller (or touch controller). They are not 'events' (in the AppKit or UIKit sense), and do not flow through the responder chain where views or gesture recognizers can act on them. Now to your specific questions: I would like to add support for game controllers on iPhone. I can't figure out how to do it. I'm afraid there is no out-of-the-box functionality for this today on macOS, iOS, or visionOS. Your application can use the Game Controller framework to receive inputs from connected game controllers. But you will need to implement the logic that interprets those inputs into updates to your user interface - sometimes called a focus engine. A minimal focus engine

First, I'd like to note this excerpt from the CKAsset documentation: When you fetch a record that contains an asset, CloudKit stores the asset’s data in a staging area accessible to your app. Use the asset’s fileURL property to access its staged location. The system regularly deletes files in the staging area to reclaim disk space. To avoid this behavior, move the data into your app’s container as soon as you fetch it. As you read (sync/query/fetch) CKRecords, you'll be updating your on-device database noting the presence of that data as it's downloaded, and you'll need to move the CKAsset files (e.g. thumbnail and any other image derivatives) into your app container. Your on-device database can then be used to feed your user interface, including whether a record has a thumbnail, etc. Since I'm not an expert in it, I won't speak to the best ways to efficiently render large sets of data that potentially have file-backed content, but presumably SwiftUI has solutions for this.

Hello @DTS Engineer, Thank you for answering. I'll try to explain a little bit more the end result I want. Basically, something like what Apple uses for the Silent Mode floating pill/indicator at the top of the screen. Something I could use in my app to indicate success/errors/confirmations when some actions are performed by the user. Let say an action is performed in the SheetContentView, I want to immediately present the indicator while also dismissing the sheet. I dismiss the sheet I want the PillNotificationView to stay visible, on top of everything. So it can't be an overlay/ZStack to the SheetContentView, and it can't be an overlay/ZStack to the MyView. Regarding the code (this does not work as explained above because the PillNotificationView is overlaid to the MyView due to the ZStack) ZStack { MyView() if isPillPresented { PillNotificationView() } } .sheet(isPresented: $isPresentingSheet) { SheetContentView() } I want the view to be presented only once either above everything (no matter if the top vie

visionOS 27 - enabling curved windows Short answer: there is a private Info.plist key that Safari uses for this, but as far as I can tell it is not honored for third-party apps (especially SwiftUI-lifecycle ones). It looks first-party gated. Here is what I found reverse-engineering the visionOS 27 SDK and the simulator runtime. 1. The key Safari sets MobileSafari.app/Info.plist on visionOS 27 contains a PreferredWindowCurvature entry, nested inside UILaunchPlacementParameters (the same dict that holds PreferredLaunchSize). This key is new in 27 - it does not exist in the 26.5 Safari Info.plist. UILaunchPlacementParameters PreferredLaunchSize Width940 Height916 PreferredWindowCurvature Enabled The accepted string values (from the MRUIWindowCurvature enum in MRUIKit) are: Default | Automatic | Enabled | Disabled Practical note: UILaunchPlacementParameters is a nested dictionary, so you cannot express it via INFOPLIST_KEY_* build settings. With GENERATE_INFOPLIST_FILE = YES you have to point INFOPLI

Hi. That sounds unexpected! Was this a SwiftUI front-end ? Could you please try to put together a minimal sample-AU that reproduces this problem ? That would help us diagnose and fix this issue. Please be sure to file a feedback request on https://feedbackassistant.apple.com Thank you!

Can you please clarify what you mean by more modern? The AUv3 template that comes bundled with Xcode gets modernized regularly embracing the latest changes, such as SwiftUI and C++-Swift-interoperability. That would be the recommended way to build an AUv3.