Hacker News new | past | comments | ask | show | jobs | submit login
Playboy bypasses Apple's App Store, makes a web app instead (businessweek.com)
89 points by vladd on May 22, 2011 | hide | past | favorite | 59 comments



Lots of people in this thread are excited about Playboy bypassing the App Store but no one is talking about the huge user experience downsides that it brings up:

* Have to sign in every time you load the app.

* Herky jerky animations & orientation switching

* No offline access!

* Low-res images that are tough to read... in a magazine app

Granted these issues could be remedied in whole or in part if the web app was built with a little more thought & care, but the fact is that it wasn't: this is the user experience people will get when they view this web app.

I work on the web, and I build native apps for the iPhone & iPad. The reason I like building native apps is because the user experience is better. Everything's faster and smoother. If developers in here are putting technopolitics above the user actually using the app, then I think people need to re-evaluate why they build software in the first place.


There is an underlying assumption here: that Apple and the AppStore have the user's best interest in mind. The assumption is that the developer and Apple are both working towards the same thing.

That's been proven untrue with walled garden providers over and over again. Ever see a commercial for an Apple product? Apple has one thing in mind: the farming out of development to tens of thousands of little starry-eyed developers scattered around the world. As long as those guys keep cranking out things that make Apple look good and advance corporate policy, they're there to help both you and the user.

If you want to write inside the walled garden, have fun with it. Providing value to the user is the goal, right? In some scenarios it probably makes sense to develop in that fashion.

But not in every scenario. Don't go into this thing either blinded against using an AppStore or blinded towards using one. The truth is a lot more complex. I could list a dozen scenarios that easily would lead me to choose a stand-alone web app. "Technopolitics" or my personal opinion of Apple has nothing to do with it.


I could list a dozen scenarios that easily would lead me to choose a stand-alone web app. "Technopolitics" or my personal opinion of Apple has nothing to do with it.

I'd be curious to know what those scenarios are, and whether your choice would actually be user-experience driven rather than based on developer preference or business constraints (such as insufficient resources).


If they could get equal adoption without the App Store, they'd be making a LOT more money on the same number of customers. That's the key advantage.

These app stores, the Mac App Store, Android Market, the App Store, they give you very little considering the gigantic margin they take from you. It's almost intolerable. It seems it is intolerable for at least one major enterprise, Playboy.


Historic margin at stores: ~50% (varies widely) Apple's margin, described here as "gigantic" and "almost intolerable": 30%


> If they could get equal adoption without the App Store, they'd be making a LOT more money on the same number of customers. That's the key advantage.

Apple started high at 30%. If competition dictates, they can lower that percentage at any time.

They're also free to renegotiate a lower rate with specific content producers.


What competition? Apple isn't going to let another app store on the iPhone so developers will continue to be forced to cough up 30% of their earnings. Even if the Android Marketplace fees went to 0%, consumers don't care. You may think developers will be more prone to writing apps for the Android exclusively but they won't because they would still be missing out on their 70% revenue from the iOS app store.


> What competition?

We were talking about the web. If there's a risk of webapps becoming competitive with native applications on the basis of that 30%, Apple is free to lower it.

Given that our clients have been discussing implementing webapps (in addition to their existing Android and iOS applications) entirely due to the 30% issue, this isn't that crazy.

> You may think developers will be more prone to writing apps for the Android exclusively but they won't because they would still be missing out on their 70% revenue from the iOS app store.

I'm not sure what you're basing this on; Android is a rapidly growing portion of our media clients' in-app purchase business.


> We were talking about the web. If there's a risk of webapps becoming competitive with native applications on the basis of that 30%, Apple is free to lower it.

How much you want to bet when that happens, Apple will release an update for iOS that cripples Safari and takes away some functionality in order to force developers to write native applications.

> I'm not sure what you're basing this on; Android is a rapidly growing portion of our media clients' in-app purchase business.

When you mentioned competition I just assumed you meant developers abandoning iOS and developing exclusively for Android (thus making customers want an Android device more and drive market share away from iPhone). I didn't think the competition you were thinking of was more and more web apps coming up to circumnavigate the 30% cut.


>It seems it is intolerable for at least one major enterprise, Playboy.

No, the real reason Playboy is going the webapp route is because Apple would never approve the content of the app. Apple knows that the web app experience is sucky compared to native apps regardless of the HTML5 hype. Even after a year passed after Jobs' pro-HTML5 and anti-Flash post, HTML5 still sucks, and Apple seems to be in no hurry except to pay lip service. After all, they have financial stake in native apps being better, especially for subscription based content,


I am admittedly entirely biased towards web apps, but please dont say that people arguing for the web are doing so from a "technopolitics" point of view.

My arguments for using open web technologies are purely based with the end users in mind, it may require some short term compromises in some areas of user experience (performance), but that doesnt mean we arent arguing for the best user experience possible.


It "compromises in some areas of the user experience" but you're saying open web technologies present the best user experience possible? How?

The App Store is one tap away. Hundreds of thousands of apps all neatly categorized and sorted a bunch of ways. User reviews right on each listing with an overall rating count that's impossible to miss. One-touch purchasing, or, if free, one-touch downloading. It downloads in the background and can be paused/resumed whenever you want.

So exactly how will open web technologies (existing now, or in the future) be a better experience for users than the App Store?


> It "compromises in some areas of the user experience" but you're saying open web technologies present the best user experience possible? How?

First, that's now what he said. "My arguments for using open web technologies are purely based with the end users in mind," and "but that doesnt mean we arent arguing for the best user experience possible."

Basically, you want to know this: "So exactly how will open web technologies (existing now, or in the future) be a better experience for users than the App Store?"

In context, it allows app makers to build the apps they want for their customers without requiring Apple approval that could/would prevent said app from being deployed.

Any discussion of iOS development and native v.s. web apps must include the app store and it's conditions. If your app cannot commit to those conditions, then you cannot release an app.

You could ignore the answer, but then you are faced with answering the question: How are native apps a better option for all cases? The answer, of course, is they aren't. Any argument otherwise is being dishonest.


Web apps and the apple appstore are not mutually exclusive, you can have web apps in the appstore (or the google chrome / android market / amazon app store)

I am not arguing about the user experience involved in using the appstore


and to point out the advantages I see in web apps

- Consistent used experience, the same app can be built for every device, not duplicated (at least) 3 times which will lead to inconsistencies.

- Intercommunication, I can right now, open a web app on my mac, start using it, then send my current screen to my phone

- Availability, I have an app on my phone with my data that works offline, I still want to be able to access thing same thing using someone elses computer / phone.

Thats a few quick ones off the top of my head, we all know the common benefits of web applications, they dont need to be thrown out the window because of some low hanging fruit that can be fixed in the frontend, I mean not having offline access is not a fault of being a web app, it is purely a technical issue that can be fixed on playboys side.


> - Consistent used experience, the same app can be built for every device, not duplicated (at least) 3 times which will lead to inconsistencies.

Unfortunately, this also means that every application will offer an inconsistent UX to their users, as there is no adherence to any platform standard.

> - Intercommunication, I can right now, open a web app on my mac, start using it, then send my current screen to my phone

The ability to save state on a server is not constrained to applications running in a browser.

> - Availability, I have an app on my phone with my data that works offline, I still want to be able to access thing same thing using someone elses computer / phone.

You can do this with native applications as well, however, one of the significant market shifts that has occurred is that you don't have to.

Logging into websites from public computers was always a significant security risk and a trade-off between user experience and convenience; it was simply an inefficient solution to the problem of not having your own, locally trusted hardware.

With the introduction of lightweight, high-performance mobile computing devices using always-on internet access, the need to access your Yahoo mail from a 3rd party's computer has all but disappeared for a large (and growing) percentage of the population.


I think the end user gets a lot more with a native app. However a company using a web app effectively gives apple the middle finger. It might be worth considering in the future as current web technologies such as local storage become more mainstream, at which stage it's plausible to say that apple's dominance may be overshadowed by the many vendors producing android devices.


I prefer web apps and open standards as well, but I think another "feature" in this case is that users don't have to have an app labelled "playboy" on their phone. My kid is always grabbing my phone to see pictures or play a game. I won't ever download a playboy app! Lots of guys have wives that would be offended as well.


The article emphasizes those drawbacks while seeming to imply it's an unavoidable result of their strategy. I don't see that they are; it sounds more like inadequate or poor development and product management.

For instance, why would you have to sign in every time? You can easily use cookies or HTML5 database to solve that in Mobile Safari.

Low Res images, too - since when is Mobile Safari constrained in that respect?


All those concerns are possible to remedy.


Thanks to external constraints a big player is going into the right direction (for a certain set of applications where native is not really needed).

Also very cool of Playboy to prominently show the historically significant "Lenna" in their advertising.

Very fitting indeed.

http://i.playboy.com/index2.html http://en.wikipedia.org/wiki/Lenna


> Thanks to external constraints a big player is going into the right direction (for a certain set of applications where native is not really needed).

While 'not really needed' is a literally true statement, the same could be said for running water and in-home heating.

Native applications are 'needed' if you want to provide the best possible user experience; Playboy is simply doing the best they can given the constraints under which they're forced to operate. This isn't the "right" direction, it's simply the only one available to them.


I do agree with all of this but I like to think that with some collective effort we'd only be some iterations away for these kind of apps ("Shiny Real World Magazine Simulation") to evolve into something of equal, possibly even better quality?

I don't talk about e.g. games or navigation apps nor am I denying the polish which went into the different native mobile frameworks/platforms.

I, for one, welcome our heterogenous appscape.


Found the original (non cropped) image and more info: http://www.cs.cmu.edu/~chuck/lennapg/


I followed your link and it said the reason the picture of Lenna (from a 1972 edition of Playboy) became significant was for its first use in 1973 in an academic conference paper on image processing.

Yet it also states that Woody Allen also used the image in the film Sleepers in the same year.

Woody Allen hardly got the idea from reading academic conference literature.

Makes me think that the image must have made an enormous impact on its release in 1972. Makes you wonder what was cropped, although her face is very nice


Amazon could to this, too, if they are forced to give all their profits to Apple after end of June. They were supposed to launch a web app reader soon anyway. They demo'ed it a few months ago.

But why didn't Playboy use offline cache or something? Is it because the Mobile Safari is limited in that regard? I have a feeling Apple will hold off improving that feature for a long time.


Considering the way Safari caches pages, you're lucky if you're not forced to reload a page when switching between Safari windows, let alone apps. The Safari cache size on iOS devices is cripplingly nonexistent, and I wouldn't be surprised if it only used RAM and no disk caching.


I think if you explicitly specify a cache-manifest, it caches it somewhere - I assume to disk, since RAM is scarce.

The Gmail web app (along with some others I've forgotten now) seem to start extremely quickly when you bookmark them to the home screen.


The Gmail web app uses regular cache manifest offline functionality to cache the assets, but then uses Web SQL (of which the W3C has dropped the development of the spec) to store and serve up the messages.


This isn't some act of defiance. Playboy is doing exactly what Apple wants them to do, which is create content for the iPad. If Apple wanted them in the App Store they would be in the App Store.


I've worked rather extensively with the offline cache, and I can confidently report that the offline cache is buggy and annoying to use, especially with MobileSafari. It's not as simple as just simply downloading content and telling the browser 'when offline, serve this up.' You need to define exactly what resources you want to cache in a file called the cache manifest. The browser will download and cache the content, and subsequent accesses to the website will serve up the cached content and assets, even if you are online. To update the cache for new items, the original cache manifest file needs to be updated. However, a pretty prevalent bug sometimes occurs when you update the cache manifest file, but MobileSafari refuses to re-cache content. In this case, MobileSafari will forever serve up the cached content and never see the changes in the cache manifest file, until the user goes to their Settings and clears the cache. I'll give you one guess as to how many will do that.

Using the cache will automatically cache the index page by default, as it is the master file that is telling the browser to cache according to the cache manifest. Therefore, every time the browser accesses this file, it will be served from cache, even if you are online. That means that if you want dynamic content, you will have to make an ajax request to refresh the content on the index page. This proves especially frustrating if you have a lot of areas with dynamic content. And forget about doing logged in/logged out functionality.

Furthermore, when the cache manifest file is updated and the browser redownloads all the files, the updated files will not show in the navigator until after a refresh. So let's say you updated your index page and bumped the cache manifest to tell the browser to update the index page. It will first serve the old index page from the old cache, and then serve the new index page from the just-updated cache upon the next refresh.

So should the offline access store the entire history of articles? Or should it store, say, the latest accessed ones? If you just store the latest accessed issues, you would have to update the cache manifest file when a new issue has been updated, and then MobileSafari will need to re-download every single image file and asset over again. No diffs. Yuck.

There are a lot of compromises you need to make when building offline caching with MobileSafari using the application cache, and there is always the risk of the occasional refusal to cache which will require the user to manually clear the application cache in the settings (few will ever do that). Offline functionality is possible, but you will need to make serious concessions and work around the problems that caching currently has. Not to mention the little space given on disk for caching.

The way I tried to work around it, which is not foolproof but at least it's Windows XP compared to the Microsoft BOB of going all offline cache, is to use offline cache for assets (css, js, index file), use ajax to populate dynamic elements when online, and for the storage and retrieval of raw data, use the (now deprecated) Web SQL database. This is the approach Google uses for offline Gmail (screenshot for the curious: http://winning.markbao.com/6xyM/Screen_shot_2011-05-22_at_7....). This only works on iOS devices, though, and would not work for Playboy since their data isn't text, but jpegs.

tl;dr caching sucks.


I guess you could store images as base64 encoded text in the Web SQL database, then create the images using the data: protocol. However, not sure you could fit many images in as the file size would be higher.


You would be able to fit a decent number of images in. The maximum database size on iOS for a Web SQL database is 50MB if I'm not mistaken.


Yes you would. Right, thats by sunday afternoon project taken care of, a transparent write-through HTTP cache using web SQL in javascript. Awesome.


And you've just reverse-engineered (some of) http://m.ibisreader.com


Errata:

"Using the cache will automatically cache the index page by default" => "...cache the page that you put the cache manifest reference to"

"This only works on iOS devices, though" => "This only works on Webkit devices, though"


Thank you, good sir, for sharing your experience.


I doubt offline storage would be remotely capable of holding all your Kindle books. And requiring an internet connection to read it isn't optimal.

In any case, this new subscription service only affects repeating payments right? So Amazon could still release the Kindle without that feature and it would still work with books that you have bought from the store.


How much space does a kindle book take?

Actually lets get some numbers for that.

Gutenberg ebook 11 (Alice in Wonderland) is available in kindle format 131kb. It is a short childrens book.

Gutenberg ebook 2600 (War and Peace) is available in kindle format 2mb. It is properly longer than most books though.

A tale of two cities (ebook 98) is also available, 506kb.

Anna Karenina (1399) is also available, at 1.1mb.

Twenty Thousand Leagues Under the Sea (ebook 2488) is 551kb with pictures, 518kb sans pictures.

So lets say the average book is going to be about 750kb and most people only need access to their three most recent books. That is only about 3-4mb - can't a web app store that much, client side?


Yes. The Web SQL database on iOS can hold a maximum of 50MB and on Android 2+ it can hold an expandable amount (in practice it's often limited for various reason to 50–100-ish).


Isn't it nigh impossible for consumers to discover these web apps?

They don't seem to stand a fighting chance as long as they are not indexed by the App store.


The app store isn't much good for finding anything outside the top 25 apps anyway. If you want to dig any deeper than that you have to page through tons of junk by hand.

I expect to see more and more apps like this move to the web. It's easier to iterate and simplifies multi-platform support. Apps will be coded to native apis because they really need that kind of access, and not just because people expect software to be delivered that way.


It is not at all difficult to let consumers discover those web apps - all you have do is to include an ad on the cover of the magazine "Get playboy for your iPad at www.playboy.com/ipad".

You then make a similar note on the homepage.

Now if you don't have a magazine you can advertise on, it becomes a little harder.


If you already have a site people go to, advertising a web app on there seems to work. Just don't it as annoyingly as IMDB.


I don't have a smart phone. What is it about iphones/androids that make it difficult to find and save interesting apps on the web? Is it that much more difficult than finding sites on a PC?


No, but that is already difficult enough. How many non-preinstalled apps does your mom have on her pc?

The app store changed all this. Suddenly, downloading apps was cool and fun. With this new web-app paradigm we're back to square one unless Apple steps in.


I don't see how the app store changed it all.

I've got both a Galaxy S with Android 2.3 and an iPhone 3GS and I do use a lot of apps, but I knew about the existence of every one of them from -- the WEB.

I mostly search for brands (I'm sure a lot of people do), like Skype, Facebook, Flickr or Angry Birds. For my Android I couldn't find an official Flickr client, therefore I haven't installed one, preferring to use the web interface instead.

That's not to say that I haven't discovered apps through the app store, but their usage was less than a single day. And when I searched for a number blacklister for my Android, I had to search the web to find a reliable one, as there are at least a dozen in Google's app store with big ratings that don't work properly and none in iTunes (through the web I found out that I have to jailbreak my iPhone).

Really, the app store is good for providing a payments system and maybe getting some inspiration from available reviews when in doubt, but the reviews are kind of unreliable as devs found ways to spam or workaround bad reviews (like uploading the app under a slightly different name). It's terrible for finding stuff and it's useless for finding out what's possible/allowed.


People somehow were finding websites before the AppStore arrival.


If you've got a brand as well known as playboy -- you've got a decent chance. Anyone else - not so much


This is basically Playboy's mobile website, not an "App" as we would have called them 4 years ago.

How hard is it to get people to be aware of Playboy's website? With a brand like that, and money to market it, and high visibility through other publications, not at all.


The javascript appears to be completely home grown, can anyone confirm?

Assuming it is, building a mobile website without a framework, be it jquery mobile, sencha, or sproutcore, shows how unaware the developers are of mobile browser quirks.

Even if it's iPad only at this point its rather nearsighted to assume they'll never want it to work on other devices.


The platform is by: http://bondidigital.com/

And the people who built it have done a lot of graphics heavy lifting in javascript in the past.

Ian Gilman i.playboy.com: https://twitter.com/iangilman/status/71255767684100097

firefox panorama: https://twitter.com/iangilman/status/60395010868264960

deep-zoom/seadragon: https://twitter.com/iangilman/status/22789135248920576

Ditto Aseem Kishore: http://aseemk.com/projects/


I expect multiple groups (Google, Amazon, Facebook?) to eventually release a Mobile Web App Store. The app/store could even be built on some sort of common frontend framework that provides many of the similar services as iOS, purchase, in-app purchases, etc. Has any group actually announced plans for anything like this?


An appstore (sort of) for web apps is already there: http://www.apple.com/webapps/


Looks great but how well does it run on Mobile Safari? Very interested in seeing a demo of this app that isn't just a video. Also very interested in knowing what tech they've used.


Why don't they have offline caching? Doesn't iOS's browser have (at least some) HTML 5 support?


MobileSafari has fantastic HTML5 support. Unfortunately, a few important features are buggy or crippled; offline cache is very hard to work with (as detailed in markbao's length comment above), and WebSQL tops out at 50 MB (with very UX-unfriendly alerts at every 5MB of new storage).

I don't think this is intentional malice, merely simple neglect from Apple. Unfortunately, the result is the same. :(


I hope they continuously improve their "platform" and make it work, and show how they make it work. If they can be successful, increase their profits by 30% and gain freedom, I can't help but think others will be eager to follow.

It'll be interesting to see how Apple responds if they do get to be a huge success/poster girl (hah, see what I did there?!)


It's baffling to me why Apple does this. Magazines and newspapers are troubled enough as it is, and the ipad could help those who prefer to read only once a month. How much does Apple make by this 30% rule? Do they need that money? Is it worth the negative press / publishers leaving iOS?




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: