On Apr 15, 2012, at 11:48 AM, Fritz Anderson wrote:
On 15 Apr 2012, at 9:39 AM, Alex Zavatone wrote:
On Apr 14, 2012, at 12:28 PM, Apple Xtools List wrote:
You do NOT need to have a device plugged in to create an IPA. Just select "iOS DEVICE" and the archive menu will enable. This is in Xcode 4.2 or later.
Jesus Apple, WHY REQUIRE THIS? Why gray it out unless an iOS device is plugged in OR you select iOS Device? Why not have it enabled all the time? You have to be kidding me. Xcode 4.x is not nearly obtuse enough.
Because the destination half of the build scheme is there for a reason. You have to tell Xcode where the app is going. Look at the build settings: The code-signing setting depends on the build configuration _and_ the destination device. Signing an app that's heading for the simulator is an error. Even if you miss the destination selector (it's in the largest font in the toolbar), the unavailability of an action that builds for devices should be enough to direct you to requesting a build for devices.
It's just that so many of the options that have changed when going from Xcode 3 to 4 seem to offer such a greater level of user hostility.
I can't remember running into so many problems in Xcode 3. I mean, I had no idea whatsoever that you actually could/had to select iOS Device to enable the Archive menu. I always plugged in a device to make it work.
Also, you can email an IPA. There is nothing that prevents this. It's just a file. The device will need a proper provisioning file installed on it for the app to install.
Not to an iOS device. It's useless once it gets there. I tried that on the very same device I just built to using Xcode 4.2 and iOS 5.0.1. Mail did not know how to handle the enclosure. Neither did Safari if I just put the IPA up on a URL I could access.
I've sent out dozens of .ipas for Ad Hoc and (pilot) Enterprise distributions via an (internal, passworded) web-based file sharing site. It is true that email distributions stopped working for me a few months ago. With the sharing site available, I didn't bother to debug the email problem.
Really? How? Did you just email them? Did you zip them?
I think the factor here is that when something fails now in Xcode 4, Apple's docs are so thick that we all simply rely on "who has gotten this working before, let me hit StackOverflow and look it up".
It would be simply awesome to be able to email an IPA to my other team members (to be opened and installed from the iDevice) and just plop an IPA on a http directory and actually be able to surf to it from the device and have it install.
When someone's out of the office, or doesn't even have a Mac, I want to minimize the time I spend in getting a build onto their machine. Simple is best in this use case.
So, does anyone know why we can't email an app, or just plop an IPA into a web server directory and give them the straight URL to the IPA?
Some servers (MS IIS) "helpfully" recognize that .ipa files are zip-compressed and push them (at least to IE) as the uncompressed .app package. There's a configuration option to correct the MIME type.
Well, our IIS server had the mime type properly configured, so our web tech (naturally) added the mime type and that caused a conflict. This resulted in the IPA not being able to be downloaded which too k a few more hours to figure out.
Does this work with a non Enterprise license? This matters since I'm on two dev accounts. One with Enterprise and one as a Personal developer.
As far as I know, yes. Personal developers put out Ad Hoc distributions through the Net all the time.
Unreal. We have a terminology collision then. Doesn't "Distribute for Enterprise" imply that you have to have an Enterprise license?
Can you do "Ad Hoc" distribution without the pList manifest file and ignoring the "Distribute for Enterprise" options?
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit
http://www.symanteccloud.com
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit
http://www.symanteccloud.com
______________________________________________________________________