Client가 adhoc버전의 파일을 원해 보냈는데 아무리 해도 설치가 안된단다.
내컴에서도 해봤는데 어랍쇼 이게왜 안되는거지..
그래서 구글신에게 물어보았더니 아래와같이 재밌게 해결법을 제시하셨다.
Ad hoc distribution of iPhone, and now iPad, applications can feel like a circus sideshow. Developers come clambering out of the Provisioning Portal like its an undersized automobile to jump through flaming code signing hoops. Generate a certificate, create an application id, add devices, create a provision, install them all and try not to get burned. If you fail to do one step, or perform a step incorrectly, the application build results will usually guide you to the solution. But what about when you do everything by the book and you still get an error?
The majority of my distribution issues usually sprout up when Apple releases a new version of the iPhone SDK. This time it happened to be installing iPhone SDK 4. After upgrading I needed to generate some Ad Hoc distributions. Since these apps are only supposed to be targeted for iPhone devices, the "Base SDK" gets configured for "iPhone Device 4.0" and the "Targeted Device Family" is set to "iPhone". The only other parameter that needed changing was the "iPhone OS Deployment Target". This app was not quite ready for "4.0" so I switched the value to "iPhone OS 3.1.3".
I configured three apps using the described values in exactly the same fashion. The Ad Hoc distributions were generated and then zipped off to be installed. To my dismay I received an email saying that one of the apps was incapable of being installed. When the app is dragged into iTunes, nothing happens. Successive attempts to drag the app into iTunes prompts this warning:
A provisioning profile named embedded.mobileprovision already exists on this computer. Do you want to replace it?
Click the "Yes" button. Nothing happens. Click the "No" button. Nothing happens. At this point, I have no idea if I want to replace it. I just want the app to sync with iTunes. Time and time again I verify that all provisions are installed and configured properly. Of course, none of which are named embedded.mobileprovision. Search Google for embedded.mobileprovision and see what turns up. Maybe a Twitter feed from a confused and frustrated developer.
There may be a multitude of reasons why this warning would appear when attempting an Ad Hoc installation but let me share with you the reason I was experiencing this issue. Contrary to the message, the problem had nothing to do with an existing embedded.mobileprovision profile. Some secret sleuthing lead me to believe that the issue originated when I choose a different "iPhone OS Deployment Target" in the project settings. While I cannot prove this, I can at least show you some things to check manually before iAnarchy.
Every application has an Info.plist file that is created out of the box. Find it in your application "Resources" group and it may look something like this:
Notice the dictionary entry "Application Requires iPhone Environment". Notice the checkbox is clearly checked. That makes sense. We are developing an application using the iPhone SDK so it is only necessary that the application requires an iPhone environment. Now open that same file as "Plain Text" to view the XML document which makes up this info dictionary. Ours looks something like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleDisplayName</key>
<string>${PRODUCT_NAME}</string>
<key>CFBundleExecutable</key>
<string>${EXECUTABLE_NAME}</string>
<key>CFBundleIconFile</key>
<string></string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>${PRODUCT_NAME}</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>1.0</string>
<key>LSRequiresIPhoneOS</key>
<true/>
<key>NSMainNibFile</key>
<string>MainWindow</string>
<key>UIStatusBarStyle</key>
<string>UIStatusBarStyleBlackOpaque</string>
</dict>
</plist>
The pertinent key/value pair we are looking for is "LSRequiresIPhoneOS" and an XML node indicating <true/>. 999 times out of 1000 I would guess this is normal. But on my 1000th attempt to build an app I see different a value:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleDisplayName</key>
<string>${PRODUCT_NAME}</string>
<key>CFBundleExecutable</key>
<string>${EXECUTABLE_NAME}</string>
<key>CFBundleIconFile</key>
<string></string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>${PRODUCT_NAME}</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>1.0</string>
<key>LSRequiresIPhoneOS</key>
<string>YES</string>
<key>NSMainNibFile</key>
<string>MainWindow</string>
<key>UIStatusBarStyle</key>
<string>UIStatusBarStyleBlackOpaque</string>
</dict>
</plist>
Notice how the value for <key>LSRequiresIPhoneOS</key> has been modified from a (bool)<true/> to a (string)<string>YES</string>. How on earth this happened I cannot guarantee, but I can tell you that this is the reason "A provisioning profile named embedded.mobileprovision already exists on this computer". If you take the time to manually replace the <string> node with a <true/> node you may be one step closer to a successful Ad Hoc distribution.
