Building Large-Scale Apps With SwiftUI
Mohammad Azam (via Christian Tietze):
I have been experimenting with MV pattern to build client/server apps and wrote about it in my original article SwiftUI Architecture - A Complete Guide to MV Pattern Approach. In this article, I will discuss how MV pattern can be applied to build large scale client/server applications. […] The main idea behind the MV Pattern is to allow views directly talk to the model.
[…]
Based on Apple’s recommendation in their WWDC videos and code samples and my own personal experience, I have been implementing a single aggregate model, which holds the entire state of the application. […] Once, you have identified different bounded contexts associated with your application you can represent them in the form of aggregate models.
[…]
To prove that a View Model unit test does not verify user interface elements, simply remove the Button view or even the Text view from the ContentView. The unit test will still pass. This can give you false confidence that your interface is working.
Pet peeve: the parameters to XCTAssertEqual() should always have the actual value first and the expected value second.
I do not recommend testing Core Data with NSInMemoryStoreType because a lot of features don’t work with it, the performance characteristics are skewed, and having an actual file helps track down memory management bugs. I find that, with modern SSDs, using NSSQLiteStoreType with a temporary folder is fine, and there are various pragmas to make it go faster. If you really need in-memory, use /dev/null/DatabaseName as the file path.
Previously:
- Rewriting Remotion in SwiftUI
- Rewriting SoundCloud in SwiftUI
- SwiftUI Notes Before WWDC 2023
- Wallaroo and SwiftUI on macOS
- Wallaroo and SwiftUI on iOS
- Converting the Streaks Apple Watch App to SwiftUI
1 Comment RSS · Twitter · Mastodon
> Pet peeve: the parameters to XCTAssertEqual() should always have the actual value first and the expected value second.
100% agree
