I am not too familiar with fastlane and template_name so not sure if any other changes are needed but tests are passing for now. Not sure if apple supports templateName now in a different way, if so some additional changes might still be needed.

I did a little bit of digging and this template_name is being used in match and sigh. There's this docs:

And the docs of the options for match and sigh say:

The name of provisioning profile template. If the developer account has provisioning profile templates (aka: custom entitlements), the template name can be found by inspecting the Entitlements drop-down while creating/editing a provisioning profile (e.g. "Apple Pay Pass Suppression Development"

Now, I poked around in ASC dashboard and couldn't find such thing.

Idk if it can still be used as intended by match

Anyone support merging this PR soon? Thanks guys!

Anyone support merging this PR soon? Thanks guys!

+1

+1 , Whats the solution for this.

This is a fairly pressing issue. Would love to see this merged and a release cut soon 🤞🏻

Quick update:
With this fix and using the additional capabilities section in the configuration of the app id in the Enterprise Program, fastlane sigh is regenerating the provisioning profiles and no template_name parameter is needed anymore - final test is currently in progress.

Quick update: With this fix and using the additional capabilities section in the configuration of the app id in the Enterprise Program, fastlane sigh is regenerating the provisioning profiles and no template_name parameter is needed anymore - final test is currently in progress.

Thanks for the update, When can we expect the fix to be in Live @jonaswaigel

Basically this PR is the fix and our tests are successful. We are now using our own fork repo of fastlane including this fix until the fastlane contributors merged this PR and released a new version. Unfortunately, I cannot merge as I am no contributor here :D @Monish-Graphy

This is not working for me. What should I do in case I need to set a template for the profile but can't do it through the additional capabilities setting?

I don't get it. i went through the changelog list and couldn't find anything related to the /profiles call and the ProfileCreateRequest.Data.Attributes. So either I missed something or apple does a bad job documenting the changes of their public api:

https://developer.apple.com/documentation/appstoreconnectapi/app-store-connect-api-release-notes

https://developer.apple.com/documentation/appstoreconnectapi/post-v1-profiles

https://developer.apple.com/documentation/appstoreconnectapi/profilecreaterequest/data-data.dictionary/attributes-data.dictionary

cc @rogerluan
This is a workaround, not a fix. Template name is still important for the provisionings that need it (althought I dont know whats the new way apple intends it to be set up).

Removing this will result in this issue: #18505

New intended way is likely through the Capabilities - In App Provisioning. Testing now

New intended way is likely through the Capabilities - In App Provisioning. Testing now

@rasberik any updates on this?

I don't get it. i went through the changelog list and couldn't find anything related to the /profiles call and the ProfileCreateRequest.Data.Attributes. So either I missed something or apple does a bad job documenting the changes of their public api

In the issue that's linked to the PR which first added support for templateName, it seems Josh was completely unaware of this field — implying it wasn't listed in the docs.

I suspect the templateName field was never documented or "officially" supported to begin with, so they probably didn't note or document its removal, either. (Which isn't really an excuse: if it was required for certain uses, Apple should have documented it, and they likewise should have followed and communicated a proper deprecation strategy to remove it. 😠)

Correct, this is also our thought about it - maybe this was done by special requirements from development teams to Apple to be able to add templates with additional capabilities which did not officially exist.
In other Apple dev accounts, this template dropdown is not available anymore with checking the app ids.

Someone has some guidance how this fix can be used until it is merged, and an updated version is released?
@jonaswaigel you mentioned that you use a fork for now?

You can clone the repo locally, make the change in a different branch and run "gem build fastlane.gemspec". To install it afterwards, you can use e.g. "gem install fastlane -v 2.227.3" which includes your change. To be sure, that you're running the right version, you can run "fastlane --version" - same approach is working in github actions

New intended way is likely through the Capabilities - In App Provisioning. Testing now

@rasberik Where would this be located? "In App Provisioning" is not present in the "Add a capability" window in Xcode 16.4 nor as a capability listed for any of our app identifiers.

@rogerluan @joshdholtz @AliSoftware can we get this merged in? Do we need more people to test to get this in and released?

Someone has some guidance how this fix can be used until it is merged, and an updated version is released? @jonaswaigel you mentioned that you use a fork for now?

@blaemmle you can also temporarily add this into your Gemfile:

gem "fastlane", git: "https://github.com/visuallization/fastlane.git", branch: "fix/templateName-is-not-an-attribute-on-the-resource-profiles"

This way you are pointing to the fixed version of fastlane. Just make sure to switch back to official repo once the issue is fixed and merged.

Removing this is problematic, but not sure what else can be done if it's been removed from the API. It's a breaking change though and should be documented as such.

At $dayjob we use this parameter to apply custom entitlements Apple has granted in our account. I still see the custom entitlements drop-down when creating a provisioning profile via https://developer.apple.com/account/resources/profiles/add, so it's odd it's been removed from the API.

Edit: The developer web site is creating the profile by doing a POST to https://developer.apple.com/services-account/v1/profiles with the complete profile contents. It's not using the App Store Connect API at all.

Edit 2: Looks like Apple expects anyone using additional entitlements to migrate to managed capabilities by submitting a form (as the account owner) here:

https://developer.apple.com/contact/request/entitlement-migration-requests/

@visuallization Sorry for late. The build itself works (can be installed and ran on device), which is a good news already.
But Im still waiting for further QA as for my use case, its Apple Pay related feature and it takes some time to get full verification.

@nasahapps Its in the setting of the generated provisioning profiles in Apple Developer portal.
e.g. Select any profile (Development, AppStore, Adhoc support this) → Edit → and will see bundle, devices, and Entitlements that are configured for this profile when it was generated.

So for certain Apple Pay features, having Entitlements configured as ApplePay In-App Provisioning Distribution was cruical and achieved by providing template_name when generating it (given the template is available in Developer portal).

Now, however, since they removed it - its unclear if its still functional. Clearly some migration & deprecation in progress from Apple, but its not documented at all.

+1

Please merge 🙏

If you are unsure whether Apple will revert support for this field, could Fastlane send it only if an actual value is provided? Then for those who need it, it will still be supported on the Fastlane side and could wait for Apple response.

same issue here :(

If you are unsure whether Apple will revert support for this field, could Fastlane send it only if an actual value is provided? Then for those who need it, it will still be supported on the Fastlane side and could wait for Apple response.

This Pr #29581 does exactly that but it breaks fastlane when template_name is provided. I don't think we should ship code that breaks.

If we are gonna merge this PR we need to update docs as well to remove mentions of template_name and let users know of the new way @rasberik is currently testing.

@visuallization cc @rogerluan
Early testing revealed no issues (given entitlements are set up as part of Capabilities), so I think we should merge this and release with warning/ potential breaking change for those who rely on template_name.

Those blocked can update fastlane, and those who need template_name will need to wait until further incremental updates.

I think this would be most efficient way if maintainers agree

To set the In-App Provisioning capability we had been using the App Store Connect API directly:
curl "https://api.appstoreconnect.apple.com/v1/bundleIdCapabilities" -X POST --header "Authorization: Bearer #{appleApiToken}" --header "Content-Type: application/json" -d '{"data": {"type": "bundleIdCapabilities", "attributes": {"capabilityType": " IN_APP_PASS_PROVISIONING"}, "relationships": {"bundleId": {"data": {"id": "#{appStoreBundleIdentifier}", "type": "bundleIds"}}}}}'

The IN_APP_PASS_PROVISIONING capability type is not documented but you can see the capability types set on a bundle ID when getting the bundle ID capabilities:
curl "https://api.appstoreconnect.apple.com/v1/bundleIds/#{appStoreBundleIdentifier}/bundleIdCapabilities" --header "Authorization: Bearer #{appleApiToken}"

After manually setting the In-App Provisioning capability via the Apple Developer portal you will see the new capabilityType:
{ "type" : "bundleIdCapabilities", "id" : "##########_IN_APP_PASS_PROVISIONING", "attributes" : { "settings" : null, "capabilityType" : "IN_APP_PASS_PROVISIONING" }, "relationships" : { "bundleId" : { "links" : { "self" : "https://api.appstoreconnect.apple.com/v1/bundleIdCapabilities/##########_IN_APP_PASS_PROVISIONING/relationships/bundleId", "related" : "https://api.appstoreconnect.apple.com/v1/bundleIdCapabilities/##########_IN_APP_PASS_PROVISIONING/bundleId" } } }, "links" : { "self" : "https://api.appstoreconnect.apple.com/v1/bundleIdCapabilities/##########_IN_APP_PASS_PROVISIONING" } }

The problem now is Apple has recently (within the last week) removed support for setting the IN_APP_PASS_PROVISIONING capability type via the bundleIdCapabilities API endpoint.
{ "errors" : [ { "id" : "####.####...", "status" : "409", "code" : "ENTITY_ERROR.ATTRIBUTE.TYPE", "title" : "An attribute in the provided entity has the wrong type", "detail" : "'IN_APP_PASS_PROVISIONING' is not a valid value for the attribute 'capabilityType'. Expected one of: 'ICLOUD', 'IN_APP_PURCHASE', 'GAME_CENTER', 'PUSH_NOTIFICATIONS', 'WALLET', 'INTER_APP_AUDIO', 'MAPS', 'ASSOCIATED_DOMAINS', 'PERSONAL_VPN', 'APP_GROUPS', 'HEALTHKIT', 'HOMEKIT', 'WIRELESS_ACCESSORY_CONFIGURATION', 'APPLE_PAY', 'DATA_PROTECTION', 'SIRIKIT', 'NETWORK_EXTENSIONS', 'MULTIPATH', 'HOT_SPOT', 'NFC_TAG_READING', 'CLASSKIT', 'AUTOFILL_CREDENTIAL_PROVIDER', 'ACCESS_WIFI_INFORMATION', 'NETWORK_CUSTOM_PROTOCOL', 'COREMEDIA_HLS_LOW_LATENCY', 'SYSTEM_EXTENSION_INSTALL', 'USER_MANAGEMENT', 'APPLE_ID_AUTH'", "source" : { "pointer" : "/data/attributes/capabilityType" } } ] }

I have opened a support ticket with App Developer as well as Apple Wallet Entitlements.
It's been 2 days and have not made any progress. Wallet Entitlements directed me to Apple Developer support even though the issue is directly related to implementing their feature set.

So at this moment the only way we can find to set the In-App Provisioning capability is manually via the Apple Developer Portal.

I don't think this In-App Provisioning issue should not prevent removal of the template_name property from fastlane. That change is needed ASAP.

I just provided this info for anyone looking for a solution/alternative to set Entitlement capabilities.

Hi folks! Thanks for looking into this.

Can this be moved forward, please? We are catering to a large open source community that relies on fastlane builds. We realize this is not an issue fastlane maintainers have introduced, but we have dozens of issue reports coming in daily due to this Apple regression in their profile API handling, and this PR looks to solve it. We would like to avoid any temporary forking of fastlane.

@rogerluan or anyone else, any insights or status updates?

This PR unblocks a critical issue. Our release is currently stuck waiting on this fix. Requesting immediate review and merge to avoid further delays. cc @reviewer-team 🙏

@visuallization cc @rogerluan Early testing revealed no issues (given entitlements are set up as part of Capabilities), so I think we should merge this and release with warning/ potential breaking change for those who rely on template_name.

Those blocked can update fastlane, and those who need template_name will need to wait until further incremental updates.

I think this would be most efficient way if maintainers agree

I whole heartedly agree here with @rasberik . Currently we can get a lot of people unblocked by merging this. The few who used to use custom entitlements with template_name can be handled in another PR. (If even necessary since there seem to be Capabilities)

I'm taking a look and will post an update here later today! 🙏

Sorry for the delay and thanks for your patience!

Could someone please merge the PR? It has been reviewed. Thank you!

Thanks @rogerluan for updating the docs! ❤️

Hey folks!

For the delay - quite a busy day 😅

This PR was merged and released as part of v2.228.0.

I'd like to welcome everyone to join the discussion I created here: #29609 so we can properly fix the custom entitlements issue for those who need/use it! 🙏

Thanks guys!

Aside from that, I learned a thing or two while debugging this issue, so I summarized everything in a new blog post of mine (not affiliated with fastlane): https://www.roger.ml/p/apple-deprecates-template-name — just thought of sharing in case you were also lost when first hearing about this 'template name' thing 😅

@rogerluan Thank you so much!