Building a Brand New iOS App
Welcome to the first in an ongoing series of posts from the Diamond Kinetics Development team!
We are proud to announce the launch of the brand-new Diamond Kinetics app! Reimagined from the ground up, we at Diamond Kinetics have had a unique opportunity to work from a clean slate to build a brand new iOS app from scratch using the latest Apple technologies. While we certainly leveraged our institutional knowledge, and some of our existing functionality, the opportunity to pivot towards a new audience has provided the space to take those learnings, leave behind any baggage, and deliver an application that takes advantage of the latest and greatest of what it means to be a modern iOS app.
Now that we’ve launched the brand new app, we thought it would be a good time to reflect on the process and share some of the learnings and experiences we gained in that effort. We’re excited to share our knowledge and hope it can help others contemplating a similar path.
Setting the Minimum OS Target
As any iOS developer who has supported an app in production for over a year, what version should the app set for the minimum OS target is one of the biggest questions that a team needs to answer. Year over year, the decision as to when to drop support for legacy version(s) of the operating system is a challenging decision that requires careful planning and a bit of risk assumption.
The development of the new DK our new app kicked off in December 2021. At the time, iOS 15 was still relatively new, and the market was still heavily reliant on iOS 14. The team was excited to explore SwiftUI, but as those who have been working in the iOS space since the launch of SwiftUI in iOS 13 in 2019 know, it’s been a bit of a moving target, as Apple hasn’t provided backward compatibility for any of the new features introduced each year. In that initial build-out, the team landed on a minimum version of iOS 14, which caused us to only be able to leverage the second iteration of SwiftUI. SwiftUI 2 was still relatively limited as compared to UIKit in functionality.
The limitations of the iterations of SwiftUI have felt very analogous to those limitations imposed by the early versions of Swift in the transition from Objective-C that iOS developers started undertaking starting in 2014 after Swift was announced as a new language. While the language wasn’t changing this time around, the paradigm switch from imperative to declarative-based UI development was a significant change of the mental model required to effectively develop using this new approach. To make things more challenging, there wasn’t feature parity between the existing UIKit APIs that have been well-established for many years and the new APIs that SwiftUI provided. These gaps made it hard to make the complete transition by allowing us to stay in a declarative SwiftUI mindset, much like the Bridging Header provided a means to pull in Objective-C code over to Swift during that transition, but forced us developers to keep one foot on each side of the dividing line between the technologies.
By late spring 2022, however, we knew we wanted to move forward, so we decided to jump up to iOS 15 as a minimum and unlock the ability to use the third iteration of SwiftUI. That added some new functionality but still limited our options to build a fully functional app, especially around programmatic navigation.
Then, as the iOS 16 betas started to roll out last summer, in the wake of WWDC 2022, we expected that we’d follow the standard practice of “N-1” where we would support the current version of iOS (16) and the previous version (15) for our initial launch. Once our true timeline came into focus, and we knew we weren’t going to launch until early 2023, we expected the pattern of iOS version adoption to mirror previous years and the vast majority of users would have migrated to iOS 16. Given that there were some features of the iOS 16 and SwiftUI 4 APIs (that we’ll discuss below) that we wanted to take advantage of, we decided to take the plunge and drop iOS 15 support earlier than originally expected and focus entirely on iOS 16.
This wasn’t a decision without risk. Unlike iOS 14 and 15, iOS 16 did sunset some previously supported devices, cutting off support for all iPhones before the iPhone 8, 8 Plus, and X that were released in 2017. Even though we are currently only directly supporting the iPhone, our app does run on iPads and there are several longer-tail models still in circulation given that iPads tend to hold their technical value longer than the phones released in the same year. Also, with our intended market being youth baseball and softball players, it seemed more likely that those kids would have hand-me-down devices from their parents that were those older models that Apple would be sunsetting with iOS 16.
That said, we decided that there were actually benefits to have to support fewer devices and operating systems out of the gate. Besides opening up the newer APIs of iOS 16 without having to worry about backward compatibility, it simplified other places in the code where we might have had to check what version of the OS the device is running. Even more important, however, was to limit the amount of testing necessary to ensure a quality product. We are a small team here at DK, and not having the geometric explosion of possible device and OS combinations helped us focus our efforts on testing those devices that do run iOS 16 more thoroughly.
Going forward, we do expect that we will have to follow the “N-1” best practice now that we have iOS 16 users in the market when iOS 17 inevitably drops later this year, but even delaying that extra level of support will help us in the short term. In the future, depending on when Apple deprecates other hardware, we may make a similar aggressive deprecation decision as well. We’ll need to evaluate where our active and paying users are on the upgrade cycle then, but we know that not having to carry any extra development or testing baggage is ideal for our productivity.
SwiftUI
As previously mentioned, the DK iOS team has been excited to explore and experiment with SwiftUI, especially the latest changes in iOS 16. It is clear that declarative programming, especially when it comes to user interfaces, is the future. In fact, it is quickly becoming the present, as demonstrated not only by SwiftUI, but JetPack Compose on Android, and React on the web. Apple has been telegraphing its plans to grow support for declarative programming with the ongoing push into SwiftUI with the changes year over year for the past four releases across all their platforms.
In some of the earliest efforts that went into the new Diamond Kinetics app the team was still using a mix of SwiftUI and UIKit, but it didn’t make good strategic sense to intermingle declarative and imperative UI code across the same code base. As the formative architecting and implementation took place while we were still on iOS 15 as the minimum version, it was decided we would separate the individual views from the navigation code, given that SwiftUI 3 that iOS 15 provides didn’t have a robust solution to programmatic navigation. Thankfully Apple’s forethought provided us with UIHostingControllers with which we could wrap our SwiftUI views. This allowed us to use UIKit navigation patterns that were well-known, predictable, and flexible while moving the user-facing portions of the UI code to SwiftUI. Our SwiftUI-based views were able to leverage SwiftUI Previews and the Canvas feature of Xcode, which was essential in the early days of app development as we were building screens without a home to display them from. As development commenced in earnest in the fall of 2022, we settled into using a Model-View-ViewModel (MVVM) approach backed by a Coordinator/Router pattern for navigation.
All that being said, we still have run into some challenges with this approach. The Coordinator/Router pattern muddied the waters as it somewhat obfuscated the model. We had some confusion around how to separate concerns between the view model and the view, and where tests added the most value. Going forward, especially since we can take advantage of the navigation patterns in SwiftUI 4 given that we’ve raised our minimum OS version to iOS 16, we expect we’ll be exploring replacing our Coordinator and Router with SwiftUI navigation using the NavigationPath-capable views. This will allow us to set up NavigationStacks and eventually NavigationSplitViews when we directly support the iPad platform.
SwiftUI Charts
While there was a lot to like about SwiftUI 4 coming out of WWDC 2022, the one thing that stood out to the DK team was Swift Charts. At its core, Diamond Kinetics has been about data and communicating information. Our existing SwingTracker and PitchTracker apps were built on top of some serious data visualization that allowed more experienced players to evaluate their swinging and pitching performances. As we conceived of the new Diamond Kinetics app that is targeted towards a younger audience, we wanted to be able to draw graphs and visualizations that were easy to see and understand, especially from a distance on a smaller iPhone screen.
It quickly became apparent that SwiftUI Charts were going to open a lot of doors and clear a path to deliver on that vision. Not having to build all those components from scratch simplified the delivery for the development team. Since they were SwiftUI native, they were easy to instantiate and ensure they were going to resize to fit the available space without too much manual intervention. We were able to repurpose those same components in both our Open Sessions
and Guided Sessions
Being able to leverage SwiftUI Charts across the entire install base and not have to worry about previous versions of the OS further cemented our decision to target iOS 16 as the minimum OS version for this new app. We look forward to further building on top of SwiftUI Charts as we continue to evolve the Diamond Kinetics app in the future.
What’s Next for DK
Like any new app, we are super thrilled to get it into the hands of our users. We are also looking forward to the next round of iOS improvements that are inevitably coming at WWDC 2023 and will launch this fall. We are also looking to expand to additional Apple platforms, such as Apple TV (tvOS) for building a 10-foot UI that may be useful in a batting or pitching cage to improve the experience at facilities to augment the personal experience on mobile. We have some interesting ideas around Apple Watch, but we’re not sure how excited users will be to wear their watch when facing live pitching. All that being said, we look forward to sharing our discoveries and learnings as we continue to grow this app. Keep checking back on this blog for more soon!
