Wednesday Mar 17, 2021
A few months ago we announced that we were working on a new project, a word game for iOS, and we’ve even been giving little peeks at the code base in recent episodes of Point-Free. Well, we’ve now officially launched the app on the App Store and we are simultaneously open sourcing the entire code base!
isowords is a large, complex application built entirely in Swift. The iOS client’s logic is built in the Composable Architecture and the UI is built mostly in SwiftUI with a little bit in SceneKit. The server is also built in Swift using our experimental web server libraries.
The code base is currently over 45k lines of code, for both the iOS client and server, and employs a number of techniques that have been discussed on Point-Free. Here’s just a small sample of some things you might be interested in:
The whole application is powered by the Composable Architecture, a library we built from scratch on Point-Free that provides tools for building applications with a focus on composability, modularity, and testability. This means:
Reducer, which is composed out of many other reducers.
There are a ton of benefits to designing applications in this manner:
ObservableObjectinstances, but this is not necessary in the Composable Architecture.
UserNotifications, or any other 3rd party APIs in your code, it doesn’t mean you should sacrifice your ability to run your app in the simulator, SwiftUI previews, or write concise tests.
The application is built in a hyper-modularized style. At the time of writing this README the client and server are split into 86 modules. This allows us to work on features without building the entire application, which improves compile times and SwiftUI preview stability. It also made it easy for us to ship an App Clip, whose size must be less than 10 MB uncompressed, by choosing the bare minimum of code and resources to build.
The code for both the iOS client and server are included in this single repository. This makes it easy to run both the client and server at the same time, and we can even debug them at the same time, e.g. set breakpoints in the server that are triggered when the simulator makes API requests.
We also share a lot of code between client and server:
The screenshots and preview video that we upload to the App Store for this app are automatically generated.
The screenshots are generated by a test suite using our SnapshotTesting library, and do the work of constructing a very specific piece of state that we load into a screen, as well as framing the UI and providing the surrounding graphics.
The preview video is generated as a screen recording of running a slimmed-down version of the app that embeds specific letters onto a cube and runs a sequence of actions to emulate a user playing the game. The app can be run locally by selecting the
TrailerPreview target in Xcode and running it in the simulator.
There are times that we want to test a feature in isolation without building the entire app. SwiftUI previews are great for this but also have their limitations, such as if you need to use APIs unavailable to previews, or if you need to debug more complex flows, etc.
So, we create mini-applications that build a small subset of the 86+ modules that comprise the entire application. Setting up these applications requires minimal work. You just specify what dependencies you need in the Xcode project and then create an entry point to launch the feature.
For example, here is all the code necessary to create a preview app for running the onboarding flow in isolation. If we were at the whims of the full application to test this feature we would need to constantly delete and reinstall the app since this screen is only shown on first launch.
Check out and explore the isowords code base today. We have a lot more Point-Free episodes coming soon that dive into some of the more advanced aspects of the code base, such as API client design, integration testing, onboarding flows, automatic trailer creation and more! 😅
Also, be sure to download isowords and share with friends 😁: