Article | What App Should You Develop?

What App Should You Develop?

Navigating the choices for building front ends can be daunting. Like everything technology based, you are faced with a bunch of technology choices and tradeoffs. This article attempts to distill your app development options and outline the various pros and cons.

Before making any decisions, it is important to understand both what the end-user experience is and your marketing objectives:

  • Do you need an App Store presence?
  • Will the App be used across desktop and mobile devices?
  • Do you already have a responsive web application?
  • What is your budget and time constraints for delivery?

As well as user and business concerns, there are other technical questions that need considering:

  • What is the capability of your development team - do they know how to build a web app or native app?
  • Does your application have an API that is optimized around building a front end?
  • Are there Native specific features that you require?
  • What specific libraries do you require, and are these available for your chosen technology?
  • Do you want offline-only capabilities?
  • What Native Only features do you need access to?

Answering these questions will help guide your decisions and move forward with your app development strategy.

Web App Development Process

What are the different options in building a front end mobile application? Below, we discuss the different mobile web app development processes and technology options available:

Responsive Web application

A responsive web application is simply a desktop web application that knows how to behave on a mobile device. The codebase is usually (but not necessarily) shared between responsive versions and desktop versions, and the server side code and business logic is reused in both instances. This is normally the fastest and most economic way to deliver mobile experiences. Any web application development project where mobile might be used to navigate the site should support a Mobile First design approach

Progressive Web App Development

A Progressive Web application (PWA) is an extension of a responsive web application; with the difference being that the web application can be bundled and launched from the phone App (not via opening the browser). Apple’s App store does not support PWA as a first class App, but with Google’s Play Store you can deploy a progressive web app. The main advantage of a progressive web app is presence in the Play Store. If you have solid channels to reach your customers, then bookmarking your Responsive Web page is a good option and removes the overhead of the Play Store deployment process.

Native application

When you compare progressive web apps vs native apps - building native applications implies you are going full-in on the App Store and Play Store deployments. Don’t underestimate the effort required to polish and submit an App through these channels. You can also find yourself up against commercial obligations if your App has any e-commerce characteristics especially with the App Store.

The advantages, though, are many. You get full exposure on the App Store(s), access to all Native features as well as unlocking performance benefits from the native device.

Use a Native technology

On iOS you can choose Swift, or Objective C. The support on stack overflow is amazing and most integration with Native technology has been solved many times before with ample examples within the online documentation and support forums.

On Android, Java, or Kotlin is the go-to. As Java has been around for a while, its community support is more widespread, although Kotlin is definitely a more pleasing language to develop in and community support is growing.

What about Cross Platform technologies?

There are other options too if you don’t want the overhead of maintaining two separate code bases. Several technologies exist to allow you to write the code once(ish) and deploy to both the App Store and Play Store.

The mainstream choices (as of 2022) are React Native or Dart/Flutter.

React Native: The React Native technology allows you to leverage React knowledge, and apply that knowledge to building Android and iOS applications using the same/similar code base. Both Android and iOS have a large number of supporting components that abstract Native features so there should be little need to write your own Native adapter.

Building up the UI is surprisingly like creating a standard Web application but renders Native UI components. You can also write business and API integration logic in Javascript/Typescript and share this between applications. Other Javascript advantages then come into play, you can pull in from a vast array of NPM packages; and provided they can run on the Javascript runtimes of Android, and iOS (iOS uses Javascript Core and misses a few features which need to be worked around or Shimmed).

Dart and Flutter: Google has tried to solve multi platform App development as well. Using the Dart programming language, they created the Flutter platform. Experience shows less overhead / DeviceOps of cross platform development, however the lack of support of pulling in supporting libraries from the NPM package base might be a problem for some use cases (You can’t execute javascript code inside your Dart language).

With both React Native and Flutter approaches, the drawbacks are in the packaging, and getting the App to run across your development environment, the iOS device, and the Android device.

Although code can be reused, be prepared that you will no doubt need hooks in your code to deal with differences in underlying features of the device. Even though these platforms try to abstract out the differences in the API’s, not all features/properties and events are available on the different platforms so as a developer you are not completely isolated from the differences.

Deploying to the App/Play stores is a very Native experience and in all technologies there seem to be no shortcuts in the pain to packaging, signing and versioning a well-polished product.

Shortcut Options - HTML to the rescue

A common approach generally used to bridge the gap between building a fully featured mobile application and leveraging a responsive website is to build a hybrid application that uses Native to gain App/Play store presence, and provide access to Native features such as notifications, high performance QR scanning, state persistence, and either embed an authenticated WebView into your Native App, or launch out of your Native App to an authenticated session in the devices browser.

You can iterate on this and move more functionality into your Native App over time. Examples of this include: rendering graphs and reports that you have already built in Web into your Native App and rarely used features, such as profile or settings, that you can bring into your Native application via a web view.

Talk about Touch?

When designing for mobile/tablets, your UX must be aware of some web features that are not available on mobile. Some web features such as Hover don’t exist on Native, and Native has a range of new features that don’t exist in web such as swiping, pinching, orientation, device themes, location, and vibration which all can change the UX between your Web world and your Native world.

And what about Tablets?

Tablets again can have quite a different user experience than a mobile. Mobile Apps generally don’t look great on the Tablet's larger device screen dimensions, and the use cases on a tablet often differ from mobile (and again for desktop!). Think about what your users are doing in each of the user contexts; are they on the couch, bus, walking, with internet or without?

How about testing?

Writing suitable tests around your codebase is much harder on UI components than traditional web applications but is equally important. Look into cloud testing frameworks like BrowserStack which offer multi-device testing for device coverage and executing your test suite. Ensure you have adequate crash reporting enabled within your application, and keep an eye on crash reports as you roll out new versions.

Native applications require an app store approval process for releases, and then require existing users to update to the new version of the app. If you discover bugs in your application, there may be users that continue to run the old version of the app despite having a new version available. Other complications can arise with maintaining version compatible APIs with all the client applications. Building in a forced upgrade feature into your app is a great idea - from the start.

Summary

This article has only touched the surface on the concerns and tradeoffs in navigating your options in choosing the appropriate technology for your unique requirements.

It’s important to work with a web app development company that has the right team, support and experience in platform-specific design and development - helping you choose the right web app development process early on.

Please do get in touch to discuss your requirements, and provide assistance in guiding and supporting your business’s mobile strategy.

Message sent
Message could not be sent
|