When I was a kid, we had a kitten named Rab. She was thus called because she was small, fluffy, white, and tail-less – like a rabbit. She was endearing and snuggly and prosh, or at least she was when she wasn’t drinking from the toilet bowl. Even as an adult, she stayed small and roughly spherical. To us, she was still a kitten.

One day, our kitten had kittens. So turns the circle of life. The litter was scrawny and stumbly, and blind enough that they’d attempt to suck milk from the olive green strands of our old shag rug.

As they grew, they got a lot cuter and a little less clumsy. As cute as they were, though, they weren’t the least bit cuddly. You could get one second of snuggle in, perhaps two, before they’d promptly mew and squirm – all they wanted to do was climb and play.

A few weeks into this, very late one night I was woken by a mewing pile of kittens in my bed. A pleasant surprise! As I blearily moved to let Rab lead them under the covers, I discovered that they were distinctly cold, wet, and shivering. Confused but dutiful, I did my best to help her warm them up, and soon fell back asleep.

The next morning, it promptly became clear what had happened. Rab, in her wisdom and stubbornness, had decided to drink from the side of the toilet in the middle the night. The kittens, in their curiosity and adventurousness, jumped up – and directly into – the bowl. Mama then taught them a critical lesson in leeching body heat from an unsuspecting human.

Disgusting, but endearing. Like much of parenting, I suppose.

As a parent, I do my best to teach my daughter well, and to keep her from harm. From time to time though, I slip up. I notice her copying behavior I wish I hadn’t modeled. I get overconfident in her climbing ability and she knocks her tooth on the pavement. Or, most recently, I give in and let her watch a cartoon that’s a little too scary. (Apparently we’re not born with the innate knowledge that “the floor is lava” is not likely to actually occur.)

If there’s a way to totally prevent these transgressions, I don’t know what it is. Nor is that a goal worth having, honestly. Letting kids slip up is a fundamental part of their education.

What’s important is, when that happens, we take care of them. We lead them to warmth, and give them comfort. Even if it’s a little gross.

And with luck, seeing my habits and mannerisms reflected in my child will continue to give me the perspective to better myself. The strength to choose my words thoughtfully, and be the person I’d like her to one day be. To stop drinking from the toilet.

Rab, mind you, she was unstoppable. Still, she was a good mom. You could just tell.

One of my most hated things is when someone over-fills a garbage bag.

You see, an almost-full garbage bag is a small task to deal with – you just close it up and pull it out. But an over-full garbage bag is a problem. Suddenly, you can’t just pull it closed anymore – dealing with the bin now involves biohazardous juggling, something nobody is inclined to do anytime soon. The resulting additional procrastination leads to, in most cases, an unstoppable garbage snowball that eventually destroys humanity itself.

Everybody has their irrational pet peeves. As long as I can remember, this has been one of mine. For years I always tried to prioritize the task of emptying the bin before it got over-filled. Sometimes I succeeded, but other times I failed, and a stupid garbage can would put me on tilt.

One day, when I attempted the task of emptying the bin, I found it over-full. And instead of emptying it, I left. I left for Home Depot, on a different task that would change how I thought about prioritization forever: I bought a smaller garbage bin.

It may be obvious to you, but for years I ignored the root cause of my age-long grief. I did nothing about the thing that actually enabled people to pile in more garbage than the bag could hold: the bin was bigger than its bag. By buying a smaller bin, the same bags simply couldn’t be over-filled. Even the most precariously over-filled bin could be wrapped up swiftly and neatly, using the specially reserved portion of bag draped on the outside of the bin, ready and waiting for duty.

It was glorious.

The quietly worthwhile

There is a lot of stuff you should get done.

Or, more accurately, there is a lot of stuff you feel like you should get done. My OmniFocus tracks 860 actions that, at one time, I felt like I should do. Many of them won’t get done. But there are some things in there that I truly should do, and if I do them, I’ll be very glad.

The question is: which ones?

Some actually-important things are urgent. If you don’t renew your passport, you can’t go on your upcoming trip. If you don’t empty the garbage before garbage day, you’ll be stuck with old garbage for two weeks. The task needs to get done, you need to do it, so you just gotta do it. It’s kind of obvious, because it’s both urgent and important.

More interesting, though, is the non-urgent stuff that is nevertheless very worthwhile. The tasks that are easy to defer, tempting to procrastinate, but actually more important than the supposedly urgent tasks: the smaller garbage bins, waiting to be bought.

So, when I’m looking at things I should do, I keep an eye out for certain kinds of tasks: work that isn’t urgent, but can multiply time. Things that could pay off for months or years to come.

In particular, I try to consider if I can:

1. Automate. Can you spend 1 hour simplifying or automating something that would then save yourself 5 minutes a week? If so, then I have an incredible investment opportunity for you: you can invest time – the most precious resource we have – at a 430% annual interest rate. The busier I get, the harder it is to get around to tackling these automation and simplification tasks, but the more worthwhile it is.
2. Teach. If there’s somebody who’d be willing to do this task in the future, but they don’t know how yet, then you have a big opportunity. The long-term payoff for teaching someone how to do a task can be massive. Even in the case of successfully handing something off only for it to “boomerang” back later, having taught still improves your understanding of the work and makes you a better teacher for the next attempt. If you’re in a leadership position of any kind, you don’t have the time not to be teaching people.
3. Calm. Like many people, I have a certain amount of tolerance for frustration and stress in a given day. At a certain point further annoyances, even small ones, cause disproportionate reactions and sap energy from me and those around me. That’s why I find it useful to prioritize fixing anything that is a persistent aggravation or stressor. In OmniFocus, I keep an ongoing project “Make Life Calmer”. Doing work today that will make tomorrow calmer and more focused is a great investment, and will let you use your future “stress budget” on something more meaningful than the fact the damn kitchen drawer is stuck closed again because the saran wrap and aluminium foil boxes got pushed on top of each other again and god DAMN it why do I have three different sets of measuring cups in here augghhhh.
4. Improve. It is extremely easy to procrastinate making yourself better. It takes motivation to build new habits, learn how do to something “right”, or to address a longstanding problem. But this work is profoundly worthwhile, since small investments here can have huge payoffs. After 35 years of using a computer like a dumb animal, I’m finally learning how to sit, type, and work in a way that doesn’t permanently injure my wrists and shoulders. Reading books about RSI or learning better posture aren’t necessarily my idea of fun, but I’m going to benefit from the investment for decades to come.

Diamonds in the rough

Next time you’re cleaning up your todos, considering a new goal or theme, or just feeling over-busy, consider how you can be multiplying your time. What things, once done, will have an impact that pays off for years?

What is your smaller garbage bin?

I try to be nice to people.

While being nice is relatively popular here in Canada, being nice is not necessarily popular in the business world. There’s something about business that makes some people feel like it’s a license to be a heel. “Well, that’s business, kid.”

Well, that’s not the kind of business I want to be in. Over the years, my team and I have made a point of making nice things and being nice to each other while we’re at it. It’s pretty simple, and it makes for a nice work environment. It’s great.

A few years back, I was at the excellent XOXO conference in Portland. Some friends and I were sitting in the sun, enjoying our cereal from a van or whatever weird-ass Portland breakfast we were eating, when an acquaintance came over from a nearby food cart with a delicious-looking free-range egg sandwich.

Now, this was a developer I’m friendly with and am always happy to see, so we quickly got to chatting. And as I talked and my acquaintance ate, he had the misfortune of getting some egg on himself.

I noticed, but I hesitated to call attention to it. To call out somebody’s appearance in a public setting, that’s not very nice, is it? So I did a rather Canadian thing – I acted like nothing was wrong.

This was a miscalculation. You see, I hadn’t considered that eventually, inevitably, my conversation partner would realize my deceit. Indeed, before long he noticed that, in a very literal sense, he had egg on his face.

Upon discovering this, he asked mournfully, “Why didn’t you tell me?”

It was a very good question. I may have felt like I was being nice, and perhaps by some shallow definition I was. But I was definitely not being kind. Immediately, I felt like the one with egg on my face. While I can only hope my friend has long since forgotten this minor cruelty, that moment has stuck with me.

Being kind vs. being nice

The distinction between niceness and kindness can seem subtle. While being nice might involve acting polite, positive, and pleasant, being kind is deeper – it’s about being caring, sympathetic, and helpful. In many circumstances the kind thing to do is simply to be nice. In some circumstances though, the kind thing to do is to be direct. Or clear. Or firm.

In learning to run a business, I found early on that however nice you are, you still need to set distinct boundaries and limits with clients in order to, for example, get paid. And when it comes to close friends and family, it can be second nature to prioritize kindness, even when it means having a less than nice conversation to help fix a problem.

The difficulty comes, I find, with acquaintances and colleagues that I’m not necessarily close to, where I can easily get away with just being nice. It can be too easy to just have conversations that are pleasant but shallow, avoiding the more uncomfortable but more helpful line of discourse. Kim Scott’s Radical Candor and countless other feedback systems are built around the idea that over-prioritizing niceness – what Scott calls “ruinous empathy” – is a short-term salve that causes long-term pain.

So, recently, I’ve been working to have deeper conversations with the people around me. I’ve been trying to ask myself: does this person necessarily care how polite I’m being, or would they rather I just prioritize being clear? It’s a bit more work, but often – especially in person – you can still do both.

I feel lucky to work somewhere where people are nice to each other, and I definitely don’t want to lose that. But there’s another notch above being nice; the next step on Maslow’s Hierarchy of Teams. Where you need to get is a culture where being nice is the default, but being kind – including having hard but helpful conversations – gets priority over always being pleasant.

That is to say, a place where you can trust that somebody will speak up – even if you have egg on you.

On an episode of Fun Fact back in March, I shared “one weird trick” for how to be an MC. Listeners seemed to find it helpful, so I wanted to write it up in a more referenceable format:

The trick to MCing an event is to control the silence.

Over the years I have MCed my fair share of conferences, meetups, weddings, and other sundry events. Any article on how to MC an event will orient you to the core requirements pretty quickly:

1. Tell people what to expect.
2. Keep things moving.
3. Make it fun.

So that’s the idea. But in order to tell your audience what to expect, you need to know what to expect. As such, a lot of MCing (or emceeing if you’re gonna be like that) involves running around collecting and confirming information about shifting plans.

How long is the break? How do you pronounce the next speaker’s name? Is there wifi? Why should we care about the rando you’ve dragged up to give a demo, toast the groom, or extol the countless virtues of immutable value types? The MC has to know what’s coming.

The next level up is about keeping things moving. Flow. How can you make this event flow smoothly, steering the audience’s attention to where it needs to be? What’s where the idea of controlling the silence becomes really useful.

May I direct your attention

You see, people are going to want to talk. Socializing is a lot of why people come to events, especially those blowhards way at the back. That’s why you need to make it clear to the crowd when it’s talk time, and when it’s pay-attention time.

If your event is well run, they will have some house music playing in the background before and between presentations. If not, you can often rig background music up yourself. House music is nice for getting folks to start talking to one another.

House music is even nicer, though, for getting people to stop talking. When it’s time to intro the next speaker or deliver a status update, just fade out the house music – or, ideally, have a sound tech do this on your signal. The sudden silence will draw everybody’s attention, and your intro blurb (or glib rhetorical question) will shut up the remaining verbal stragglers. You then say your bit, and hand that hard-won energy off to the next speaker by introducing them by name.

The reverse flow happens on the way out: you thank the speaker by name, tell people what to expect next, and then get the house music back on. By controlling the silence – by ensuring there’s only dead air immediately before something interesting is about to happen – you can control the room.

The smooth handoff

There are a couple sub-tricks to keeping folks’ attention as an MC. If it’s time for the next presenter and you jump into introducing them, you might realize post-intro that they’re not actually ready. “Oh, uh, I need to get my laptop set up.” Cue 2 minutes of awkward silence as your speaker fumbles around, inwardly panicking, while the audience slowly starts to talk amongst themselves again. Bad MC, bad! By the time things really are ready to go, the energy and attention have been lost to the wind.

Luckily, there are two simple ways to prevent a botched handoff:

1. Check with your next-up speaker if they’re good to go before you get the audience’s attention.
2. If you realize you’ve gotten the audience’s attention too early, and you can’t shuck and jive long enough to fill the gap, just give the attention back. Instead of letting things get awkward, explain that you’ll need a few more minutes and we’ll be going shortly – then get the music back on.

MCing an event isn’t rocket surgery. It does take a bit of practice, but the biggest requirement is simply caring about how things flow, and putting the work in to make them flow well.

Being the steward of an audience’s attention is a privilege. If you treat that attention as a precious resource, then they’ll be willing and ready to give it when you need it.

Once upon a time, Apple debuted an application for playing music.

Yes, an application. That’s what we called apps back when dinosaurs roamed the Mac. And one of the most-loved applications back in that ancient era was for playing your MP3s. It was called iTunes.

iTunes brought together a shiny interface and powerful library management that Just Worked™. What we didn’t know in 2001 was that iTunes was the first piece of a “digital hub” strategy that would change Apple forever. From its humble beginnings as a nice way to play music, iTunes quickly became the core of Apple’s push into consumer electronics: first the iPod, and later the iPhone.

Two years after its debut, iTunes was already at version 4. The addition of the iTunes Music Store turned a trusty utility into an internet marketplace overnight. The Store completely overturned the music industry and overturned Apple itself, kickstarting its shift from a computer company to a device and services company.

As fortuitous as this path would be for Apple’s business, the frenzied shoehorning of network and sync features into a large existing codebase – inherited from the aquisition of SoundJam MP – brought about the end of iTunes’ golden era.

Later that year, iTunes arrived on Windows. Apple quickly gained a foothold on millions of Microsoft PCs; a base they could add to every time they had the need to support something across platforms. As penance for this, the iTunes team was sentenced to maintain and add functionality on Windows every time Apple launched a new product or service.

And add functionality they did. Over the years, iTunes accumulated features for local music, playing and burning CDs, the iTunes Store, iTunes in the Cloud, iTunes Match, Apple Music, TV, movies, Smart playlists, Genius playlists, podcasts, network library sharing, device backup, internet radio, ratings, iTunes Extras, iTunes U, device software update and restore, media sync, ringtone sync, contact and calendar sync, AirPlay, queueing, Ping, Connect, literally rearranging the icons on your iPhone home screen and – most importantly – displaying a bangin’ visualization of the Hootie and the Blowfish track you just purchased for $0.99.

As the central device and platform hub, iTunes became a leaf on the wind of Apple’s strategic moves. The refined focus of the app’s early days gave way to an era of ever increasing complexity and power.

Of course, with great power comes great technical debt. As iTunes became a mammoth katamari of features tangentially related to media, it failed to become a robust front-end for Apple’s increasingly complex network of media services. UI oddities – ranging from weird modal dialogs to an often complete inability to handle network problems – often belied iTunes’ status as a tired legacy product.

Undeterred, Apple marched forward towards streaming music, introducing iTunes Match, iCloud Music Library, and iTunes in the Cloud – which, believe it or not, are three separate things. While Apple’s marketing team may not have struggled to keep up with this growing array of services, iTunes itself certainly did.

While building the UI for many of these new features using web technology might have been a pragmatic move, it exacerbated iTunes’ struggle to provide a polished and seamless user experience. A move from store pages powered by XML to one fuelled by WebKit never stopped the background drumbeat of glitchiness that often ground the app to a halt.

By 2015, it was time for a reset. With great fanfare and a remarkable performance by Eddy Cue, Apple Music was born. With Apple Music, the iTunes team was finally given the time and space to fully overhaul the app, ditching 15 years of legacy chaos once and for all.

Just kidding, it was just stuck on top of what was already there.

Of course, a focused and clean music-only app for Mac is still the endgame. The real question has long been: when?

Retiring iTunes is a hard thing to do, given the wild web of legacy things it enables. Building a ground-up replacement for music on the Mac is a tall order, especially if they wanted to bring across the powerful library management features that made Mac users fall in love with it all those years ago.

Alternatively, Apple must have at least experimented with bringing the much-maligned but generally more modern Music app from iOS to the Mac. Perhaps they could use some kind of almond-flavoured confection to ease the transition.

Regardless, replacing an app the size of iTunes is a big job.

So we waited. The world turned. Users slowly shifted from iTunes to Spotify. A movie came out about a gumshoe Pikachu and it was somehow not horrible. That is to say, it’s taken a very long time – so long that one might assume there has been a false start or two along the way.

But if the rumour and leak mill is to be believed, iTunes’ end is finally nigh. In macOS 10.15 we will finally see a Music.app for Mac. Surprisingly, this new app is said to be based not on the iOS app or a new codebase, but on the venerable iTunes itself.

There will surely be naysayers that claim iTunes should have been tossed entirely. And admittely, if the new Music app ditches iTunes’ interface but can’t cure its deep and baffling love for obtuse modal error dialogs, I too will bemoan its preservation. But arguing for code to be rewritten just because it’s old has never been the right way to build systems that work.

And whatever the composition and fate of this new app, you really have to hand it to iTunes for getting this far. Seriously, this app has been keeping the beat for almost 20 years. It has survived a veritable hurricane of scope creep and strategy taxes. It was a key part of Apple’s growth from charming underdog to singular goliath.

And now, it can finally lay down its burdens and get back to its roots. It can cash out its stock options, and once again be a music app. What better way for a vintage app to spend its retirement?

So let’s pour one out for iTunes. Farewell.

Writing is meant for reading.

Sometimes, the reading doesn’t matter that much. We might dash off a quick text, toss out a laugh line, or send a rote confirmation. Our emoji are leaves on the wind.

Other times though, the reading matters a lot. Occasionally we need to write something that must be understood, absorbed, and acted on. The more important it is that readers understand and act, the more time you should spend refining the writing.

There are a lot of things you can do to make an email, blog post, proposal, or process document clearer. For example you can keep it short, make it engaging, or have a colleague refine it before sending it out. These can all help a lot.

However, if it’s critical to you that your writing is read – especially by busy people – you need to make it skimmable.

There are a few ways you can facilitate this.

You can use short sentences and paragraphs, for example. That helps a lot because folks tend to primarily read the beginning of each paragraph. It’s kind of a hack, but it works.

There is one core approach though, one workhorse of the skimmable document, that is worth mastering: lists. Lists are rightly derided in the era of Buzzfeed, but the same principles that drive engagement on social media also drive engagement in a Google Doc or email. So today, I’d like to share one weird trick to quickly writing a clear and useful list: The Bolding Trick.

The Bolding Trick

1. Draft a bulleted list, whether it’s the key goals for a process, the main principles in a design, or whatever. Rather than trying to make it perfect on the first go, just get it out.
2. Your list should only have 3-8 items on it, with each item 1-3 sentences, which should keep it readable and digestible. Still, unless each item is extremely short, the resulting block of text can still be a slog to read, appearing monotonous and causing your audience’s eyes to glaze over, or – worse – cause them to decide to read it later.
3. For each point in your list, find and bold the key phrase in the paragraph. For example, the key phrase in this point was “bold the key phrase”. This will make the list far more skimmable.
4. If it’s an important list, it’s worth also pulling those bolded phrases up front. Once the core points are bolded, run down the list again and pull the bolded part to the beginning of each item, making it the heading/summary of the item.
5. Your eminently readable and skimmable list is now ready to be absorbed and acted upon, and easily maintained.

A thing I love about this process is that when you pull out the key phrases into headings, it also naturally drives you to edit the prose to be clearer:

The Refined List

1. Make a bulleted list. Hammer out the key goals for a process, the main principles in a design, or your weird trick for making lists.
2. Include 3-8 Items. Make the list clear and focused by keeping it to 3-8 items of 1-3 sentences each.
3. Bold each key phrase. Go through the items you wrote and mark in bold the 1-4 words that matter most. This would be often be a verb phrase in a process document, or an adjective phrase in a list of goals.
4. Make the phrases headings. While you can stop after bolding, it’s often worth also pulling the key phrases into inline headings. Rewriting your list this way also helps you refine and repeat the key points.
5. Share and maintain. The formatting will make your list much easier to read, update, and act on.

I find this approach faster than trying to come up with the headings first, and it has the added bonus of being incremental: after each pass you can stop and you have a useful document.

Once upon a time, when I would try to document a process or a project, I’d approach it like a blog post. I’d spin a narrative, write pages worth of context and detail, and really get to the heart of the matter. Once the resulting tome was complete, it would be read once, and then left to the sands of time. That was fine for battle stories and manifestos, but not so much for process or design documents.

Now, I write short docs consisting mostly of lists and bolded key phrases. They get read and maintained.

It’s a lot better.

If you publish apps for iOS, understanding the App Store review process is part of your job. While the core guidelines are public, their enforcement relies on a large set of private rules and policies, policed by human beings. When you’re trying to release an update to your customers, the keeper of the Bridge of Death is not the nicely summarized guidelines, but the machinery that enforces them.

The high-level guidelines don’t change often, and when they do change developers are often warned in advance. The enforcement policies though – the de facto rules – are continually mutating in response to the latest App Store scams, PR issues, or problem areas.

So, while some guidelines – such as the one about not sending push notifications for marketing – don’t seem to be enforced at all, others are strictly enforced to the letter of the law, and flouting them will prompt a swift rejection. Or, more nerve-wracking, an eventual rejection of a bugfix update that doesn’t change the relevant functionality. So it helps to know the system.

You say you wanna add subscriptions

For example, suppose you’ve seen where the wind is blowing, and have decided to add subscriptions to your app. In preparation, you may come across public Guideline 3.1.2:

Ensure you clearly communicate the requirements described in Schedule 2 of the Apple Developer Program License Agreement, found in Agreements, Tax, and Banking.

While you probably should read the full agreement, it’s a little over 24,000 words long. Maybe more of a weekend read. In the meantime, you can save a bit of time by scoping out a little thing I like to call the “Apple Developer Program License Agreement Schedule 2 section 3.8 part b”.

This clause actually has some pretty clear language asking developers to:

…clearly and conspicuously disclose to users the following information regarding Your auto-renewing subscription:

• Title of publication or service
• Length of subscription (time period and/or content/services provided during each subscription period)
• Price of subscription, and price per unit if appropriate
• Payment will be charged to iTunes Account at confirmation of purchase
• Subscription automatically renews unless auto-renew is turned off at least 24-hours before the end of the current period
• Account will be charged for renewal within 24-hours prior to the end of the current period, and identify the cost of the renewal
• Subscriptions may be managed by the user and auto-renewal may be turned off by going to the user’s Account Settings after purchase
• Links to Your Privacy Policy and Terms of Use

Presented with the above, any app designer worth their salt will have a follow-up question: is it even possible to design a nice subscription flow that actually makes all eight of these things clear and conspicuous? Even with all the detail Apple provides – more than we generally get with most guidelines – the requirements leave key questions about how they’ll actually be enforced:

1. Do the App Store reviewers require text meet a certain standard to consider it “clear and conspicuous”? (They do.)
2. Do the links to your privacy policy and terms of use in your app’s settings count towards this requirement? (They don’t.)
3. Do reviewers require that some of these things are more clear and conspicuous than others? (They do.)
4. Would they approve an app that followed Apple’s own examples of how to implement subscriptions? (Not even close.)

I know about these pitfalls thanks to various developers sharing their lessons learned about the unwritten parts of Apple’s subscription guidelines. As thanks, I wanted to pitch in by sharing some info about a different guideline I’ve learned a fair bit about over the years: 2.1.

Guideline 2.1: Information Needed

According to Apple’s data, the most common reason for an app to be rejected is ostensibly a simple one: “Guideline 2.1 – App Completeness”. The public guidelines for 2.1 describe a few kinds of incomplete or trivial apps, for example:

We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems.

Eminently reasonable. In addition to this though, App Review categorizes a common type of provisional rejection as being under Guideline 2.1: “Information Needed”. Since an Information Needed rejection is usually unexpected, it can easily ruin a developer’s day. Thus, it helps to be prepared.

Here are some common reasons you may hit a 2.1:

1. You didn’t include a working demo account. D’oh.
2. You didn’t include enough info to test your In App Purchases. This is apparently quite common – reviewers have to try out your IAPs, and if it’s not immediately clear how to do so you can get a 2.1 rejection.
3. Your app is sketchy. Certain categories of apps are, by volume, often scam or spam. Slots apps, for example, can get a 2.1 as basically a “one strike warning” to give the developer a chance to double-check whether they violate certain rules before they go through full app review. There are various copies of this warning text online, so if you’re participating in the dodgy end of the App Store then it’s worth being aware of this.
4. Your app isn’t testable on a simulator. If your app isn’t testable except in the “real world”, or requires special hardware, reviewers may 2.1 reject the app pending a video that shows how it works. If your app doesn’t run in the simulator, pre-prepping a demo video can help expedite this process. Steamclock builds a lot of apps for Bluetooth devices, so we prep these fairly often.
5. You need to prove that your company is authorized to offer this app. For example, let’s say you titled your app “Royal Bank of Canada”, but tried to publish it under “Surprised Pikachu LLC”. You may be surprised when App Review asks for some evidence that you are in fact the largest financial institution in Canada and not in fact a lazy scammer.

While these cases are all fairly straightforward, there is one particular 2.1 request that I have seen from time to time that did surprise me when I first saw it, and as far as I can tell not much has been written about it. You may in fact be rejected if:

6. Your app requires users to log in, but doesn’t offer account creation.

Without a way to create an account, App Review can’t evaluate your payment mechanism. In this case, App Review will typically hit the brakes to determine if the app violates “3.1 Payments”.

If your app’s business model was crafted specifically to circumvent Apple’s In App Purchase rules and you thought just not offering in-app account creation would be enough to fool them, then you’re gonna have a bad time. Otherwise, things aren’t so bad. You just need to – carefully, but quickly since your app update is now in the dreaded Review Limbo – make the case that your business model is kosher.

One of the few accounts online of this process comes from this Japanese blog post by Takuya Matsuyama, who outlines what App Review may ask in this “business model review” scenario:

• Does your app access any paid content or services?
• What are the paid content or services, and what are the costs?
• Do individual customers pay for the content or services?
• If no, does a company or organization pay for the content or services?
• Where do they pay, and what’s the payment method?
• If users create an account to use your app, are there fees involved?
• How do users obtain an account?

Through the magic of Google Translate, I can see that Takuya and I felt similarly after getting this kind of rejection for the first time:

Even though Apple’s examination was nothing last time, it is scary because it is pointed out from the point of view not to predict suddenly.

Put another away, it’s not fun to have the Supreme Gatekeeper suddenly audit your business model.

Being prepared

Since I know better than to try to end-run around Apple’s payment rules, every time I’ve received this kind of rejection I’ve been able to walk App Review through the business model and why it’s above board.

That’s not to say caution isn’t merited. I’ve definitely seen clients get a business model review, respond ambiguously without understanding the underlying guidelines, and as a result get caught in a slow secondary review. Don’t be like them – be prepared.

If you’re considering building an iOS app that requires login but doesn’t let users create accounts in-app, be sure to review and understand Apple’s rules around in-app payment, and schedule an extra 1-2 weeks when you launch or make a major change to the app to accommodate a potentially long review. If your initial submission is approved without a 2.1, be cautious since any future update, even a critical bugfix, could trigger the review.

If the bridgekeeper perceives your iOS app to be main value of a service customers are paying for elsewhere, they could toss you into the Gorge of Eternal Peril for not offering IAP.

If everything is on the level though, and you just haven’t gotten around to providing account creation in-app in your initial release, then you should be fine.

Just don’t forget your favourite colour.

In iOS 11, Apple made a variety of changes and improvements to the Apple Podcasts app and spec. Among other things, they added support for a new show format: serial podcasts. Finally, narrative-driven shows could request to be shown in strict chronological order.

As part of this change, Apple added support for an “episode number” tag, and recommended that podcasters stop including episode numbers directly in the title of each episode. Sure whatever, metadata best practices blah blah.

Smash cut to yesterday, when we all received a mass email from Apple Podcasts about ensuring our show isn’t “rejected or removed from Apple Podcasts” by “optimizing your show’s metadata”. While much of it was just about not being spammy, they asked more firmly this time for podcasters to stop including episode numbers in titles:

Adding episode numbers in titles. For example, show titles like “The Very Hungry Tourists Episode 01” or episode titles like “01 Broken Heirloom.”

I was a bit surprised by this. Everybody includes episode numbers in their titles… don’t they? Though come to think of it, why do we? Why do I do it for Fun Fact? We don’t number our blog posts; why podcasts? Am I being sucked into a deeply pedantic rabbit hole, never to return?

No, why, why do you care about this Allen

According to historians, podcasters have included episode numbers in titles since the late Cretaceous Period. There are a few benefits, but the primary two are:

1. Give people an easy handle to find or refer back to to a specific episode
2. Make it easier to play through episodes from the beginning in a podcast client

While the introduction of “serial” shows has made playing from the beginning easy for certain kinds of podcasts, apps still make the assumption that all shows are either strictly linear and need to be listened to in order (a crime investigation in 10 parts), or that each episode is completely unrelated and you would never want to start from the beginning (a daily news briefing).

This is a pain in the ass for shows where the episodes are loosely ordered, kind of like a sitcom. The episodes make sense on their own, so new viewers probably want to check out the latest one first – but there are back-references and follow-up items that can make it appealing to listen from the beginning. Without episode numbers, this can be annoying to actually do.

In an ideal world, Apple would support a third type of show, something like episodic-series, for shows where playing from either end is desirable. It could then prioritize the newest episodes, but still surface episode numbers and accommodate users who want to start at the beginning.

Back in the actual world, Apple wants you to decide if your show is linear or ephemeral, and stop trying to hedge that classification.

Still though, why do they care? Is it truly awful to have semi-episodic podcasts putting numbers in their episode titles?

As is often the case, you can indeed find something truly awful by exploring iTunes:

Yes that’s right, on the desktop iTunes will number your numbered episodes as if the latest episode was episode 1, followed mind-bendingly by the episode number you’ve included in the title. While this is horrific, it actually makes podcasters want to keep including their episode numbers right in the title, since otherwise the presentation makes it look like the newest episode was actually your first, which is even more horrific and I just can’t even with this thing.

Thankfully, most people do not listen to podcasts in desktop iTunes. The big show, the app that we – and Apple – are concerned about is Podcasts on iOS. So let’s take a look at how episode numbers show up there.

045: The Why Do You Care About This Allen Show – Ne…

With iOS 11 and the new metadata, Apple built accommodations for episode numbers into the UI, allowing them to cleanly and consistently show numbers in contexts where it matters – such as serial shows – and not show episode numbers in contexts where it doesn’t matter. For an example, let’s take a look at the Top Episodes list.

Now, £1 says that Jony Ive would be rather cross if he saw this list with 5 different formats for showing episode numbers. With title data this noxious, there’s not much Apple can do to present a nice, clear list of episodes.

Consistency aside, in this context the episode numbers aren’t even useful. While the Top Episodes list should in theory be a gentle entry point for somebody new to podcasting, it is currently weird and intimidating.

If they can get podcasters to provide title and episode number metadata separately, Apple Podcasts can show the numbers where relevant, and style the them thoughtfully in different contexts, rather than being forced to serve up the the dog’s breakfast that is episode title metadata today.

And while numbers in titles is a time-honoured tradition, I have to admit that episodes of newer shows that follow Apple’s guidelines look pretty nice amongst their metadata-laden peers.

The more I look at these screenshots, the more sympathetic I am to the ideal of relegating the episode numbers to metadata, and having player apps take the responsibility of showing those numbers where they’re useful. In fact, when it comes to finding specific episodes or playing “episodic” shows chronologically, modern podcast apps already have some helpful features that make episode numbers less important than they once were.

For example, in Overcast you can tell a smart playlist to sort by “Oldest to Newest by Podcast”. Then, if you go into a show’s back catalog and add a horde of early episodes, they’ll automatically stay together in chronological order. It’s pretty hidden, but in Castro you can also queue up a show chronologically by subscribing to a show, then going to Library → That Show, then dragging “All” to your queue.

While neither of these approaches are as nice as a simple UI for playing a show from the beginning, I think they can bridge the gap if shows start to move episode numbers into metadata and players get smarter about it.

Similarly with episode discovery, instead of scrolling to find a numbered show, you can type an episode title into Apple Podcasts and it will come right up. In Overcast you need to search for the show first and then the episode title, but the functionality is still there.

Unfortunately, there is still a gap between the web and podcast players when it comes to linking an episode. As far as I know, there’s no way yet for your podcast’s website to predict the URL for “Open Episode X in Player Y”, which would make it easier to go from a Google search or a shownotes link right to listening to an episode. With luck this will come.

I get it, you care, what are you going to do about it

Regardless of what any 3rd party podcast apps are doing, the reality is that Apple runs the biggest podcast directory and app in the world. They’ve told us to give them a clean title and episode tag in <itunes:title> and <itunes:episode>. In return, they’ll be more likely to feature our show, Jony will be placated, and they’ll stop maybe-implying that our podcast may be “rejected or removed”. So, a pretty easy call there, I think.

A more interesting question remains though: for semi-episodic shows like Fun Fact where people may want to start at the beginning, should we keep the episode number in the <title> tag for 3rd party clients like Overcast and Castro? Certainly some people with opinions on the internet think so.

But I have to admit: I can’t unsee what I’ve seen. I’ve beheld the clean and clear presentation of numberless episode titles. I’ve heard from the listeners who are scared off from trying out podcasts where every title advertises how many episodes they’ve missed. I’ve come to terms with the fact that for our show – even a few months in – starting with the most recent episode is the way to go. And most dangerously of all, I’ve come to the conclusion that It Would Be Nice™ if podcast players directly used the episode meta tag to only show numbers where it matters.

So, as of today, our episode titles are clean and number-free. It was difficult and emotionally taxing, but I have made peace with my decision.

May the the era of clean podcast titles one day come to pass.

Update: Apple just sent a followup email clarifying that “Your Show Won’t Be Removed for Having Episode Numbers in Episode Titles”. It then goes on to say:

We encourage you to use the tag to send us your episode numbers. If you decide to include episode numbers in your episode

The email then ends mid-sentence. We can only speculate on the fate of the Apple Podcasts employee who attempted to send this missive. Our thoughts are with their family tonight.

When launching a product, especially a consumer-oriented one, you want it to be interesting. A novel, bold, or distinctive UI can make an app stand out from the crowd, be memorable, and inspire curiosity. Plus, it’s cool.

Luckily, there are a lot of ways you can make an interface interesting. You can use striking colours, intriguing illustrations, or thoughtful copywriting. You can add whimsical touches of animation or sound. You can make the feature set brilliantly simple, or awesomely powerful. Almost any part of an app can be a good place to add novelty, except for one: navigation. Navigation is different.

Navigation should be boring.

With a delightfully boring navigation scheme, users don’t need to learn how to explore your app. Their “attention span budget” can thus be spent considering how your new thing can fit into their lives, rather than trying to recall how many fingers they’re supposed to drag from the left side of the screen in order to pull out the Alternate Quick Access Wheel.

While experienced design and development teams will usually tamp down on the worst navigation fever dreams in short order, there is often still an allure, or even explicit pressure, to build out novel navigation patterns. It’s just so damn satisfying to transcend the standard fare. “Would it be so bad if we just tried just a little horizontal scroll here, and just one two-finger gesture there..?” One thing leads to another, and your app’s first-run experience is a screen filled with goofy arrows and hand-written tips like “insert tab A into slot B to view next photo”.

If you’re weird-navigation skeptic, then take heart: the data is on your side. The A/B tests and other success metrics I’ve seen almost always support clear, familiar navigation approaches. Tab bars get better engagement than hamburger menus, many users don’t even find gestures, and simple menus works better than a whiz-bang feature dashboards. Boring navigation affordances lead to more navigation, and faster navigation, than clever ones do. As the nobly helmeted interaction designer Luke Wroblewski likes to say, “Obvious always wins.”

Of course, metrics aren’t everything, and there are examples of products that have implemented novel navigation schemes that were very well received. Even ignoring the obvious exception of games, a lot of the most interesting apps released over the years – from Jared Sinclair’s Unread and Q Branch’s Vesper on the indie side, to Snapchat and Facebook’s Paper at other end of the spectrum – invested in novel navigation patterns and styles that made them truly distinctive.

Which is super cool. But also kind of sad, since this type of investment doesn’t typically pay off.

The high price of failure

Notwithstanding the usability pitfalls, there is a bigger reason why a new app shouldn’t have an experimental navigation scheme: the cost is too damn high.

We know that building good products is all about iteration. And typically, the parts of your product that need the most iteration are the novel ones. The neat stuff, the distinctive bits. That’s no problem if you’re iterating a sound effect, a button asset, or even better a core user-facing feature. It gets expensive and wasteful fast though if you’re thrashing around how your screens are organized, divided, and connected. God help you if you’re halfway through a wild navigation experiment and an iOS update breaks your custom UINavigationController wallhacks before you’ve even been able to market-test them. It’s no fun.

Once you ship, things go from bad to worse. Overhauling the navigation of a living app is even more time-consuming, and is also usually poorly received by existing users – even if the new scheme is objectively better. Just ask Snapchat: after they concluded their wacky navigation scheme was inhibiting long-term growth, they launched a reworked UI that was easier to use – and monetize – but suffered a huge backlash from users who were used to the old UI. Perhaps if they’d tracked towards clear navigation a little earlier, Instagram wouldn’t be eating their lunch as badly today.

Of course, it doesn’t matter what’s good for Snapchat or anybody else. What matters is what’s good for your product and its customers. The app you’re building today. And if your goal is to make a distinctive app, then dollar for dollar, sprint for sprint, novel navigation schemes are one of the worst ways to achieve that.

So do your app a favour: keep the navigation boring. At least at first. Use colour, typography, and the many other tools in your tickle trunk to make your product interesting and appealing while you prove out your business model. Invest in navigation, sure – but invest in making it clear, fast, and good.

That is to say: make it boring.

A new podcast where every other Friday, Arik Devens and I discuss a variety of fun facts. They range from historical, to practical, to garburetor-related. It’s fun.

This year, in addition to my typical longer articles, I’ll also post some simple links from time to time. This is one of those.

When you have a young child, other parents often offer advice. This advice comes in many forms and covers many topics, but one phrase is more common than any other. “Enjoy it while it lasts. It goes by faster than you think.” New parents hear this many times.

It can sound rather strange. You’re holding a teething infant, you’ve barely slept, and you’re counting the seconds until you can next attempt a nap. Time seems to go by very slowly indeed.

As an infant turns into a toddler though, and as that toddler becomes a kid, you can’t help but be struck by the passage of time. Your new family member gains abilities at a rapid clip, marking time not day by day, but change by change.

They are constantly picking up new endearing habits – little phrases and behaviors that melt your heart and give you joy. Just as quickly though, they are losing them. Before your eyes, she goes from not being able to say “octopus”, to delightfully squealing at the sight of an “oppatoo!”, to just saying “look dada, it’s an octopus.”

And it’s beautiful, and it’s great. But it also hurts your heart a little bit. No more oppatoo.

It is a strange feeling, that hurt. Why would it be sad when she starts to say “octopus”? Or “I want to do it myself”, or “No dada pick me up”? I mean, it’s certainly for the best. I can hardly be her lifelong transportation, caregiver, and translator as it pertains to 8-limbed mollusks.

But kids inspire love, such deep unconditional love. You love and treasure how they are, down to the smallest quirk. Then, suddenly, right in front of you, they change. While one might grow used to the slow, sad change of growing apart from an adult you love, this feels very different. Overnight, no more “dada up?” No more oppatoo.

In a flash, the behaviors, quirks, and tiny things you’ve grown to love disappear. Just like that, they’re replaced by new phrases, new quirks. New things you’ll also grow to love – before they disappear too.

It’s beautiful, and it’s great. But it also hurts your heart a little bit.

So we take photos, and now videos. And we indulge our hearts, and cry a bit. Sometimes from pride, sometimes from joy, and on occasion from the loss of something tiny.

And when we see a new parent, one with a child much younger than ours, we know it’s silly, but we can’t help ourselves. We feel it’s very important to let them know:

“Enjoy it while it lasts. It goes by faster than you think.”

Congratulations, you’re getting promoted! You have excelled at the Thing You Do to such a degree that you’ll now be leading a whole team of people who Do That Thing. Very responsibility, much excite.

Okay wait, you may say. That’s cool, but I like Doing the Thing. I’m pretty good at it, and if I’m leading a team, will I still get to do it? Will I still get to perform the work that got me to where I am today?

The short answer is: Yes, you can! If it’s important to you to keep doing some “individual contributor” work as a manager, you can make that happen.

The long answer is: Well, you can. Like, if Mark Zuckerberg wants to go in and make some code changes to Facebook, he has the authority necessary to do that. And reportedly, in frustration with a pet bug or issue, Zuck has been known to bang out a fix and submit a merge request – which then hits a series of roadblocks around coding guidelines, localization, automated testing, and oh god why is this stuff so complicated these days ughhhhh.

And that’s good. It’s helpful for leaders to get their hands dirty from time to time, to get caught up on what their teams are doing, how they’re doing it, and get more context for the detail work involved.

But let’s be honest. Is Mark Zuckerberg’s time best spent mastering Facebook’s latest pull request rules around internationalization flow, or would that same time be better spent, I don’t know, figuring out how Facebook can ruin the world less?

As a manager, you too need to consider these tradeoffs. Yes, you have the ability to dig in and do the work yourself, but you now have a specialer ability: you can multiply your efforts across a whole group. As a leader, you’re in a position to solve bigger problems than you ever could by yourself, since you can deploy the full force of a team.

In other words, you are now a mech pilot.

Megazord Assemble

If you’re not familiar with the concept of a mech, it is basically a giant robot you can use to go around and do badass stuff that you wouldn’t be strong enough or capable enough to do by yourself.

A mech pilot doesn’t have the fine-grained control or precision they might have on foot, but they can achieve much more due to the mech’s broader abilities, sensors, strength, and skills. You might not be able to see behind you, but your mech can – and it can take evasive manoeuvres, deal with issues before they become problems, and do more at once than a mere human.

At its best, being a leader feels like piloting a mech. Your team can achieve far more than you can. As a group they’re stronger, smarter, and can see more than you can. When your team smashes a problem into bits, it’s not literally you that did it, but you can get the deep satisfaction of smashing problems that are bigger and scarier than you could ever smash yourself.

At its worst, being a leader can also feel like piloting a mech. Sometimes you try to go somewhere, but nothing happens. Maybe there isn’t enough fuel, there are serious technical issues, or you haven’t given a critical part the care and attention it needs. Maybe a request is refused – “ERROR: COMMAND UNCLEAR OR ILL-ADVISED”. Maybe you hop out and set your mech on autopilot, only to later realize it’s rampaged off doing exactly as you’d asked for weeks straight, and now you have this big fancy video editing feature built out that had no budget or detailed requirements.

You know, typical giant-robot stuff.

As a leader, there will be times where you’ll be tempted to get out and just do the work yourself. And sure, sometimes that’s pragmatic or necessary, but that’s not leadership. A leader investigates, identifies their team’s problems, and gives them what they need to be fully operational.

And then, they get back to smashing giant space bugs.