WillowTree (www.willowtreeapps.com) is a leading app development company that has produced over 300 titles since 2007, such as My Pregnancy Today that has seen more than 12 million downloads. Our collaborator, Alkis Polyrakis, discussed with their Systems Architect, Alex Shafran, who led the development of projects for GunBroker, Quintiles, the Red Cross and the NBA, about their strategies and tools of preference.

Please begin by giving us some information on a few of WillowTree’s most successful apps.

WillowTree has helped clients succeed in a variety of markets. Johnson & Johnson’s Baby Center apps have been a worldwide success, grossing over 10 million downloads and consistently ranking high in the App Stores. We recently released the new version of the official NCAA app, which is the main source of college sports scores and news. In the enterprise, we built an app for the AOL marketing team that auto-generates sales slideshows based on a quick questionnaire. This app saves each salesperson hours each day and allows them to prepare less and sell more.

WillowTree claims to tackle complex enterprise-grade mobile deployments by beginning with a simple question: “Where should what logic live?”. Can you explain what this quote means to our readers?

Even the simplest “mobile apps” require infrastructures to support them. Ordinarily, this “backend infrastructure” is software running on a collection of servers in a data center. By asking where should live, we are referring to the separation of concerns between the app on the phone and the backend servers. Consider Pandora, the popular music streaming app. When the Pandora app is downloaded from the App Store, the phone now has the code to run the app. However, the phone must get the music from somewhere — the entire music catalog is not stored on each user’s phone (that would be redundant…and impossible). This is where backend servers come into play. At a basic level, Pandora has a collection of severs that store the millions of songs in their catalog. When the apps need to play a song, they use the internet to download the song in real time from one of these servers.

Pandora is the most obvious example of “where logic should live” — clearly the entire music catalog should not be on each phone. But we encounter different flavors of this problem everyday, from “Should the phones store the user’s password” (the answer is no, NEVER), to something as basic as “Should we use the phone’s clock or the server’s clock in our realtime bidding app?”. While the answers might come easy to us, talking through these details can help our clients understand the benefit of adding an additional component to the system.

The sheer number of mobile apps that you have developed for major clients is impressive. In addition to quality project management, this is a clear indication that you are using the right development tools. What are those, and how do they make your job easier?

Development tools are only part of the story. They are critical to keeping projects on track, but they must be used as a supplement, not a replacement, to in-person communication. Our entire development team is colocated in Charlottesville, Virginia, which gives us massive efficiencies. When possible, we like to share those efficiencies with our clients. We regularly send entire project teams to client sites, and their development teams visit us just as frequently. There is no replacement for in-person collaboration.

Of course, we also make regular use of phone checkins and online tools. We use Teamwork for project management and communication. It is so simple and powerful that many of our enterprise clients have also adopted it internally. Project/sprint planning is done in Jira, which helps us gauge project burndown and overall progress.

Our continuous integration system (CI) is the most automated tool in our process. When a developer commits code, the CI downloads the newest code, builds it, runs the auto-mated tests, and releases it to our QA team (and the client, if appropriate). This entire process can take under a minute, but the same tasks could take a developer half an hour.

Is prototyping part of your development process? If so, which tools do you prefer for your apps?

Absolutely. We try to get usable software into our client’s hands as quickly and as often as possible. Prototyping is often the fastest way to do this, via static prototypes or even stubbed code. Before development even begins, our UX team uses InVision to turn visual mockups into clickable prototypes. These prototypes run on the phone just like real apps, which allows us to get critical feedback very early in the process. We highly recommend using InVision when possible.

Clients often want their apps to support in-app purchases and ads. Do you prefer to build a business model around the project before the development even begins? What is your monetization platform of choice?

There are a several monetization models available on mobile, from: free, ad-supported, in-app purchases, and paid download. The first goal of any application is to get the user to download the app, and we have found that a price-tag of even $0.99 can be a deter-rent for apps in saturated markets or lower-income demographics. In these situations, our clients should consider alternate monetization policies. If the basic functionality can be provided at a low cost, then it might be a good idea to consider a “freemium” model, where the app is free to download but premium features must be purchased (e.g. Evernote). Ad-based models (Facebook, Flixter) can also work, and companies are getting very creative with “native” ads that look like real content. The freemium-ad hybrid model is also popular, which is where a user can pay to remove the ads. However, the paid-download model, like the Dark Sky realtime weather app, can succeed if the app provides functionality that is otherwise unavailable.

Compare the development tools that were at hand when WillowTree started out 8 years ago to the current ones.

When WillowTree first started out 8 years ago, mobile was a very small (but rapidly-growing) industry. The tools we used were either provided by Apple/Google (the xCode IDE) or ported from other tools (Eclipse for Android). There was no third-party ecosystem of tools to modify for our needs.

Now, we use Android Studio, which is an extension of IntelliJ specifically for Android development. xCode for iOS is more robust (and hardly crashes), and both tools are a core part of our Continuous Integration (CI) workflow, which took years to fine-tune. It allows us to automatically (and safely) ship tested code to clients and to the App Stores. Our build distribution tools, TestFlight and HockeyApp, now allow us to see which versions of the app the client has installed/tested. These automated workflows take the burden off developers and allow them to focus on writing quality code.