Handwriting Recognition Is an API Now: PencilKit and PaperKit in iPadOS 27

Read Apple's own iPadOS 27 developer guide and something becomes obvious quite quickly: most of it isn't about the iPad. Foundation Models, App Intents, Core AI, the SwiftUI and UIKit refresh all land on iPhone and Mac in the same release. That's Apple's deliberate strategy, and it's mostly good for us.

One section is different. PencilKit and PaperKit are the part of iPadOS 27 that only makes sense on a device you hold a stylus against, and it's the part that received the least coverage.

In this post:

• What actually shipped
• The phrase that matters
• The languages point is bigger than it looks
• How do you test this?
• What else is in iPadOS 27
• My take

What Actually Shipped

Two things from Apple's iPadOS 27 guide.

PencilKit gained handwriting recognition. It now recognises handwritten text across a wide range of alphabets and languages, built on the same on-device recognition technology behind Notes and Freeform, so people can write naturally with Apple Pencil and your app can understand what they've written. Apple also notes that new APIs make it easier to integrate PencilKit into a wider variety of apps beyond traditional drawing canvases.

PaperKit is the surface underneath it. It offers a paper-like writing experience with the fluid, low-latency inking people expect from Apple Pencil on iPad.

The relevant sessions are Read between the strokes with PencilKit and Unwrap PaperKit.

That's a smaller announcement than a new framework and a considerably bigger one than it sounds, because it stops being your problem.

The Phrase That Matters: "Beyond Drawing Canvases"

Until now, PencilKit had a fairly narrow shape in most developers' heads: a canvas you put in a view when you wanted freehand drawing. If you wanted text out of handwriting, you were on your own, training or licensing a recognition model, handling the languages yourself, and accepting that your accuracy would sit some distance below the recognition Apple ships in Notes.

That gap is what closed. The recognition behind Notes and Freeform is now something you call.

Follow that through, and the interesting applications aren't drawing apps at all, since those were already served. It's the ones where handwriting was previously an input method you couldn't accept:

• A form where a field can be written into rather than typed
• Note capture that becomes searchable text without the user transcribing anything
• Annotation on a document where the marginal note is queryable
• Any workflow where a stylus is faster than a keyboard: clinical notes, site surveys, stock counts, lab records

That last category is where I'd expect this to matter commercially. There's a lot of enterprise iPad deployment in contexts where people are standing up, wearing gloves, or moving between locations, and where typing is genuinely worse than writing. Those apps have been either accepting images of handwriting, unsearchable and unprocessable, or paying for third-party recognition.

The Languages Point Is Bigger Than It Looks

"A wide range of alphabets and languages" is the sort of phrase that slides past on a slide, and it's doing a lot of work.

Handwriting recognition is one of the hardest problems to scale across writing systems. Latin-script cursive is a different problem from Arabic, which is different again from Devanagari, Bengali or Chinese: different stroke orders, different segmentation, different ligature behaviour, different relationships between what's written and what's meant. Building your own recogniser that works across them isn't a feature. It's a research programme.

Inheriting Apple's means a small team can ship handwriting input for users whose scripts they can't personally read. That's a genuine accessibility and internationalisation win, and it's the kind that usually only large companies could afford.

It also raises the obvious question, which Apple's guide doesn't answer: which alphabets and languages, and how well each performs. That's the first thing I'd want to establish before promising anything to users. Apple ships this in Notes, so you can get a rough answer today by writing in the languages you care about and seeing what comes back. But confirm the supported list in the documentation for the SDK you're building against rather than assuming parity with Notes.

How Do You Test Handwriting Recognition?

Here's the part that will actually consume your time, and it's the same shape as a problem I've written about elsewhere.

You cannot unit test this. No assertion expresses "recognises my handwriting correctly." Recognition quality is a distribution, not a boolean. It depends on the writer, the script, how fast they wrote, whether they were resting their hand, whether they write in a hurry or carefully. Two people writing the same word produce different inputs, and one of them will be recognised better than the other.

That puts it in the same category as the object tracking I looked at in visionOS 27: a feature whose correctness a build agent can't establish, because the input is a physical human act. Your CI can verify that the API is called, that the result is handled, that an empty result doesn't crash you. It cannot verify that the thing works.

What you can actually do:

Build a corpus early. Collect handwriting samples from real people, ideally across the scripts and the demographics you serve, before you commit to the feature. Store them as recorded stroke data rather than images, so you can replay them as input rather than eyeballing screenshots. This is the single highest-value thing on the list and the one most likely to be skipped, because it looks like admin rather than engineering.

Test the failure path harder than the success path. Your app will receive wrong text. Not occasionally, but routinely, for some users, permanently. The interesting design question isn't accuracy. It's what your interface does when recognition is wrong: how visible the correction affordance is, whether the original strokes are preserved so the user can see what they actually wrote, whether a wrong recognition can be undone without redoing the input. Most of the user experience lives here, and none of it depends on the recogniser.

Watch out for the accuracy trap in your own testing. You will test this with your own handwriting, constantly, for weeks. Your handwriting will become the handwriting the feature is tuned for, and you will lose the ability to judge how it performs for anyone else. Get it in front of other people early and repeatedly.

Don't let recognition be load-bearing without a fallback. If a workflow can only be completed by writing, and recognition fails for a particular user, they're stuck. Keyboard input should always remain available.

Apple did ship something relevant to the broader problem this year: the new Evaluations framework, which they describe as a way to verify that AI features behave correctly across dynamic conditions, going beyond what unit tests alone can catch. That framing targets Foundation Models rather than PencilKit specifically, but the underlying admission is the interesting part. Apple is acknowledging that probabilistic features need a different verification model from deterministic ones. That's the right acknowledgement, and it applies here too.

What Else Is in iPadOS 27, Honestly

Worth being straight about the rest, because much coverage presents shared platform features as iPad news.

Foundation Models is the big one, and it's cross-platform. You can now work with any language model: Apple's own, cloud models like Claude and Gemini, or any provider conforming to the LanguageModel protocol. Multimodal prompts let you pass images alongside text; Vision framework tools like OCR and barcode reading are callable by the model directly and on-device; and Dynamic Profiles let you swap models, tools, and instructions within a continuous session.

One genuinely notable commercial detail: if you're in the App Store Small Business Program with fewer than two million total first-time downloads, you get access to the next generation of Apple Foundation Models on Private Cloud Compute at no cloud API cost. That's a meaningful subsidy for small developers, and it's had far less attention than it deserves.

App Intents continues expanding. Entity schemas contribute your content to the Spotlight semantic index, and the new View Annotations API maps views to entities so people can reference what's on screen conversationally. I've written separately about testing that integration.

Core AI is a new framework for running your own models on-device, with a memory-safe Swift API, automatic hardware specialisation and ahead-of-time compilation.

UIKit adds new layouts that adapt for iPhone Mirroring, which is the closest thing here to an adaptive-layout story.

All useful. None of it is iPad-specific.

My Take

The most iPad-ish thing Apple shipped this year got the least attention, and that's a recurring pattern worth noticing. Coverage follows the keynote, the keynote follows the AI narrative, and a genuinely differentiating platform capability lands in a guide section below the fold. If you build for iPad specifically, rather than shipping an iPhone app that runs bigger, the Pencil is your platform's actual advantage, and it just got a substantial upgrade.

Handwriting is having a slightly unexpected moment, and I don't think it's nostalgia. There's a real body of thinking about handwriting and cognition, and separately, a lot of people have simply noticed they think differently with a pen. What changed technically is that the transcription tax disappeared: writing by hand no longer means the output is trapped as an image. That's the actual unlock, and it makes handwriting a first-class input rather than a lossy one.

The testing problem is why you should start now rather than when you ship. A feature you cannot verify automatically is one whose quality depends entirely on how deliberately you gather evidence. Collecting handwriting samples across scripts and writing styles takes calendar time, because you have to actually find people, and it's the thing that determines whether you discover a problem in testing or in reviews. If you're planning to adopt this, start collecting before you start building.

And the honest constraint: this is only worth anything if your users have an Apple Pencil. That's a smaller population than "iPad users," and it's worth checking your own analytics before building a workflow around it rather than assuming. Where it fits, it fits extremely well. Where it doesn't, no amount of recognition accuracy helps.

FAQ

What's new in PencilKit in iPadOS 27?
It now recognises handwritten text across a wide range of alphabets and languages, using the same on-device recognition technology behind Notes and Freeform, plus new APIs for integrating PencilKit beyond traditional drawing canvases.

What is PaperKit?
A framework offering a paper-like writing surface with the fluid, low-latency inking experience people expect from Apple Pencil on iPad.

Which languages are supported?
Apple describes it as supporting a wide range of alphabets and languages but doesn't publish a list in the guide. Check the documentation for the SDK you're building against before promising specific language support.

Does recognition happen on device?
Yes. It's built on Apple's on-device recognition technology, the same used by Notes and Freeform.

Can I test handwriting recognition automatically?
Not meaningfully. You can test that your code handles results and empty results correctly, but recognition quality depends on real human input. Build a corpus of recorded stroke samples from real writers instead.

Is the rest of iPadOS 27 iPad-specific?
Mostly not. Foundation Models, App Intents, Core AI and the SwiftUI and UIKit updates all arrive across Apple's platforms in the same release.