< Onymos Blog

10 Considerations for Developing a Mobile App

By: Steve Shaw • August 28, 2020

Whether you’re building a mobile app from scratch or trying to create a mobile version of a web app, there are considerations for mobile App development. It’s a unique environment – one where experience is crucial. Shiva Nathan, the founder of Onymos, has years of experience successfully managing web and mobile app dev projects, and he shares his considerations.

1. Do You Even Need a Mobile App?

It seems like all the cool companies are creating apps, but let’s be honest, there are costs and overhead in creating mobile apps. While the world is moving to a single App platform (web, mobile, other form-factors,…), there are still plenty of existing (legacy) services.

The fastest path to market is to run the existing web app in the phone’s browser.

But what are the options, and what should be considered? Let’s dig in:

If this is an existing Web App, is it responsive? Responsive design is required for a mobile app. It may be easier to recreate the functionality in mobile versus fixing and updating the web content.
Would the App be enhanced by taking advantage of mobile? There are approaches like PWA (progressive web apps) that seek to maintain primarily web-centric functionality while extending the App to a mobile platform. But if your app needs precise geolocation, notifications, camera access, or accelerometer input, particularly on iOS, you’ll need to create a traditional mobile App.

2. Will You Go Native?

Assuming a full mobile app is required, there are two development paths –

Native development. Create the iOS app using Swift, and create the Android app using Kotlin establishing two separate dev streams, or
Hybrid development. A write-once/use anywhere approach where Web development skills like HTML5, CSS, and JavaScript/TypeScript can be re-purposed.

For the vast majority of Apps, and particularly apps moving from a web environment, Hybrid is the way to go. The incremental knowledge required of Web development engineers is less, and majority of it is in interacting with device-specific functions, OS-specific nuances, and the mobile app release process itself.

There are a handful of reasons when Native is required –

Super-high performance, like gaming or something where milliseconds of lag is an issue; bleeding-edge features
Capabilities arrive in Native environments first and take time to be adopted into Hybrid platforms;
Support for exotic peripherals or extensions. Hybrid platforms support main-stream plugins, but if you’re building a bat-sonar tracking app that relies on an echo-location peripheral, native is probably the way to go.

3. Architecture & Design – An App Famine

Mobile devices are the epitome of feast or famine. In some sense, a Mobile app is a starved Web app – starved in visual real-estate, processing speed, memory, storage, connectivity (both speed and throughput), user’s visual pointing accuracy, and more. These resource constraints bring with them considerable strains on architecting and designing a mobile app.

User Interface and User Experience (UI/UX) design for mobile apps have to circumvent two challenges – a smaller screen size and reduced accuracy in where a user is clicking on that screen.

A web app has the distinct advantages of both a larger real-estate and pixel-level pointing accuracy of a mouse. On the other hand, mobile apps are constrained by smaller real-estate and the rough accuracy of a finger touch.

Mobile apps also struggle from the processing power limitations of the devices they run on. An application architect can no longer assume that significant client-size processing power exists to manipulate large amounts of data and/or perform complex visual rendering or mathematical calculations.

In addition to the processing power limitations is the restriction on memory that mobile apps have to contend with. The sandbox within which a mobile app runs has strict limits on memory imposed by the operating systems (iOS and Android).

Lots of data cannot be stored either as there are restrictions on local storage requirements as well.

In my experience, this separates good from great developers. Good app developers often remain blissfully unaware of any compute, power, or bandwidth limitations. Great developers (and Component creators) consider these limitations and account for them in both architecture and algorithms.

4. Architecture & Design – An App Feast

However, the mobile platform is not all famine and starvation. Mobile devices open up a wealth of capabilities that have transformed the user experience as well as industries.

With precise GPS, more advanced cameras, accelerometers, the capability of AR, and more, it’s vital to re-imagine the form, fit, and function of the application.

In reality, there are very few applications that do not benefit or cannot be improved by using the additional capabilities inherent in a mobile device.

5. Connectivity

A user trying to access a web application immediately understands it will be unavailable when there is no Internet connectivity. Whereas, the same user has different expectations when using a mobile app.

Users expect mobile apps to support ‘offline’ functionality when the device is not connected to the Internet. For example, a user can reply to a text or access downloaded content that will synch automatically when connectivity is restored.

A more complicated case is spotty or lousy connectivity. The user expects the app to function, albeit at ‘reduced quality.’ Example: In poor cellular coverage, a user would prefer to watch a pixelated lower quality video rather than have the experience end and the video to pause.

Handling these connectivity situations in a Mobile app takes engineering effort.

6. Help! I Need A Fix

Unlike the web development team, a mobile development team does not control its entire destiny. We have relinquished some control to the Apple Appstore and Google Playstore approval process.

Gone are the days when a development team finds a bug, creates a fix, and then rolls it out the same hour.

For a mobile app, even if the bug is super-critical and fixed within minutes, a mobile team has to wait for an unknown amount of time for a different company, Apple or Google, to approve and roll the fix out. Till that time, your customers are still in hot water with the bug, and only get the fix if they update or have auto-updates enabled.

This external dependency in itself alters the dynamics of the rigorous requirement in quality of testing, speed of release process, and responsiveness to customers.

7. Process Combinatorics

Mobile development brings with it different requirements to a team’s engineering processes. CI/CD (Continuous Integration/Continuous Delivery) processes need to be wholly reimagined for how source-control is handled, testing effects on simulators versus real devices, and release processes to the AppStores are handled.
Consider a simple comparison – a web application is tested on one or two hardware platforms with a handful of browser types and versions.

A mobile application needs to be tested on a range of hardware devices from a variety of manufacturers, all running different variations of the Android operating system and a few combinations of iOS operating systems for each release.
App store approval process (what is approved, how long it takes for approval) can be the subject of an article in its own right.

8. It’s Alive! Care and Feeding Considerations

All apps are living, evolving entities that require care and feed. Whereas a web app is more like a sloth, with it and its environment evolving at a slow and constant pace, a mobile app is far more active and requires significantly more care and feeding.

Both iOS and Android have more than a dozen updates each year, including a major yearly update. The dependencies that a mobile app relies on – other services constantly change as well. Plus, there are new devices from a range of vendors, all including different capabilities (touch ID, face ID, single/multiple cameras,…)

9. Don’t Ignore the Stars

There’s a reason why leading apps solicit feedback from happy users – because it’s an essential aspect of attracting new users. The five-star rating system has become ubiquitous, and with it, informed consumers can quickly gauge how likely they are to enjoy the app and the experience.

For a mobile app to be relevant and have increased usage, adoption, and high rating, the mobile app has to be continuously updated and upgraded. At least 20-40% of the time, cost, and effort spent in the initial creation of a mobile app needs to be ear-marked yearly for a successful app.

It becomes a vicious cycle – low ratings reflect trouble in the mobile app platform, resulting in less investment, which translates into even lower ratings. Consider it the ‘broken windows’ theory applied to apps. (https://en.wikipedia.org/wiki/Broken_windows_theory)

10. Get an (unfair?) Advantage

At the end of the day, you’re in business to win – win customers, win in the race to market, and be rewarded for your effort. So any advantage should be considered carefully.

Think about Apps you use on a regular basis. Is there a Login function? How about Notification? Does it use Geo-Location? Access to your Contacts? Maybe Chat?

See, there are common, fundamental building blocks needed in all apps. These functions won’t make your App 5-Star, but if implemented poorly, will definitely drag down ratings. And yet many companies spend valuable time, money and effort to re-create the same building blocks over and over again.

The Onymos Fabric is a suite of nearly 20 full-stack software Components designed specifically to jump-start any app dev program.

Conclusion

Migrating an app from the Web is a challenge but also an opportunity to re-imagine how customers interact with your product and your data. However you choose to proceed, real customer feedback is the best guidance. Starting with an MVP and iterating quickly will build a better, stronger and faster mobile App.