The design process is important and the costs will rise if the app is complex and has many different screens. The designer also needs to understand the expected user experience for the phone in question, so if you are looking cross-platform then they will need to be familiar with those models. Estimate two to three man-weeks.
Apps probably come down to a few categories. A simple app with all the data stored on the phone might take between two and four weeks, while one showing simple lists extracted from a database would take double that. For more complex server-side integration with offline working the estimate is around eight to 12 weeks. A full enterprise automation app, with integration to business processes and possibly including a shopping cart and payment gateway, will take anything from three to six months.
Naturally, this is for a single target. Although the back-end integration will be shareable, none of the code will be unless you use a hybrid approach and create most of the user interaction within a browser instance. This is an attractive approach when considering cross-platform apps as otherwise the cost doubles or triples depending on the extra devices supported.
Clearly a simple app is considerably quicker to test than one that interacts with back-end servers. The testing has to cover the scenario where the phone has mobile data signal and then it drops, or it switches to Wi-Fi.
The bottom line
It’s safe to assume that a simple single-platform app will cost around £10,000 and a cross-platform enterprise app won’t come in under £100,000.
How do I cut costs?
There are several ways to reduce these costs, especially if you intend to make a cross-platform app. Here are my top tips.
• Decide your target phones at the start of your project, and plan cross-platform if that’s what you want. Otherwise you’ll have at least two development teams and doubled project management costs.
• Specify the functionality of the app carefully at the start of the project: don’t have regular meetings with the designer where you add more functionality as you go along.
• Ensure your designers cope well with different resolutions. The design for a 320x240 screen will be very different from an iPad. Consider having larger images for the larger screen sizes.
• Make sure your app works offline. If your app can only work when connected to the internet then it’s not going to be useful to people who live in rural areas, sit in metal-framed offices or use the Tube.
• If you are pushing data to the phone, make sure this works via notifications when the app is in the background.
• You can save yourself a lot of testing if you use a proven framework that contains a tested communication library.
• If you are using a back-end server, ensure it uses common standards such as JSON or XML. This can then be the basis for your mobile system and also your web pages.
• Make sure the framework you use allows you to easily debug your app on the real device. Many problems will happen on actual handsets that don’t occur on phone simulators.
This paper seeks to provide education and technical insight to beacons, in addition to providing insight to Apple's iBeacon specification
Focus on cost efficiency, simplicity, performance, scalability and future-readiness when architecting your data protection strategy