The increasing sophistication of mobile devices has created many opportunities for developers. Thanks to APIs* and open data, developers can build thousands of mobile apps and mobile websites to meet users’ needs. This opportunity has created one of the most contentious debates in the mobile development community: mobile apps versus mobile websites? There is, yet, no solution to the debate. However, there are some advantages and disadvantages to both types of mobile solutions.
The advantages to mobile websites are that they are easier to build than mobile apps and can be updated instantly. Mobile websites are cross-platform, meaning that the mobile website only needs to be created once but can be viewed on all types of mobile devices whether they are Android, iPads/iPhones, or even Blackberry. Some mobile website advocates also claim that mobile websites have a better ability to reach a wider audience and last longer than mobile apps because of the constant introduction of new mobile apps in the major app stores. Personally, I have not seen research to support either claim.
Mobile apps differ from mobile websites in that the application is built in the native programming language of the mobile device. Android apps are built to run in the Android operating system environment while iPhone/iPad apps can use either Objective-C or Swift. This makes mobile apps work much faster than mobile websites and allows for better interactivity with the user. Mobile apps can also perform more sophisticated functions for the user and are easier to personalize. Mobile apps also have a great advantage in that the mobile app does not need to be connected to still function.
Mobile apps do have their disadvantages. They are not as easy to create as mobile websites and require the user to install a compatible version of the mobile app for their device. I have often been frustrated to hear of a great mobile app that is only for iPhones/iPads and not for Android. Mobile apps are not as easy to update. When the operating system (Android, iPhone/iPad, or Blackberry) is updated, often the mobile app breaks and there may be a long wait for a new version (if the developer is still supporting the mobile app).
So, which do you choose? It depends on two factors: who is your audience and what are you trying to accomplish. I think that all federal websites should have responsive design baked in, and that simple interactions with the public should be through a mobile website. For more complex interactions, a mobile app is better because of the ability to save data and work offline when needed. Even so, if the agency creates a mobile app, please have the necessary resources to build mobile apps for the major mobile devices’ operating systems and to maintain the app for a reasonable amount of time. Again, personal experience, it is frustrating to rely on a mobile app that suddenly disappears or becomes obsolete once the mobile device’s operating system updates.
There is also a side issue for third-party apps that are developed using federal data and are used heavily by some citizens. Does the federal government have an obligation to step in and support the third-party app once the developer stops doing so? If the developer was encouraged by a federal agency hackathon to create the app and it is widely used, does that imply a responsibility for the federal agency to keep the mobile app alive and functioning? I would like to hear from you, the readers, on this issue.
*API – Application Programming Interface. How software programs and databases share data and functions with each other. Check out APIs in Government for more information.
(All references to specific brands and/or companies are used only for illustrative purposes and do not imply endorsement by the U.S. federal government or any federal government agency.)
Each week, The Data Briefing showcases the latest federal data news and trends. Dr. William Brantley is the Training Administrator for the U.S. Patent and Trademark Office’s Global Intellectual Property Academy. You can find out more about his personal work in open data, analytics, and related topics at BillBrantley.com. All opinions are his own and do not reflect the opinions of the USPTO or GSA.