Comparison between Code and No code mobile apps

This article offers an insight into developing and delivering mobile apps both with code and without. Both offer unique challenges and benefits. With real world insights from both sides, exploring the journey from idea to install.

Myth	Reality
A product or code path is easy and does everything	All platforms have a learning curve and none offers a complete solution for all users and circumstances.
One size fits all	Some people prefer working visually, others prefer words (code), many mix and match and enjoy the benefits of both environments.
Visual design is hard	Once you have decided on a your preferred choice, visual design and user experience matter. Both are easy to use and there are various design frameworks that make this task straightforward.
Coding is hard	Coding is easier to use and faster to learn thanks to significant improvements, frameworks, documentation and tutorials enabling almost everyone to start coding then continue productively. Like everything there's a learning curve, but templates, examples and online help offer extensive advice thus accelerating both starting a project and ongoing development. Unless you're at the cutting edge of development, chances are someone has already solved, documented and shared it.
No Code will solve everything	Except for the most trivial or mainstream apps, it's almost inevitable that bespoke code will be needed to deliver one or more aspects of key functionality. It's usually straightforward with tutorials and examples available for guidance.

 

Main benefits

No Code

Good end to end solutions exist and it's possible to quickly get a working prototype of an idea ready for publishing on Google Play and Apple store.

Many components are available, well engineered, tested and are usually well integrated into a system.

Delivers an app with documentation on how to publish to both Google Play store and Apple App Store.

Code

Complete flexibility to design and deliver a bespoke solution using most third party components and external services.

It's probably already been invented! From official documentation to sites such as Stack overflow, copying and pasting with modifications is normal.

Although Kotlin, Java, and C++ are traditional native mobile app development languages, there are many alternatives for example Cordova and NativeScript for Angular, React Native leverages JavaScript, and python-for-android converts native Python Kivy framework into an android abk.

It's trivial to answer questions such as "Where is xxx in the app", "What changed between then and now", Can you change all instances of xxx to yyy. Traditional command line tools and their GUI equivalents are easy to use and are basic building blocks that all programmers use. The tools to answer the previous questions are: find + grep, diff and sed.

Version control software such as git is taken for granted in code, ensuring changes are controlled, easy to identify and used to reliably apply changes.

Shell scripts / batch files can automate repetitive tasks.

Main drawbacks

No Code

Limited choice of ready made components and integrated external services. These are usually sufficient for many apps and there's usually an option to create modules or add code as required.

Restricted ability to see what's going on "under the hood". By their nature, no code apps avoid exposing these details.

Unable to track details of differences between versions. Although it's usually possible to save different and incremental versions of an app, it's not usually possible to see what those differences are.

Choices are often limited to a platform. Due to the engineering effort to generate and integrate external services such as oAuth, it's normal for a platform to integrate their preferred solution. As was discovered, one of our platforms didn't support a required feature, we quickly transitioned to another and although we had to change our oAuth supplier, this was painless and almost feature equivalent.

Code

Separate output generation mechanisms for Google Play and Apple App Store apps. IOs apps can only be build on the OS X operating system.

It's possible to get bogged down in choosing external services instead of accepting recommended defaults.

Initial learning curve and setting up a build environment can be challenging.

Testing is optional, if highly recommended part of development.

Conclusion

Which choice to make is as much about personal preference as meeting functional requirements. The notion that no code is faster to market is generally a myth except for the most basic of apps, though they do offer a quick full featured start.

It's easy to get started with both offerings, no code vendors have good tutorials as do their code alternatives.

The most important thing is to start, then publish an app. It's easier to add and adapt once a project is successfully started. It's also easier to demo an app and get buy in with something tangible.

Recommend tutorials

Angular Heroes tutorial: https://angular.io/tutorial and if you're completely new you might want to choose the "Try it now" link for an even faster introduction.

Apache Cordova: https://cordova.apache.org/#getstarted

Ionic: https://ionicframework.com/

NativeScript: https://nativescript.org/

Bootstrap: https://getbootstrap.com

It's essential to recognise that a few days getting acquainted with various systems is highly valuable as it's increasingly expensive to change as you build your app.