jamulussoftware
Automate build of iOS signed ipa file for App Store submission
This PR adds automation to create a signed ipa (installer) file for direct submission to the iOS App Store.
CHANGELOG: adds iOS signed pkg build automation
Context: automates building of signed pkg file for iOS App Store
Does this change need documentation? What needs to be documented and how?
Required:
- In Apple Developer Account, create the following resources in in https://developer.apple.com/account/resources/certificates/list
-
Certificates:
- iOS Distribution
-
Identifier:
- app ID (bundleID)
-
Profile:
- iOS Distribution (AppStore) - ProvisioningProfile
- Add the certs and provisioning profile to Github Secrets as per https://docs.github.com/en/actions/deployment/deploying-xcode-applications/installing-an-apple-certificate-on-macos-runners-for-xcode-development
Status of this Pull Request
What is missing until this pull request can be merged?
Checklist
- [x] I've verified that this Pull Request follows the general code principles
- [x] I tested my code and it does what I want
- [ ] My code follows the style guide
- [ ] I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
- [ ] I've filled all the content above
@danryu The CI failed. We currently don't have a valid cert on this repo.
Ok I've pushed a fix now to check for the cert non-zero value before attempting to move the signed IPA for download. This should resolve this CI failure where there is no valid cert in place.
Please note also that if signing is requested and dependencies are satisfied, the script will now attempt to validate and upload to App Store using the existing NOTARIZATION_USER and NOTARIZATION_PASSWORD. We may need to fine-tune this behaviour if eg re-uploading the same version (eg 3.9.0) to the App Store repeatedly (I think it will fail rather than updating the existing similar version). Let me know what you think should happen in this case.
Hmm. I think the upload should only happen if we have a release build (there's a GitHub variable for that, I think). Look for the variable which enables/disabled uploading to GitHub releases.
Ok, the Github release stuff switches on needs.create_release.outputs.publish_to_release == 'true' - so maybe I should add a separate extra step in autobuild.yml for iOS App Store upload - after the Notarization and Staple steps perhaps?
Then I can split out the validate and upload stages from the main build run, which seems sensible.
I'm working on adding the extra step now.
Also: I've noticed that the iOS App Store upload validation (to appear in TestFlight in App Connect) requires an images assets catalog in a directory entitled Images.xcassets - I have this working in branch CI as a subdir of ios. However the asset catalog is a collection of ~26 files, normally generated by XCode or another utility. I'm thinking of integrating a tool like https://github.com/alfianlosari/AppIconGenCLI, which would then mean we just have to include a single 1024x1024 png file to generate all the others, and saving us from putting all 26+ files in source control.
I think both approaches have advantages and disadvantages (another CI job vs more data in the repo). Any other comments on this @ngocdh @emlynmac
Hi @ann0see yes, I have Store submission working as part of the release procedure (also for macOS for the other PR). I just need to confirm what the desired behavior is before updating the PR. Do we still want to keep the unsigned IPA if the signed one is generated?
Can the signed ipa be re-signed for debugging? If yes, no need to have the unsigned ipa. Else just provide the unsigned one and upload the signed one to Apple.
I'm actually not 100% sure on that point, so I will keep the unsigned IPA for now, to not break the existing pattern.
I am re-assessing this PR in the light of errors that I get when running apps in TestFlight, that have been built and submitted by this automation. The app builds fine and is validated and accepted by TestFlight - but when the app actually starts it quits immediately with a SIG11 error. This does NOT happen when the same build and submission is carried out locally on macOS/XCode. I will update this PR when I have worked out the reason for the CI failure.
Strange. Do you use Qt5?
No, Qt 6.3.2 and actually 6.4.0 for iOS (for some touch-handling fixes).
It is indeed very strange - after all, if TestFlight validates the package, one would expect it to run! I suspect it may be related to something like the handling of Bitcode in the build, or something equally obscure.
Incidentally, the result is the same when I use a dedicated Github Action for iOS building - yukiarrr/[email protected] - which I think might be the simplest way of doing iOS builds going forward.
Yes, the iOS build crashes with Qt6 for me too (at least on GH actions). It's a known issue with Qt6
https://github.com/jamulussoftware/jamulus/issues/2711
Yes, the iOS build crashes with Qt6 for me too (at least on GH actions). It's a known issue with Qt6
#2711
Hmmm, I think I may have fixed that particular issue by including this in .pro file for iOS:
QMAKE_LFLAGS += -Wl,-e,_qt_main_wrapper
Though I don't have the reference for the fix to hand. With this in place, I've been building and running the iOS app for several months, with Qt 6.3.2 and now 6.4.0. However, within the last 4-6 weeks (roughly), TestFlight has been validating and accepting the CI iOS builds, only to have them crash with SIG11 on startup. I spent considerable time building from historical commits, exactly replicating previous configurations - but couldn't shake the error. To me it seems like an opaque change in how TestFlight is handling the builds in each case - very frustrating. The workaround currently for me is to do the local XCode build as mentioned.
Please check and try the Koord app in the iOS App Store for proof that Qt6 works fine with iOS :)
Koord app
Great. That's a modified Jamulus client I suppose? If you plan to maintain your app and keep it compatible and up to date, we could link it as Jamulus compatible 3rd party App here in the KB: https://jamulus.io/kb/2022/03/04/Alternative-Install-Methods.html
Great. That's a modified Jamulus client I suppose? If you plan to maintain your app and keep it compatible and up to date, we could link it as Jamulus compatible 3rd party App here in the KB: https://jamulus.io/kb/2022/03/04/Alternative-Install-Methods.html
That would be great! We definitely intend on maintaining it :) and also keeping upstream compatibility! https://github.com/koord-live/koord-app We are a few months behind upstream master, and that will be merged in shortly.
There are a few points of interest in the app - but I might open a quick Discussion for that!
Adding this stackoverflow post as reference for the new flags: https://stackoverflow.com/questions/45508043/qt-ios-linker-error-entry-point-main-undefined