Should the delegate property in the struct also be marked with weak? It depends on whether it may create a reference cycle or not. In the example code you have shown, hostingController may hold a strong reference to ExampleView.delegate, but it is not held as a strong reference in viewController. (Please start type names with Capital letter, even in a simplified example.) So, you have no need to declare the property ExampleView.delegate as weak. Generally, in case of View structs, you have no need to care about reference cycles if you are using the View in a usual way. But, if you are not using the View in a usual way, or the struct is not a View and it may be used in various ways, you may need to place weak on properties which may make reference cycle. If you do not understand what would be usual nor what might make reference cycles, better use weak even when it is not named delegate.

If you come here to solve your issue, please try to explain your problem precisely. Please show your code to reproduce the issue, what is the current behavior and what would be the expected behavior. Including screen shots and images would help readers understanding.

Swift 5.5 introduced a new dot leaded notation. SE-0299Extending Static Member Lookup in Generic Contexts Please try this: .navigationViewStyle(.columns)

The problem is, that is dont only need the billModel in the PDFManger but also everywhere else in the App I do not think that would be an issue, you can do what Dirk-FU said: class PDFManager: ObservableObject { var billModel : BillModel? func saveToDB() { billModel?.addData(billToAdd: bill) } //... } And set PDFManager.billModel on start up of your app: var body: some Scene { WindowGroup { MainView() .environmentObject(billModel) .environmentObject(customerModel) .environmentObject(itemModel) .environmentObject(sheet) .environmentObject(manager) .onAppear(perform: { manager.billModel = billModel billModel.getData() customerModel.getData() itemModel.getData() }) } }

@MinhQuang I cannot say what are good User Interfaces, but it seems you have your own good User Interfaces in mind. Please try to explain what is the problem of the current UI and what would be your expected UI. I do not understand what you mean by I can't make the inside park I tried to use List layout but it didn't work out. Hand-drawn sketch would help. Please do not forget to show your current code.

As far as I read your requirements, you do not seem to have many choices. One possible way, prepare a generic TaskView: struct TaskView: View { let number: Int var body: some View { switch number { case 1: Task01View() case 2: Task02View() case 3: Task03View() //... default: EmptyView() } } } And use it like this: ForEach(0...6, id: \.self) { task in NavigationLink( destination: TaskView(number: task) ) { Text("\(task). Aufgabe") .font(.custom("Chalkduster", fixedSize: 16)) .foregroundColor(Color(UIColor.brown)) } }

Thanks for finding and sharing an interesting example. For me, it seems to be a bug of Swift. You should better send a bug report to swift.org.

Does anyone know if there is an official URL for the Shazam API and how I can use it? As far as I know, Apple has never announced the Web API for ShazamKit. And the current shazam.com (Shazam is now a family company of Apple) does not have any documentations or links to the API you have shown. So, you may need to research and learn it by yourself and use it on your own risk. (Seems it is not free.)

Can you show the whole message shown in the debug console? I have not tested enough, but recent iOS are eager to detect more unexpected usages than ever. Do you think of anything unusual in the usage of your WKWebView? Showing more context, including the content of stringUrl or other project settings related to WKWebView may help.

Is there a way to show the app launch screen until firebase fully loads, NO. maybe there is any other way? Many apps show sort of Loading View while some sort of communication is going on. Simply, you can show a better word than "nil", or you could show your own Loading View (other than launch screen).

Should I dispatch to the main queue from within my presentAlert function, or... That's one thing required. But if your issue is really caused by threading problem, there may be many other things to fix. Better try fixing it and test on the TestFlight with as many testers involved as you can.

how can I fix it? When you show your code, you should better show the code and the whole error message as text (use the Code Block). With the code being easily testable (copy and paste!), more readers would be involved. Screen shot is useful as an additional info, but you should better not think it would be a good primary info. Any way, the most problematic issue is here: I´m going through the "Develop in swift Fundamentals XCODE 12" course I'm currently on XCODE 13 Why the heck are you using Xcode 13 for the course written for Xcode 12?????????? Xcode and iOS changes every year, and in some cases it may cause some severe issues when you followed instructions correctly. Especially, iOS 15 introduced some ground up changes in UIButton. You may have noticed some settings views are different than in the course. If you insist on going on with Xcode 13, you may find other issues in the future. I recommend you to find a course written for Xcode 13 or get Xcode 12. (See More Downloads pages.)

It doesn't look like Combine lets us observe a button tap. Am I right? Right. Combine has no native approach?  NO. At least, not yet. you still have to use the IBAction? Currently, target-action seems to be the only event handling scheme of UIKit. There may be some advances in the future, announced in WWDC 22 or later. As you know, Combine seems to be mainly designed for SwiftUI and works well with SwiftUI. If you want some native support for Combine in UIKit, you may want to write an enhancement request to Apple using the Feedback Assistant.

{The site was malfunctioning -- removed.}

Do you have any questions? If so, please clarify what you want to ask.