How to create a magazine or news app
This article was written with publishers in mind, a different take for corporations and organisations is also available here.
Do you need an app?
Before we get into the subject you first need to be convinced an app is indeed what you need.
We will not push you towards an app if this medium is not the best fit for your needs or if we are not convinced mobile will offer you value for money.
Today we all have the habit of regularly taking out our mobile phone to check for the latest news. Most of us will have their preferred sources and will probably use one or more apps. At the same time some of us can’t imagine reading a graphic arts magazine on a tablet, as they feel nothing can match the print experience, the smell of specialty paper, …
For different communication strategies, mobile may be a be part of a multi-channel approach but most of all, mobile is the best approach for certain specific needs and goals.
Publishers had to accept mobile was here to stay and that a large part of their audience would expect to be able to read their content on mobile, but at the same time they started to understand mobile works better for specific circumstances. While readers consult their phone for instant news they are more likely to use the tablet app to get more background information about a headline to better understand the subject. It is also about understanding how different a user interacts with a tablet and a phone.
If a publisher wants his readers to keep on valuing his brand he needs to fulfil the different types of needs his reader could have.
The biggest advantage about an app is that you can’t get any closer to the user.
Check for yourself which apps do you have on your tablet or on your phone? The ones that make life easier for you and the ones that are related to things you like. Your hobbies, preferred brands and preferred news channels, perhaps also work-related apps.
The main reasons to go for an app is because you want to be closer to your user. You want your brand to be top of mind, you want users to first come to you. Therefor you make life as easy as possible for the user/reader and you offer him tools to do this, you create convenience.
Nice to haves are the security aspect and the ability to use apps off-line, which can be an essential advantage in comparison to just a web site that offers about the same content.
Web or app?
You could argue that being close to the reader is just about that icon on the user’s home screen and that you can offer as much convenience with web technology as you can with native apps. Well not exactly, you’re right about that icon but it is easier for a native app to access and work with device specific features and most importantly a native app will work more fluently.
Most users are not aware of this, but by using the native features of the operating system, you offer your users an environment that works exactly the same way as most of the applications they are using on their device.
This makes the difference between having a good feeling about an app or having the feeling that there is something wrong.
Then there’s the aspect of security when selling content or providing specific content to specific users and the need to have the content accessible for off-line use.
Now you’ve determined that you need an app, let’s start with the concept:
What are your goals?
What are your expectations?
Define performance indicators that can be associated with your goals.
Do this because you need to be able to objectively evaluate if you are successful or not and to identify how you can do a better job.
There are always two sides, you the publisher and the reader. What would you expect being the reader, what is your reader looking for, what is key for him?
Question whether what is important to you is also important to your readers or question how you can translate your goals into a win for your readers.
Take a good look at your readers: who are your target groups, what exactly do you want to publish, in which circumstances will your reader access your app? Can you approach each of them with an app? Can you approach all of them with one app? Don’t try to reach too many target groups with one app. It is difficult to integrate different concepts and approaches in one app.
Clear and succinct communication is paramount!
A consumer association can have an app for its magazine but could also offer a separate app just to compare prices and product features. Interfaces in both apps may be completely different. The magazine app could be more popular on tablet, where the other app may be more popular on phones.
Define on which type of device you are going to publish. This is related to the need you are fulfilling and to your target group(s).
It makes more sense to publish an op-ed magazine that provides in-depth insights about news items, on a tablet app because you’ll have more screen estate to publish charts, video’s and pictures but also to create an experience; the pure news app with the latest news could be a phone only app.
Defining the kind of device you are going to publish for is key when it comes to defining how you are going to create your content.
Why will users want to use your app frequently?
A business focused news app might offer real-time stock prices to its members.
Many popular magazines offer a game section with crossword puzzles and sudokus.
- Define what will make your app unique.
- Which elements will attract the users you target?
- Which elements will keep them coming back?
What about the other media you are using. Are you going to bring a copy to mobile or will your users expect something else? How will you differentiate from your other channels?
Will the experience you’ll offer be in line with the expectations of your targets group(s)?
You absolutely need to meet expectations and offer a mobile experience that makes sense. A publisher offering access in a mobile app to a copy of the newspaper content that is also available in print and on the web is just fine, some of the readers will have that expectation. But e.g. offering extra in-depth background information on the main subjects of the day on the tablet is how you differentiate and create extra value.
For a publisher having different titles in his portfolio about different areas of interest offering a personalized magazine with articles coming from different magazines based on the points of interest of the reader creates again that added value.
It is not only about how you differentiate but also about how you integrate. You can combine the different media you are using. We have a publisher of a consumer magazine that is publishing its magazine in an app. When it comes to complicated comparison tables he provides a link to his website within his app. So the standard information is in the app but the detailed info is only published online.
How you position mobile in your communication strategy is extremely important. How do you make the puzzle fit? Is there a different approach between print, web and mobile and how do they fit together. How does social media fit in? Will you publish the same content to all media, will you start from the same content but reshape it to better fit each specific medium? Or is the approach completely different? Do you focus on one specific medium and are the others supportive?
You’ll understand this strategic question will influence how your team will create and layout content. In which format will they create their content and which elements do they need to have in their content.
Now you have defined what you want, the question is: “How am I going to develop this thing?”
“Am I going for custom development or for an off-the-shelf solution or combination of solutions?”
What’s your budget?
What’s it worth to you to be independent and can you at all be independent?
As a solution provider, it is obvious that we think the off-the-shelf solution approach is the better one. But let’s explain our point of view.
For us flexibility is key. Our customer needs to be in control and capable to switch to whatever other solution at any moment without too many inconveniences. Therefor the format of the content is key and you need to work with different solutions that can each be integrated with different solutions. An open architecture is extremely important.
Our team of developers has been working on our solution for about 10 years, perhaps you don’t need every feature we offer, but understand it will take you a lot of time, effort and money to develop a custom app. Once you’re there you will encounter completely different challenges. Make sure you can keep your team together in terms of keeping the knowledge in house. It will be about maintaining your solution, so there won’t be a big difference in cost between developing your app and then maintaining it. You’ll setup a team and you’ll stay with that team/cost for years.
Oh, you could decide to outsource the development, but in that case… there goes your independence.
Instead of that approach you have the possibility to be part of a larger initiative where you will only pay a fraction of the cost of custom development and where you will have a dedicated team continuously developing your solution based on the experience and needs of different customers. Perhaps not offering all the bells & whistles you want but at least offering you a solution that fits your budget and leaves you enough funds to focus on the experience you’ll be offering.
You might think a progressive web app will be more affordable because you only need to develop for one platform.
That’s correct, it is cheaper than custom developing for iOS and Android but it is still custom development and it also brings us back to the discussion of web vs native. It is a web app that only offers a partial answer to an offline need.
Where we do understand a number of publishers are getting tired of Apple and Google intervening in what their apps can and can’t offer we still find native apps a better alternative.
A user will always find it easier to trust an app published in an app store than an app published somewhere on the web.
In terms of development cost using an off-the-shelf solution remains far more affordable.
You’re going to develop a custom native app using an off-the-shelf product.
Let us focus on the content.
What will be the format?
What type of device are you going to publish to? Do you need to be able to publish your content also to another medium? What format are you starting from?
We offer the ability to publish InDesign-, HTML- and PDF-based content but also video and audio content, along with optional integration with any CMS or with an editorial system.
Starting from InDesign is the pixel perfect approach, meaning you’ll need at least to create two different layouts if you want to publish to tablets and phones. This brings a high creation cost that is difficult to automate especially if you choose to enrich that content, what readers would expect you to do.
Publishing a PDF is very basic, offering a poor reader experience. Here it all depends on what exactly you are offering as a PDF. A large comparison sheet, technical product specifications are fine but please don’t offer full articles that are only readable once you zoom into the content. This is completely disrespectful towards your reader.
What we promote is responsive HTML based content. The initial investment may be a bit higher, as you first need to create your templates, but once this is done you can publish and enrich your content very easily without the need to have professional HTML developers on the payroll.
Working with HTML content also makes it easier to publish that content to the web too.
Because Twixl apps let you integrate HTML articles, you can easily integrate web services to your app, meaning your app should not only be about content but also offer extra services.
As Twixl has an open architecture, you can easily integrate with an HTML editor solution, a CMS or an editorial system.
As an example, the TopGear app integrates with an editorial system that starts from PDF content that is converted to HTML, then published directly into the app. It offers an optimal workflow but with limited enrichment. The strategy here is that having an app is only seen as an extra for the print subscribers, and not to provide extra value.
The extra creation cost for mobile is limited, and they just need to update the interface of their app every time a new publication becomes available.
This brings us to the interface and the navigation.
Where a solution like Twixl was only offering limited presentation options in the past, it now lets you create and manage your interface and navigation just the way you want it too. This has become an essential part of your app. This is your front door, your first impression. You now guide your reader through your app. It is you who will define which content/service will be highlighted. This part of your app needs to evolve continuously. Your readers need to see there is new content and you need to use the interface and navigation to get them where you want to. They are part of the experience you are offering just as your content and services are.
How will you organize the access to your content?
As a publisher, you’ll probably offer paid content.
If you are providing content for purchase, you’ll be obliged to make it available through the app stores (in-app purchases), in addition to e.g. your own web shop. Print, web and mobile… you’ll define different types of subscriptions that you can sell in your web shop. All communication is targeted at guiding potential users to one market place and not to a diversity of market places, even though you may be selling through different sales channels.
In terms of subscriptions, it depends on your content strategy whether you will offer a dedicated mobile subscription and whether you will price a print/web/mobile subscriptions more expensively than a subscription for one medium.
Most publishers will offer subscribers an app to download from the app stores and a login that connects to the subscriber database, and then readers will get access to the content they are entitled to. This way publishers avoid the 30% commission the app stores are receiving. On the other hand, they still have to make it possible to subscribe through the app and for these subscriptions the app stores will get their commission.
You can offer each publication as a separate in-app-purchase and you can also offer subscriptions. You’re not required to combine both, it is your choice. Subscriptions can either be “all access”, where readers get access to all the content as long as they have an active subscription, or periodical, providing access only to content published during a specific timeframe. All access is easier to manage. Either you have it or you don’t. Once the subscription has expired the reader doesn’t have access to the content anymore. With a periodical subscription and in-app-purchases, a reader always need to be able to access all purchased publications. This sounds logical but it is something that can become a problem after some time. How long are you going to provide access to legacy content?
It is also important to show your potential users what you offer in the app. You can combine paid content with free content. We recommend to always provide a free preview of the content you’re selling, free access to the table of contents and access to (a part of) some articles.
Integrating your subscriber database in your app is what we call entitlement. Here we offer a number of built-in options, but using our API’s we can also integrate with your own external entitlement server.
Another option we offer to define which reader will get access to which content is a feature called ‘advanced scripting’.
With advanced scripting you can define which content will be shown to which user based on the properties available in the app. This can be preferences, this can be based on an event executed by the user, this can be based on info received from an external service. Next to the direct entitlement this allows the publisher to better manage which content is published to whom and to define different scenarios.
Building and deploying the app
You have the content, you know how you are going to sell your content or provide access to it, now you need to build your app and deploy it.
Twixl will build the app for you, the Twixl application just require some info from you and at the end of the process you’ll get a .ipa file to publish to iOS devices, a .apk file to publish to Android devices and a link for the browser version.
The .ipa or .apk files are basically an empty shell for your app and all the content is downloaded from our servers. Once the file is distributed via the stores, and the user starts the app, it will connect to our servers and get the data from there.
The approach to publish in the app stores is similar for both Apple and Google.
On iOS you’ll need to subscribe to the Apple developer program to be able to sign your apps and publish them in Apple’s App Store.
You’ll need to submit your app for review by Apple and they’ll need to approve it, and will verify whether your app complies with their guidelines.
On Android you just need to subscribe to the Google Play Console to publish on Google Play. Here too you’ll need to submit your app to Google and your app will need to comply with their guidelines, but they are not as strict as Apple’s.
Distribute the content to your app
Next, let’s define how you’ll get your content into your app.
Twixl will handle this but you have some options.
First it is important to manage the size of your app. A content-centric app can take up quite a bit of space on a device, and a user could easily decide to remove the app if he runs out of memory. For sure if the content is for free or if the subscription content is not compelling enough.
We absolutely need to avoid this.
With Twixl we limit the volume of cached data stored on the device by continuously removing the content that was accessed the longest time ago. The user keeps on having access to the content but will need to download it again.
How do we handle offline access then? Well the publisher has the option, in the app settings, to allow collections to be available for complete download. That way users can download a complete publication. Using this option we make the user aware of the consequences of downloading a complete publication by telling him how much space this file will require on his device. The user is immediately aware and can always remove that content later on.
You may think your app is ready, but let’s first test this thing.
Never publish an app without testing to check whether everything works well, all content is displayed correctly, entitlement works properly, and in case you are using in-app purchases and subscriptions, check whether restoring purchases works fine. This you’ll need to do for every new app you publish but also for every update you want to publish.
When developing a new concept, it would be recommended to have a test audience to see how the app scores and whether it reaches expectations. For updates define your own internal test procedures and work with a checklist.
About updates, we can understand that once your app is finally ready and it works perfectly, you may think like ‘now I won’t touch anything anymore’. Well you have to, as updating an app is something that should be done on a regular basis. Technologies evolve and something that works today might no longer work tomorrow if you never update: new devices, new operating systems come to market, and suddenly something could be broken. That’s why we advise you to update your app at least once per quarter.
An update of your app is often not visible to your user, the app will remain the same and will keep functioning in the same way, it is just up to date with the latest technologies and new (Twixl) features, as possibly certain bugs have been fixed.
Updating your content and the interface of your app on the other hand is really a continuous job. You manage this on the Twixl Distribution Platform, and any change you make will immediately be available to the user. Updating your content and updating your app are two separate things.
We really invite you to regularly change or update the interface of your app and to monitor the success of your app so you can remove what is not successful and add new content and services as required.
Your users need to see your app is constantly evolving. It shows your level of engagement.
If an app remains unchanged the user might wonder if you are still actively supporting the app.
Understand that publishing and maintaining an app is a daily job, it’s not something you just setup once and then it’s done.
Promoting your app
Now comes the part of getting users to discover and use your app.
It’s not because your app is in the app stores that success will come naturally.
It’s not because users download your app that they will start to use it frequently.
You need to keep every subscriber, you need to keep every user.
For that marketing is the answer. You can get your message across through different media, so use them.
Use the push notifications to inform existing users of the availability of new content and bring them directly from the push notification to a specific article.
Use your social media channels to do the same.
Email your users if you know who they are.
Define and setup a complete chain of communication whenever you publish something new.
Be careful with the exact moment you’ll be communicating, this is also important. Will your user be receptive for the news that you are bringing?
Just see how Netflix is promoting its new content. You value Netflix even if you don’t watch all the content they provide and that’s important.
You won’t get many messages from Netflix early in the week, most of the time it will be on Thursday and Friday.
For an internal sales app, publish new content at the end of the day and inform users at the same time. In the morning or during the day the users won’t have the time to check for updates.
When publishing an app in the app stores, you also need to put some work in maximizing your exposure and ranking.
It’s always better to not only use the name of your brand as app name but also one or two words that identify what it is about. Think in terms of what people would be searching for if they wanted to find your app. The terminology you would be using is not necessarily the one your users would use.
Description, Keywords are also important. This is not only the first impression to potential users but the app stores algorithms will also use this to define your ranking.
It should promote the core features of your app and again contain the keyword your users might use searching for an app that offers what you have to offer.
Other things potential users get to see are your app icon and your screenshots.
Both need to be appealing. Your icon should be aligned with your branding but also stand out in terms of the use of colors, you need recognition and exclusivity at the same time. The screenshots you are going to share should show the most appealing parts of your app, even if it is not the core. If possible provide a video first.
Most users will only look at the first 3 screenshots.
Once you start to get more users, ratings and reviews will become more important. Invite happy users to share their experience, answer reviews, it shows that you care. You can learn from bad reviews, tell users what you’ll do about it or why you’re doing things in a specific way, always try to highlight the advantages in your response, avoid arguing.
Privacy is an issue, accept it, respect it.
OK, it is obvious from a sales point of view that we all want to identify sales opportunities. But today it is the user that will define when and how you can approach him/her.
We can track whatever the user is doing in the app if he agrees with it. Of course the situation is different in an enterprise environment, but there too, you still need to inform the user and comply with acceptable use policies.
A user doesn’t necessarily need to be identified with a name and email address. Just a number can be fine. Based on behaviour you can identify categories of users and define how to approach each specific category.
Build up trust, get closer step by step. Define a gradual approach. Identify when you could ask for more. Offer more in return for something.
Don’t ask a new user to accept push notifications before he even had the chance to get a taste of what you have to offer. Wait for e.g. a third visit. Get his trust.
If you get to know him, never inundate him with communication.
Analytics are interesting, and you need to analyze how users interact with your content, but it is your duty to also inform your users about the fact that you’re tracking them. Openness is appreciated and creates mutual respect.
Also, allow a user not to be tracked.
In the end the user is always in control. Only when you accept this you’ll be able to handle privacy and analytics, and to communicate in an effective way with your users.
How much does it cost?
We can tell you from our perspective but it is difficult for us to calculate your internal cost.
In terms of the subscription for one app the most common configuration is with entitlement and integration API. This lets you manage different types of users and to integrate with other solutions to optimize your workflow.
Price: 4.450 € / 5,450 US$ per year
But you could actually start with just one app without any options at 1.950 € / 2.450 US$
You may still need a solution to create responsive HTML content too.
Price: about 3.000 € / 3,500 US$
Possibly there’s the extra cost to integrate with a specific CMS or with a solution that already connects to Twixl. Depending on the complexity of the project and the number of solutions involved this could take between 1 to 10 days of development.
Some assistance developing your app interface, develop some templates might take between 5 to 10 days.
Training and some availability in terms of support will take between 3 and 5 days.
This brings the total license cost between 1.950 and 7.450 € or 2,450 and 8,950 US$ per year.
If you would only need some training and support the extra cost would be between 2.500 and 4.000 € or 2,750 and 4,500 US$.
In terms of development the total cost would be between 6.000 and 25.000 € or 6,500 and 28,000 US$.
So you can actually start at about a 2.000 if you go for a standard app and want to do everything by yourself.
For a full grown project you should reckon with at least an extra 15.000 and for a complex project an extra 35.000.
Note that these are just rough figures to give you an idea of the total cost involved… your mileage may vary.