A digital waiver app is two small problems: catching the signature, and keeping the signed form.
A digital waiver app shows your form, captures a signature drawn with a finger on the screen, and keeps the signed copy somewhere you can still find it in two years. The catching part is the easy half. Apple ships a framework for it, PencilKit, whose own summary is capturing touch and Apple Pencil input as a drawing. The keeping part is where the review rules land, because the second that signed form leaves the device it is personal data you collected, and Apple's rules on collection apply in full. Every guideline number and every quote below comes from Apple's own documentation, read on 14 October 2026. The form rarely stands alone, which is why this question usually arrives from someone already using a booking app builder.
What follows is how the signature gets onto the screen, what you store the moment it is signed, and the handful of guidelines App Review applies to the record you keep. Then the rule Apple does not publish. The review guidelines never use the word signature, so nothing in them tells you whether yours counts for anything.
Start hereThe short version
What does a digital waiver app actually have to do?
Three things, in this order. Show the current version of the waiver text, in a form a person can read on a phone. Capture that they agreed, in a way you can reproduce later. Store the record with the time, the name they gave, and the exact text they saw. Most people build the second one first and never finish the third, which is the wrong way round, because the third is the only part that has any value the day somebody disputes it.
A drawn squiggle on its own proves very little. It is a picture. What gives a waiver weight months later is everything around it: the version of the text, the timestamp, the device, the booking it attaches to. Design the record first and the signature screen becomes a twenty minute job. Design the signature screen first and you end up with a folder of unlabelled images.
The good news for a small shop is that none of this needs a server on day one. The same local first starting point that makes a loyalty card app straightforward works for waivers too, right up to the moment you want the signed copy on a second device or in an inbox. That is the moment the rules in the fourth section switch on.
How do you capture a signature on a phone?
On Apple platforms there is a framework for exactly this, and it has been there since iOS 13. PencilKit's own one line description is capturing touch and Apple Pencil input as a drawing, and displaying that content from your app. Apple lists it as available on iOS 13.0, iPadOS 13.0, Mac Catalyst 13.0, macOS 10.15 and visionOS 1.0. The view you put on the screen is PKCanvasView, which Apple describes as a view that captures Apple Pencil input and displays the rendered results in an iOS app. Its overview is blunter and more useful: the canvas view handles all of the touch events and data coming from Apple Pencil, and renders that information using the tool you specify.
Two details in that documentation decide whether your waiver screen works for a real customer. The first is drawingPolicy, the property Apple describes as the policy that controls the types of touches allowed when drawing on the canvas. It has three cases: default, anyInput and pencilOnly. Nobody signing a waiver at a gym counter has an Apple Pencil, so pencilOnly is the wrong answer, and Apple does not say what default resolves to in practice. Set anyInput and stop guessing. The older property for this, allowsFingerDrawing, is marked deprecated, so do not copy it out of an old sample.
The second detail is that PKCanvasView is a scroll view. Apple says so, and explains that users scroll around the canvas with a two finger pan gesture, or with one finger when finger drawing is off. For a note taking app that is the point. For a signature box it is a bug waiting to happen, because the customer's palm will move the canvas while they sign. Fix the content size to the box, turn scrolling off, and keep the box wide and short the way a paper signature line is. The matching thing to skip is PKToolPicker, which Apple describes as a tool palette that displays a selection of drawing tools and colors for tools that a person can choose from. Nobody signing a waiver needs to pick an ink colour. Choose one PKInkingTool and never show the palette.
If your app is React Native, as a generated app will be, PencilKit is reachable only through a native module, and it only exists on Apple platforms. There is no Android equivalent, so a cross platform waiver screen usually does the simpler thing instead: the view reports touch coordinates as the finger moves, you collect the points into a path, and you draw that path. One code path, both platforms, no native work. You give up PencilKit's stroke model and its ink rendering, which for a signature nobody will frame is a fair trade. If the app is an iPad that lives on a counter and never ships to Android, write the native module and use the real thing.
Apple, PencilKit developer documentation, read 14 October 2026
Check yours
Which rule your waiver screen runs into
Tick what your app does with the signed form. The guideline numbers and the wording come from Apple's own review guidelines.
Nothing ticked. A waiver that is drawn, rendered and kept on one device sits outside Apple's collection rules, and outside any backup you have.
What do you store once the form is signed?
Apple answers half of this for you. The canvas hands back a PKDrawing, which Apple describes as a structure representing the drawing information captured by a canvas view. The overview says what to do with it: you use drawing objects to store the data associated with your user's drawings, you can save this data with the rest of your app's content, you can use that saved data to create a new drawing object later, and you can also generate an image based on the drawn content. That is three documented moves. dataRepresentation hands you the data. The initializer that takes data rebuilds a drawing from it. The image method takes a rectangle and a scale and gives you a picture.
Store the data, not the picture, and render the picture when you need one. A rendered image is a dead end: you cannot zoom it, you cannot redraw it at a different size for a PDF, and you cannot inspect the strokes. The data lets you do all three. Apple also exposes bounds, the smallest rectangle used to represent the content's bounds taking the line widths into account, which is the rectangle to hand the image method so the signature is not swimming in whitespace. And strokes, an array of PKStroke, if you ever need to prove the thing was drawn rather than pasted.
One trap is documented and easy to miss. PKDrawing carries a requiredContentVersion property, which Apple describes as the version of PencilKit necessary to use the drawing. A drawing captured with newer tools can need newer software to open, so a seven year old waiver is not automatically readable by whatever you are running when you need it. If the record has to outlive the app, store a rendered image alongside the data at the moment of signing, and treat the image as the archive copy. Apple also publishes a uniform type identifier for the data, which is what you attach it to a file or a share sheet with.
The signature is the smallest field in your record. Around it go the full text of the waiver the person actually saw, a version number for that text, the time, the name and contact detail they typed, and the appointment it belongs to. Store the text, not a link to a page you will later edit, because the whole point is to show what was on the screen that day. Done properly, a waiver is one row and one blob hanging off a booking, which is why it usually ends up inside something like a salon booking app rather than living as an app of its own.
Apple, PencilKit developer documentation, read 14 October 2026
What does App Review require of a waiver app?
Nothing about signatures, and everything about the data. Read the App Store Review Guidelines end to end on 14 October 2026 and the words signature, waiver and signed document do not appear once. What does appear, in detail, is guideline 5.1.1 on data collection and storage, and a waiver app is a data collection app wearing a different hat. Four of its sub points decide your screens.
Guideline 5.1.1(i) covers privacy policies. Every app must link its privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner, and the policy must identify what data the app collects, how it collects it and all uses of that data, confirm that any third party you share with gives the same or equal protection, and explain its retention and deletion policies including how a user revokes consent or requests deletion. For a waiver app that last clause is the hard one. How long do you keep a signed form, and what happens when somebody asks you to delete one that you may need later? Answer that before you write a line of code, because it is a business decision, not an engineering one.
Guideline 5.1.1(ii) covers permission. Apps that collect user or usage data must secure user consent for the collection, even if that data is considered anonymous at the time, and must provide an easily accessible and understandable way to withdraw consent. Guideline 5.1.1(iii) is data minimization: only request access to data relevant to the core functionality, and only collect and use data required to accomplish the task. Every optional field you added just in case fails that test. Guideline 5.1.2(i) adds that you may not use, transmit or share someone's personal data without first obtaining their permission, and that you must clearly disclose where personal data will be shared with third parties, including with third party AI, and get explicit permission before doing so. Emailing a signed copy through a mail provider is sharing.
Guideline 5.1.1(v) is the one that quietly kills a popular design. If your app does not include significant account based features, let people use it without a login, and if your app supports account creation you must also offer account deletion within the app. It also says apps may not require users to enter personal information to function except where directly relevant to core functionality or required by law. A walk in customer who has to register an account before they can sign is the exact shape Apple is describing. Let them sign and leave. Keep the login for staff.
One more, and it decides whose name the app ships under. Guideline 5.1.1(ix) says apps that provide services in highly regulated fields, naming banking and financial services, healthcare, gambling, legal cannabis use, air travel and crypto exchanges, or that require sensitive user information, should be submitted by a legal entity that provides the services and not by an individual developer. A gym waiver is fine. A dental practice consent form built as a side project under your personal developer account is not.
Does charging for the session change the waiver screen?
It changes the screen after it, and the answer is better than most people expect. Guideline 3.1.3(e), goods and services outside of the app, says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. A climbing session, a haircut, a massage and a trampoline hour are all consumed outside the app. So you take the card, not an in-app purchase, and that is the rule rather than a loophole.
The consequence people care about follows from that. Because the payment never runs through in-app purchase, Apple's commission does not attach to it. The line Apple draws is about where the thing is consumed, not about when the money moves, so read the guideline yourself if what you sell is ambiguous. A ten class pass that gets redeemed at the door is a service. A credit that only does something inside the app is a different conversation with a different answer.
The last rule is about who presses submit. Guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. Paired with 5.1.1(ix), that means the business whose waiver it is owns the developer account, owns the submission, and owns the privacy policy. If someone offers to put your waiver app on the store under their account, they are describing a rejection.
Two ways to sign a form in an app
A drawn signature feels more official and a typed name is easier to read back. Both are worth the same on their own, which is nothing, and both carry the same obligations. Pick on the practical rows.
| The question | Drawn on a canvas | Typed name and a tick box | Same either way |
|---|---|---|---|
| What the customer does | Draws with a finger or Apple Pencil | Types their name, ticks the box | No |
| What you store | Stroke data, plus a rendered image | A short string and a timestamp | No |
| Works with no Apple Pencil in the building | Yes | Yes | Yes |
| Reads back on a phone screen | Awkward, signatures are wide | Easy, it is only text | No |
| Needs a native module in React Native | Only if you want PencilKit itself | No | No |
| Survives without the record around it | No | No | Yes |
| Still needs consent and a privacy policy | Yes | Yes | Yes |
Where this lands if a builder generated your app
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own, with two way GitHub sync so the code is never trapped. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It does not submit to the App Store for you, because of guideline 4.2.6: the provider of the content has to submit. It is $25 a month, with no free tier.
For a waiver that shape is helpful in one specific way. A generated app starts local first: the data sits on the device, there are no accounts and there is no server. A signature captured and kept on the staff iPad is not collection under Apple's rules, so the whole of guideline 5.1.1 is dormant. The moment you ask for the signed copy on a second device, in an inbox, or in a dashboard, the agent adds a backend, the data leaves the phone, and every rule in the fourth section switches on at once. That switch is worth noticing when it happens rather than at submission.
The honest limit: a builder will draw you a signature box in an afternoon and cannot write your retention policy. It does not know how long you keep signed forms, who in your business can read them, what you do when someone asks for theirs back, or whether your waiver text means anything where you trade. Those four answers are the actual product. The screen is the easy part, which is the same thing this page started with.
Questions people ask about digital waiver apps
A screen that shows your waiver text, captures agreement, and stores the signed record so you can find it again months later. The capture is usually a signature drawn with a finger, though a typed name and a tick box is what most shipped designs actually use. What makes the record useful later is not the squiggle. It is the surrounding detail: which version of the text the person agreed to, the time they agreed, and what they told you their name was. Apple publishes a framework for the drawing part, PencilKit, and its guidelines cover the data you keep. Nothing in the App Store Review Guidelines mentions signatures or waivers at all, checked on 14 October 2026.
Write down what the record holds, then build the box
List the fields a signed waiver has to carry, say out loud how long you keep it, and only then describe the screen. In that order the signature box is an afternoon and the privacy policy writes itself.
Start building