diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index fe8d09f..619e70a 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -34,3 +34,11 @@ jobs:
- name: Type-check mock-core
run: pnpm --filter @wavex-os/mock-core exec tsc -p tsconfig.json --noEmit || true
+
+ - name: Install Playwright browsers
+ run: pnpm exec playwright install chromium --with-deps
+
+ - name: Smoke test (mobile — iPhone 13 viewport)
+ run: pnpm exec playwright test e2e/touch-target.spec.ts --project=chromium
+ env:
+ PLAYWRIGHT_BASE_URL: http://localhost:5173
diff --git a/content/blog/mobile-app-qa-checklist/index.mdx b/content/blog/mobile-app-qa-checklist/index.mdx
new file mode 100644
index 0000000..6296203
--- /dev/null
+++ b/content/blog/mobile-app-qa-checklist/index.mdx
@@ -0,0 +1,276 @@
+---
+title: "Mobile App QA Checklist: Everything Your Team Needs Before Every Release"
+slug: mobile-app-qa-checklist
+date: 2026-05-17
+author: Tony Apple QA Studio
+description: "A comprehensive mobile app QA checklist covering functional testing, UI regression, performance, device matrix, and CI/CD gates. Download the free PDF."
+keywords: ["mobile app qa checklist", "mobile app testing checklist", "mobile qa process", "app release checklist"]
+category: mobile-testing
+type: blog_post
+published: false
+published_at: null
+cta_url: "https://wavexos.com/signup?utm_source=organic&utm_medium=seo&utm_campaign=qa-checklist-pdf"
+schema:
+ "@context": "https://schema.org"
+ "@type": "Article"
+ headline: "Mobile App QA Checklist: Everything Your Team Needs Before Every Release"
+ author:
+ "@type": "Organization"
+ name: "Tony Apple QA Studio"
+ datePublished: "2026-05-17"
+ publisher:
+ "@type": "Organization"
+ name: "Tony Apple QA Studio"
+---
+
+import { EmailGate } from '@/components/EmailGate'
+import { SignupCTA } from '@/components/SignupCTA'
+
+
+
+# Mobile App QA Checklist: Everything Your Team Needs Before Every Release
+
+Shipping a broken release costs more than delaying it. A single crash on the most-used flow can tank your App Store rating overnight, trigger a wave of uninstalls, and generate support tickets that swamp your team for days. The fix is not heroic last-minute testing—it is a repeatable checklist that every engineer and QA lead runs before every release, every time. This guide gives you that checklist, section by section, plus a downloadable PDF you can attach to your release pipeline.
+
+---
+
+## 1. Functional Testing: Core User Flows
+
+Functional testing verifies that the app does what it is supposed to do. Start with the flows that generate revenue or retain users—everything else is secondary.
+
+Run each item manually on at least one real device and confirm it is covered in your [automated smoke-test suite](/blog/mobile-smoke-testing-guide):
+
+- **Onboarding / sign-up:** new user can complete registration without errors on both iOS and Android
+- **Login:** email/password, SSO, and biometric (FaceID / fingerprint) each succeed
+- **Core value action:** the single action your app is built around (place order, send message, start workout) completes end-to-end
+- **Payments / in-app purchase:** transaction succeeds in sandbox; receipt is validated server-side
+- **Notifications:** push notification tap routes to the correct in-app screen
+- **Deep links:** marketing links open the right screen without crashing when the app is cold-started
+- **Offline graceful degradation:** app displays a clear error (not a blank screen or crash) when there is no network
+- **Session expiry:** expired token triggers re-authentication, not a silent failure or infinite spinner
+- **Logout:** session is fully cleared; back-button does not restore authenticated screens
+- **Permissions:** camera, location, and microphone permission prompts appear at the right moment and are handled correctly when denied
+
+If any of these flows fails, the release does not ship. No exceptions.
+
+---
+
+## 2. UI and Regression Testing: Touch Targets and Visual Diffs
+
+
+
+A functional app can still feel broken if buttons are mis-sized, text is truncated, or a layout breaks on a specific screen width. UI regression catches the drift between releases.
+
+**Touch target checklist:**
+
+- Every tappable element is at least 44×44 pt (Apple HIG) / 48×48 dp (Material Design)
+- No overlapping hit areas — a "back" button should not fire when the user taps the header text
+- Form inputs scroll above the keyboard on both platforms (no input hidden behind the keyboard)
+- All interactive elements have visible focus states for accessibility
+
+**Visual regression with screenshot diffs:**
+
+Screenshot diffing compares a reference screenshot against the current build pixel-by-pixel. Tools like Applitools, Percy, or the open-source [automated regression framework](/blog/automated-regression-testing-mobile) you already use will flag layout shifts before humans catch them.
+
+Run screenshot diffs against:
+
+- Home / dashboard screen
+- Product listing or content feed
+- Checkout or conversion screen
+- Settings / profile page
+- Any modal or bottom-sheet that appears on a primary CTA
+
+Flag any diff above a 0.1% threshold for human review. Do not auto-approve diffs from a changed feature branch without a second set of eyes.
+
+---
+
+## 3. Performance: Startup Time, Memory, and Battery
+
+Performance regressions are invisible until they are catastrophic. A 300 ms startup regression compounding over 10 releases becomes a 3-second cold launch—and users notice at 2 seconds.
+
+**Startup time:**
+
+- Cold launch (app not in memory): target ≤ 2 s on a mid-range device from your [device matrix](/blog/ios-android-device-matrix-testing)
+- Warm launch (app backgrounded): target ≤ 1 s
+- Measure with Xcode Instruments (Time Profiler) or Android Profiler, not wall-clock stopwatch
+
+**Memory:**
+
+- Peak RSS during a typical user session should not exceed your baseline by more than 15%
+- No memory leaks detectable after 5 full navigation cycles (use Instruments Leaks / Android Memory Profiler)
+- App should not be OOM-killed in the background within 30 minutes on a device with 3 GB RAM
+
+**Battery:**
+
+- Background location or sensor polling should consume ≤ 2% battery per hour (measure with Android Battery Historian or iOS Energy Log)
+- No wakelocks held unnecessarily between user actions
+
+---
+
+## 4. Device and OS Matrix Coverage
+
+You cannot test every device, but you can test a representative matrix. Skipping this step is why releases that "passed QA" crash on the most common Android skin in your target market.
+
+**Minimum viable matrix (adjust for your analytics):**
+
+| Tier | iOS | Android |
+|------|-----|---------|
+| Latest | iPhone 16 Pro (iOS 18) | Pixel 9 (Android 15) |
+| Previous flagship | iPhone 15 (iOS 17) | Samsung Galaxy S24 (One UI 6) |
+| Mid-range | iPhone SE 3rd gen | Samsung Galaxy A55 |
+| Older OS | iOS 16 (min supported) | Android 12 (min supported) |
+| Small screen | — | Pixel 4a (5.8″) |
+
+**What to test on each tier:**
+
+- Core user flows (functional checklist above)
+- Orientation: portrait and landscape on tablet-class devices
+- Text scaling: run at 150% text size and verify no clipping
+- Dark mode: if supported, verify on at least one device per OS
+
+For [continuous device coverage](/blog/ci-cd-mobile-testing-pipeline), integrate a cloud device farm (BrowserStack, Sauce Labs, Firebase Test Lab) into your CI pipeline so every PR runs smoke tests on the top-three devices automatically.
+
+---
+
+## 5. CI/CD Integration Gate
+
+A checklist that lives in a spreadsheet is a checklist that gets skipped under deadline pressure. The only reliable checklist is one that blocks a merge or deployment automatically.
+
+**Gate structure:**
+
+```
+PR opened → unit tests → lint + type-check
+ ↓
+Merge to staging branch → smoke tests (real device, cloud farm)
+ ↓
+Release candidate tag → full regression suite → screenshot diffs
+ ↓
+Human sign-off (QA lead) → App Store / Play Store submission
+```
+
+**Minimum CI gate requirements:**
+
+- **Unit tests:** must pass with ≥ 80% coverage on business logic modules
+- **Smoke tests:** top-5 user flows on at minimum 2 real devices (iOS + Android)
+- **Screenshot diffs:** auto-fail on any diff > 0.1% on core screens
+- **Performance budget:** fail the build if cold launch time regresses > 10% vs. baseline
+- **Dependency audit:** flag any new third-party dependency not approved by the security review
+
+**Gate enforcement rules:**
+
+- No bypass without a written exception signed by the engineering lead
+- Exception log is reviewed at the weekly release retrospective
+- Three consecutive exceptions on the same check = mandatory automation investment to fix the underlying issue
+
+---
+
+## Summary: Release-Ready Checklist at a Glance
+
+| Section | Pass criteria |
+|---------|---------------|
+| Functional flows | All 10 core flows pass on iOS + Android |
+| Touch targets | All tappable elements ≥ 44pt/48dp, no overlap |
+| Screenshot diffs | < 0.1% change on core screens |
+| Cold launch | ≤ 2 s on mid-range device |
+| Memory | Peak RSS within 15% of baseline, 0 leaks |
+| Device matrix | Tested on 4 tiers minimum |
+| CI gate | All automated checks green before human sign-off |
+
+**Get the full checklist as a printable, fillable PDF:**
+
+
+
+---
+
+## Frequently Asked Questions
+
+
+
+
+
+### What should a mobile app QA checklist include?
+
+A complete mobile app QA checklist should cover five areas: functional testing of core user flows, UI and regression testing with screenshot diffs, performance benchmarks (startup time, memory, battery), device and OS matrix coverage, and CI/CD gate enforcement. The goal is a repeatable process that catches regressions before they reach users.
+
+### How often should you run a mobile app QA checklist?
+
+Run the full checklist before every production release. Run an abbreviated smoke-test subset (core flows + CI gate) on every pull request merge to your main branch. The more automation you have in place, the lower the marginal cost of running checks continuously.
+
+### What is the difference between functional testing and regression testing in mobile QA?
+
+Functional testing verifies that features work as designed — the app does the right thing. Regression testing verifies that previously working features have not broken — the app still does what it used to do. Both are required: a new feature can be functionally correct while inadvertently breaking an unrelated screen.
+
+### How do you test a mobile app across multiple devices without a large hardware lab?
+
+Use a cloud device farm such as Firebase Test Lab, BrowserStack App Automate, or Sauce Labs. These services give you access to hundreds of real devices on demand, integrate directly with CI/CD pipelines, and are typically cheaper than maintaining a physical lab once you account for device refresh cycles and maintenance time.
+
+### What is a CI/CD gate for mobile app releases?
+
+A CI/CD gate is an automated check that must pass before a build can proceed to the next stage — for example, from a feature branch to the release candidate. Typical gates include unit test pass rate, smoke test results on real devices, screenshot diff thresholds, and performance budgets. Gates enforce the QA checklist automatically so no release can bypass it under deadline pressure.
+
+
diff --git a/docs/demo/pr-ci-demo.html b/docs/demo/pr-ci-demo.html
new file mode 100644
index 0000000..ab82b3b
--- /dev/null
+++ b/docs/demo/pr-ci-demo.html
@@ -0,0 +1,706 @@
+
+
+
+
+
+Tony Apple QA Studio — Demo
+
+
+
+
+
+