Take a look at the official Swift book

This should be possible by adjusting your sort condition. Instead of lValue.categoryName < rValue.categoryNameyou could write something like this: (lValue.categoryName == price || rValue.categoryName == price) || lValue.categoryName < rValue.categoryName or !(lValue.categoryName == price || rValue.categoryName == price) || lValue.categoryName < rValue.categoryName This is not correct code yet and I didn't validate the conditions, but I hope you get the idea. lValue.categoryName < rValue.categoryName is the sort condition the .sort-function uses to decide in which order the elements should appear. You can use very complex conditions or even a function deciding the order of two items by returning true or false depending on the order you want the two compared elements to appear.

filed feedback with Apple: FB11722934

This is a computed variable on the type which returns a new instance of the type using it's init(). something like static var computedTypeProperty:String { return "Test" }

What happens if you put @StateObject var env = EnvObj() above your App's body declaration and pass env on to ContentView? In your code EnvObj() my be called multiple times because body may be evaluated every time SwiftUI needs it.

This seems to be a common problem with the App Store: You need to have already "bought" the app when the older version was still current. See this guide ( https://www.makeuseof.com/how-to-download-older-versions-of-apps-on-older-iphone/ ) for example.

You can use Swift Playgrounds on iPad to create real apps. There are free eBooks from Apple for this topic: Learn to Code - Teacher Guide and many more! For school-related questions Apples Education Community should be a great resource.

What about requestMediaDataWhenReady( on queue: DispatchQueue, using block: @escaping () -> Void )(see documentation)

You can alway add     #if targetEnvironment(simulator)         print("Documents Directory:\n\(URL.documentsDirectory.path())")     #endif somewhere in the initialization of your app code and print the path to the console. Or use the following app https://github.com/twostraws/ControlRoom for additional features the simulator should have, including access to the documents directory and the directory where the Files App stores its data.

Did you add the Swift Collections Package to your playground as shown in the video at runtime 3 min 50 secs? This step is different from and necessary prerequisite for import Collections.

In your first example your properties are missing the @Published annotation. Views observing an ObservableObject only refresh on change of properties which are marked as @Published.

What happens if you replay @ObservedObject with @StateObject in your App struct?

You are still thinking to much in "imperative programming" terms. SwiftUI is "declarative". The var body of a View is no regular Swift function, it is a @ViewBuilder. This means only a subset of Swift is allowed there. Like generating Views and some conditional statements. Regular "imperative" code like weightKg = weight/2.205 is not allowed. You have to derive all of the View's state from your model. Some Views like Button have closures which can contain "imperative" code. You can do/cause calculations there or in your model. Better would be to bind the weight variable to the input field of a View and make a calculated var for the other weight which is used by a Text for example. @State var weight = 175.0 var weightKg:Double{ return weight/2.205 } var body:some View{ // ... SomeInput($weight) // SomeInput is not really an existing type, you would have to look up the correct syntax for TextField for example Text("weight in kg: \(weightKg)") // ... }

First, you have to separate the reading of the data into a model from the rendering the model data into the GUI! ForEach is only usable to render existing model data, you can't read or create the data in this loop. This is not the way SwiftUI works. For reading table data see TabularData data framework, Swift RegEx or String.split(separator:..)

Unfortunately in the meantime FB 11722934 was closed by Apple: "Investigation completed - functional capability according to current design given" (translated from the german status message on the Feedback web page) In the best interpretation this means the problem is known to behave this way until Swift 6 compatible frameworks come out? But this is not really a helpful answer. I even tried to ask about this problem in an Ask Apple: Swift session but it was not covered in the topics answered.