Developing an entire application takes approximately 2-3 months of full time work, if you are working on the entire project by yourself. This can easily increase with the complexity of the application. As you will soon see, it takes such a long time because there are many aspects to application development - testing, design, and lots more. Writing code is only a portion of the entire process.
The following is a quick overview of the entire mobile application development process. While different projects will almost certainly have different requirements and different workflow-bottlenecks, this document should give you a very high-level understanding of what it takes to build a mobile application.
The high-level overview of the app development process is pretty simple. It can be broken down to six phases:
- Phase 1 - Brainstorming
- Phase 2 - Wireframing
- Phase 3 - Design
- Phase 4 - Development
- Phase 5 - Testing
- Phase 6 - Release
Ideally, there would be a team, and each member could focus on their specialties. However, if you hope to master becoming a solo developer, you should take each phase seriously.
In other words, do not neglect one area simply because you feel you may not be good at it. There are plenty of resources that will teach you the fundamentals of development, design, testing, iterative release cycle practices, etc. It will be a lot of work, but it is possible.
With the knowledge that building a fully functional application can take anywhere between 2-3 months of full-time work (and longer if you are only developing on a part-time basis), it very quickly becomes clear that app development will be a huge undertaking and a big investment.
Therefore, it is crucial that you plan your project as thoroughly as possible. As the project progresses, you will end up making changes, coming up with new ideas and new solutions for different parts of the project. However, you need a solid, well-built plan that will act as the foundation for the rest of your project.
Brainstorming includes (and is not limited to) the following:
- All ideas you have of potential projects you may or may not pursue
- Your goals and the reasons you are undertaking the project(s)
- Market research of the projects you wish to pursue
- Your application specifications - detailed criteria for the application you intend to develop
- Knowledge of the resources you will need to complete and deliver your application
Wireframing begins once you have a solid well thought-out foundation underlying your project. Wireframing builds on all the work you have done during the brainstorming phase. Wireframing helps you begin building something tangible.
Wireframing forces you to thoroughly think through the entire application flow at a high level. If you wait too long and make wireframing decisions during development, you may find yourself with a badly designed application. This is because development focuses on the much lower-level aspects of the application, the individual building blocks as opposed to the overall blueprint. These are two very different perspectives and they each deserve individual thought and consideration. The high-level (wireframing) focuses on the overall structure and functionality of the application and the low-level (development) focuses on how that structure and functionality is actually implemented- how it works at the code level.
You can wireframe on paper or you can use software. In either case, what you want to do is create a preliminary model of your entire application. From the launch screen, to every other screen, you want to begin conceptualizing the entire flow, structure and basic functionality of the application. You want to build the skeleton of your project based on what individual components do more than anything else. This is not the time for designing graphics. Focus on functionality and keep it bare-bones simple with regards to presentation.
The design phase takes approximately the same amount of time as the development phase. It is possible to handle development and design yourself. However, the main issue with such an approach is efficiency. You can get a lot more done in a lot less time with a well-organized and well-coordinated team than you can by yourself. But in the case where this is not yet possible, it may be that you have to take on the design role yourself.
Be aware that you should be putting as much effort into design as you are going to put for development. This means learning a little bit about color theory, typography, vector art, icon design and more if you do not have any previous experience.
Design is important. No matter how well-written your code may be, your users may never see it. Well-written code should never be noticed. Badly-written code will be noticed, because the functionality of the application will be hindered in some way (e.g., through lag, crashes, etc.). Design, however, is the phase that allows you to present your application in any way you wish to the user. You can make it look professional, competent and visually appealing, or you can make it look the opposite.
To start off, learn the techniques you need for the project at hand. If you need some image buttons, this is an opportunity to learn about iconography and all the necessary skills successful icon and button design may require. Learn what you need. Inevitably, you will end up learning skills that you will be able to apply elsewhere in the future.
You have an idea, you have done your research, and you have thoroughly wireframed your application! You have even completed most, if not all, of the necessary image assets and other design resources. Now you can finally get to the coding aspect of the project.
This will take some time and a lot of problem solving. You will handle the platform-specific APIs to interact with the mobile operating system and make your application do exactly what you want it to do.
There’s not much else to say. You code, you run the application, you debug and then you code some more. It will be a slow process. Some days, you may only successfully implement one feature. Sometimes, it may even take days of full-time work to implement one feature. This is one of the critical places the brainstorming phase will help you- you will have defined a set of application specs required for the first release cycle. So while feature creep1 may be tempting, your set of requirements will trump anything else, keep you on task, and keep you on schedule. If you find yourself spending too much time on components not part of the original set of specs, it may be wise to cut that component out entirely.
Manage your expectations and focus on your core requirements. More often than not, those few core features alone will take a long time to properly implement on various platforms as well as (depending on the platform) numerous devices. You can always expand in future release cycles.
The testing phase is the phase in which you rigorously put your application through as much trouble as possible. The goal is to build a high enough confidence that your application will work under any number of conditions and under any sort of treatment. The testing phase is the phase that your application is being prepared for the production environment. You are preparing to publicize.
You need to test on as many devices as you can get a hold of. If you have access to physical devices, use them. Emulators and simulators are also available for the different platforms. You can use them to run the applications on your computer. However, testing on physical devices is always the best option. You will not know how various parts of your application are functioning in a real world setting unless you get it running on a physical device.
Always run your tests on both the oldest device you wish to support as well as the newest device you wish to support. Test on the different screen sizes you wish to support. Test on tablets as well as phones if you are providing support for both. The end result should be that you are testing on a sample of devices that is representative of the total number of devices you wish to support. You may not be able to test on all of them, and in some cases, testing on every device will prove to be impossible (e.g., Android runs on thousands of different devices). Build a manageable sample of devices you can test on, use emulators and simulators, and make sure to test on physical devices.
You may also consider performing alpha and beta testing. These are actually a critical part of application development as well as software development in general and there are many different ways to approach and execute these kinds of tests. This should come after your individual sample-testing. The goal is to try and put your application in real-world conditions using a much larger sample size than you can provide on your own.
Testing is a major phase of software development. But it ensures that your application is or will become reliable, robust and functional for all users.
The release phase is more of a pseudo-phase. While it may not take as long to complete as any of the other five phases, it will not exactly be a one-click-submit-and-you-are-done kind of deal. There are several things you need to prepare for and several things you need to do for the release phase.
In some ways, release is a lot like building a website landing page for a product- you’re going to need to show off your product, consider the best SEO and keywords to use, write an attractive description and more. All of these will be used by the various app stores when you create your application listing. This is a major part of the marketing involved so that potential users will want to download your application.
There are also technical requirements that you will have to complete, such as signing your application using a digital signature to tie the application to your identity. This signature would be used to allow future updates from only that signature.
The different app stores give you all kinds of tools for monitoring your application as well as various metrics- crash logs, download rates, retention rates and more. Monitor and use this information for future release cycles.
Application development takes time. As you progress, you will learn and become more and more efficient. Soon enough, you will have completed your entire project. Like with anything else, all you have to do is keep at it.
Feature creep - Over a long time period, extra unnecessary features seem to “creep” into the codebase. These features usually go beyond the application’s goals. This is often seen as negative because it typically introduces more complexity to the code while providing little to no value. At its worst, it can severely delay project completion and has been known to kill entire projects.