CodeVerse Creatives
Esc
React Native Syllabus / Phase 8 · Publishing & Capstone / Week 22

Week 22: Capstone — Test, Polish & Ship

The skeleton from Week 21 becomes a finished, shippable app this week — a real test suite, a performance and accessibility pass, notifications wired in if your capstone uses them, a production build, and a genuine submission to at least one store's testing track. This is the last week of the course.

Phase 8 of 8 Week 22 of 22 ~6–8 Hours Hands-on Exercise Included

By the end of this week, you'll be able to

  • Add unit, component and E2E test coverage for your capstone's core flow
  • Run a performance and accessibility pass using Weeks 16–18's tools and techniques
  • Produce a signed production EAS build
  • Submit the app to at least one store's testing track
1 Testing & Polish 2 Performance & Accessibility 3 Final Build & Submission 4 Wrap-Up: Where to Go From Here 5 Exercise 6 Knowledge Check

1. Testing & Polish

Bring Weeks 16–17's tools to bear on the app built last week, aiming for meaningful coverage rather than 100% — the core flow (sign-in, the primary screen, the one write action that matters most) matters far more than exhaustive edge-case coverage on screens nobody will notice a bug in.

  • Component tests for at least the two or three highest-traffic screens.
  • One Detox E2E flow covering the full core path, start to finish.
  • A pass fixing anything the tests or manual use surfaced — a missing loading state, an unhandled error, a broken empty state.
  • Notifications wired end to end, if your capstone includes them, tested on a real device per Week 14.

2. Performance & Accessibility

A short, focused pass using Week 18's tools: profile the app's longest list or busiest screen, fix any re-render or FlatList tuning issue it surfaces, and check the bundle with source-map-explorer for anything unexpectedly large.

Alongside performance, a basic accessibility pass matters for a genuinely shippable app: every interactive element needs an accessible label (accessibilityLabel), touch targets should meet each platform's minimum size, and the app should be navigable with a screen reader (VoiceOver on iOS, TalkBack on Android) for its core flow at minimum.

3. Final Build & Submission

terminal — the release sequence from Weeks 19–20
eas build --platform all --profile production
eas submit --platform ios --latest
eas submit --platform android --latest

Confirm the app record's metadata, screenshots and privacy disclosures (Week 20) genuinely match this finished build — not the plan from Week 21 — before submitting, and include reviewer notes with working demo credentials if the app is signed-in-only.

4. Wrap-Up: Where to Go From Here

Shipping this capstone means you've taken an app through the exact same path a production React Native app follows at a real company — navigation and state, real device integration, native modules when nothing else fit, a real backend, a genuine test suite, and a real build-and-release pipeline. From here:

  • Keep the capstone alive — add one real feature a month, and let its EAS/CI pipeline keep working for you.
  • Go deeper on native — Apple's and Google's own platform documentation is the natural next step past Weeks 12–13.
  • Pair this course with this site's Node.js & Express or Spring Boot course if your capstone's backend was a mock — building the real thing closes the loop.
  • If a staged rollout (Week 20) is available on your submission, actually use it for your app's first real production release.

That's the full 22-week React Native curriculum. Congratulations on shipping.

5. Hands-on Exercise

Hands-on

Ship it (Week 2 of 2)

Finish, test, polish, and submit the capstone app for real.

Requirements:

  1. Component and E2E test coverage for the app's core flow, plus a fix pass on anything they surface.
  2. A performance profiling pass on the busiest screen, and a basic accessibility pass (labels, touch targets, screen-reader navigability) on the core flow.
  3. A production EAS build, correctly signed, matching the app record's current metadata.
  4. A real submission to at least one store's testing track (TestFlight or an Android testing track), with reviewer notes if the app is signed-in-only.
  5. A short retrospective (half a page is enough) — what you'd do differently, and one feature you deliberately cut to hit the finish line.
Hint

If you're short on time, prioritize in this order: a working, tested core flow over broad feature coverage; a real submission to at least one store's testing track over polishing both platforms equally; and an honest retrospective over a perfect one — a capstone that's genuinely finished, even modestly scoped, is worth far more than an ambitious one still in progress.

6. Knowledge Check

Four quick questions. Expand each to check your answer.

Q1

Why does this week aim for meaningful test coverage on the core flow rather than exhaustive coverage everywhere?

Time is finite in the last week of a course, and a bug in the sign-in flow or the primary screen affects every single user, while a bug in a rarely-used edge case affects almost no one — prioritizing coverage where it protects the most real usage is a better use of limited time than chasing a coverage percentage.

Q2

Why check the app record's metadata and screenshots against the finished build specifically now, rather than trusting what was set up in Week 20?

The app likely changed between the Week 21 skeleton and this week's finished, polished version — a screenshot or description depicting functionality the current build doesn't match is a real rejection reason (Week 20's "metadata mismatch"), so it needs re-verifying against what's actually being submitted, not what was true two weeks ago.

Q3

Why does a basic accessibility pass belong in the same week as the production build, rather than being optional polish?

Accessibility gaps — missing labels, undersized touch targets, a core flow that breaks under a screen reader — are real usability failures for real users, not cosmetic issues, and both platforms' review guidelines increasingly weigh on this. Treating it as part of "is this actually finished" rather than optional extra work reflects that it's a genuine requirement of a shippable app, not a nice-to-have.

Q4

What's the practical benefit of using a staged rollout (Week 20) for the capstone's first real production release, if it's available on your submission?

It limits the blast radius of anything the testing tracks and this week's testing pass still missed — a small percentage of users see a problem first, giving you a chance to catch and halt it before it reaches everyone, which matters most on exactly the release (the very first one) where the fewest real users have exercised the app yet.

← Previous Week 21: Capstone — Plan & Build Next Full Syllabus — Course Complete