reconfigure Xcode project with new code signing and provisioning profile settings
reconfigure Xcode project with new code signing and provisioning profile settings

procedure
- manually generate new provisioning profiles; the profiles
  auto-generated by Xcode are confusingly labelled
- storing the profiles in ~/Library/MobileDevices/Provisioning Profiles
  lets Xcode pick them up automatically

settings for code signing identity
- set this to "Automatic" everywhere
- in the .pbxproj this results in CODE_SIGN_IDENTITY = ""
- Xcode automatically uses the certificate from the provisioning
  profile to code sign; this works as long as the profile contains
  only one certificate - which is true in my case

settings for provisioning profiles
- create 3 profiles for the main target
  - Little Go development: A development provisioning profile to be
    used for the Debug and Release configurations; a development
    profile is required so that Xcode can attach the debugger to the
    process when it runs on the device; the debugger cannot be
    attached to the process if the app is installed with a
    distribution profile.
  - Little Go ad-hoc distribution: A distribution provisioning profile
    to be used for the Distribute_AdHoc configuration
  - Little Go App Store distribution: A distribution provisioning
    profile to be used for the Distribute_AppStore configuration
  - for all 3 profiles: don't use a wildcard app ID, because wildcard
    app IDs don't work with Game Center, and Game Center support will
    be added soon
- create 1 profile for the unit test target
  - in order to build & run the app on a real device, the unit test
    bundle must also be code signed, because the build schemes link the
    unit test target with the main target
  - in order to code sign, the unit test target requires a provisioning
    profile
  - we cannot use any of the profiles we created for the main target
    1) because the unit test bundle has its own bundle identifier that
    is different from the main bundle identifier, and 2) because we
    didn't use a wildcard app ID for the main target provisioning
    profiles - i.e. those profiles are all linked to the explicit
    main bundle identifier
  - to simplify things, only 1 provisioning profile is created for the
    unit test target; the profile uses a wildcard app ID so that it can
    be reused for any number of unit test targets

herzbube/littlego,herzbube/littlego,herzbube/littlego,herzbube/littlego,herzbube/littlego