Watch on YouTube

I am delighted to announce that today I am launching a new development related podcast with Marco Arment. It is called Under the Radar and starts today on the fine Relay FM Network.

I have been doing Developing Perspective since July 13, 2011 (roughly 4.5 years). During that time I have chronicled the rises and falls of being an independent developer in the App Store. I am immensely proud of Developing Perspective and glad that I have it to refer to later on as I look back on my career.

The time has come now to embark on a new adventure in podcasting.

Back in late 2010 a new podcast was started called Build & Analyze with Marco Arment and Dan Benjamin. I hadn’t really heard of either of them before but I immediately latched onto it. Marco’s experiences and perspectives in being a developer were both relevant to my work and engaging to hear. For the entire run of Build & Analyze you’d always find me in the chatroom listening live, suggesting titles.

In many ways it was the show that most motivated me to start podcasting. To create a venue for sharing my experiences and hard learned lessons. I was very sad when it finally wrapped up its 108 episode run. All that makes the prospect of starting a new development podcast with Marco a great joy.

If you liked listening to Developing Perspective I’d really encourage you to subscribe to Under the Radar. It is in many ways the spiritual successor to Developing Perspective and Build & Analyze. A venue for us both to discuss and examine what being a developer means today — the challenges we face, the opportunities we see, the lessons we learn. Oh, and it’s never longer than 30 minutes.

So let’s get Started

• the beta schedule,
• timing for release,
• the importance of RADARS,
• my growing interest in Swift and

• an encouragement for everyone to build something new this summer.

• Will Hains’ iOS Beta History

My Essential Experience Target: An application focused on surfacing the data currently collected by the Apple Watch and iPhone and presenting it in a useful, actionable, and encouraging way.

Blizzard’s Games I discuss:

• Hearthstone
• Heroes of the Storm

My previous Start-to-Finish series discussing the creation of Check the Weather:

• #91: Thank you and the Road from Here.
• #90: Check the Weather
• #89: Counting Down.
• #87: Basic App Marketing.
• #86: App Pricing.
• #85: Pragmatism.
• #84: Shipped it.
• #83: Performance and Letting Go.
• #82: Localizing an App.
• #80: Managing functionality.
• #77: Prototyping a new project.

• 2015 Developing Perspective t-shirts (4 days to order, ends May 18.)

One of the most dangerous traps when learning from someone else’s experience is ascribing intentionality to what in reality was accidental. This can make it feel somehow magical or impossible to learn from. We are all just muddling along.

• Pedometer += 1,000,000
• Joe’s Extraordinarily Kind Words

• 2015 Developing Perspective t-shirts (1 Week left to order.)

Once again the topic of sustainable revenue has surfaced around our lovely community. I’ve recently been changing/adapting my thinking on the subject so it seemed the time to wade in again.

• Tim on the App Store

“The app store had its best quarter ever, with a record number of customers making purchases, driving a new record for revenue, and 29 percent year on year growth.”

• App Store Metrics

In April, 2015: 1,561 apps per day (35,929 non-games, 12,451 games, 48,380 total)

Where we are:

• Redacted for Mac Launch
• Realmac Product Revenue Snapshot
• Sensor Tower Top Grossing Analysis

From here:

• Inquisitive: Behind the App #11

• Learning to Ride a Bicycle, Again.

• Sam Soffes on Developing Perspective #208

• 2015 Developing Perspective t-shirts

• My WatchKit Apps

• Release Notes Conference

In some ways this week’s episode is a follow up to last week’s show about hustle. All that thinking about the role that asking for money plays in my business got me to thinking about some of the complications that being the face of your business carries. When you are an independent business owner your own personal brand becomes the brand of your products. This can be awesome but also makes certain parts of promotion and discourse more complicated.

• My WatchKit Apps

• Simultaneous Invention

Chart of my consistency track record for Developing Perspective:

The Phases of Gold Rush:

• The Rumor
• The Legend
• The Rush
• The Reality

Luck = Opportunity + Preparation

• My WatchKit Series
• Scott Forstall, “Whole new Gold Rush”
• The California Gold Rush
• Trism
• WatchCon 2

There is unfortunately no shortcut to gaining expertise in a subject. You can only truly understand something by working on it, by immersing yourself in it, by building terrible prototypes and throwing them away. You cannot throw away what you haven’t made.

• Building an App Preview

My intention isn’t to scare anyone off, but just to help you understand the inherent complexity of this line of work, and an appreciation for the things other people handle for you in a J-O-B, job.

General Development

• Software engineering
• Bug tracking
• Product Design
• Release planning
• Customer support
• Version Control
• iTunes Connect submission lifecycle

iOS Development

• Objective C, Xcode, Interface Builder
• Device and iOS version management
• Photoshop, PaintCode
• Testing / QA

Server Development

• Ruby on Rails
• Postgres
• Memcached, nginx, redis
• Queueing, sidekiq
• Linux system administration, Backups, Security updates

Operations

• iTunes Connect, contracts, payments,
• Accounting, Taxes and banking.
• Budgeting
• Compliance, Local, State, Federal, Business Licenses
• Benefits / Welness
• General hosting, email, domains, etc

Marketing

• Websites
• ‘Brand’, personal and otherwise
• Photoshop
• Marketing concepts and ideas
• Microeconomics

• Swift on Apple.com
• My WatchKit series

Sam has been developing for iOS since 2008 and has worked on a wide variety of successful products. He is currently working on Whiskey, a Markdown editor for Mac and iOS.

• Marketing Complexity: The pressure to keep adding features in order to keep software relevant in a marketplace.
• Intrinsic Complexity: The unfortunate reality that any added feature doesn’t just linearly increase complexity, instead it increases radically.
• Personnel/Personal Complexity: The tension and struggle around keeping sharp, talented engineers focused on stability when the promise of working on something else, newer and more exciting looms.

These are the concerns we need to stay conscious of in order to manage our software over time.

• Handshake Problem

As an experiment I also recorded this episode as a video. I’m not really sure how valuable this is but I’ll never know unless I try. I’m thoroughly enjoying trying out video recently as a medium for sharing within our community.

As a result of how my recording was setup the audio for this episode as a bit more echo than I would have liked, I’ll get that buttoned down if I try this again.

• YouTube version of this Episode

• My first attempt at Youtube

Then, I dive into the economics of building WatchKit apps. In general I think that the economic realities of building apps for it are consistent with any other app endeavor. If it was a good idea before it is likely doubly so to add a Watch extension. If it is a new idea you have a great opportunity to be an early adopter.

• Getting Started with WatchKit
• My Initial Impressions
• Apple’s Main WatchKit page
• Developer Forums

• Derek Sivers on ideas.

Trying to formularize this I came up with the following structure for ideas and where sharing them is likely a good and poor choice.

Like all good concepts it can be best demonstrated with a two-axis graph with four quadrants:

On the one axis is the ease of implementing/realizing the idea. On the other is the expected return on a successful implementation of that idea.

• Easy, High Reward: If you actually have one of these (you likely don’t) keep it quiet and run with it as fast as you can. Likely hyper competitive. Simultaneous invention everywhere.
• Easy, Low Reward: Confections that are likely flash in the pan (if they flash at all).
• Hard, Low Reward: Time sinks, labors of love. Most ‘I have a great idea for an app’ pitches. XKCD on easy vs hard problems.
• Hard, High Reward: Real businesses are built here.

To help me get up to speed I’ve been purchasing a variety of devices to start getting my feet at least slightly damp, if not actually wet. I started with the Jawbone UP and just got the Microsft Band. These are my initial reactions and thoughts.

• Jawbone UP 24
• Microsoft Band

• My 7th iOS (iPhone) Developer Program
• My first app approved 6 years ago
• 200 Episodes

I tried to boil them down into four keys:

• Purpose
• Diversity
• Flexibility / Ruthlessness
• Patience / Tenacity

Also, what’s going on with the iPad?

• Marco Arments’s thoughts on Retina iMac vs Mac Pro
• AnandTech’s Hands-on

Also, why I didn’t make the icons wiggle.

• The Boring Designer
• Creating Passionate Users
• Creating Passionate Users - Feature Curve

🎉

Trade Offs:

• App Review
• Marketing (good and bad)
• Bugs and Issues
• Helpdesk load
• New features and their worth
• Wasted effort

Approaches:

• As ready as you’ll ever be: Work feverishly, battling through buggy betas and API changes to be as possibly ready as possible for the estimated release date.
• Measured compatibility: Just make sure it doesn’t break
• Kinda ready: Keep an eye on the changes, have plans in place for basic compatibility begin in earnest once bugs are fixed
• Wait and See: Wait until you have all the information before you really start

Pincer Maneuvers

Apple is fantastic at laying groundwork. When you take a step back and how their offerings both on software and hardware have evolved over the last few years you can clearly see how much forethought has gone into their approach. Apple doesn’t just throw things over the wall as soon as they are ready. Instead they prefer to gradually expand and enhance their capabilities over time, giving developers lots of warning and time to adapt.

I can think of many areas where this has been the case but perhaps the clearest example is the iPhone 6/6+ screens. A few years back they brought Auto Layout to iOS. Then they changed the UI aesthetic in iOS 7 to discourage designs that focused on pixel perfect layouts. They introduced Dynamic Text to add an element of variability and customization to the user experience. Then came Adaptive Layouts, Launch screen Nibs and Asset Collections. Each of these is a puzzle piece that gave the astute developer insight into what was coming down the road. This is just one example. Things like TouchID, or AirPlay have similar aspects. You can even see some of this in the Apple Watch. How it builds so neatly on top of the Extensions approach in iOS 8.

You could almost imagine room deep in One Infinite Loop with a massive product roadmap laid out. Around it, like Generals in combat, Craig and Jony push around the little pieces that comprise Apple’s ecosystem. Slowly pushing them into place so that they can combine in clean pincer movements around desired objectives.

Apple does this better than most companies I know. There are times their plans don’t quite come together but they do more often than not. It is a reminder to me as a developer to try and not focus too tightly on the direct implications of a new API or technology. Instead I should take a step back and think what this could be laying the groundwork for down the road.

Stubbed Toes

Nobody likes stubbing their toes. It’s painful, expletive laden and can leave a mark. But what is really bad isn’t stubbing your toe…it’s stubbing your toe while running. That is when the real damage happens. Now it isn’t just your toe that hurts it is your entire body hitting the pavement.

The breakneck pace that Apple has been moving at over the last few years broken more than a few toes along the way. I see this especially in the areas of Developer Tools and Infrastructure. Working with these I’m often give the impression that they are straining to the limit to keep up with the complexity and pace of the platforms they need to support.

If an Army marches on its stomach, Developers march on their Tools.

Xcode is the tool I spend most of my working life in. I know it very well and for most of what I need it to do it does a great job. But each year I am confronted with a new wave of challenges, crashes, or workarounds as I try to make it do what it ostensibly can and needs to do. Some of these are excusable as early beta issues or components that weren’t quite ready for WWDC but as we get close to launch their failings become painful. If the tool isn’t sharp the sculpture won’t be smooth.

Similarly the infrastructure that supports so much of what we need to do is straining to keep up. Provisioning and iTunes Connect never quite seem finished. Having done this for a long time I know most of the workaround and ways to massage things into place but I can only imagine how tricky this must be for a new developer. They get better over time but just as soon as they stabilize some new complexity is thrown onto them to try and tackle.

I have nothing but respect of the talented folks at Apple (some of which I know personally) who try and hold these together. But it is Sisyphus-ian task to keep up with the pace of change in our toolset. What worries me most is whether we are heading to a point where our pace of change will overtake their ability to keep up and then the whole body comes crashing down.

In it together.

These two aspects of modern iOS life are both closely entwined and diametrically opposed. Apple appears to have an incredibly rich roadmap had for his platforms. As a developer I can see tremendous opportunities coming down the pipe. In many ways this is the best time to be a developer I’ve ever seen. I just hope that Apple is able to re-double their efforts on the tooling and infrastructure fronts to keep up with the colossal task ahead of them.

I’ll also touch on the new page Apple published listing the Common App Rejection reasons.

I went ahead and organized the changes into a more readable format.

Accessibility Note: A less color oriented version of this diff is available here.

Preamble

We have over a million Apps in the App Store. If your App doesn’t do something useful, unique or provide some form of lasting entertainment, or if your app is plain creepy, it may not be accepted.

2. Functionality

2.9 Apps that are "beta", “demo”, “trial”, or “test” versions will be rejected. Beta Apps may only be submitted through TestFlight and must follow the TestFlight guidelines

2.25 Apps that display Apps other than your own for purchase or promotion in a manner similar to or confusing with the App Store will be rejected, unless designed for a specific approved need (e.g. health management, aviation, accessibility, etc.) or which provide significant added value for a specific group of customers

Update: Section 2.26 still includes much of this language and reads “Apps may display and recommend apps other than your own only if the collection is designed for a specific approved need (e.g. health management, aviation, accessibility, etc.) or provides significant added value for a specific group of customers, or they will be rejected” Thanks @Padraig

3. Metadata

3.3 Apps with names, descriptions, screenshots, or previews not relevant to the content and functionality of the App will be rejected

3.6 Apps with App icons, screenshots, and previews that do not adhere to the 4+ age rating will be rejected

3.14 App previews may only use video screen captures of the app, voice-overs, and textual and design overlays, or the app will be rejected

3.15 Apps with previews that display personal information of a real person without permission will be rejected

3.16 App previews may only include music that is licensed for that purpose in all selected territories

3.17 App previews that include content played or streamed via the app (e.g. iTunes playlist, YouTube streaming video) that is not licensed for use in the preview will be rejected

14. Personal attacks

14.3 Apps that display user generated content must include a method for filtering objectionable material, a mechanism for users to flag offensive content, and the ability to block abusive users from the service

17. Privacy

17.5 Apps that include account registration or access a user’s existing account must include a privacy policy or they will be rejected

22. Legal requirements

22.10 Apps that use iTunes music previews in an unauthorized manner will be rejected

25. Extensions

25.1 Apps hosting extensions must comply with the App Extension Programming Guide

25.2 Apps hosting extensions must provide some functionality (help screens, additional settings) or they will be rejected

25.3 Apps hosting extensions that include marketing, advertising, or in-app purchases in their extension view will be rejected

25.4 Keyboard extensions must provide a method for progressing to the next keyboard

25.5 Keyboard extensions must remain functional with no network access or they will be rejected

25.6 Keyboard extensions must provide Number and Decimal keyboard types as described in the App Extension Programming Guide or they will be rejected

25.7 Apps offering Keyboard extensions must have a primary category of Utilities and a privacy policy or they will be rejected

25.8 Apps offering Keyboard extensions may only collect user activity to enhance the functionality of their keyboard extension on the iOS device or they may be rejected

26. HomeKit

26.1 Apps using the HomeKit framework must have a primary purpose of providing home automation services

26.2 Apps using the HomeKit framework must indicate this usage in their marketing text and they must provide a privacy policy or they will be rejected

26.3 Apps must not use data gathered from the HomeKit APIs for advertising or other use-based data mining

26.4 Apps using data gathered from the HomeKit API for purposes other than improving the user experience or hardware/software performance in providing home automation functionality will be rejected

27. HealthKit

27.1 Apps using the HealthKit framework must comply with applicable law for each Territory in which the App is made available, as well as Sections 3.3.28 and 3.39 of the iOS Developer Program License Agreement

27.2 Apps that write false or inaccurate data into HealthKit will be rejected

27.3 Apps using the HealthKit framework that store users’ health information in iCloud will be rejected

27.4 Apps may not use user data gathered from the HealthKit API for advertising or other use-based data mining purposes other than improving health, medical, and fitness management, or for the purpose of medical research

27.5 Apps that share user data acquired via the HealthKit API with third parties without user consent will be rejected

27.6 Apps using the HealthKit framework must indicate integration with the Health app in their marketing text and must clearly identify the HealthKit functionality in the app’s user interface

27.7 Apps using the HealthKit framework must provide a privacy policy or they will be rejected

27.8 Apps that provide diagnoses, treatment advice, or control hardware designed to diagnose or treat medical conditions that do not provide written regulatory approval upon request will be rejected

28. TestFlight

28.1 Apps may only use TestFlight to beta test apps intended for public distribution and must comply with the full App Review Guidelines

28.2 Apps using TestFlight must be submitted for review whenever a build contains material changes to content or functionality

28.3 Apps using TestFlight may not be distributed to testers in exchange for compensation of any kind

Context

I did a long analysis of the update trends in the App Store. I recommend you visit that yourself but the short version is:

• 50% of Top Apps are have been updated in the last 3 months (26% overall)
• 86% of Top Apps in the last year (60% overall)
• 300,000 apps were updated in the last 3 months.
• 480,000 apps are effectively abandoned (no updates in last year)

Types of Updates

An actual shipped update might include more than one of the following categories but it is likely constructive to think about why you are making a change before you make it.

• Compatibility: An update that exists to allow the existing feature set to work on new hardware, operating system, API, etc.
• Remedial: An update that exists to correct a flaw or deficiency in existing functionality.
• Defensive: An update that exists to keep up with the competition.
• Enhancement: An update that adds functionality or capability to the app.
• Marketing: An update with purpose of drawing attention to the app or garnering revenue.
• Refactor: An update that does not change the user facing portions of the app but improves it internally.

Things to consider

• Is this update necessary? Why, concretely, am I doing it?
• Does adding this functionality improve the app for most users?
• Would adding the functionality hurt the experience of any of my users?
• How do I expect to be compensated for the time I put into this update?

I must confess I was a bit apprehensive in preparing for this week’s show. I have had a number of people reach out to me saying they can’t wait to hear me chime in. I’m right in the thick of this. I’m an “indie” developer who has been making my living off the App Store for nearly five years now, so I’m no stranger to the ups-and-downs it involves. If you are hoping that I have some grand unified model that might summarize our current situation, sadly I think I’ll have to disappoint. Business is complicated, dynamic and ever changing. You can do the same thing twice and have wildly different outcomes. Replicating someone else’s approach may not work, or may work shockingly better. Perhaps most importantly, we all have different goals, personal situations and backgrounds.

But here is my best effort, constructed as a series of semi-cohesive mini-rants.

Super, mega, high level overview.

It has never been easy to make a living (whatever that might mean to you) in the App Store. When the Store was young it may have been somewhat more straightforward to try something and see if it would hit. But it was never “easy”. Most of my failed apps were launched in the first 3 years of the Store. As the Store has matured it has also become a much more efficient marketplace (in the economics sense of market). The little tips and tricks that I used to be able to use to gain an ‘unfair’ advantage now are few and far between. The fundamentals of business competition still apply:

• You need more than a good idea.
• The market doesn’t care about the process it cares about the result.
• As supply goes up, prices will fall.
• Diversification of your product line is essential for stability.
• Most businesses will fail.
• …

There are aspects of the App Store’s design that may have enhanced or hastened the emergence of some of these behaviors (and certainly a few unnecessary, undesirable ones) but most would be there no matter what.

Unique opportunity.

One thing that also strikes me is how uniquely situated developers are as a profession. It is rather remarkable that we can even consider there to be a reasonable likelihood that if we do the thing that we love it will ultimately result in a sustainable living. I think of almost all other crafts where you can pursue your passion: art, design, acting, music, etc. In most cases you either pursue your passion as a hobby and are fine with that or pursue it while employed by someone else. Software and the current state of the tools at our disposal allow for a tremendous opportunity to have an alternative path. For you to create something, to enjoy the process of making it and for it to be reasonably possible for you to make a living from it. Let’s be careful to make sure we don’t forget just how fortunate a position that is.

Different Goals.

Whenever we start to think and talk in terms of things like ‘making a living’ it is almost necessarily ambiguous for what that might mean. We all have different goals, lifestyles, standards of living. Perhaps, even more significantly live in different countries. Our individual definitions of success are likely wildly distinct. I know many developers for whom the ultimate goal was simply to ship, and while the fleeting notion that they could derive some renumeration for their work was fun to muse about over a beer was never really the goal. On the other hand I know people who dive in full steam and put their family livelihood on the back of their work. I remember working on one of my apps in the early days of the App Store and reading an article by my most direct competitor (who I knew was making a similar amount of income as I because of our relative ranks). He was based in eastern europe and talking about how he was able to support a team of developers on their income. I wasn’t even yet able to support myself on that apps income. It is all relative.

I will again state my most oft stated advice to anyone wanting to get into making apps. Define what success means for you, before you start building.

Indie Life.

The word ‘Indie’ has taken on a somewhat mythical connotation within our community (whether conscious or unconsciously). It can take on the persona of this genius engineer, tirelessly toiling away on their work, sweating the details, making the hard decisions and then (after much noble blood, sweat and tears) emerging with a gleaming product. They then take this product out into the world and it begins to generate “passive income” sufficient for them to continue their artisanal craftsmanship. I must say I love this story. It sure does sound nice. It lets us elevate and aspire towards a rather delightful ideal. However, as someone for whom this title is oft ascribed I can say the reality is almost nothing like this.

Being an ‘Indie’ (if I take that definition to be a small [1-3 people] team of developers who make their core income directly from the software they create) is much less romantic. It is a lot of duct tape, cut corners, worried nights, ends-not-quite-meeting. All with the Specter of Failure’s chilled breath down your neck. Don’t get me wrong I love it, it appeals to my personality. But it isn’t for everyone, nor should it be.

As a community I think we tread into dangerous territory where we place undue elevation on this type of development and begin to (either directly or by implication) start to look down our proverbial noses at the many other much more sane ways to make a living. I have tremendous respect for people who support their families working hard within larger corporations (whether that be Apple or the OmniGroup or XYZ Corp). And for consultants who do the very hard work of consulting.

The nobility comes intrinsically from the effort, from the care and attention, from work in its own right. It doesn’t come from the context in which that work is done, it is the work itself.

Patience.

There is a natural human reflex to look at the end result of someone’s long effort and want to arrive at the same endpoint, but without internalizing the time, energy and effort it took to get there. If you are foolish enough to begin down the path of creating and selling your own products the single most important thing to have as a character trait is patience, well maybe that and a thick skin. The path to a sustainable income is almost necessarily built upon a series of mistakes (whether they be public or private). I can think of very few counter examples to the notion that it will takes a time period measured in years to be able to support yourself from your work. I do truly believe that building quality products, being an adaptive student of the stores/markets into which they are sold and consistently improving your own skills provides a likely path to sustainable revenue, but it isn’t an easy, nor quick path.

Build. Ship. Repeat.

Required Reading.

Here are a selection of the fantastic posts written on this topic recently. I commend them all to you as homework. If you have any interest in devoting your time or career into this arena you’ll be foolish to not put in the time to read them all. They are written by some seriously smart people, who I respect very much.

• Confessions of an ex-developer
• Who at the Table is an Indie iOS Developer? - Brent Simmons
• A Candid Look at Unread’s First Year - Jared Sinclair
• More on iOS Indies - Brent Simmons
• Jared Sinclair Discusses Unread’s Earnings - Benjamin Mayo
• The New Indie - Cezar Pereira
• A Candid Look at the Financial Side of Building Mac Apps on Your Own - Tyler Hall
• App Rot - Marco Arment
• Looking Up - Joe Cieplinski
• Unavoidable - Luc Vandal
• The Price of Great Software- Robert Myers
• Why I Left Indie Development - Nick Bradbury
• Being Indie in 2014 - Gus Mueller
• Hacker News on Jared’s Article
• On Promotion and Marketing - A Response to Critics of Yesterday’s Article about Unread - Jared Sinclair
• The market for paid apps, and the sum of all compromises - Rene Ritchie
• App Store Pricing Models - Stephen Johnson
• Developers cannot monetize continuous development of their products. - amber
• The iOS Indie That Could - Faruk Ateş

I will be on vacation for the next two weeks, so unless something monumental happens in between now and late July there won’t be any episodes of Developing Perspective.

Back at WWDC, basking in the glow of the river of great new announcements I had quipped “Wow, they gave us everything but a business model.” That comment is clearly absurd but it does drive towards a more honest and worthwhile point. In many ways the situation iOS developers find themselves in heading into the Autumn of 2014 isn’t about technology or tools, it is about business. As the market has matured the natural consequence is that older inefficiencies that may have propped up unsustainable models have fallen away.

The App Store and related ecosystems are now extremely efficient. If there is an opportunity to be exploited we can expect it to be found and exploited. If you come up with a great new idea it will be analyzed, dissected and the interesting parts copied with often head-turning pace. As I have navigated this transition myself I have started to see many issues with the approach I had been taking to my business. Some of which I have been able to address but many of which I’m still working through.

For the purpose of today’s episode I thought it might be constructive to take a quick tour of the various models and their various strengths and weaknesses. I’m going to be working in rough order of which I think they are desirable in the current ecosystem.

Subscriptions

tl;dr - People pay you on an ongoing basis for providing software and software related services.

Pros - So long as your subscription base is enough for your expenses and your renewal/signup rate exceeds your cancellations you are golden.

Cons - Often tricker to get someone to make a long term commitment. Managing credit cards, expirations, etc. Typically smaller user base needed (yay!), each requiring and feeling owed more (not so yay).

Advertising

tl;dr - People use your software and are presented a message from someone else you pays you.

Pros - Strong possibility for ongoing revenue. Can make your software free.

Cons - You need to show other people’s messages in your apps. Requires large customerbases for reasonable revenue.

Consumable In-App Purchases

tl;dr - People make (typically) small, repeated payments to continue to gain access to aspects of your software. Gratuity based models also fall into this category.

Pros - Strong possibility for ongoing revenue. Lets you segment your customer base by how much they are willing to spend.

Cons - Can quickly get very dodgy.

One Time In-App Purchases

tl;dr - People make payments to gain access to specific parts of the application or content therein.

Pros - Gives users a clear trial of the experience before needing to make a commitment.

Cons - Often very tricky to work out what part of the application can be segmented off. If you are too generous nobody will buy, too stingy and nobody will buy.

Up Front One Time Purchase

tl;dr - People pay money to be able to use your software.

Pros - Simple and straightforward.

Cons - Trickier to make sustainable since your effectively cap your income per user. Single Price. Long term support gets hard to justify.

Free

tl;dr - You create software, everyone uses it without charge.

Pros - Wide adoption potential.

Cons - Often hard to sustain long term. Most often seen in either altruistic or venture based software.

What is best?

It is going to vary for each business. What I have found over the last 6 years is that models that have more of a focus on ongoing revenue are more sustainable than things that are more one-time oriented. Mixing as many as you can often is important too.

It is also absolutely imperative that you have a good working definition of what success looks like for yourself before you can make a thoughtful choice.

This isn’t an exhaustive list but these are the places I always make sure I’m up to date with.

I actually use Twitter a lot less than I used to. The signal-to-noise (even with aggressive muting) is just too low.

Podcasts

Programming and Design

• Debug
• Iterate
• Mobile Couch

Business-y Stuff

• Release Notes
• Core Intuition

General News

• The Prompt
• Accidental Tech Podcast

Blogs

• Inessential
• Jared Sinclair
• Ole Begemann
• MacStories

Misc

• Hello Internet
• Pragmatic

Accessibility is an important aspect of software development. Apple’s platforms provide a wide array of tools for easily adding it into your apps. The return for this effort is often somewhat ephemeral but nevertheless rewarding.

• Basic Accessibility overview
• Triple-tap home shortcut
• Thoughtful ordering of controls
• Thoughtful ordering of words

• Design the experience, not narration.

• Pedometer++ (the app discussed).

Get a solid grasp of what’s new

Start with Apple’s own overviews:

• iOS 8 for Developers
• What’s new in iOS
• API Diffs

Keep in mind questions like these:

• What does this enable that isn’t currently possible?
• How would Apple promote this feature?
• Is this a evolutionary or ‘revolutionary’?
• Does this seem to be a dead-end or a beachhead?

Short list your paths

Start to think about how you are going to spend your summer.

• How much time do you have?
• What are your ‘minimum’ required things? Not what could you do, what must you do?
• What would you enjoy trying most?
• Do you have any specific skills, connections or experience that give you an advantage?

Avoid the pitfalls

Keep a few things in mind.

• New developer focused features are often really buggy to start with and your customers won’t care.
• It likely need to be ready by September 1. So be careful how much you bite off. (It was Sept 10 for iOS 7).
• Try to focus on what is going to cool in iOS 8, tackling lots of problems that aren’t specific to it might not make much sense.

And most of all, have fun!

• #128: WWDC Tips and Etiquette.
• #53: Please, be polite at WWDC.

Today I’m going to talk through a bit of my thoughts heading into WWDC. If the last episode bummed you out a bit this will hopefully put a more positive spin onto things.

I also talk a bit about what I’m expecting/hoping to see announced next week.

I will be in San Francisco next week and hope you meet many of you there.

Anxiety and Inertia

I’ll be taking a quick break from the Unconventional Wisdom series today. I want to ruminate a bit on something more topical for my personally.

Feed Wrangler hit its one year anniversary this past week. That accomplishment in and of itself is rather significant for me. If you have been listening to this podcast over the last year you know the trials and triumphs getting to here has involved. I wrote up my thoughts about that here if you are interested.

The actual topic I want to discuss though isn’t directly related to Feed Wrangler. It has to do with the anxiety of sustaining a business. I’ve been making my primary living from the App Store for just shy of five years now. In that time I’ve seen it morph and change dramatically. The manner in which I have been able to make a living has necessarily required several adjustments along the way. One thing that has remained constant is the lurking sense of anxiety that tomorrow everything will fall apart and my business will fail. I’ve had that lingering fear now for five years running. From talking to other iOS developers I know I’m not alone in it.

As a brief aside the funny thing about being independent is that this anxiety feels much more real than it does working for a larger company but I doubt if it is actually as dramatically more likely as it feels. Because there is a direct connection between your work and your success everything gets magnified. But I suspect you are roughly as likely to get laid off as you are for your business to fail.

I’ve had to learn to deal with this fear in order to stay sane and to take the risks necessary to grow my business. It hasn’t gone away but it has become manageable, if not useful, for me.

The key I found was to rely on what I will now pompously refer to as “Underscore’s First Law of Business Dynamics”

On any given timeframe, the rate your business will decay roughly matches the rate it grew.

Put another way fast up, fast down — slow up, slow down.

I’ve seen this in my own apps time and time again. I’ll have big spikes followed by big falls, but over the long term things decay much more slowly. I’ve rarely been hit by sudden dramatic fall offs in sales unless they were preceded by big spikes. They haven’t always been at the level I’d like but even when an app falls down to just a few sales a day…it tends to stay consistent there.

This gives me some comfort. When I look at my business today I can roughly predict how it will do by looking at the past few months. The trends over the long term might not always work out but the need for day to day worry is likely unfounded.

I am doing another run of t-shirts for the show. After I did the campaign for them last fall I heard from a lot of people that they missed out. This year I’m giving the campaign a nice long run (through April 28). The shirt design this year combines three distinctly geeky things—underscores, square brackets and fixed width fonts.

Shirts are $14.59 (never longer than 15 minutes). Get one at http://teespring.com/developing. My thanks for the dozens of people who have already got one.

Unconventional Wisdom

I’m doing a series of episodes trying to take contrarian positions against conventional wisdom in software development. My goal is to challenge the assumptions we make and help us to think more critically about how we conduct our business.

The result is something that isn’t 100% my actual position on things but should be productive and hopefully thought provoking nevertheless. I’ll be making sweeping, un-nuanced statements for effect. As with everything in life, it is more complicated than I’m going to present it. The interesting part of being in business is navigating that nuance for yourself.

The second topic is customer support.

Providing good customer support is important?

I can’t count the number of times I have heard “the thing we pride ourselves in is our customer support” at conferences. I have so often heard people getting up and talking about how they love interacting with their customers. How this has driven their companies forward. How it is the responsible thing to do as a software engineer. I couldn’t disagree more.

The needs of the many

To start off my attack on the important of good customer support I’m going to start off by invoking Spock—which should likely settle the matter. The needs of the many out weigh the needs of the few. That in a nutshell is the core of the problem with providing good customer support. Every business (except perhaps VC based shops) are always operating in an environment of scarcity. You are forced to make hard decisions about how you spend your time and money. Within that context any time and energy that you are putting into customer support is necessarily taking time away from energy that you could be putting into making your product better. Helping customers individually is terribly inefficient. Hopefully your product has a large enough audience that any one person is a vanishingly small percentage of your overall customer base. Would you rather spend a few hours definitely making 99.99999% of your customer’s experience better or making it possibly better for the 0.00001%?

Relentlessly focusing on making the product better and better also has the effect of reducing the need for one-on-one customer support.

Horrible, unscalable hourly rate

If your product is available in the iOS app store the revenue you receive per customer is likely pretty small. You are likely getting somewhere between $0.70 and $2.10 per user (at best). If you spend 15 minutes helping a customer out you are looking at an hourly rate of $2.80 - $8.40/hr. You’d be better off burning coffee and mispronouncing names at Starbucks. Also, how can you scale up your product with that type of cost. If you want to provide customer support for increasingly more and more customers you’ll need to hire someone to help. You are then either paying them minimum wage or taking a loss with each request.

Worst customers

Not to pass a judgment on the actual people using your software but the people who require your support are also necessarily your worst customers. The best customers for your business are ones who give you money then cost you the least. These are the customers you want. You want to make life as good for these people as possible. They are going to be the reason your business is able to be sustainable. To apply the 80/20 rule you want to optimize and focus on the experience of the productive 80%, not the counter productive 20%.

You don’t need it

I’m often struck by how most of the wildly successful apps in the App Store provide no customer support whatsoever. I’m thinking of games. You hardly ever see a game with a ‘Contact Us’ button in it. They just build a solid app, deploy it to the market and then reap the benefits of their labors. “But productivity software is different,” you say. Is it, or are we just lazily relying on customer support to fill in the holes we allow to grow in our products? In many ways the need to provide customer support is a symptom of a problem in our products. The need to provide extensive support or help to our customers necessarily means we have missed something in our development process. Maybe we should just put more effort in getting it right the first time.

I am doing another run of t-shirts for the show. After I did the campaign for them last fall I heard from a lot of people that they missed out. This year I’m giving the campaign a nice long run (through April 28). The shirt design this year combines three distinctly geeky things—underscores, square brackets and fixed width fonts.

Shirts are $14.59 (never longer than 15 minutes). Get one at http://teespring.com/developing .

Wrapping up

I have published the consolidated, summarized article for my Towards a Better App Store series.

Unconventional Wisdom

Today I thought it might be fun to start another series of episodes. I like doing series because then I don’t have to think so much about my topic each week. The concept I’m starting with is modeled a bit after debate exercise where you are given a topic or statement then told to take either the pro or against position. The process of having to defend either side of an argument often helps to think in ways you wouldn’t otherwise. Along those lines I’m going to try and take the intentionally contrarian position against ‘conventional wisdom’ in the software business.

The result is something that isn’t 100% my actual position on things but should be productive and hopefully thought provoking nevertheless. I’ll be making sweeping, un-nuanced statements for effect. As with everything in life, it is more complicated than I’m going to present it. The interesting part of being in business is navigating that nuance for yourself.

The first topic I’m going to attack is pricing.

Paid software is good for customers and developers?

When I first got into the software business nearly 6 years ago the prevailing ‘best practice’ for software sales was to charge a reasonable up front price for your product. Then provide minor update and bug-fix update patches for free. Then charge (with upgrade pricing) for each major update to the product. This model had worked pretty well for many years and had grown up in the era of boxed software. More importantly this system had been widely accepted by customers as reasonable and appropriate.

It is, however, an awful way to sell software. For, at least, 3 reason.

Barrier to entry

Software typically has an extremely low marginal cost. Unless you are hosting media for your customers you can typically add one more customer to your user-base for a tiny cost. Even with things like customer support you each additional user is essentially free. As such charging a large up front amount for your software doesn’t make sense. This pricing model could only be maintained in an uncompetitive marketplace. Otherwise, you will quickly be undercut by someone else who is willing to lower their prices, to get them closer to their marginal costs.

You are also scaring away potential customers. Often the hardest part of selling software is getting it known to potential customers. If you finally have a customer considering your product (after whatever long, drawn out marketing effort) and then you put up a barrier to them then actually getting it you are shooting yourself in the foot. That is likely your only chance to convince them to download it, make that process as easy as possible.

Unsustainable

The paid software model is fundamentally unsustainable. To most clearly demonstrate this imagine a world where your paid sales are going well, you’ve built up a reasonable customer-base of happy users and then suddenly your sales drop off. The reason for the drop off isn’t particularly important. You now find yourself in an extremely awkward position. You continue to have expenses and have made commitments for minor updates to your customers but have no income to back them up. You either need to start squeezing your existing users progressively harder for additional income or go out of business.

The fundamental flaw in this model was that each purchase was necessarily short-lived. You had no plan to make a continuous income from your product. Each day you need to find more people to buy your software. A process that will be progressively harder and more expensive to do. You’ve spent all the good-will of your customers all once.

Imagine instead a business model that is based on subscriptions or advertising. This is far better. Now your viability as a business is directly based on how used your software actually is! Should your application fall out of favor and your customers stop using it, then fine, your income drops but nobody has any commitments that you are then not following through on if you cease development. If it is wildly successful then you have a virtuous cycle of more revenue for more development.

Horribly Abrupt

The nature of the paid model is to get large bundles of income along with significant updates. Your sales will often then fall down dramatically thereafter. This means that you are essentially in a feast-and-famine cycle. You need to store up and be frugal enough with the days of plenty to survive through the days of want. I can say from experience this is horrifically stressful. As you chip away at your storehouse your level of comfort will dramatically reduce. While conceptually you could say that it is functionally identical to getting the same overall amount evenly over the same period, human nature says otherwise. There are few things as comforting as a dependable, consistent income. Something paid apps simply don’t provide.

Improving the App Store: Part 5

Ratings

The star rating of an application is the most important aspects of the sale experience that is outside of the developer’s direct control. It is displayed on every page and instance where your app is shown and gives the customer a general cue about the quality of your app. As such developers tend to take whatever actions they can to increase it. If this were just a question of improving the quality of their apps that would be fine but that isn’t where most developers stop off. Not to reopen the tempest about prompt dialogs, but there are a lot of potentially dubious and tricky things developers can do to try and ‘artificially’ boost their ratings. There are also some really solid, thoughtful ways to accomplish the same goal.

My general recommendations about ways this could be improved.

• Define a clear policy about where, how, and when applications may prompt for reviews.

Much of the discussion around the dialog prompts stemmed from a feeling that ‘everyone was doing it’ so ‘I need to too’. The best way to reward earnest developers who are trying to optimize for their users’ experience is to level the playing field by establishing exactly what is permitted.

• Make the rating scale a rolling, weighted average rather than just current, at least soon after updates.

I remember when Apple changed the review score from a global average to only the current version. This was an attempt to make sure that a single buggy version didn’t forever hang around your neck. It also makes the reviews perhaps more reflective of the experience the customer should expect. The challenge though is that immediately after submitting your update your reviews all go to zero which gives the customer a very different perspective about your app. It makes it look unused or low quality. This discourages updates and encourages annoying your users with review prompts immediately after updates. Either show the overall average or a rolling, weighted average, even if only recently after update.

Editorial

While the role and scope of editorial (feature) coverage of the store has been steadily improving over the years I think there is still a massive amount of room to be done here. Apart from the top lists, the featured area is probably the most visible place your app can be found. Building an app with the goal of being featured incentivizes quality, thoughtful and relevant app creation. Which is great but means that the value of being featured should be less abrupt.

• Expand the scope and frequency of editorial coverage in the Store

It seems very odd that features are only ever updated once a week (typically thursday afternoon). New apps are added to the store constantly, updates are submitted constantly, it seems like features should be updated accordingly. I’d love to see things like ‘daily picks’/promotions or similar. Things that could potentially drive user engagement with the App Store app, checking in on what is new and interesting.

• Make an app’s featured status visible after their initial feature

If an app is featured I’d love to see some kind of badge or notation on its App Store page promoting its selection. Apple has already taken the time and effort to identify apps that are worth the user’s attention, why not communicate that to user’s on the actual product page for the app. Similarly I’d love to see the curated lists that Apple puts together show up as search results. For example, if you search for ‘accounting’ the featured list for “Managing your Money” would seem like a great place to present the user with some apps that might be worth initially considering. This has the added benefit of improving the quality of search results.

Categories

• Expand the diversity of categories associated with each app.

Lastly I’d love to see the variety and specificity of categories you could assign to an app be expanded. The current metadata assignment into one of only 24 categories seems paltry when trying to catalog over a million individual apps. I’m sure based on the search data that Apple has at its disposal I’m sure they could subdivide of the existing categories into several useful sub-categories (much like how games are treated). This would also help improve the relevance of the top charts. Being the top app in a more niche sub-category might be genuinely useful for developers and customers alike.

This concludes this series on the App Store.

Then I talk through some of the tradeoffs involved in choosing the level of abstraction to use for your web-service backends, explaining my own tendency to go pretty low level. Starting from these few posts:

• The Parts of Your Platform
• Web Hosting For App Developers
• On Running Your Own Servers, and Why We’re Not

Make the App Store Refund policy more obvious

I really don’t understand why Apple makes the refund process so opaque and awkward. I know from my own experience in physical stores that a clear and easy refund policy helps drive sales. It is far better than a ‘trial-mode’ because it sustains the value of the app (rather than giving it away for free then asking for money later). However, it still maintains that escape hatch for purchases unsure of whether they really want the app.

I’d love two things, neither of which are actually policy changes.

• Educate App Store customers about what the policy is and ideally phrase it in clear terms.

I’m sure there is an internal policy within Apple customer support, but I haven’t been able to find a clear explanation of it. The legalese Terms and Conditions for the App Store states that “All sales and rentals of products are final” but that is clearly not the actual policy since people get refunds all the time. Whatever the policy is this should be clear the customers.

• Make the process of applying for a refund clear and straightforward.

Right now you go to reportaproblem.apple.com and then fill in a form. I’d love to see this integrated into the App Store app itself. Perhaps even into the Purchased Apps area.

Make in-app purchases (especially consumable) more honest

Building on a blog post I wrote last year I would love to see the App Store better inform its customers about how in-app purchases will affect their experience of an app.

• Present a typical overall cost for an app in the App Store description

Make it clear that when you are downloading an app that says ‘free’ next to it that you may not actually be making the less expensive choice. Also, provides a clear expectation about the type of app the user is about to interact with.

• Show how much you have spent on the app with each new purchase.

Be upfront with the user about how much money they have spent. Allowing them to make a more informed (and less manipulated) decision.

Drop or reframe the Top Grossing Chart

The Top Grossing chart was ostensibly added to help improve the visibility of higher paid apps within the store, at least that is how it appeared to me externally. If that is the goal it entirely fails to do that. Either drop the list or perhaps change it to only include paid apps, or at least exclude consumable in-app purchases from the ‘app revenue’ number.

Continuing my series of Towards a Better App Store, trying to find practical suggestions for how we could improve the App Store. Today I’m going to focus on Search.

• Physical Design: Make the cards interface for search optional (if not eliminated).
• Ranking: Rewards or punish applications based on objective measures. For example, recently updated, crash frequency, refund requests, reviews, etc.
• Curation: While still algorithmically based periodically vet the most popular keywords to ensure good relevance.
• Power Search: Add the ability to filter and manage search results to more finely tune the results.

Make it up in Volume

This is Part 2 of an ongoing series trying to explore practical ways that the App Store could be better for customers. Today I’m going to talk about the Store’s size.

The size of the App Store’s catalog is often thrown around as a valuable, useful metric for judging the heath and vitality of the ecosystem. That may have been true before a certain scale. There is value in having a diverse and deep inventory that mets every need but beyond a certain point it completely looses relevance. Duplication, ‘spamming’ and decay of older apps hurts the store more than helps it. In many ways the incredible volume of the Store is at the core of many of the other challenges it faces. App Review takes longer than developers would like. Search becomes tricky. Editorially curating new arrivals becomes daunting.

It isn’t an easy problem to solve. How do you determine which apps should be allowed in which should not. Just how many Flappy clones should be allowed to exist in the Store? 5, 10, 1000? It isn’t just the overall size that is a problem though, the rate of increase is also increasing.

This is only new apps approved on the store (taken from 148Apps), add to this updates and it is an incredible volume.

Also, how many of the apps on the App Store are being actively maintained. I’d guess the number is pretty low but the old apps still stay there. Buoying the numbers but not actually providing good value to

Aside on Apple

For this whole series I’m going to assume that tackling the questions of making the App Store better aren’t constrained by budget nor desire. I’m going to assume that somewhere in Apple’s Profit & Loss they can find whatever resources they need to attack these challenges. Furthermore, I’m going to assume that they have a desire to make the App Store as customer friendly a place as possible. Both of these seem like reasonable things to assume but I feel I should put that out there before I begin.

Recommendations

I had initially gone down the road of trying to work out ways to make judgments about which apps are the ‘good’ ones and which ‘deserved’ to be in the Store. It very quickly became clear that this was nearly impossible to do. While I (personally) can look at apps on the store and say they don’t belong, based on my own tastes. This never generalized. The App Store would be worse off if it were filtered with too harsh an opinion. I had also thought of applying other external limits on the number of apps. Things like raising the cost per submission or number of new apps per developer per year. These would only really affect the current trend of re-skinned apps (which can be better addressed directly), I’d rather have things simple for the majority than punish everyone for a few bad apples.

I’m reminded of a parenting adage. Have few rules but strictly enforce them. I think this would do much to improve the situation on the Store. The App Review Guidelines are a pretty solid set of rules. They have evolved and adapted to the times but overall they do a pretty good job of keeping out the stuff that is objectively ‘junk’. There are of course grey areas, as there should be, but I don’t have too many complaints with the guidelines we have today. The area that I think we could do much better on is the way in which they are enforced. Specifically, when they are enforced. As best I can tell, other than in exceptional cases once an app is approved it is always approved.

#1: Apps should be required to pass approval on an ongoing basis.

The purpose of the having app review and rules about what constitutes an acceptable app is to form and direct the content of the store in the customer’s favor. This applies to things like avoiding crashing, malware ridden software. It equally applies to establishing a baseline of design and development standards that everyone must meet. Having things like the Human Interface Guidelines (HIG) as a requirement for submissions establishes a bare minimum for quality for all apps. However, the App Store is a vibrant, ever moving ecosystem. What was acceptable a few years ago is likely not today, at least not without any adaptations. This applies most concretely to supporting new versions of iOS. Since February 1st all new submissions just be built against the latest SDK and be “optimized for iOS 7”. If that applies on the front end, it should be reapplied to the back-catalog as well.

Exactly how this would be applied doesn’t really matter. It could be applied on a monthly, quarterly or (honestly) even annual basis. The important thing is that it would create a Store where any app a customer purchases would be assured of meeting and complying with the current set of guidelines. The stated goal of the Guidelines is to “ensure they are reliable, perform as expected, and are free of offensive material.” I believe every app on the store should meet those criteria.

If older apps no longer meet the stated guidelines for what an app should be they should be de-listed (still available to re-download if already purchased). Leaving space on the virtual shelves for apps that provide the best possible experience for customers. This would constitute a lot of work for the App Review team, but I think it is hard to argue that the result wouldn’t be worth it for customers.

A note on Show Notes. I’m planning to continue the long form notes for now, but realize that they are only a taste of what is discussed in the show and not a transcript.

The Goal

It is perhaps a bit glib to assume that the App Store is in need of fixing. It is perhaps the most success software marketplace in history. It has facilitated the download of over 60 billion applications. It removed a tremendous amount of friction and hassle with software distribution. It has allowed the creation of a new way for customers to think about software.

But I think it can be better. I have genuine, personal affection for the App Store. It has allowed me personally to do things I never thought possible. But (to quote myself):

I want to believe that the App Store is a special place. I want for it to be the singularly best venue for customers to come and find innovative, well designed, quality software. Software that pushes the boundaries of what is possible and continually amazes and delights its customers. I want for there to be an aspirational pull upwards on my own development. I want to feel like I need to work extra hard to make sure my apps meet the high standards my customers have been trained to expect.

I don’t think the App Store lives up to these projected goals, but I think it could.

When trying to think of the areas and ways in which the App Store could be improved it is likely not productive to think from a developer’s point of view. In all cases for the App Store to be successful it needs to be customer oriented. I need a target towards which to aim. With this in mind I started out with the goal making an app store that:

That need could be specific (I need to listen to a podcast) or general (I’m bored, What fun apps have come out recently). In either case the goal of the App Store should be to help customers find a robust, quality app in as few taps as possible. Stated in the converse it would minimize customer confusion, disappointment and regret.

Generally speaking this will also help out developers. Many discussions of what would make the App Store better tend to focus around a theoretical divide between “Good” developers and “Bad” developers. I know I myself have fallen into this stereotyping, but it is unlikely to be productive when considering a broader context. There are some behaviors that we can likely all agree are undesirable (copyright infringement, deceptive marketing, etc) but beyond that it is constructive to start with an assumption that all apps enter the store equal and are differentiated based on the market itself not our own notions.

The Problems

Over the next few weeks I plan to unpack ways this could improve in the following areas:

• Catalog Size
• Business Models
• Search
• Ratings
• Editorial
• Categories
• Top Charts

The Hate

Things like Twitter and the short attention span culture that grows up around it have developed a mentality where it seems perfectly acceptable to tear apart other people or their work. Over the weekend I was disheartened to see so many people I know and admire passing judgement on someone they didn’t know based on 140 character messages. Guessing the motives of anyone other than your closest friends is a fools errand, and even for them it is usually a terrible idea (just ask my friends). People are complicated, fragile and valuable. Projecting into someone else’s situation and then passing degrees on how they respond isn’t nearly as productive as projecting yourself into their situation and trying to learn for yourself.

Words have meaning and I see no clearer example of how powerful they can be than what happened to Dong Nguyen. I genuinely hope he is able to move on from this in a positive way.

Jeff Vogel’s take on this is worth a read. He comes from a background where he has had to deal with this type of interaction. While he has a variety of good points I found his observations about the role PR companies play in business very germane to this audience. The blessing and curse of being an independent is that you often interact directly with your customers. It is impossible for this to not impact you personally and emotionally. Human nature is to dwell on the negative far more than the positive. If you aren’t careful about drawing boundaries you’ll go crazy.

A lesson

There are a number of more squishy lessons to learn from Flappy Bird, but there is one that is manifestly practical. Never, ever, ever share revenue numbers publicly. As soon as you throw a number out there it will be all anyone can talk about. This is a natural reaction since it is one of the only things about your unique situation that is directly comparable to theirs. That voyeuristic tendency is highly venomous. Every single article I’ve read since has thrown that number around as a core part of their justifications. Just don’t do it. While I know it can be frustrating to see y-axis without numbers or to want to learn from the experiences of others it is never a great idea, and this coming from someone who tries very hard to share my numbers, stats and results.

Localization Results

I published a breakdown of the impact of localizing Pedometer++. Overall it was a great success.

A request

I’ve never really asked for iTunes reviews, it isn’t something I think is particularly important nor something I like doing. However, the quantitative side of me really wonders if it is as important as various podcast hosts say. So I’d like to conduct a little experiment. If you have time over the next week I’d love for you to write or rate the show in iTunes. You can find it here. I’m skeptical but very curious about what an influx of reviews would do. Thank you.

I’m not going to wade into the specifics of the Paper-on-Paper-on-Paper-on-Paper battle but I thought it was an interesting topic to address more generally. Naming is an important part of creating, launching and marketing a product. Along with your icon it is probably the single most significant part of your branding efforts. It is what people will search for and how they will tell others about your app. Here are some of the things I’ve learned from my tenure in the App Store.

Remember folks, I’m not a lawyer. Don’t base your legal or branding choices solely on the recommendation of a 15 minute podcast.

Considerations when choosing a name

There are two general groups that your app’s name can fall into:

• A unique, contrived or invented word. Some examples of this category are Groupon, YouTube, Snapchat and Pinterest. The advantage of these is that they are typically easier to defend and protect. Because you made up a word it is hard for people to claim collisions are coincidence.
• A more generic term. Some examples of this category are Audiobooks, Paper, Flashlight and Camera. The advantage of these is that they are easily recognizable and have built in search optimization. However, they are much trickier to defend and lay claim to.

Some App Store Realities

• Name “squatting” is a reality of the Store. While Apple has a variety of policies in place to attempt to mitigate this it is easy for someone to lay claim to a name in the Store without really using it to sell an actual product.
• As of today there have been 1,509,669 apps approved in the life of the App Store. With that large of a pool it is very likely that all the basic, short names have already been used for most common nouns and verbs (The Oxford English Dictionary only has around 250,000 words for comparison).
• Name duplication is possible through a variety of means. I used to think that once a name was “claimed” it was no longer possible for another app to have the exact same name. This isn’t true. Whether by guile or glitch I’ve seen many instances where a name has been duplicated exactly.
• Beyond direct duplication you can also indirectly duplicate an app by adding text or characters to the end of the name. Just do a search for “Flashlight” in the App Store to see what this looks like. This is often also done to improve search ranking in the Store.
• Search optimization is an important part of getting your app in front of your customers. Your app’s name (whether just a name or name-plus-tagline) and keywords are the only texts used in search so what you choose for this is very important. This is another area where being more generic can be useful. Naming your app Camera+, Camera Awesome, or Camera Plus gives you immediate advantage for people going to the store and searching for “camera” apps.

Higher Powers

• Trademarks are the legal means of protecting your name and preventing customer confusion. Not everything can be trademarked, nor does getting a trademark solve all your problems.
• As with most things involving lawyers it is only partially a question of who is “right” in a trademark dispute. It is who can fight the longest, best fight and convince the highest power to take their side. I know of many stories of “little guys” getting trampled by someone who had the budget mount legal battles that the rightful owner just couldn’t sustain.
• Apple generally seems to have a two tier approach to disputes. When it is a clear violation of an valid, simple trademark they are very quick to act. When things start to get more gray and complicated they step back and let the parties work it out between themselves. I think this approach makes a lot of sense and while it can be frustrating if you are fighting the later case its really the most reasonable approach for them to take.

General recommendations

The easiest way to avoid his whole thing is to try and name your apps in as unique a manner as possible. Invent a name and then market around that. You can incorporate parts of the generic terms to make it more recognizable (e.g. Fantastical). You loose the native search optimization of this but can easily make up for that using your keywords.

Trademark your name and hope for the best, realizing that whatever you do you may need to get a lawyer involved at some point.

• Previous Episode on Localization
• WWDC Video about Localization
• Apple Developer Overview
• My Cheat Sheet for looking up Languages
• iTunes Connect Transporter
• Tethras, the service I use

I’ll be speaking at NSNorth in Ottawa, Canada. The conference runs from May 8-10.

Today my main topic is about distinctiveness. Stemming from my experience with copy-cat apps of Pedometer++.

• Invest in fewer but more personal relationships.
• Avoid controversies.
• Slow Down, stabilize on quality before moving forward.
• Try to be less cynical. Read my App Store reviews. Listen to all my customers.

The video I mentioned in the intro.

• App Store Distribution and Marketing for Apps

• Decisions and Tensions

I’ll be speaking at two conferences next spring.

• NSConf
• CocoaConf

Five Years in the App Store

• The Prompt: The Mind of the Underscore
• Pedometer++

Please excuse my audio quality. I only have a single proper microphone, so I had her record with that while I used a USB headset.

• We start off talking about some implications of Realmac’s decision to backpedal on the pricing structure for Clear. How the decision to offer a paid, separate upgrade creates a situation where customers are apt to seek out other alternatives. The dynamics of this seem to play out differently than doing an in-app upgrade.
• The fear of wasting money in purchasing apps and how that can often drive people towards free apps simply because the apparent risks are so much lower. One of the implications of this fear or hesitation is that purchases made within an app are much less daunting than purchases directly from the App Store.
• How social proof and personal recommendations can drive purchases in a way that less personal marketing never does.
• The misconception that the App Store is stocked by Apple directly rather than by independent 3rd Party apps. This sets up unrealistic expectations with customers about what is sustainable and reasonable to expect from developers. How Apple’s decision to make the iWork suite free feeds into this perception with customers that Apps should come free with their devices with infinite free updates.
• The role that good customer service can provide to personalize and humanize your relationship with customers. This can serve as a great avenue both for their continued support and to help give them a realistic set of expectations.

• Pod Wrangler
• iOS Version Stats

• Changing a Car Tire while Driving

• Developing Perspective t-shirt
• The Inspirational Mug
• Grain of Salt Origin

• Developing Perspective T-shirt
• HockeyApp
• TestFlight

• #72: Mistakes, Designing Icons and getting Acquired.
• iTunes Connect Developer Guide
• iTunes Affiliate Linking

• Dev Portal Status
• Honest In-App Purchases
• Çingleton Symposium 3

• FMDB
• Base

Discussing a few principles of solid design that apply very strongly to iOS 7. Contrast, Repetition, Alignment & Proximity. Taken from The Non-Designer’s Design Book (3rd Edition).

• First Episode of Developing Perspective, 2 years ago

• iOS 7 Redesigns

• Pinboard Article

General Tips

• Casey’s WWDC Tips
• Jeff LaMarche First Timer’s Guide
• Pick up your badge Sunday
• Have questions prepared for the Labs
• Don’t feel like you have to do something in every slot, take care of yourself

Etiquette Soapbox

AKA: Please, don’t be a jerk at WWDC.

• Be thankful to the Apple engineers and employees
• Be considerate of others and your presenter during sessions
• Make sure all your technology is on Silent (not vibrate)
• Please, don’t noisily pack up your stuff and leave before the presenter actually concludes.  Wait until they are done!
• Pick up your trash
• Be polite in line and don’t hold spaces for unreasonable numbers of people
• Be aware and respectful of people’s time and attention
• Don’t be a pushy salesman for your apps

• Feed Wrangler
• Briefs

• WWDC Tickets
• WWDC Apple Design Awards
• WWDC Student Scholarships

• Napkin App
• ADN Invite Link

• Apple Walkthrough

• Linode’s New Memory Blog Post

• Ash Furrow’s Your First iOS App project

More details and a sign-up for getting notified when it launches here:

• FeedWrangler.net
• My blog post about Feed Wrangler

• RailsCasts
• Recipes for provisioning servers
• Linode (affiliate link)

• My website, David-Smith.org

• App.Net’s Free Tier
• The Realities of App.net App Pricing

• Marco.org
• Marco on Twitter
• Marco on App.Net
• Instapaper
• The Magazine
• TextMate 2 Beta
• Soulver

• Interview with Brent Simmons
• My Article about Negotiating

• Inessential, Brent’s Blog
• Identical Cousins, Brent’s Podcast
• Azure
• Heroku
• Linode
• xScope
• Skala Preview
• Kaleidoscope
• Glassboard
• Lighthouse
• BitBucket

• Identical Cousins
• Gone Indie

I’ll be in San Francisco coincident with MacWorld this year. If you want to meet up please get in touch.

• Chair - Embody
• Keyboard - Microsoft Natural
• Mouse - Razer Deathadder (Wired)
• Mouse Pad - SteelSeries 4HD

• Seven Deadly Sins of Modern Objective-C
• Coders in the Hands of an Angry God
• UITableViewCell Is Not a Controller

• nshipster
• Mattt Thompson on github
• Objective-C on github
• Mike Ash
• Peter Steinberger

• Google Apps
• TextExpander

• Dragonforce

• Pro Git

• Malcom Gladwell at TED

• Check the Weather

• The Magazine

• TestFlight
• User Friendly Promo Codes

• Linguan

App Localization Services:

• Tethras - My chosen provider. I went with them because they seemed to have a good balance between cost and quality. I wasn’t disappointed.
• AppLingua
• Wordcrafts
• iCanLocalize

• Smart App Banners

• iOS Version Stats

• CocoaPods

• Apple’s Unsolicited Idea Submission Policy

• Rob Rhyne on Twitter
• Rob’s Blog
• MartianCraft
• Invincible - transitional music
• Epic Soundtracks on Pandora
• xScope
• Favorite Mailboxes by Matt Gemmell
• Acorn
• The Design of Everyday Things
• Mike Rundle
• Matt Gemmell
• Sticky Notifications

• New My Recipe Book icon
• Iconfactory

• Bill Dudney on Twitter
• Bill Dudney’s Blog
• iOS Programming Course with The Pragmatic Studio
• iOS SDK Development by Chris Adamson and Bill Dudney
• TextMate
• OmniGraffle
• Pro Git
• Tower - Git Client
• Learn to Program by Chris Pine
• Programming in Objective-C by Stephen Kochan
• LEGO Mindstorms
• Sinclair Spectrum

• Build and Analyze #90: This Person Isn’t Really Here
• Ulrik Damm
• Robocat Apps
• App Store Metrics

• Matthew Bischoff on Twitter
• MatthewBischoff.com
• Quotebook
• Pair Programming
• Tomorrow Theme
• Advanced Appearance Customization on iOS - WWDC Video
• Code Complete

• #58: Managing new SDKs
• The Path to Success in the App Store
• AppAnnie
• App Figures

Some People to Follow:

• Ian Marsh
• David Barnard
• Eli Hodapp
• Phill Ryu
• Blake Patterson
• Marco Arment
• Paul Haddad
• Steve Streza
• Federico Viticci

My first impressions of the Retina MacBook Pro and how I used the Apple Business Team to get it.

• Survey
• Edge Cases
• Episode 64

Question via @nalenb.

• Edge Cases
• Popular Names

• Show 63
• Simperium
• Parse

• iOS and Mac Podcasts
• Plain Wallpapers
• Cheddar API

Question from Paul Dunahoo.

Question via @EricWelander

Question via Mason.

Links:

• Octopress
• Podcasts App
• WWDC Videos
• Retina MacBook Pro

Question via @nalenb

#29: Working in an Office

• The Value of a Handshake - Shawn Blanc

• Be thankful to the Apple engineers and employees
• Be considerate of others and your presenter during sessions
• Make sure all your technology is on Silent (not vibrate)
• Please, don’t noisily pack up your stuff and leave before the presenter concludes.  Wait until they are done.
• Pick up your trash
• Be polite in line and don’t hold spaces for unreasonable numbers of people
• Don’t be a pushy salesman for your apps
• Don’t overdo it.  Have Fun.  Pace yourself.

• Geekbench Scores

• Instapaper for Android
• Show 5 and Show 0.8

A discussion of the process of an app being featured in the App Store.

• 5by5 | The Talk Show #56: That Day Has Come
• Thanks @gruber and @danbenjamin

Dan’s response to The Talk Show leaving: http://5by5.tv/specials/6

John’s new show, The Talk Show: link

Dan’s new show, Big Week: link

• itcStatus
• Majic Rank
• Audiobooks

• Back to Work #23: Failure is ALWAYS an Option
• Marco.org: iOS 5.1.1 upgrade stats
• My very first Episode: Show 0.1
• My Blog: david-smith.org
• 5by5 Radio iOS App
• FiveLive: Mac Live Listening App

Links:

• SimpleCasts
• User Friendly iTunes Affiliate Links

• Things you should never do

• A lathe in use

• Audiobooks

• My Audiobooks app

• Build and Analyze: #75 My Twitterrific Moment

Recorded just prior to the announcement on March 7th.

• HashContacts: an iOS Address Book Wrapper

• OS X Mountain Lion

• Clear

Developing Perspective is a podcast discussing news of note in iOS, Apple and the like.

Never longer than 15 minutes.

• Linode
• Engine Yard

• Build and Analyze: #6: Cycles of Motivation

• Temple Run
• Indiana Jones: Raiders of the Lost Ark

• Regus

The App Store Christmas Bump

User Friendly iTunes Affiliate Links

• Git Is Simpler Than You Think

• A better introduction to Objective-C

• How to clean Apple products

• Developing in secret.

• On Wednesday, Amazon Will Unveil The “Kindle Fire” | TechCrunch

• P versus NP

• ~/.osx — a collection of sensible defaults for OS X Lion

• Twenty-Five Pieces of Basic Sartorial Knowledge So You Don’t Look Dumb

• Bootstrapping a $30k profit/month company from our internship earnings

• Staying focused.

• Eight Traits of Great Metro Apps

• Lessons from Valve – How to build a designer’s paradise

• What’s Your Start-up’s “Bus Count”? 7 Myths of Entrepreneurship and Programming

• The London Tube Map, Redesigned For A Multiscreen World

• Pomodoro Technique Illustrated - by Staffan Nöteberg

• The new iPhone

• GOLD3N RATIO

• Six Stages of Debugging

• xdissent/ievms - GitHub

• Amazon’s Kindle Tablet Is Very Real. I’ve Seen It, Played With It. | TechCrunch

• After the launch

• 148Apps.biz | Apple iTunes App Store Metrics, Statistics and Numbers for iPhone Apps

• Linode Reduces Transfer Pricing (Incoming Data is now Free)

• Texture Tutorial on Vimeo

• The Price of (Dev) Happiness: Part Two

• Submitting to the App Store

• iTunes Connect

• Why Markdown? A two-minute explanation

• Spotify inside your iOS app

• GitHub Flow

• How Steve Jobs handles trolls (WWDC 1997)

• 5% off everything.

• Avoiding Parkinson’s Law

• Parkinson’s Law

• Learn Vim Progressively

• XPCKit

• Importing and displaying large data sets in Core Data

• A simple way to create custom Rounded Rect Buttons

• The Apple Logo

• Getting setup for submitting an app

• Developer Portal

• A Tribute to Steve: 21KM Apple Logo

• Objective-C - GitHub

• What’s New for Developers in Mac OS X Lion (Part 3)

• Exporting from Photoshop

• How I learn new languages.

• The Pragmatic Studio | Top Developer Training

• thoughtbot playbook

• What’s New for Developers in Mac OS X Lion (Part 2)

• Rob “CmdrTaco” Malda Resigns From Slashdot

• How we found the file that was used to Hack RSA

• If I Launched a Startup | Startup Lawyer

• My hourly billing system

• Why I prefer fixed price over hourly contracts

• Letter from Steve Jobs

Thoughts on Steve’s transition to Chairman of the Board.

• Plausible Labs » A software… cooperative?

• Creating web apps for iOS

• How to Get $12 Billion of Gold to Venezuela

• ∞ Mac Pro Fast

• How to measure your time

• American Bar Association Guidelines

• Irradiated Software - SizeUp

• github/gitignore at master

• A letter from _why

• Recent / iOS UI Patterns (beta)

• My Setup

• on_the_path_gitflow

• Learn Ruby The Hard Way

• The Macalope Weekly: Gotta know when to hold ‘em, know when to fold ‘em

Importance of Perspective

• Camels and Rubber Duckies

• Polyglot Platform

• Personal Style

• carlbrown/PDKeychainBindingsController

• Less Code, less effort.

• Discussion on taking vacation and rest as an independent.

I’m heading out for vacation until August 22nd.  In the meantime enjoy the archives.

• The Price of (Dev) Happiness: Part One

• Adam Lisagor Is The Quietest Pitchman

• Sandwich Video

• Giving up on giving up TextMate

• Amazon Kindle Cloud Reader

• Kindle Cloud. Almost but not quite.

• My workflow

• Instapaper

• Rode Podcaster

• Audacity

• Transmit

• The Growing User and the Perennial Beginner

• Apple - Recycling Program

• Lion Recovery Disk Assistant

• Automatic Reference Counting for Some Files

• Bash prompt, five examples to set your own

• A discussion of avoiding becoming addicted to digital information and more conscious about your time and attention.

• Lion Adoption

• Agile Week 2011: 40% off

• The Definitive Guide To Forms based Website Authentication

• The Trivialities and Transcendence of Kickstarter

• Talking Stocks

• What does “organic” really mean?

• Getting started and celebrations for my 20th episode

• Back to Work #23: Failure is ALWAYS an Option

• Show TODO’s And FIXME’s As Warnings In Xcode 4 - Deallocated Objects by Jake Marsh

• Network Link Conditioner in Lion » Matt Legend Gemmell

• CodeKata: Code Kata

• Musing on having a ‘lifestyle’ business

• The Blogfather

• Learn Ruby The Hard Way

• Why “Coupon Code” Should Not be a Field on Your Payment Form

• Mac OS X 10.7 Lion Automation Release Notes

• Free icons for any object in the world

• Why wireless networks are slow

• Build and Analyze #36: Jobs (Not The Steve Kind)

• By The Numbers: What Can An OWC 6G SSD Do For Your 2011 Mac mini?

• Meet Comex, The 19-Year-Old iPhone Uber-Hacker Who Keeps Outsmarting Apple

• Tweetbot 1.4.3

• The Making of Drunkify

• The Problem with All-Star Teams

• ★ Google: Patently Absurd

• Handling Interruptions and Focus

• ∞ Digital Interruptions

• Pomodoro Technique Illustrated

• Essential TextMate Shortcuts, Tips and Techniques

• Streamline your git workflow with aliases

• Core i5 MacBook Airs approach perfection Review

• An iOS Developer Takes on Android

• Faceplanting: an app launch horror story with a twist

• Amazon Appstore

• Amazon Free App of the Day

• A Tale of Three App Stores

• Apple - iCloud stores your content and pushes it to your devices.

• Method and Apparatus for Kicking Ass

• Invisible Scrollbars

• iOS and Mac Development Link Roundup: July 2011

• Understanding the Git Workflow

• Backups

• RAID is not Backup

• Marketing Hacks for iOS: How we got 250k downloads in 4 days.

• Making Lion Work Right For Me

• A few days of programming on iOS and Android illustrates a vast difference

• The Future of the Mac After Lion

• What tiny thing in Lion makes you smile or has caught you off guard?

• Discussing tools and their role in successful development

• Enjoyment of one’s tools — The Endeavour

• Articles about the App Store, design and Bjango

• Apple captured two thirds of available mobile phone profits in Q2

• Secrets

• myell0w/MTStatusBarOverlay

• Using 3rd party code in your app

• Is Compilation CPU Bound?

• Invest In Yourself

• Wanted: Technical Writer / Tinkerer

• ∞ How I Evaluate and Decide to Purchase New iOS Apps

• App Store Sales Volatility

• Writing without version 1.1

• mattt/FormatterKit

• Rails Ultimate Install Guide on OS X Lion

• Defining quality

• Read It Later Raises $2.5 Million, Wants To Become The Dropbox Of Content

• Mac Value Analysis

• Pilky.me - The Xcode 4.1 Review

• iOS reading apps begin ditching outside store links in droves

• 1Click Bookmarks | 1Password 3 User Guide

• Text files and me IV - BBEdit and TextMate

• Subtle Patterns

• Free High Resolution Textures

• Founders and Indies

• A robot that flies like a bird

• Mac mini Hosting

• Intellectual Ventures And The War Over Software Patents

• When Patents Atack

• On Succeeding Steve Jobs

• mogenerator 1.23

• Whole Disk Encryption Benchmarks

• iOS 5 Over-the-Air Update