Last week I tweeted something regarding Dynamic Type, custom transitions and the like that got a lot more interest than I imagined. Sadly, a lot of people misunderstood aspects of this.

Building iOS apps? Expensive right?
This tweet saves you many $1000s:

🙅‍♀️ Don’t use custom fonts or sizes, Dynamic Type only
🙅‍♂️ Don’t create custom navigation
🙅‍♀️ Don’t create custom transitions unless it is pivotal to your product

Accessibility is more important.

✅ Ego-free UX

— Marc Palmer (@marcpalmerdev) February 20, 2019

As you might expect there was a lot of support and some disagreement. The core message is that people (and it seems especially one-person indies, based on feedback) don’t understand the total cost of “easy” things like this. There are elements of developer bravado in this. In a larger organisation with separate designers you can add to that designer bravado and you have a recipe for “Sure we can do that, it’s easy”, without consideration for the realistic cost in development, QA and inter-team communication required to achieve and verify these things in quality products.

In any non-bedroom organisation making apps, a notional cost per day across the involvement of design, engineering and QA — let alone managers sitting in on these things — is easily $2000 per day. Nobody thinks about these numbers except maybe your managers who don’t know the “small” decisions being made about several days’ effort per year on an “easy” item like this.

A lot of people focused on the custom font part of this and delighted in saying, perhaps coincidentally, how easy it is to implement Dynamic Type sizes for custom fonts. Something like a custom font — which in 99% of cases is something that benefits nobody except a designer (I do love designers by the way) — is not in itself that hard if you’re already doing Dynamic Type which by its nature requires good Auto Layout work. Neither of these should be considered optional, but a custom typeface¹ is very optional.

A bunch of other people confused the part about custom transitions with me saying we should not have nice animations and make boring uniform apps. Tweets even at 280 chars are too short for nuance, what can I say. Custom presentation transitions are generally very bad news in cost terms because the APIs are already complex, accessibility issues start to fall out of it, QA on all platforms and sizes is costly and you have to maintain this stuff “forever”. Don’t do this. I’ve seen many tens of thousands of dollars wasted at startups on this stuff because people conflate novel transitions with beauty. Start with the basics. One day maybe you have tons of budget to burn on custom transitions instead of features/marketing.

At the meeting where it is announced the VC runway is only 2 months long and people may lose their jobs, few people have the guts to stick their hand up at the meeting and say “Actually, maybe we shouldn’t have spent two months of dev budget plus many weeks later with debugging and maintenance on custom UI transitions”.

A lot of people also misunderstood the Accessibility part as being about VoiceOver or catering for a niche. I should have used the word Inclusion instead. As it happens there was a very interesting episode of Presentable that covered some of this. We’re all on a multi-axis spectrum of abilities, be they visual, muscular, dextrous, auditory or cognitive and this can change from hour to hour let alone as we age or become ill temporarily or permanently. This is just a reality of life.

Inclusion is a better term and encompasses people of all ranges of abilities, as in the ~40% in cases like Overcast who have non-standard text sizes on iOS.

So to clarify, the real essence of the tweet is:

• Maximise your market by supporting Dynamic Type — you have to do the layout work for this anyway to support translation which is something very expensive to retrofit by rebuilding all your layouts later, so grow your market by catering for Dynamic Type from the start and get the option to add translations “for free” later. Don’t use fixed height views for text.
• Put realistic full-stack² internal price tags on all custom type, navigation and transition work. Management do not have sight of this information usually. Design should compromise until you have plenty of time and money to neglect the core features of the app for this stuff. If you have to choose the full custom design or dynamic type plus more app features, I strongly recommend the latter.
• Choose to spend your time and money on the things that truly move the needle with customers. Not what the company brand/ego and design department jump to as a default “must have”. This rot usually starts early on… and frankly conflicts massively with much loved “MVP” thinking.

Finally the failure to do the above often contributes to the notion that native development is way too expensive and empowers people who think tools like React Native are a better option. That makes me sad. A lot of people are shooting for Mars when we should first shoot for the Moon. Or something.