An Event Apart: Bridging the App Gap

by February 8, 2012

In his Bridging the App Gap talk at An Event Apart in Atlanta, GA 2012 Marco Arment shared the differences between mobile Web sites and native mobile and some tips for working on native app designs. Here are my notes from his talk:

  • The iPhone changed a lot about the world we live, work and play in. It was the first mobile device that came with a capable browser. It also made people start using their mobile phones as computers. As a result, people now turn to their phones for lots of important things.
  • When the iPhone first came out, all you could do as a developer was build Web apps. But this was 2007, and Web apps couldn’t come close to anything you could do in apps on the desktop.
  • For a lot reasons, developers really needed native apps and in 2008, they got them. But a lot of early native apps were just Web sites, they just didn’t take advantage of what native apps could do.
  • iOS is a major presence in mobile and often times the most important for developers. So it makes sense to learn and use it to build apps.

Native App or Website?

  • Do you need to have a Website? Instagram is iOS only and it has millions of users. The service has sharing links on the Web but not a complete site. You no longer need to assume the only way to reach your audience is through a Web site. You can pick or choose.
  • When an app is not the answer:
    • If you only have a content site
    • If you have a low budget, apps are more expensive to develop
    • Prototypes are better suited to Web sites
    • If you need to reach a broad audience
  • You can always make a native application later.
  • When a website is not enough:
    • Hardware access. Though APIs may come later you can get access in native apps now
    • Software limitations: you can’t do background processing or run full screen
    • Data limitations: you can’t get into contacts, address book, etc.
    • Connectivity: cache manifest is a recommendation not a law on iOS, and can even be deleted automatically.
    • Practical constraints of size
    • Performance of Javascript is getting better but it is not good enough.
    • There is a shift in how and where people find us: they look for apps vs. going to Web site.
  • Instapaper had a Web service with 30,000 users when it launched an app in the iOS app store. A lot of people actually found the app, then moved on to the Website. But the app first launched without a login screen, had to quickly add it back. For many people, the app was the starting point.
  • If you have a good app, you will be featured at least once if not every few months. There are lots of slots to fill in the top ten lists and app store promos and not a lot of good apps.
  • App stores are closed. There will be gatekeepers for the foreseeable future. They don’t need us but we need them. They take 30% commission.
  • Reviews can be unfair, untrue, or incorrect but they never go away. There is also no way for you to respond to comments. People use reviews to request features and rate an app low.
  • If it’s easy to pay for things people will buy stuff. This is a huge advantage in app stores.
  • Monetization on ads is how most people make money on the Web. Ads don’t work as well in native apps. Instead people pay for content and services.
  • Monetization matters. If you make money from direct payments, you have direct interactions with customers. Which helps prompt good business practices.
  • The Web works everywhere on everything. Apps are not inclusive. You have to select a small market to address but it can still be quite profitable.
  • It depends on the business you are in. If you need to reach as many people as possible, an app might not be the best fit for you. If you need to charge for content, you probably want an app.

Designing Native Apps

  • Native UI widgets in iOS will work exactly as intended in a native app. But if you want to do anything custom, it is a lot of work.
  • UILabel only displays one font, one color, and one style. CoreText is really low-level and gives you full control over how text is drawn. You need to tell it how to do everything. UIWebView is a WebKit renderer. It can do everything you can do in HTML & CSS. But it brings overhead –it is slow and heavy.
  • Instagram is a giant UIWebView with a UITabBar. Mail uses UIWebView for the messages. Twitter iPad app uses UITableView and CoreText. Most reading apps are using UIWebView and some native buttons.
  • As designers you need to consider what makes things implementable in native apps. Know what can be done and what the impact on performance could be.
  • If you don’t know how these things work, it may be harder to work with developers.
  • Use standard controls where possible. It makes development easier and keeps things more consistent with the operating system and other apps.
  • Scroll under a layer instead of into a fade if you have a scrolling text areas.

Taming UIWebView

  • You only need to worry about one browser. Mobile Safari supports new stuff really quickly in their WebKit browser.
  • Use UTF-8 and specify encoding in the header.
  • If you want to avoid flashes, use a simple script when loading content.
  • Show activity when loading content from remote WebView (with a spinner control)
  • Disable scrolling if you have content that will fit into a single window or dialog.
  • Disable long tap menus otherwise you will get the default Web browser menus where you might not want them.
  • Disable text-zooming and retain 1:1 viewport scale in both orientations. Use the meta viewport tag to set this.
  • Advanced text rendering options should be considered but be aware of slow rendering. Use it for things like headings or short blurbs.
  • You can use hyphenation in WebView but it does have performance costs.
  • Consider disabling phone-number, address, event, etc. auto-linking.
  • If you want to communicate from an app into the Javascript environment, you can but it’s difficult.

If you are a Web programmer, why do you need to know how to build apps? HTML has forced Web designers to learn about code. Designers have had to learn a bit about HTML. Native apps are today where HTML was in the 90s. Designers and programmers are going to have to learn a bit how they work. They are here and not going away anytime soon. If you want to learn about this technology, it is much easier if you start now.