“swiftui”

It’s hard to give definitive advice here because there are many different ways to do these things. But lemme take a stab at your two main questions: [quote='831836021, Yoorbo, /thread/831836, /profile/Yoorbo'] When sharing SwiftUI views and business logic for DRY, whats the actual best way to do that? A „core“ swift package, or a library? [/quote] One of those, yes. [quote='831836021, Yoorbo, /thread/831836, /profile/Yoorbo'] what are the implications of choosing one over the other? [/quote] If your library is only ever going to be used by an Xcode project then I think a framework target makes more sense. Swift packages do have significant advantages, but framework targets are directly implemented by Xcode and thus tend to work better when you’re building an app for Apple platforms. [quote='831836021, Yoorbo, /thread/831836, /profile/Yoorbo'] I’ll have to use app groups so that both can have the same data store [/quote] Right. Technically what you use is an app group container. You sign your app to c

For Expo/React Native apps with committed ios/ projects, is a thin Swift native module wrapping Foundation Models the recommended pattern, or does App Review / platform policy expect FM usage only from fully native UI flows? Are there memory, background, or entitlement constraints that make FM impractical when invoked from RN via a bridge (vs pure SwiftUI)?

Does the launch agent need to then launch a GUI App? Can the launch agent get the permission to use bluetooth or does that require a GUI App? What's actually happening when you try to use CoreBluetooth? There isn't actually any fundamental difference between a launch agent and an app. If you're adding something to the menu bar, then you're an app. What API (AppKit, UIKit, or SwiftUI) are you built with and how are you making yourself faceless? How are you setting up your agent? Using SMAppService or a plist? Is your agent embedded inside an app or is it a standalone app bundle? Does it work properly if you're NOT running as a faceless process? __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Hi Mr. Jefferson, thanks for reaching out! I am happy to share the answers below: x refers to the time that the app is in the foreground and the device isn’t connected to power, for the most recent version of your app. The display portion of the block is impacted by display power usage by ProMotion devices. Display power can be influenced in two primary ways: display luminance and display refresh rate. First, the lower the luminance of the display, the lower the display power. Having a dark mode for users who desire it will allow the app to have better display power characteristics. Second, the lower the refresh rate of the display, the lower the display power. A game that runs at 60Hz will have better display power characteristics than one that runs at 120Hz. Additionally, pausing the display when nothing on screen is animating or refreshing will reduce power further. SwiftUI and UIKit manage and minimize refresh rate automatically. Please refer to this documentation to learn more. We can certainly

Thanks for that additional info @Sakuya_Izayoi, If you were replacing the window with another window you could use pushWindow. However, this API is not available to push a volume. I'd greatly appreciate if you could file an enhancement request using Feedback Assistant for this functionality. If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why? Could you provide me with more context of the information provided by the menu and your content? In Hello World, the menu window is kept around when the volumetric globe is opened. Does it make sense for your experience to have both of these scenes open at the same time? In Petite Asteroids, the application launches to the first scene of the game with a menu shown open top of it. This provides a great immersive experience giving the user a taste of what they'd expect once they start the game. Would your experience benefit from any spatial content that you could present inside the volume alongside the menu? In Canyon Cr

My recommendation for a system-standard button would be to use the button role initializer without a text. This also resolves the issue with the transition. Code attached in A If you want to use a custom label, you can specify the same identifier for each button so SwiftUI knows those buttons match and it won't pulse when transitioning. Code attached in B A: With System Standard Button struct ContentView: View { @State private var path: [String] = [] var body: some View { NavigationStack(path: $path) { Button(Go) { path.append(Second) } .navigationDestination(for: String.self) { destination in switch destination { case Second: VStack { Text(Second) Button(Next) { path.append(Third) } } .toolbar { ToolbarItem(placement: .topBarTrailing) { Button(role: .cancel) { path = [] } } } case Third: VStack { Text(Third) Button(Finish) { path = [] } } .toolbar { ToolbarItem(placement: .topBarTrailing) { Button(role: .cancel) { path = [] } } } default: Text(Undefined) } } } } } B: With custom text struct ContentV

Hi @_lrmathias RealityKit supports the just embed a 3D scene in my app use case. No ARKit required. Start here: the SceneKit to RealityKit migration guide Bringing your SceneKit projects to RealityKit. Side-by-side mapping of SCNScene, SCNNode, SCNCamera, SCNLight, materials, and animations. WWDC25: Bring your SceneKit project to RealityKit. Companion session to the article above. The single most relevant resource for your exact question. Other on-point WWDC sessions WWDC26: Explore advances in RealityKit. WWDC25: What's new in RealityKit. WWDC25: Better together: SwiftUI and RealityKit. Composing 3D scenes inside a SwiftUI app. WWDC24: Discover RealityKit APIs for iOS, macOS, and visionOS. Cross-platform, covers lights, shadows, hover effects. Authoring scenes with Reality Composer Pro Reality Composer Pro lets you build scenes (entities, lights, materials, cameras) visually and load them into your app with Entity(named:). The AR branding is misleading; the output works in any RealityKit co

Thanks for the question! My recommendation would be to not intermix SwiftUI and UIKit navigation within the same ‘stack’ (NavigationStack in SwiftUI, UINavigationController in UIKit) - having the 2 frameworks both trying to mutate the same stack can run into issues. (Apps also sometimes try mixing and matching by putting one stack inside the other and hiding the navigation bar, but I would say that’s an anti-pattern and can cause issues with transitions and/or items going into the wrong bar) In terms of how to accomplish this when mixing frameworks: if you use a UINavigationController and want to push a view written in SwiftUI, you can push a UIHostingController onto the nav controller that contains the SwiftUI view. If you use a NavigationStack and want to push a UIViewController, you can push a SwiftUI view that contains a UIViewControllerRepresentable. Regardless of which framework you pick, I’d structure your navigation data model in a way that is state-driven

AnyView is fine to use if you actually want to erase the underlying type! In fact it's provided expressly for this purpose! Existentials (like any View) can't conform to their own protocol types, so SwiftUI provides a type eraser for you. The only caveats about AnyView use: If you can preserve static type information, that is always better! However, if you're trying to store a heterogenous collection, then that's likely not possible (unless you could maybe use a parameter pack for your purposes?) Additionally, AnyView is not super performant if: You are passing the AnyView directly to a List or lazy layout: Lazy containers have poor performance if they don't know the number of subviews produced by their content, and AnyView could produce any number of subviews! If you need to show type-erased content in a lazy container, wrap it in a layout like a VStack so it always produces one subview. You are changing the underlying type of the AnyView: If the underlying type an AnyView erases doesn't change, its

ViewThatFits attempts to size the views from top to bottom given to it. This means that when the last view is chosen that all views before it have been fully initialized (SwiftUI builds the graph for the view) and measured. This is repeated every time the view is invalidated or the parent layout system changes. Try to minimize invalidations by putting the ViewThatFits into a separate view. Custom layouts can also be a good alternative. One benefit is that SwiftUI only actually fully initialize the views once and you are just measuring those in different ways and placing them. Animations work better too when views change their position through a custom layout. Another alternative would be to use AnyLayout and switch dynamically between layouts. This also allows SwiftUI to reuse the underlying graph of the views and just remeasures them and positions them at a different places.

Thanks for the question! Please try this out on macOS 27 if you haven't already - we've made changes in this area. For this case you could try using Animatable to allow SwiftUI to drive the animation if that is appropriate for this case. The Use SwiftUI with AppKit and UIKit session from this year has a great example of this. For this example, this should also work by using NSAnimationContext.animate(_:changes:completion:) in the updateNSView callback similar to: if let currentAnimation = context.transaction.animation { NSAnimationContext.animate(currentAnimation) { nsView.layer?.backgroundColor = targetColor.cgColor } } Please also attach the feedback ID here so that we can be sure it's tracked properly.

The API you want in here is the container background passing the navigation placements. This is working well for me on 27.0. Are you seeing another behavior on 26.0? import SwiftUI @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } struct ContentView: View { @State private var splitViewColor: Color = .teal @State private var splitViewOpacity: Double = 1 @State private var sidebarColor: Color = .orange @State private var sidebarOpacity: Double = 1 @State private var detailColor: Color = .indigo @State private var detailOpacity: Double = 1 var body: some View { NavigationSplitView { List { Section(.navigationSplitView) { ColorPicker(Color, selection: $splitViewColor) Slider(value: $splitViewOpacity) { Text(Opacity) } } Section(Sidebar .navigation) { ColorPicker(Color, selection: $sidebarColor) Slider(value: $sidebarOpacity) { Text(Opacity) } } Section(Detail .navigation) { ColorPicker(Color, selection: $detailColor) Slider(value: $detailOpacity) { Text(Opacity) } } } .na

A few WWDC sessions worth watching if you haven't already: The craft of SwiftUI API design: Progressive disclosure (WWDC22, Matt Ricketson) Demystify SwiftUI containers (WWDC24) — covers ContainerValues Compose custom layouts with SwiftUI (WWDC22) Demystify SwiftUI (WWDC21) — for the identity model that underpins environment-based theming Swift Charts is a useful reference for API design: it combines a result-builder DSL, constrained ...Mark initializers, and a family of ...Style protocols that compose through the environment. The most important principle: design the call site first, then work backward to the implementation. A few patterns that tend to produce reusable, evolvable components: Style protocol. Define protocol BadgeStyle { func makeBody(configuration:) -> some View } with a Configuration that exposes only semantic inputs. Ship .automatic, two or three named built-ins, and the protocol itself. Propagate via the environment so .badgeStyle(.prominent) cascades