fastlane: Unable to upload to testflight using Xcode 14 beta

I found FASTLANE_ITUNES_TRANSPORTER_USE_SHELL_SCRIPT to make success upload ipa to AppStore with Transporter.app

export FASTLANE_ITUNES_TRANSPORTER_USE_SHELL_SCRIPT=1 
export FASTLANE_ITUNES_TRANSPORTER_PATH=/Applications/Transporter.app/Contents/itms 
bundle exec fastlane {your_action}

Please set FASTLANE_ITUNES_TRANSPORTER_USE_SHELL_SCRIPT as 1 if you want to use Transporter.app.

Dear all,

@freddi-kit PR https://github.com/fastlane/fastlane/pull/20631 looks good now…we have covered all the possible known scenarios. I am adding status: workaround available in this ticket because people are no longer blocked to start using Xcode14. Now Xcode14 users can switch the Fastlane version to PR https://github.com/fastlane/fastlane/pull/20631 in local and CI both and everything should work without any hack and without any change inside the Fastfile-scripts/pilot/deliver code.

Switch your Fastlane version to PR

• Update Gemfile to 👇 and run bundle install, bundle update fastlane, or bundle update

gem "fastlane", :git => "https://github.com/freddi-kit/fastlane.git", :branch => "altool-upload"

Please let us know if we are still missing any edge-case or something! To me, PR https://github.com/fastlane/fastlane/pull/20631 is simply fire 🔥🔥🔥 good to go 🚀 Thank you again @freddi-kit 👏

Oh, I was not aware of this! I totally missed this issue 😱

Will add to my queue!

But I’m also working on replacing iTMSTransporter with altool for xcode14 beta user, please wait a moment

This worked with Xcode 14 production version and Fastlane 2.210.0.

One thing to note is that if you haven’t updated your Fastlane in a long time, bundle update fastlane might not actually update your Fastlane. I don’t know what random series of commands like gem update and gem update bundler and bundle update fastlane got me there, but… make sure fastlane --version is reporting the version you actually need.

You don’t need any other workarounds if you have the latest Fastlane. Thanks again.

Edit: Apparently with verify-only updating Fastlane isn’t enough. So there’s that 😉

Merged, let’s wait new release version. I still wanna your Feedback because there may be missed case, thanks 🙇

Dear all,

@freddi-kit made a good-progress in this PR https://github.com/fastlane/fastlane/pull/20631 I am adding here the testing steps to test this PR and provide valuable feedback.

Testing Steps

• Update Gemfile to 👇 and run bundle install, bundle update fastlane, or bundle update

gem "fastlane", :git => "https://github.com/freddi-kit/fastlane.git", :branch => "altool-upload"

• Try to test for all possible combinations
  • Pilot using AppStore-connect API key (i tested this and it is failing at the moment - see details)
  • Pilot using username-password (old fashion apple-id, password) (i tested this and works 🚀)
  • Deliver using AppStore-connect API key
  • Deliver using username-password (old fashion apple-id, password)

Hello. I’ve got answer from Apple via Feedback. ITMSTransporter is officially removed from Xcode 14 beta and now it is only available on Transporter.app. Or apple recommends to use atool instread.

Hi @stherold, we were having the same issue, by looking at Fastlane’s sources, I saw that if you have the ITMSTRANSPORTER_FORCE_ITMS_PACKAGE_UPLOAD environment variable set, even if Fastlane uses altool, it affects the resulting path as you can see here.

After removing that env var, altool didn’t complain anymore. Check out if you are setting that, in case you are facing the same thing as we were.

With the final version of Xcode14, I’m still having the issue despite the workaround, does anyone else?

I updated to fastlane 2.210.0, removed the two FASTLANE_ITUNES_TRANSPORTER* environment variables, and was able to run fastlane beta and upload my app to TestFlight successfully.

Thank you, @freddi-kit ❤️❤️❤️

I’m seeing the exact same issue with Xcode 14 beta and macOS Ventura.

not working for me either. xcode must have auto-updated today.

Any updates on an official fix?

Did anyone figure out how to setup specific version (2.210.0) on github actions? There is no option provided for it, and the error persists for maierj/fastlane-action@v2.3.0

@ all who want to use 2.210.0

Please don’t forget to unset environment variable which mentioned in https://github.com/fastlane/fastlane/issues/20371#issuecomment-1239093663

Also, please check your Gemfile version and what fastlane you are calling.

If you ask the question which related to them, I may not reply because I wanna focus on actual bug as possible 🙇 (please write freely if you want to ask something)

I’m seeing the exact same issue with Xcode 14 beta and macOS Ventura.

So it looks like Transporter.app is no longer bundled with Xcode 14. I managed to make some pretty good progress with this by installing Transporter.app from the App Store and specifying:

FASTLANE_ITUNES_TRANSPORTER_PATH=/Applications/Transporter.app/Contents/itms

Disappointingly this now means we hit another error:

[13:37:14]: [iTMSTransporter] -Djava.ext.dirs=/Applications/Transporter.app/Contents/itms/java/lib/ext is not supported.  Use -classpath instead.
[13:37:14]: [iTMSTransporter] Error: Could not create the Java Virtual Machine.
[13:37:14]: [iTMSTransporter] Error: A fatal exception has occurred. Program will exit.

Curiously https://github.com/fastlane/fastlane/pull/16689 looks like it actually tried to address this lack of support for -Djava.ext.dirs= in Transporter.app’s bundled java. That code is still in master (see https://github.com/fastlane/fastlane/blob/master/fastlane_core/lib/fastlane_core/itunes_transporter.rb#L280), so I wonder if perhaps Xcode 14 and Ventura are causing it to fail to use this more up-to-date code path?

Further thoughts:

xcrun iTMSTransporter still happily works on Xcode 14 and Ventura so I have a theory that Fastlane is performing a check that it doesn’t actually need if it’s going to use the xcrun mechanism and incorrectly failing early.

ITMSTransporter

It’s worked for me with Xcode 14.0 (Build version 14A309).

before_all do |_lane, options|
  ENV["FASTLANE_ITUNES_TRANSPORTER_USE_SHELL_SCRIPT"]="1"
  ENV["FASTLANE_ITUNES_TRANSPORTER_PATH"]="/Applications/Transporter.app/Contents/itms"
end

ah! yes thank you!

Thank you @freddi-kit, your workaround has saved me a big headache 🙌

@freddi-kit - Nice job, that worked for me using Xcode 14 RC on MacOS Ventura Beta 6.

I success to fix it when using iTMSTransporter.app. please wait a moment to open PR

Using Xcode 13 fallback or altool, mentioned by @ptxmac, we have an ITMS error with Xcode 14 beta 3. Apple does not allow to upload builds from the current iOS and tvOS beta versions.

ERROR ITMS-90744: Unsupported Xcode or SDK Version. Your app was built with a version of Xcode or SDK that is not yet supported for upload to App Store Connect. For more information about supported versions of Xcode and SDK for Testflight or App Store submissions, view the App Store Connect What's New page (https://developer.apple.com/app-store-connect/whats-new/).

Using FASTLANE_ITUNES_TRANSPORTER_PATH=/Applications/Transporter.app/Contents/itms on macOS Monterey 12.4 has the same “Java Virtual Machine” issue, mentioned by @jbmorley .

@AlexScharch-BO Thank you for reporting it. And I’m sorry, in this PR I focused only update part and verify is not implemented, as itunes_transporter.rb says so 🙇

If you want to use verify, please consider to use https://github.com/fastlane/fastlane/issues/20371#issuecomment-1239093663. I will work the verify part soon as possible so please wait a moment.

To track issue easy, could you create new issue for it?

While following your last suggestion I found the culprit 🤦

I had this in my Fastfile:

  before_all do
    ENV["FASTLANE_ITUNES_TRANSPORTER_PATH"]="/Applications/Transporter.app/Contents/itms"
  end

which I must’ve added months ago when first trying to solve the original issue!

edit: thanks again for your help @freddi-kit!

I’ve switched over to the master branch but still seem to be getting this error

[!] Could not find transporter at /Applications/Xcode.app/Contents/Developer/. Please make sure you set the correct path to your Xcode installation.

my gemfile looks like this

source "https://rubygems.org"

gem "fastlane", :git => "https://github.com/fastlane/fastlane.git", :branch => "master"

and i ran bundle update fastlane and that updated correctly

@asincole

Please call bundle update fastlane after my PR merged to fetch new version 😄

Ah, it looks take so long time even if connect side finished processing in my env, i think it can be skipped by skip_waiting_for_build_processing. Let me check later but I think it is issue of App side API because there are update of AppStore Connect API today.

@freddi-kit sounds like that problem could also be this

Hello, I did some workaround and investigation. I wrote about them

Workaround

• Before calling pilot action, I called xcode-select("/Application/Xcode13.4.1.app") and it works.
  • NOTE: Please replace “/Application/Xcode13.4.1.app” with your env’s Xcode 13
  • NOTE: I will not bear any responsibility when you have some trouble by this workaround.

Investigation

• It looks like ITMSTransporter has problem in Xcode 14 beta and now I sent feed back to apple, please wait for answer

  • If you get error message shell An error (-10814) occurred. The operation couldn’t be completed. (OSStatus error -10814.) (null), you looks select xcode version correctly. But please consider to do xcode-select if you got another error message, it should be other issue which I’m not mention.

• The fastlane bahavior with FASTLANE_ITUNES_TRANSPORTER_PATH may be bug. I’m not sure why fastlane calls to java runtime directly which is contained in itsm. This should be done by frontend part of ITMSTransporter. I’m checking how to improve it.

  • https://github.com/fastlane/fastlane/blob/master/fastlane_core/lib/fastlane_core/itunes_transporter.rb#L299-L316 code is here

Perhaps it would make sense to look at altool instead of iTMS. It seems to be apples preferred way to do uplaods from scripts / cli: https://help.apple.com/asc/appsaltool/

I am still seeing this issue with xcode14.2 using pilot

you save my life, bro @freddi-kit

ITMSTransporter

It’s worked for me with Xcode 14.0 (Build version 14A309).

before_all do |_lane, options|
  ENV["FASTLANE_ITUNES_TRANSPORTER_USE_SHELL_SCRIPT"]="1"
  ENV["FASTLANE_ITUNES_TRANSPORTER_PATH"]="/Applications/Transporter.app/Contents/itms"
end

put this code on top of the fastfile or?

YES ！

@willokyes @niyaoyao I’m not sure why you are still using old fastlane, but you don’t need to do them in newest fastlane version with Xcode 14

I found FASTLANE_ITUNES_TRANSPORTER_USE_SHELL_SCRIPT to make success upload ipa to AppStore with Transporter.app

export FASTLANE_ITUNES_TRANSPORTER_USE_SHELL_SCRIPT=1 
export FASTLANE_ITUNES_TRANSPORTER_PATH=/Applications/Transporter.app/Contents/itms 
bundle exec fastlane {your_action}

Please set FASTLANE_ITUNES_TRANSPORTER_USE_SHELL_SCRIPT as 1 if you want to use Transporter.app.

Thanks, it worked 👍🏼

First of all, thanks very much for putting this fix in place and addressing this issue so quickly, @freddi-kit! Really appreciate it. 🙂

It looks like the changes do not make any updates to validation, as I just tried the latest Fastlane version (2.210.0) and validation still fails with the Could not find transporter at /Applications/Xcode.app/Contents/Developer/. error.

I also see this addition in itunes_transporter.rb:

    def build_verify_command(username, password, source = "/tmp", provider_short_name = "", jwt = nil)
      raise "This feature has not been implemented yet with altool for Xcode 14"
    end

I’m wondering if there is any intention to expand this solution to fix validation as well. My team and I sometimes use App Store Connect validation to make sure that our CI deployment pipeline continues to function properly (without having to actually upload the .ipa file).

@freddi-kit the upload to TF was successful thank you for the help. My ENV variables were never set so that wasn’t the issue By my previous comment I wanted to confirm whether the Transporter.app uninstallation is mandatory or not

yes, and now you can uninstall Transporter.app

You also can try to check by adding below code in Fastfile @alfavata

puts ENV['FASTLANE_ITUNES_TRANSPORTER_PATH']

fastlane never loads Transporter.app if FASTLANE_ITUNES_TRANSPORTER_PATH is not set. so … i would like you to do other way like opening new terminal.app and try. Could you try? (And please check your environment variable settings in .zshrc or other CI settings)

hm…

@alfavata You may still set FASTLANE_ITUNES_TRANSPORTER_PATH, please unset it

sorry please wait, I missed you said you unset them

@freddi-kit Yep managed to build and deploy using bundle exec fastlane {your_lane} not sure what changed between tries but all working now.

Thanks for the help 😃

@freddi-kit thanks a lot. 😃

Curious though, when your PR is merged, I can update my gemfile to look like this

source "https://rubygems.org"

 gem "fastlane"

@freddi-kit thanks a lot, it works fine now. I can’t remember why I was getting an error yesterday. You are a lifesaver, thanks a lot. So moving forward, I always need to prefix with bundle exec before running my Fastlane command?

Same in CI yeah?

thanks @peagasilva

@asincole Good job 👍

@asincole Okay, you need to run bundle exec fastlane ios beta if you install fastlane via bundle install with Gemfile.

This error shows that you specifying invalid key_content to app_store_connect_api, please check your key_content is correct format.

@freddi-kit oh shit, sorry lol. I deleted my keys from the file because I wanted to paste them here.

I’ve restored the keys and I’m rerunning the command. I unset those env variables and so far, I do not have a problem. I will update you when it finishes running if it works this time. thanks

@freddi-kit just to make sure: is your api key correct?

invalid curve name happened to me, but it turned out my key was incorrect - empty in my case.

I hope this can help pointing you to the right direction.

@asincole

sorry, I missed your comment. You don’t need FASTLANE_ITUNES_TRANSPORTER_USE_SHELL_SCRIPT and FASTLANE_ITUNES_TRANSPORTER_PATH if you use my branch. Or what error did you get?

hey @freddi-kit no worries, I can see you have your hands full. Thanks for all the work you are doing.

if I unset FASTLANE_ITUNES_TRANSPORTER_USE_SHELL_SCRIPT and FASTLANE_ITUNES_TRANSPORTER_PATH then I get this when I try to push a beta with pilot

 [iTMSTransporter] An error (-10814) occurred. The operation couldn’t be completed. (OSStatus error -10814.) (null) #20650
Closed 

Thanks for all the work here - eager to see the final release with the aitool branch merged, hopefully after the API hanging thing was fixed. This looks like a frustrating little tangle of issues.

Posting what worked for me just now, since I use fastlane but without using bundler so installing from a git repo/branch is more difficult, but “specific_install” makes it possible:

gem install specific_install
gem specific_install -l https://github.com/freddi-kit/fastlane.git -b altool-upload

Then I altered my upload_to_testflight to have parameter skip_waiting_for_build_processing: true, and 💥 it worked. Kudos!

@hervenivon I investigated and it should be other issue due to API issue, let me check after the this issue and PR is merged, please consider to use skip_waiting_for_build_processing until it

@Roberdan @rmdvector this workaround https://github.com/fastlane/fastlane/issues/20371#issuecomment-1242768042 worked for me except for the end of processing. faslane has never been able to get the update “signal” to finish.

Me too, and AppStore Connect still show app is in processing so I think it is app store connect side issue

@hervenivon that was the first thing I tried, didn’t work. I’m currently unpacking XCode 13 to see if that works. Meantime I was able to use xcode to upload the archive to testflight.

@Roberdan @rmdvector this workaround https://github.com/fastlane/fastlane/issues/20371#issuecomment-1242768042 worked for me except for the end of processing. faslane has never been able to get the update “signal” to finish.

@freddi-kit, confirmed working, thanks!

@IanHoar I fixed my code, please try it again

@crazymanish I think you are seeing the same issue as me. I just attempted a deploy with your instructions using Pilot+APIKey and got this: 'build_upload_command': \e[31m[!] undefined method 'shellescape' for nil:NilClass\e[0m (NoMethodError)

Apple still doesn’t accept Xcode 14 submissions, no? At least I haven’t seen any Apple news in that regard yet.

Of course that’s only a matter of hours/days probably.

Submission is open since September 7: https://developer.apple.com/news/releases/?id=09072022h

After reading all the great answers here, one way that worked for us until a new method is default:

• Extract itms/ folder from XC 13. Can be zipped and moved around between machines
• Set export FASTLANE_ITUNES_TRANSPORTER_USE_SHELL_SCRIPT=1 and export FASTLANE_ITUNES_TRANSPORTER_PATH=/path/to/unzipped/itms
• Run Fastlane as before against XC 14 and don’t get into any issues with ASC

After few days, and maybe the public betas, ITMS now accept builds built with Xcode 14 beta 3. ✅

Sorry for hijacking this thread, but does Apple already accepts Xcode 14/iOS 16 builds for TestFlight? I can’t seem to find any information here.

Yes. After few rejected builds when the new Xcode beta was available, now, it works like a charm.

After few days, and maybe the public betas, ITMS now accept builds built with Xcode 14 beta 3. ✅

Sorry for hijacking this thread, but does Apple already accepts Xcode 14/iOS 16 builds for TestFlight? I can’t seem to find any information here.

Thanks for @ptxmac 's idea , I was able to upload my app using altool and here is the azure task for it

- task: Bash@3
  displayName: 'Release to App store'
  inputs:
    targetType: inline
    script: |
      xcrun altool --validate-app -f my-app.ipa --apiKey $apiKeyId --apiIssuer $apiIssuer --output-format json --type ios
      xcrun altool --upload-app -f my-app.ipa --primary-bundle-id $bundleId --apiKey $apiKeyId --apiIssuer $apiIssuer --type ios

But you must ensure that you have installed the API key P8 file at ~/private_keys on your machine. and clean it after finishing the build

A workaround is to keep XCode 13 installed and use either xcode-select to change the default xcode, or overwrite it in the fastlane file (the method is also called xcode-select in fastlane).

Xcode 13 won’t open on macOS 13, but the cli tools still work perfectly.

Also note that Apple won’t even approve Xcode 14 ipa’s for the appstore, so having a Xcode 13 install is a must for anyone wishing to release.