Mobile application development is more popular than ever. Today, there are tens of mobile application development platforms (MADPs) that fight for adoption and market share. In this post, I am going to share what characteristics a good, in my opinion, MADP should have.
Let’s start with some facts and obvious trends. Today, most of us have a mobile device of some sort and the trend is that mobile devices would become even more popular. So, it is a growing market with a lot of opportunities. To stay competitive on the market, you must have shorter product release cycles while maintaining excellent product quality. Using a MADP is one way to achieve the aforementioned goals.
So, you have this wonderful idea for a mobile application and you want it to be a big success. First, you have to build it. Let’s dig in the build process. Many applications start their live as a series of visual concepts. Usually the app author has mind models for some user interfaces (UIs), e.g. some buttons, labels, text boxes, etc. and some logic behind these UIs. A good MADP should reflect this thought process and should provide model-view-controller (MVC) paradigm for app development. Good news is that today’s modern MADPs support MVC design pattern. It should be mentioned that a MADP should support both declarative and imperative ways to define a UI. Another important aspect of the declarative UI programming is that the declarative language should be both easy and powerful. Nobody demands that all MADPs should use the same UI declarative language but it should be easy for us mere developers to switch between different MADPs when it does make sense.
We touched an important part of the application development – the programming language. A good MADP should use as common as possible programming language (in an ideal world MADP should support multiple programming languages). There is no point to have superb MADPs that use uncanny or esoteric languages. The entering barrier should be as low as possible. Using well-know and popular languages has a lot of benefits. Your developers can be easily trained in case they are not experienced with it. Another advantage is that there will be a lot of frameworks, components and libraries for that language. The presence of package manager like NuGet, npm or gem is also a big advantage. Community driven package repositories are invaluable and a big time saver. Of course, sometimes a MADP may offer new possibilities at the cost of a new or unpopular programming language and in this case I would recommend to carefully reconsider all the risks.
A closely related topic to the programming language is the IDE. For some developers it is a bit controversial topic but there are many others that find using an IDE a good practice. In general, a good MADP should not tie you up to a particular IDE and should allow building applications without an IDE as well. But for many developers the presence of an IDE is reassuring. Providing features as auto-completion, visual debugging, navigation and code refactoring may increase developer productivity. An IDE can also provide visual designers to support MVC design pattern as well.
While we examined the programming language and its surrounding ecosystem, our main focus was on the usage of local frameworks, components and libraries. We haven’t look at cloud services though. A good MADP should offer the following minimal set of cloud services: data services for storing application data, authentication services for managing user and application identities, push notification services for notifying mobile application about important events, integration data services for integrating and sharing data with other applications and custom application services for building common application logic blocks.
So far, we talked a lot about source code. Ultimately, this source code must be stored somewhere. In some cases, before you start with the project you already have the source code for some of components in your repository. A good MADP should support external source code repositories and support the most common source control systems (e.g. git, svn, mercurial, etc). This is an important requirement as we will read about testing and deploying in the next paragraphs.
We covered the major part of the building mobile application. This is only a part from build-test-deploy cycle though. While most developers are aware of the benefits of continuous integration (CI) solutions and embrace test-drive development (TDD) practices, they often underestimate the last part of build-test-deploy cycle. I am going to explore the last two parts together as the test part should test the deployment as well. Often, there is a friction in deployment process that forces the developers to test their app on a few platforms only. The problem is that the variety of mobile devices is enormous and there are good chances that your app won’t work correctly on some devices. Instead of testing and deploying your app on five or ten devices you should better test it on dozens of devices. A good MADP will automate as much as possible starting with CI, automated unit testing, deployment and automated UI/integration testing. A MADP should provide intelligent test scenarios for different mobile platforms and operating systems.
Okay, we have built and released our application, now what? Now comes another important thing – collecting and analyzing user feedback. My experience shows it is rarely that an app becomes success since its first release. Usually this is not the case. You release the first version and then start gathering user feedback what they like and dislike, what they want to see in next app versions and so on. Analyzing the user feedback is a hard task. There will be always users that likes your app and other that dislike it. It is a tricky thing what you should implement, change or improve in the next app version. To be able to take the right decision you should be correctly informed. This means that you should be able to collect and measure the user feedback. Once you have the data you can analyze it and take the proper actions. In my opinion, the hardest part is to engage the users to send you a feedback about their experience. A MADP should provide means that allow you to collect user experience data with minimal intrusion. Survey dialogs and rating forms just don’t work. A MADP should provide instruments to infer user experience from the application usage. There is a technical aspect as well. Collecting crash reports, call stacks and performance data from your app in also very important. Nobody likes unstable or slow apps. A MADP should provide mechanisms for collecting crash, bug and performance reports without any trouble for the end user.
In conclusion, a good MADP should:
- support MVC design pattern
- provide both declarative and imperative UI programming
- use popular and well-know programming language
- provide package manager
- provide an optional IDE
- provide rich cloud services
- support as many as possible external source control systems
- automate as much as possible and remove the friction in build-test-deploy cycle
- collect and analyze user feedback and technical reports
Some of the existing MADPs claim they already provide these capabilities. Check it out yourself.