Mobile Application Development Series – Part 1
“Which are the top cross platform mobile app development frameworks?”
“Hmm…think I’m gonna need a development partner. How do I choose the best one..??”
“Which app development tool should I use?”
If you’re trying to figure out app dev concerns like these, then you’ve come to the right place!
Welcome to our 5-part series on mobile application development. Over the next few weeks we’ll delve into some of the key issues around mobile app dev and address queries like the ones above.
So, to kick off the series, we’re taking a look at essentials you need to consider when working out your mobile application development cost. No matter how fantastic your mobile app idea is, it always has to be planned for and budgeted carefully. Read on…
Thinking about the design of your next product? Then the mobile application development cost needs to be a priority consideration alongside other elements of the product design – such as hardware, embedded firmware, tooling and manufacturing.
Generally, you should look to allocate your project budget as follows:
Depending on the requirements, the cost of the mobile application may play a key part in the overall design and needs to be thought through carefully. It may even steer hardware decisions in the product. Let’s break this down further.
When drawing up the design requirements also consider how future features would be integrated in. It’s well worth considering these at the beginning of a development; doing so may well save time and cost and reduce risk when adding functionality in the future.
Do be clear on how realistic these future requirements are. If they have a low chance of ever being included, then provision for them really shouldn’t drive any initial development. The last thing you want to do is to needlessly inflate the mobile application development cost for functions unlikely to see the light of day. However, it’s best to allow for expansion for future.
This initial requirements phase may take a number of days to outline and then fine tune. Include as many people in these discussions as possible – designing a system that is technically impossible to implement is of no use! The whole process may take weeks to finally agree on functionality, but should result in a feature set that details the current features, known future items and details about priorities/key features.
Depending on the application, there could be a requirement for graphics content outside of the standard icons and widgets of the phone operating system.
It’s worth ensuring these are created by a graphics/UX designer in your company or at an external agency.
A graphic designer will be keen to work with you to generate the storyboards for the application, showing the flow the user will take through the application as well as the images that will be used in the application.
This process may take a few days to a few weeks depending on the complexity of the application.
Developing applications for all types of phones can be a tricky requirement, Android and iOS are the two leading mobile operating systems but they don’t share much when it comes to mobile development.
Traditionally companies develop two native applications; one in Java for Android and one in Objective-C for iOS, this effectively doubles the cost of development.
The development tools for both platforms are free and there does exist many cross development packages but many of these have limitations or costs involved in using them.
If your application contains a great deal of logic code for any processing or handing of content it maybe that one of these cross development tools would suit your requirements, having to write the same code in two languages is time consuming, costly and can easily introduce bugs that users won’t be happy about.
There are several different permutations for getting testing done – unit testing with the developer, or system testing with any supporting software or hardware, then going to a small group of users for trial or beta testing.
Consider how you will feedback bugs and issues in a way that your developers can take this information and bugfix.
Make sure a bug tracking system is in place, the more information you can provide to developers about the set up and error conditions the quicker issues will be able to be closed down.
In many developments, the full testing phase will take as long as the coding phase and in many cases will not be absolutely bug free but to a level of quality that allows most users to use the product without issues.
Testing on all models of phones with all combinations of operating systems and versions is just not possible, because of this you will need to support customers from the day you release a product with bug fixes and support questions on variants of devices you were unable to test for.
If your application is on more than one platform (iOS/Android/etc) you may need engineers capable of supporting each platform. Support and bug fixing may also not be a full time job.
If you are using an agency for this development then they will most likely be able to dial their involvement down to a number of days per month. However, if you are supporting the application using internal resources then now could be a good time to implement new features in-between support requests – otherwise you will be paying for an engineer who isn’t being fully utilised.
Care should be taken not to introduce functionality into your production app that will increase support incidents. Keep bug fixing and new developments separate if possible.
It can be surprising the cost and effort the mobile application development can take in the above steps. Many ‘simple’ applications have a surprising number of underlying features or requirements that all involve design, implementation, testing and then support. Development cycles may range from weeks to many months depending on complexity.
It is worth considering similar products and application and what they offer to their users. Mobile applications can make or break products, consider this development as crucial as other parts of the product design. Some customers may see the application after purchasing your product and some they may trial your application before committing to purchasing at all, for both engagements the application is a critical part of your product.