I am also encountering numerous problems with the update to 3.4 (1302.27). They range from The operation couldn’t be completed. (PlaygroundBuild.BuildSystem.BuildError error 0.) to playground pages just aborting with the error flag saying There was a problem encountered while running this playground. Check your [previously fine and executable!] code. (Note: in case it’s not obvious, I added the comment enclosed by the brackets.) And in one case, there’s even a thread dump — this is from a playground which was just fine 2 days ago: remoteProcessWasInterrupted Error: Fatal error: file SwiftUI, line 0 ... [thread dump elided] It is nice to have a console and somewhat better error reporting, but yikes, this update has delivered disaster after disaster — perfectly working playgrounds in which I have a lot of effort invested are now trash. I have only an iPad to write playgrounds, and therefore don’t have access to possibly better error analysis in Xcode. Pretty frustrating. Feedback Assistant - https://feedbackassistant.apple.com/ is where you can file bug reports. You may have to sign in to a Developer account (you don’t have to be a paying developer; just the “free” level). The problem is that when filing a bug report, you should submit the simplest case which reproduces the error. That’s going to be nigh impossible distilling such a case from fairly large projects containing complex code.

I’m beginning to suspect that the team/process which packaged the 3.4 release did not update the linked SwiftUI library that was used to compile and test Playgrounds. (This is just a hunch since I cannot inspect what’s in the app’s package on the iPad — I don’t have a Mac to do this kind of inspection.) The errors are all related to SwiftUI, and seem to mostly relate to layout. Some of my playgrounds are drawn half offscreen before they crash. However, it’s not just limited to UI elements. In one very complicated playground, it crashes because the environment object hasn’t been instantiated before the views are orchestrated. This is serious, since the contract is that the environment must be set up *before* views are instantiated. I also suspect that testing wasn’t done on an actual iPad since you say that they work on the Mac. My guess is that tests were run on Macs with Playgrounds running as a Catalyst app. Just a hunch. But who would have certified the tests had they seen what happens on an actual iPad? For the moment, until an update to fix this, I’m dead in the water.

Did you file a bug report through Feedback Assistant? Also, if you eliminate the SwiftUI (still need to import UIKit for Bundle) and just invoke something like movies.forEach { print(“\($0.title)”) } does it behave as expected? (I just did this with your code, and there doesn’t seem to be a problem with the decoding. I have to say, having the console, added in this release, is quite nice for debug logging.)

To go one step further (from @Tylor’s) in refactoring your code, pull the func sendHttpPostDesktops() out of the ContentView struct, since the function’s concerns are not those of the view. Such a refactoring makes the function testable without firing up a view. Also, add a parameter to the function, like this: func sendHttpPostDesktops(ip: String) { let session = ... // same code as before let url = URL(string: "http://\(ip):\(String(port))/\(cmd)")!	 ... // the rest of your existing code } and invoke this method in your button’s action closure: Button(action: { sendHttpPostDesktops(ip: serverIp) }, label: {...}). .... (Note that I have elided pieces of code from @Tylor’s example for brevity.) You do want to write unit tests, especially for functions like sendHttpPostDesktops to assure yourself that they work properly with bad and good inputs.

You can try starting from an Xcode playground, but from my experience (I have playgrounds which were started from “Blank” and the Xcode template), none of them work correctly. Some of those written using the Xcode template display more or less correctly, but I’m noticing that bindings (@State, etc.) don’t work. Such a mess. The difference between the two template types is in folder and file structure. If you have an editor like Textastic which lets you navigate into a playground package, you can see the differences. You can also get a hint if you click on the “...” menu button (next the the “+” menu item when working on a playground), go to “Advanced” and “View Auxiliary Source Files”. Lastly, did you mean “dragging the final brace downward to include code”? (Either way, thanks for reminding me about this dragging behavior in the editor on iOS.)

It may be that you have encountered some of the problems that many of us now have with our own playground code since the Playgrounds app was updated to version 3.4 (1302.27). This happened about a week ago now. The update broke playgrounds rather severely in terms of rendering, bindings, and even just the ability to run previously working code without crashes and unhelpful error messages. But look on the brighter side: you now have a console for viewing print() output, and even some level of crash reporting with exception traces. Now if our playgrounds would just work, we’d be fine. You might consider filing a report using the Feedback Assistant - https://developer.apple.com/bug-reporting/.