Marco.org

Christina Farr’s Reuters article is pretty bad, as helpfully detailed by John Gruber. Apple’s accessibility support leads the industry by a mile.

But the actual issue, buried in the sloppy article, is legitimate:

But when apps don’t work, life can grind to a stop. Jonathan Lyens, a San Francisco city employee, who is legally blind, has a hard time browsing jobs on professional networking site LinkedIn.

“The app is insane. Buttons aren’t labeled. It’s difficult to navigate,” said Lyens. When it comes to social media apps, new problems arise with every release, he said. “I get nervous every time I hit the update button.” …

Now, Apple and Google both have developer guidelines on how to make features accessible, such as labeling buttons that can be read by Apple’s VoiceOver software.

But they don’t require accessibility, in contrast to other strictly enforced rules, such as a ban on apps that present crude or objectionable content. Nor do they offer an accessibility rating system, which some disabled advocates say would be a big help.

Apps with standard UIs get most accessibility for free, Apple doesn’t reject apps for inaccessibility, and most customers don’t rely on accessibility tools, so most developers never hear about accessibility problems.

In the rush to get apps and updates out the door, it’s easy to forget to test every UI change with VoiceOver. I’ve certainly forgotten many times.

But while accessibility problems only affect a small percentage of an app’s userbase, their impact can be extremely damaging or fatal to those customers’ ability to use the app.

Accessibility failures should be embarrassments to all developers because they’re usually very easy to fix. For most problems, you just need to add label text to a custom control or image button. Rare “complex” issues are usually less than an hour’s work.

I try hard to get accessibility right… when I remember to. My triple-tap home-button shortcut is always mapped to VoiceOver so I can easily test. I include VoiceOver users in betas whenever possible and had an extremely valuable and insightful accessibility review in the WWDC labs this year. But I still occasionally ship unlabeled buttons, hidden-view clutter, or inaccessible custom views.

Poor or broken accessibility is exactly the sort of problem that Apple’s App Review team should check for: many developers forget to test it, it’s easy for Apple to quickly test when reviewing each app, and it’s easy to fix.

It’s even more clear when considering the customers’ point of view. App Review assures customers of minimum quality and security standards so they feel comfortable buying apps, and we all benefit from it. The App Store Review Guidelines are quite clear on the basics:

2.2 Apps that exhibit bugs will be rejected

2.3 Apps that do not perform as advertised by the developer will be rejected

Of course. Customers should know that they’re getting what’s promised.

But those rules aren’t applied to accessibility. For a customer who uses VoiceOver, rows of unlabeled buttons and inescapable screens are “bugs”, and an app with inaccessible features certainly does not “perform as advertised”.

This sucks for everyone: Apple, developers, and most of all, customers relying on accessibility aides who unknowingly pick a bad app, can’t do what they need, and now can’t trust the App Store with future purchases.

Requiring all apps and games to be completely accessible is probably infeasible. But that’s not the only option. My proposed fix:

1. Allow developers to opt into accessibility testing for each submission in iTunes Connect. Put it on the screen that asks about cryptography so all developers must answer it and are made aware of it.

2. Show a small badge on each app’s page in the Store that passes accessibility testing. This helps customers make buying decisions for their needs.

   Passing requires all advertised functionality to be accessible, all accessible controls to have accurate labels, and no navigational traps such as inescapable screens or stuck states.

3. If a user has VoiceOver enabled while downloading an app that has not been tested for accessibility, or while updating a previously tested app to to an untested version, show a warning dialog and ask them to confirm whether they still want to proceed. This helps them and gives developers a good reason to opt into accessibility testing.

There’s definitely more Apple can do to address this very real problem, and a system like this would make a huge difference.

In Headphones and Coffee, I had to disclaim that I hadn’t tried most of the best headphones in the world — I was sticking with what normal people would consider a “high-end” range of $500–700, but to a headphone audiophile, that’s midrange. I had never heard what many consider the quintessential high-end headphone: the famous Sennheiser HD 800.

As expected, I heard about it. I also had a great Amazon-referral month, so I decided to “reinvest” (that’s what I tell myself to justify high-end headphones, at least) and give them a real shot. I also hated my closed headphones,¹ so I got what many consider the best closed headphones currently for sale, the Fostex TH900. Both retail for $1500, and both are frequently on sale for a few hundred bucks less. I planned to try both for a few months, then sell one or both.

I still can’t detect a sound-quality difference between amps and DACs² unless there’s an electrical problem, like an amp with insufficient power for the headphones or a DAC with audible noise on the outputs. But I wanted to give these headphones a fair shot, and the HD 800 needed more power than my existing amp could deliver.

Choosing an audiophile amp and DAC are difficult because audiophiles will tell you a great deal of unscientific wine-tasting descriptions of how each component sounds, then recommend whatever they bought. As soon as you pick one, the same people blame it for any flaw or disappointment you find. “Oh, you aren’t impressed by these expensive headphones? Burn them in for 600 more hours, upgrade that inferior stock cable, and replace that harsh DAC.” It’s exhausting.

I like what Schiit stands for. Their founders are extremely good electrical engineers, and their products hit all of the checkboxes — high power, low distortion, fancy inputs and outputs, both tube and solid-state models, etc. — but they’re very affordable (relative to similar products), and their no-bullshit attitude is refreshing in an industry that’s otherwise so full of it. (Really. Read some of their product FAQs, or co-founder Jason Stoddard’s ongoing story of their early days.)

I chose well enough to give these headphones a fair shot by most reasonable estimates:

• Asgard 2 amp, $250: It delivers plenty of power for the HD 800 and similar headphones, it’s very well-priced for a headphone amp, I don’t notice any flaws in the sound, there are no finicky tubes to deal with, and it looks great. Fair warning, though: since it’s a class-A circuit, it runs hot by design, constantly emitting about 30 watts of heat if it’s not playing anything. You should probably turn it off when it’s not in use. Still, I recommend this amp if you need its power.³
• Bifrost DAC, $350–520: To minimize audiophile-complaint vectors, I got the fully upgraded model with the USB Gen 2 Input and Uber Analog Stage. I have no complaints, but I also don’t think this was necessary. The line-out from my Mac directly to the amp sounds just as good to me, with a very minor exception: with my most sensitive headphones (the TH900), nothing playing, and the volume cranked very high — higher than I’d ever play music — I can hear very slight noise from my Mac’s output that isn’t present on the Bifrost’s. But I rarely listen to extremely loud silence.

So if you need an amp, the Asgard 2 is great. If you need a DAC, the Bifrost is great, but I still question whether you need one — given any budget constraints, a great DAC’s price is much better allocated to better headphones first.

*   *   *

I previously chose the Beyerdynamic T90 ($650) because of its incredible detail, quality, and comfort, with the caveat that its treble can be harsh with some music, especially studio rock and pop albums sloppily mastered in the mid-2000s to sound better on awful earbuds. But that was the only substantial flaw, and I was blown away by everything else about it, especially that level of detail.

When the Sennheiser HD 800 and Fostex TH900 arrived, I put the T90 in the closet for a few months, leaving me to get to know the new arrivals full-time: the HD 800 when I could use an open pair, and the TH900 when I couldn’t.

When I first tried the venerable Sennheiser HD 800, which costs at least twice as much, I was disappointed — it wasn’t very different from the T90. Over the last few months, I’ve been able to put my finger on why it’s so well-regarded: It has no obvious flaws.

Well, almost. The bass is pretty light, even for audiophile headphones. But this isn’t a problem with any music the way the T90’s treble can be too hot with some. With the HD 800, I never notice any flaws, when listening to anything, that I can point to as a headphone shortcoming. It’s a technical marvel.

But this comes at a cost that took me a few more months to realize: the HD 800 has no personality whatsoever.

The best part of owning great headphones is the occasional “Holy shit!” factor: those moments where you’re just blown away by how great the music sounds. The HD 800 never sounds exciting or fun, and I’ve never had a “Holy shit!” moment from it. You don’t rock out with the HD 800 — it’s very pleasant, but it won’t make you dance in your chair.

It’s technically brilliant, but in reality, it just needs a bit more… something. It’s like a perfectly cooked filet mignon with no salt.

The Fostex TH900 is another story. It’s by far the best closed headphone I’ve ever heard, but that’s partly because it’s not very closed. Its isolation is roughly in the middle between open headphones and almost any other closed pair. But my wife is very forgiving of the sound leakage.

The TH900 has the same incredible level of detail as the HD 800 and T90, but with ample personality. If the HD 800 is like a perfectly flat equalizer, the TH900 is slightly and pleasantly V-shaped: the midrange is recessed just a tad, the treble is boosted slightly, and the bass is strong (though not overpowering like Beats). Unlike the T90, the extra treble never sounds harsh — it just boosts the detail slightly, like a dash of salt.

It’s not neutral-sounding, and the HD 800 is definitely the technically superior headphone. But over the months that I’ve owned both, my HD 800 usage is decreasing, and I’m finding myself going to the TH900 more. The extra hint of treble — and more-than-a-hint of bass — are much better for almost everything I listen to.

The TH900 is also a bit more comfortable, and looks a hell of a lot better — the HD 800 looks like it was designed by space aliens in 1993. And the TH900 is much easier to drive: my Mac Pro’s headphone port can power it amply with a size adapter, though I’ve been using the amp anyway. (Both are far too large, unwieldy, and fancy for portable use.)

*   *   *

Back when such things mattered, in a review I read comparing the first Playstation to the Sega Saturn, the author wrote something that I’m almost positive I’m remembering correctly: “If you only get one, get the Playstation. But if you have both, you’ll play the Saturn most.”

I was frustrated at the time, as a Sega fan: why not pick the Saturn, then? But the author was clear that the Playstation was the “better” system, whatever that meant. I didn’t understand it for years, but I finally get it now.

If you want the best headphones, I must recommend the HD 800.⁴

If you’re willing to drop $1500 on a pair of headphones, it’s hard for me to advise you to buy any other pair. If you don’t get the HD 800, and you’re anything like me, you’ll always wonder what you’re missing.

If you never want to doubt your choice and feel like you’re missing out on something better — well, that’s an unrealistic expectation. If you’re considering $1500 headphones, you’ll never stop wondering if something else could sound even better. But if you at least want to minimize those times, get the HD 800.

The HD 800 is the better headphone. But the Fostex is my favorite.

And I finally see the difference. If I can only have one, I’ll take the Fostex.

*   *   *

Epilogue

After writing most of this, I took the $650 T90 out of the closet for the first time in months and compared it against these $1500 flagships.

It performs admirably: it has all of the personality and detail of the TH900 in a smaller, lighter, cheaper, open headphone, and I think I actually prefer it to the HD 800 despite its hot-treble flaw. Sometimes higher-end is “better”, but not preferable.

The TH900 manages the same detail and personality without the harshness. It really is better. It’s not almost-3-times-the-price better, but it’s still my favorite.

By opting “only” for the T90, you’re really not missing much that the highest-end headphone world has to offer. As with most pursuits, diminishing returns set in rapidly. The T90 delivers far more of the top-of-the-line qualities than its price suggests.

I’m searching for a properly powered HiFiMAN HE-6 to audition, hopefully with the upcoming Schiit Ragnarok amp. I wish there was a better way to try these things out other than just buying them and selling them later, but there mostly isn’t. (At least resale value tends to hold well.) And I still need to tell you my SR-009 story, but that’s for another day.

I’ve been listening to podcasts regularly for almost a decade, and there have always been more great podcasts than I’ve had time to listen to. Podcasting doesn’t have a content problem. More great podcasts are always welcome, but there isn’t a lack of great podcasts holding back the medium.

Podcast adoption has always been driven primarily by ease of listening, which has improved dramatically with the rise of smartphones, podcast apps, and Bluetooth audio in cars. When it’s easier to listen, not only do more people listen, but listeners find more opportunities to listen. There’s still plenty of potential to help people who already like podcasts listen to more of them.¹

I had been wanting to make a podcast app for a while by late 2012, when I got two ideas that encouraged me to look more into it:

• Smart Speed shortens silences. Playing at faster speeds has always helped people make time to hear more podcasts, but it usually came at the expense of sound quality and intelligibility. Smart Speed is like getting another speed increment for free: it saves time without sounding weird.
• Voice Boost is a combination of dynamic compression and equalization that can make many shows more listenable and normalize volume across all shows. This makes amateur-produced podcasts (including many of my favorites) more listenable in loud environments, like cars, where you’d otherwise need to crank the volume so loudly to hear the quiet parts that you’d blow your ears out when the loudest person spoke.

Neither of these are original ideas, but I knew both would greatly help me as a listener, and none of the podcast apps offered anything like them.²

Over the following weeks, I learned the low-level Core Audio API and made a “Castaway” prototype that could apply these effects to a podcast file. To my surprise, Smart Speed sounded nearly perfect with no audible artifacts. Conversations still sounded natural — often better, with tighter timing. Voice Boost easily normalized and enhanced everything I threw at it. And these ran at full speed on an iPhone with very low CPU usage.³ I knew I had something good, but Instapaper and The Magazine were keeping me too busy to pursue it.

Months later, in the spring of 2013, I sold both for unrelated reasons. Realizing that I had the rare opportunity of a clear plate, I dusted off the Castaway prototype and started the truly hard part: building an entire podcast app around the audio engine I had prototyped.

Smart Speed and Voice Boost are killer features to me, but a lot of people won’t care nearly as much about them, and there’s nothing stopping the other apps’ developers from adding similar features. My podcast app needed to be a compelling overall package, not just two features. There was a lot of work ahead.

By June, I had the server basics running, with feed crawlers trying to find and update as many podcast feeds as possible.

At WWDC, I got even more encouragement. iOS 7 shook up the market and, by pure luck, shifted high-end iOS design away from fashions I could never compete in — heavy use of textures and complex graphical widgets — into what I could actually do: simplicity, space, and typography. I also demoed the audio prototype in my hotel room to Guy English, using his own voice,⁴ and he was impressed — a great relief to me, as this was the first time anyone else had heard it.

Over the next few months, I worked my ass off, both building the app and naming it. By the time I had announced Overcast in September with my XOXO presentation and blog post, I was already using it myself full-time, so I thought it was almost done when I said it would be out about six months ago, at the latest.

But the audio engine was the easiest part of writing a modern, full-featured podcast app. Yes, I could use it full-time almost a year ago, but that’s because it only did the minimum functionality I needed, I hardcoded it to always be logged into my account, I could adjust settings by changing constants in the code, I subscribed to new shows by typing an INSERT statement into a MySQL command line, and I hadn’t yet tried to rewrite the sync engine. (Twice.)

When I finally started the beta, I expected to ship within two weeks. That was over two months ago, and I’m glad, because my beta testers pushed me to make it much better. I owe them quite a bit of gratitude.

It’s been a long road, but 1.0 is finally done. I’m proud of what I’m shipping today.⁵

Thank you to everyone who has helped me and Overcast along the way.

If you’re interested, here’s Overcast 1.0.

Many great ones, including:

• Federico Viticci (MacStories)
• Jason Snell (Macworld)
• Rene Ritchie (iMore)
• Benjamin Mayo (9to5Mac)
• John Chidgey (Tech Distortion)
• Josh Centers (TidBITS)
• Steven Aquino (on accessibility)

I’ve been plowing through thousands of tweets and emails. I’m nowhere near the bottom of the pile yet, a few small bugs got out (like almost every 1.0 release), and yes, I really need streaming. But overall, the launch went exceptionally, far exceeding my expectations and calming my fears.

Thanks, everyone.

I got this email from a “Senior Recruiter” (spammer) at Robert Half Technology today:

Hello Marco,

I hope this email finds you well. Your qualifications match a PHP Developer position we currently have with a great company in the Columbus market area. I wanted to find out your current employment situation and inquire as to whether or not you are currently in the job market and what type of opportunities you might entertain?

PHP Web Developer

[pages of garbage removed]

Desired Candidate Profile:

• Delivering Quality code.
• Extensive knowledge of iterative development lifecycle management and tools.
• Able to direct the work of others, prioritize tasks and allocate resources.

• Must be able to lead cross-functional project teams and coordinate activities of others.

  Experience in:

• Design, develop, and management of PHP Web Applications.

• Familiarity with WAMP, LAMP environments.
• Experience with MySQL.
• Taken a team through multiple complete product development cycles.
• Agile application development.
• Experience developing and using Web Services

I look forward to hearing back from you!

Let me tell you a story about Robert Half Technology in my hometown of Columbus, Ohio.

Robert Half was the first place I went to interview for a job after college. They listed a specific job online, maintained that premise through a phone interview, and then asked me to come in, only to reveal in person that there wasn’t actually a specific position available — they just wanted to get me on their list of temp consultants they could rent out.

Robert Half Technology does everything that gives tech recruiters a bad name, and everything that makes looking for a tech job so incredibly difficult when you’re young and inexperienced. They do the entire industry a great disservice. Nobody who works there should be proud of what their company does, or be under the illusion that they’re helping anyone.

After looking over my resume with me in person, which was pretty light since I was applying for my first job after getting my computer science degree, they said I couldn’t and shouldn’t be a programmer, and should stick to basic IT jobs instead.

A few days later, they assigned me one awful weekend job where I, and about 50 other similar chumps, sat around and watched a huge company’s PCs upgrade to Windows 2000 and occasionally clicked buttons when necessary. I quit after two days when I got a real job offer — as a programmer.

But that was mostly luck: a friend from college had just been hired there and connected us. I narrowly escaped a career of working for cheap IT body-farms, always regretting not starting out as a programmer like I wanted to.

So, Robert Half Technology, kindly fuck off.¹

In 2008, I added tilt scrolling to Instapaper. Today, that’s an “innovation” in Amazon’s Fire Phone, but Farhad Manjoo says they blew it:

Take Auto Scroll, which moves the text on your screen as you tilt the phone back and forth. Because Auto Scroll calibrates its scrolling speed according to how you’re holding the device when you first load up an article, your brain will struggle to find a set rule about how much to tilt to get the right speed. Often I’d scroll too fast or too slow.

This is the biggest design challenge when implementing tilt scrolling. Tilting is relative to some “zero” point — tilt forward from that angle to scroll up, and tilt back to scroll down.¹ When, and how, is the zero point set?

You can’t just have a fixed angle be the zero point, like straight up, because nobody holds their phone in the exact same orientation all the time. The zero point needs to be relative to however the phone is being held.

My solution is to have tilt scrolling always default to off, make the user toggle it on every time they want it, and use the phone’s current orientation as the zero point when they tap the button. Critically, this means they can toggle the button off and on again to reset the zero point whenever they want, like if they change positions while sitting or in bed.

Amazon has apparently chosen instead to set this when the article is first loaded, but that will never work well enough in practice. I assumed my method was common sense, but apparently not.

The biggest problem with tilt scrolling is that doing it right requires a prominent button to toggle it on and off to make realignments easy for users, and it can never just be on by default. In most cases, it’s not a widely-used enough feature to justify a prominent, always-there button in the interface, so it’s (rightly) cut from the feature list.

I don’t have a Fire Phone to test with — thank goodness, it seems — but I wonder how they did on the other details. For tilt scrolling to be useful in practice, there needs to be a bit of a dead zone around the zero point, where no scrolling occurs, so it’s forgiving of inadvertent small motions. The dead zone should be wide enough so nobody accidentally scrolls in the wrong direction when they’re trying to keep it still, but narrow enough that neither direction is frustratingly far away:

But it’s no good if someone activates tilt scrolling, tries to scroll down (the most common action), and the first few tilt degrees do nothing because the trigger zone is too far away. It feels unresponsive. So the best thing to do is not quite to center the scrolling bands around the zero point, but offset them so that the zero point is very close to the beginning of the scroll-down zone:

This way:

• The most common action is extremely easy to do.
• The screen angle while gently scrolling down is very close to the way the phone was already being held, which is probably the user’s preferred reading angle at that moment.
• There’s a wide enough no-scrolling zone in the middle to let people “rest” comfortably.
• The uncommon action of scrolling up is reachable, but far enough away that it won’t be accidentally triggered.

I assumed all of this would be common sense to anyone implementing a tilt-scrolling feature.

More from Manjoo’s review:

Worse, if you put your phone down on a table while you’re in the middle of an article, the scrolling goes haywire and you lose your place. The best thing about Auto Scroll is that you can turn it off.

This also seems like common sense. Instapaper’s tilt scrolling always stopped if the phone was set on a flat surface. Originally, that was actually a bug — probably not wrapping around the zero angle properly — but it was so obviously useful that I left it in.

Look around your iPad for a minute. How are its third-party apps doing?

Are they all being actively updated? Are they all built for iOS 7 yet? You never see any non-Retina graphics, iOS 6 keyboards, or old-style controls anymore, right?

Have you looked for any great new iPad apps recently? Did the market seem vibrant, with multiple good choices?

New iOS apps you care about are still launching with iPad versions, and they seem well-cared-for, right?¹

Are you confident that they’ll be updated to take advantage of iOS 8 shortly after its release?

I hope you’ve said yes to everything, and I’m the anomaly. Because while I’m not the most devoted or frequent iPad user, the software landscape on mine has become alarmingly stagnant.

*   *   *

Apple’s App Store design is a big part of the problem. The dominance and prominence of “top lists” stratifies the top 0.02% so far above everyone else that the entire ecosystem is encouraged to design for a theoretical top-list placement that, by definition, won’t happen to 99.98% of them. Top lists reward apps that get people to download them, regardless of quality or long-term use, so that’s what most developers optimize for. Profits at the top are so massive that the promise alone attracts vast floods of spam, sleaziness, clones, and ripoffs.

Quality, sustainability, and updates are almost irrelevant to App Store success and usually aren’t rewarded as much as we think they should be, and that’s mostly the fault of Apple’s lazy reliance on top lists instead of more editorial selections and better search.

The best thing Apple could do to increase the quality of apps is remove every top list from the App Store.

I hope Apple realizes how important it is to everyone — developers, customers, and Apple — that they make changes to encourage more high-quality apps. If they’re trying to boost iPad sales and increase differentiation between iOS and Android devices, that’s the first place to start.

But that won’t solve the biggest problem. (Neither will upgrade pricing, trials, or any other theoretical panacea.)

*   *   *

The app market is becoming a mature, developed industry, with vastly increased commoditization compared to its early days. Competition is ubiquitous, relentless, and often shameless, even in categories that were previously under-the-radar niches. Standing out requires more effort than ever, yet profits are harder to come by than ever.²

Full-time iOS indie developers — people who make the majority of their income from sales of their apps, rather than consulting or other related work — are increasingly rare. I thought Brent Simmons would get flooded with counterexamples when he proposed that there are very few, but he didn’t.

Consulting isn’t immune to decline, either. Clients were spending top dollar on app development in 2008 because they had to, as almost nobody could make apps. Now, mobile-app developers are everywhere. App development is no longer a specialty — it’s a commodity.

I’m not the only one seeing this. Here’s Matt Gemmell:

There’s a chill wind blowing, isn’t there? I know we don’t talk about it much, and that you’re crossing your fingers and knocking on wood right now, but you do know what I mean.

We’ve had our (latest) software Renaissance in the form of the mobile platforms and their App Stores, and I think the software biz is now starting to slide back towards consolidation and mega-corps again. It’s not a particularly great time to be an indie app developer anymore.

Small shops are closing. Three-person companies are dropping back to sole proprietorships all over the place. Products are being acquired every week, usually just for their development teams, and then discarded.

Luc Vandal:

Let’s face it, the app gold rush is well over. It is now much harder to make it into the market and it requires more planning, financial investment and time. … I have spoken with other successful developers and many told me the same: sales are generally down. They are still doing great but there are more and more competitors are also taking a slice of the same pie.

Gus Mueller:

I’m in my tenth year as a full time indie dev (so I can claim to have a bit of perspective). And I think that yes, it is much harder these days to go indie.

Why though?

I think it comes down to a handful of reasons, but the major one is that we have more potential customers than ever, but we also have more developers than ever.

Jared Sinclair’s sales figures for Unread, which launched to rave reviews from major writers in our community:

Considering the enormous amount of effort I have put into these apps over the past year, that’s a depressing figure. I try not to think about the salary I could earn if I worked for another company, with my skills and qualifications. It’s also a solid piece of evidence that shows that paid-up-front app sales are not a sustainable way to make money on the App Store.

These pressures are taking an immense toll on the quality and sustainability of iOS apps. I picked on the iPad earlier because its problem is deeper and more visible than on the iPhone today: while the iPad has most of the pricing and competitive pressure of the iPhone, the iPhone’s immense installed base can hide the problems for longer. The iPad has a much smaller installed base, so iPad development is even harder to justify.

But the iPhone app market has the same fate. It’s most of the way there already.

*   *   *

As the economics get tighter, it becomes much harder to support the lavish treatment that developers have given apps in the past, such as full-time staffs, offices, pixel-perfect custom designs of every screen, frequent free updates, and completely different iPhone and iPad interfaces.

Many will give up and leave for stable, better-paying jobs. (Many already have.) But there’s a way forward for those of us who want to stay.

When other industries mature and deal with these pressures, the survivors are those who can adapt and — to borrow a horrible phrase for corporations to justify downsizing and convince the remaining workers to accept more work without a raise — do more with less.

That’s where we are today.

Benjamin Mayo in response to the Unread numbers, emphasis mine:

You have to be efficient with your time to make good ROI’s on the App Store. … If you want to maximise your profitability, make small apps that do a few things well. The amount of effort you put into an app has very little to do with how much of the market will buy it.

Brent Simmons on standard vs. custom controls a few weeks ago:

A big problem is the cost of all this development. … It’s probably necessary for indies to make more than just one iPhone app. Do the same app on Macintosh. Maybe make a second or third app.

Not long ago this would have been very, very expensive — because we believed (rightly) that we had to do custom versions of all the things.

But now, I most emphatically suggest getting out of that mindset. Use standard components in the expected ways as much as possible. Create custom things only when absolutely needed.

Efficiency is key. And efficiency means doing more (or all) of the work yourself, writing a lot less custom code and UI, dropping support for older OSes, and providing less customer support.³

Apple is greatly helping our efficiency. Every version of iOS brings new capabilities that make previously difficult features much easier. iOS 7’s redesign gave indie developers a huge advantage by making the stock UI cool again.

iOS 8 helps even more. Extensions open up vast new markets and give our apps a lot more functionality for very little effort. CloudKit removes the need for many apps to run web services. Adaptive Layout will remove the need for most apps to code radically different UIs for their iPad and iPhone versions, instead providing a responsive-web-like method of automatically rearranging one UI to fit any size screen.

It’s not going to be an easy road, but it’s possible to adapt and keep going.