Developing Perspective

Under the Radar RSS Feed Overcast Link iTunes Link PocketCasts Subscribe Link 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

I tend to think of my app business in terms of revenue per day. Breaking it down to that level helps me keep a close eye on it and know how well or poorly I’m doing. Today I walk through the reasoning for this as well as do a thought experiment of what the numbers might look like for a new business.

Some thoughts on the implications of having to take an unplanned absence from your work when you are self-employed. There are a lot of benefits of being independent that manifest themselves in a situation like this but also a few things to be careful of and plan for.

An overview of what to expect this summer: 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

First Impressions from WWDC 2015. These are my initial reactions right after the Keynote, I’ll probably do another episode later in the week which has more considered reactions.

Some high level thoughts about WWDC and my excitement for it. Then, a few thoughts about whether mobile advertising is in a precarious position.

Today I begin a new Start-to-Finish series discussing the creation of an application from idea to the App Store. 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.

Thinking through why I have such a hang up about talking about and asking for Money. Why this is probably not such a great thing for my business and what I might do to fix it. My WatchKit Apps

How to build little features into your applications that re-wire your user’s brains to come to expect a certain behavior. These ‘insidious’ features are a delightful way to help build loyalty with your customers.

Simultaneous Invention or setting realistic expectations for uniqueness. Simultaneous Invention

After a longer than typical break I’m back with another episode…on a related note I’m talking about how to get unstuck. How I manage the situation that seems to happen often enough where I get stuck in a creative rut. Then I talk a bit about how to manage the process of submitting WatchKit apps. Chart of my consistency track record for Developing Perspective:

In the run up to Apple’s media event on March 9th I keep hearing the phrase ‘Gold Rush’ over and over again. Today I unpack that concept and whether it might apply to the Apple Watch. 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.

Prompted by some thinking I did around building the App Preview for Pedometer++, I start to wonder about honesty in advertising. How honesty should I be? What level of candor is appropriate, helpful, reasonable? Building an App Preview

I’m not a huge fan of the term polymath. It sounds kinda pretentious but sometimes the best word for something is that way. Today I was struck by the wild variety of tasks and skills that it takes to run a business principally on your own. So I wanted to walk through some of disparate aspects of the ‘job’. Hopefully giving someone who is considering going out on their own some good food for thought. 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

Today I walk through my history thinking about Swift. From WWDC to now I’ve done a lot of thinking about Swift as whether I should be using it. The result makes me feel a bit conflicted, but the brutally pragmatic part of me is winning out. Swift on Apple.com My WatchKit series

I take a break out of my normal 15 minute format for a return of my occational interview series. This week I’m delighted to talk to Sam Soffes about balancing your own product work with doing consulting, different ways of thinking about success and deciding what it is you want to do with your time. 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.

Rather than wading into the hullabaloo regarding Apple’s software quality directly I instead decided to take a step backwards and consider the forces that have driven us to this situation in the first place. My goal is to consider the forces that make keeping software stable over time difficult. The result can apply to small projects as well as to a company as large as Apple. 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

Today I think out loud about the implications of an App Store that is functionally full. Where applications cannot realistically thrive simply because of novelty or freshness. Whatever you do now you are facing up against a hyper-competitive marketplace. I think this changes significantly how we need to pursue things from a business perspective as well as helps us be realistic about what to expect. 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

Thinking out loud about why I recently starting my series called As I Learn WatchKit. I’ve learned a lot about the creative process by giving myself permission to put unpolished things into the world. 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.

My first reactions to WatchKit. I’m really glad Apple has given is some genuinely powerful capabilities with this first generation of APIs. Getting Started with WatchKit My Initial Impressions Apple’s Main WatchKit page Developer Forums

For a while now I’ve had an episode idea discussing some of the ‘interesting math’ about working on a project by yourself. I discuss how working on something by yourself is so very different than in working on any other sized team.

I’ve had a few folks ask me about my plans and ideas for Apple Watch. While I don’t try to be too coy about what I’m working on I’ve definitely kept some of my ideas close to the vest. I’m well aware that ideas, in general, are useless on their own. But that doesn’t mean that being promiscuous with your ideas is still always a good choice. 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.

With the impending arrival of the AppleWatch next year and the WatchKit SDK next month I’m starting to shift my focus towards ‘wearables’. They present a few challenges to me as a developer, not the least of which is that I have almost no experience with that type of device. I used to wear a watch years ago but haven’t consistently for a long time. I saw the Pebble when it first came out and it looked kinda janky. But now it is clear this is an area that the larger companies that I piggyback my business on are heading so I’m trying hard to make sure I don’t fall off. 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

I recently hit a few milestones that got me thinking about the attributes of sustained projects. 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

Thinking through the Retina iMac in a world where pixels stop mattering. Also, what’s going on with the iPad? Marco Arments’s thoughts on Retina iMac vs Mac Pro AnandTech’s Hands-on

While a single button might seem somewhat boring or mundane to discuss I unpack the process of thinking through a single button in Emoji++. Specifically how to handle editing of favorites. Ultimately I went with an Edit button rather than a gesture based approach. While somewhat benign superficially decisions like this can make or break your user experience. Also, why I didn’t make the icons wiggle. The Boring Designer Creating Passionate Users Creating Passionate Users - Feature Curve

Talking through the process that ultimately lead to the creation of Emoji++, my recently launched custom keyboard for iOS 8.

Getting an app ready for day one of an iOS/device launch is impossible to do right. As a developer you have a variety of options available for how you approach it, none of which are perfect. 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

With the rollout of iOS 8 upon us I consider two aspects of the current Apple ecosystem that appear to lie in tension. 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.

Today I wanted to take a quick run through the App Review Guidelines. Love ‘em. Hate ‘em. They are one of the most core parts of creating and distributing apps for the App Store. I will give some high level thoughts about the state of App Review and then walk through some of the recent changes Apple published. 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

Today I’m going to dive into the world of app updates. Why we do them, how often we do them and whether they are important. 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?

This past week has seen an explosion of writing and discussion about the business of making software for sale on the iOS App Store. Personally I love it when these little bubbles of discussion appear. If you’ve listened to me for any period of time you’ll know that one of the things I really like is being a student of the App Store. These discussions provide the opportunity and motivation for all sorts of anecdotes which help expand my view on where things stand. 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ş

Back from a delightful, extended vacation I want to take a minute (or 15) to talk about the importance of stepping back from the day to day inputs that can so easily mold or distort your views on things. The world is a varied and complex place and likely very different than the people and perspectives you interact with on a daily basis.

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 past week we had a bit of drama about the role of podcast networks. I don’t intend to wade into that discussion but as a result of it I was asked about the role that linking and recommendations play in expanding my own audience for this show. Which is considerable and measurable. I wanted to return the favor this week by talking about how I stay informed about the goings-on in Apple development. 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

ASCIIwwdc 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).

We are exploring a new territory within the Apple developer landscape. Here is how I plan my expedition. 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!

My initial impressions on the 2014 WWDC Keynote. Wow, it was a big one.

This year I’m going to skip my usual soapbox speech about WWDC tips and etiquette. Given the way the ticket distribution played out it seems neither kind nor productive. If you are going to WWDC I commend these two #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.

I wax philosophical about the future. Trying to wrestle with the uncertainty that surrounds our industry. Some products succeed, some products fail. Where will mine fall?

My thanks to everyone who purchased a t-shirt in the last two weeks. They should be at the printer and then on their way to your door within the next week or so. 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.

T-shirts 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.

T-shirts 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.

I hope you fared better in the WWDC lottery than I did, though I’m hopeful for a possibility of a second round on Monday (maybe?). The system and process generally went really well and I think this is likely the process we’ll see going forward. It isn’t perfect but is as good as I could imagine. 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.

A few words of appreciation for the new lottery based WWDC ticket sales. Get your name in the hat by Monday morning. 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

After taking credit ;) for Apple’s experiments in search improvements I dive into a few changes to the App Store that could improve doing business in the store. 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.

I will be at NSConference next week, if you are a listener of the show please make sure you find me and say hi. 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.

Towards a Better App Store: Part 2 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.