Creating a mobile app

It can be exciting to expand into the world of mobile applications, but it’s likely you’ll have a lot of questions and considerations to make. There are also several options around how to build your app, and it can be difficult to know when to start.

Below, we’re talking you through the steps you may want to consider when building your app:

Solid foundations and user testing

We’ve all felt the high of finding an amazing new app that makes our lives better or easier, as well as (perhaps more memorably) the frustration of inadequate technology robbing us of our valuable time.

A decade since the iPhone was first released, the App Store and Google Play are littered with apps of questionable quality and low user ratings that you’d never download; an inevitable waste of your valuable time (not to mention the time of those who developed them!).

So to ensure your app is successful, it pays to involve your users from initial scoping through to final testing, via feedback forms, polls, surveys, and focus groups.

Most digital projects have a deadline, and high stakeholder expectations for features – two factors at odds with each other – so carefully managing these reduces the risk of investing in yet another app that nobody loves.

Reputation management

Any good app will be clearly branded. In fact a key objective for many app projects is to positively influence perception of a brand, drive awareness of it, or both.

Failure to meet the needs of users will result in irreparable damage to your ratings in the App Store and Google Play. This creates a downward spiral of negative reviews, which discourages more downloads – the very thing needed to attain positive reviews of an improved version.

In summary, the long-term reputational risk of a failed app project often far outweighs the perceived reward of meeting the original deadline, so it’s vital that stakeholders really understand this, in order to provide the time and money to do the job properly.

Consider app versions

You will never get everything right first time, and you can never know exactly what ‘finished’ looks like at the outset.

Look at any popular app in the App Store, or on Google Play – what version is it on? How many previous releases were there, over what timeline? How many of those releases were bug fixes, new features, or both? Perhaps more importantly, consider how long it took and how much it really cost to get to the latest version.

If you’re appointing a developer to build you a new app, they will almost certainly be quoting to build you version 1.0 – so you need to budget for version 2.0, because version 1.0 will never be sufficient.

An app isn’t a milestone; it’s a roadmap, a journey, an ongoing relationship with customers and their changing demands. It’s also a commitment – when new operating systems and devices are released, often several times a year, you will need to cater for these – so ongoing support, and the cost of it, must be considered.

Most projects will be delivered using an ‘Agile’ approach, where features will be scoped, estimated, and prioritised. Inevitably your budget will run out at some point, but by this point you will have included the most important features and made them as good as can be. This is often called your Minimum Viable Product (MVP). The remaining features that don’t make the MVP release are then prioritised and become part of the future delivery roadmap that you should also budget for.

App components

Most apps are more than just an app. There is the ‘front end’, the bit your customer will see, and there will likely be many other aspects they do not such as integrations between websites, CRMs, payment providers, third-party systems, etc.

Many app projects require some form of back-end ‘application’ to be built and integrated with these systems; administration interfaces (and logins) will be created for staff to manage user accounts, and other information within the app that will change frequently.

This ‘other information’ is likely to contain sensitive data, which will be affected by GDPR (and possibly PCI) compliance. It must be safely (and justifiably) stored, securely transmitted, and safeguarded by internal policies.

This is where you quickly begin to differentiate between developers –  those who just build what you ask – and those who really know their onions, who become your trusted advisor.

Choosing the right technology for your app

There are several ways to build an app. At one end of the spectrum, there’s a website that feels like an app. At the other, there’s a true ‘native’ app – the ‘native’ bit means it’s joined at the hip to the device, so the user interface (UI) of both the app and device’s operating system (OS) feel identical, and the hardware capability of the device can be fully utilised.

The most popular approaches, where the best option for your business will be decided following user research, are:

Web app

A mobile-first, responsive ‘website’, accessed via a URL, that performs the functions of an application, and ‘feels’ like an app, but runs in your device’s browser.

Example: Facebook or LinkedIn using your smartphone’s web browser.

Limitations: Some ‘native’ features (such as push notifications) will not work on any device. Will not be as fast or responsive. No offline support; users must be connected to load the app. Won’t be ‘discovered’ in the respective app stores.

Benefits: Greatly reduced development costs. A single code base. No app store (waiting for Apple to approve releases, logins/barriers to downloading). Users can save a shortcut icon to the home screen, prompted by a popup. Can be accessed from any web-enabled device. Supported by modern smartphones/tablets, including photo upload, GPS location, etc.

Progressive web app (PWA)

A web app that progressively enhances the user experience and feature set, increasing with each device’s capability, right up to a native feature set (such as offline storage, push notifications, etc). Accessed via a URL, the device downloads an ‘app shell’ (and home screen icon), reducing data transfer and increasing performance. Browser controls disappear and the user is left with a ‘native-like’ experience, and user friction is greatly reduced compared to native.

Example: Financial Times (ft.com) / Twitter (best on Android/Windows, still good on iOS)

Limitations: Apple is currently developing ‘native’ support for service workers on iOS, so that user experience is not yet as good compared to Windows/Android. Won’t be ‘discovered’ in the respective app stores.

Benefits: As per #1, improved user experience and native support, with offline functionality. Good native support on Windows and Android.

Hybrid app

A web app that is ‘wrapped’ or ‘ported’ so that it can mimic a ‘native’ app and be published to the relevant app store.

Example: Many of the more niche/business/productivity apps that you might download.

Limitations: App store approvals process and delay when publishing changes. More friction in the user journey to first use. Mimicking the native UI can be labour-intensive.

Benefits: Single code base. Improved native feature set (push notifications, offline support, etc). Allows one code base to be maintained and published (separately) to the app stores. Exposure to users of the app stores.

Native app

An app specifically coded for each platform (iOS/Android/Windows/etc)

Example: Most mainstream native apps – eBay, Amazon, Facebook, Twitter, etc.

Limitations: Can be very costly, due to separate code bases and different programming knowledge for each OS version. Less popular OS versions (such as Windows) are often unlikely to have a user base large enough to justify the investment in a separate build. More friction in the user journey to first use.

Benefits: Improved performance, complete native support and compatibility with each device. Ideal where performance (such as gaming) or platform-specific nuances are important. Full native user interface, for a more intuitive experience. Exposure to users of the app stores.

So, which type of app does my business need (and when)?

The most prolific native apps have a web-app as a fallback – think of the ones you use most – logging in to the (Facebook/Twitter/YouTube/etc) websites using your smartphone’s browser still provides a reasonable experience.

If that fall-back is a PWA, then it will currently support important features, including some native functionality for Windows 10 and Android devices, with iOS expected in the near future.

This fall-back means that if (for example) an app isn’t available for Blackberry users, they’re not excluded, and more importantly, it provides an ‘access anywhere’ solution where users aren’t tied to using a device that has the app installed, (or being forced to temporarily download the app) just to quickly check something while borrowing someone else’s device.

So strategically, starting with a PWA before going native, makes a lot of sense as it allows you to:

• Provide the widest support for your customer base, with forward/backward compatibility

• Work out foibles before staking your reputation in the app stores

• Understand user behaviour to justify investment in native features and/or versions

• Reduce the effort and risk involved in meeting your original deadline

• Remove much of the friction in the user journey to access your app

• Provide an ‘access anywhere’ platform, instead of siloed apps¡

• Target users of the PWA with adverts for the native version (if you build one)

• Because of this, PWAs are receiving praise from leading brands, with many case studies reporting double-digit increases in conversion rates, a trend likely to grow with future iOS support.

For some, ‘native’ may be an inevitability, although for most of you reading this, a PWA-first strategy will help you justify any business case for ‘native’, while putting users first from the outset.

App development support

The team at Logic+Magic have a wealth of experience in creating bespoke web applications for clients of differing needs. Not only will you have our development team by your side but our user experience team to ensure your app is built with your end users in mind, as well as our SEO team to support on App Store Optimisation. Get in touch with our team to start on building your application today.