Disable Wildcard iOS Provisioning Profile by Default

Feature Requests Steps
,
1

I found this issue after getting the same provisioning profile error:

It would be helpful if the BitriseBot-Wildcard certificate was turned off by default, because the default behavior that a user currently experiences is very counterintuitive. If I have a problem with a certificate or provisioning profile, I expect my build process to give me an error that helps me diagnose the problem, not a silent fallback to a certificate that will not actually work.

What happened:

  • Trigger build in Bitrise
  • Build succeeds and uploads to Hockeyapp
  • Try to install app from HockeyApp onto iOS device
  • See error message about app not being valid for device
  • Double-check provisioning profile on Apple Developer site
  • Re-download and install provisioning profile and certificate into Bitrise
  • See same error message about app not being valid for device
  • Question all life decisions that led to writing software for iOS
  • Read through Bitrise logs
  • Notice that BitriseBot-Wildcard provisioning profile is being used instead of the desired provisioning profile
  • Infer that there is a problem with how the desired provisioning profile is being specified
  • Find and fix problem
  • Build proceeds as expected

What should have happened:

  • Trigger build in Bitrise
  • Build error: no valid provisioning profile found
  • Question all life decisions that led to writing software for iOS
  • Read through Bitrise logs
  • Find and fix problem
  • Build proceeds as expected
2

Hi @calvin.fisher,

Thanks for the Feature Requests, and I definitely feel your pain re:

But of course there’s a reason why we include that wildcard profile.

You can read all the details here: http://blog.bitrise.io/2016/06/07/automatic-ios-wildcard-development-code-signing-files.html + you can find a solution to disable it (“If you don’t like this solution …” section).

In short, this was required due to changes in Xcode 7 / 8, and especially when Carthage started to get more popular. Without this wildcard profile Carthage (and CocoaPods for framework dependencies) failed to run as it explicitly require(d) a wildcard development profile. So even if your own project did not need that and you uploaded all the required signing files for your project, dependency compiles might still have failed due to the missing wildcard dev profile.

We’ll definitely investigate whether the wildcard profile is still required / the best solution (out of all the available, most likely even worse ones), and we also work on other code signing related features :wink:

3

Anyone who’s ever touched a provisioning profile knows that struggle! :laughing:

I do mobile development exclusively with Xamarin and have never even heard of Carthage. I’m sure it’s the same for people who use React Native, etc.

Since this sounds like a workaround specifically for an issue with Carthage/CocoaPods, maybe the code signing step could have some kind of detection to see if the project uses one of those, and provide a helpful error/warning message explaining how to set the default profile URL, rather than just enabling it by default?

1 Like
4

You’re right to some extent, but not that simple. Carthage/CocoaPods can very well be used (and in fact it frequently is) in a React Native project for example. AFAIK only Xamarin does not leverage those native iOS dependency managers.

But in case of Xamarin you’re absolutely right, we definitely could configure the base configuration for Xamarin projects so that the wildcard profile will not be used - I’ll discuss this with the related team :wink: