iOS 14 app clips unlock the power of NFC background tags

We first got a taste of iOS 14 app clips with the slick Titanium Apple Card setup that leverages the NFC background tag reading ability of iPhone XR/XS and later. Jennifer Bailey gave a sneak peek of NFC background tag Apple Pay in May 2019 but the pieces weren’t in place for a WWDC19 rollout.

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.


UPDATES

October 22 2020: The first Japanese iOS app clip for ordering via NFC tags and QR have started at Kitasando Coffee and Tailored Cafe.

Transit Gate Evolution: tap speed matters more than ever in the COVID era

As COVID restrictions are eased and the world slowly goes back to work, school and hopefully slightly more normal life, avoiding crowds will be key in keeping COVID from becoming resurgent in the months ahead.

For commuters in Japanese metro areas avoiding crowds is no easy matter. Fortunately the Japanese transit gate infrastructure is a great help. FeliCa based IC transit cards (Suica, PASMO, ICOCA, etc.) with fast transaction speeds combined with open gate flap design maximizes people flow: people walk through gates at normal pace. This is very important for Japanese stations that have to make do with large crowds in limited spaces and smaller gate areas.

It’s wrong however, to think that this only applies to Japan. The benefits of fast tap speed combined with intelligent transit gate design are relevant everywhere and very necessary in this day and age: fast gate tap speed is essential in keeping gate crowding at a minimum. It makes things safer not only for train operation, but also addresses crowd control health concerns in the COVID era.

A reader sent a link to a good discussion of NFC protocols and gate tap speeds that was apparently deleted when YouTube comments were turned off. I retyped the comment in the section below from a screenshot with some light editing for clarity. If I find the author I will link to the original. The videos have already appeared in other posts but it’s good have them in one place. A previous installment already covered QR transit code gate issues, this post will focus on NFC tap speeds.


While transit gates and NFC processors are found worldwide, what makes the Japanese gates different from the rest of the world is they don’t use global standard ISO 14443 (never mind Type A which uses Miller bit coding, the least efficient bit coding method) protocol which is common in many transit and bank cards issued worldwide.

The tap time with ISO 14443 Type A (née Philips) and B (née Motorola) varies greatly: from 200 to 500 milliseconds (ms) with 200 ms only achievable with Type B/Calypso. But it never reaches the short as 100 ms which is only achieved with Felica developed by Sony, also designated NFC-F and NFC Tag Type 3 by the NFC Forum and compatible with ISO 18092 which is commonly found in smartphones and NFC wearables since 2013. In this following video passengers maintain their walking pace but never overshoot and trigger a gate closure nor slow down not even a bit:

It may seem like a minor difference but due to the high volume of passengers per gate and to reduce gate maintenance requirements, tap times really matter.

Companies such as JR East have specified tap time of 200 ms but Suica is actually faster and this allows real life speed tolerances: some passengers tap faster than others due to walking pace, the higher speed tolerances are only possible with the 100 ms tap time of FeliCa. A comparison example of large crowds at gates in Malaysia and Japan below:

Open Loop NFC ticketing in its current form is based on EMVCo Contactless specifications adopted in contactless bank cards issued worldwide including China UnionPay QuickPass which is PBOC derived from the EMVCo Contactless spec. All of these use ISO 14443 Type A at 106 kbps only for 500 ms tap time, which is adopted in cities worldwide such as London, New York, Moscow and Rio de Janeiro where normal walking speed is never supported.

But as seen here, transit cards in Japan such as Suica, PASMO and ICOCA are supported for ultra hight speed and precise account verification and fare processing. Transit cards use offline Stored Fare (SF) which includes the amount of funds stored in the card’s IC smart chip data storage, NOT backend on a server like a bank card, and stored commuter passes. Here are walk flow comparisons for Tokyo and London, and MTA OMNY Open Loop performance:

Japanese IT journalist Junya Suzuki tests OMNY transit gate speed…
and reliability

One hopes the NFC Forum works to increase NFC speeds and global specifications to “improve the overall user experience for NFC users.” Improving the NFC user experience is what it is all about. With the addition of Ultra Wideband to Mobile FeliCa and Mobile MIFARE now is the time for the NFC Forum partners to revisit the global NFC ISO 14443 and ISO 18092 specifications.

EMV is payment technology created for leisurely supermarket checkout, not whizzing through transit gates at rush hour. It doesn’t address the needs of transit and never will in it’s current format because it is controlled by credit card companies. NFC Forum partners need create a single faster more reliable NFC standard encompassing NFC A-B-F and other wireless technologies, a new standard that improves and expands the NFC user experience on mobile devices for digital transit, digital keys and payments, while making it all future-proof.

Related
Transit Gate Evolution: Do QR Codes Suck for Transit?

Octopus is Out of Time

Is this the last time? Just a few thoughts as iOS 13.5 closes in on what hopefully will be a late May delivery, also rumored to be the launch iOS for Apple Pay Octopus. Recent beta test feedback says the minimal system for using Apple Pay Octopus was raised from iOS 13.2 to iOS 13.4.5 (rebranded by Apple to iOS 13.5). Also a new Schedule of Fees and Guidelines is due May 20. The Hong Kong Economic Times eZone site has taken this to mean that both iOS 13.5 and Apple Pay Octopus will launch on the May 20 Octopus Fees and Guideline update day.

The enthusiasm is understandable, but a similar situation happened in December with no launch. In short, hope for the best but don’t get your hopes up. We’ve been down this road before, but time is running out. If Apple Pay Octopus doesn’t launch in the iOS 13.5 timeframe, it’s not launching at all.

There aren’t any technical reasons for the delay; after all the Smart Octopus mobile service on Samsung Pay has been operating since December 2017 with Mobile SIM service before that. I believe it’s a result of the pressure politics facing Hong Kong, pressures both economic and governmental.

Out of Time Octopus
Octopus was the world’s first transit platform business that extended the transit smartcard to include payments and many other services but Octopus Cards Limited (OCL) has been slow extending the service to include mobile. Instead of putting early effort into digital wallet support for Apple Pay/Google Pay/Samsung Pay, OCL wasted time and resources developing the niche Mobile SIM product which really didn’t pan out.

This lag coupled with the rise of AliPay and WeChat Pay QR Code payment empires put enormous pressure on OCL to do something comprehensively mobile which it did with the O! ePay service in early 2019. But it’s not the only pressure: with so much traffic and business from the mainland, OCL owner MTR is looking to add QR Code Open Loop transit support (paywalled link) at some point. There is also the pressure of creating a Greater Bay Area transit card, and pressure from credit cards and banks. Every player wants a piece of the action.

Perhaps MTR gates will eventually look like the ones in Guangzhou with PBOC/FeliCa/QR Code readers supporting Octopus, China T-Union, AliPay/WeChat Pay, perhaps even EMV contactless bank cards:

At which point I say OCL doesn’t have a viable transit platform business anymore. Mainland China dumped the MIFARE based Beijing and Shanghai card architecture for their own slower PBOC 2.3/3.0 China T-Union standard, I don’t think it’s a stretch to see the same thing happening to Hong Kong Octopus at some point.

Supporters will undoubtably point out the technical merits of China using a single transit standard but that’s just a red herring. Smart devices and digital wallets handle all protocols and will continue to incorporate new technologies. The deciding factors will be good old money and politics: is it more profitable to keep Octopus in place or junk it in favor of QR and China T-Union, and who benefits from it all?

Octopus is living on borrowed time. If it doesn’t aggressively expand services on digital wallet platforms, it doesn’t have a future. Apple Pay Suica turned things around for Suica, let’s hope the Apple Pay Octopus launch can do the same for Octopus.


Apple Pay Suica had a huge impact on Mobile Suica use
Modern digital wallets like Apple Pay seamlessly support multiple payment technology protocols

UPDATE: on May 18 at 4:30 PM, an Octopus system glitch temporarily showed an option to add Apple Pay Octopus cards to Wallet to some iOS Octopus app users, but the feature not functional on the Apple Pay Wallet end. The glitch was quickly fixed but this is a sign that a service launch is imminent post glitch rumors say June 2. (Edit: June 2 did turn out to be Apple Pay Octopus launch day)

Transit Platform Basics

I have attempted to explain the unique Japanese ‘transit platform’ business model in many posts scattered over 3 years. It’s a model that didn’t exist outside of Japan for a long time because Japan was the first country to move beyond plastic cards and launch them on mobile devices in 2006. There are transit systems that are close to what the Japanese transit platform does, Hong Kong Octopus in particular, but none that combine the elements of private enterprise transit, a mobile platform and a nationwide footprint.

A reader asked some very good questions regarding JR East Transit Platform model basics and how they compare to Open Loop. I’ll try to summarize the essential points.

1) Thinking about this recently – is there a non-techie argument for introducing Suica-type cards in the current day in places with preexisting open-loop infrastructure, wide debit card adoption (even kids), and little overcrowding at ticket gates due to lower volumes?

2) As a tech & transit nerd, I obviously love them, but what could be a convincing, economically sound pitch to a transit operator for creating/adopting an integrated transit&e-money system, given the significant expense and questionable added value?

3) Answers to possible q’s about EMV contactless: 1. 定期券 (commuter passes) & discounts can be tied to card no.; 2. solution for visitors: in-app/paper/multi-trip tickets (like in SG). Obv., Suica has superior privacy & speed, but where speed is not an issue, what’s the killer argument?

My response:

Simple choice: moving people quickly and safely by transit, managed wisely, is a license to make money. A transit company can use that license to build something of greater long term value for the users and businesses of the transit region, a win-win, or give it away to someone else.

A transit platform is the best approach if a company wants to achieve the former. Investing everything in Open Loop as the only strategy is the latter.

Any argument for building a Transit Platform or going all in with Open Loop transit comes down to transit company priorities for safe operation, better customer service and long term business goals. A few crucial points to consider.

Who owns the customer?
A vital point many people miss in the Open Loop debate is that transit users end up as the bank card customer, not the transit company customer. This might seem like an insignificant difference but ‘owning the customer’ is the whole game and key to growing any kind of business, in our era or any era. Which brings us to the next point because one of the best ways to own the transit customer and build a business far beyond simple fare collection is a transit card.

Transit Cards: bank account without the bank
Prepaid transit cards are a delivery vehicle for all kinds of service goodies, a mini non-bank account if you will, from transit to points rewards and a growing portfolio of services. The beauty of a non-bank transit prepaid card is its flexibility and security. It can be a simple ticket that customers buy with cash from a station kiosk, or it can be linked to an online account for extended transit services and users can further extend it by attaching a credit card and earn reward points.

eMoney for all kinds of payments
The important transformation here is evolving the card beyond transit fares to eMoney payments that can be used throughout the transit region, pioneered by Suica and Octopus. One benefit not discussed much in the open is that by encouraging heavy use and ‘recharge’ of the transit/eMoney card, the transit company earns interest on the ‘float’, the combined total of all those unused prepaid balances sitting in all of those transit cards in the system. The next transformative step is mobile, which is key.

Digital Wallets: extending the reach
The most powerful transit card incarnation is the digital wallet transit card with a flexible recharge backend, where any bank card can attached in an app, or on the fly (Apple Pay, Google Pay, etc.), or even cash recharge at stations, convenience stores and such. Once the transit card goes mobile it can extend beyond the restraints of plastic card technology. It can also have a flexible front-end that can be NFC, UWB Touchless or even QR. My basic position regarding open loop bank cards for transit is that doing so eliminates these options for the transit company. I say it’s better for the transit operator to decide what payment technology works best for their needs and how to deliver better customer service with new payment technologies, not banks.

Value Capture
Value Capture applies to rail and transit operators with the rights to develop the land around their stations, I include station retail development and operations. Owning a transit + payment card like Suica or Octopus combined with retail opens up a whole new levels of value creation and capture.

It’s also important to remember a few other dynamics, (1) Transit is the golden uptake path for contactless payments, (2) Contactless payments are most successful when a transit payment platform, like Suica, is matched with a mobile wallet platform, like Apple Pay. The key is building better payment services tied to transit platform cards that benefit customers and businesses of the entire transit region.

The limitations of Open Loop EMV cards
Regarding detailed questions such as attaching commuter passes to EMV cards and special ticketing, I am no systems expert but a few things come to mind. First of all we have not seen Open Loop commuter passes because the EMV spec doesn’t store anything locally and there are always security and performance issues to consider when everything is done in the cloud with soft-linked registration to system outside numbers.

The classic catch 22 here is that when the soft-linked number changes on one system, everything attached to it on the other system stops working. This is a constant weakness of the SmartEx and new JR East Shinkansen eTicket service. And what happens if the bank cancels a card mid-transit? These things happen. They are endless headaches when linking to any outside system, for this reason Open Loop sticks with the simple stuff while transit operators keep the more complex stuff in-house. In general the more complicated the fare configuration, the less likely it can be synced with an outside system or be hosted on Open Loop.

Paper ticketing and NFC passes
For low volume specialty ticketing, QR codes are the easiest step up from mag strip paper and QR can be printed on ordinary paper for transit users without smartphones. This is why JR East is deploying QR code readers in some gates as they prepare to end mag strip ticketing.

NFC Contactless Passes might sound like a good idea but Apple Pay VAS and Google Pay Smart Tap were designed for retail and are far too slow for transit use. The transit gate reader system has to juggle different protocols. It could be done, but from my experience of using Apple Pay VAS PONTA and dPOINT cards the technology hold promise but the current version isn’t there yet. QR Codes are faster and easier to implement.

Summary
In the long run there are no easy solutions which demands a clearly defined strong but flexible business vision. The risk of Open Loop is that it is sold as a general easy ‘fix all’ and mobile solution, which it’s not. This lulls transit operators into complacency instead of improving Closed Loop ticketing systems and extending them to the mobile digital wallets. The bigger and more complex the transit system, the less Open Loop can accomplish.

Relevant Core Posts
The Contactless Payment Turf Wars: Transit Platforms (an intro)
Transit Gate Evolution: Do QR Codes Really Suck for Transit? (a deeper dive into transit cards, gates and technology)
Value Capture and the Ecosystem of Transit Platforms (the bigger picture)
The Japanese Transit Platform Business Model (an outside perspective)

iOS 14 Apple Pay: going the distance with Ultra Wideband Touchless and QR (Updated)

It’s that time of year again to look into the WWDC crystal ball and see what changes might be in store for Apple Pay. 2019 was an exciting year with the important Core NFC Read-Write additions for ISO 7816, ISO 15693, FeliCa, and MIFARE tags. Since then we’ve seen iOS apps add support for contactless passports, drivers licenses, retail and manufacturer vicinity NFC tags, transit ticketing, badging, and more. Some expectations ended up on the cutting room floor. The NFC tag Apple Pay feature that Jennifer Bailey showed back in May 2019 has yet to appear. Apple Pay Ventra and Octopus transit services slated for 2019 and iOS 13 failed to launch. Apple Pay Octopus launched June 2, Apple Pay Ventra has yet to appear.

Predicting anything in 2020 is risky business because of COVID. iPhone 12 might be delayed, iOS 14 might be delayed, features brought forward, pushed back…all plans are up in the air. Some developments are clear, but timing is opaque. What follows is based on: (1) NTT Docomo announcement of Ultra Wideband (UWB) ‘Touchless’ Mobile FeliCa additions and JR East developing UWB Touchless transit gates, (2) CarKey and the Car Connectivity Consortium Digital Key 3.0 spec, and (3) Mac 9to5 reports of AliPay coming to iOS 14 Apple Pay.

Going the distance with Ultra Wideband
The NFC standard has been around a long time, long before smartphones, conceived when everything was built around close proximity read write physical IC cards. The standards have served us very well. So why are NTT Docomo and Sony (Mobile FeliCa) and NXP (MIFARE) adding Ultra Wideband + Bluetooth into the mix?

UWB + Bluetooth delivers Touchless: a hands-free keep-smartphone-in-pocket experience for unlocking a car door, walking through a transit gate or paying for takeout while sitting in the drive thru. It’s the same combo that powers Apple AirTags. UWB Touchless delivers distance with accuracy doing away with “you’re holding it wrong” close proximity hit areas necessary when using NFC. With Touchless your iPhone is essentially a big AirTag to the reader,

For Apple Pay Wallet cards it means hands free Express Card door access, Suica Express transit gate access and payments that ‘just work’ by walking up to a scan area or car. As Junya Suzuki pointed out recently, UWB Touchless is passive vs. the active NFC ‘touch to the reader’ gesture, as such it will live on smartphones and not on plastic cards. Those will remain limited to NFC which does not require a battery.

Secure Element evolution and digital key sharing
The addition of UWB Touchless however means that the Secure Element, where transaction keys are kept and applets perform their magic, has to change and evolve. Up until now the Secure Element worked hand in glove with the NFC controller to make sure communications between the reader are secure and encrypted. For this reason an embedded Secure Element (eSE) usually resides on the NFC controller chip.

Apple chose to put a Global Platform certified Apple Pay eSE in their own A/S series chips. The arrangement gives Apple more control and flexibility, such as the ability to update Secure Element applets and implement features like global NFC. The addition of UWB Touchless in FeliCa and MIFARE means both smartphone and readers need new hardware and software. Apple already has UWB in the U1 chip on iPhone 11. Mobile FeliCa software support could be coming with the next generation ‘Super Suica’ release in the spring of 2021 that requires an updated FeliCa OS.

Recent screen images of a CarKey card in Wallet…with Express Mode can we call it Suicar?

The arrival of UWB Touchless signals another change in the Secure Element as shown in middle CarKey screen image: digital key sharing via the cloud where the master key on the smartphone devices ‘blesses’ and revokes shared keys. Mobile FeliCa Digital key sharing with FeliCa cards and devices was demonstrated at the Docomo Open House in January, also outlined in the Car Connectivity Consortium (CCR) Digital Key White Paper. An interesting aspect of the CCR Digital Key architecture is the platform neutrality, any Secure Element provider (FeliCa, MIFARE, etc.) can plug into it. Calypso could join the party but I don’t see EMV moving to add UWB Touchless because it requires a battery. EMV will probably stick with battery free NFC and plastic cards.

Diagram from Car Connectivity Consortium (CCR) Digital Key White Paper

QR Code Payment Cards
There is another possible eSE transition for Apple Pay. If the 9to5 Mac AliPay for Apple Pay iOS 14 rumor is true, it represents a huge change for Apple Pay which has strictly limited payment transactions to NFC. The whole identity of Apple Pay is NFC payment cards vs. Wallet which can hold both cards (NFC) and passes (NFC or QR/Barcodes).

A few weeks ago a reader asked for some thoughts regarding the AliPay on iOS 14 Apple Pay rumor with a link to some screen/mockup images on the LIHKG site. Before getting to that it’s helpful to review some key Apple Pay Wallet features for payment cards:

  • Direct side button Wallet activation with automatic Face/Touch ID authentication and payment at the reader.
  • Device transactions handled by the eSE without a network connection.
  • Ability to set a default main card for Apple Pay use.

The images suggest a scenario for implementing AliPay in iOS 14 Apple Pay:

  • AliPay has a PassKit API method to add a ‘QR Card’ to Wallet.
  • Apple Pay Wallet QR Card set as the main card is directly activated with a button double-click for Face or a Touch ID authentication and dynamic QR Code payment generation in Apple Pay.
  • Direct static QR Code reads activate Apple Pay AliPay payment.

If Apple is adding AliPay to the ranks of top tier Wallet payment cards, they have to provide a way in. The new “PKSecureElementPass” PassKit framework addition in iOS 13.4 could be just that. Instead of PassKit NFC Certificates, the additions suggest a Secure Element Pass/certificate. Secure Element Certificates instead of NFC Certificates, or better yet completely decouple the Secure Element from NFC so that there are 2 kinds of certificates: a Secure Element Pass for Secure Element transactions, and a NFC Certificate ‘lite’ for non-Secure Element NFC use such as VAS passes which pull everything off a JSON server. In the long run Apple needs to provide finer definitions and controls for NFC and UWB access instead of one black box that PassKit NFC Certificates have been up to now.

One possible scenario for PassKit NFC Certificate evolution

The burning question here is: have Apple and AliPay developed Secure Element technology and Java Card applets for encrypted transactions that work without network connections? If so QR Wallet payment ‘cards’ are possible. Direct Apple Pay Wallet QR integration with would open up things for 3rd party (non bank) payment players. QR integration with separate access controls for the Secure Element and NFC/UWB hardware frontend might also help Apple skirt NFC monopoly allegations that got Apple Pay in trouble in Europe.

Dual Mode and flexible front ends
The addition of QR and UWB with NFC for payments opens up a long term possibility suggested by Toyota Wallet. The current app lets the user attach a QR code app payment method and/or a NFC Wallet payment method to an account. It’s intriguing but clunky. Wallet QR Payment support would allow Toyota Wallet to move the entire payment front end to Wallet and let the user choose to add one or both.

It’s the latter that interests me most. Instead of having separate NFC and QR payment ‘cards’ from the same issuer for the same account, I’d much rather have one adaptive Wallet card that smartly uses the appropriate protocol, QR, NFC, UWB for the payment at hand.

Ultimately I don’t believe that payment players need or want to anchor their services to specific technologies like QR or even NFC. AliPay may have needed QR to start their payment business empire, why not offer NFC and UWB if it’s there as a front end choice? It’s all virtual.

Capable, flexible, smart. This is what digital wallets should do, things that plastic can never achieve. Let’s hope Apple Pay Wallet makes it there someday, and that payment and transit providers are up to the mix and match challenge in the Touchless era.


WWDC20 UPDATE

CarKey
Apple announced CarKey, digital car keys and Ultra Wideband Touchless in the WWDC20 Keynote and accompanying press release:

Digital car keys give users a secure way to use iPhone or Apple Watch to unlock and start their car. Digital car keys can be easily shared using Messages, or disabled through iCloud if a device is lost, and are available starting this year through NFC. Apple also unveiled the next generation of digital car keys based on Ultra Wideband technology for spatial awareness delivered through the U1 chip, which will allow users to unlock future car models without removing their iPhone from their pocket or bag, and will become available next year.

Apple Newsroom

More details were revealed the CarKey session:

One thing the CarKey session made clear is that Secure Element ‘radio technologies’ are evolving beyond NFC. Another interesting aspect of CarKey is the device requirement: iPhone XR/XS or later, Apple Watch Series 5 or later.

A12 devices and later makes perfect sense because they all support Express Cards with power reserve. Apple Watch does not support this feature but the Series 5 and later requirement suggests the S series chip is getting very close and likely involves Secure Element digital key sharing. We may see Express Cards with power reserve arrive with Apple Watch Series 6.

App Clips
App Clips finally unleash the power of background NFC tag reading and is the other big Apple Pay development announced at WWDC20. This is what Jennifer Bailey talked about last year just before WWDC19 but it took another year to come together.

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 sheet pop-ups. This will be huge. See the separate post for details.

Apple Pay Code Payments
AliPay QR Code support was not mentioned in the WWDC20 keynote or sessions but there are Apple Pay code payment references in iOS 14 beta 2, code name Aquaman. There is also a iOS 14 PassKit alipay payment network reference and other new PassKit framework additions for code payments. The closer we get to the iOS 14 official release, the more I’m convinced that Apple Pay Code Payments are more of a App Clip thing because App Clips have the potential to deliver a much better user experience than Apple Pay Code Payment can just by itself.