I’ve always said that if Apple Watch ever gained direct Suica loading with parental controls, Apple could make a killing selling it into the Japanese education market. watchOS 7 Family Setup is almost there for the JP market but needs one more thing: Family Suica.
The service outline is simple and combines what car keys do in Wallet with digital key sharing and Apple Cash Family does with transfers and limits. A master Apple Pay Suica ID is setup on an iPhone and manages family member Apple Pay Suica on other devices. The master ‘organizer’ would transfer stored fare (SF) via Messages and set spending limits just like Apple Cash Family does. Simple intuitive convenience.
Apple Pay Family Suica also needs transferable commuter passes. That way a parent can set one up for a child, transfer it to Apple Watch and renew it remotely. Transferable commuter passes would also be handy in our COVID teleworking era as working parents might not need a pass every working day. A “hey honey can I borrow your pass today,” thing that plastic transit card users do all the time.
So far nobody has managed to to produce a smartwatch that matches the super convenience of Apple Watch and Apple Pay Suica. If JR East and Apple produce Family Suica, they would effectively future-proof both next generation Suica and Apple Watch in the Japan market.
When the AliPay Apple Pay leak surfaced earlier this year the stock story was that Apple Pay must support AliPay and WeChat Pay if Apple Pay is to have any relevance for iPhone users in China. The real story is more interesting and is centered on App Clips, not AliPay or other specific QR code payment players.
Tap or Scan Simplicity The strength of code payments is simplicity and low cost. iPhone is both a radio (NFC) and camera (scanner). NFC always has an advantage over a scanner in that it works without light and can be activated just by the user pointing their device at an NFC reader or tag.
The downside is the NFC reader side of the equation: the reader + cash register/transit gate + transaction software has a higher initial investment than a code scanner attached to a POS system. The promise of App Clips is they finally put NFC, specifically NFC tags, on the same low cost entry bar of QR codes.
App Clips are activated by:
App Clip Codes
Safari App Banners
Links in Messages
Place Cards in Maps
Let’s examine the ‘real world’ App Clip activation triggers: Apple App Clip codes, NFC tags, QR codes. For Apple designed App Clip codes, “You can scan them with your camera or tap one using NFC.14” The #14 footnote is interesting: “Camera support for scanning an App Clip code will be made available in an iOS 14 software update later this year.”
This means those fancy Apple designed App Clip codes are coming after the initial iOS 14 launch, and when they do Apple Pay Code Payments will certainly be coming with them. It boils down to one thing: making App Clips a simple tap or scan process. NFC tags still enjoy the ’point here’ advantage as App Clip does the rest. For visual codes the user has to launch the camera and scan before App Clip takes over.
The Code Payment/App Clip Network Connection Requirement Apple Pay Wallet NFC payment cards have 3 major features that payment apps do not:
Direct side button Wallet activation with automatic Face/Touch ID authentication and payment at the reader
Device transactions without a network connection
Ability to set a default main card for Apple Pay use
Apple Pay Code payments can possibly offer this for dynamic code payments where a scanner reads the code off the iPhone screen. However, static code payments are messy because Apple Pay requires a network connection to process the payment just like apps do. In the Apple Pay code payment scenario suggested by the AliPay screenshot leaks, a static code scan directly activates the appropriate Apple Pay code payment (AliPay, etc.), the user enters the amount, taps ‘Pay’, authenticates, and Apple Pay does the transaction via the network connection. It’s a similar scenario for NFC tag payments.
It’s because of this network connection requirement that I believe Apple is pushing Apple Pay NFC tag and code payments wrapped in the App Clip experience. They will work by themselves of course, but they work better as part of the total App Clip experience. This is where App Clip codes come in.
App Clip codes are Apple-designed identifiers that are uniquely paired to specific App Clips and provide an easy way to find and launch an app experience at the exact place and moment you need it. You can scan an App Clip code with your camera or by tapping one using NFC.14 We will be adding support for them in an iOS 14 software update later this year.
How is this any different from regular NFC tags or QR codes? I suspect it’s a mini qualification program for developers, payment providers and merchants to supply the ultimate App Clip experience. It also works as App Clip branding and advertising for Apple.
Are there special App Clip code tags that push the App Clip experience further than regular NFC tags and QR? I suspect so and that could be fun. Think about it, what if the Apple designed App Clip code NFC tag activated an App Clip with code payment. A QR payment without the static QR code. That would be the ultimate App Clip experience indeed.
As with every major iOS update the Apple Pay Suica UI gets a minor tweak or two. Sometimes they pan out, sometimes they don’t. The dynamic commute plan ‘Renew’ button was a little more descriptive in b4 and b5. At best it’s was of questionable value when the language was Japanese but downright embarrassing to look at when the language was English.
Since Wallet card UI elements can be dynamic why not highlight the expiration date in red instead? Apple engineers fortunately had the better sense to change the button label back to the sensible iOS 13 design in iOS 14 b6, the final design.
watchOS 7 Suica is getting some useful tweaks: card transaction history, low balance and commute plan renewal reminders, and Suica card information can now be viewed and/or set directly on Apple Watch. In watchOS 6 these can only be viewed or set in iOS Watch App.
2020 is the coming out party for Apple designed OpenType variable fonts, both the SF Pro and SF Compact system fonts and the all-new New York font shipping in iOS 14, watchOS 7 and macOS 11. The Apple created variable font technology is not new of course. It has been around since the QuickDraw GX days along with the TrueType GX enhanced Skia font. It was due to be standard in MacOS Copland system fonts including a Japanese variable font created by FontWorks. Then Steve Jobs returned to Apple and everything changed.
Yes, it has taken 25 years for an Apple created technology to make it into the basic system. It proves my long stated belief that font technology doesn’t matter unless it is built into every nook and cranny of the OS foundation. The TrueType GX Skia variable font has been with us all this time, but only matters now because the SF Pro system font has gone variable.
Why is It Taking So Long? iOS 14 and macOS 11 variable font basics are covered in an excellent WWDC20 video, ‘The Details of UI Typography’. It’s important to remember that while OpenType variable font technology is ‘world ready’, at this stage they only apply to Roman based font sets. It’s going to be a long time before we see a Japanese language system font in variable format.
There are many reasons. In the WWDC20 video Loïc Sander of the Apple design team drops a big hint when he explains that while digital technology (PostScript fonts) “gave us a lot more flexibility in handling text,” it also “made typography a bit more crude than it used to be.” The statement shows how clueless designers and engineers outside of Japan can be about Japanese fonts and typography.
While a ‘bit more crude’ might be true for Roman based fonts and text layout, PostScript fonts completely broke traditional Japanese font design and composition models. Everything was thrown out because Adobe made no accommodation outside of western typography needs when creating the PostScript font DTP foundation.
Another big problem was that Adobe relations with Japanese PostScript licensees in the 1990’s was not healthy. Adobe stuck with closed print device font licensing for far too long and discouraged independent font production wherever they could. Because of this situation, digital font progress in Japan was slow and very expensive.
Here are some challenges facing Japanese variable fonts.
Once Upon a Time One basic flaw of OpenType outline font technology is that it’s extremely inefficient for kanji glyph production and storage. Every glyph has to be created and stored separately and doesn’t scale well. This is why OpenType CJK fonts on tiny devices like Apple Watch are a match made in hell. One solution to this problem is stroke fonts. Stroke fonts use a library of basic glyph parts to efficiently create complex glyphs.
Stroke fonts are a perfect fit for kanji font production and for small constrained devices like Apple Watch because reusable parts don’t take up precious resources. On the desktop, stroke fonts can do weight variations over the full range from Light through Ultra Bold without losing typographic details, all in a single 4 MB font while an equivalent OpenType variable font can weigh in around 18 MB.
The technology has been around for a long time and was supported up until macOS 9 but lost out when Apple quietly dropped the QuickDraw GX derived Open Font Scaler architecture in the migration from classic to macOS X.
While stroke fonts are not supported in the current Apple OS lineup, on the font tool side stroke font technology has appeared in software such as the classic MacOS Gaiji Master from FontWorks. The lead engineer of that effort is currently working independently on a similar gaiji glyph tool for Windows based on stroke font technology that is much more advanced than the old and long unavailable FontWorks software. I plan to cover developments in a future post.
The Japanese Font Production Challenge The Hiragino iOS/macOS Japanese system font was not created by Apple, it was licensed from Screen Holdings (SH), originally created by independent font design studio Jiyukobo in the early 1990’s. There is much more work involved creating a Japanese font compared to Roman based languages. Hand drawn glyphs are created, scanned and cleaned up for digital production.
The Adobe Japan 1-7 glyph collection requires 23,060 glyphs for a single weight, multiply this work by the different weights for one family and you get an idea how massive the undertaking is. From Osamu Torinoumi, one of the key designers of the Apple licensed Hiragino font on its creation:
On average, one person would (hand) draw 12 or 13 glyphs a day, which is not much change of pace from the days of creating block type…the whole process, from start to finish, took three years.
One might think that a single CJK (Chinese-Japanese-Korean) font sharing a common design can streamline the process but this is a huge misconception. Each culture has centuries worth of different design aesthetics that good design must incorporate: what looks good to a Chinese designer and works well in a Chinese text design, looks terrible in Japanese context. I have yet to see a decent digital ‘kana’ design from a Chinese font designer. Osamu Torinoumi on the differences in creating the Simplified Chinese Hiragino Sans GB:
“We worked with the Adobe GB 1-4 character set (29,064 glyphs) at 2 weights. Basically we had to finish one weight in 6 months. One year for the entire project. At first we only thought we would be there as backup, but Screen kept passing us all the questions from Beijing. It turned out to be a lot more work than we anticipated.”
Jiyukobo sent all the original Hiragino design data to Hanyi Keyin through Screen and they adapted the designs for China. Torinoumi said that one of the major differences is that Chinese design demands that Gothic (sans serif) characters mimic handwritten style. This means the character should be slightly off center within the virtual body. “Even after the project was over I still didn’t understand the difference between Japan and Chinese “Kokoro” glyph which the Chinese designers insisted were different.”
The Variable font UI Challenge Finally we get to a problem on the Apple OS platform side that has been around since the GX days: how to present advanced typography features in a useful and easy to understand system UI that works everywhere. What works on macOS obviously won’t work on iOS, but iPad OS will need some degree of advanced typography feature access. Sliders have their place but I agree with Adobe Type Senior Manager Dan Rhatigan who made a very good point in his TYPO Talk 2016 presentation: there has to be a better UI control concept out there.
Japanese typography is unique in that it has preserved its own print ‘moji bunka’ cultural history and vision that China and Korea have largely abandoned in the face of western centric computer culture that all too often pretends to care about such things, which it does not. If it did we’d have vertical text in web browsers by now that actually works. I hope a rich text culture can be preserved and conveyed to future generations even in such small details as a well designed and executed Japanese variable font for computers and smart-devices.
The first problem was the iPhone lineup. iPhone 8 didn’t fit because only A12 Bionic devices and later support NFC background tag reading. This was solved with the release of A13 Bionic powered iPhone SE and deletion of iPhone 8 from the lineup.
The second problem was the clunky ‘launch an app’ or ‘launch Safari’ to do anything. This has been a problem for NFC tag solution providers like SmartPlate. User interaction needs to reside on a task focused pop-up sheet while the screen is on. The new iOS 14 App Clips framework that works hand in hand with iOS 14 Core NFC to load just what is needed to take care of the NFC tag task at hand, is the right solution.
The pieces appear to fit very nicely now: the NFC background tag sheet pops-up ‘while the screen is on’, the right code snippets load in for a simple focused task, the user can Sign In with Apple ID if needed, and pay with Apple Pay. Simple, uncluttered action; no apps, no Safari launch. And we have background NFC tag reading on every current iPhone model.
There are a few flies in the ointment:
Face ID in the face mask era is a lousy unlock and Apple Pay user experience, App Clip powered NFC background tag reading is gonna rock on Touch ID iPhone SE even though it was designed for Face ID.
A network connection is required, Apple Pay transactions at the NFC reader work without a network connection but App Clips + Apple Pay transactions need a network connection for the obvious reasons of loading app clip content, and because of this…
A weak borderline WiFi connection can jam the entire process even with WiFi Assist turned on.
The NFC advantage over QR Codes here is that background tag reading automatically pulls up the App Clip sheet when the screen is on while QR Code users have to manually pull up the QR reader app and scan a code to join the fun.
The combination of App Clips, NFC tags and Apple Pay will be extremely disruptive in markets where NFC and QR payment players are very competitive. Places like Japan. PayPay and Line Pay lose their edge. Smart QR payment players can adapt and add NFC tag support in their payment apps. And they can bypass Apple Pay if they want to, though it won’t be as slick. Ultimately they are not wedded to QR codes, PayPay and Line Pay have always said they would add NFC if customers want it.
App Clips finally unlocks the power of background NFC tag reading and is the other big WWDC20 Apple Pay development in addition to CarKey and Apple Pay QR Code AliPay payments. App Clips puts NFC tags on equal footing with QR Codes for the first time with the added edge of the ‘when the screen is on’ background tag read sheet pop-ups. This will be huge.