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.

The phrase "FBCDN image is not allowed in stream" does not have much meaning to most of the natural world, but to a developer integrating with Facebook features this phrase is a nightmare.  Over the past year we have been developing iPhone apps that will process images in unique ways.  We thought it would be interesting to allow users to share these images with their friends on Facebook, if they have any friends.  The normal procedure is a two part process.  First, a user would upload the image to their very own photo gallery hosted on their Facebook profile.  When that is successful the user could then choose to publish a message to their stream which would include a link to this recently uploaded image.  It was fast and it was fun.

About two weeks ago I noticed that some previously published feeds, and any new feeds, were missing the shared photo.  Immediately I thought there must be a problem with the code.  Let me take a look.  HMMMMMMM.  Everything looks good, but why is the image missing?  Wow, I don't have much time to continue debugging this.  Let me check Facebook Developer Documentation.  Nothing here about missing images.

On the 17th of June 2010 the shock was felt. I was testing a new iPhone app we are working on for in20years.com.  The Facebook integration was complete and I attempted to publish a message to my Facebook profile using a Facebook Photo Gallery image.  The process came to a halt and the dialog read, "FBCDN image is not allowed in stream ..... You can see this because you are one of the developers of the app."  Ouch.  I could indeed see this message and yet I have no idea what it means.  Endless Google searches return nothing.

With shifting priorities in schedule we decided to let this go for the weekend.  Monday morning was a bit more informative.  Facebook Developer Forums erupted in outrage that all existing apps ceased to work due to this error. The official word came through an RSS feed reading:

Serving Images in Stream Stories
Jun 18, 2010 3:21pm

We no longer allow stream stories to contain images that are hosted on the fbcdn.net domain. The images associated with these URLs aren't always optimized for stream stories and occasionally resulted in errors, leading to a poor user experience. Make sure your stream attachments don't reference images with this domain. You should host the images locally.

So what does this mean?  Well it depends on your point of view.  It means Facebook does not have enough consideration for current applications using images in the fbcdn.net domain to grace the developers with a warning of this new policy.  I was experiencing problems for weeks before this statement was released.  It means that developers cannot rely on any implementation of a Facebook API component to behave the way they expect on a day to day basis.  It means that developers must find a way to host their own images if they plan on placing them in a Facebook Stream.  It means we must react with Ninja-like reflexes.