Even the best ideas can fall apart in execution. Developing great iOS or Android apps is no exception. Having a great idea for an interesting app is exciting and can build a creative fire, but at the same time it is easy for idea overreach or a too-aggressive vision for the first version to overwhelm what could have been a successful app. Generally, apps that are too aggressive in their first functionality or vision of their 1.0 fall apart for one (or more) of four core reasons:
1) The app was a solution in search of a problem (i.e., no real need existed),
2) The implementation was poor,
3) The app tried to do too much; or
4) The Apple App Store rejects the app (either because the implementation was poor or it violated Apple’s content policies).
Keeping the app as simple as possible is the best way to avoid these pitfalls. Most successful apps (indeed, most successful consumer tech products) are based on what is called an MVP, or minimum viable product. It’s the product with the smallest feature set that can deliver the core function without any distracting “bells and whistles.” You know you have an MVP if the product would no longer function if you removed any single feature.
But what should that core feature be? One of the best examples of an MVP is Mail. Version 1 (on the Mac) offered a clear, limited and intuitive feature set whose usefulness was immediately obvious to anyone. Today’s iPhone version integrates seamlessly with your phone, contacts and calendaring. It automatically corrects spelling as you type, lets you email photos directly from your photos app, and does much more. But all that came later and was built on top of a basic core function. And that’s how your first app should be built. The key is to come up with something with a clear value that changes people’s lives.
So, in drawing up your MVP feature list, ask yourself what features are key to the experience. Some basic market research is probably in order, starting with a visit to the App Store to see what already exists (possibly to be improved upon and/or to compete with you). Likely must-have core capabilities include:
- Performance (e.g., fast screen refresh)
- Offline capability (i.e., ability to work when not connected to the Internet)
- Location awareness (e.g., the data/experience will change with the user’s location)
- Cloud syncing (e.g., users see the same data on multiple devices)
- Push notifications (i.e., sending updated information to devices as soon as it is available)
When you have a handle on what your app does, the next step is to design it. Designing your app involves making choices of how information and controls are presented to the user as well as how to implement app logic, and figuring out what data lives locally and what belongs in the Cloud.
Your user experience decisions will determine the app’s look and feel. They answer questions such as: What does the app look like? What screens does it have? In the software development world, onscreen objects like buttons, sliders, and fill-in boxes are called widgets. So you need to decide which types of widgets will reside on which screens. And what actions will occur as a result of the user interacting with those widgets?
Keep in mind that users will expect to interact differently with a mobile device than they do with a PC because the screens on mobile devices are much smaller. They’ll expect to use their fingers instead of a mouse or a track pad. Ideally, your app can even be used with one hand holding the device while using just a thumb for scrolling and working the app’s other controls — the Path app is a good example, and increasingly, so is Facebook.
Your app’s features will inform its architecture, which is how you’ll divide the code and data into functional parts. If your app requires interacting with other app users or networked services, you’ll need to figure out what piece of the logic lives in the app code and what comes from the backend. For example, your app might integrate with a restaurant recommendation engine, share user location, or pull real-time traffic data.
This is done using APIs provided by various service providers — but you don’t have to wire up your app to a network to get started. You can develop a prototype using predefined representative (or “dummy”) data. It’s easier to fine-tune the front end if you don’t have to simultaneously modify our backend too. Once you get the app’s look-and-feel right, then make those backend connections.
Once you’ve got the overall concept for your app, the next step is to express that design in terms of the iOS app architecture. That architecture is the model for what parts an iOS app can contain and how those parts fit together. It’s a well thought-out approach for translating a product concept into actual code you can deploy on a device.
How To Make An App: iOS Edition is a new eBook by Kinvey to get you up and running with XCode and iOS development. Readers of How To Make An App will learn the basic functionality of XCode, how to create user interfaces for iOS, exchange data with a backend, and how to make further progress.
How To Make An App: iOS Edition was written by Randall Cronk and Michael Katz. Since 1990, Randall has helped over 250 high-tech companies convey the value of what they do through white papers, web content, brochures, case studies and articles. Based today in downtown Boston, he was previously a vice president with Regis McKenna where he ran the Digital Equipment account.
Michael has always been a programmer; from developing logo programs in second grade to a visual basic-based performance piece on the Seven Bridges of Königsberg in high school. In college he detoured into modeling the brain, but eventually found his way back into software development at MathWorks. While there he developed Java-based desktop software before getting on the mobile bandwagon. For the past two years he worked on a native iOS app to perform complex scientific computation on the cloud.
Access the full eBook – here