Headless Content Management System for Mobile (Mobile Headless CMS)

Key Takeaways

• There are various interpretations of what a mobile CMS is, as well as the technical requirements each of them has.
• Although powering native mobile apps is the focus, it's impossible to ignore mobile websites.
• A true mobile CMS gives you all the features of a mobile BaaS, as well as editorial workflows for non-technical users.
• A mobile CMS should enable you to deliver content to any portable device – phones, tablets, watches, and even VR headsets.
• There is no true headless “portable CMS” for editing content on the move – however, certain alternatives exist.
• In a mobile-first and IoT world, Headless CMS consistently generates more advantages than legacy CMS.

Interpretations of a mobile CMS

When somebody says “Mobile CMS” they could actually have a few different things in mind, raising a few complications towards the concept – there are various interpretations of what a mobile CMS is. The following are the 3 most common interpretations of what a mobile CMS is:

1. A CMS to manage content in native mobile apps.

For example, you have an app for iOS and Android, where users are able to purchase cars. You would like a CMS that stores all relevant car information and delivers it to your app on both mobile platforms. This could be seen as a mobile CMS.

2. A CMS to manage content in mobile responsive websites.

Let’s take the previous example and say that, in addition to your iOS and Android apps for selling cars, you also have a website that people visit from various mobile devices. You may or may not have a native mobile app, or users may not wish to download another app, making it necessary to have a mobile “optimized” website. In this case, your CMS needs to support content delivery to all possible screen sizes, aspect ratios, and resolutions, across smartphones and tablets. A CMS for such mobile responsive websites could also be seen as a mobile CMS.

3. An application running on a mobile platform that allows a user to manage an existing CMS instance.

For example, you have a news website that you built with WordPress. You would like an application for your Android phone to be able to add new articles and update existing news stories as they develop on the go, taking a part of your website and injecting it into a mobile app. This could also be seen as a mobile CMS. Therefore, when talking about Mobile CMS, especially when making decisions within a team, it is important to make sure everyone’s on the same page.

A Mobile CMS for Native Mobile Apps

If you would like to create content that would then be delivered to a mobile application on a mobile platform - phone, tablet, smartwatch, or other - you have a few ways of accomplishing that.

App as a Mobile CMS

In some ways, you could use the application itself as a CMS. In other words, the content that you need in the application could be hardcoded in the application itself. This makes it a really straightforward option of having content in your app. Except for extremely minimal and static apps, however, there are significant drawbacks to this approach. A few points to consider in this approach:

• For any meaningful dynamic app the size of the app has the potential to be quite large, since storing all content locally takes up space. In addition, running such an app on a mobile device will likely consume a significant portion of the device’s processing power. The resulting user experience (UX) will likely suffer from the app being branded “slow” and “unresponsive”.
• Any content changes will lengthen delivery cycles and, therefore, affect your roadmap. Since every content change will be considered a change to the app, every new version will have to be resubmitted to the respective mobile app store and be subject to the review and approval process every time.
• Speaking of app stores, if you plan on having your app on multiple mobile platforms simultaneously, you will need to update all apps manually at the same time and continuously make sure they’re in sync. If you like to add another platform later, such as an internet-connected car, for example, your administrative effort would increase yet again. While certainly a possibility, realistically speaking, for any meaningful mobile app experience, using the app itself as a CMS is most likely not the best option given the drawbacks.

Mobile Backend-as-a-Service (Mobile BaaS) as a Mobile CMS

As an alternative to hard-coding your content within your Mobile application, you could utilize a mobile Backend-as-a-Service product for your Mobile CMS needs. There are a few alternatives you could consider, depending on what you are after: If you’re keen on open source software, you could take a look at Parse. For a GraphQL-based alternative of an mBaaS, there is Graphcool. If you are coming from an established company with an enterprise context, Kinvey might be an option to consider for you. While a mBaaS is a great alternative to hard-coding content within the mobile application itself - it also does a good job for simple noncontent heavy applications, where the content is mostly static - the key functionality lacking with a mBaaS is the actual CMS. Therefore, for mobile applications that need content updated frequently or where there is a need for proper editorial workflows, especially involving non-technical users, a mobile Backend-as-a-Service is likely not the best solution.

A True Mobile CMS

Having reviewed alternatives, let’s dive into the details of what it would mean to have a true mobile CMS powering the content in your mobile applications. As we can synthesize from the previous discussion, a true mobile CMS absolutely must meet the following requirements:

• First of all, it needs to be a CMS in the sense that it supports editorial workflows, especially for non-technical users.
• It needs to support dynamic content that is changing frequently without delays to the release cycle.
• It needs to easily publish content to multiple mobile platforms, including ones that may not even exist yet.
• It should support agile teams to deliver projects faster, allowing editorial and development teams to work in parallel.
• Considering the escalating consumption of content globally, a true mobile CMS should support localization and multiple mobile frameworks.

To address these requirements, the concept of a headless content management system was developed. A headless CMS is defined by the following characteristics:

• A headless CMS is API-first. This means that, unlike legacy content management systems, such as Drupal and WordPress (where the API can be added via third-party plugins or was added at a much later stage of development), Headless CMS was built from the ground up with the API at their heart. This can either be a legacy REST API or a GraphQL API.
• A headless CMS separates content from the presentation layer (front end). Giving the right tools to the right people is another differentiating factor of a headless CMS, whereby developers match the right presentation of content to the right platform by utilizing the API, while content creators produce and manage content with the tools they’re used to.
• A headless CMS is natively multi-platform. Because a headless CMS provides content via an API and doesn’t dictate how content needs to be presented, such a content management system, by nature, supports all platforms. This can range from any platform from smartwatches and smart-fridges to AR and VR platforms. In theory, as long as a device can receive content via API, a Headless CMS can deliver content to it.
• A headless CMS guarantees stability, API performance, and security. Though there are self-hosted options of headless CMS, it is preferred to rely on a cloud-based provider’s expertise and full-time dedication to manage the critical aspects of system stability, so that developers can focus on building engaging mobile applications, instead of doing risk-heavy DevOps and infrastructure work.

There are a number of attractive options for such headless content management systems. In the case of Hygraph - the first headless CMS to provide a GraphQL API, you can experience the following scenarios:

• Minimal footprint in mobile apps. As an alternative to REST APIs and combined with advanced filters, a Hygraph GraphQL API response has a minimal size and presents a JSON response exactly in the shape of the request itself, getting rid of the need to reformat or aggregate data once it reaches the mobile app. This ensures the mobile application is as performant on any mobile device as possible.
• Native support for poor connectivity environments. The Hygraph API eliminates the need for multiple roundtrips to API to fetch all required data, thus saving bandwidth and supporting bad connectivity and low data transfer scenarios inherent in mobile platforms.
• Auto-generated API documentation. Thanks to the power of GraphQL, the Hygraph API auto-generates documentation of itself making onboarding of new developers very easy.
• An intuitive web application for content creation. The Hygraph web application for creating and managing content is inspired by the best in design and user interaction research. This makes for intuitive and efficient ways to produce and edit content.

A Headless Mobile CMS for Responsive Mobile Sites

Mobile applications are certainly the dominating mode of consuming content on mobile platforms. There is still room for mobile websites, however, and it would be a mistake to neglect them.

The challenge with mobile responsive websites is in the fact that between Apple’s iOS and Google’s Android mobile operating systems, not to mention various smartwatches and other smart devices with a screen, there is a multitude of devices and screen sizes. Choosing to build a mobile responsive website means that you have to deliver a consistently smooth user experience across all of these screens, regardless of how different their sizes and proportions may be.

The good news is that, more often than not, a mobile responsive website is a counterpart to an already existing desktop website. This presents a few options on how to manage content in this case.

If the existing desktop website is already powered by a content management system, especially if it is a legacy CMS, you may choose to utilize existing themes and plugins to simply make your desktop website responsive. For WordPress, you may opt for the default responsive theme, which has been installed more than 1 million times as of this writing. If you’re a Drupal user, take a look at the responsive plugins here. For other content management system providers, you may rely on the expertise of your design and development teams to make your existing website responsive.

If, on the other hand, you are building both the desktop website and the mobile responsive website from scratch, it is a great opportunity to consider the benefits of a content management system for mobile, as outlined above. Specifically, a headless CMS, because you would have the opportunity to deliver the same content through the same API to two different platforms. In other words, you or your content creators would produce the content once and the CMS would distribute it to any platform with ease. In this case, it would be a desktop website and a mobile responsive website. You could even throw in more devices into the mix though. A VR headset, a smartwatch, or an electronic billboard. In theory, you’d only produce content for them once and have all platforms connected to the same API.

A mobile CMS on the go

In cases when you would like a mobile CMS in the sense of an application for your mobile device to administer your existing CMS instance, you have a few options. If you already have a legacy CMS in place, you could use the mobile app that WordPress provides for your CMS on-the-go needs. You can dive in here. Alternatively, for really simple use cases, such as personal or corporate blogs, you could look to modern publishing platforms, such as Medium. A great way to create simple content and offer mobile apps on the go.