This article by Jürgen Siebert was first posted on June 17, 2013 to the German Fontblog.de. The English translation for Typographica.org is by Maurice Meilleur.
There was no shortage of long-distance diagnoses of the typography in Apple’s recently presented mobile interface, iOS 7. The live-streaming keynote address from the WWDC developer’s conference last Monday hadn’t even started before the first typophiles started sharing their concerns on Twitter. The day before the announcement, our friend Stephen Coles was already deeply worried about the light weight of Helvetica on the display banners hanging at the WWDC venue in San Francisco:
“Skinny font as seen on the iOS 7 banner at WWDC.” Please, no. http://t.co/8ajr15GOgL
— Typographica (@typographica) June 10, 2013
The next morning former New York Times art director Khoi Vinh compared the look of the new iOS to a cosmetics department:
https://twitter.com/khoi/statuses/344510376345485313
And two days later, Thomas Phinney (formerly in the type team at Adobe) also took iOS 7’s typography to task:
1/2 iOS 7 preview: horrible type. Low foreground/background contrast & lighter weight Helvetica trending illegible.
— @[email protected] (@ThomasPhinney) June 13, 2013
2/2 Existing iOS Helvetica UI font was already anti-legibility. iOS 7 choices could make me run for the hills.
— @[email protected] (@ThomasPhinney) June 13, 2013
I should remind the early birds who were already chirping during the keynote:
- that it will take at least another four months for the final version of iOS 7 to reach the market
- that you can’t judge the effectiveness of a typeface in a dynamic OS from videos or screenshots
- that no one commenting on the keynote said a word about iOS’s underlying font technology, which has obviously changed.
People did calm down over the subsequent days of the week-long conference. This was largely because of the presentations from Apple’s engineers devoted to ways the OS would handle fonts, in which they revealed the first details of the new technology.
No, text and words aren’t sinking ships in iOS 7.In fact, it’s just the opposite.
In his session, Ian Baird, the person in Cupertino responsible for how Apple’s mobile products handle text, showed off what he called the “coolest feature in iOS 7”: Text Kit. Behind this name is a new API (application programming interface) for developers of apps in which text plays a critical role. Text Kit is built over Core Text, a sophisticated Unicode layout engine with a lot of power, the potential of which unfortunately hasn’t been very easy to tap in the past. But now, no one needs to struggle with it, because Text Kit is there to act as an interpreter.
Text Kit is a fast, modern layout- and text-rendering engine, easy to maintain through settings integrated into the User Interface Kit. Those settings give developers full control over all Core Text functions, so they can choose very precisely how text will behave in all user interface elements. To make that possible, Apple has revised UITextView, UITextLabel, and UILabel. The good news: this means the seamless integration of animation and text (the same principle behind UICollectionView and UITableView) for the first time ever in the history of iOS. The bad news: this means existing text-heavy apps will have to be redeveloped in order to support all these nifty new features.
Apple has rebuilt the text layout architecture in iOS 7, allowing developers to build control over the behavior of text and fonts into the user interfaces of their apps, with a level of dynamic freedom unheard-of before.
So what do all these new options mean, practically speaking? Developers can now drop long-form texts into reader-friendly, attractive layouts, with multiple columns and with image layers that aren’t chained to the grid. There are exciting new possibilities hiding behind the labels “Interactive Text Color”, “Text Folding”, and “Custom Truncation”. So, for example, it will soon be possible while composing in iOS to have the color of text change if the app recognizes a specific dynamic element (a hashtag, a Twitter account name, or the like). Or, we can trim longer texts into previews without being limited to options like before/after/middle; developers can define those options however they want.
With just a few lines of code, developers can display the time using presentable typography, with proportionally-spaced figures and the correct hh:mm divider.
Typographic aesthetes will be happy to learn that support for kerning and ligatures (Apple calls these macros “font descriptors”) will be turned on throughout iOS 7, effortlessly accessible even over very advanced visual effects like the deceptively real-looking handmade paper texture. But don’t worry: the magical letterpress look is, for now, the only remaining skeumorphism that has survived the update, and that only in the Notes app. Think of it as an example of something that can be turned off in the future, something developers will have the right to use, or not, as they wish.
But the hottest typographic number in iOS 7 is Dynamic Type. As far as I know, Apple’s mobile products will be the first electronic devices that will by default consider a quality of type that hasn’t been given so much attention since the age of letterpress. That’s right: we’re talking about an operating system, not an application or a layout job. It’s true, optical sizes were tried in photosetting and desktop publishing—but they weren’t really automatic, and some of the attempts turned out to be blind alleys (like Adobe Multiple Masters). And yes, there are any number of displays in industry products that use different ‘grades’ of text for smaller and larger settings. But optical sizing in iOS builds on these earlier attempts and offers astonishing possibilities.
The Dynamic Type waterfall in iOS 7 (middle) lets developers specify which fonts to use at each font size. This allows them to select heavier weights when type is small, for example. Compare this to the example on the left which demonstrates a simple decrease in size of the headline weight only, and the one on the right which shows just the text font getting larger. The letterspacing shown here isn’t perfect, but an app developer could always embed a different font family, one with a wider spaced variant for the text size. Update: It appears Dynamic Text does not work with custom embedded fonts like we hoped.
Thanks to Dynamic Type, users can now use sliders (with seven stops, found under Settings > General > Text Size) to adjust the text size in every app according to their own taste. And in case the largest size isn’t large enough, those with impaired vision can find under Settings > General > Accessibility a way to turn Dynamic Type up to its maximum size, options to “improve legibility” (which sets the text over a light gradient without changing its size), and optimize the background contrast.
Conclusion: When iOS is ready to be released in a few months, the operating system itself may not offer the best typography (using Neue Helvetica). But the OS’s underlying text layout and rendering technologies offer Apple and developers everything they need to conjure up dynamic and readable text on the Retina Display in ways they’ve never been able to before.
From what I understand from reading about iOS 7, there is a setting under the Accessibility options called “Enhance Text Legibility” that appears to replace all Helvetica Ultra Light with a Helvetica Light.
Jürgen mentions that in the article, Randy, but thanks for the image!
With regard to “Optical scaling”, this is a misnomer in this case, because all they’re doing is interpolating weight between the regular and light weight Helvetica Neue fonts. Neither design has been specifically tailored to particular sizes: it just happens that they use the regular for text and the light for display. Presumably, though, the technology used could be applied to actual optical size designs.
It just sort of perplexes me that a company with a history of design such as Apple would deliberately choose a typeface that was designed for neither screen use or legibility.
Unless they’re trying to prove that you can take a generic, pedestrian typeface like Helvetica and make it legible using powerful mobile hardware/software?
Still, I think they could have expanded upon the Myriad family (which had much more character and better legibility) much like Microsoft did with Segoe UI to be a really solid UI typeface.
d_rek: But as mobile devices are progressing, we are moving away from “screen” vs “print”. As pixel densities increase, this distinction becomes much less of an issue, and seeing as how most of the text on an iPhone (disregarding webpages and similar, which are styled on their own anyway) is made up of short labels, I really don’t think that legibility is an issue. Or obviously; it’s an issue but not nearly as much as if we were discussing an e-book reader or similar.
I’m not convinced that this is the correct way of moving forward, but after spending some time with the iOS 7 beta, I can safely say that it works pretty great. Not in all cases obviously, but in most of them — so let’s just hope Apple fixes the rest of them before public launch!
John Hudson: I believe they had a session on fonts at WWDC (you can check these out if you are a developer, even a non-paid one, on Apple’s site), where they said they had designers who chose optimal spacing for letters at every size. They even make use of ligatures so words like “butter” will have the t’s connected.
d_rek: Kind of irrelevant since they use Retina display in most of their devices which renders the type pretty well.
However they always used Helvetica for iOS so it’s preplexing that it’s only now that designers are complaining about this.
ovonhauske: Typographers are complaining about the very light weight and tight spacing of the Helvetica in iOS 7. Legibility is also more important than in previous versions because iOS 7 is a minimalist UI with far fewer buttons, shapes, or other symbolical cues. It is a UI that truly relies on typography.
I’m not arguing that the hardware isn’t powerful enough to display the typeface legibly and accurately. What i’m arguing is that Helvetica, by virtue of design, was:
1. Never meant to be used in a screen space.
2. To my knowledge has never been properly reconsidered/redesigned to address the inherent problems that particular typeface has when displaying on screen (hinting, stroke width variation, etc.)
3. Is actually one of the least legible modernist sans-serif typefaces created in the 20th century because of the uniformity of the letterforms and lack of variation in the widths of the strokes of the letters.
4. Because of it’s pervasiveness in design and popular culture is a very pedestrian type solution to what is an otherwise elegant design solution (the solution being iOS).
Again, It perplexes me that Apple would choose to retrofit a typeface that has never properly been considered/designed for digital ecosystems for the above reasons.
Well,
I hope the screen shot above, of the Accessibility Settings, is indeed real.
I haven’t had an opportunity to play with the beta, and if I had, I couldn’t say anything due to NDA..
But, it does make my brain itch, a bit. With this option, Apple’s admitting what many have been saying about this god-awful system font choice. It isn’t readable to anyone w/o 20/20 vision! So, why use it AT ALL?
Well, at least I will be able to add yet another tech support offering for my customers.. “Assisting w/ iOS Readability issues” ;-) = PROFIT!
Yay?
That is awesome. Too bad text is not the most important part of iOS. The most important part is buttons and other touchable elements. Is there a Button Kit? Phones are controlled with fingers pressing buttons, whether T9 or original iPhone.
“Interactive text color” here makes me very, very sad. Try finding someone who is not a Web designer who understands the coded messages that Web hyperlinks send with their colors. Any way that iOS becomes more Web-like is bad.
Good news: according to several sources, the iOS 7 Beta 3 released today uses the Regular weight for most small text instead of Light or Ultra Light.
In the words of Matthew Panzarino, “a great weight has been lifted”. Now we can move on to other monumental issues, such as Helvetica itself.
Above: an animated GIF using screenshots from Cabel Sasser showing the default view of the Settings panel in Beta 2 and Beta 3.
d_rek:
By Apple going to a Retina Display, there no longer is a difference between rendering in print versus screen. A font can now be rendered in all its glory – whether on a small screen or on print.
I think Apple purposely chose a controversial font for iOS 7:
1. to get everyone talking about it.
2. to get potential copiers (e.g. Samsung, Google) to choose wrongly
3. to surprise and delight everyone once the amazing type capability in iOS 7 – and Mac OS X 10.9 – once the operating systems are released.
It is a new age of typography in the Apple Kingdom that surpasses anything that came before. It brings us closer to an age when there is no difference between screen and print typography.
True, current apps have to be rewritten to take advantage of all iOS has to offer. But this means each developer – big, new, small – has a new opportunity to release the next greatest app.
iOS – by forcing a rewrite – levels the playing field and opens the gate for the small developer, new to iOS and Mac OS X.
jameskatt: I think you overestimate the abilities of a Retina display. Some typefaces are simply not optimal for reading at small sizes, regardless of render quality or substrate. It has to do with weight, spacing, openness of letterforms, and most importantly rhythm. Neue Helvetica is known for its strict uniformity. This makes it appealing for big, graphic stuff like headlines, posters, and logos, but does not make it a great text or UI face.
Are we going to get ligature support in iOS 7, does anyone know? I’m burning to put things like FF Chartwell to use in a new-gen interface.
Doesn’t matter, since HiDPI (Retina etc) screens are just like paper in the attributes it matters.
So whether the original designers designed them for paper or screen use is now irrelevant.
foljs: Perhaps, but what is relevant is whether a typeface is meant for long reading or small sizes. Neue Helvetica is not. See my comment above.
So in order to benefit from Dynamic Type, I assume we have to use Helvetica Neue in our app designs, is that right? Can anyone validate this?
Umm, there is no “long reading” in the UI. Most of the UI “element” labels and such are precisely display items and for the most part look perfectly fine using a display face.
Don’t get the UI mixed up with content. iOS will have more than one font installed.
Looks like it is very easy for Apple to tweak the Text with their new framework. Beta 3 looks unbelievably good. Th UI is clear and easy on the eyes even from a distance, a full arm length away, I can read the icon labels. Nice job, Apple!
Dave C.: Any font will work. In fact, you can have multiple fonts depending on the size of the font. Font selection is Dynamic.
I am wondering if these are breaking NDAs? Or Is it this the new way of Apple handling new information.
Ed: All the information in Jürgen’s article was gathered and deduced from publicly available sources, including the WWDC keynote. Jürgen created the diagrams for his Fontblog.de article and I edited them to use Typographica’s house type. These are not slides from Apple’s presentations (as has been misreported elsewhere).
Image setters for offset printing output at 3600 dpi and above. Studies demonstrate at least 1200 dpi are needed for curves to be perceived as continuously smooth. Even cheap office laser printers have 600 dpi, for some decade now.
No visible pixels in 9 pt Didot on your “retina” display? Even with a designed optical size, interpolated, or with proper hinting, compared to print, the iPhone 5’s “retina” display offers a meager 326 ppi. Even the HTC One’s 469 ppi is still a long shot from the crispness of printed type.
Rumors on nonsensical (sans-serif!) ‘tt’ ligatures are not exactly a reassurance as regards Apple’s typographically well-instructed focus on readability over design fancy.
Dr. Wouter Soudan:
If you really knew anything about offset printing, then you’d know that it makes no sense to compare the DPI value of a printer with the DPI value of an LCD or OLED screen.
A printer can only print a dot of solid colour, whereas a computer screen pixel is capable of producing every colour the display is capable of. A printer needs that extra DPI because it also had to use those dots to create convincing shades of colour. They also aren’t as precise as the grid of a computer screen. And as far as type is concerned, an iPhone has a horizontal DPI of 978, as it uses sub-pixel anti-aliasing.
That’s not actually true. iOS uses greyscale anti-aliasing for all type rendering (web and app). Android also uses greyscale anti-aliasing for all type rendering, as does Windows Modern UI. OS X and Windows do use subpixel anti-aliasing, but only under certain conditions (display not rotated, drawing to an opaque background etc).
I agree that offset printing is different though. However, don’t conflate image DPI when printing with line screen and dot pattern. They’re separate, but related, items.
@ Justin Bell
Well, I happen to do offset printing, AM stochastic screens (and FM @ >220 lpi), where actual dot size does matter. As I use dpi and ppi (and lpi, for that matter) as different units (which you seem to confuse), you could have noticed I know to tell a digital display and analogous “printer” output apart. (By the way, printing presses are no desktop printers: they can do the full PMS gamma too, if you want to.)
Subpixel “anti-aliasing” is nothing more than a hack, to make up for the lack of adequate pixel density. And it only works — as you correctly acknowledge — on the x axis.
Type still is first and foremost one color only: it is not (should not be) rasterized, and you do need the extra pixels/dots to render crisp diagonals and curves, both on the x and the y axes.
Buried in Jürgen’s article is the small news that kerning is now enabled in iOS 7. I’m embarrassed to say I’ve been living without it in many of iOS 6’s system apps without even noticing. (Or maybe I did early on and learned to ignore it.) Of course, the looser font spacing in iOS 6 was much more forgiving of missing kerns.
André and I snapped some Mail.app screenshots that show how Neue Helvetica looks in iOS 6 and iOS 7 (see pairs like ‘Vo’, ‘Ty’, ‘LY’):
On 7.8.13, Jake said this about Dynamic Text:
We also thought Dynamic Text would work directly with embedded fonts, and we implied so in the article. Unfortunately, it doesn’t — at least not yet. Brent Simmons reports:
Bummer. But there’s a workaround. Simmons continues:
And Matthew Bischoff, formerly of the New York Times iOS team, concurs, saying that this technique is exactly what Apple recommends. Apple’s Ned Holbrook adds another option:
The kerning has made a massive improvement to legibility, word shapes are hugely improved and I find my self reading endlessly on my small screen iPhone 4.
As a typesetter, I loathe web typography. Considering the amount text people read online, why has ICS never been thought about? Apple has addressed this well and I prefer reading now on my phone rather than on my laptop or desktop.
Is there an existing version of iOS 7′s optical scaling written for the web? […]
[…] of Helvetica, and then to a squarer face than the other OS fonts as part of the introduction of multiple-size masters for the new […]