It seems Xcode 13.1 RC requires the unreleased macOS 12.  What source says so? In Apple's official Release Notes, you can find this: Overview Xcode 13.1 RC includes SDKs for iOS 15, iPadOS 15, tvOS 15, watchOS 8, and macOS Monterey 12. The Xcode 13.1 release candidate supports on-device debugging for iOS 9 and later, tvOS 9 and later, and watchOS 2 and later. Xcode 13.1 RC requires a Mac running macOS 11.3 or later. macOS 11.3 or later is the requirement to run Xcode 13.1 RC. And RC is very near to the released version, in the past the released version had exactly the same build number as RC. I would expect Xcode 13.1 runs on macOS 11.3 or later. Apple says Xcode 13 is required to develop apps on Macs running macOS Monterey . But it is not the requirement to run Xcode 13.1.

You know the new M1 Pro/Max is not out yet, so you cannot find any actual experiences here as for now. But, in the era of Intel, Xcode is known as a tremendous memory eater. I would not expect too much about new behavior on M1. I would choose 32 GB or more for my dev machine.

I can see the downloaded data correctly in the console Can you show the example of the downloaded data? "The data couldn't be read because it isn't in the correct format." The error message is shown when the data type (in your case, [FDCFoodItem]) and the actual data returned mismatch. Please show the definition of FDCFoodItem. But you should use print(error) instead of print(error.localizedDescription). print(error) will show you more info about what is wrong. Please show the full message you can get with print(error). I am guessing I have to add something like the "encoder: utf8" statement in the .decode function Bad guess. There's no such parameter like encoder: utf8. All raw response in JSON should be encoded in UTF-8 and you have no need to specify encodings when using JSONDecoder. Or maybe transform the data in the .tryMap closure before returning.  Again, very unlikely. .decode would do the transform in this case. Anyway, if you could show enough info as above, you would be able to find the right solution.

The input is all textual and to speed things up needs to be saved as binary data for input. How efficient does that processing needs to be? Unless you call it thousands of times in a second, users would not feel the difference than using more stable and easy to use serialization like JSON. Plists are too slow.  How slow is it compared to the required speed? Can you clarify how you have evaluated the required speed? And your way of saving or retrieving binary data is completely wrong: targetfile += Data ( bytes: &headerValues, count: headerValues.count * MemoryLayout<[Any]>.stride ) With this usage of Data(bytes:count:), Swift copies the internal structure into the Data as is. Do you know how Swift.Array is represented in memory precisely? How is Swift.String? How is Any? They all may contain some pointers internally, so the contents pointed by the pointers also needs to be exist in the serialized binary. And even if you successfully save the pointees, you cannot retrieve them as you cannot modify such internal pointers. But when I read the data into an [[Any]] array the data is confused (extra data is found, especially in the header values). You were just lucky (or unlucky in a meaning) that your app does not crash on reading. You should better re-consider if you really need such binary data for input. If you insist on using binary data, you can define a C-struct: #define MAX_VERSION_LEN 32 #define MAX_BODY_LEN 32 #define INT_VALUE_LEN 14 #define DOUBLE_VALUE_LEN 5 typedef struct InputData { char version[MAX_VERSION_LEN]; char body[MAX_BODY_LEN]; long intValues[INT_VALUE_LEN]; double doubleValues[DOUBLE_VALUE_LEN]; // ...and more... } InputData; and import this struct into your Swift project, parse the input for this struct.

When you show your code, please show it as text using Code Block. I do not know much about Apple Pie Guided Project, but is it written for the version of Xcode you are using? Apple introduced drastic changes to UIButton in iOS 15, so some of the code once worked in old Xcodes, does not work in Xcode 13. One possible way to fix this issue, is getting the right version of Xcode which your Apple Pie Guided Project is targeting. More Downloads Another possible try, though I'm not sure if this works well in your case, would be changing the Project Format compatible to an old one. If you want to learn what's changed in iOS 15 rather than the basics of app development, there may be some fix just touching some parts of your code. But, as you are not showing your code as text, I cannot retrieve needed text from your screen shot.

What should I do? In fact, I have experienced similar behaviors even in Xcode 12 on macOS Big Sur. In some of my projects, the pull down menu Assistant abruptly recovered its functionality and now it works as expected. Maybe some sort of background setups are running behind and we may need to wait them to finish without interrupting it, but I'm not sure. As a workaround until the functionality will be recovered, you may need to open another Editor side by side and choose the right swift file by yourself.

I'm sure the tag I selected doesn't have anything to do with what I am asking, but I had to select a tag. The UI of this site is sort of broken, but you could choose Swift or Objective-C or Xcode or something like that. By the way, what do you mean by building Loop in Xcode? I cannot understand what you are trying to achieve. Can you add some more explanations? Including some images or links would explain it better.

You may need to provide more info to let readers try to help solving your issue. Can you show the source file which contains the compile error? (Please do not forget to show the code a text using Code Block.) The whole message shown in the debug console may also be useful. Info about your project, such as iOS app or macOs app, or used third party libraries if any...and so on.

Can you clarify what you have done till now on your Mac? In a usual app project of Xcode, you do not use JavaScript and there is no root.plist.

Can you create a minimized project to reproduce the issue and show all the code of it?

As far as I know, Xcode 13 has removed Life Cycle from templates of SwiftUI apps. If you want a project template with Life Cycle as UIKit App Delegate, create a project with Xcode 12 create a new SwiftUI project with Xcode 13 and create/copy AppDelegate.swift and SceneDelegate.swift by yourself create a new UIKit project (Interface: Storyboard) with Xcode 13 and modify SceneDelegate.swift by yourself (You may need to modify some settings.) Check this similar thread of 3 months ago.

Seems you have read the Concurrency part of the Swift book, but it does not tell much about the current restrictions of async let. Does swift 5.5 support this case??? If you mean using async let inside a code block of looping statement such as for-in, the answer is no. In the accepted proposal SE-0317 async let bindings, you can find this description: Specifically, async let declarations are not able to express dynamic numbers of tasks executing in parallel, like this group showcases: func toyParallelMap<A, B>(_ items: [A], f: (A) async -> B) async -> [B] { return await withTaskGroup(of: (Int, B).self) { group in var bs = [B?](repeating: nil, count: items.count) // spawn off processing all `f` mapping functions in parallel // in reality, one might want to limit the "width" of these for i in items.indices { group.async { (i, await f(items[i])) } } // collect all results for await (i, mapped) in group { bs[i] = mapped } return bs.map { $0! } } } In the above toyParallelMap the number of child-tasks is dynamic because it depends on the count of elements in the items array at runtime. Such patterns are not possible to express using async let because we'd have to know how many async let declarations to create at compile time. I use TaskGroup already, but I want to know that swift supports it. Seems you need to go on with TaskGroup in cases such as described in your opening post.

if foods were class, would that make a difference? YES. Is that right? Right.

To show the right usage of @StateObject, the relationship of two views needs to be clarified. But generally, if there are two initializers in your code, there may be two or more different instances of the same class, which causes unexpected behavior. Assuming your SampleWeatherView is a subview of WeatherView in your view hierarchy, you can write something like this: WeatherView struct WeatherView: View { @AppStorage("userTempChoice") var userTempChoice = "Fahrenheit" //Use only 1 `@StateObject` where the only initializer exists @StateObject var weather = UserWeatherData() var body: some View { VStack { SampleWeatherView(weather: weather) Text("Tap Me") .onTapGesture { //I set my data //A simplified working example weather.currentDescription = "Sunny all day!!!" } } } } SampleWeatherView struct SampleWeatherView: View { //Do not put an initializer except `@StateObject` @ObservedObject var weather: UserWeatherData var body: some View { Text(weather.currentDescription) } } If you could show more context representing the view hierarchy of your app, there might be the right solution other than above code.

When you show your code, please show it as text using Code Block. And you should better properly respond to the comments and answers to your old post.