parislemon: Speaking Of Shoddy iOS Apps… 

Believe me, I’m usually the last to defend Facebook or Google, and I completely agree that the Gmail app is a half-assed disappointment, but I think this is a pretty glib take on “web vs. native.” I’ve been a Cocoa developer for a long time now, and my sympathies are very much with Apple, but I am increasingly convinced that we’ll someday look back at these early days of the iOS as a kind of bubble for old-school native software development.

This is not to say that iOS won’t continue to be successful as a platform, or that developers will abandon the App Store en masse. I just think that the current situation—in which many companies whose engineering efforts have traditionally not extended far beyond basic web technologies are suddenly expected to maintain complex native development projects for multiple platforms—seems a tad untenable. I feel pretty confident in asserting this because, for whatever perceived benefits native apps offer, they also presents a lot of very significant challenges—many of which are likely to be quite surprising to anyone who is accustomed to web programming.

To me, one of the textbook examples of something the web is made for but is practically rocket science on iOS is text rendering. While users are accustomed to thinking of iOS apps as exceptionally beautiful and visually sophisticated, UIKit’s text rendering capabilities turn out to be frustratingly primitive, making it quite a challenge for even expert iOS developers to match the advanced page layout and text formatting capabilities of web browsers. This is less of a problem for a utilitarian service like Twitter, where content is uniform, unformatted, and basically free of inline media. But when you start attempting to replicate something like the Tumblr Dashboard or Facebook News Feed in native code, you’re faced with a formidable engineering challenge.

Many of the, shall we say, least experienced iOS shops (read: content companies) have solved this problem by essentially shipping 200 MB InDesign layouts masquerading as general purpose software. Other, more sophisticated companies have attempted to get around this problem, at great development cost, by building rich text rendering and CSS-like styling facilities into megalomaniacal frameworks like Facebook’s three20. The problem with that approach, in my experience, is that you don’t have to go very far down the path of text rendering before you’re basically reinventing HTML and CSS. Considering that, as I said, the web is designed for media, content, and rich text, I don’t think a decision to rely on a web view for something the web is exceptionally good at is a sign of laziness—in fact, it may be a sign of prudence. I suspect this realization, not mere half-assedness, is behind Facebook’s decision to back away from their fully native, three20 based approach and instead focus on building a hybrid mobile platform.

None of this is to say that I think native apps are bad or that I’m trying to discourage companies from investing in them—far from it. Developing iOS apps is what I love, and I hope to continue doing it for some time. I just think that most companies could use a bit more nuance in their mobile strategy than the current “native is king” thinking usually implies. I’d personally prefer to see more companies develop a great baseline mobile web (or hybrid) product rather than feeling obligated to slavishly (and often poorly) recreate their entire product in native code.