Guest Post: Why developers should implement a CMS into their app

Editor's note: The following guest post was written by Will Lovegrove, CEO and founder of Release Mobile. The company recently launch a new cloud-based data sharing platform called datownia, a product that helps companies connect their data to mobile apps and business systems. Recognize this? “What’s new: content update” You may as well write “we’ve got an immature mobile app strategy” in the release notes of your mobile app than “content update”. It means pretty much the same thing. A search on Google Play and the Apple App Store revealed that more than 1,800 apps were updated in the last six months solely for the purpose of “updating content”. That’s 1,800 developer teams and their clients who worked together to update content in the app, test the app and then re-submit it to the app stores. In the case of one very high profile app -- the U.K.’s National Trust -- the data update went badly wrong and they had to make a second ‘patch’ release on November 28th. In the interim period, they suffered miserable reviews and their app’s star-rating plummeted. Releasing a new version of the app into the app store just so you can update content in that app is bad for the app owner, the customer, the developer who built the app and the owner of the app store. It’s bad for the app-owner because it’s a slow process involving technical work (meaning it’s expensive) and as demonstrated by the National Trust it can be risky. The problem is exasperated if the app has been published to multi-platform channels, e.g. iOS, Android, Web and others. If you don’t simultaneously coordinate the release of new content into all channels then you are creating marketplace confusion. It’s bad for the customer because downloading excessive app updates can be a pain, especially if you are on 3G or in a broadband-poor area of the country. You’re only kidding yourself if you think that your customers will appreciate a new app version with fresh content because it shows there’s a team behind the app which is working to keep the app relevant. That may have been OK 2009, but it won’t be OK now. Customers may start hating your app if all the new version offers is fresh content. If you are in a competitive marketplace and your rivals can update their content without the need for a new app download then you are already losing. It’s bad for the app store owner. Perhaps this is not so much of an issue given app store owners tend to be multi-billion dollar companies. But nonetheless, reviewing new app versions is work that someone has to do. Plus, the subsequent surge of downloads of the new version will consume machine and broadband capacity. Finally, it’s bad for the app developer. Developers hate updating content by releasing a new version of software. Nothing is more frustrating for teams that take a pride in devising state of the art digital business solutions than to have to clean up a spreadsheet emailed to them by a client and hack that into a SQLite database. Developers don’t like handling client data, they don’t like going through software test-cycles (just for content releases) and they hate doing work which they know can be done better with a technical solution such as a CMS with API capability. APIs are the obvious solution. The issue for many app developers has been that without a client-side API, it’s not possible to update content in apps elegantly. Sure, most good developers can easily create APIs using cloud services and the emerging backend-as-a-service solution providers like StackMob. But that’s not what’s needed. What’s needed is an API provided by the client, so that content update work can be delegated away from developers and back into the hands of the app publishers. An API creation project requires a different type of project, with different stakeholders and different budgets. RSS is a good stand-in for a mobile content API (and frankly is often overlooked and highly underrated) but if you want to do something more sophisticated with your data than an API is the only real solution. And that’s where the catch-22 is. For many businesses mobile apps have been an experiment: a test to see what the market is like. Expanding a mobile app project to also build an API will require more money and a longer, more technical, project. However, spending more money when the market is unproven is not sound. Yet apps that don’t refresh with content are not going to be as valuable or helpful to the customer as integrated-apps. So how good a test of market potential is a static app really going to be? This is a problem which troubles a very large number of businesses who are just entering the mobile app market. The answer is clear: any company wanting to launch a new mobile app must also integrate that app into a content management system as part of the project. This is something that developers must advocate and not let themselves be talked out of. Otherwise those developers face the same fate as the National Trust’s mobile app developer team and have to scramble to patch a software release which could have been completely avoided if the app was connected to a simple content API. Footnote: the author of this article contacted the National Trust to recommend an API for their future mobile content updates and was informed an API project was underway and would be online in early 2013.

Social Pro Daily

Guest Post: Why developers should implement a CMS into their app

Guest Post

About

Subscriptions

Events

Publications

WORK SMARTER - LEARN, GROW AND BE INSPIRED.

Subscribe today!

Guest Post