This looks fixed from Xcode 27 beta 6. Thanks!

This is still broken for me from Xcode 27 beta 5. But it looks like we did patch a fix on 6.4.^1

Another repro: struct Repeater<each Input> { private var __storage = LazyState(initialValue: { Storage() }) private var input: (repeat each Input) init(_ input: repeat each Input) { self.input = (repeat each input) } } Using classic State does not crash: struct Repeater<each Input> { private var __storage = State(initialValue: Storage()) private var input: (repeat each Input) init(_ input: repeat each Input) { self.input = (repeat each input) } } And for some reason I can build from LazyState if I do not save my parameter pack to a stored instance variable: struct Repeater<each Input> { private var __storage = LazyState(initialValue: { Storage() }) init(_ input: repeat each Input) { } } It also turns out I can also use LazyState if I declare the stored parameter pack variable before I declare the LazyState variable: struct Repeater<each Input> { private var input: (repeat each Input) private var __storage = LazyState(initialValue: { Storage() }) init(_ input: repeat each Input) { self.input = (repeat each input) } } That one does not crash.

Here is a version that crashes without the State macro: struct Repeater<each Input> { private var __storage = SwiftUICore.State._makeStorage({ Storage() }) private var input: (repeat each Input) init(_ input: repeat each Input) { self.input = (repeat each input) } }

I checked with a colleague and they agreed that my theory above is correct So if the expected behavior is: According to my theory, I don't believe the @State has actually been initialized at this point, so your call to start() actually initializes a Timer, starts it, and then as soon as that scope exits ARC destroys that Timer. Then, a little bit later, the @State managed Timer is actually created, resulting in these logs: ObjectIdentifier(0x0000000a22a2ca80) init ObjectIdentifier(0x0000000a22c245a0) stop And the "bad" example from TN3211 is: struct ContentView: View { @State private var counter: Int = 0 init() { self.counter = 42 } } I kind of start to think here that if State has an inline initial value and the developer attempts to set a value in init we want to either crash at runtime or at least try to display one of those purple warnings in Xcode. Something other than just sort of failing silently might be a very good idea here considering all the code that is probably out there either using this example from TN3211 or my example.

If you call start() in a .task on the view instead of in the App's init, I believe you will see what you expect. So this is not a bad idea… but unfortunately does not quite get me what I would have hoped for. If I inspect the SwiftUI view lifecycle here: @main struct StateDemoApp: App { @State private var timer = Timer() init() { print("StateDemoApp init") self.timer.start() } var body: some Scene { WindowGroup { ContentView() .onAppear { print("StateDemoApp onAppear") } .task { print("StateDemoApp task") } } } } and then put additional print logs in ContentView itself I get the init log from StateDemoApp called before the init log from ContentView and the onAppear and task logs from StateDemoApp called after the onAppear and task logs from ContentView. Ideally I would like to start this Timer before ContentView might be doing something else with global state that might break if the Timer did not start first. I can also workaround by moving the Timer construction to init: @main struct StateDemoApp: App { @State private var timer: Timer init() { print("StateDemoApp init") self.timer = Timer() self.timer.start() } var body: some Scene { WindowGroup { ContentView() } } } If this works correctly from Xcode 26 and Xcode 27 then this might be best for me.

This is still broken for me in Xcode 27 Beta 4. :(

This is still broken for me in Xcode 27 Beta 4. :(

If the find a bug in the sample code please file a big report via Feedback Assistant and post the FB number here once you do. https://appleinsider.com/articles/25/04/18/when-you-report-bugs-on-ios-some-content-may-be-used-for-ai-training Thanks… but for privacy reasons I'm currently blocked on submitting bug reports due to a requirement on AI training. Are you referring to the dismiss environment property? I'm referring to the Select and Done buttons that appear to toggle EditMode:

https://github.com/apple/sample-food-truck/blob/3954a769e99f3cc53297d94f2b960ceb2665b3d6/App/Orders/OrderDetailView.swift#L87-L110 I had another question about using Live Activities from Xcode Preview. My question is from a different POV: I have a view component that performs some logic to start and end live activity. I am wondering… what kind of support do I have from Xcode Preview to then actually see that Live Activity in action as a kind of "end to end" test that my call to ActivityKit.Activity started an activity correctly? My understanding here is the supported way to test Live Activity starting and stopping is to actually run the app and start the activity from that component. There isn't a supported "shortcut" from Xcode Preview. Is that correct?

Does not repro from Xcode Version 16.2 and macOS 15.2. Thanks! :D

Hmm… I believe I do now have an understanding how a State variable would tie the lifecycle of its value to the lifecycle of a View component… but I am still unclear how this helps me to understand how a State variable defined on an App component can be expected to behave: https://developer.apple.com/documentation/swiftui/managing-user-interface-state This article has many examples of using State in a View component… but I do not see examples of using State in our App component. https://developer.apple.com/videos/play/wwdc2020/10040/?time=1852 This video does have an example of a StateObject being used as a global "source of truth" (which is going to be most similar to my use case)… but this video predates the release of State and Observable. https://developer.apple.com/videos/play/wwdc2023/10149 I believe this video has a close example from FoodTruckModel to achieve a similar feature to my use case. What this video seems to be missing is where this FoodTruckModel should first be created. Similar to the previous talk… this "global source of truth" looks like it should belong in my root App component… but then would that imply that FoodTruckModel be better initialized as a State var or as a regular Swift let? A side-question I would have here is how it would be possible for an engineer to stress-test their app in a way to cause the App component instance to be disposed by SwiftUI (and then rebuilt while the process is running). Is such a use case ever possible in an edge case? Is this something (recreating App component) that engineers should ever have to prepare for to defend against?

This is a more detailed example that shows some extra work from my production app: @main struct StepperDemoApp: App { var body: some Scene { WindowGroup { ContentView() } } } @Observable final class Number { var value: Int = 0 } struct ContentView: View { @State private var number = Number() func onIncrement() { number.value += 1 print(#function) } func onDecrement() { number.value -= 1 print(#function) } var body: some View { Stepper { Text("Stepper \(number.value)") } onIncrement: { self.onIncrement() } onDecrement: { self.onDecrement() } .padding() } } #Preview { ContentView() } In this example, the Stepper text label value depends on state (the number class), but I see the same unexpected behavior (potential bug) from my original example. My Stepper text label is correctly updating when the Observable value changes… but the onIncrement and onDecrement closures are in some kind of "bad" state. My original example showed how the Stepper behaves unexpectedly when no state is triggering a redraw. This new example behaves unexpectedly when state is triggering a redraw through an Observable object. Our previous example showed how Stepper behaves as expected when we trigger a redraw directly on state (without the indirection of an Observable object). All these repros are from macOS 14.6.1… deploying to iPhone simulator behaves as expected on all examples (no unexpected behavior).

I've submitted a bug report myself and will see if I can find a workaround. Thanks! I am actually kind of "unblocked" in a different way by building my own custom component: @main struct StepperDemoApp: App { func onIncrement() { print(#function) } func onDecrement() { print(#function) } var body: some Scene { WindowGroup { VStack { Text("Stepper") Button("Increment") { self.onIncrement() } Button("Decrement") { self.onDecrement() } } .padding() } } } This unblocks my use case for my app… but I am still blocked from using the system Stepper component. If I did ship this custom component as a workaround it would be helpful for my repo to be able to explain to readers why this workaround is needed (because the production stepper component is potentially causing a bug on macOS).

could you explain what you're using this for that's not updating any UI Thanks! The post here is an attempt at a MRE test case to show I am unable to see these two functions called how I expect on macOS (but iPhone simulator behaves as expected). My production app does more complex work in the onIncrement and onDecrement functions and I am not seeing that work being called correctly. I seem to be running into the same problem in my production app I have here in the MRE test case… without an explicit state or id refreshing the stepper then the macOS stepper seems to get in some weird situation where the + and - buttons do not dispatch correctly until the next manual refresh computes a new body.