Technology
**Developing Perspective**

Developing Perspective is a podcast discussing the news of note in iOS Development, Apple and the like. Hosted by David Smith, an independent iOS developer.

Latest Episodes:

#196: Faust had it easy. Sep 24, 2014

Show notes

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

#194: In Review. Sep 04, 2014

Show notes

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

#193: Update Treadmill. Aug 08, 2014

Show notes

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?

#192: Nobility of Effort. Jul 30, 2014

Show notes

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.

#191: Insulated Perspectives. Jul 24, 2014

Show notes

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.

#190: Everything but a Business Model Jul 03, 2014

Show notes

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.

#189: In the Loop Jun 26, 2014

Show notes

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

Business-y Stuff

General News

Blogs

Misc

#188: Thoughtful Accessibility Jun 20, 2014

Show notes

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

Our TOPPODCAST Picks

Follow Us

Stay Connected

Developing Perspective

Pincer Maneuvers

Stubbed Toes

In it together.

Context

Types of Updates

Things to consider

Super, mega, high level overview.

Unique opportunity.

Different Goals.

Indie Life.

Patience.

Build. Ship. Repeat.

Required Reading.

Subscriptions

Advertising

Consumable In-App Purchases

One Time In-App Purchases

Up Front One Time Purchase

Free

What is best?

Podcasts

Programming and Design

Business-y Stuff

General News

Blogs

Misc

Related Podcasts

Links

Stay Connected