Access
Get the engine. It is free, and it is licensed rather than open.
Register an application and a licence and a key are issued against it, straight away, with no approval step and no charge. There is no paid tier above it — what you register for is the whole engine. What registration establishes is the licence itself: an application we have issued one against, and an address we can reach you at.
A PressboardKit licence
The whole engine. Not a cut-down build, not a trial on a timer, and not the free half of something: there is one engine and a licence covers all of it — every module, every language, every behaviour property.
What you get
- The complete engine: rendering, layouts, callouts, autocorrect, prediction, slide-to-type
- All 73 languages — layout tables and long-press callouts; 53 of them resolve to one of the 39 bundled word-frequency lists
- All 51 behaviour properties, every one of them switchable
- The optional autocomplete and emoji modules
- The demo app: a standalone Xcode project with a real keyboard extension
- Integration guide, behaviour reference and changelog
How you get it
- Register with an email address, and name the application — its product name and bundle identifier.
- We issue a licence and a key straight away. There is no approval step and no charge.
- Add the Swift package to your app and its keyboard extension and start typing.
The build you have today does not check anything: the engine carries a licensing seam whose default unlocks every feature, and no part of the package talks to a server. When validation does ship, the licence terms say what it does — the keyboard extension verifies a signature offline and never opens a connection, and every way it can fail leaves the keyboard typing.
Request a licence →What a licence covers
One engine, one licence, no charge. The second column is what an unregistered application gets once the SDK validates licences — which no shipped build does yet.
| Feature | RegisteredFree | Not registeredOnce validation ships |
|---|---|---|
| The engine | ||
| Native-parity rendering, callouts and key-popThe system keyboard's own look, measured rather than approximated, light and dark | Included | Rendering and layout only |
| All 73 localesLayout tables, long-press callouts, domain-key TLDs; 53 of them resolve to one of the 39 bundled word-frequency lists | Included | English |
| All 51 behaviour propertiesEvery behaviour switchable, native by default | Included | Native defaults |
| Autocorrect, next-word prediction, slide-to-type | Included | Not included |
| Autocomplete and emoji modulesSeparate SPM products, so an app that does not use them does not link them | Included | Not included |
| The keyboard still typesThe floor, and there is nothing below it. No licence, an expired one, a signature that does not verify, or a service of ours being down — every one of them leaves a working keyboard | Always | Always |
| Feature-gated buildThere is one engine; nothing is compiled differently for anybody | None | None |
| Licence | ||
| Price | Free | — |
| RegistrationBy email today — the dashboard that replaces it is being built | Required | — |
| Bound toOne licence per application, named by product name and bundle identifier | Your application | — |
| Validated by the SDK at setupThe way KeyboardKit does it. Not shipped yet: the licensing seam currently unlocks everything | Signature, verified offline | — |
| What leaves your appThe licence key and the bundle identifier, from the containing app. No typed text, no keystrokes, no device or installation identifier — and the keyboard extension opens no connection at all | Licence key and bundle id | Nothing |
| How it is deliveredA Swift package you can read and step through today. A signed binary framework is the intention, so treat source access as the current arrangement rather than a term of the licence | Swift package | — |
| Right to modify and ship a forkFree is not open. Ask if you need it and we will answer in writing | Not offered | — |
| Support | ||
| Integration guide, behaviour reference, changelog | Included | Public |
| Email support | Best effort | Not offered |
| Response timesNo service level, and we would rather say so than publish a number we cannot hold to | No commitment | — |
| Roadmap inputParity work and new locales get prioritised against what people actually ship | Feedback welcome | — |
Shipping this in a product
If a keyboard is going into something your company ships, the licence costs nothing but the questions around it are not trivial: what your procurement needs in writing, which languages you need, and what parity work matters to you. The roadmap is ours to set, but what gets done first is worth arguing about.
Tell us what you are building and we will answer for your case.
Questions
Answered where there is an answer, and marked as open where there is not.
- How do I register?
By email, for now. You write to us, tell us the application — its product name and bundle identifier — and we issue a licence and a key. There is no approval step. A dashboard that does this without the email is being built; until it exists we would rather say so than draw a button that pretends otherwise.
Request a licence →- What does it cost?
Nothing. There is no charge for a licence, no tier above it, and no capability held back for one — an application with a licence gets the whole engine. What the licence terms reserve is the right to change them on at least three months’ written notice to your registration address, which is the ordinary shape of a licence rather than a hint about anything.
Read the licence →- Is it open source, then?
No. Free and open are different things, and this is the first one only. What you receive today is a Swift package rather than a compiled framework, so you can read it, step through it in a debugger and see exactly what it does inside your extension — but you receive it under a licence we issue to you, not under an open-source licence. Do not plan around that format: a signed binary framework is the intention, because a licence that has to be honoured cannot live in source the licensee can edit.
Read the licence →- Why do I have to register at all, if it is free?
Because a licence is a relationship with terms, and terms need somewhere to be served. Every notice in the licence — a change to it, anything that would affect an application you have already published — goes to the address you register with. Registering also binds the licence to one application, which is what makes it ours to enforce rather than a file anybody can copy.
Read the licence →- Does the keyboard talk to a server?
The keyboard extension does not, and cannot — it contains no networking code. When validation ships, your containing app exchanges its licence key for a signed licence lease and stores it where the extension can read it; the extension verifies that signature offline. What leaves your application is the licence key and the bundle identifier. No text your users type, no keystrokes, no device identifier and no identifier of an individual installation are sent to us by any part of the engine, ever.
See how integration works →- Is licence validation enforced today?
No. The engine carries a licensing seam that has been there since the first commit, and its default unlocks every feature; there is no licence-key API to call and no check at setup. The licence says the terms of validation before a build that validates ships — you will not meet it for the first time in a release note.
Read the licence →- Will an app I ship today keep working?
Yes, and it is written into the licence rather than promised here: an application you have already published goes on working. If the terms ever change in a way you do not accept, what continues is the free tier — English, native rendering, no autocorrect — in published applications and new builds alike, and we will not ask you to withdraw anything. Nothing stops mid-sentence on someone’s phone: a lease is granted for a period rather than per launch, it fails open when it cannot be reached, and it closes only on an expiry it has actually seen.
Read the licence →- What are the technical requirements?
iOS 26 or newer, Swift 6, Swift Package Manager. Your keyboard extension links the core engine and the layout tables at minimum; autocomplete and emoji are optional products you add only if you use them, because a keyboard extension lives on a fraction of an app's memory.
Read the integration guide →- Does the engine need my app to be a particular shape?
No. Everything host-specific — theme, toolbar, word lists, suggestion source, settings storage — is injected, and the kit imports none of your code. A working keyboard extension is a subclass of the provided input view controller returning a configuration value.
See the features →
Registering is an email: hello@pressboardkit.com. The engine needs iOS 26 and Swift 6.