Re: more provisioning fun
Re: more provisioning fun
- Subject: Re: more provisioning fun
- From: Fritz Anderson <email@hidden>
- Date: Mon, 17 Feb 2014 12:03:06 -0600
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. A wildcard profile works well, because if that’s the only privilege, it can apply to all apps.
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.
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.
(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.)
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.
— F
--
Xcode 5 Start to Finish
Now in production, on sale late March/early April
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden