Is there an existing issue for this?

• I have searched the existing issues
• I have read the guide to filing a bug

Use case

When running flutter build ipa, the -allowProvisioningUpdates flag is applied at the export stage, but I think that it isn't being applied when building the initial archive.

I have a project set up for automatic signing, which fails a flutter build ipa because there's no signing certificate: ```
Error (Xcode): No signing certificate "iOS Development" found: No "iOS Development" signing certificate matching team ID
"23Z8894VWP" with a private key was found.
/Users/sam/Developer/Projects/mono/client/club/ios/Runner.xcodeproj

It does not appear to attempt to repair/create the keys, which is what I would expect if the `-allowProvisioningUpdates` flag was supplied to xcode during the archiving phase.

If I perform a manual xcodebuild and supply that flag (and also an app store api key), it works: ```
    xcodebuild archive \
      -workspace "client/$APP_NAME/ios/Runner.xcworkspace" \
      -scheme Runner \
      -destination generic/platform=iOS \
      -archivePath "$ARCHIVE_NAME" \
      -allowProvisioningUpdates \
      -authenticationKeyID $AUTH_KEY \
      -authenticationKeyIssuerID $AUTH_ISSUER \
      -authenticationKeyPath "~/.private_keys/AuthKey_$AUTH_KEY.p8"

It will correctly generate the developer cert/key. Running flutter build ipa will subsequently succeed.

I'm not sure that using the authKey is specifically necessary here - it would probably also work without it if the user had an up to date developer signing account signed in with Xcode. Being able to supply the key is useful though.

It would be great to be able to build this behaviour into flutter, particularly for use in CI environments.

Proposal

Two changes:

• Extend flutter build ipa so that authentication key arguments can be passed through to xcode build
• Extend flutter build ipa so that the initial archive correctly uses the -allowProvisioningUpdates flag

The first would be useful regardless.

The second ought to be happening now, but I believe that there may be a hole in the logic of buildXcodeProject which is causing the flag not to be applied in my situation. Either that, or it's the fact that the auth key arguments are required in my case -- I haven't quite figured out which.