How to create an app

This article was written with corporations and organizations in mind, a different take for publishers 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.

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.

It makes sense that the best way to provide technical info to a maintenance technician is to work with an app where all content can be made available in off-line mode and offers the possibility to be always be up to date.

A mobile app is the most effective way to distribute content to multiple sales reps, where you need to manage who gets access to which content, and where it is important that you can be sure no one else gets access at all.

It is always key to identify which medium will be the most effective to bring your message.
What are you trying to achieve and how are you target groups using different media in relation to your goal?
Providing your customers updates about new products and about availability can be useful but this is something that will work better in a phone app than in a tablet app. Providing in depth technical information about the installation of a product might work better on a tablet app because you need a minimum screen size to see a certain level of detail.
No company can afford to keep on working the same way as years ago, technology evolves and if you want your customers to keep on valuing your brand you need to deliver upon their expectations.

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.

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.

The concept

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’s always two sides, the brand and the user. What would you expect being the user, what is the user looking for, what is key for him?
Question if what is important to you is also important to your users or question how you can translate your goals into a win for your users.

Take a good look at your users, who are your target groups? 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!

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.
If you want to create a sales presentation app it is easy, you know the type of device your representatives are using.
If you are creating an internal communication app it already becomes more complex. Not every co-worker has a company device. What kind of app will it be? If you are going to run complex services in the app then you may require more screen estate and you’ll probably go for a tablet app. If it is more about communication, spreading the news, and if you want to reach as many users as possible you’ll probably go for a phone 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 fashion brand can offer exclusive access to limited editions via its app so fans will check the app on a regular basis.

For an internal communication app you could offer internal news, although this is not really sexy, is it? What about integrating a service to order sandwiches for lunch or a bulletin board for staff members to trade or exchange whatever they want. Adding those services will make your app popular, people will start to use it more frequently and you’ll get a powerful channel to publish your internal news that only a limited number of users were reading before.

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 car manufacturer offering the same content in his app as on his web site is just fine, some users will prefer to use an app. But e.g. offering a community app where users can share videos where they present their car, where influencers can share their impressions about testing new models and where everyone can post comments is something completely different. The official presentation, documentation and configuration is on the website, the excitement, the emotions will be in the app.
We start to get used to having our own car app to check the status of our car. This is something we expect to do with an app because it is like the key to our car we also carry in our pocket. We might be able to do this on a web site too but the experience would be completely different and not so personal, (who would want to check the status on the web??) but the technology used is exactly the same!

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 manufacturer of music instruments that is publishing his catalog in an app. When it comes to comparing different models of specific instruments they work with detailed comparison tables. Those are links to their website they provide within the app. So the standard information is available 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.

Development

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.

The Content

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 price list, 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 templates that are responsive, 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.
We integrate with different HTML editors enabling you to publish directly from those editors into you app. We integrate with marketing automation tools so that the behavior of a user in your app can automatically initiate a marketing action towards him at a later time.
In the spirit of integrated communication you need to be able to integrate the solution you are using to publish to mobile with other solutions you are using to create your content, to publish to other media or to organize your communication.

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 user 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 users 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.

Managing access

How will you organize the access to your content?

For organizations and corporations access to content can be an issue. The larger the organization the more likely it is that they have their own users-database and some custom integration will make the app(s) connect with this database to detect who can get access to which content.
For smaller organizations we have built-in entitlement that can perfectly let you work with users and groups of users and so to define on a group or user level who can get access to which content.
But we even offer more. Corporate apps often have huge amounts of content and organize it in different levels. With advanced scripting you can define which content will be shown to which user based on the properties available in the user’s 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 you to better manage which content is published to whom and to define scenarios.

For those corporations that would also want to sell certain parts of the content they are offering, do note this is also possible. Twixl apps support in-app-purchases and subscriptions.

Building and deploying the app

You have the content, you know how you are going to 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.

If your app is not intended for all audiences, Apple offers two different approaches to publish your app either in-house or privately.

If you are a company with more than 100 employees and you want to deploy your own app internally you can subscribe to the Apple developer Enterprise program. Because you publish internally, there is no app review process in this case. You will deploy the .ipa file (Enterprise build) on an internal server and provide access to the users that need to get the app.
One important guideline from Apple is that you can only publish to employees within your company. There’s no strict control of this and in reality we see lots of customers having a “broad interpretation” of this concept.

But then there’s the other approach Apple offers to deploy an app privately. Create a Custom app for business.
With Apple Business Manager, you can privately and securely distribute to specific partners, clients, franchisees, … and businesses can also distribute proprietary apps to their internal employees. This is also useful for businesses with less than 100 employees.

The clients, partners, franchisees, … you want to publish to first need to have an Apple Business account.
Then you, as a publisher, will need to identify in App Store Connect to whom you are going to publish by registering the Apple Business IDs of your clients, partners, franchisees, …  or if you want to publish internally to your employees their individual Apple IDs.

Businesses that you identify in App Store Connect will see your app and be able to purchase it in the Apps and Books section of Apple Business Manager. You can offer custom apps for free or at any price tier you choose.
You’ll need to upload your app to the App Store for review and select the Custom App Distribution option. You’ll deploy the .ipa file (a Twixl App Store build).

The organizations that you identified will be able to distribute your app through a Mobile Device Management system. Alternatively, organizations can choose to provide redemption codes to authorized users to download the app on the App Store.
An organization can identify those authorized users with their Apple ID.

Based on this you can also use the Apple Business Manager approach to publish internally to individuals who you will identify with their Apple ID within your own account.
This allows you just to ask the Apple ID of individuals and enable them to download your app privately just by providing them a redemption code.

If you choose not to go for the Custom App Distribution you can still work with restricted access. An app with restricted access will require you to login when you start the app, and after a successful login you can access the content. But understand that Apple might reject such an app if they identify it as only targeting a limited audience in a specific organization. At any rate, when you submit such an app, make sure to provide a test login for the Apple review team, that displays relevant content.

A hybrid approach with parts of the content being available for all users and other parts only to entitled users is also an option. Different users or groups can have access to different parts of the content.

On Android it is much easier. 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.
In order to publish in-house you don’t need anything extra, as you’ll just distribute your .apk file.
Corporations that publish on Android will mainly publish in-house because it is easier for them to deploy with no restrictions.

Still, the enterprise market is predominantly an iOS market because publishing to iOS devices is more secure.

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 editor 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.

The situation is different for in-house apps. Here the corporation will want certainty about the content being always available on the device of its users. For this we have an offline mode, also an app setting. Using this option, all app content will be downloaded the first time a user opens the app. On subsequent opens, the app will first check for new content and if available, it will download it. In most cases the size of the app is not really an issue because it is published on company devices.
Be aware that the timing for publishing new content will be critical and that the users of your app should show some discipline, and check for new content at moments they have time for a possibly larger download to finish first, and not just seconds before they need to use the app.
If you publish new content throughout the day and frequently need to update large content files (like e.g. video), then you may get in a situation where this feature will become more of a hassle than a convenience.

Testing

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.

Updates

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 user.

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

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.

Our Professional plan is for customers who are looking for an integrated approach. Integrated in relation to the publishing workflow, to the entitlement approach or even towards setting up automated content flows form web to mobile.
The price for this plan starts at least at double the price of the Essential plan and depends on the types of integrations you’ll need.

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 €4.950 and 10.000 or US$5,450 and 11,000 per year.
If you would need some training and support the extra cost would be between €2.500 and 4.000 or US$2,750 and 4,500.
In terms of development the total cost would be between €6.000 and 25.000 or US$6,500 and 28,000.

So you can actually start at about a 5K 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.

We hope this paper can help you with your project. Of course every project has its specifics, that’s why our experts are always open to discuss and help you better understand what you might need and how to define your project.

We have our local partners, we have partners that are specialized in certain specific domains and markets and we have our own experts in Europe and in the US. Just challenge us.