Introduction
Godtear released off of a successful Kickstarter campaign around the beginning of December 2019. As someone who bought into the Early Access kit, I had already committed myself as a fan of the game.
Fast-forward to me receiving my Chosen Pledge in the mail—I didn't get the Ascended Pledge since I have the Early Access models—and I realized I didn't have the production cards for the models in the Early Access kit...
A normal person would have just printed the cards, but I decided this would be a good opportunity to learn something new and make something cool.
Motivation
This project is me officially dipping my toes into mobile development waters. I chose to get into the weeds with Kotlin/Native + Multiplatform for this project rather than developing for Android and iOS natively. Kotlin/Native + Multiplatform are extremely experimental projects at the moment, but they have the potential to really shake-up the mobile development world—I want to be ahead of the curve.
Progress
I started by rendering a UITableView natively for iOS and a RecyclerView natively for Android. I did this to understand what I'd be working with for the view model (since this is all new technology for me). Additionally, selecting a Cohort row would display the selected cards. This is fine and dandy and could be released, but I'm not happy with it (also, I've been trying for a month to get Apple to approve my Developer account). From here, I'm working backwards to port business logic and project structure over to Kotlin/Native according to "Uncle Bob's" Clean Architecture.
A note on mobile architecture
The mobile development community seems to have this notion that MVC, MVP, MVVM, VIPER and Clean Swift are forms of architecture rather than simply design patterns. These patterns taken as architecture create a lot of messy projects out on GitHub. There is no one-size-fits-all template for clean architecture. If you look at the sample project provided by Clean Swift, you'll see dependencies all over the place.
Uncle Bob's Clean Architecture
Clean Swift's "Clean Architecture"
As you can see, Clean Swift completely bypasses architectural boundaries. UIKit as well as each application module depend directly on the data models—this is not clean architecture, it's spaghetti. If one makes a change to the data models in this project, they potentially break the functionality along every layer. In my opinion, this is code re-use and DRY (don't repeat yourself) taken too far. You are sacrificing clean architecture and easily testable, modular code for a shared data model. This is the sort of thing that gives object-oriented programming a bad name.
Concluding thoughts on mobile architecture
I'm struggling to apply my existing knowledge to the mobile development world in a way that works with Kotlin/Native + Multiplatform, but I'm not stuck. I am making progress, it's just taking experimentation.
Conclusion
While this app is simple enough for now, I want to have a solid project base before I release anything. I know you're all excited, but I promise this will pay off in the long-run. A well-architected project that shares code between both Android and iOS opens a lot of doors for this app in the future. A modular design lends itself to collaboration—different people can work on different things at the same time and not create conflicts in the codebase. Don't like the way something is implemented? No problem, just replace that module and be rest-assured it doesn't break any other piece of code. By separating the business logic from the UI implementations, I can also rely on people much more skilled than I to contribute to making the UI slick.
Release 1.0 estimate
I expect to have a simple 1.0 version of the app finished within this week. From there, it's just a matter of polish and waiting for the App Store and Play Store to accept my submissions. Thanks for reading this far and thank you for all your support.
-Nick