Same here, but on a Mac with Intel CPU

I think your question can't be answered without you telling us how you create and pass your GlobalObj in the levels above? Do you use @StateObject for example? Additionally in the WWDC lounges someone asked: I’ve had several intermittent crashes from environment objects being nil when I pass them to a sheet or NavigationLink. [...] The answer was: NavigationLink by design doesn’t flow EnvironmentObjects through to its destination as it’s unclear where the environmentObject should be inherited from. I suspect this might what’s causing your issue. In order to get the behavior you expect, you’ll have to explicitly pass the environmentObject through at that point.

Like with every async function called from a synchronous context (the global context of your playground) you have to wrap your call to doStuff() in an async block and await it: async{ await doStuff() } This is expected to change to Task.async{ await doStuff() } in a later beta. The following list of WWDC videos covering Swift concurrency should provide further background: Meet Swift Concurrency

Sorry, I forgot about three additional things you have to do to use Swift concurrency in Playgrounds: import _Concurrency import PlaygroundSupport PlaygroundPage.current.needsIndefiniteExecution = true

PS: is it supported on iPad Air 2 to begin with? Playgrounds 4 will run on all devices capable of running iOS 15 and will be available later this year, was the information given at WWDC.

Interesting! Unfortunately this is does not give the same result, depending on the views content. Try Circle().stroke() for example, to see the difference in rendering.

Did you try: init() { timer = Timer.scheduledTimer(withTimeInterval: 0.1, repeats: true) { [weak self] timer in self?.getRandonNumber() } } Capturing self is alway „dangerous“ and can lead to memory leaks. The timer/closure keeps a reference to the ViewModel and the ViewModel keeps a reference to the timer, therefore their memory is never released. I don't know if your ViewModel is recreated many times during the run of your app, but if it where, this reference cycle would lead to a memory leak.

I can't see anything really broken about your code. Only .environmentObject(vm) in the body of ContentView is not necessary.

Did you try .sheet(isPresented: $showTest) {             FailingView().environmentObject(stateObj)  }

I would suspect it has to do with the same limitation all of SwiftUI suffers: You can only declare 10 subviews inside of a view. The usual workaround is to use Group{} like this: HStack{ Group{ Item1 Item2 ... Item10 } Group{ Item11 ... Item 20 } }

I think you declared your Property wrapper outside of a view struct (like on the to level of the Playground code) which is not supported.

I'm not sure, if it is intended by Apple or even allowed to use @EnvironmentObject inside the model code. I think you should declare billModel in PDFManger as a simple let or var and set it yourself using an initializer:

let bundle = Bundle(for: TheNameOfYourXCTestCaseSubClass.self) Using the class name of your XCTestCase-derived class the above code gives you the corresponding Bundle. Afterwards use the methods on Bundle to access the specific file.

The swift compiler's error message is misleading, but what happens if you write presentationMode instead of presentatoinMode ?

Yesterday Apple updated its iPadOS 15 web page: For „Universal Control“ they added a badge saying that it was delayed to spring 2022. For Swift Playgrounds they removed a footnote stating it would come „late 2021“. So there is still hope we will see it before the holidays. My children and I are also waiting for it to be released and would be very disappointed if it was delayed even more. Come on Apple, you can do it!