feat: Added multiple backend support

[YazdanRa]

Note worthy comments

• Added multiple backend support: altool, transporter, appstoreapi (default to appstoreapi)
• AppStoreAPI backend can be used with ubuntu runners as well as macOS runners.
• Users may set uses-non-exempt-encryption to false if they wish to automate this process from AppStore Connect.
• Users may set wait-for-processing to false if they wish to skip the wait, this will disable the releaseNote and usesNonExemptEncryption settings.
• Since Transporter can now be installed in the a step in any macOS runner, users may now set transporter-executable-path to have more control.

Copilot Summary

This pull request introduces significant improvements and new features to the TestFlight upload GitHub Action, adding support for multiple upload backends, enhanced metadata handling, and improved documentation. The changes modularize the upload process, add new configuration options, and update dependencies to support new functionality.

Key changes:

1. Multi-backend Upload Support

• Refactored the upload process to support three different backends: appstoreApi (default), transporter, and altool, allowing users to select the preferred method for uploading builds to TestFlight. (src/main.ts, src/backends/types.ts, src/backends/appstore-api.ts, src/backends/transporter.ts, src/backends/altool.ts) [1] [2] [3] [4] [5]

• Added new inputs in action.yml to configure the backend, specify the path for the Transporter binary, and control processing/waiting behavior. (action.yml)

2. App Store Connect API Integration

• Implemented a robust upload flow using the App Store Connect API, including JWT authentication, chunked file uploads, and build processing polling. (src/auth/jwt.ts, src/backends/appstore-api.ts) [1] [2]

• Added automatic build metadata extraction and App Store Connect build lookup utilities. (src/backends/appstore-api.ts, src/buildMetadata.ts) [1] [2]

3. Improved Metadata Updates

• Enhanced TestFlight metadata update logic to handle release notes and encryption compliance settings, with retry logic for build visibility and localization readiness. (src/buildMetadata.ts, src/main.ts) [1] [2]

4. Documentation and User Guidance

• Updated the README.md with detailed backend usage instructions, including Transporter installation notes and new configuration options. (README.md)

5. Dependency and Output Updates

• Added new dependencies for IPA and plist parsing, and updated outputs to reflect the backend used for the upload. (package.json, action.yml) [1] [2]

[YazdanRa]

#138 , #139 should get resolved by this.

[thomasbach-dk]

FYI: I have created an issue here:

actions/runner-images#13389

[YazdanRa]

FYI: I have created an issue here:

actions/runner-images#13389

I was able to install the transporter in the runtime via the step provided in that issue. I documented it and updated the code to use the installed version instead of relying on xcrun.
Thank you so much for your help!

[thomasbach-dk]

Great job. But I wonder if supporting multiple upload tools is redundant since it's now an option to install Transporter to the runners in GH?

[YazdanRa]

Great job. But I wonder if supporting multiple upload tools is redundant since it's now an option to install Transporter to the runners in GH?

Good point. Supporting multiple upload tools might seem redundant now that Transporter can be installed on GH runners.

Still, the previous version needs an update to use the new executable path instead of xcrun. Beyond that, having multiple backends is useful. The download link always installing the latest version can break the action if something changes, or the link might disappear entirely. With alternative backends, the deploy can continue without waiting for a new hot fix.

I think of it as disaster-recovery insurance.

I was thinking about more optional configuration in a future PRs, like an optional fallback backend or setting the encryption for the build. The new architecture, makes these kinda expansions easier.

[Redth]

I'd argue that it still makes sense to add the App Store Connect API backend for this step. Yes, it looks like that obscure url to download transporter does work, but that feels a bit hacky and something that is likely to break in the future, not to mention there seems to be some ambiguity around which versions are supported on various macOS versions.

The web API is meant to be used like this and should remain stable.

Really appreciate your efforts here!

[YazdanRa]

@daveisfera

The PR got much bigger than what I would've liked it to be, but it has finally came together.

I have tested all three backends with official GitHub macos-latest image, as well as ubuntu-latest image with appstoreapi backend.

I probably need to update the documentation as well, please take a look at the changes and let me know if you have any feedback for me or any change is needed.

Thanks again and happy holidays! 🎄

[thomasbach-dk]

@daveisfera any chance that you can find time to review this? :) Thanks in advance!

[kazizi-tenzr]

Hi all, we are also looking for the transporter feature as well. Any idea when this PR would be merged?

[YazdanRa]

Tip

For the time being, you can use my repo (uses: yazdanra/upload-testflight-build@v1) in your step, this is a temporary solution until this PR gets merged.

- name: 'Upload app to TestFlight'
   uses: yazdanra/upload-testflight-build@v1
   with: 
     app-path: 'path/to/application.ipa' 
     issuer-id: ${{ vars.APPSTORE_ISSUER_ID }}
     api-key-id: ${{ vars.APPSTORE_API_KEY_ID }}
     api-private-key: ${{ secrets.APPSTORE_API_PRIVATE_KEY }}
     backend: AppStoreAPI # optional: AppStoreAPI | transporter | altool (default: AppStoreAPI; case insensitive)
     wait-for-processing: 'true' # optional: set to "false" to skip waiting (metadata updates will be skipped)
     release-notes: "Bug fixes and performance improvements."  # optional
     uses-non-exempt-encryption: 'false' # optional: "true" or "false" maps directly to App Store Connect usesNonExemptEncryption