Logged into to work today with a plea from a coworker to perform my iOS voodoo magic to get the builds to stablize on release candidate. Not sure what is going, first time I’ve seen the message Exiting early, found no Swift version in executables. Not sure where this comes from but looking for it, nothing had shown up.

Certificate Authority Interlude

T mentioned she got a certificate warning from Facebook randomly while browsing through the site. Taking a look at I saw the same thing. Double checked with OpenSSL on my laptop and sure enough it failed. Worked under my Linux workstation though. Reached out to Digicert and Facebook. Digicert blamed my system configuration. Funny, as I don’t monkey with the CA setup for either Chrome or OSX on my laptop.

Shoveling the Coal

Alrighty, time to buckle this down. I’ve updated the Gem_s and _Pod_s we use. The strange complaint about _Swift not existing has since ran away. However the signing problems I had anticipated have surfaced. During the development of a long running feature branch we ran into provisioning profile and signing issues. We elected to try the automated code signing so now it’s time to pay for the gains we realized earlier. Time to track down which provisioning profiles we have, see if I can find the specific one being complained about.

I’m glad I put the diagnostic dump into the build output. I know to most developers who use the build process it’s not helpful however the information is really valuable. Using openssl asn1parse -inform DER -in $provisioning_profile | grep -A1 "<key>Name</key>" | tail -1 where provisioning_profile is the name of file we are extracting the names out of. The installed provisioning profiles can be found at ~/Library/MobileDevice/Provisioning\ Profiles. If you are interested in the certificate contents of a given provisioning profile, useful for key matching, you can dup it using /usr/libexec/PlistBuddy -c "Print :DeveloperCertificates:0" /dev/stdin <<< $(security cms -D -i apple/$profile ) >cert && openssl x509 -inform der -text -in cert.

These are not the droids you are looking for.

Must be what happened with Xcode becuase despite having the profiles installed into the correct location it can’t find them. Although I think the profile name mismatch is a problem I’m wondering if there is another problem earlier in the build and the profile name is just a symptom. The interesting message Exiting early, found no Swift version in executables. is back.

Hey! marciok documented how to setup the Keychain on Travis! Awesome!

After some reading the best candidate I have is akashivskyy’s commonet on the CocoaPod’s project.

post_install do |installer|

  puts 'Setting appropriate code signing identities'
  installer.pods_project.targets.each { |target|
      'iPhone Developer' => ['Debug'],
      'iPhone Distribution' => ['Release', 'Staging', 'Production'],
    }.each { |value, configs|
      target.set_build_setting('CODE_SIGN_IDENTITY[sdk=iphoneos*]', value, configs)


class Xcodeproj::Project::Object::PBXNativeTarget

  def set_build_setting setting, value, config = nil
    unless config.nil?
      if config.kind_of?(Xcodeproj::Project::Object::XCBuildConfiguration)
        config.build_settings[setting] = value
      elsif config.kind_of?(String)
          .select { |config_obj| config_obj.name == config }
          .each { |config| set_build_setting(setting, value, config) }
      elsif config.kind_of?(Array)
        config.each { |config| set_build_setting(setting, value, config) }
        raise 'Unsupported configuration type: ' + config.class.inspect
      set_build_setting(setting, value, build_configurations)


Didn’t hurt, but didn’t help either. Still failed though. StackOverflow has a question about it. There is hope, maybe I’m not out in no-mans land this tiem around. Within this question there is a mention of a Ruby script will switch profiles. The script points to a full Gem, XCProvisioner, which will update these for me. Good by class extension above. The only real question I have is “what are provision specifications”?

No luck on that goose chase.

Looks like the end result was updating the provisioning profiles and locking them down in the project settings everything worked.