On Feb 17, 2014, at 10:03, Fritz Anderson < email@hidden> wrote: On 16 Feb 2014, at 5:38 PM, Steve Christensen <email@hidden> wrote:
Way back in the Xcode 3.x and iOS 2 or 3 days, we ended up creating a wildcard development profile with a bundle ID of the form com.mycompany.foo.* so that we could work on a number of projects without having to create a new development profile for each app. (This was before the team provisioning profiles.)
Fast-forward to Xcode 5 (5.0.2) and I just recently noticed that I am “blessed” with a bunch of fully-resolved development profiles: com.mycompany.foo.app1, com.mycompany.foo.app2, … com.mycompany.foo.appn, in addition to the original com.mycompany.foo.*. If you look at them in the developer portal, they’re all marked as “managed by Xcode”.
This is the way I connect the dots — I’ve never seen it spelled out.
Development provisioning under Xcode 5 is a superset of what it was. Before, development provisioning profiles governed only one privilege: Running the app on a device tethered (+/-) to the development machine.
Not exactly. Provisioning profiles have always (even back in the Xcode 3.1 days) governed several privileges. A wildcard profile works well, because if that’s the only privilege, it can apply to all apps.
Indeed. If that is the only privilege you care about, then there is no need to use anything other than a wildcard App ID Even better (Xcode 3.2.late?), Developer Services can refer to its roster of team members, and reissue a wildcard “Team Provisioning Profile” that updates itself whenever the roster changes. It’s automatic, and people don’t have to do the coordination themselves.
Indeed. Since the wildcard profile is often “good enough” for most people, we decided to make it simple to create and update such a profile automatically. Xcode 5 does a lot more with application privileges. The Target editor lets you apply for additional development privileges, such as iCloud, though the IDE, without having to go into the App-ID editor in the portal. Flip the switch, accept the automatic changes to the target frameworks, and Xcode and Developer Services negotiate the rest behind the scenes.
But that means that, potentially, every app can have different sets of privileges — and for services that need API keys, there’s no way to share them. A single wildcard Team Provisioning Profile can’t support that. Each application has to have its own development profile that grants the app the unique privilege set the app needs.
Unless you’ve explicitly turned on a capability that requires an explicit App ID, Xcode will still use the generic, wildcard profile as appropriate.
(Yes, I believe this must entail expanding the content of provisioning profiles to things that had previously been, and still are, in Info.plist and the entitlements file.)
Not so. There was no change in how profiles worked or in what information they contained in Xcode 5. The only changes were the addition of the ability for Xcode to manage these dependencies automatically. Technically speaking, there is nothing that Xcode 5 can do that you couldn’t do manually before; the process that Xcode 5 goes through when you enable one of the capabilities in the project editor is the exact same process that you would have had to do yourself in Xcode 4. Those are still team profiles — they (are supposed to) update automatically as the team changes — but they can’t be wildcards. So you get a provisioning roster that is much longer and harder to read (because, of course, the part of the profile name that tells you which app it attaches to always runs off the side of the column).
At least, that’s my best inference.
And a decent bit of inference it was :)
|