Make Commet buildable and Runnable in macOS and iOS

[polemarkh]

This makes it possible to create commet desktop and iOS apps, and the iOS app is confirmed to pass App Store beta review.

[Airyzz]

Thanks, this is quite exciting!

Would you be able to setup actions to build for macos, as at this point I can't really test that this actually works, so that would be super helpful!

[polemarkh]

I think that's added an action that should (hopefully) build for Mac. I want to make sure that it works before I add one that builds for iOS.

[polemarkh]

My base status here is that the macOS build is failing, but it's failing because the base64 decode of the certificate (that I have as a secret) is failing, and I'm having trouble figuring out why it's failing. There may well be other bugs as well, but until this part is figured out, there's no good way to check that, because the runner never actually gets to the point where it's trying to build the macOS binary.

[polemarkh]

Okay, this is now at the point where the builds are working both locally and on GitHub, and the builds have been made configurable on GitHub. In particular, in order to successfully build, you will need the following repository variables:

• IOS_BUNDLE_ID: the bundle identifier for the commet iOS app (chat.commet.commetapp.quirt for me)
• IOS_BUNDLE_SERVICER_ID: the bundle identifier for the notification service component (I just set it to the bundle ID with ".notificationservice" appended to the end)
• MACOS_BUNDLE_ID: the bundle identifier for the commet macOS app (chat.commet.commetapp.macos for me currently)

You will also need to have the following secrets set and available:

• COMMET_IOS_MOBILEPROVISION: the base64-encoded iOS provisioning profile (.mobileprovision) file downloaded from the Apple developer website.
• COMMET_IOS_EXTENSION_MOBILEPROVISION: same, but for the iOS notification service extension
• COMMET_MACOS_PROVISIONPROFILE: same, but for the macOS app, and thus a ".provisionprofile" file instead of a ".mobileprovision" file.
• DEV_TEAM_ID: your developer team ID (the one that the provisioning profiles were created under)
• IOS_PROVISIONING_PROFILE_NAME: string value of what you named your mobileprovision on the apple developer website.
• IOS_EXTENSION_PROVISIONING_PROFILE_NAME: same but for the notification service extension
• MACOS_PROVISIONING_PROFILE_NAME: same but for the macOS version
• IOS_SIGNING_P12: The signing certificate attached to the iOS provisioning profile, exported in .p12 format, and base64-encoded.
• IOS_SIGNING_P12_PASSWORD: The password you set when exporting the above certificate
• MACOS_SIGNING_P12: The signing certificate attached to the macOS provisioning profile, exported in .p12 format, and base64-encoded. A different certificate because this certificate can be for distributing macOS apps outside of the Mac App Store, whereas there is no profile for distributing iOS apps outside of the App Store.
• MACOS_SIGNING_P12_PASSWORD: The password you set when exporting the above certificate
• KEYCHAIN_PASSWORD: The password you use to create the temporary keychain in the GitHub build workflow. It honestly doesn't matter what this is, because it's literally used as the password you need to set when making a local keychain, and then that keychain gets deleted at the end of the workflow, so it's never really called on for anything.

I realize that's a lot of things, but as the above extremely long list of commits probably indicates, figuring out how to properly prepare an app, whether macOS or iOS, how to get everything signed appropriately, and how to get flutter, GitHub, and Xcode to all work together when doing so, is complicated. And it all gets more complicated when trying to make it modular.

One note is that the iOS build is creating a ".ipa" file, which is the file that you would submit to the App Store, for either beta testing or release. As the build actions are currently configured, the version information comes from the pubspec.yaml file, as does the build number. It's possible to set them at build time, and you might want to do that in order to do releases that give you code products.

If there's anything in the above that isn't clear, I'm happy to answer questions.

[Airyzz]

Thanks so much for the massive effort! It will take me a while to look through everything, but this is really cool!

[polemarkh]

Okay, as you said it's a massive set of code, which means I forgot something. There's now a new GitHub environment variable, IOS_PUSH_GATEWAY, that will need to be set to a matrix push gateway that has the necessary keys installed for the app ID.

[MrRaph]

I'm really looking forward to testing this out!!

My macOS/iOS app building skills are really weak, I'll wait until the process is simplified! :)

[polemarkh]

@MrRaph if you would like to be added to the iOS TestFlight (or get a copy of the macOS application), let me know, and (for test flight) let me know an e-mail where you can receive a TestFlight invitation. Test reports are always welcome, and will make their way into this branch.

[MrRaph]

@MrRaph if you would like to be added to the iOS TestFlight (or get a copy of the macOS application), let me know, and (for test flight) let me know an e-mail where you can receive a TestFlight invitation. Test reports are always welcome, and will make their way into this branch.

I'll will be glad to test both :) Let's discuss about that on Matrix if you agree ! :) @mrraph_:chat.mrraph.fr