Developer insight: Avoiding development pitfalls for app longevity

Building an application for the long-term is not quite as easy as it seems. Despite having the ambition, developers often stumble over the same obvious and avoidable pitfalls with the end result being an app that fails to engage the user, or worse, fails the Apple and Android review process.  Time and time again, we see the same three hurdles to creating an elegant, refined and immersive application: firstly, operators don’t have the funds to develop it; secondly, they try to leverage as many cross-platform components as possible; and finally – in simple terms – they don’t know what they are doing.

For an application to succeed, the first thing to consider is the user journey. Apps must have clear, intuitive navigation and an easy interface that does not confuse or cause the customer to “wait” while servers kick into action.  It is common for developers to try and shortcut to the end product by repackaging existing code, but apps are not websites. Operating systems have distinct rules on navigation and though on Android some of this navigation is built into the hardware, on Apple it is not. It’s crucial to consider the navigation flow and how the customer can get out of a user journey they no longer want to participate in.

So many of the apps we review leverage numerous cross platform “economy” saving features, whether these are Webviews, ReactNative, Xamarin Forms and dare I even mention it, Cordova. The trouble with these cross-platform products is they leverage a common cross platform mechanism to undertake certain controls. This has the unfortunate result of bringing Android style right justifications to Apple dialogues, WebStyle select buttons (some so small, a person with the smallest fingers could not select the correct select button), vague wishy-washy button colourings and extremely poor accessibility controls.

Design must flow through the app in a consistent manner, otherwise you will confuse your customers. That means all Call to Action (CTA) features have to be consistent throughout the user journey. Apple’s Human Interface Guide (HIG) is a good start, especially now that Apple is reviewing apps against this and refusing those with poor implementation – so be warned.

Building for longevity

To build an application that has a long shelf life the design needs to be robust from the outset. A central element of that is decoupling functional features from the user interface so that either the UI or the logic of the app can be updated without breaking the other. This point cannot be stressed enough: decouple, decouple and decouple. By using sensible design patterns, operators can ensure that their app is nicely partitioned and manageable for future releases. As soon as a new release is on the table, developers need to think about regression, or how to test to ensure the new feature has not broken an existing piece in the application. Again, decoupling and proper architecture helps tremendously.

The next point – the code – is probably the most subjunctive. Just as no one likes to be told their child is ugly, developers equally don’t like to hear the same about their code.  Android, Java, Kotlin is an Object Orientated language, iOS, ObjectiveC, Swift is the same and allows you to build component code that is reusable. Breaking features and functions down into small code “bits” and re-using them is the way to go. We frequently see developers creating enormous chunks of code that does “everything” to get the application out the door quickly, but this approach is unmanageable, brittle and will come to bite when a feature is added, or a bug needs to be fixed further down the road.

How the code is managed in the long run is not something to overlook. mkodo espouses something called TDD and is one of the few companies that unit test our iOS codebase. This allows us to test for regressions way before the application even hits a quality assurance engineer. It also allows us to test for extremely vague edge cases that are never seen in the development and test stages but become immediately visible the day you go into production. Regular pairing of developers helps with good coding practices, so it is key to ensure that developers share their code between them. The general mantra of a one-person development team will not result in code quality.

I’m still amazed how few apps are properly quality assured. When our clients walk through their apps under review, we come across numerous obvious deficiencies. It is almost inevitable that issues will arise in building code, but that is the very reason why quality assurance is so important. Our large QA department is not just about testing the functional aspects of an app but also aligning to the designs and style guides. Our tried and tested review process, focusing on the user journey, the design and style, architecture, coding quality and quality assurance consistently deliver better and more engaging applications for our partners.  Building on these foundations is what separates our apps in this market space.

Stuart Godfree is managing director and co-founder of mobile technology specialist mkodo. He started the company in 2001, together with Sue Yoxall and has decades of experience from working with mobile and information technology services.