Design to Developer Handoff Checklist for Mobile Apps

A complete design to developer handoff checklist for a mobile app includes annotated screens, every UI state, spacing and typography tokens, iOS or Android platform rules, assets, and short behaviour notes. Send this as one structured package, not just a Figma link. Figma is the best source of truth for most teams; Figma Make is useful for exploring flows, but it is not a substitute for production-ready specs.

The short version

Our pick: Figma as the source-of-truth handoff file, backed by a written handoff brief.

Best for: Founders handing an iOS or Android app design to a remote freelance developer or small product team.

Skip it if: Do not rely on Figma alone if the app has payments, offline behaviour, permissions, complex rules, or API-driven content that needs written product decisions.

Key takeaways

• •A Figma link shows what a screen looks like; a handoff package explains what it does, including the states no one sees in the happy-path prototype.
• •For every screen with data, specify loading, empty, error, partial-data, and retry behaviour before development starts.
• •Tell the developer whether each screen follows iOS, Android, or deliberately custom conventions. Otherwise they will make reasonable assumptions that may not match your intent.
• •A remote developer needs a one-page product brief, a named source-of-truth file, an ordered build list, and a place to ask and record decisions.
• •Use tokens for spacing, type, colour, radius, and elevation. Repeated measurements typed manually into frames create drift by the third screen.
• •Figma Make can help test an idea or demonstrate a flow, but developers still need inspectable layouts, assets, state rules, and implementation notes.

What's on this page

• •A Figma link is a starting point, not a developer handoff package
• •Start with an ordered screen inventory, not a canvas full of frames
• •Design the states developers cannot infer from the happy path
• •Send tokens so spacing does not drift screen by screen
• •Write down iOS and Android conventions before the developer chooses for you
• •Package the work for a remote developer who has no product context
• •Use Figma and Figma Make for the jobs they actually do
• •Run a handoff review after the first build, not only before development

A Figma link is a starting point, not a developer handoff package

The usual failure starts with a founder sending a Figma link and writing, “Here are the final designs.” The developer opens the home screen, login screen, and settings screen, then starts filling in the gaps. That is not poor development. It is the only possible response to missing decisions.

A design file answers some visual questions: hierarchy, approximate layout, labels, colours, and components. It rarely answers what happens while data loads, when a list is empty, when a request fails, when a user denies a permission, or when text is longer than the example copy. Those decisions appear in the first build as generic spinners, blank pages, Android-style controls in an iPhone app, or expensive questions halfway through a sprint.

Your developer handoff package should contain four core parts:

• •Screens: every intended screen, at the device sizes you are building first.
• •States: the non-happy-path versions of each important screen.
• •Tokens: named spacing, typography, colour, radius, border, and elevation values.
• •Platform notes: explicit iOS and Android behaviour and navigation choices.

Figma should be the visual source of truth. Keep one clearly named page for approved screens and another for work in progress, so a developer does not build an abandoned concept by accident. If you use Figma Make to explore an interface from prompts, treat its result as an exploration or flow demonstration until you have checked the individual screens, states, and measurements.

The goal is not a 40-page specification. It is to remove the 15 assumptions that turn a clean design into a first build you have to pay to rebuild.

Start with an ordered screen inventory, not a canvas full of frames

A developer needs to know what to build first and what counts as complete. Put an ordered inventory at the front of the Figma file or in the handoff brief. A canvas with 27 unnamed frames is not an inventory.

For each screen, give it a stable name and a status. For example: 01 Onboarding / Welcome / approved, 02 Sign in / Email / approved, and 06 Home / populated / approved. Group variants beside the base screen rather than hiding them several pages away.

Your inventory should state:

• •the primary user journey to build first;
• •the screen’s route or navigation destination, if known;
• •whether it is iOS, Android, or shared design;
• •whether it uses static sample content or live API content;
• •which states are required for the first release;
• •any screen that is intentionally out of scope.

This matters when you have hired a developer by the project rather than by the hour. “Build the app in this file” sounds finite, but it is not. A developer can reasonably count five visible screens while you expect five screens plus authentication, keyboard handling, empty lists, errors, permissions, and settings. The difference can double the real work.

Use realistic content in the approved frames. A two-word example title does not reveal what happens when a merchant name is 28 characters, a user has no profile photo, or an amount has a currency symbol and decimals. Add one long-content example for feeds, cards, profile fields, and buttons that might localise. You will catch clipping before it becomes a code fix.

Keep prototype links if they explain sequence, but do not assume the prototype is the specification. A prototype can show that tapping a card opens details; it does not define whether the tap is disabled during loading, whether the user can go back, or what happens if those details cannot be retrieved.

Design the states developers cannot infer from the happy path

The most expensive omissions are not visual polish. They are states. A developer can reproduce a visible card reasonably well. They cannot know your product decision for an empty account, a slow network, or a failed upload unless you provide it.

For every screen that displays or submits data, review these design handoff states and specs:

• •Loading: first load, refresh, and submit-in-progress. State whether content uses skeletons, a spinner, or retained old content.
• •Empty: no orders, no saved items, no search results, no notifications, or a new user with no activity. Include the message and the action, if any.
• •Error: network failure, server failure, invalid form input, expired session, and failed payment or upload where relevant. Show whether retry is available.
• •Partial or stale data: a list can load while one image fails; a dashboard can show cached figures while refresh fails. Decide what the user sees.
• •Success and confirmation: saved changes, submitted form, copied code, deleted item, or completed purchase. Define whether feedback is inline, a banner, a dialog, or a new screen.
• •Disabled and unavailable: unavailable feature, locked option, permission not granted, offline action, and button disabled until valid input.

You do not need separate artwork for every edge case. A clearly labelled variant with the exact copy and action is enough. For example, Home / empty / first visit should include the illustration or icon if one is intended, the headline, body copy, and “Add first item” action. Home / error / retry should show whether old content remains on screen.

Do this before the developer estimates. An empty state is not “just another screen” if it needs an API response distinction, analytics event, CTA destination, and a reusable component. It is product scope.

Send tokens so spacing does not drift screen by screen

The third day of implementation is where untokenised Figma files become costly. The developer has reproduced eight, 12, 16, 20, and 24 pixel gaps from different frames. Then you ask for the list rows to feel tighter. They now have to find every near-match, decide which was intentional, and avoid breaking another screen.

Create a small token page in Figma and use the same named values in the approved screens. You do not need a mature design system to do this. For a first app release, define the values you actually use:

• •spacing scale and page gutters;
• •type styles: family, weight, size, line height, and letter spacing;
• •colour roles, not only raw hex values: primary text, secondary text, surface, divider, destructive action, and so on;
• •radii, borders, shadows or elevation;
• •button, input, icon, avatar, and list-row dimensions;
• •light and dark appearance rules if dark mode is in scope.

Use Figma variables and styles where practical, but do not confuse a named style with an implementation contract. Add a short note for anything that is intentional but unusual: “Cards are always 16pt from the screen edge,” “minimum tap target is 44pt on iOS,” or “body text may wrap to three lines; do not truncate.”

Give the developer the actual source assets too. Do not leave them to screenshot icons out of Figma or guess whether a logo is an SVG, PNG, or app icon asset. Export and label each asset, identify its intended size, and state whether it should tint with the interface colour. For platform icons, name the intended iOS or Android system icon where that is your preference rather than drawing a slightly different custom version.

A token sheet does not make the developer copy pixels blindly. It gives them a consistent rule to implement, which is what preserves the design across screens you have not yet drawn.

Write down iOS and Android conventions before the developer chooses for you

A mobile UI can use the same visual language on iOS and Android without behaving identically. If you do not state the target platform and the exceptions, a developer will use their normal framework defaults. Those defaults may be sensible and still be wrong for your product.

For iOS, decide whether navigation uses a native-style navigation bar and back behaviour, a tab bar for top-level destinations, sheets for temporary tasks, and iOS-style date, time, share, and permission flows. Account for the safe areas around the Dynamic Island and home indicator. Specify whether swipe-back should work and whether a destructive action needs confirmation.

For Android, decide whether the app follows Material navigation patterns, how the system back action behaves, whether screens use a top app bar, and whether a bottom navigation bar is present. Account for system bars and gesture navigation. Android users generally expect the system back action to return them predictably through the app; do not leave that path implied by a prototype.

Also call out platform-level choices that affect implementation:

• •status bar appearance and safe-area treatment;
• •keyboard behaviour on forms and chat-like screens;
• •permission timing and the screen shown after denial;
• •native pickers for date, photo, file, and share actions;
• •haptics, pull-to-refresh, swipe actions, and destructive confirmation;
• •accessibility expectations such as dynamic text, contrast, and screen-reader labels.

A single shared Figma frame is fine only if it genuinely applies to both platforms. If an iOS sheet and an Android bottom sheet should differ, show both or attach a concise note. “Make it feel native” is not enough direction for a developer working across Flutter, React Native, SwiftUI, or Jetpack Compose.

Package the work for a remote developer who has no product context

A remote developer in the UK, India, or any other time zone cannot absorb product intent through hallway conversations. Your package must let them start work, make routine decisions, and raise the right questions without waiting a day for a reply.

Send one handoff folder or project page with links to five things:

1. •A one-page product brief. State the user, the job they are trying to do, the first-release goal, and the one primary journey. “A marketplace app” is too broad. “A renter can save a listing, request a viewing, and see the request status” is useful.
2. •The approved Figma file. Give view or inspect access as appropriate. Mark the approved page, archive old work, and identify the person who can approve changes.
3. •A screen and state inventory. List what is in scope for this build, in build order, with links to each frame or section.
4. •A behaviour and decision log. Record rules such as validation, sorting, cancellation, permissions, and navigation. Put unresolved decisions in a separate list; do not bury them in comments.
5. •Assets and technical references. Include copy, icons, logos, API documentation or sample responses if available, test credentials, analytics requirements, and app-store or privacy constraints that affect the UI.

Set one communication rule: questions go in a shared issue tracker or decision document, not only in chat. A written answer such as “search filters persist until the user clears them” becomes part of the specification. A message lost in a thread becomes a later disagreement.

Finally, agree on a review rhythm. Ask for a test build after the login flow and one representative data screen, not after all 25 screens. You will catch font rendering, safe-area spacing, navigation assumptions, and component choices while the developer can still apply a fix everywhere.

Use Figma and Figma Make for the jobs they actually do

Figma is usually the right place to hand off mobile interface design because it can hold approved screens, components, variables, annotations, prototypes, and developer-facing inspection in one shared file. It is not magic documentation. A clean file still needs clear state names, product rules, and an agreed scope.

Figma Make can be useful earlier in the process: you can explore an idea from a prompt, test a rough interaction, or give a developer a clearer sense of a flow than static frames alone. But do not send a Figma Make result as the only brief for a production app. A working-looking demonstration can conceal missing error handling, undefined data, unsupported interactions, and inconsistent layout rules. The developer still needs the approved source screens and written choices described in this guide.

Before handoff, run a 30-minute review against the actual file:

• •Can a new person identify the approved screens in under two minutes?
• •Does every important data screen have loading, empty, and error variants?
• •Are repeated values represented by reusable styles, variables, or an explicit token list?
• •Is every icon and image available as a real asset?
• •Do platform-specific screens say iOS or Android?
• •Can the developer tell what happens after each primary action?
• •Are unresolved product decisions visibly marked rather than silently omitted?

If the answer is no, the file is not ready, even if it looks polished. A developer does not need more visual decoration. They need fewer ambiguous choices.

For a small first release, this review often prevents a week of rework. It is especially valuable when you are paying a fixed project fee: the first estimate is only as accurate as the package you provide.

Run a handoff review after the first build, not only before development

Handoff is not a single meeting. It is a short control loop between the approved design and the first implementation. The first test build exposes decisions that static frames cannot: keyboard overlap, real device safe areas, slow content, image cropping, native control behaviour, and text rendering.

Review one complete vertical slice first. For example: onboarding, sign in, home in loading state, home with content, home empty state, item details, and the primary action. Check it on the target iPhone and Android device sizes, not only in a browser preview. If you are building only one platform first, say that plainly so the developer does not spend early budget copying platform work you will not ship yet.

Log findings in three categories:

• •Design mismatch: wrong spacing, typography, icon, colour, alignment, or component state.
• •Missing specification: the build reveals a state or rule you did not provide.
• •Changed product decision: you now want a different flow or behaviour.

These categories protect both sides. A design mismatch belongs in the agreed scope. A missing specification needs a decision. A changed product decision may change time and cost. Calling all three “small tweaks” is how founders lose track of budget and developers lose trust.

Once the first slice is correct, freeze the shared components and tokens before the remaining screens are built. That is the point of doing handoff properly: not to make the first screen perfect in isolation, but to stop the same wrong interpretation appearing across 20 screens.

If you generate screens with floow.design, export the screens and their states to your working file, confirm platform notes and product rules, then hand over the package. floow.design can assemble the visual material quickly; your written decisions still tell the developer how the app should behave.

What each handoff artifact prevents

What it costs

The cost of handoff is mostly time spent making decisions before development. Figma offers different plan levels and collaboration or developer-oriented capabilities may vary by plan; Figma Make availability and limits may also vary. Published pricing and included features change, so check Figma’s own pricing page before choosing a plan. For a founder, the useful comparison is not a monthly tool price versus zero: it is a few hours of structured handoff versus paying a developer to rebuild avoidable omissions after the first build.

Mistakes that cost you the most

Sending only the polished happy-path screens.

Add loading, empty, error, disabled, success, and long-content variants for every important data or form screen.

Leaving iOS and Android behaviour implicit.

Label each target platform and document navigation, back actions, safe areas, keyboards, permissions, and native pickers.

Using manual measurements on every frame.

Define and reuse a small spacing and typography scale, plus component dimensions and colour roles.

Mixing approved work with experiments in the same Figma page.

Create one clearly marked approved handoff page, archive old concepts, and name frames by flow, screen, and state.

Frequently asked questions

What should I send a developer besides a Figma link?

Send a developer an approved Figma file plus a one-page product brief, screen inventory, state variants, design tokens, exported assets, platform notes, and a written decision log. The brief should explain the user and primary journey; the inventory should define scope and build order. Include loading, empty, error, disabled, and success states, because a Figma link alone rarely explains those behaviours.

What states am I forgetting in my design handoff?

The states most often missing from a mobile app handoff are first-load loading, refresh loading, empty lists, no search results, network errors, validation errors, expired sessions, disabled buttons, permission denial, offline behaviour, partial data, long text, and success feedback after an action. Review every screen that reads, submits, deletes, uploads, or searches for each of these cases.

How do I write handoff notes for a remote developer?

Write handoff notes as short decisions attached to the relevant screen or collected in one shared decision log. State the trigger, expected behaviour, and exception: for example, “On save, keep the user on this screen, show a confirmation banner, and disable Save until another field changes.” Label open questions separately. A remote developer needs written rules, not comments that assume prior product conversations.

What's a complete developer handoff checklist for an app?

A complete developer handoff checklist for an app includes approved screens, an in-scope screen list, loading and error variants, empty and success states, spacing and type tokens, colour and component rules, exported assets, iOS or Android platform notes, navigation behaviour, form validation, permission flows, API or sample-data references, test access, and a decision log. Review the first implemented user journey on real devices before building every remaining screen.

Is Figma Make enough for a developer handoff?

Figma Make can help communicate an early app concept or demonstrate a flow, but it is not enough by itself for a production developer handoff. A developer still needs approved screens, inspectable layout rules, assets, loading and error states, platform conventions, and product behaviour notes. Use Figma Make to explore and explain; use a structured Figma file and handoff brief to define what must be built.

Where this leaves you

Do not judge a handoff by whether the Figma file looks finished. Judge it by whether a developer who has never discussed the product can build the first user journey without inventing its missing states and rules. Send screens, states, spacing tokens, platform notes, assets, and a concise remote brief. floow.design exports every state and screen with spacing intact, so the handoff package is already assembled by the time a developer opens it.

---

Design the screens before you commit to a tool

floow.design exports every state and screen with spacing intact, so the handoff package is already assembled by the time a developer opens it.

If that is roughly your situation: describe the app in plain English and floow.design draws the iOS and Android screens, takes your changes by chat, and exports the result to Figma or to Flutter, React Native, SwiftUI and Jetpack Compose.

Design your app screens now →

---

Free tools you can use right now

• •iOS App Icon Sizes — free, no sign-up
• •Notch & Safe Area Simulator — free, no sign-up
• •Device Size Reference — free, no sign-up

Related reading

• •How to Choose a Design Tool Based on How Clean the Dev Handoff Is
• •Best AI Design Tools for Keeping a Mobile Design System Consistent
• •Cursor for Design Alternatives: Better Tools for Mobile App UI
• •Google Stitch Review: What It's Actually Like to Design a Mobile App With It