A podcast discussing news of note in iOS Development, Apple and the like.

#195: Pincer Maneuvers and Stubbed Toes.

Download MP3

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.

#194: In Review.

Download MP3

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.


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

#193: Update Treadmill.

Download MP3

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.


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?

#192: Nobility of Effort.

Download MP3

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.


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.

#191: Insulated Perspectives.

Download MP3

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.