So, it only works if you've archived the app once?
Why doesn't it throw an alert stating "don't do that" or "By using this distribution profile, this project must be archived first to run on a device. Please consider using a development profile", instead of launching the app, then quitting it, without any message why it was quit?
The issue(s) here are this:
For that debug setting, there really needs to be a notification that states what will happen if you select a distro profile - or simply do not allow it. On Oct 24, 2012, at 1:29 PM, Fritz Anderson wrote: The StackOverflow thread concluded with
You can't run apps signed with a distribution profile by running them from Xcode. They crash shortly after launch. Well, yeah. A distribution profile, for untethered installations of distribution-signed .ipa's, will not work for tethered installations of never-archived apps. If you want to debug, use a development provisioning profile and a developer identity; those are for tethered development. The two are different because tethered and untethered are different.
The defaults make this really, really easy if you leave them alone: The wildcard Team Provisioning Profile will be selected by default, and the Debug > Any iOS SDK setting is for "iPhone Developer" (no qualification with the name of the developer), which will automatically match to the development certificate of whomever is doing the build. (Note the sub-setting of Any iOS SDK. That's in the template, too, and I assume it's for a reason.)
But at 4 AM, when you're trying to push an app out for your CIO's demo on another continent, it's 4 AM and if you have one brain cell still functioning, you're lucky.
Or at 9 PM and you're working on a drop from your interns and you have to change the code signing to get the project to build at all, it's way too easy to assign the wrong profile in the code signing.
It's also really easy to get the defaults to do the wrong thing. Take this example:
I'm a member of two dev groups, my personal and our corporate. Whenever a new iOS project is created, Xcode starts out by setting the Company identifier as me, instead of letting me pick which profile I am creating this project in. As a result, I have to change the code signing on all new projects to get them to work against our Enterprise license.
All of the above situations have happened to me in the past month and getting no message why the problem is occurring doesn't make anyone like the dev environment or the provisioning process any more. It's a red herring that the configuration is called "Debug." Xcode makes no inferences from the name alone. The template prefills the developer certificate in that configuration, but that's a matter of a setting in a configuration that happens to be named "Debug," and that the Run scheme happens to use.
Yeah, I think it would make much more sense if it said "Development". That there is no console message is disturbing, but Xcode's complaint is a clue: The iOS kernel blocks invalidly-provisioned apps from being launched, and the debugger never had a process to attach to. I'm curious to know what the device log (under the device's entry in the Devices organizer) says.
I never got that complaint. All I got was "Process can not be found". There was no message in the console or in the device's log in the organizer. Thanks for detailing how this works. You're on my Christmas list.
— F
On 24 Oct 2012, at 10:50 AM, Alex Zavatone < email@hidden> wrote: From what I was able to tell, this exact behaviour when trying to build and run an app on a device:
App compiles without error App launches on device App processes and displays first screen App suddenly quits with no warning or error Xcode reports that "Process can not be found" No error logs in the device console or in Xcode are reported
is caused be a distribution profile being assigned to:
Target iOS Application Build Settings Code Signing Code Signing Identity Debug
So, if a distribution profile is assigned to an iOS app's Debug build configuration, the app will build properly, launch and quit without a warning, or anything explaining why this happened.
If this is true, then this is really nasty since information on this is scarce and Xcode lets you assign any provisioning file to this configuration. The only way I was able to track this down was through a 1.5 year old comment on StackExchange about this being a known open bug.
If this is indeed the case, why is something like this still open, why doesn't Xcode report an error when attempting to run with a dist profile and why does Xcode let you apply a dist profile to the debug build configuration in the first place?
For an issue of this consequence to throw no error at all and even be allowed in the first place is pretty bad.
Here's the SE link that refers to the issue
|