Avatar

I'm Drew Breunig and I obsess about technology, media, language, and culture. I live in New York, studied anthropology, and work at PlaceIQ.

Likes

Posts tagged dev

A Checklist for App Developers in 2014

This weekend I thought a lot about the trouble app developers have breaking through the noise. It’s clear we’ve hit an inflection point in app development. As production became easier and distribution became democratized, a new problem emerged: yes, we can all build global apps in our garage, but so can everyone else.

The balance between supply and demand is difficult in every medium (film, music, TV, podcasts…) because demand is capped by a variable we cannot control: the time can spend people discovering and consuming. We can try to make each discovery and consumption easier or lower our costs of production, but the customer’s time itself is fixed. At some point, we always hit this wall.

And apps have hit this wall.

Our problem now is not how we build apps, but how we breakthrough. Great development isn’t enough. Only when development, design, and marketing are planned together can we succeed. Because an app isn’t good if nobody knows it exists.

Given this, I’ve assembled a quick and dirty checklist for marketing-phobic app developers inspired by both my experience as an app developer and my experiences crafting brand strategies for major companies.

  1. What is the single, simple mission of your app? If you had to reduce your app down to a single sound bite, what would it be? Is that sound bite compelling? Is it unique to you? It’s important for your app to have a simple purpose because almost every person you want to use your app won’t have more than a few moments to evaluate it. If your app doesn’t fit into a sound bite, you’re probably spinning your wheels on features that people won’t care about or, worse, will make your app more confusing.
  2. What existing community will your app appeal to? What group of people will care about and talk about your app? The biggest challenge here is (a) not picking a community that is already saturated with other apps and (b) picking a socially active community. If the community you want to target is being messaged about a new app almost daily, the odds are against you no matter how great your app. If the community doesn’t have an active online presence, they certainly aren’t going to talk about you. Find a community that’s underserved, vocal, and cares about your mission. Bonus question: how will you start a discussion with this community?
  3. How will your app be naturally shared via social networks? In today’s market, building an app without Facebook and Twitter integration (at least) is like playing baseball without a glove. You could do it. But you’ll disappoint your team, audience, and probably hurt yourself. I’m not advocating forced sharing (“Tell your friends now to unlock a level!”), though that may have its place. I’m arguing that you invest time and development into building a social sharing feature that makes sense and helps communicate your selected mission to your selected community.

This may seem like basics, but based on my dealings with app developers and surveys of the app store, I don’t think these questions are being clearly answered early in the process.

As app developers, we often become attached to features that impress us. Worse, we over-simplify planning with platitudes and ‘principles’ people apply to apps which have succeeded in different contexts. “Build something that solves a problem you have,” works when there’s only a handful of developers like you. Today, that’s probably not the case.

Treat these questions as a 3-part venn diagram. The features that sit in the overlap are the ones which should be focused on.

But, in a nutshell, here is my advice to everyone developing apps in 2014:

Identify a social, underserved community which has a problem you can solve. Build a simple app for them and give them a reason to talk about your solution.

In a future post perhaps I’ll break down how we stepped through this plan for Reporter (and yes, we dropped the ball on #3).


Update:

Two different developers (Jared Sinclair and Tyler Hall) published relevant case studies today highlighting their income from two apps, one iOS and one Mac.

In addition to being interesting financial snapshots, these cases highlight the discovery and pace of app installs (lots of hockey sticks). For one, they both target themselves, the developer/app nerd audience. To underscore this, Sinclair talks about how his biggest days were when bloggers featured his app, but the bloggers he mentions are Federico Viticci and Shawn Blanc, two dyed in the wool Mac bloggers. Sinclair’s RSS app Unread is excellent, but he’s stuck inside his community, not one which might support him. (Selling an RSS app to Mac nerds is like selling ice to Eskimos).

Unread also raises a bonus question for question #1: is your mission unique to you? Compounding the problem of Unread being an RSS app in a sea of RSS apps, its minimalistic approach isn’t unique, especially among RSS apps geared towards this community. If your mission is already owned by an established player who’s selling to your community, why do you exist?

Quick Sunday experiment: using an iBeacon to protect application data. If the beacon is more than 4 feet away the app locks up.

Here’s the code if you’re curious. You can pick up a beacon at Red Bear.

Objective-C: Decaying Time Interval 

In iOS 7 apps, color and animation provide the user with cues to an app’s function and data organization. An animation situates the user within the interface context, acting as a clue to the app’s inner workings.

But apps don’t usually evolve with their users. Animations move at the same speed during the first day of use as they do six months later. The user’s knowledge of the app has significantly improved. But the app gives the same day-one cues, like a heavy handed teacher ignorant of a student’s progress.

Maybe animations should speed up over time.

Here’s a quick function which allows you to specify an initial animation duration and an eventual duration. Over the decay period (14 days, in this snippet – adjust as needed) the animation duration quickens to its eventual speed.

Pass this to your animation calls and let your apps keep pace with their users1.


  1. This Gist is a late night sketch, so use with a grain of salt. Using the date since initial launch is a hack; perhaps a launch counter would be more apt. Also, you shouldn’t be hitting the disk every call. A time factor should be loaded in memory on launch.

Apple has Released the Source for TextEdit 

Great way to learn about Mac application structure.

The iOS 6 App Opportunity: Transit

Apple’s new maps application ships without public transit directions. Transit directions was a service provided by Google, whom does a mostly fantastic job at aggregating disparate public transit data into a unified format. While Apple has focused on delivering a great in-car experience, they’ve punted on local transit.

As a compromise, they’re recommending apps that provide transit directions from within the Maps app itself. A cany developer or team could be ready on launch day with apps for the top metro areas, which implimenting the new API hooks, and skip the hubbub of the App Store entirely by selling an app for a few dollars within Maps’ recommendation space.

Or you could make the app free and use it as a beachhead to promo additional apps. Shops with lots of apps (game companies, media outlets, etc) hugely benefit from being able to cross-market their other apps from within successful apps. For example, when Zynga launches a new app, they promo it within their existing install base to guarantee initial attention. One could use a transit app, ready on day one, to build a wide base of users for an larger suite of apps.

Personally, I prefer the pay case (and am anxiously awaiting such apps before I upgrade). Either way, it’s a big opportunity for the developer who can craft a sharp app quickly but is often stymied by the App Store.

Shell Apps and Silver Bullets 

90wpm:

Web technology is great for many things. Replicating a native app experience is not one of them.

If you’re thinking of going with HTML5 for your company’s app, read this and think again. Great arguments from someone who seems to know their ass from a hole in the ground.

AKA: don’t judge a framework/language/technique by its demo app.

This not only applies to HTML5, but also to bridge efforts like Ruby Motion. Sure, it’s crazy simple to write an example app, but once your app grows to a practical size, and you start spelunking in the API, the benefits of the bridge becomes moot.

However: the writer’s Facebook example is poorly chosen. FB’s app is largely HTML5, and for their specific situation this makes a lot of sense.

Update: Pete Warden (who is much better qualified to address this than I) responds much more vigorously (and convincingly) against this article’s claims, especially with regard to HTML5 performance claims.

Mike Krieger explains why Instagram uploads photos so quickly.

It’s slight of app.

More specifically, Adobe will require developers to share 9 percent of net revenue beyond $50,000 for using the premium features, Adobe announced today. The premium features are Stage 3D for hardware-accelerated graphics and domain memory for better conversion of games previously written in C or C++.

CNET on Adobe’s upcoming payment terms for premium Flash features. Adobe’s Emmy Huang explains the motivation behind the charges, “We’ve designed this pricing to encourage the kind of innovation and experimentation that often helps to spark inspired and inventive games.”

I’m a bit confused: asking developers to pay to keep a waning language competitive helps innovation how?

If this works, Sony will start taking royalties from filmmakers for an HD version of BetaMax.

PeteSearch: Twelve steps to running your Ruby code across five billion web pages 

Using CommonCrawl’s web archives, Ruby, S3 and Elastic MapReduce, Pete Warden shows you how to crawl 5 billion web pages for a few dimes.

Absolutely demystifying.

Build task claims to succeed in spite of generating error messages.
Best Xcode error message yet.
Next page Something went wrong, try loading again? Loading more posts