Examples of Acceptance Criteria for Mobile Apps

Examples of Acceptance Criteria for Mobile Apps

If your mobile acceptance criteria are vague, your team will guess. This article fixes that with 12 mobile app examples that turn broad requests into clear pass/fail checks for iOS and Android.

I’d sum it up like this: good mobile acceptance criteria should tell the team what success looks like, what can fail, how fast it should work, and what changes by platform. The article applies that pattern to common features like login, password reset, onboarding, profile editing, push settings, search, checkout, uploads, offline sync, cross-device performance, and AI chat.

Here’s the short version of what the article covers:

• What acceptance criteria are: story-level conditions that show when a feature is done
• What they should include: clear behavior, validation, measurable timing, device and network context, accessibility, and security
• What mobile teams need to define: screen sizes, OS behavior, permissions, offline states, interruptions, and session handling
• Which features get examples:
• Email and password login
• Social login and SSO
• Password reset
• First-time onboarding
• User profile editing
• Push notification preferences
• Search and filter
• Shopping cart and checkout
• Image and file uploads
• Offline mode and data sync
• Cross-device performance
• AI recommendations and chat
• What good criteria look like: measurable targets such as 2-second search results, 3-second checkout completion, 95% response thresholds, 10-second sync for 100 queued actions, and 99.5% crash-free sessions
• What to avoid: vague wording, implementation notes, happy-path-only stories, mixed iOS/Android behavior, and criteria that combine too many outcomes at once

A few points stand out right away:

• The article keeps pushing one idea: write outcomes, not build instructions
• It treats errors, offline use, and permission denial as first-class cases, not edge cases
• It makes performance testable with numbers like ≤2 seconds, ≤3 seconds, and P95
• It separates story acceptance criteria from the team’s general Definition of Done

If I were using this article as a working guide, I’d take one user story and make sure it answers four questions:

• What should happen when it works?
• What should happen when input or network fails?
• How fast should it respond?
• What is different on iOS and Android?

That’s the core of the piece. The rest of the article shows how to apply that same pattern across all 12 mobile app flows.

How to Write Acceptance Criteria? Explained with Real Examples

sbb-itb-622dc24

What Good Mobile Acceptance Criteria Should Include

Good acceptance criteria should be specific, measurable, testable, and focused on the outcome rather than the build method.

That last part matters more than it may seem.

For example, instead of writing "choose Google login" as a note about how the feature works, say what the user should get: "When the user chooses Google login, they are authenticated and returned to the app signed in, or shown an error message if authentication fails." That kind of wording is much easier to test. It also fits across the mobile stories that come next.

Vague criteria create confusion fast. A line like "App loads quickly" sounds fine at first, but what does "quickly" mean? Two seconds? Five? On what device? Under what network conditions? A line such as "Search results appear within 2 seconds on a supported device under normal network conditions" gives the team something clear to build and verify.

Mobile work also needs more context than desktop work in many cases. You should spell out supported devices, OS versions, network states, and what happens when the app is interrupted and then resumed. For instance, the screen should render correctly on iPhone SE and current Android phones, with no clipped text or overlapping controls. And if the user goes offline, has a weak connection, or gets interrupted, the expected behavior should still be clear. If a phone call comes in during checkout, the entered form data should still be there when the app opens again.

Accessibility and security belong in the same set of criteria too. Keep them just as concrete and observable.

For accessibility, write outcomes a tester can check, such as:

• "All interactive elements have accessible labels for VoiceOver and TalkBack."
• "Text remains usable when the system font size is increased."

For security, define the result just as plainly. Examples include clearing locally stored session tokens after logout, or asking for camera permission only when the user taps a feature such as "Scan receipt," with a clear explanation if permission is denied.

You can also include measured standards when they apply. For example, mobile text should meet a 4.5:1 minimum contrast ratio for standard text on mobile screens. That's not vague. It's a clear pass-or-fail rule.

The table below shows the difference between weak and strong criteria across common mobile areas:

1. Email and Password Login

User story: As a registered user, I want to log in with my email and password so I can access my account.

When a registered user enters valid credentials and taps "Log In," the app should sign them in and show the home screen within 2 seconds for 95% of requests on stable 4G or Wi-Fi. If the request runs longer than 10 seconds, the app should show a timeout message and let the user try again without restarting the app.

Validation needs to be clear and strict. The email field must reject invalid formats, including addresses missing @ or a valid domain. It should also trim leading and trailing spaces and show "Enter a valid email address." The password must be at least 8 characters and include uppercase letters, lowercase letters, numbers, and special characters. If either field is invalid, the app must not send the login request.

Error handling should stay generic and secure. If the user enters the wrong credentials, the app shows "Incorrect email or password" without saying whether the email exists in the system. After 5 failed attempts within 10 minutes from the same device, login is blocked for 15 minutes and the app shows "Too many attempts, please try again later." If the issue is the network, the app should show "Unable to connect. Check your internet connection and try again," along with a Retry button.

A few device and session rules matter here too. The email field should open the email keyboard on both iOS and Android. Session tokens must be stored in Keychain on iOS and Keystore on Android. Passwords must never be stored on the device. Tokens should be cleared on logout. If the session expires, the user should be sent back to the login screen with "Your session has expired. Please log in again."

Use the same pattern for other login flows: define the success path, validation errors, and session rules.

2. Social Login and Single Sign-On

User story: As a user, I want to sign in with Google, Apple, or my company's SSO so I don't have to create a separate password.

Social login adds a few moving parts that standard sign-in doesn't. The app has to hand the user off to the provider, handle the redirect back, and deal with account-linking when an email already exists. If the flow works, the user should land on the right post-login screen: the home dashboard for returning users, or onboarding for new users. That should happen within the set timing targets on both iOS and Android. As a practical benchmark, the login button should show tap feedback within 200 ms, and a successful login on a stable 4G/LTE connection should usually finish in 3 to 5 seconds.

Error handling needs to cover the messy parts too. If the user cancels the provider dialog, the app should return to the login screen, avoid creating any logged-in state, and show "Sign-in canceled." If the provider denies access or the network drops during the SSO handoff, show a plain message like "Check your connection and try again" and give the user a retry option. If token validation fails on the backend, access must be denied right away and the user should see a generic auth error. And if an account already exists with the same email address, the app should ask the user to sign in with their current method first, then offer account linking afterward.

Platform rules need to be spelled out. On iOS, include Sign in with Apple whenever other third-party social logins are offered. Use the official button style, plus a system browser with OAuth 2.0 authorization code flow and PKCE. On Android, Google Sign-In should use the official SDK and follow current OAuth/OpenID Connect rules. Universal Links and App Links should bring users back to the right screen in the app instead of dumping them somewhere random.

Store tokens in Keychain on iOS and encrypted Keystore-backed storage on Android, and clear them on logout. If silent refresh fails, send the user back to login with "Your session has expired. Please log in again."

3. Password Reset

User story: As a user, I want to reset my password so I can regain access to my account without contacting support.

Password reset needs the same kind of clear, testable rules as sign-in. If a registered user taps Forgot password and finishes the reset flow, they should be able to log in with the new password within 1 minute of completing it.

On the request screen, the app must validate email format on the client side within 200 ms, with no server call. It also needs to show the same generic submission message for every email address, whether the account exists or not. After submission, the reset email must be triggered within 1 second and reach the inbox within 30 seconds for at least 95% of successful requests.

The reset flow must use a single-use token that expires in 15–30 minutes. If the user asks for a second reset link, every earlier token must stop working at once. On the new password screen, the app should show the password rules inline and update feedback as the user types. The password must include:

• At least 8 characters
• At least one uppercase letter
• At least one lowercase letter
• At least one number
• At least one special character

The confirm password field must match before the submit button becomes active. After a successful reset, all active sessions must be signed out. The user must also get a confirmation email saying their password was changed, but that email must not include the password itself.

Platform behavior should be spelled out just as clearly. On iOS, reset links must open the app through Universal Links. On Android, they must open through App Links. If the app isn't installed, the link must fall back to a responsive web page that lets the user finish the same flow. On Android, pressing the Back button should return the user to the previous reset step instead of closing the flow. Autofill should populate the email and new-password fields, and the email field should bring up the email-specific keyboard.

The table below turns those rules into simple pass-or-fail cases.

4. First-Time Onboarding

User story: As a new user, I want to be guided through the app's setup so I can reach the main experience quickly and without confusion.

After auth and account recovery, onboarding adds a few things that can make or break the first session: first-run state, skip paths, and saved progress. The goal is simple. A new user opens the app, finishes or skips onboarding, and lands on the home screen without getting stuck.

Onboarding should appear only on the first launch after install or account creation. After a user completes or skips it, the flow should not appear again unless they reinstall the app or manually reset onboarding. That completion state must persist after the app is closed and reopened on both iOS and Android. The full flow should take about 60–120 seconds across 3–4 screens.

Validation needs to be just as clear as the happy path. If onboarding asks for an email address, the app must reject malformed input and show a plain inline message such as "Enter a valid email address." If the flow includes preferences, the criteria should spell out whether the user must pick at least one option, whether the step can be skipped, and whether selections remain in place when the user goes back. If a required field is empty and the user taps Next, the app must show an inline error and keep the user on that step.

Error handling is where teams often miss small but painful details. If the app saves onboarding progress to a backend and that request fails, the user must see a friendly error with a Retry option. Previously entered data must stay in place. If onboarding requests permissions like notifications, location, or camera, the requirements must state what happens when the user taps Not Now or denies access in system settings. In those cases, the app should still continue to the home screen.

Platform behavior also needs to be written in a way QA can test. On iOS, users must be able to skip onboarding and reach the main flow without dead ends. On Android, show a plain-English permission explanation before the system dialog. Android back navigation must be defined so users can move to the previous step without losing progress. On both platforms, the flow should display correctly on small and large screens, and the onboarding completion state should sync in a consistent way for the same account across devices.

The table below covers the main pass-or-fail scenarios.

5. User Profile Editing

User story: As a logged-in user, I want to update my profile information so that my details stay current without needing to use a web browser.

Once onboarding is done, profile editing helps keep account details up to date across sessions and devices. The edit screen should load with the user's current profile data already filled in, check each change before saving, and show saved updates without making the user restart the app.

Each field needs clear rules.

• Display name: required and limited to 50 characters
• Email: must use a standard email format. If the user changes it, the app should send a verification link to the new address, and the new email should not take effect until verification is complete
• Phone number: must use digits only and be 10 to 15 digits long. The app should accept standard U.S. phone number formats
• Profile photo: must be JPG or PNG and no more than 5 MB. The app must compress the image before upload

If a user enters a bad value and taps Save, the app must stop the save, mark the problem field inline, and show a plain message such as "Enter a valid email address." After validation, the behavior for save timing, upload flow, and offline recovery also needs to be clear.

On a standard 4G/LTE connection, basic profile saves should finish and refresh the profile screen within 2 seconds. For photo uploads, show a progress indicator right away, then confirm success only after the server confirms success. If a save fails because of a network issue, the form must keep all entered data and give the user a Retry option.

If the user tries to leave with unsaved changes, show a discard-or-stay dialog. Once changes are saved, updates must appear in headers, comments, and messages without a manual refresh.

For cross-platform coverage, iOS and Android must use the same validation rules, error messages, and field behavior. Behavior should match on both platforms. Testing should include at least one small-screen device, such as an iPhone SE, and one large-screen device on each platform to make sure no fields get clipped or overlap.

6. Push Notification Preferences

User story: As a logged-in user, I want to control which push notifications I receive so that I only get alerts that are relevant to me.

Push notification settings should feel simple and immediate. When a logged-in user changes a setting, the app should respond right away, make it clear what happened, and handle failures without trapping the user.

The settings screen should show each notification category - Order Updates, Promotions, Reminders, and Social Activity - with an on/off toggle and a short one-line description. When the user changes a toggle, the app should update the setting at once and sync it to the server within 2 seconds under normal network conditions. If the device is offline, the app should save the change locally, mark it as pending, and sync it when the connection comes back. That saved state should still be there after the app restarts and after the user signs in again.

Validation here depends on the OS permission state. If notification permission is turned off at the system level, the app should detect it, disable the related in-app toggles, and show guidance that sends the user to Settings. The app must never suggest that notifications are on when OS-level permission is off. If the server save fails, show a non-blocking error and return the toggle to its previous state.

OS-specific permission behavior also matters. On iOS, the app should respect the current authorization status and send denied users to Settings. On Android 13+, request POST_NOTIFICATIONS only at the first relevant use, not during install, and map each category to the right notification channel so users can manage them in Android system settings too.

7. Search and Filter

User story: As a user, I want to search for items and apply filters so that I can quickly find what I'm looking for on both iOS and Android.

Search is a high-intent action on mobile. Someone types a keyword, adds filters, and expects the app to narrow things down fast. The key is simple: show only matching results, keep active filters easy to see, and make them easy to remove. Users should also be able to change or clear criteria without losing their place. As with the other flows, define what success looks like, what happens when nothing matches, and what happens when something breaks.

Be explicit about query, filter, and result logic. If a user searches for "jacket" and adds "Men's", "Blue", and "Under $100," the app should return only items that match all of those constraints. No loose matching, no surprises. Results should load within 2 seconds on a supported device under normal network conditions. If loading takes longer, show a loading indicator. For live search, use a 150-300 ms debounce. In filter modals, use a single Apply action so users can review choices before updating results.

Validation rules need to be spelled out too. The app should trim leading and trailing spaces before running a search, ignore case, and allow partial matches. It also needs to handle special characters, emoji, and whitespace-only input without breaking. Empty queries should disable Search until the user enters text. If input goes past 300 characters, cap it and show a clear message.

Empty and error states need their own pass-or-fail rules. If nothing matches, show "No results found" with a "Reset filters" action. If the network drops during search, show an error the user can retry, and keep the current query and filters in place.

Behavior should stay the same on both platforms, even if the controls look a little different. That means the same result logic, the same filter logic, and the same error handling on iOS and Android. Use native controls for each OS: follow iOS search bar patterns, use Android bottom-sheet filter overlays, and make sure the keyboard's Search key runs the query on both. Touch targets should meet platform guidance: 44 pt on iOS and 48 dp on Android for search controls, filters, and chips. Active filters should appear as removable chips above the results list, with a "Clear all" option whenever filters are active.

The table below turns those rules into pass-or-fail checks.

8. Shopping Cart and Checkout

User story: As a user, I want to add items to my cart, review my order, and complete checkout so that I can purchase products quickly and confidently on both iOS and Android.

Once users find the right item, checkout needs to make each cart and payment step clear. This is one of the highest-risk mobile flows, so the rules here need to leave no gray area. These criteria cover cart updates, validation, recovery, and order completion. Success means the user gets a confirmed order number after entering valid shipping and payment details.

Start with the cart. When a user taps Add to Cart, the app must add the correct product, variant, quantity, and price. The cart badge must update right away. If the user changes quantity or removes an item, the order total should recalculate in real time, without a full page reload. If an item goes out of stock before the order is submitted, the app must show a clear message and stop the user from placing the order for that item. Shipping costs, taxes, and any applied discounts must appear in the order summary before the user reaches the payment screen.

Validation and error handling need direct pass-or-fail rules. Required fields include shipping address, email, phone number, payment method, and billing information. The app should reject invalid ZIP codes, expired cards, unsupported card types, and missing address fields. Each issue should show as an inline, field-level error that tells the user what failed and what to fix. If payment authorization fails, the user must stay on the checkout screen, see a clear error, and be able to try another payment method without entering shipping details again.

Speed matters here. Cart updates should appear within 1–2 seconds, and shipping or tax recalculations should refresh before order submission. From tapping Place Order to seeing the confirmation screen, checkout submission should finish within 3 seconds on a supported device and connection. If it takes longer than 3 seconds, show a loading indicator.

Platform behavior should be specific enough for iOS and Android QA to test without guessing. The flow must work the same way on current supported versions of both iOS and Android, across common device sizes. Use Apple Pay on iOS and Google Pay on Android where supported. Numeric fields, such as card number and ZIP code, should open the number keyboard automatically. Payment entry must use a secure, PCI-compliant flow, and raw card data must not be stored on the device.

9. Image and File Uploads

User story: As a user, I want to select and upload images or files from my device so that I can attach content to my profile, posts, or submissions on both iOS and Android.

This flow has three clear outcomes: pick, upload, and confirm.

The user opens a picker, chooses a supported file, sees upload progress, and then gets a success state. Once the upload finishes, the item should show up in the app right away. No manual refresh.

Be explicit about every entry point:

• Camera
• Photo library
• Files
• In-app document picker

That matters because iOS and Android handle permissions and file selectors in different ways.

Each upload story should use the same pass/fail setup. That means checking:

• File type
• File size
• Progress state
• Retry behavior
• Recovery after failure

The app should accept JPG, PNG, and PDF files up to 10 MB. If the user picks an unsupported format, show an inline error before the upload starts. Images should be auto-compressed before upload. Documents should keep their original quality. Only PDF is allowed for documents. Do not accept DOCX unless the story says so.

Error handling needs to cover the failures users hit most often: unsupported file type, file over the size limit, no network connection, upload timeout, server error, and permission denied. The user must be able to retry without picking the file again. Each error should say what went wrong and what to do next in plain language, such as "File must be under 10 MB" or "Upload failed. Try again." Uploads must continue or resume after the app is minimized or interrupted.

Performance matters here too. The progress indicator should appear within 1 second of tapping Upload, and the app should stay responsive while the file is transferring. Small files under 5 MB should upload in a few seconds on a standard 4G or 5G connection.

The scenarios below turn those rules into simple pass-or-fail checks.

10. Offline Mode and Data Sync

User story: As a user, I want to keep using the app when I lose my connection so that I can view my data, make changes, and have everything sync automatically when I'm back online - on both iOS and Android.

This section builds on the earlier error-handling patterns and spells out what the app should do when the network drops.

The main goal is simple: users should still be able to use key parts of the app without a connection, and anything they change should be stored safely and synced later with no data loss or duplicate records.

Focus the rules on state changes, not just the offline moment. The app should handle three states: offline, reconnecting, and synced.

When the user is offline, the app should show cached data and a clear offline indicator. It should not crash, freeze, or sit there loading forever. Any action that needs a live connection should be disabled and explained in plain language, instead of failing with no warning.

When the connection comes back, sync should start automatically. On stable Wi-Fi or LTE, the app should finish syncing up to 100 queued actions within 10 seconds.

Validation should happen in two places:

• Run client-side validation on the device before data is queued.
• Run server-side checks during sync.

If a queued record fails server-side validation, the app should mark that record with an error state and show a message such as, "Couldn't save this item to the server: [reason]." If sync fails, the app should retry 3 times over 30 seconds, then show a non-blocking banner while keeping all queued data safe.

Conflict handling needs to be spelled out. For most content, last write wins by timestamp is acceptable. For financial data or bookings, the server should be authoritative. Either way, the criteria should state exactly how conflicts are settled and what the user sees after the conflict is resolved.

Background sync also needs platform-specific rules. On iOS, sync should run in the foreground and in the background when the system allows it, without blocking the user's actions. On Android, schedule sync with WorkManager so it can resume after Doze or app standby.

Test this on real devices, not just simulators. Use throttled networks or airplane mode to make sure the app behaves the way people expect when the connection gets spotty or disappears altogether.

11. Cross-Device Performance

User story: As a user, I want the app to work smoothly and render correctly on iPhone and Android devices so I can complete tasks without slowdowns, crashes, or broken layouts.

Cross-device performance matters because mobile apps need to stay stable across many device models, screen sizes, and OS versions. That’s especially true for stories with heavy rendering, network calls, or lots of state changes.

Start with a 15–20 device/OS matrix based on real usage data. Pull it from Google Play Console or App Store Connect so the matrix matches how people actually use the app.

Then use that matrix to define pass/fail limits for launch, scrolling, loading, memory, and stability:

• Cold start: ≤3 seconds on mid-range devices, ≤5 seconds on minimum-spec devices
• Screen transitions and data loading: ≤2 seconds for cached content, ≤3 seconds for fresh data on 4G or Wi-Fi
• Touch interactions: respond within 100–200 ms; scrolling maintains at least 50 FPS
• Memory usage: ≤300 MB RAM during normal browsing on mid-range devices
• Stability: ≥99.5% crash-free sessions across supported devices; no device-specific crash cluster above the defined threshold

Error handling should follow the same acceptance-criteria pattern used throughout this article: clear trigger, clear response, clear recovery. A blank screen tells the user nothing. If a screen doesn’t load within 5 seconds on a low-end Android device, show a retry option and placeholder content instead. If the app detects an unsupported OS version, show "This app requires iOS 15 or later" rather than failing silently.

The scenarios below turn those limits into outcomes you can test.

Use Xcode Instruments for iOS and Android Studio Profiler for Android to measure startup time, frame rate, CPU, memory, and network usage against these thresholds. On AI-heavy screens, those same latency and memory limits matter even more.

12. AI Recommendations and Chat

User story: As a user, I want the app to show me relevant recommendations and let me ask questions through AI chat so I can find what I need quickly without empty states or unclear failures.

Just like the other mobile flows, AI needs clear acceptance criteria around success, fallback behavior, speed, and platform parity. The point is simple: define what the user sees, how fast it shows up, and what happens when the model doesn’t deliver.

For recommendations, a direct, testable rule could be: if I’m logged in and open the home screen, I should see at least 10 personalized suggestions within 2 seconds on a 4G connection. If I don’t have any history yet, the app should show a curated default or category-based fallback instead of an empty state. If recommendations time out, the app should return a fallback list. If the data is malformed, it should fall back to category items. After a favorite or purchase, results should refresh within 5 seconds.

There’s also a quality check here. Recommendations shouldn’t keep cycling the same narrow set of items again and again. And if the app tells the user why something was recommended, that explanation should stay short and match across both platforms.

For AI chat, define both the happy path and the fallback path. If confidence drops below 0.7, the bot should ask a clarifying question and show three quick replies, such as Track an order, Return an item, and Talk to an agent. If content is unsafe or blocked, the app should return a neutral message and route the user to support. If the chat service is temporarily unavailable, the app should say so plainly and offer a retry option.

The handoff to a human needs its own rule too. When a user taps Talk to an agent, the handoff should finish within 10 seconds, and the AI should stop responding in that session. Chat history should persist if the app is closed and reopened within 5 minutes. After that, a new session should begin with a clear notice.

Keep all performance thresholds in one place so nobody has to hunt for them later:

• AI chat replies render within 3 seconds for 95% of requests under normal load
• Recommendation availability stays at 99.5% over 30 days
• At least 80% of top-five intent chats - order status, returns, shipping, account help, and general info - end without human escalation

The table below turns those rules into direct pass-or-fail checks.

Use the same prompt, response schema, and fallback rules on both platforms.

How to Write Acceptance Criteria for Mobile User Stories

Use two formats: rule-based bullet lists and Given/When/Then scenarios. Both fit the login, onboarding, checkout, upload, offline, and AI stories in this article.

Rule-based bullets are best for validations, UI limits, and performance thresholds. Each line should be atomic and easy to test. For example: "Search results appear in under 2 seconds on a stable 4G/5G connection" or "The Continue button stays disabled until both fields contain valid input."

Given/When/Then is a better fit when behavior changes based on user state or a step-by-step flow. The pattern is simple: Given the context, When the user takes an action, Then the app responds. For example: "Given the user is signed out, when they tap 'Log in with Google,' then they are redirected to Google authentication and returned to the app upon success."

Be specific. Use measurable thresholds instead of fuzzy wording. And tie performance to a network condition - stable Wi-Fi, 4G, or 5G - because mobile results change with connection quality. "The form displays an inline error within 1 second of an invalid submission" can be tested. "The app should load quickly" can’t.

Start with the happy path. Then layer in errors, permissions, offline states, and app interruptions. That order keeps the core flow clear before you deal with what happens when things go sideways.

Use these formats to tighten the mobile examples above before reviewing common mistakes.

Common Mistakes to Avoid

A few mistakes show up again and again in mobile acceptance criteria, and they tend to make QA work harder than it should.

Vague criteria are a big one. Phrases like "load fast" or "feel smooth" sound fine at first, but they can't be tested. You need a measurable result instead, like: "The home screen loads in under 2.0 seconds on 4G for 95% of test runs." If QA has to come back with follow-up questions, the criterion isn't ready.

Another common problem is putting implementation details into acceptance criteria. That locks the story to one way of building it. The better move is to describe behavior: sign-in succeeds, the user reaches the home screen, and the session stays active until logout or expiry. The how belongs in technical design docs, not in the user story.

Then there's skipping negative paths. That's where a lot of production bugs slip through. If your criteria only cover the happy path, you're leaving out the moments when things go wrong. Write separate criteria for declined payments, expired sessions, and denied permissions.

It's also easy to miss platform differences between iOS and Android. But those differences matter. Permissions and navigation don't work the same way on both platforms, so your criteria shouldn't pretend they do. Write separate criteria for each OS when behavior changes.

One more issue: bundling several outcomes into one criterion. That's a recipe for confusion. Search speed, result display, and error handling should be split into separate criteria. Each one should stand on its own with a clear pass/fail result.

Use the table below as a quick check before moving to the reference table.

Acceptance Criteria Reference Table

This table boils 12 examples down to the four checks teams lean on most: user outcome, validation, performance, and platform rules. It gives you a side-by-side view of how those checks show up across the 12 examples above.

When a story needs step-by-step behavior, the scenario format below works well. It turns broad rules into something teams can test without guessing.

Conclusion

Clear acceptance criteria cut rework, speed up testing, and make releases more predictable.

The 12 examples in this article focus on the mobile app flows that matter most: authentication, onboarding, checkout, offline access, and AI-driven features. They’re not meant to be copied line by line. Think of them as starting points, then shape each one around your app’s business rules and the needs of each platform. Once you’ve done that, apply the pattern to one user story at a time.

A simple way to start is to pick one high-impact story and write criteria for:

• success
• errors
• performance
• iOS and Android behavior

Start with the user outcome. Then move to testable validation rules. After that, spell out any platform-specific behavior. That gives QA a clear checklist and gives the team a shared definition of done.

FAQs

How do I write acceptance criteria for a new mobile feature?

Start by working with a tester, developer, and product owner so the acceptance criteria are clear, testable, and tied to what the user wants to get done.

The user story should be Independent, Negotiable, Valuable, Estimable, Small, and Testable. Spell out the success metrics, explain the feature from the user’s point of view, show how it should work, call out technical requirements, and include accessibility needs based on WCAG.

What metrics should mobile acceptance criteria include?

Mobile acceptance criteria should include measurable performance and usability metrics. That way, you can check whether the app is doing what it’s supposed to do instead of relying on gut feel.

Key metrics often include:

• Loading times under 3 seconds
• Stability with no crashes
• Task completion rates
• Time on task
• Error rates, such as misclicks
• User satisfaction scores like the System Usability Scale or Net Promoter Score

These metrics give teams a clear way to judge whether the app is ready and whether people can use it without friction.

When should iOS and Android criteria be separated?

Separate iOS and Android acceptance criteria when each platform needs its own behavior, UI pattern, or technical setup.

This matters most when the apps rely on different native tools, like VoiceOver on iOS and TalkBack on Android, follow different platform conventions, or are built natively with Swift or Kotlin.