Technology | February 1, 2018
How to Develop a Mobile Application
The mobile application development market has exploded in recent years, but it still takes careful effort to create and manage a perfect team to accomplish your business goals. Mobile development can encompass a wide range of products: from a 1.5” smartwatch screen, to smartphones, tablets, cars, up to 100” smart TVs. Whatever you want to develop your app for major smartphone platforms like iOS and Android, or to use the mobile market to its fullest, it all starts with business requirements.
Client needs and requirements
Mobile applications are increasing on a huge scale each day and the need to have reliable applications is essential. A professional software development company will be able to create bespoke mobile applications using a range of technologies. It is the planning and requirements that are critical to making the application a success.
The first part of the process is always to define the needs and goals of mobile development. Those requirements have a variety of details – some clients can define exactly what system they want and can create a detailed specification of their expectations. Other clients only have more general business goals. That’s ok – there are appropriate models of cooperation for each of these cases.
The process of creating and updating project requirements is often split between the client and service provider:
- If you have a detailed requirements and want to directly control your development team – use the team extension model and use the provider’s developers as your own team.
- If you have requirements, but want to make use of the experience of the service providers to improve and refine them – use a development outsource modelto have the analysis, design and project development done by the service provider.
- If you only have business goals – use the project outsource/managed service model, in which the service provider will take over the entire process – starting with designing a business model and proposal for your project(s), refining it, implementing it, and continuously supporting and further expanding it over time.
To start defining the project requirements, we need to answer a few questions. The first one is about platforms – does the client want to release the app for iOS or Android? Depending on goals, you can pick all of the above, if you want to have almost 100% market coverage, or only some of them to save on expenses. Every platform is different, and each one requires a slightly different approach to designing certain features. This is specific to the mobile world – projects typically have exactly the same requirements, but the resulting apps are slightly different on each platform. They are customized to the UI standard of each platform, tailored to services offered by each platform owner, and designed to be familiar to the target audience of each system.
Those differences lead to the biggest question in mobile projects: Native or cross-platform development?
Cross-platform development makes it possible to create apps for every platform in one go, so typically it’s less expensive and requires smaller teams. But this technology often creates problems relating to implementing features, performance, stability and quality. It works great for apps for which the primary requirement is to present the user with information; but features like GPS, camera, advanced use of maps, layered animations etc. can be problematic.
Native development allows the team to achieve everything that is possible on each platform, offer the highest quality and level of performance, as well as perfect customization for the UI and design patterns of each platform. Native means that each platform has its own team of developers (at least one per platform), so there are more developers and the cost is higher, but it yields the best results.
Your service provider should always help to decide between cross-platform and native, because this impacts both technical implementation and limitations, team setup, and the budget.
If you only need the app for one platform – for example you are making an application for internal use in your company, and you only use iOS – always choose native, because there won’t be any difference in cost, but the quality will be higher.
Mobile apps are rarely stand-alone. Usually the data in the application is downloaded from the Internet – by means of a mechanism called API or webservice. The client may already have some system and database which can be integrated with mobile apps. Alternatively, the service provider can design a web-based CMS (Content Management System) that makes it possible to easily edit mobile app content in the web-browser.
Defining app logic and functionality
After setting the baseline requirements and deciding on the external webservice, it’s time to define the core of the application – features, UX and UI. Depending on the cooperation model, this can mostly be done by the client, or the client can just define the business goals and the overall idea, and the service provider can design the exact features, UX and UI.
These are the typical phases of app design:
- Functional specification– defining what should be in the application – which features are essential and which are optional. Target audiences and devices should be kept in mind throughout the process.
- Interactive mockup/wireframe– this stage defines UX and the overall layout and screens of the application. At this stage, the UX designer focuses on designing screens, transitions, and placing UI elements like buttons, images and text etc. However, this stage doesn’t include the final look – only the layout. Preparing this stage allows the client to click through the prototype, and see how the application presents data, whether it is sufficiently intuitive etc. Making changes at this stage is far less expensive than making them after the application has been finished. Therefore, iterating the design and gathering feedback from potential users is essential.
- Graphics– when the mockup is accepted, the next stage is to design final graphics for the designed mockup. This defines the final look of the application.
Having functional specification, the mockup and graphics concludes the requirement-setting phase. The next step is to define the team required for the project and the process of development, including tests.
Nowadays, quality assurance is essential for publishing high quality apps, and with a plethora of devices on the market, it isn’t an easy task. The possibilities and challenges of testing in mobile worlds are slightly different than those in desktop/server development. The situation is additionally complicated by the enormous number of mobile devices available on the market. In addition to tests, it is also important to conduct the project in accordance with the Agile philosophy and agile methodologies. I would like to point out the best practices for testing mobile applications and ways to manage a programming project that fit perfectly into the application testing policy.
Sprint in the Agile model
The Agile process of development is the preferred way of developing mobile apps. With Agile, we use the so-called sprint – it’s a set period of time during which specific work has to be completed and made ready for review. The length of the sprint is fixed and chosen at the start of the project – for example 2 weeks. Then, at the beginning of each sprint, we set goals – what we want to implement and function – and, after the sprint, that part is ready. After the sprint we can evaluate the current state of our product, and can redefine priorities or even the design of the application. Each sprint is designed to have relatively small, but fully working functionality added or modified. Thus we make use of Agile methodology to maintain the flexibility to make changes after each sprint. There is freedom for the client to make changes during the development to react to the market, user opinions or changing business priorities.
The above description is true for all software development, but is particularly important in the mobile world. Current distribution platforms (App Store, Google Play, and Windows Marketplace) make it very easy to publish an early version of the product, and even easier to update it often without any effort from the end user. This, along with the agile development flow, allows clients to publish the app early, see user reviews and reactions, and iterate functionality with each sprint, publish new versions and get feedback from the real market. Feedback from real usage makes it possible to set priorities that benefit users the most, and to alter the original vision so as to make the most attractive product.
Agile, along with the frequent publish model, makes it faster to iterate toward a polished, functional product.
Product owner in the Agile development model
The product owner represents requirements in terms of software development. The client should select a single person for this role, who will be the main contact responsible for providing a vision of the product from the client’s side, for cooperating with the team which will transform this vision into the product design process, and then for implementing this design. The product owner is not responsible for the technical details of implementation (unless the client so desires), but is responsible for understanding target audiences and desired functionalities, answering questions about projects, and the ongoing process of selecting the priorities for the next sprint. The product owner doesn’t need to have programming experience, but it’s good if he has some understanding of the market, knowledge of similar solutions and possibilities, as well as a basic level of technical knowledge. The product owner should have enough time to be available for communication with the development team throughout the process.
Read the case study: HealthTech Mobile Application – CareForIT
Scrum development team
The Scrum team is responsible for executing the product owner’s vision and requirements. This team creates the technical architecture for the application, implements it, and tests it. The Scrum team is in constant communication with the product owner during development. At the beginning of the sprint, the product owner is responsible for selecting the most important tasks to implement, and the team is responsible for estimating how many of those tasks they are able to do within the confines of this sprint. They consult on the details of requirements with the team owner throughout the sprint process, and the results of their work is tested, then submitted for review at the end of each sprint. Depending on the cooperation model, the entire team (except the product owner) can be from the service provider, or composed from among both the client’s and service provider’s specialists.
Since we already know that software testing is an inherent element of agile methodologies, when an application is being created, let’s focus on testing capabilities.
Ongoing mobile testing process
With the complexity of current software, the old model of testing the software at the end of the development cycle is long gone. Testing should be done throughout the development process – for every functionality added, there should be testing (both manual and automatic) to ensure that the functionality actually works. Automatic testing is also essential to ensure that further development of the project, and changes in the project environment, don’t damage any previous functionality.
Okay, but what types of tests should we take into account? We should definitely consider such options as:
- Unit tests
- Automatic UI testing
- Testing applications on the device farm
- Beta tests and automatic crash reporting
Unit testing is a classical approach to automated testing. In this approach, each code functionality is tested individually in separate unit tests. This can ensure that each code unit works when it should, and behaves as planned in the case of errors. Unit testing works particularly well when testing business logic. However, many mobile applications are written in the ‘thin client’ way, which means that most logic is on the server side, and the application’s only role is to download data from the server and present it to the user. This is often the preferred model, because one type of business logic can be implemented on the server and used on every platform (each mobile platform, web and desktop). On the other hand, it makes unit testing slightly less useful – unit testing is not the best tool for testing UI, and there’s not much business logic to be tested. Unit testing is still useful in testing the technical aspects of UI – proper initialization, handling of screen rotation, saving user data, maintaining the correctness of data downloaded from web services, etc. – but unit testing is not an effective tool for testing the entire application from the user’s perspective.
Of course, this changes when application is built in the “fat client” way – in this model, the application has its own internal data model and business logic that is partially or fully independent of that which is on a server. In this case, unit testing is essential for making sure that each use case and each code flow behaves correctly in numerous possible scenarios.
UI automation testing
UI automation testing constitutes an answer to the problems inherent in unit testing. Instead of focusing on individually testing each part of the code, it tests the application as a whole (black-box testing). Contrary to its name, it doesn’t only test UI – it tests the entire application, but from a user perspective. Instead of testing which code is executed, it tests the results of user interaction. For example it tests that results of pressing the button are as expected. This allows the entire application to be tested – both UI events, internal code for web service communication, and server-side code that responds to data. At all times, it also tests to make sure that the application doesn’t crash or execute properly.
An additional advantage of UI automation is that it is much better suited to testing device-dependent problems, such as problems with layouts, specific custom behavior on some devices that needs to be handled differently, etc. Running the same tests on different devices ensures that the application will work correctly on a wide array of devices, and may find unexpected errors that can’t be detected with unit tests.
Read other articles about the Quality Assurance:
- Today’s Approach to Testing Has No Future – Part I
- Justice League of Tests – Cloud Competence. Part II
Testing mobile application on a Device Farm
Every respectable mobile application vendor has multiple devices by which to test applications – both manually and using automated tests. This is a good foundation during the development phase for finding the most common problems and correcting them as soon as they are found. However there are so many devices on the market that this is impossible to test on-site for even a noticeable fraction of them. Android has more than 11 000 device models at the time of writing, and that number is constantly growing. Samsung alone has more than 1000 device models that are sold worldwide (including local variations for selected markets). iOS have a slightly smaller number of devices, but they still come in different variations and system versions. That variety makes it unrealistic to have real market coverage of testing, when testing is only undertaken on-site.
Luckily there are providers that offer device farms – remote services that allow companies to run remote tests on a large number of device models in a short time. Device farms are inexpensive, because you only pay for the time used on devices, and tests typically proceed rapidly. It saves the vendor the cost of buying hundreds of devices for testing, and also makes it possible to test the same device with different OS versions.
Device farms allow for the undertaking of most tests – unit, UI automation, and others, on multiple devices. Those tests make it possible to see detailed results, which in turn enable developers to find problems even if they only arise on a small subset of devices.
Additionally, aside from automated testing, device farms also make it possible to take screenshots of every screen in the app, which then allows for manual (human) checking to spot potential UI problems.
Beta testing and automatic crash reporting
Even a perfectly tested app may still have potential problems – new devices and versions of mobile systems arise every day and some of them change important behaviors or hardware features. So before final release, it is wise to first release the application in beta test mode. The app may be available to everyone, but the reviews and scores from the beta test are removed when the full version is released. Using the framework for automatic crash reporting, every time an application crashes on the user’s device, developers get a detailed report including which devices it was on, what version of OS, and when the application crashed. Due to this, it is possible to fix all the potential problems that weren’t spotted before going public, and allows for the release of a “final” version that is bug-free.
Automated crash reporting is essential even after full release – this mechanism makes it possible to fully monitor the market and spot potential problems even before users report them. For example, if the new OS version makes the app crash, developers receive instant reports of such events and are able to quickly pinpoint the reason and fix it.
Testing is essential for the ongoing quality assurance process, and should be done throughout the development process, not just before releasing the application. Combining unit testing and UI automation testing allows for a sufficiently acceptable initial release, while beta testing each version and monitoring crash reports throughout allows developers to make sure the application works well throughout its lifecycle.