Our DNA is written in Swift

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 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 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 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 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:


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 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.


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


  1. Just wanted to mention the reason why Apple needs to remove the YouTube app:

    They bought a license from Google for extended Youtube use for some years, and next month it will run out. Therefore they can only use Youtube in a way, that the official Youtube terms of service (TOS) permit.

    These state:

    “You shall not copy, reproduce, distribute, transmit, broadcast, **display**, sell, license, or otherwise exploit any Content for any other purposes without the prior written consent of YouTube or the respective licensors of the Content. YouTube and its licensors reserve all rights not expressly granted in and to the Service and the Content.”

    We at tried to get an app in the Mac AppStore that tried to interact with YouTube, and they rejected it mentioning these TOS in an email. The only way for you to officially use Youtube in an app is to plainly load the YouTube website in a WebView.

  2. … unless the App is made by YouTube themselves. Obviously they have every freedom in how to access their own content.

  3. I really missed having the YouTube icon and running in fullscreen native app mode on my 4s and iPad 3 running ios6.
    I wrote a small lil html5 app
    It doesn’t have access to the special api you spoke about but it somewhat does the job of bringing back the old tv icon and running in fullscreen.

  4. “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.”

    I just got hit by that same rule for a news app. My app has a good offline mode though, with local caching. But it still got rejected, and they’re really not cooperative in telling me what is wrong compared to every other news app out there on the Store. What kind of interactivity did you add to get it accepted? I already included native iOS 5 twitter sharing of course, and native e-mail sharing too, but it doesn’t seem to be enough.

    Thank you very much for your advice!

  5. the only I way I know how “other News apps” get around this is to have the primary view be rendered without UIWebView, i.e. in a Reader-mode fashion. Then if users want to see the original content they can open a web view.

  6. My app uses a UIWebView to technically display the content, but of course it’s not just a webview showing the original content — it’s actually rendered in-app (data is retrieved from our JSON webservice, and a custom html is built in Cocoa from this data before displaying it in the UIWebView). Articles list is of course displayed with UITableViews.

    This is how it looks in the app:

    This is the same article on our website:,05116