What I did is here: I deleted VALIDARCHS from Project I deleted VALIDARCHS from Target Build Active Architecture Only = YES (for Debug) Architectures = Standard Architectures $(ARCHS_STANDARD) Also, File -> Project/Workspace Settings == New Build System

ok so If I am getting correctly then Account will have code for validation, network call, caching, routing, etc... // State (shared in view hierarchy), part of your model class Account: ObservableObject {     @Published var isLogged: Bool = false     func signIn(email: String, password: String) async throws { // VALIDATION CODE ****1 // NETWORK CALL (we will have shared network object) ****2 // PERSISTENT (we will have shared persistent object) ****3 // ROUTE TO NEXT SCREEN (we will have global navigator or screen router) ****4 } } What we are achieving by giving so much responsibility to Account model. Instead can't we just go with simple with SignInViewModel, also Validation, Persistency and Routing will not be tight together in Account. See what I am thinking, and let's justify which one is better. class SignInViewModel {     func signIn(email: String, password: String) async throws { // NETWORK CALL (we will have shared network object) ****2 } } // View struct SignInView: View {     @EnvironmentObject private var account: Account     @State private var email: String     @State private var password: String     var body: some View { ... }     // Call from button     func signIn() {         // WE CAN CALL VALIDATION UTILITY FROM HERE ****1         Task {             do {                 try await signInViewModel.signIn(email: email, password: password)         // WE CAN CALL PERSISTENT UTILITY FROM HERE ****3 // THEN ROUTER CAN ROUTE TO NEXT VIEW ****4             } catch {                 // Change error state             }         }     } }

Let me try to explain what is over engineering looks like for a following problem statement: Problem Statement: Print "Hello World" 5 times. // Technique 1 : Can be written by a naive developer, but that is fine, code is functional print("Hello World") print("Hello World") print("Hello World") print("Hello World") print("Hello World") // Technique 2 : Better, here developer followed DRY principle ie Don't repeat yourself for (i=1;i<=5;i=i+1) { print("Hello World") } // Technique 3 : Much better, along with DRY developer kept in mind for new changes that should be done easily #define SIZE 5 for (i=1;i<=SIZE;i=i+1) { print("Hello World") } // Technique 4 : over engineering started, well in this case developer don't need to recompile the code when changes are there for SIZE, just need to update number in the config file int SIZE = ReadSizeFromAConfigurationFile("config") for (i=1;i<=SIZE;i=i+1) { print("Hello World") } // Technique 5 : too much over engineering, now developer is reading that SIZE from the backend, again this has great flexibility, but you can see too many things have been involved here int SIZE = ReadSizeFromTheBackend("some_server_url") for (i=1;i<=SIZE;i=i+1) { print("Hello World") } // Technique 6 : again too much over engineering, and developer is not following YAGNI principle, that's means requirement was saying print "Hello World", but developer written in a way that he/she can also change the string without any recompilation int SIZE = ReadSizeFromTheBackend("some_server_url") String s = ReadStringFromTheBackend("some_server_url") for (i=1;i<=SIZE;i=i+1) { print("\(s)") } For naive developers technique 6 can be over engineered... but for someone else it can be functional + maintainable code, also there is no standard definition of over engineering code...

Let me try to explain what is over engineering looks like for a following problem statement: Problem Statement: Print "Hello World" 5 times. // Technique 1 : Can be written by a naive developer, but that is fine, code is functional print("Hello World") print("Hello World") print("Hello World") print("Hello World") print("Hello World") // Technique 2 : Better, here developer followed DRY principle ie Don't repeat yourself for (i=1;i<=5;i=i+1) { print("Hello World") } // Technique 3 : Much better, along with DRY developer kept in mind for new changes that should be done easily #define SIZE 5 for (i=1;i<=SIZE;i=i+1) { print("Hello World") } // Technique 4 : over engineering started, well in this case developer don't need to recompile the code when changes are there for SIZE, just need to update number in the config file int SIZE = ReadSizeFromAConfigurationFile("config") for (i=1;i<=SIZE;i=i+1) { print("Hello World") } // Technique 5 : too much over engineering, now developer is reading that SIZE from the backend, again this has great flexibility, but you can see too many things have been involved here int SIZE = ReadSizeFromTheBackend("some_server_url") for (i=1;i<=SIZE;i=i+1) { print("Hello World") } // Technique 6 : again too much over engineering, and developer is not following YAGNI principle, that's means requirement was saying print "Hello World", but developer written in a way that he/she can also change the string without any recompilation int SIZE = ReadSizeFromTheBackend("some_server_url") String s = ReadStringFromTheBackend("some_server_url") for (i=1;i<=SIZE;i=i+1) { print("\(s)") } For naive developers technique 6 can be over engineered... but for someone else it can be functional + maintainable code, also there is no standard definition of over engineering code...

This is really nice that Team KISS did the project just in 120hrs (15 working days) and Team SOLID took 1500hrs ie around 6 months S:Single responsibility O:Open closed L:Liskov substitution I:Interface segregation D:Dependency Inversion I am just wondering which part took that much time, well they must be using S for writing isolated component or modules, also O for adding new features, not sure about L and I, but D also must be there for inverting the dependency. Can you please elaborate?

I am also having same problem. In iOS 17 below it is working fine. In iOS 17 if I remove modalPresentationStyle then I dont see any crash.

@Akshay271 UINavigationController. Try this: if (![viewControllerToPresent isKindOfClass:[UINavigationController class]]) { viewControllerToPresent.modalPresentationStyle = UIModalPresentationFullScreen; }