How to Plan a Mobile App Project

Over the past four years, I’ve worked on more than a dozen native apps for iOS. In this article, I’ll share a few insights gained through my work on three nonprofit apps:

Native App or Mobile Web?

Native apps are written specifically for a single mobile operating system, such as iOS or Android. They tend to be more expensive than websites – so why would you build a native app?

  • Performance and gloss: Sluggish experiences translate into a loss of audience and attention
  • Rich media: Your audience doesn’t have to wait for individual media files (audio, video, and high-resolution imagery) to download over unreliable cell networks
  • Offline access: Apps can be self-contained
  • Integrate emerging technology: iBeacons, environmental sensors, health monitoring devices, etc.
  • Buzz: It’s still easier to get your fans – and the press – excited about an app than a website
  • Focus: Apps can present an immersive, full-screen experience, without the distractions of web addresses and navigation
  • Multi-screen experiences: Technologies like AirPlay allow apps to present visuals on big screens – great for education and presentation contexts

Mobile websites are still sometimes a good alternative when:

  • Budget is limited
  • Cross-platform is essential (especially when combined with budget considerations)
  • Your audience will always have a decent internet connection
  • Media files are small or not essential to the experience

Defining the Project

If you’re not sure precisely what you want to build, hire a designer or developer to explore the possibilities through a limited discovery phase. This might include user stories, screen mockups, design elements, etc.

One great way to narrow the scope and features of an app is to write the app store description first, and sketch out five screenshots that will best convey what your project is about.

Be Prepared

Next, assemble your content: all of the text, images, sound, video, and other material you want to present.

Gathering and structuring this data doesn’t require complex database development. The Regional Arts & Culture Council uses a Filemaker Pro database to keep track of their public art collection in Portland. The Des Moines public art app is based on the data they manage in their WordPress-based website.

This is a long-term investment: when your organization makes a conscious choice to maintain a database, you will be ready to re-use the information in a variety of contexts well beyond the app you currently have in mind. It’s impossible to know how you might want to present this information in five or ten years, but you’ll be ready for new opportunities as they arise.

Refine Your Plan

All three of the projects mentioned above feature geographic data. Though they seem similar on the surface, working with actual content led to diverse designs. (For more on this, check out slides from a talk I gave at the O’Reilly Open Source Conference in 2011.)

Here in Portland, we chose to use pin colors to highlight the different artistic disciplines of the public art on the map:

Public Art PDX - mobile app screenshot

In contrast to Portland, Des Moines’ public art collection tends to be located in specific places, such as the Pappajohn Sculpture Park. We added a feature to let the audience zoom in on a particular area of the city:

Des Moines Public Art - mobile app screenshot

The original designs for the PDX Social History Guide also focused on mapping, but as we listened to the interviews, we found that fewer than half the story clips could be attached to a specific location. We switched to a thematic index instead as the primary interface:

PDX Social History Guide- mobile app screenshot

The app still has a map, but it’s a secondary path to the stories, and its value is different: it reminds of us the geographic overlap and interplay of different histories and communities.

While some of these nuances can be predicted in advance, it’s not always possible to imagine the best ways to present content until you have it. That’s why you want to have a good, representative draft of all your content before you start building the app.

If content arrives partway through implementation and it doesn’t fit your design concepts, this can create major delays, require costly rewrites, or sink a project altogether.

Define Deliverables for Content and Media

It’s expected that your developer will work towards project milestones, but it’s just as essential to define internal deadlines for delivering graphics, media, and text, as well as feedback on designs and test versions to your developer. Falling behind on deadlines and sign-offs can be expensive, as mentioned above.

Ideally, don’t begin the design phase of your project until you have your content ready to go, a clearly defined scope for your project, and your funding in place.

Move Fast

Once you have your scope and content, move through the design and implementation phases quickly. Unless your project is truly massive, an implementation phase longer than a few months is not advisable.

iOS has settled into a yearly update cycle and it’s not unusual to see 70-80% adoption of a new iOS release within a few months. You don’t want to be stuck with an app that’s based on a previous version when most of your audience has already moved on.

Building on current features will also help you future-proof your app and extend the value and impact of your investment.

Test, Test, Test

I can’t emphasize this enough: make sure your developers are doing real-world testing on actual devices. Your app needs to be ready for the rigors of mobile, including:

  • Limited hardware
  • Unreliable cell and wi-fi connections
  • Battery warnings, notifications, phone calls, and other disruptions
  • Screen glare or audio in noisy environments

Simulators are fine for the development phase, but there are many problems you won’t identify until you try to use your app as your audience will on a phone or tablet.

Also, ask your developers to share regular beta test versions with you as you get close to launch and provide regular, timely feedback.

Revenue & Donations

Amidst the deluge of free digital content, I’ve been encouraging clients to consider charging for their apps. If you charge for print publications, conferences, trainings, or other program activities, why not charge for apps?

At a minimum, think about giving your audience the opportunity to support your work by making extra features available via in-app purchases.

Either way you go, be aware that the app stores do take a hefty cut of sales: Apple, for example, takes a commission of 30% on all App Store transactions.

Donations are an option, but there are some limitations: Apple requires that apps with donations must be free, and all donations must be made in the Safari browser or via text message. Though this is less convenient for your supporters, the upside is that you don’t have to pay a commission.

Matt Blair
Software Developer
Matt Blair is a software developer that creates apps and websites that enrich our connections to culture, place, and each other. He led development of iOS apps that were selected by Apple for their iPad Apps of the Year collections in 2012 and 2013, and also designed and built a poetry editor for iPad called Line & Verse. He lives in Portland, Oregon. Website: