/standups

A rebuild of Apple’s “Scrumdinger” application using modern, best practices for SwiftUI development.

Primary LanguageSwiftMIT LicenseMIT

Standups

This project demonstrates how to build a complex, real world application that deals with many forms of navigation (e.g., sheets, drill-downs, alerts), many side effects (timers, speech recognizer, data persistence), and do so in a way that is testable and modular.

This application was built over the course of many episodes on Point-Free, a video series exploring functional programming and the Swift language, hosted by Brandon Williams and Stephen Celis.

video poster image

Call to action!

While we have built the Standups application in the style that makes the most sense to us, we know that some of our choices aren’t for everyone. We would love if others fork this repo and rebuild it in the style of their choice.

Don’t like to use an ObservableObject for each screen? Prefer to use @StateObject instead of @ObservedObject? Want to use an architectural pattern such as VIPER? Have a different way of handling dependencies?

Please show us! Just complete the following steps:

  1. Fork our repo and rebuild the app any way you see fit. If you want to start with Apple’s code rather than ours, you can download it here.
  2. Update the Readme.md to describe your choices in rebuilding the app (see below for ours).
  3. Open a PR to this repo where you add a link to your port in this readme.

We will collect links to the other ports so that there can be a single place to reference many different approaches for building the same application.

Overview

The inspiration for this application comes Apple's Scrumdinger tutorial:

This module guides you through the development of Scrumdinger, an iOS app that helps users manage their daily scrums. To help keep scrums short and focused, Scrumdinger uses visual and audio cues to indicate when and how long each attendee should speak. The app also displays a progress screen that shows the time remaining in the meeting and creates a transcript that users can refer to later.

The Scrumdinger app is one of Apple's most interesting code samples as it deals with many real world world problems that one faces in application development. It shows off many types of navigation, it deals with complex effects such as timers and speech recognition, and it persists application data to disk.

However, it is not necessarily built in the most ideal way. It uses mostly fire-and-forget style navigation, which means you can't easily deep link into any screen of the app, which is handy for push notifications and opening URLs. It also uses uncontrolled dependencies, including file system access, timers and a speech recognizer, which makes it nearly impossible to write automated tests and even hinders the ability to preview the app in Xcode previews.

But, the simplicity of Apple's Scrumdinger codebase is not a defect. In fact, it's a feature! Apple's sample code is viewed by hundreds of thousands of developers across the world, and so its goal is to be as approachable as possible in order to teach the basics of SwiftUI. But, that doesn't mean there isn't room for improvement.

Modern SwiftUI

Our Standups application is a rebuild of Apple's Scrumdinger application, but with a focus on modern, best practices for SwiftUI development. We faithfully recreate the Scrumdinger, but with some key additions:

  1. Identifiers are made type safe using our Tagged library. This prevents us from writing non-sensical code, such as comparing a Standup.ID to a Attendee.ID.
  2. Instead of using bare arrays in feature logic we use an "identified" array from our IdentifiedCollections library. This allows you to read and modify elements of the collection via their ID rather than positional index, which can be error prone and lead to bugs or crashes.
  3. All navigation is driven off of state, including sheets, drill-downs and alerts. This makes it possible to deep link into any screen of the app by just constructing a piece of state and handing it off to SwiftUI.
  4. Further, each view represents its navigation destinations as a single enum, which gives us compile time proof that two destinations cannot be active at the same time. This cannot be accomplished with default SwiftUI tools, but can be done with our SwiftUINavigation library.
  5. All side effects are controlled. This includes access to the file system for persistence, access to time-based asynchrony for timers, access to speech recognition APIs, and even the creation of dates and UUIDs. This allows us to run our application in specific execution contexts, which is very useful in tests and Xcode previews. We accomplish this using our Dependencies library.
  6. The project includes a full test suite. Since all of navigation is driven off of state, and because we controlled all dependencies, we can write very comprehensive and nuanced tests. For example, we can write a unit test that proves that when a standup meeting's timer runs out the screen pops off the stack and a new transcript is added to the standup. Such a test would be very difficult, if not impossible, without controlling dependencies.

Ports

Here is a list of ports of the app: