Libraries can easily outsource the creation of native mobile apps for their libraries. With one, potential, exception related to tighter and “better” integration with vendor apps, I have trouble seeing benefits compared to a thoughtful website strategy.
Not long ago, I received a marketing solicitation from Boopsie, a company that builds native mobile apps for libraries. I have no reason to doubt that their product is good: they have a large portfolio of very reputable libraries ranging from public to general academic to special libraries. Indeed, one of my Law Librarianship in the Digital Age co-authors wrote about his library’s effective use of a Boopsie-built mobile app.
But my strong gut reaction is still deep skepticism that there is any reason for a library to have a native app, as opposed to a responsive or otherwise mobile-friendly website. Or, I should say, with one major exception — itself somewhat troubling to me — I see few compelling advantages for native apps over mobile-friendly websites in library applications.
And given that libraries with any sort of public-facing role are likely to need a website, regardless, I wonder if a largely mobile-friendly website isn’t ultimately the most efficient and cost-effective approach as well. I suspect the demand for outsourced management of “cookie cutter” (or template-driven) native web apps is largely reflective of the difficulty that so many libraries do have in effectively managing their web presences. I wonder if the real appeal of app-centric development for many of them isn’t, as much as anything, the management and administrative challenges they encounter in engaging in even a basic web-first strategy. For many libraries “duplicating” their efforts into mobile-native apps may simply be easier than overcoming the obstacles they face to effective (re-)development of responsive websites. But a defective capacity to work on the web is not the reason we would like to have to favor app-forward development.
Statistics: They Use Mobile Apps, But Not Your App
I don’t buy the arguments from usage statistics. Boopsie itself touts statistics related to the popularity of mobile apps. “69% of Library Patrons use Mobile Apps to Access Information!” and “Mobile Device Users Spend 2-1/2 HOURS PER DAY Using Apps and only 30 Minutes per Day Using Mobile Browsers!” And there are a number of market studies that do point to smartphone users (especially) spending astonishing amounts of time using native mobile apps (software running locally on their phone’s OS, acquired via the relevant “app store”) while comparatively neglecting their phone’s general-purpose web browsers. Digital analytics firm Comscore’s white paper, the 2014 U.S. Mobile App Report, finds that not only do smartphones and tablets now account for 60% of digital media time spent in the U.S., but that the vast majority of that time (nearly 90%, which is enough to comprise a bare majority of overall “digital media time” on all devices) is spent using apps.
So “meeting our users where they are” requires that we have our own apps, then, right?
Not so fast. Peeling just a little bit below the headline statistics undermines the argument that these huge top-line statistics necessarily have much at all to say about library apps versus websites. First, app usage itself is very concentrated. As the Comscore report notes, “a staggering 42% of all app time spent on smartphones occurs on the individual’s single most used app.” (Cough, Facebook, cough.) And three-quarters of app time is in one of the individual user’s top four most-used apps. Additionally, while the report frames this as “more than one-third of U.S. smartphone owners download[ing] at least one app per month,” the corollary is that approximately two thirds of app users download apps less often than monthly. That’s not a lot. How many websites do you visit in a month? And, to make sense of the other statistics about most app usage happening within a very few of any given users preferred apps, even most of those occasional additional apps that do get downloaded are likely to be barely used. (So without more evidence I’m also reluctant to buy the idea that once they download your app they are more “stuck” to you as repeat users.)
Category-wise, the overwhelming share of this large headline number of “app use” is spent in social-networking apps, messaging apps, games, and “radio” (streaming audio) apps. Just because users are spending a lot of time in a handful of apps doesn’t mean that they will spend any more time in your app than they would have on your (reasonably mobile-friendly) website. That they prefer “apps” overall might just mean that they like games and Facebook (which has an app-forward mobile strategy, although one with a very interesting propensity to lead users to, um, a lot of websites).
But Integrations May be Improved
The one place, however, where apps do have an advantage over even the HTML5-enhanced, mobile-friendly, Web is in their tighter integration with the native capacities of the device. The capacity to “talk” to the hardware is much more refined for apps than for web-based applications. This includes not only integration with various embedded sensors (camera, bluetooth, accelerometers, GPS, etc.) but also with local storage. This can mean that apps work better “offline” — where there is poor or no connection, via either WiFi or cellular networking, to the Internet. But an app that relies heavily on data from the “cloud” will still be impaired. However, it also means that “information vending” apps and the user experience around them — not only streaming video or audio but also ebooks or audiobooks, can be potentially better controlled through the app ecosystem than through the web ecosystem. The real power, potentially, of the “app” in the library-affiliated space is for tighter centralized control over the user’s access to and interaction with content.
And here is the one troubling exception I mentioned at the start. App environments simply offer tighter control over user experience. This ranges from the “app stores” themselves and their control over what applications most users are even able to access, to an added layer of mediation between the user and both the device hardware and the Internet. This tighter control can include control over how content — movies, ebooks, audio — is handled, and library content vendors may be likely to pursue an app-forward strategy so long as secure management of proprietary content is perceived to be better or more reliable via apps than via the web.
Because a library app has the potential to integrate single authentication and user experience between the various app-embedded versions of these library services, it may ultimately be a strategy more compatible with the mobile strategies that content proprietors and aggregators will pursue. While this is the one way in which I see (eventual) practical benefits to libraries and their users that are hard to replicate solely within the web browser, it is still an arena in which to tread carefully. And leads us to broader issues of the library’s fraught relationship with digital rights management and control over user access to content, and of whether an “appified” Internet is the future that we should want to see.