fastlane: [pilot] fails to upload build to TestFlight using api key after iTMSTransporter auto updated to version 3.0.0 with `An exception has occurred: issuerId is required` error

I had the same problem.

In my environment, the upload was successful after setting the following environment variables.

ENV['ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD'] = 'true'

Set the environment in the shell or shell script:

#!/bin/bash
export ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true
bundle exec fastlane ios lane_that_calls_pilot

or set it on the command only:

ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true bundle exec fastlane ios lane_that_calls_pilot

It worked for me.

I used this combination:

👍 Xcode 13.4.1 - uploaded with ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true before upload 👎 Xcode 13.4.1 - fail to upload without ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true

👎 Xcode 14.0.1 - fail with ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true before upload 👍 Xcode 14.0.1 - uploaded without ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true

fastlane 2.210.1

Same on bitrise. Add this to your Env vars:

I do wonder why Apple keeps constantly breaking their build tools… Android has no such problem and has been stable for years.

Clearing the cache in the path helped us: /Users/<username>/Library/Caches/com.apple.amp.itmstransporter

base on my test, this update works

build_app(xcargs: "-allowProvisioningUpdates", workspace: "Unity-iPhone.xcworkspace", scheme: "Unity-iPhone")
     
// add this line before the pilot
ENV['ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD'] = 'true' 

pilot(
)

Same issue here with:

• Bitrise CI
• Xcode 14.0.1
• Fastlane 2.210.1

Could not determine the package’s bundle ID. The package is missing an Info.plist or the CFBundlePackageType is not ‘APPL’ or ‘FMWK’. Unable to validate your application.

Solved by settings ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD = false

I am using Xcode 14.1 Fastlane 2.211.0

and explicitly setting ENV['ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD'] = 'false' in Fastfile fixed the issue for me.

github actions Something like this i think:

env:
          ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD: true

ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true failed on Xcode 14

[05:59:38]: Could not determine the package’s bundle ID. The package is missing an Info.plist or the CFBundlePackageType is not ‘APPL’ or ‘FMWK’. Unable to validate your application. (-21017) На 13ом без флага An exception has occurred: issuerId is required [11:05:50]: [iTMSTransporter] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [11:05:50]: [iTMSTransporter] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) [11:05:50]: [iTMSTransporter] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) [11:05:50]: [iTMSTransporter] at java.base/java.lang.reflect.Method.invoke(Unknown Source) [11:05:50]: [iTMSTransporter] at com.apple.transporter.bootstrap.BootstrapperPhase1.bootstrap(BootstrapperPhase1.java:107) [11:05:50]: [iTMSTransporter] at com.apple.transporter.bootstrap.BootstrapperPhase1.bootstrap(BootstrapperPhase1.java:78) [11:05:50]: [iTMSTransporter] at com.apple.transporter.launcher.Launcher.launchBootstrapper(Launcher.java:37) [11:05:50]: [iTMSTransporter] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [11:05:50]: [iTMSTransporter] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) [11:05:50]: [iTMSTransporter] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) [11:05:50]: [iTMSTransporter] at java.base/java.lang.reflect.Method.invoke(Unknown Source) [11:05:50]: [iTMSTransporter] at com.apple.transporter.launcher.Application.start(Application.java:450) [11:05:50]: [iTMSTransporter] at com.apple.transporter.launcher.Application.main(Application.java:947) [11:05:50]: [iTMSTransporter] [11:05:50]: [iTMSTransporter] [2022-10-18 11:05:50 MSK] <main> DBG-X: Returning 1 [11:05:50]: iTunes Transporter output above ^

@Lascorbe You can take a look in code, I didn’t found any other doc. https://github.com/fastlane/fastlane/search?q=ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD My guess is that the cli invocation differs .

Remember to remove the ENV['ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD'] = 'true' now once you have upgraded, or you will face this error instead:

[11:32:59]: [altool] NSLocalizedDescription = "Could not determine the packages bundle ID. The package is missing an Info.plist or the CFBundlePackageType is not APPL or FMWK.";

As @henderson2350 said. Add the following line to fastfile fix the issue.

ENV['ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD'] = "true"

Where in Fastfile this line should be added?

I’ve just added at the beginning of my deploy's lane

Thanks

Alright - I traced and modified some code to make the upload work for my case, but very brute force like and inelegant due to me not knowing exactly how things work.

Summary of my findings (for my broken case - using Xcode 13 and API Key):

• I don’t want to force ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD to true because this causes, for reasons unknown, validate to fail in the transporter - similar to what’s discussed in #19572
• If I don’t set ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD to true, we’re back to the original issuerId is required; the reason this error is happening seems to be because the following command is being executed: xcrun iTMSTransporter -m upload -jwt YourJWT -assetFile /var/folders/sg/c0tzk72j58s8pbfbzxpp1hkc0000gn/T/74acf81b-00e8-46d0-b5e4-b434e1e2b194.ipa -k 100000 2>&1

Notice the above command references a JWT (which I don’t use) and doesn’t pass in the apiKey.

diff --git a/fastlane_core/lib/fastlane_core/itunes_transporter.rb b/fastlane_core/lib/fastlane_core/itunes_transporter.rb
index d785b792f..8b46047a6 100644
--- a/fastlane_core/lib/fastlane_core/itunes_transporter.rb
+++ b/fastlane_core/lib/fastlane_core/itunes_transporter.rb
@@ -373,9 +373,6 @@ module FastlaneCore
       [
         '"' + Helper.transporter_path + '"',
         "-m upload",
-        ("-u #{username.shellescape}" unless use_jwt),
-        ("-p #{shell_escaped_password(password)}" unless use_jwt),
-        ("-jwt #{jwt}" if use_jwt),
         file_upload_option(source),
         additional_upload_parameters, # that's here, because the user might overwrite the -t option
         "-k 100000",
@@ -466,14 +463,17 @@ module FastlaneCore
   class JavaTransporterExecutor < TransporterExecutor
     def build_upload_command(username, password, source = "/tmp", provider_short_name = "", jwt = nil, platform = nil, api_key = nil)
       use_jwt = !jwt.to_s.empty?
+      use_api_key = !api_key.nil?
       if !Helper.user_defined_itms_path? && Helper.mac? && Helper.xcode_at_least?(11)
         [
-          ("ITMS_TRANSPORTER_PASSWORD=#{password.shellescape}" unless use_jwt),
+#          ("ITMS_TRANSPORTER_PASSWORD=#{password.shellescape}" unless use_jwt),
           'xcrun iTMSTransporter',
           '-m upload',
-          ("-u #{username.shellescape}" unless use_jwt),
-          ("-p @env:ITMS_TRANSPORTER_PASSWORD" unless use_jwt),
-          ("-jwt #{jwt}" if use_jwt),
+#          ("-u #{username.shellescape}" unless use_jwt),
+#          ("-p @env:ITMS_TRANSPORTER_PASSWORD" unless use_jwt),
+#          ("-jwt #{jwt}" if use_jwt),
+          ("--apiKey #{api_key[:key_id]}" if use_api_key),
+          ("--apiIssuer #{api_key[:issuer_id]}" if use_api_key),        
           file_upload_option(source),
           additional_upload_parameters, # that's here, because the user might overwrite the -t option
           '-k 100000',

Curiously, the original code above doesn’t use the apiKey at all. I made the above modifications to test my theory, and with those changes, things ALMOST work. I hard commented out the JWT bits because for some reason, jwt is not nil or empty - it’s set to YourJWT 🤷 .

With the above code changes, I still get the following error:

ERROR [2022-10-19 12:34:07.77]: Transporter transfer failed.
WARN [2022-10-19 12:34:07.77]: 
ERROR [2022-10-19 12:34:07.77]: Could not locate the private key file: AuthKey_XXXXXXXXX.p8

Looking up the Transporter docs, I found this:

The generated API key consists of a public key and a private key. The private key is in a file called AuthKey_<apiKey value>.p8. If you use the -apiIssuer and -apiKey options, Transporter will search the following directories in this order looking for a file that matches this format AuthKey_<apiKey value>.p8:

<current_directory>/private_keys <user_home>/private_keys <user_home>/.private_keys <user_home>/.appstoreconnect/private_keys Note: for Windows users, below are examples of where the file could be stored:

<current_directory>\private_keys C:\Users\johnny_appleseed\private_keys C:\Users\johnny_appleseed.private_keys C:\Users\johnny_appleseed.appstore_connect\private_keys This -apiKey option is used in combination with -apiIssuer.

The options -u, -p, or -asc_provider are not allowed with the -apiKey and -apiIssuer option pair.

So, I manually created a <user_home>/private_keys folder and copied the p8 AuthKey to that location in the format specified, and lo and behold, everything works. I’ve tried creating a private_keys folder in the “current working directory” from where I ran fastlane and copy the keys there, but that doesn’t seem to work.

Phew. Those are a lot of things that I needed to change to make things work - hopefully provides enough clues for a proper fix.

(Updated the diff - the original diff was wrong - I updated the wrong build_upload_command method. Whoopsie)

Same issue here with:

• Bitrise CI
• Xcode 14.0.1
• Fastlane 2.210.1

Could not determine the package’s bundle ID. The package is missing an Info.plist or the CFBundlePackageType is not ‘APPL’ or ‘FMWK’. Unable to validate your application.

Solved by settings ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD = false

We had a similar problem with our CI pipeline, but with a different error message. The above workaround with the environment variable solved it. Just commenting because I randomly stumbled into this issue and search engines couldn’t find it

Transporter transfer failed.
[iTMSTransporter]             data: null
[iTMSTransporter]         }
[iTMSTransporter]         buildAssetSpi: class BuildRelationshipsBuildAssetDescription {
[iTMSTransporter]             links: class AppAvailabilityRelationshipsAppLinks {
[iTMSTransporter]                 self: https://contentdelivery.itunes.apple.com/MZContentDeliveryService/iris/v1/builds/f7ab2c5b-3a81-4bd7-958c-f4cfea69cba1/relationships/buildAssetSpi
[iTMSTransporter]                 related: https://contentdelivery.itunes.apple.com/MZContentDeliveryService/iris/v1/builds/f7ab2c5b-3a81-4bd7-958c-f4cfea69cba1/buildAssetSpi
[iTMSTransporter]             }
[iTMSTransporter]             data: null
[iTMSTransporter]         }
[iTMSTransporter]     }
[iTMSTransporter]     links: class ResourceLinks {
[iTMSTransporter]         self: https://contentdelivery.itunes.apple.com/MZContentDeliveryService/iris/v1/builds/f7ab2c5b-3a81-4bd7-958c-f4cfea69cba1
[iTMSTransporter]     }
[iTMSTransporter] }
[iTMSTransporter] [2022-11-15 10:48:37 CET] <main> DBG-X: Returning 1
iTunes Transporter output above ^
Upload is not in processing state, please try again. state: class Build {
Return status of iTunes Transporter was 1: Upload is not in processing state, please try again. state: class Build {
The call to the iTMSTransporter completed with a non-zero exit status: 1. This indicates a failure.

We found it handy to introduce the workaround suggested above directly in our Fastfile, just before pilot

# Workaround for https://github.com/fastlane/fastlane/issues/20741
environment_variable(set: {
 'ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD' => 'true'
})

pilot

Note: I managed to make it work again in Azure Devops by updating the Agent Specification to macOS-12. Here, Xcode 14 is the default.

I used this combination:

👍 Xcode 13.4.1 - uploaded with ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true before upload 👎 Xcode 13.4.1 - fail to upload without ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true

👎 Xcode 14.0.1 - fail with ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true before upload 👍 Xcode 14.0.1 - uploaded without ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true

fastlane 2.210.1

Confirmed – now using this crude workaround to support both Xcode 13 and 14:

ENV['ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD'] = 'true' if ENV['FL_XCODE_VERSION'] && ENV['FL_XCODE_VERSION'].include?(' 13.')

Any chance this workaround could be integrated in Fastlane?

confirmed adding

  before_all do
    ENV['ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD'] = "true"
  end

to the Fastfile fixes it

setting ENV['ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD'] = 'true' in fastlane build job fixed the issue in Xcode 13.2.1 for us

for anyone using CircleCI, just adding the ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true on Project Settings -> Environment Variables.

Resolved the issue for me

After updating to the latest version of fastlane and ensuring that upload_to_testflight is using Xcode 14, it’s working again.

I did some digging on my own. Looks like it’s a bug inside iTMSTransporter 3.0.0. Fastlane passes -jwt param to iTMSTransporter and that param is mutually exclusive with -apiKey and -apiIssurer.

ERROR: The -jwt option must not include the -apiIssuer option.

Also it’s Java NPE, but not arguments parsing error:

1 package(s) were not uploaded because they had problems:
[2022-10-17 12:56:34 MSK] <main> ERROR: There was a general exception while executing
[2022-10-17 12:56:34 MSK] <main> ERROR: An exception has occurred: issuerId is required
[2022-10-17 12:56:34 MSK] <main> DEBUG: java.lang.NullPointerException: issuerId is required
	at java.base/java.util.Objects.requireNonNull(Unknown Source)
	at com.apple.transporter.core.auth.jwt.impl.DefaultJWTSupplierFactory.make(DefaultJWTSupplierFactory.java:27)
	at com.apple.transporter.core.auth.jwt.JWTSupplierFactory.make(JWTSupplierFactory.java:17)
	at com.apple.transporter.core.auth.impl.DefaultHttpHeaderAuthenticationFactory.javaJwtHttpRequestInterceptor(DefaultHttpHeaderAuthenticationFactory.java:46)
	at com.apple.transporter.core.auth.impl.DefaultHttpHeaderAuthenticationFactory.javaHttpRequestInterceptor(DefaultHttpHeaderAuthenticationFactory.java:37)
	at com.apple.transporter.software.SoftwareUploader.configureApiClients(SoftwareUploader.java:110)
	at com.apple.transporter.software.SoftwareUploader.configure(SoftwareUploader.java:131)
	at com.apple.transporter.core.transport.upload.api.UploadDriver.upload(UploadDriver.java:17)
	at com.apple.transporter.operation.UploadSoftwareOperation.executeRestUploader(UploadSoftwareOperation.java:99)
	at com.apple.transporter.operation.UploadSoftwareOperation.execute(UploadSoftwareOperation.java:66)
	at com.apple.transporter.Application.reallyBegin(Application.java:295)
	at com.apple.transporter.Application.begin(Application.java:129)
	at com.apple.transporter.osgi.TransporterService.start(TransporterService.java:84)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at com.apple.transporter.starter.TransporterStarter.runService(TransporterStarter.java:421)
	at com.apple.transporter.starter.TransporterStarter.runTransporterService(TransporterStarter.java:394)
	at com.apple.transporter.starter.TransporterStarter.start(TransporterStarter.java:164)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at com.apple.transporter.bootstrap.BootstrapperPhase2.runStartable(BootstrapperPhase2.java:362)
	at com.apple.transporter.bootstrap.BootstrapperPhase2.runStarter(BootstrapperPhase2.java:324)
	at com.apple.transporter.bootstrap.BootstrapperPhase2.start(BootstrapperPhase2.java:167)
	at com.apple.transporter.bootstrap.BootstrapperPhase1.startOSGiFramework(BootstrapperPhase1.java:439)
	at com.apple.transporter.bootstrap.BootstrapperPhase1.realBootstrap(BootstrapperPhase1.java:238)
	at com.apple.transporter.bootstrap.BootstrapperPhase1.bootstrap(BootstrapperPhase1.java:86)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at com.apple.transporter.bootstrap.BootstrapperPhase1.bootstrap(BootstrapperPhase1.java:107)
	at com.apple.transporter.bootstrap.BootstrapperPhase1.bootstrap(BootstrapperPhase1.java:78)
	at com.apple.transporter.launcher.Launcher.launchBootstrapper(Launcher.java:37)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at com.apple.transporter.launcher.Application.start(Application.java:450)
	at com.apple.transporter.launcher.Application.main(Application.java:947)

I don’t know how long will it take for Apple to provide a fix, so maybe there’s an option to force pilot to use altool instead of iTMSTransporter? AFAIK, altool is the default choice when using Xcode 14.

Can anyone confirm that Transporter is now working fine without any of the above mentioned workarounds? 🤔

Because I have noticed that all our Testflight uploads (more than 10+ builds) from 27th Oct onwards started succeeding again ✅, without adding any flags or workarounds to our fastlane pilot command (= didn’t touch anything on our side).

What I noticed is:

• All our failure builds (including 24th Oct) was when iTMSTransporter was auto-updating to 3.0.0.28 ❌ , which is exactly the version this issue was reported with as mentioned above
• But all our successful uploads starting from 27th Oct onwards were now auto-updating and using 3.0.0.30 ✅

Our build nodes are using Xcode 13.4.1 and macOS 12.4 and fastlane 2.204.3 (not the latest). Verified the transporter version by running pilot --verbose command.

If I unterstand some things :

I did some digging on my own. Looks like it’s a bug inside iTMSTransporter 3.0.0. Fastlane passes -jwt param to iTMSTransporter and that param is mutually exclusive with -apiKey and -apiIssurer.

ERROR: The -jwt option must not include the -apiIssuer option.

Also it’s Java NPE, but not arguments parsing error:

I don’t know how long will it take for Apple to provide a fix, so maybe there’s an option to force pilot to use altool instead of iTMSTransporter? AFAIK, altool is the default choice when using Xcode 14.

Here I understand that fastlane can use altool OR iTMSTransporter. So if you got these kinds of log :

DEBUG [2022-10-23 23:22:30.23]: [altool]:  {

DEBUG [2022-10-23 23:22:30.23]: [altool]:     NSLocalizedDescription = "Could not determine the package\U2019s bundle ID. The package is missing an Info.plist or the CFBundlePackageType is not \U2018APPL\U2019 or \U2018FMWK\U2019.";

DEBUG [2022-10-23 23:22:30.23]: [altool]:     NSLocalizedFailureReason = "Unable to validate your application.";

DEBUG [2022-10-23 23:22:30.23]: [altool]: }

WARN [2022-10-23 23:22:30.24]: [altool] 2022-10-23 23:22:30.237 *** Error: Could not determine the package’s bundle ID. The package is missing an Info.plist or the CFBundlePackageType is not ‘APPL’ or ‘FMWK’. Unable to validate your application. (-21017)

WARN [2022-10-23 23:22:30.24]: [altool]  {

WARN [2022-10-23 23:22:30.24]: [altool]     NSLocalizedDescription = "Could not determine the package\U2019s bundle ID. The package is missing an Info.plist or the CFBundlePackageType is not \U2018APPL\U2019 or \U2018FMWK\U2019.";

WARN [2022-10-23 23:22:30.24]: [altool]     NSLocalizedFailureReason = "Unable to validate your application.";

WARN [2022-10-23 23:22:30.24]: [altool] }

INFO [2022-10-23 23:22:30.24]: Application Loader output above ^
ERROR [2022-10-23 23:22:30.24]: Error uploading '/var/folders/24/.../T/..../...b2-439d-b475-b7b49f4930a3.itmsp'.

ERROR [2022-10-23 23:22:30.24]: Could not determine the package’s bundle ID. The package is missing an Info.plist or the CFBundlePackageType is not ‘APPL’ or ‘FMWK’. Unable to validate your application. (-21017)

ERROR [2022-10-23 23:22:30.24]: The call to the altool completed with a non-zero exit status: 1. This indicates a failure.
ERROR [2022-10-23 23:22:30.24]: Could not download/upload from App Store Connect!`

the error is still here. cannot upload to testflight.

ENV['ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD'] = 'true'

build_app(
  project: project_path,
  scheme: 'Unity-iPhone',
  xcargs: '-allowProvisioningUpdates',
  output_directory: './build',
  output_name: 'MyTestIPA.ipa'
)

upload_to_testflight(
  app_identifier: ENV["IOS_BUNDLE_ID"],
  username: ENV["APPLE_DEVELOPER_EMAIL"],
  skip_waiting_for_build_processing: true,
  itc_provider: ENV["APPLE_TEAM_ID"],
  team_id: ENV["APPLE_TEAM_ID"],
  ipa: "./build/MyTestIPA.ipa"
)

That you use Altool. And so,

I don’t know why altool wants to upload an itmsp file

This is a bug in the fastlane code. Do not set ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD environment variable when using alltool.

And

Update to the latest version of Fastlane, it should use altool instead of iTMSTransporter which works fine with Xcode 14. Make sure to also have Xcode 14 installed, it does check whether Xcode 14 is installed before using altool instead of checking whether the iTMSTransporter version is 3.*.

we use 2.210.0, it works great without ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true

So, I wonder, there is 2 solutions, right ? One with iTMSTransporter and one with Altool.

-> How to froce fastlane to use iTMSTransporter ? -> What is the correct way with Altool ?

Sorry if my question is dumb 😦

Edit : For our project we keepts that configuration after the bump discovery :

• Xcode 14
• Remove ENV['ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD'] = 'true'
• Add app_identifier: config["app_identifier"]to upload_to_testflight

I Don’t know if theese thing are all needed, but now it’s deploy.

@victortumble The issue is not only 14.0.1, this also happens on 13.3.1.

hey guys the ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD isn’t need.

The issue is due to XCode version don’t use 14.0.1 it is a beta version, it doesn’t have the Transporter on it.

Use 14.1.0 this will fix the uploading but not the sign problem, in my case just by using the pod plugin cocoapods-pod-sign as described on the issue Xcode 14 build failed with manual code sign and app resource bundles resolved the issue once for all.

Oh and using the configuration from this comment to upload to testflight.

Thanks to @honkmaster I was able to get it up and running. If anyone is updating the yaml files, change

pool:
  name: Azure Pipelines
  vmImage: 'macOS-latest'
  demands:
    - xcode

to

pool:
  name: Azure Pipelines
  vmImage: 'macOS-12'
  demands:
    - xcode

This issue popped up with our nightly builds. Using Xcode 13 + fastlane 2.210.1. Setting the env var ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true got us past the An exception has occurred: issuerId is required error.

However, hitting a different error after that. These automated builds were working fine until last night

[09:44:48]: Creating authorization token for App Store Connect API
[09:44:50]: Ready to upload new build to TestFlight (App: <redacted>)...
[09:44:53]: Going to upload updated app to App Store Connect
[09:44:53]: This might take a few minutes. Please don't interrupt the script.
[09:45:10]: Transporter transfer failed.
[09:45:10]: 
[09:45:10]: An error occurred while trying to call the requested method validateAssets. (1272)
[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main> DBG-X:   parameter ErrorMessage = An error occurred while trying to call the requested method validateAssets. (1272)

[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main> DBG-X:   parameter ShouldUseRESTAPIs = false

[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main> DBG-X:   parameter Success = false

[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main> ERROR: An error occurred while trying to call the requested method validateAssets. (1272)

[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main> DBG-X: The error code is: 1272

[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main>  INFO: Done performing authentication.

[09:45:11]: [iTMSTransporter] 

[09:45:11]: [iTMSTransporter] 

[09:45:11]: [iTMSTransporter] 

[09:45:11]: [iTMSTransporter] Package Summary:

[09:45:11]: [iTMSTransporter]  

[09:45:11]: [iTMSTransporter] 1 package(s) were not uploaded because they had problems:

[09:45:11]: [iTMSTransporter] 	/var/folders/sg/c0tzk72j58s8pbfbzxpp1hkc0000gn/T/d20221019-14706-hgvg0q/1575818020-09605950-d0c3-4512-a568-50e727b4cd3f.itmsp - Error Messages:

[09:45:11]: [iTMSTransporter] 		An error occurred while trying to call the requested method validateAssets. (1272)

[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main> DBG-X: Returning 1

We are currently manually uploading the IPA using Transporter and it uploads to TestFlight fine, so the IPA should be valid.

yes, same issue here

Can anyone confirm that Transporter is now working fine without any of the above mentioned workarounds? 🤔

Because I have noticed that all our Testflight uploads (more than 10+ builds) from 27th Oct onwards started succeeding again ✅, without adding any flags or workarounds to our fastlane pilot command (= didn’t touch anything on our side).

What I noticed is:

• All our failure builds (including 24th Oct) was when iTMSTransporter was auto-updating to 3.0.0.28 ❌ , which is exactly the version this issue was reported with as mentioned above
• But all our successful uploads starting from 27th Oct onwards were now auto-updating and using 3.0.0.30 ✅

Our build nodes are using Xcode 13.4.1 and macOS 12.4 and fastlane 2.204.3 (not the latest). Verified the transporter version by running pilot --verbose command.

Can anyone confirm that Transporter is now working fine without any of the above mentioned workarounds? 🤔

Because I have noticed that all our Testflight uploads (more than 10+ builds) from 27th Oct onwards started succeeding again ✅, without adding any flags or workarounds to our fastlane pilot command (= didn’t touch anything on our side).

What I noticed is:

• All our failure builds (including 24th Oct) was when iTMSTransporter was auto-updating to 3.0.0.28 ❌ , which is exactly the version this issue was reported with as mentioned above
• But all our successful uploads starting from 27th Oct onwards were now auto-updating and using 3.0.0.30 ✅

Our build nodes are using Xcode 13.4.1 and macOS 12.4 and fastlane 2.204.3 (not the latest). Verified the transporter version by running pilot --verbose command.

Yes, we haven´t applied any of the solutions mentioned on this thread (we were temporarily using altool directly instead of fastlane) and I can confirm fastlane is working again with the iTMSTransporter 3.0.0.30.

Hi We have couple of projects one with Xcode13 and other is with Xcode14. When we set the ENV[‘ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD’] = ‘true’ in Fastfile, able to upload app from Xcode13 project where as it is failing with Xcode14. It seems it is not checking Xcode version to use either iTMS Transporter or altool to deploy app.

If you are using circleci, you can add the environment variable in the project setting.

I don’t know why altool wants to upload an itmsp file

This is a bug in the fastlane code. Do not set ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD environment variable when using alltool.

This issue popped up with our nightly builds. Using Xcode 13 + fastlane 2.210.1. Setting the env var ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true got us past the An exception has occurred: issuerId is required error.

However, hitting a different error after that. These automated builds were working fine until last night

[09:44:48]: Creating authorization token for App Store Connect API
[09:44:50]: Ready to upload new build to TestFlight (App: <redacted>)...
[09:44:53]: Going to upload updated app to App Store Connect
[09:44:53]: This might take a few minutes. Please don't interrupt the script.
[09:45:10]: Transporter transfer failed.
[09:45:10]: 
[09:45:10]: An error occurred while trying to call the requested method validateAssets. (1272)
[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main> DBG-X:   parameter ErrorMessage = An error occurred while trying to call the requested method validateAssets. (1272)

[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main> DBG-X:   parameter ShouldUseRESTAPIs = false

[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main> DBG-X:   parameter Success = false

[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main> ERROR: An error occurred while trying to call the requested method validateAssets. (1272)

[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main> DBG-X: The error code is: 1272

[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main>  INFO: Done performing authentication.

[09:45:11]: [iTMSTransporter] 

[09:45:11]: [iTMSTransporter] 

[09:45:11]: [iTMSTransporter] 

[09:45:11]: [iTMSTransporter] Package Summary:

[09:45:11]: [iTMSTransporter]  

[09:45:11]: [iTMSTransporter] 1 package(s) were not uploaded because they had problems:

[09:45:11]: [iTMSTransporter] 	/var/folders/sg/c0tzk72j58s8pbfbzxpp1hkc0000gn/T/d20221019-14706-hgvg0q/1575818020-09605950-d0c3-4512-a568-50e727b4cd3f.itmsp - Error Messages:

[09:45:11]: [iTMSTransporter] 		An error occurred while trying to call the requested method validateAssets. (1272)

[09:45:11]: [iTMSTransporter] [2022-10-19 09:45:10 PDT] <main> DBG-X: Returning 1

We are currently manually uploading the IPA using Transporter and it uploads to TestFlight fine, so the IPA should be valid.

We’re seeing the exact same issue. Updating to Xcode 14 isn’t an option for us at the moment and we’re also now stuck manually uploading via Transporter. Everything was working yesterday until it just wasn’t.

Update to the latest version of Fastlane, it should use altool instead of iTMSTransporter which works fine with Xcode 14. Make sure to also have Xcode 14 installed, it does check whether Xcode 14 is installed before using altool instead of checking whether the iTMSTransporter version is 3.*.

we use 2.210.0, it works great without ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true

I had the same problem.

In my environment, the upload was successful after setting the following environment variables.

ENV['ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD'] = 'true'

where I should put this ENV in the fastline file? I try in the

default_platform(:ios)

ENV['ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD'] = 'true'

platform :ios do

then build fail:

2022-10-17 15:49:06.355 xcodebuild[39424:39811737] CFURLRequestSetHTTPCookieStorageAcceptPolicy_block_invoke: no longer implemented and should not be called
error: exportArchive: The operation couldn’t be completed. (DVTFoundation.DVTCodeSignerError error 0.)

Should I put it before the pilot() section like this:

build_app(xcargs: "-allowProvisioningUpdates", workspace: "Unity-iPhone.xcworkspace", scheme: "Unity-iPhone")
     
ENV['ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD'] = 'true'

pilot(
)

I can confirm that env: ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD: true in our github fastlane workflow fixed the issue.

hey guys the ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD isn’t need.

The issue is due to XCode version don’t use 14.0.1 it is a beta version and it doesn’t have the Transporter on it.

Use 14.1.0 this will fix the uploading but not the sign problem, in my case just by using the pod plugin cocoapods-pod-sign as described on the issue Xcode 14 build failed with manual code sign and app resource bundles resolved the issue once for all.

Oh and using the configuration from this comment to upload to testflight.

@victortumble XCode 14.1 is the solution?

This is a bug in the fastlane code. Do not set ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD environment variable when using alltool.

Ah you’re right! I forgot to remove the env flag! Built again and it worked 👍

You can also add the variable using something like this, or adding this to your CI/CD env manager:

export ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true && bundle exec fastlane ios build

@stherold use this soltion then: https://github.com/fastlane/fastlane/issues/20741#issuecomment-1286699506

• “An error occurred while trying to call the requested method validateAssets”

@bmarkowww I’ve tried it already, and it fails with the same problem mentioned by @Foggzie : ‘“An error occurred while trying to call the requested method validateAssets”’

@thiagoguardado - see my post above - if you are using Xcode13 and apikey, then you can try to apply my patch. I’ve pinned our fastlane to version 2.210.1 and apply the patch during our build process.

e.g.:

bundle install --path vendor/bundle
#bundle update fastlane
patch ./vendor/bundle/ruby/2.6.0/gems/fastlane-2.210.1/fastlane_core/lib/fastlane_core/itunes_transporter.rb < fastlane/fix_for_transporter.patch
bundle exec fastlane beta ipa:${ARCHIVE_NAME} dsym:${DSYM_PATH} changelog:"./metadata/apple/en-US/release_notes.txt"

• XCode 14 isn’t an option for us at the moment

Then I’d try to build the app with Xcode 13, but to upload with Xcode 14. You can use xcode_select just before upload_to_testflight.

Our current state after perusing this thread:

• XCode 14 isn’t an option for us at the moment
• Setting ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD=true results in “An error occurred while trying to call the requested method validateAssets” as a few others have observed.
• Removing the com.apple.amp.itmstransporter library cache is ineffectual.

We’d like to try the above-mentioned FASTLANE_ITUNES_TRANSPORTER_PATH workaround but cannot find any way to get back to a pre 3.0.0 version. All our build agents have auto-updated. Is anyone aware of a way to grab an older version (I believe we were on something like 2.3.x)?

@Rakchon-n I haven’t tried the other workaround mentioned in this thread (i.e. ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD). In my Fastfile, build_app has already been using Xcode 14, but not upload_to_testflight.

Ok, so we’ve uncovered my issue above, and sorry this isn’t exactly matching the original report here, but is related and possible that others could hit both issues if they’re as dumb as us.

We have been using the wrong ios app ID in fastlane pilot for months (for an app that doesn’t even exist in our account). It seems fastlane/apple transporter has never checked/failed for this incorrect ID, and perhaps has matched based on the bundle ID.

I’m assuming Apple has also fixed this to now check and error, and released this fix at the same time they released the iTMSTransporter error that we all hit yesterday. So that’s why I felt things were too coincidental. Oops…

The env variable worked for one of our apps (dev env) today, but our production env app receives this error:

/Users/vagrant/.rbenv/versions/2.6.9/lib/ruby/gems/2.6.0/gems/fastlane-2.208.0/fastlane_core/lib/fastlane_core/ui/interface.rb:141:in `user_error!': [!] Error uploading ipa file:  (FastlaneCore::Interface::FastlaneError)
 [Transporter Error Output]: ERROR ITMS-4088: The organization <redacted for github issue> does not have permission to modify the application with the Apple ID <redacted for github issue>. Please try again, using an account for an organization with access to this application. at SoftwareAssets
[Transporter Error Output]: Invalid AdamId: <redacted for github issue>.
[Transporter Error Output]: Return status of iTunes Transporter was 1: ERROR ITMS-4088: The organization <redacted for github issue> does not have permission to modify the application with the Apple ID <redacted for github issue>. Please try again, using an account for an organization with access to this application. at SoftwareAssets
\nInvalid AdamId: <redacted for github issue>.
[Transporter Error Output]: The call to the iTMSTransporter completed with a non-zero exit status: 1. This indicates a failure.

Obviously we have been pilot’ing this app up until today, and have checked that there’s nothing pending in itunesconnect.

EDIT: I’ve ran it twice, and still get the same response. The two apps are under the same account/org and both run via our bitrise. Our dev is making it there no problem, but production is failing with this. So I presume I can rule out account/permission issues on my end. Perhaps some bug on Apple’s side? 🤔

2nd EDIT: Still failing for our production app a day later. Perhaps this is more of an Apple issue, than fastlane though.