A few months ago I launched Planning Cards, an app designed to help Agile teams during their backlog refinement sessions. The app is very simple. The premise of the app is that users select a card and tap again to reveal the value to their team. Software engineers working in Agile teams do this very frequently to assign chunks of work value based on development effort. Teams usually use tools such as physical cards which can be limiting, especially if your team isn’t using a standardized point-system or if you forget to bring your card deck to the meeting. I’ve personally used some apps for this purpose but sometimes wanted to use my Apple Watch without having to bring my phone to the meeting. I also wanted custom card decks. Therefore, I decided to develop Planning Cards.
This post is going to be a broad overview of the application. To best understand how the application works feel free to look at the source code, which is available here.
Since I wanted to use Apple’s latest native tech stack, I ended up using SwiftUI for both the iOS app and the watch extension. This allowed me to share a few UI components between both platforms. I also used Grid, a SwiftUI library, to display the cards in a grid layout.
To store the custom deck data I used CoreData and set up relationships between cards and decks. CoreData allowed me to use FetchResultControllers in my SwiftUI views. Using FetchResultControllers is handy since SwiftUI handles the data to show and automatically updates it if the values change in CoreData. To store the user settings, I used UserDefaults.
To synchronize the custom deck data to the watch, I used WatchConnectivity and UserDefaults. WatchConnectivity was used to send the deck data from the iOS to the Apple Watch app. Since the Watch app only cares about the currently selected deck, it doesn’t need to know about any of the other decks that the user has created. That being said, we can use a simpler solution for storing the deck data on the watch app. This is why the watch app uses UserDefaults and doesn’t use CoreData.
Wanting to reach as wide of an audience as possible, Planning Cards is localized in English, Danish, German, Japanese, and Simplified Chinese.
If you check the automated UI Tests they include configuration for Fastlane’s Snapshot tool. This makes it easy to capture all the screenshots in all our 5 localizations. I also used Fastlane’s deliver tool to store my metadata. This could be helpful in the future when wanting to submit a future version of the app, so we won’t have to retype unchanged information in App Store Connect between all the different locales.