Haven’t done one of these in a while. This really isn’t a to do list or a wish list, just a few things Apple needs to address in future iOS / macOS versions. The sooner the better.
Apple Wallet
One of the most important recent digital wallet / embedded secure element (eSE) platform trends is the shift away from traditional security smartcard proprietary protocols like MIFARE and FeliCa in favor of public-key infrastructure (PKI) based ‘open’ PKI protocols such the CCC Digital Key standard, aka digital car keys, that came to Apple Wallet in 2020. The JPKI (Japanese Public Key Infrastructure) based My Number digital ID card came to Apple Wallet in 2025. In 2026 we have another new PKI digital key standard Aliro for home / hotel / office keys, that launched in February. Aliro has yet to arrive in locks and digital wallets but Apple and Google have committed to supporting it ‘out of the gate’.
Like the CCC standard, Aliro supports UWB for ‘touchless’ door unlocking, walk-through access barriers, etc., a big digital advantage, which bodes well for 2027 shaping up to be a big year for UWB. It’s safe to expect some UWB related Apple Wallet developments at WWDC26. Digital home keys will be the initial focus for Aliro, the low hanging fruit. Hotel and office keys are a different story; there’s a huge installed base of MIFARE and FeliCa card systems in this space so any migration will take time.
Real bottle-necks remain for digital hotel keys and the digital check-in / card issue process, solving these issues is crucial for digital hotel key expansion. In Japan specifically, verifying guest identity and collecting payment in advance remain important challenges. Recently, major hotel chains in Japan have been actively working on this area. This concept is essentially “pre-check-in”, similar to online check-in for airline tickets. Guests complete identity verification and payment in advance so that the actual check-in process becomes much smoother.
However, the challenge in Japan has been that many domestic PMS (Property Management Systems) historically did not support this concept of pre-check-in. As a result, hotels have had to build their own systems to enable it. Because of this, many hotels have spent several years implementing these capabilities. For example, Mitsui Fudosan’s recently released system had already been under development for about three years.
Another important factor is Japanese regulation. Under the Hotel Business Act, hotels are required to perform identity verification at check-in, either at the front desk or through approved digital self-check-in systems. In other words, when guests arrive at the hotel, they must complete some form of check-in procedure that corresponds to identity verification. Even if Aliro gains traction as the go-to home key and office key digital standard, real change on the digital hotel key check-in side will take time.
Apple Text Layout Architecture
This subject is more problematic. As outlined years ago, the history of Apple’s text layout architectures has been very convoluted and without any long term vision for some time now. When I ran across Artem Loenko’s post, ‘Native all the way, until you need text’, my first reaction was ‘that’s what happens without a unified vision’. Nobody at Apple seems to be asking ‘where can we take customers and developers?’ The difference in Apple Pay Wallet and text teams is striking. Loenko outlines the basic problem of using TextKit 2:
- Selection and interaction limitations: SwiftUI primitives can’t properly support selecting an entire Markdown document/message “by design.”
- Integration and compatibility issues: Switching to NSTextView (with TextKit 2) breaks SwiftUI performance/testing work and doesn’t integrate smoothly. Lower-level TextKit 2 requires manual hacks for expanding text chunks and still struggles with streaming.
- Performance and streaming: Streaming AI responses (common in 2026 chats) causes CPU spikes in native views. Scrolling can feel jumpy, and collection views have blinking issues.
- Missing features and maturity: Achieving basic native behaviors (context menus, dictionary lookup, accessibility, text interactions) takes months of work even with TextKit 2. It doesn’t “play well with anything modern.”
In short, for long-form rich text, Markdown, flexible typography, and chats, native SDKs feel immature compared to web text engines. Ultimately WebKit and Electron are surprisingly effective with better typography, Markdown, text ops, and even macOS integrations out of the box. This explains why many chat-heavy or rich-text apps use web-based text engines instead native frameworks.
So what defines ‘works out of the box’?
- Better modern integration: Seamless mixing with SwiftUI (no major performance/testing regressions), smooth streaming support without CPU spikes, and reliable dynamic content (e.g., no blinking in collections).
- Out-of-the-box rich text capabilities: Native-level support for Markdown, flexible typography, long-form selection, and advanced operations without months of custom low-level work.
- Performance parity or better: Reliable scrolling, expanding text, and handling of complex documents—matching or exceeding web/Electron ease and speed.
- Feature completeness: Full, effortless parity with expected macOS behaviors (accessibility, interactions, context menus) without fighting the framework.
- Developer-friendly for contemporary apps: Tools that treat rich text/chat/long-form content as first-class rather than edge cases.
It’s a fascinating ongoing discussion though I doubt we’ll hear anything text layout / typography / font related at WWDC. The last few years have been quiet on those fronts, I don’ think that will change. One thing is clear: traditional high end typography esthetics are more irrelevant than ever in a web text engine based world and that’s the catch. With web text everywhere good typography for non-roman languages, CJK especially, are locked into forever 2nd class status. Forget about real vertical text layout in web browsers, it will never happen.
Post WWDC26 Notes
As expected there wasn’t much new for Apple Wallet, other easier barcode pass creation and storage, more coupons and points right? Which have nothing to do with the NFC/UWB/embedded secure element side of things. There are hints of more hotel key support but few details, and of course no mention of UWB transit. Over the past few years Apple has rolled out new Wallet functions completely uncoupled from annual fall iOS releases. Tap to Pay on iPhone, My Number ID for iPhone Wallet, NFC & SE Platform have all come in later updates. Expanded Wallet support for UWB hotel keys and transit cards will be the same.
The WWDC26 TextKit story is much more interesting. Apple is listening to developer feedback about the problems using native text APIs. The Elevate your app’s text experience with TextKit video session addresses those concerns with some new TextKit APIs. I’m really lazy today so I’ll let Grok take over.
A key friction has been the choice between:
Framework text views (UITextView, NSTextView, TextEditor in SwiftUI): These provide rich built-in features (input, selection, accessibility, undo/redo, dictation, etc.) but limited customization of drawing, viewport management, or advanced behaviors.
Fully custom TextKit implementations: These offer total control over layout/rendering via NSTextLayoutManager, viewport controllers, etc., but require rebuilding many editor features from scratch, which is labor-intensive.
New TextKit APIs aim to let developers get “the best of both worlds” by extending the convenient framework text views with deeper TextKit integration for custom behaviors (e.g., line numbers in code editors, collapsible sections).
Key New APIs (e.g., NSTextViewportRenderingSurface)
NSTextViewportRenderingSurface protocol (and companion NSTextViewportRenderingSurfaceKey): This is a major highlight. It provides a common abstraction for visual elements (conformable by UIView, NSView, or CALayer) that render text layout fragments in the viewport.New delegate methods on the viewport controller let you assign, query, and track these rendering surfaces during the viewport layout process. This improves management of visible elements across layout cycles, aiding consistent custom drawing, reuse, and integration.
Other enhancements: The session covers new ways to extend text views, updated caching/reuse policies for text attachments (improving performance with custom or dynamic content), and better hooks into the TextKit architecture (storage, layout, viewport layers).
These build on TextKit 2’s viewport-based design (introduced earlier for performance with large documents) and make it easier to customize without going fully custom.
Do They Fully Address Concerns?
Strong yes for extension/customization: They reduce the “all-or-nothing” tradeoff, making advanced features like line-numbered editors or structured/collapsible text much more accessible while retaining framework perks. This directly tackles feedback about limited drawing/viewport control in standard views.
Performance and architecture: Improvements in viewport handling, attachment reuse, and rendering surface management should help with efficiency in complex or large-text scenarios.
As always it comes down to real-world adoption. Broader testing with complex international scripts, heavy customization, or integration with other frameworks will reveal more over the coming months. Will it be enough to stop the ‘use web browser text engines for everything ’cause it’s good enough text layout for most’ mentality (even though real typography on the WebKit side requires lots of customization, i.e. there’s no abstraction you have to know what you’re doing)? Probably not but it’s always a good thing when native text layout APIs up the game and give developers better choices (with the safety of abstraction).
This is the state of Apple Pay Wallet since the arrival of iOS 18.1 NFC & SE Platform. The only real change needed for 2027 is the expansion of UWB support in CCC digital car keys to include recent UWB FiRa Consortium spec developments in Mobile FeliCa, Mobile MIFARE and Aliro. This would allow UWB Express Mode use with transit cards, hotel keys, home keys, office keys and ID badges.
You must be logged in to post a comment.