From f973926aa400967e5ea45d08cf6fa2620d8cfdd4 Mon Sep 17 00:00:00 2001 From: "Developer @ Loverde Company" Date: Fri, 11 Sep 2026 13:36:56 -0300 Subject: [PATCH] fix: renew provisioning profiles by exact name, for both app and extension targets The prior force:true fix only touched the main app's profile and let sigh name it ' AppStore' - a different name than the one manual signing expects (PROVISIONING_PROFILE_SPECIFIER = 'LC Prov PediFoods Dist Profile' / 'LC Prov PediFoods Dist Push Profile', baked into PediFoods.xcodeproj per target). Xcode resolves profiles by exact Name match against installed .mobileprovision files, so it never found sigh's freshly-created one and kept falling back to the stale, wrong-certificate profile under the old name - the extension's profile was never touched at all, since sigh only acts on the app_identifier it's given. Added renew_provisioning_profiles (shared by beta and release), calling get_provisioning_profile once per target with an explicit provisioning_name matching what the project actually expects, plus force: true so each is regenerated against the team's current certificates. --- fastlane/Fastfile | 52 +++++++++++++++++++++++++++-------------------- 1 file changed, 30 insertions(+), 22 deletions(-) diff --git a/fastlane/Fastfile b/fastlane/Fastfile index bc5d738..183bbfe 100644 --- a/fastlane/Fastfile +++ b/fastlane/Fastfile @@ -34,20 +34,38 @@ lane :assemble do |options| ) end +# Manual signing (PROVISIONING_PROFILE_SPECIFIER baked directly into +# PediFoods.xcodeproj's build settings, per target) means Xcode resolves +# a profile by matching that exact Name string against installed +# .mobileprovision files - not by bundle identifier alone. Without an +# explicit provisioning_name:, sigh names a freshly (re)created profile +# " AppStore" by default, which doesn't match the +# project's expected names ("LC Prov PediFoods Dist Profile" / "LC Prov +# PediFoods Dist Push Profile") - Xcode then can't find it and falls +# back to whatever stale profile happens to already be installed under +# the old name, which is exactly the doesn't-include-this-cert error +# force: true alone didn't fix. Also needs one call per target: sigh +# only touches the app_identifier it's given, and the +# NotificationServiceExtension has its own separate bundle id. +private_lane :renew_provisioning_profiles do + get_provisioning_profile( + api_key_path: "fastlane/apikey.json", + app_identifier: "com.br.pedifoods.app", + provisioning_name: "LC Prov PediFoods Dist Profile", + force: true + ) + get_provisioning_profile( + api_key_path: "fastlane/apikey.json", + app_identifier: "com.br.pedifoods.app.NotificationService", + provisioning_name: "LC Prov PediFoods Dist Push Profile", + force: true + ) +end + lane :beta do |options| desc "Build and upload to TestFlight" - # force: true - without it, sigh just downloads whatever profile - # already exists on Apple's servers as-is. This CI keychain's - # distribution certificate is a different one than whatever the - # existing profile was last generated against, so a plain (non-forced) - # fetch produced a profile that doesn't include this machine's cert - - # "Provisioning profile ... doesn't include signing certificate - # 'iPhone Distribution: Loverde Company LTDA (K4E5BZMM4V)'" at archive - # time. Forcing a renewal makes sigh regenerate the profile against - # the team's currently valid certificates instead of reusing a stale - # one. - get_provisioning_profile(api_key_path: "fastlane/apikey.json", force: true) + renew_provisioning_profiles assemble @@ -65,17 +83,7 @@ lane :release do |options| # if you have an apikey.json file (https://developer.apple.com/documentation/appstoreconnectapi/creating-api-keys-for-app-store-connect-api), fastlane can automatically fetch certificates and the ASC authentication information #get_certificates(api_key_path: "fastlane/apikey.json") - # force: true - without it, sigh just downloads whatever profile - # already exists on Apple's servers as-is. This CI keychain's - # distribution certificate is a different one than whatever the - # existing profile was last generated against, so a plain (non-forced) - # fetch produced a profile that doesn't include this machine's cert - - # "Provisioning profile ... doesn't include signing certificate - # 'iPhone Distribution: Loverde Company LTDA (K4E5BZMM4V)'" at archive - # time. Forcing a renewal makes sigh regenerate the profile against - # the team's currently valid certificates instead of reusing a stale - # one. - get_provisioning_profile(api_key_path: "fastlane/apikey.json", force: true) + renew_provisioning_profiles assemble