Mobile app development is more expensive, time- and money-wise, than developing web apps or mobile websites. Reasons include device constraints, multiple device connectivity options and input methods, and device diversity.<\/p>\n
On the web, you can change fonts and font sizes thrice a week if you fancy. On mobile, you must carefully choose your design elements before going to development. What looks great on one device might be too hard to read on another: You need to look at screen sizes and resolutions. User expectations in a jam-packed app marketplace make it even harder on the mobile app developer. And with mobile technologies and devices constantly evolving, you also need to think about your app\u2019s shelf-life vis-\u00e0-vis business strategy.<\/p>\n
So what goes into building a marketable app? Here\u2019s what you need to know about resources, roles, and the development cycle.<\/p>\n
How many developers \/ designers?<\/strong><\/p>\n Your budget, and how complex your app is, should help you decide this one. While it\u2019s possible for a one-man team to develop an app, it usually takes more than one man (or woman, and that\u2019s assuming he\/she has design skills and UX sensibilities as well). A development team includes front-end developers and UI\/UX designers. Larger projects involve a creative director to guide the wireframing process. They may rope in a business analyst to gather perspective on your app from the technology, business, release cycle, and market angles.<\/p>\n If your app sends and receives data that needs to be stored and processed, you\u2019ll need a backend \u2014 and a backend engineer to set up and maintain servers and other equipment. Then of course there\u2019s the project manager to make sure everything hangs together: Project plan, adherence to cycle times, resource allocation\u2026<\/p>\n \u2026And with all of these roles, the app development cycle moves along fixed steps across app releases: Defining requirements, design and development, and testing.<\/p>\n The app development sequence<\/strong><\/p>\n On the front end, the development sequence typically goes from wireframing to UX design, on to UI blueprinting and UI design, followed by visual design and then development. Putting the wireframe stage first streamlines development: It makes it clear upfront to your client how the end product is going to look<\/em>, feel<\/em>, and work<\/em>.<\/p>\n If you go with a bare-bones wireframe, your client won\u2019t know what the app will look like until after the visual design. But that\u2019s often a good thing. Mockups \u2014 with visuals of all of the app\u2019s screens, including colors, icons, and scrollbars \u2014 can sway decisions, overriding more important considerations such as content placement. But to see why wireframing should<\/em> come first, we need to take a look at UX and UI.<\/p>\n UI \/ UX<\/strong><\/p>\n The UX design dictates how your app will feel. Good (or bad) UX appeals to the user\u2019s emotions, while the UI dictates how the user interacts with the device. So the UI drives the UX to a good extent.<\/p>\n Assigning project roles more granularly means different UX and UI designers. The UX folks look at the app from the user\u2019s viewpoint, and also evaluate user feedback. UI designers relate UX inputs with hardware aspects such as screen size, placement of visual elements on screen, physical buttons, and on-screen clickable areas.<\/p>\n Good UI and UX are harder to achieve on mobile devices than on the Web: The screens are small<\/em>, so it\u2019s inherently more difficult to get things done than on a desktop. And with so many apps out there, you need to provide superior UX to make yours stand out.<\/p>\n With different devices (smartphones, tablets, phablets), platforms, screen resolutions (Android phones chalk up 16 screen types<\/a> with four screen sizes and four pixel densities), and orientations (portrait or landscape), designers have a huge number of screens to play with. They need to figure out what will work in each case.<\/p>\n So after it\u2019s clear how the app will work, the wireframe is signed off. But before development comes\u2026<\/p>\n Visual design<\/strong><\/p>\n Clients often don\u2019t understand how difficult it can be for a developer to change things. Just two extra menu items can make the menu fall off the screen \u2014 which means designing and coding another screen. A font change might make text unreadable on 10% of Android devices, and so forth.<\/p>\n What platform will the app run on? Will it be used on a tablet? Can we design for all possible screen types? Is the proposed look and feel acceptable \/ appealing?<\/em> Your client must be able to answer these questions before the development phase.<\/p>\n Development and testing<\/strong><\/p>\n It\u2019s best to hire a developer who has extensive experience on the platform(s) or device(s), so they\u2019ll be able to advice you about how best to use the features of that platform or device. After development comes testing for functionality, for performance, for optimization \u2014 and back to defining requirements for v2. The same factors that make app development challenging make comprehensive testing difficult: Device diversity, a multitude of platforms, user expectations, and so forth.<\/p>\n Here\u2019s what IBM Distinguished Engineer Leigh Williamson had to say in 2013 about why development and testing for mobile is more complicated<\/a> than for desktop: \u201c\u2026Because of the variety of device types that have to be supported. There’s all these different mobile operating systems \u2026 the range of human interaction to provide input for mobile applications is a whole lot wider \u2026 The breadth of functional capabilities that you have to test and also support in the code \u2026 is \u2026 at least one or maybe even two dimensional order of magnitudes greater than for most typical desktop applications.\u201d<\/p>\n That\u2019s a lot. Two orders of magnitude?<\/em> Bottom line: It\u2019s hard to make a good app. Perhaps that\u2019s<\/em> why we have close to 3 million \u2014 on iOS<\/a>, Android<\/a>, and Windows Phone<\/a> combined?<\/p>\n