App Review Advice for YouTube v2

I googled “Clint Eastwood Invisible Obama” because I was wondering why suddenly everybody is posting pictures of chairs with invisible presidents in them, hash tag #eastwooding. Of course there already was a video of the 10-minute speech to be found on YouTube, so I watched that.

The video quality bad, really bad, 360p kind of bad. I was watching it on my iPad 3 where I still sport iOS 5. This is my comfortable consumption device and where would consumption be without a YouTube client. You know, iOS 6 doesn’t have one any more. I am not referring to Mr. Eastwoods remarks when I am calling the experience painful.

YouTube is going to great lengths to prevent people from getting at the h.264 videos they are specifically preparing for iOS devices. Only the YouTube app as well as the MPMoviePlayerController’s that webviews overlay to fake embedded video know how to request the actual video data from Google’s servers. This video stream is then served as a progressive download.

The video was stalling every 3-5 minutes and frantically hacking at the play button would not have made any difference. Only if I moved the slider into the future, waited until the new position was showing and then moving it back to where it had stopped was I able to continue viewing.

There are only two qualities for YouTube videos on iOS at the moment, a “mobile” quality which is used if you don’t have WiFi connectivity and a higher bitrate quality for when you do. The selection is exclusively done via the type of connection. No bandwidth rate adapting seems to be going on as would be expected from streaming video.

Oh THIS is why Apple is killing it!

The Verge reported that the reason for Apple removing their YouTube app as of iOS 6 was caused by their license to the app expiring:

Our license to include the YouTube app in iOS has ended, customers can use YouTube in the Safari browser and Google is working on a new YouTube app to be on the App Store.

But this statement is not entirely truthful. The original YouTube.app was written by Apple themselves, there is no lack of license that would require them to remove the app. Rather the license expires that gave Apple access to the above mentioned special API and video versions that display on iOS devices. Without these YouTube.app simply has nothing that it could display.

It could still get search results via the Google Data APIs, but not videos. Those APIs are geared towards giving web developers an embeddable player, not a directly playable video URL. As I said before, Google keeps a firm grasp of their content.

Apple abhors situations where most of the value inside a stock app comes from reliance of somebody else’s content platform. Google abhors situations where they cannot affix monetize their content as they are doing so at YouTube.com. The situation kind of reminds me of what is going on with Twitter at the moment. By weaning users from third party clients the content owner (Twitter) can make sure that ads are properly delivered. YouTube is doing exactly the same, with ads being overlaid the bottom of suitable videos in a way that the user needs to close them to see all of the video.

Now Apple did an exceptionally smart move by removing YouTube. They no longer have to face the blame for crappy progressive download stalling viewing experiences. They can conveniently point the finger at Google for not taking care of the best streaming experience.

Changes to UIWebView

Essentially the view that was playing a video inside the YouTube.app and one inside Safari where one and the same. iOS detected via the object or video tag that there was a video to be embedded, inquired the appropriate h.264 file URL and then used an MPMoviePlayerController to play that. Apparently Safari will still be able to do that, although I suspect that this is due to YouTube’s now available HTML 5 video.

Over the past year YouTube has been tinkering on their HTML5 embedded player to get in on par with the Flash-based version. On August 7th the documentation about the embeddable player has been last updated to reflect the fact that the IFRAME player is no longer in BETA. In fact I just went to YouTube and clicked on the first video I saw and it turned out to be served as HTML5 video.

This means that Apple can also remove the workaround code they had in place to replace the Flash objects. Now all it needs is to look for the HTML5 <video> tag and play the attached video. And Google will undoubtedly still employ fancy JavaScript to obscure and protect the true source of the h.264 video which they no longer just produce for Apple but for everybody who has a browser capable of playing h.264.

When I vented my anger about the Invisible Obama stalling, Joel Bernstein responded:

@cocoanetics $10 says the @youtube client is basically just a web view.

— Joel Bernstein (@CastIrony) August 31, 2012

I can understand the reasoning, it is the solution that any good engineer would come up with presented the technical landscape. But I have good reason to believe that Apple would never approve such a solution.

Guidelines for YouTube.app v2

There are several reasons to be found in the app store review guidelines that also dictate the “correct” way for Google to make a YouTube client that Apple would approve for the App Store.

The “entry level” of new YouTube accounts is 15 minutes. If you posted good content for a while this is lifted and then you’re able to upload videos only limited by file size, up to 12 hours running time. Suffice it to say that much content is longer then 10 minutes.

9.4 Video streaming content over a cellular network longer than 10 minutes must use HTTP Live Streaming and include a baseline 64 kbps audio-only HTTP Live stream

HTTP Live streaming chops up videos into many little pieces and then has a manifest file that serves as an index for what piece fits where. Also multiple bitrates can be supported at the same time with the player switching between streams depending on available bandwidth. There is an “informal” spec at the IETF website that explains how it is implemented.

This requirement means that YouTube has to implement HTTP live streaming if they want to get their video to mobile devices. It is possible that they would also implement it on their website but that would again open up a pandoras box since everybody who gets their hands on a video’s manifest can get all the pieces and reassemble the best quality version outside of Google’s control.

It is more likely that YouTube will have a separate server for dealing with HTTP live streaming and have the iOS video playing views directly talk to that.

On the theory of “bunch of web views”:

12.3 Apps that are simply web clippings, content aggregators, or a collection of links, may be rejected

This is another hint. Apple does their best to reject apps that are collections of web views. YouTube definitely IS a “content aggregator” or maybe even a “collection of links” (to video pages). If it looks like it could be a browser view then Apple will tell you that you should do it as a mobile web app and not a native one.

I myself once got hit by this rule. The way around it was to add a good offline mode and interactivity that is not possible with only UIWebViews. From this experience I know how serious Apple takes this.

17.1 Apps cannot transmit data about a user without obtaining the user’s prior permission and providing the user with access to information about how and where the data will be used

YouTube is collecting information about their users for purpose of ad targeting. The new app will definitely some privacy settings and a privacy policy.

Finally this relatively new section should prompt Google to go well beyond a set of UIWebViews:

10.6 Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good, it may be rejected

From these facts I am deriving my prediction that the Google-made YouTube player app will have to far exceed what we have seen until now.

Conclusion

Google might try the “easy way out” solution with a bunch of UIWebViews, but it is extremely likely that Apple will look really hard at what they come up with. Any sub-par experience that violates the above mentioned guidelines will not be accepted into the App Store. Even more so because we know that Apple and Google are on competitive terms.

The review guidelines are there fore every developer to measure up against, so Google better pull their act together and finally give as a good HTTP Live Streaming based solution. If Google just took the look of the current YouTube app and reimplemented that with UIWebViews for the players then they can be certain of a rejection.

Here’s their chance of showing us that they are able to provide a better video viewing experience than Apple ever was able to.

Categories: Business