To add signature capture to an app you need a box to draw in and a record to attach it to.
To add signature capture to an app you put a wide box on screen, collect the coordinates the finger passes through, draw them as a path, and save the result against the thing being signed. In a React Native and Expo project that is about a day of work, and the drawing code is not the hard part. Here is the limit, at the top where it belongs: what you capture is a picture. It counts as a signature because of what it is attached to and what the person was shown when they drew it, never because the line looks like ink. That gap is the whole design problem inside proof of delivery apps.
This page covers how a stroke is actually captured, what the federal definition of an electronic signature turns on, what to store beside the picture, and when to send a document through a service instead of building any of it.
See what a stroke is made ofThe short version
Drawing the line is one day of work, proving who drew what is the rest of it.
Two things come out of a box that asks somebody to sign on a phone screen. A picture of a squiggle, which is easy and which nobody ever argues about. And a claim that a named person agreed to a named thing at a named time, which is the part somebody will argue about later.
Nearly every signature feature that disappoints stored the picture and threw away everything around it. The image is the smallest part of the record, and on a first attempt it is usually the only part anybody keeps.
What a captured stroke is actually made of
A signature box is a view that claims the touches inside it. In React Native that is the gesture responder system, usually reached through PanResponder, which the API reference describes as reconciling several touches into a single gesture so a one finger drag survives a stray second touch. Each move handler receives a gestureState object. The two fields that matter here are moveX and moveY, the latest screen coordinates of the touch that just moved. x0 and y0 give you where the finger first landed, and numberActiveTouches tells you when a palm has arrived on the screen as well.
You push each pair of coordinates onto an array, and that array is one stroke. A finger lift ends a stroke and the next touch starts another, so keep a list of strokes rather than one long list of points. That single decision gives you undo for free, because undo is dropping the last stroke, and it keeps the letters apart when somebody dots an i.
Rendering is the easy half. Turn each stroke into an SVG path string and draw it. Two details make the box feel broken if you skip them. Give it the full width of the screen, because people sign small in a small box and then say it looks nothing like their signature. And convert the coordinates to be relative to the box rather than the screen, or the line appears a header's height away from the finger.
The other route is a WebView with an HTML canvas inside it, which is less code and a common shortcut. It also puts the drawing behind a bridge, so the delay between touch and line is the thing to test on the oldest phone you support before you commit to it.
What the legal definition actually turns on
This is where people expect a technical standard and find none. Under the federal ESIGN Act, an electronic signature is an electronic sound, symbol or process that is attached to or logically associated with a contract or other record, and that a person executed or adopted with the intent to sign that record. Read it twice. Nothing in it is about ink, pressure, stroke speed or how convincing the curve looks.
Three things carry the weight instead: the association with one specific record, the intent of the person doing it, and the identity of that person. A file sitting in a storage bucket with a customer name for a filename satisfies none of the three. That is the honest answer to whether a drawing is a signature. On its own it is an image, and it becomes evidence only through what you stored around it.
The same Act, a few sections earlier, sets out what a kept record has to do. It has to accurately reflect the information in the record, and it has to stay accessible for as long as the law requires, in a form that can be accurately reproduced later. A cropped thumbnail of a squiggle, with the terms it was given against long since edited, fails both halves of that test.
None of this is legal advice. The Act also carves out categories it does not cover at all, including wills, codicils and testamentary trusts, state family law matters such as adoption and divorce, court documents, and documents that have to accompany hazardous materials. Rules outside the United States are different again and we have not checked them here. If the document matters, ask somebody qualified before you ship the box.
Store the record, not just the picture
The reason to capture a signature in your app rather than on paper is the row it creates, so decide what that row holds before you write the save function. Adding fields to signatures you already collected is miserable. A reasonable minimum: the image for a human to look at, the stroke points so you can tell a drawn line from a pasted one, a timestamp your server set rather than one the phone claimed, an identifier for the exact version of the text the person was shown, and who was signed in when it happened.
The version identifier is the one everybody leaves out and later regrets. If your terms change in March, every signature captured in February now points at wording nobody agreed to. Store a hash or a version number of what was actually on the screen and that whole argument goes away.
Where the record lives is a separate decision and it is the usual one about a vibe coding backend database. A signature is a small row with a file attached, so most options work. What it cannot be is a file in a shared folder named after the customer, because a folder has no way to say which row of which job the drawing belongs to.
Try it
What your signature record can answer later
Tick what you save when somebody signs. The questions underneath get asked months later, by somebody who was not in the room.
1 of 5 questions answered
- answered Did somebody sign at all?
- still open When did they sign it?
- still open What exactly did they agree to?
- still open Who was holding the phone?
- still open Was it drawn here and not pasted in?
Build it, buy it, or skip it
Build it when the signature happens in the field, on a phone, at the moment the work finishes, often with no signal. A driver at a loading dock, an engineer closing a job, a moving company app taking an inventory at the kerb. In those cases the signature is one field at the end of a form that already exists, a hosted service would be a second app to open in the rain, and the value sits in the drawing being tied to the job.
Buy it when the thing being signed is a document rather than a job. Hosted e signature services exist because contracts need a sender, a named recipient, a sealed copy, a completion certificate and an audit trail that neither side wrote. Rebuilding that so you can avoid a fee per envelope is a project, not a feature, and you would be the only auditor of your own audit trail.
Skip it more often than you think. A tick box next to a typed name meets the same statutory definition as a drawing, and for an internal approval it is easier to read back, because nobody holds a specimen signature to compare the drawing against anyway. A drawing is also harder to produce for anyone using a switch, a stylus they do not have, or a screen reader. Ask what the squiggle is for. If the answer is that it feels more official, you are building a decoration.
What each option can answer a year later
| Option | Works with no signal | Ties to a document version | Timestamp the signer cannot set | Effort to build |
|---|---|---|---|---|
| Paper, then photograph it | Yes | No | No | none |
| Drawing saved as an image only | Yes | No | No | one day |
| Drawing plus a stored record | Yes | Yes | server sets it on sync | a few days |
| Typed name and a tick box | Yes | Yes | server sets it on sync | an hour |
| Hosted e signature service | No | Yes | the service sets it | an integration |
Building the box into the app that already exists
A signature is almost never the app. It is the last field on a job sheet, a delivery, an inspection or a consent form, and on its own it is worth very little. That is the argument for putting it inside the app your team already opens rather than sending people to a second tool for one scrawl at the end of a shift.
Newly is an AI app builder. You describe the app in plain English, including the form the signature sits at the end of, and it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and ships it to TestFlight and to Google Play internal testing. It is $25 a month with no free plan, iOS needs your own Apple Developer account, and there are no built in payments. The backend the signature record lands in is a choice you make, not something that arrives with the project.
One thing to settle before any of the code: what you need the signature to prove, and to whom. That question is upstream of every storage decision on this page, and it sits with the rest of what a signature proves.
Questions people ask about signature capture
You give a view the touches inside it and record where the finger goes. In React Native that is the gesture responder system, usually through PanResponder, whose gestureState object hands each move handler moveX and moveY, the latest screen coordinates of the touch that moved, plus x0 and y0 for where it started. Collect those coordinates into one array per stroke, convert them to positions relative to the box rather than the screen, and render each stroke as a path.
Put the signature at the end of the job, not in a second app
Describe the form the signature belongs to, decide now what the record has to answer a year from now, and build the box into the app your team already opens.
Start building