This is a follow-up to the article Developing Content for the Apple iPhone first published on ContentDeveloper.com back in January when the iPhone was announced. There were a couple key questions impacting content developers left unanswered in that post that we’ll try and answer here.

Question 1: Will the Safari browser included on the iPhone include the Flash plug-in?

The answer, currently at least, appears to be no. Walt Mossberg suggested during his iPhone launch day Charlie Rose appearance and in a recent Mossberg Mailbox that this lack of a Flash plug in may be solved in the near future with a software update for the iPhone delivered via iTunes. Other observers – with hypotheses ranging from Apple not wanting to help Adobe, to the argument that Flash will make it too easy for users to bypass wireless carrier revenue generating SMS gateway and voice services – remain slightly more skeptical that Flash will arrive anytime soon on the iPhone.

Let’s hope Walt is right.

One bright spot in our Flash testing was that if you’re using swfobject to deliver your Flash content, and you have your non Flash option set up correctly, that combo appeared to work well in delivering alternative non Flash content to the iPhone.

Before we leave the topic of Flash on the iPhone, on a lighter note here’s one of the better spoof commercials regarding the matter:

OK, next question -

Question 2: How will the iPhone handle open source third party audio/video content?

Last summer ContentDeveloper.com put several mobile devices and carriers through some tests to see whether they would allow a user to access audio and video content from publishers beyond those who had formal content agreements with the mobile carriers.

The challenge was pretty simple. SMS the device a link to a third party 3GP and MP3 file and see what it does with it. Passing the test meant the device would allow the user to access the link from their text messaging screen (or a menu available on that screen) and having that audio or video play, or at least download so that the user could watch it on demand with another application on their device.

Those tests revealed that some mobile devices and certain wireless carriers were pretty open. Others, not so much.

Here’s how the iPhone performed under similar testing:

First, we texted a raw link to an MP3 file. The iPhone passed the first part of this test as the link was hot and the user could click on it.

This feature is an important one for the small to mid sized independent content developer wanting to deliver mobile content. Our earlier tests revealed that some devices, especially on Verizon Wireless, did not make this link hot. If a device introduces that limitation, that means that the user may not be able to easily access some third party content delivered via SMS.

Now, what happens when the user clicks on the link to the MP3 file in their iPhone? Good news here too. The MP3 file located at the URL we texted loaded up and played just fine. This is a big plus for content developers wanting to deliver on demand audio content in situations where delivery through iTunes may not be the best option, or even an available option.

And if you’re using tools from innovative companies like Mozes to deliver your MP3 audio content via SMS, then you should be in good shape with your new iPhone based audience as well.

So, when it comes to delivering third party audio content via SMS, the iPhone gets a thumbs up.

Now, what about video?

The Apple iPhone Developers Connection offers a comprehensive list of rich media mime types that Safari on the iPhone should support, including many types of video:

iPhone mime types from the Apple Developer Connection

For our first video challenge we selected 3GP from the list and SMS’d the iPhone a link to a legacy 3GP video made with the old Nokia Multimedia Converter. This time the link was again hot, but when we clicked on the link, the iPhone would not play it. The same player that handled the MP3 file in our previous test launched as before, but this time nothing played.

Thinking perhaps the problem might be the codec, we next tried texting a link to a video encoded with the always reliable Sorenson codec.

Same result, no play. Hmm?

At this point I double checked to be sure that the Apache server we were using to deliver these video files supported byte-range requests which the iPhone requires. Apple provides info on a cURL command you can run to verify whether your server is configured correctly in this area:

curl --range 0-99 http://example.com/test.mov -o /dev/null

(substitute your mov file for the example.com address)

The server checked out fine here.

I’d heard that videos for the special iPhone YouTube video player were being encoded in the more recently introduced H.264, so we gave that a try.

Same result. No play.

Well, maybe it is the raw link to the movie that is causing the problem. So we launched Safari on the iPhone and manually visited some web sites that had QuickTime movies embedded.

Same result. No play. So back to the drawing board.

At this stage of our tests to help simplify things we ditched our other video compression tools we had been using like Compressor and Premiere and were now relying solely on QuickTime Pro to render out our test videos.

We set our compression profile as follows:

Screenshot from QuickTime Pro

These settings worked.

We texted the iPhone a link to a video compressed with that profile and it loaded it up and played just fine.

For another test we adjusted the setting slightly and turned on the Internet Streaming – Fast Start option and this video played as well. So far so good.

Next test, we turned on the Fast Start – Compressed Header option. And this test failed, suggesting a likely culprit for the failures in our earlier tests.

Apple has done a good job informing developers that the iPhone currently does not support traditional video streaming like RTSP, but for content developers delivering on demand video content it appears from these tests that the iPhone does support Fast Start streaming, or progressive download as it’s also known as, so long as you leave the compressed header off.

One area here that still remains a little cloudy though is that in our earlier tests the QuickTime videos compressed with Premiere had no internet streaming set and yet they still failed to play on the iPhone? Didn’t come up with an answer for that one, but now that we actually got some SMS delivered video playing on the device we decided to try a few more compression profiles.

For the next test we sent the device a link to a m4v file and the iPhone returned a giant string of ascii text back to us. This is a sign that the m4v mime type wasn’t configured correctly on our server that was dishing out these test files. A quick inspection showed that was indeed the case so we added the following line to our mime.type file -

video/x-m4v m4v

We then sent a link to a file using the QuickTime Pro iPod preset which uses the h.264 video codec and the AAC audio codec to create a m4v file.

This video played fine, but worth noting here is that in our next test we chose the h.264 and AAC codecs manually, as opposed to with the iPod preset, and these files would not play on the iPhone. Further testing also suggested the device can be somewhat finicky regarding the audio codecs that you choose.

Based on our test results so far, the compression profile that may be the current best fit for those searching for universal web delivery from one video file is Sorenson 3 video, IMA 4:1 audio with the progressive download option enabled. This setting roughly delivers the same user experience whether you’re visiting via iPhone or desktop, Mac, PC etc…, all from one file. The downside with this approach of course is that users accessing via EDGE will have to wait for their video to download. Another option is to use the reference movie approach, encode multiple versions of your video and let QuickTime’s auto-select feature deliver the best version based on the user’s device and bandwidth. That’s a solid choice, but it somehow feels retro for a device with such a forward thinking spirit.

Overall though, despite some drawbacks like the apparent inability to store content delivered via SMS on the device, the iPhone and T have demonstrated they are reasonably open for users to receive third party audio and video content from content providers and publishers who don’t have formal relationships in place with the wireless carrier.

And that should be a good thing for the content marketplace and content developers.

Special thanks to Abby and Martin for their help with these tests.

———-

Related item: For those using SMTP to communicate with mobile devices via open source sms, the old Cingular address worked well on the iPhone we were testing -

tendigitnumber @ mobile.mycingluar.com

as well at the ATT Wireless address

ten digit number @ txt.att.net

Related item: If you’re using tools like feed2js to remix and mashup RSS content, good news. All our feeds delivered via this method displayed correctly with Safari on the iPhone. With AJAX apparently being the de facto iPhone SDK for now, the client side javascript processing looked strong in our tests.

Related item: During some early tests we were running in the ATT Wireless store, the iPhone Safari browser kept shutting down intermittently. This happened on three different devices while visiting several unrelated sites. A user in the apple support forums thinks this appears to happen when you try to zoom before a web page loads fully. That would be consistent with my experience. But some further testing with a new iPhone user in our office turned up no problems like this. Will have to wait and see if this turns out to be a problem in need of a patch.

Related item: We wanted to see what happens when you right click on a link, but after a brief stab at RTFM, and various Google searches, no information surfaced on how to right click in Safari on the iPhone. If you’ve figured this one out, please do share.

Related item: Stories about iPhone security vulnerabilities uncovered by Independent Security Evaluators continue to circulate. Keeping track of security issues is a must for content developers working on any platform, and the iPhone will be no different. Digital Media Wire offers some takes on the iPhone backlash.

Related item: Here’s how AAPL has performed during first month of iPhone release.

Related item: From Geek Entertainment TV, Dontcha wish your cellphone was hot like me -

Related links: iPhone Developers Camp; iPhone Application List; iPhoneWebDev Google Group

tags: Windows Media Video; Real Video; Flash Video; QuickTime