However, I was advocating at the time to hard-code the provisioning profile UUID into the .xcconfig file to make it explicit. One of the problems with that approach is that whenever you update the provisioning profile on the Apple Developer Portal the UUID changes. So this means every time you add a new device for testing, you then need to update the .xcconfig file with the new UUID.
From what I had read, it implied that you had to use UUIDs as using the new PROVISIONING_PROFILE_SPECIFIER variable would require switching over to fully automatic signing.
After a lot of playing about I managed to get it so that you could specify the name of the profile rather than the UUID, but not have it try to automatically manage the profiles. This means that the provisioning style is still manual but that it will look for the profile by name. So if you use Fastlane and use sigh to pull down the latest profile when the build job runs, it means it will always use the latest profile.
We have three different build configurations develop, feature, and release. The first two are AdHoc builds and are for testing. The latter uses an AppStore profile for uploading to TestFlight and the App Store.
This was a talk I gave at the SWMobile Meetup in Bristol in October 2016. The talk was a lightning talk on automating the new Xcode 8 automated signing system when using it in a CI setup.
In our case we use it with Jenkins and Fastlane to automate all our builds.
Xcode 8 brings with it a new automatic code signing system. It is meant to make life a lot easier for developers, but needs a bit of work to get working with headless CI systems like Fastlane and Jenkins.