Native Multi-platform Game: Data Handling (11 of …)

With game testing almost done, I am behind on implementing data integration for reports, dashboard and assignments. My original plan was to try and do this in a re-usable cross-platform way. However, given the complexity of handling server connectivity and that Firebase has great documentation on iOS, but, not multi-platform Kotlin, I decided to stick to the well-treaded path and build it as a reusable framework in Swift. It will be simple to replace it with a common Kotlin module if/when Firebase provides a multi-platform Kotlin library to do so.

Keeping in mind that I may do a common implementation later, I put the data model in the common module in Kotlin, and defined a common Data Handling interface there too.

interface DataHandler {
    fun login()
    fun logout()
    ...
}

Then, I created a separate library in Xcode using Swift to implement the data handling interface. Kotlin-Native automatically prepends the three letter acronym (GDK) for our common framework to class definitions. So, we access the Kotlin interface DataHandler from Swift as GDKDataHandler.

public class FirebaseDataHandler: GDKDataHandler {
    func login() {
        ...
    }
    func logout() {
        ...
    }
    ...
}

My iOS project structure is growing with separate libraries for games, data, shared screens, and then one app each for Kindergarten, 1st and 2nd grade to put it all together for publishing:

Next part was setting up Firebase SDK. As usual, this was the hard part, with many problems e.g. Pods did not work for Firebase SDK setup, since I am not using workspaces, only xcode projects. So, I added it manually as a static library. Initially I put the frameworks and .h and modulemap files in separate folders from the frameworks, which did not work. Putting them all in the same folder, and adding that folder to the User Header Search paths for both the data framework and the kindergarten math app project worked. The Firebase.configure() call worked after putting the Google services plist file into the data framework (Note: By dragging and dropping it into the data framework project, it is automatically added to the copy resources phase of the build).

We had previously used Google Single-sign-on for our project. It made sense for Android, but, I prefer a more open system for iOS. Fortunately, Firebase recently introduced email-link authentication. The email-link-auth also verifies the email during login, and automatically ties together new logins to user accounts previously created using Google Single-sign-on. This means that existing customers can login using the same email on iOS and see the same reports, dashboards, assignments etc. on either device. Eventually, I plan to replace Google Single-sign-on with email link authentication on Android as well. It is safer for kids, since parents must access their email to login.

With this plan, I had to repeat the Firebase implementation code in iOS, but, given that our data model is not complex, it was the best approach at this time. Next, I will add subscription purchase for the iOS app and we will be ready to publish our first app to iOS.