Improved documentation (and potentially tooling) around iOS/Android deployment

Hi!

I’ve noticed that a disproportionate amount of questions in the Discord are centered around setting up mobile deployment. Both the current GameCI deployment docs and Fastlane’s own documentation assume strong familiarity with the iOS and Android codesigning and build processes, moreso than e.g. what the unity-builder docs assume about the Unity build pipeline. A lot of game devs hoping to deploy their GameCI-powered builds to iOS and Android don’t have that familiarity. Bridging that knowledge gap could do a lot to reduce dev confusion, and I’d love to help with that.

On a basic level, I think it makes sense to revamp the GameCI mobile deployment docs (iOS and Android on both GitHub and GitLab) to provide a more explicit introduction to Fastlane, walking through how to set it up for a given platform in more detail than the docs currently do. I’m happy to take a stab at a draft of this, provided there’s interest.

Additionally, I have a proof-of-concept project (https://github.com/lazerwalker/boatattack) that uses GH Actions to completely manage the iOS codesigning process, including doing initial certificate generation on a Mac runner without requiring manually operating a physical Mac. I’m in the process of adapting this to something more composable, most likely a set of Actions to generate codesigning certificates and store them in a git repo via match, build and codesign an iOS or Android project generated by Unity, and upload builds to TestFlight/App Store/Google Play. These would be mostly pre-configured “it just works” actions with a few configuration points, with additional direct access to the underlying code so people who want to fork and more heavily customize can do so beyond what you would expect from Actions parameters.

In short, this work aims to abstract away knowledge of Fastlane for happy-path scenarios, the same way the unity-builder action does for Unity’s command-line interface.

I’m wondering if this is something that might potentially be worth including as “part of GameCI” (hosting the Actions in the GameCI GH org, and hosting docs on the main site). Technically, this isn’t Unity specific, it’s just a set of wrappers around Fastlane. But providing this tooling will be particularly valuable to game devs without iOS/Android native dev experience, and I think there’s a great deal of discoverability value in having it live under the GameCI branding umbrella instead of off to the side.

So, I really have two questions:

1. If I were to put together a draft of updated deploy docs that were more targeted at folks unfamiliar with the iOS/Android codesigning processes or Fastlane, would that be welcome?
2. Is there tentatively interest in those mobile codesigning- and deployment-focused Actions? I’m obviously not expecting a firm answer when I can’t yet point to concrete code, and there are questions around future maintenance plans, etc, but it would be good to get a general sense if this is something people think would even remotely be a fit for the GameCI org. Especially since any updates to the existing deployment docs would likely differ based on whether or not we have a more streamlined workflow to recommend to newcomers.

Let me know your thoughts!

[lazerwalker]

Re: linking to a getting started guide, I think what’s tricky is the Fastlane documentation is (reasonably and correctly!) speaking to an audience of iOS and Android devs, which is an assumption we can’t make. I’m proposing that I take a stab at a new “getting started” guide that assumes a Unity dev with no knowledge of Xcode or Android Studio.

I have answers to a lot of those (legitimately hard, important, and open-ended!) questions about how I think a set of happy path Fastlane actions would work, what can and can’t be streamlined, and what the correct abstraction level is. But it seems to me like we’re already at a point where me showing off working actions would be infinitely more productive than going back-and-forth here😅. Will loop back later on that when I have more to show.

[lazerwalker]

Cool, to just keep updating in here, I took a stab at combining those two workflows into one, and the act of doing it made me realize it’s a bad idea. It’s totally doable, but combining the two into one workflow means you still need a separate workflow to run once a year (or whatever) in order to regenerate certificates, since the init script fails out if it’s already configured (and modifying that behavior would be doable, but probably inadvisable for a number of reasons).

At this point, I strongly suspect my one remaining action item is taking my two initialization workflows as-is (one that configures a Match repo, one that generates certs) and adding a section or two to the iOS deployment docs that includes those workflow files and explains how to use them.