native-update 1.4.9 → 3.1.0

package/docs/social-media-marketing/posts-batch-02.md

@@ -0,0 +1,528 @@
+# Native Update — Posts Batch 02
+
+10 LinkedIn / Facebook posts, batch 02. Each: 2700–2900 chars. Different angles from batch 01.
+
+Series tag: **#NativeUpdateInside** (a "behind the scenes / advanced" companion arc to the `#NativeUpdate10` introductory series).
+
+Mark consumed: replace heading with `USED — Post NN — …`.
+
+---
+
+## Post 01 — Why I built Native Update (founder note)
+
+> "Why are you building a Capacitor OTA plugin in 2026? Hasn't someone already done this?"
+
+I get this question a lot. Worth answering plainly.
+
+I ship a portfolio of mobile apps on the Capacitor stack. For years, the OTA story on Capacitor felt like the third-party Wild West. The two patterns were:
+
+1. **DIY** — write your own bundle pull, hash check, atomic swap, rollback, telemetry. About 4 weeks of engineer time you don't have. Then maintain it forever.
+2. **Paid SaaS lock-in** — sign up for a hosted live-update service. Pay per device. Upload your bundles to their cloud. Hope they don't sunset the product or change pricing.
+
+Both are bad trades. The first eats your runway. The second hands strategic infrastructure to a vendor you can't easily replace.
+
+So I built the third option: **Native Update — MIT-licensed plugin + reference Laravel backend you self-host.** No per-device fees. No vendor lock-in. The plugin and the backend ship from the same monorepo and stay in sync because the same author writes both.
+
+### What the project costs me
+
+Real talk on sustainability — this matters if you're picking infrastructure.
+
+- **Time** — significant. v3.0.0 alone was ~3,000 LOC deletions and a dual-backend → single-backend migration
+- **Money** — minimal. Self-hosted backend on a small VPS. Marketing site on Firebase Hosting (free tier)
+- **Motivation** — strong. I use Native Update on my own projects. If I stop maintaining it, my own apps break
+
+### What you can expect
+
+- Continuous maintenance because I'm the largest user
+- A clear changelog and migration path on BREAKING releases (v3.0.0 has one in `docs/MIGRATION.md`)
+- An MIT license that lets you fork the entire monorepo if I ever go silent
+- A 7-day full-audit cooldown that keeps churn out of the commit log
+
+### What you should NOT expect
+
+- 24/7 enterprise support (this is a community-maintained MIT project)
+- An SLA-backed delivery guarantee (you self-host; you own uptime)
+- A magical hosted-SaaS option (it's on the roadmap; not shipped yet)
+
+### Where this matters most
+
+The biggest risk for small / mid-size teams: building your release pipeline on a vendor that might disappear or 10x its pricing next quarter. MIT-licensed, self-hosted infrastructure is the antidote — your release path keeps working even if I stop maintaining the project. The code is yours to fork.
+
+If "MIT, self-hosted, author dog-foods it on their own apps" is the trade you want, this is your plugin. If you'd rather pay for managed convenience, hosted SaaS exists and serves that market — Native Update isn't competing there.
+
+`#NativeUpdateInside` 01 of 10 — behind-the-scenes arc complementing the introductory `#NativeUpdate10` series.
+
+**👉 https://nativeupdate.aoneahsan.com**
+
+#NativeUpdate #FounderStory #OpenSource #Aoneahsan #BestOpenSourceCommunityProject
+
+---
+
+## Post 02 — How Native Update compares to other Capacitor OTA options
+
+Honest comparison post. No fanboy energy. If you're picking an OTA tool for a Capacitor app, here's the landscape.
+
+### Capgo (capgo.app)
+
+Mature, hosted SaaS, paid tiers. Solid product. Real engineering behind it. Pricing scales with active devices, which is the right model for a hosted service.
+
+When Capgo wins: you want zero-ops; you'd rather pay than self-host; you're an SMB whose first 10k devices fit in their free tier.
+
+When Native Update wins: you want MIT, self-hosted, no per-device fee; you're enterprise and can't put bundles on a third-party cloud; you want to fork the backend.
+
+### Capacitor's own Live Updates
+
+Ionic offers a Live Updates product (paid, tied to Appflow). Mature, well-documented, but tightly bound to the Ionic / Appflow ecosystem.
+
+When Live Updates wins: you're already paying for Appflow.
+
+When Native Update wins: you don't want vendor lock-in to Ionic's hosted services.
+
+### DIY
+
+Roll your own with a CDN + hash check + atomic swap script.
+
+When DIY wins: you have a unique constraint that none of the off-the-shelf options support.
+
+When Native Update wins: you're tempted to DIY because everything off-the-shelf is paid SaaS, but you'd actually take an MIT-licensed reference if it existed.
+
+### What Native Update brings to the table
+
+- MIT-licensed end-to-end (plugin, native code, CLI, backend, examples)
+- Real native Kotlin / Swift, not a JS shim
+- A reference Laravel backend in the same repo
+- 81 unit tests + Detox E2E
+- 3 example apps validating the protocol against 3 backend postures
+- v3.0.0 single-backend architecture (one mental model)
+- 7-day audit cooldown (mature ops cadence)
+
+### What it doesn't bring
+
+- A hosted SaaS option (yet — on the roadmap, not shipped)
+- A 24/7 support contract
+- Years of "thousands of independent integrators" social proof — that's still building
+
+### A decision framework
+
+Ask yourself in this order:
+
+1. Is your release infrastructure strategic enough to own? If yes → self-host (Native Update). If no → managed SaaS (Capgo).
+2. Are you willing to operate a Laravel backend on a VPS? If yes → Native Update. If no → Capgo.
+3. Do you need to fork the entire stack on day one? If yes → Native Update (MIT). If no → either works.
+4. Are you in a regulated environment that can't put bundles on a third-party cloud? If yes → Native Update. If no → either works.
+
+Most teams cluster on either "fully managed" or "fully self-hosted." Native Update is uncompromisingly the second. Capgo is uncompromisingly the first. Pick the one that matches your operational posture, not the one with the louder marketing.
+
+Pick by trade-off, not by hype. If MIT + self-host fits, this is the package.
+
+**👉 `yarn add native-update` or https://nativeupdate.aoneahsan.com**
+
+#NativeUpdate #Comparison #Capacitor #Aoneahsan #TopFree
+
+---
+
+## Post 03 — The security model: bundle hashes, signed URLs, threat model
+
+`#NativeUpdateInside` 03 of 10.
+
+Updating a hybrid app's JS bundle from a remote server has a real threat surface. Most "live update" pitches gloss over it. Here's exactly what Native Update does — and what it doesn't.
+
+### The threats we model
+
+1. **Hostile network** — attacker on the user's Wi-Fi (coffee shop, airport, compromised home router) tries to swap your bundle for malicious JS during download.
+2. **Compromised CDN** — your bundle host is compromised; attacker uploads a bad bundle in place of yours.
+3. **Stale bundle replay** — attacker captures an old bundle and tries to force the device to apply it (downgrade attack).
+4. **Wrong-bundle delivery** — server bug or operator mistake serves a bundle to the wrong channel / wrong binary version.
+
+### What Native Update does about each
+
+1. **Hostile network → SHA-256 hash verification.** The CLI computes the SHA-256 of the bundle at upload time and stores it with the release record. The device re-computes the hash after download and refuses to apply if it doesn't match. A swapped bundle fails the check.
+2. **Compromised CDN → server-stored hashes.** The hash lives in the database (not in the bundle URL or its metadata file on the CDN). An attacker who compromises the CDN alone cannot change what hash the device expects — they'd also need to compromise the backend.
+3. **Stale bundle replay → version + release-ID gating.** The device records the release ID it last applied and checks that the offered release is newer. A captured-and-replayed older bundle is rejected.
+4. **Wrong-bundle delivery → channel + binary-version constraints on the server.** The release record carries a channel and a binary-version constraint. The device passes its channel + binary version on every check; the server only offers releases that match.
+
+### What Native Update does NOT do (be honest about this)
+
+- **No code signing of the bundle itself.** The hash check + HTTPS transport is your integrity story. If you need code-sign-grade assurance, layer your own signing on top — the protocol is open.
+- **No "user-level" auth on bundle download by default.** Bundles are typically signed-URL gated by the backend. If you need per-user auth, you can wire that in via the protocol.
+- **No bypass of network-stack TLS.** If your backend's TLS is broken, that's your problem; Native Update assumes HTTPS works.
+
+### Why this matters
+
+A plugin that updates JS at runtime is a plugin that can compromise your entire app at runtime. The hash + version-gating pattern Native Update uses is the minimum bar — but it IS that bar, by default, with no special configuration. Don't skip the threat-model conversation when you adopt any OTA tool.
+
+**👉 Read the security docs: https://nativeupdate.aoneahsan.com**
+
+#NativeUpdate #Security #ThreatModel #Aoneahsan #SaaSApp
+
+---
+
+## Post 04 — Common OTA mistakes I see teams make
+
+`#NativeUpdateInside` 04. Pattern-recognition from helping teams adopt OTA on hybrid apps. The same handful of mistakes show up over and over.
+
+### Mistake 1: marking everything mandatory
+
+The temptation is "I want users on the latest, so every release is mandatory." The cost: every mandatory update is a chance for the user to bounce out at the worst moment. They opened the app to do one thing, got blocked on a force-update screen, lost goodwill.
+
+Fix: optional by default. Mandatory only for security patches and "binary contains an irrecoverable bug" emergencies.
+
+### Mistake 2: skipping canary
+
+"It's a small change, ship it to 100% of production." Then 0.3% of devices crash on boot, you get 30 angry tickets in 20 minutes, and you're rolling back at 3 AM.
+
+Fix: canary every release (5–10%), watch Sentry for an hour, then ramp. The CLI's `promote --rollout` flow is built for this. 26 hours from staging to 100% is the right pace, not 5 minutes.
+
+### Mistake 3: shipping without Sentry
+
+If your OTA bundle breaks on a subset of devices and you have no error monitoring, you'll find out via support tickets — hours late, with no diagnostic context.
+
+Fix: tag every Sentry event with the Native Update release ID. Two lines:
+
+```ts
+const release = await NativeUpdate.getCurrentRelease();
+Sentry.setTag('nativeupdate.release', release.id);
+```
+
+You'll see "release X-Y is throwing for these users" in Sentry within minutes of the rollout.
+
+### Mistake 4: trying to OTA native changes
+
+"We added a new Capacitor plugin and want to push it via OTA." It doesn't work. New plugins, new permissions, anything in `Info.plist` / `AndroidManifest.xml` are binary releases. The plugin can't help. Plan for a binary release, OTA the rest.
+
+### Mistake 5: no release-version display in the app
+
+When debugging "user says feature X is broken," your first question is "what release are they on?" If your app doesn't display the Native Update release ID somewhere (settings screen, About page), you can't answer that.
+
+Fix: show `getCurrentRelease().id` in your About screen. 5 lines of code. Saves hours of triage.
+
+### Mistake 6: confusing channels with feature flags
+
+Channels are for *release distribution*. Feature flags are for *runtime conditional logic within a release*. Use channels for "should this device get this bundle?" and a feature-flag system (LaunchDarkly, Statsig, your own backend) for "should this user see this UI?". Different tools, different problems.
+
+### Mistake 7: no rollback rehearsal
+
+You only learn how `rollback` actually works the first time you need it. Practice it on staging *before* the production fire.
+
+**👉 Avoid the mistakes from day one: https://nativeupdate.aoneahsan.com**
+
+#NativeUpdate #BestPractices #ReleaseManagement #Aoneahsan #TopFree
+
+---
+
+## Post 05 — Multi-app Native Update: one backend, many apps
+
+`#NativeUpdateInside` 05.
+
+A pattern more teams adopt as their app portfolio grows: **one Native Update backend serving multiple apps.**
+
+### The setup
+
+Each app gets:
+- Its own app key (generated from Nova admin)
+- Its own channels (`production-app-A`, `staging-app-A`, `production-app-B`, etc. — or just rely on the app-key namespace)
+- Its own binary-version space
+- Its own release history
+
+But shares:
+- One Laravel + Nova install
+- One database
+- One CDN / Storage bucket (with key-prefixed paths)
+- One operations footprint
+
+### Why this is the right pattern for portfolio teams
+
+- **Single ops surface.** One backend to monitor, patch, and back up.
+- **Single Nova admin.** Operators see all apps in one place. Switching is a dropdown.
+- **Shared infrastructure cost.** A small VPS that handles 10k devices for one app handles 10k for ten apps just as well. The expensive part is bandwidth, which scales linearly per app.
+- **Single auth model.** Token scoping happens per app + per channel; one token system covers everything.
+- **Easier policy enforcement.** Want every app in the portfolio to have a 7-day staging soak before promote-to-production? One operational rule, applied across all apps.
+
+### The Nova admin model
+
+Nova's resource UI handles the multi-app case naturally. Each App resource owns its Channels, Releases, and Devices. The relationship hierarchy is:
+
+```
+App
+├── Channels (production / staging / canary / custom)
+│   └── Releases (versioned bundles)
+│       └── DeviceTelemetry (which device on which release)
+```
+
+You browse by app first, then drill in. Operators never see app B's data when working on app A.
+
+### When NOT to multi-app a single backend
+
+- **Compliance separation.** If app A handles PHI and app B doesn't, separate backends make audit boundaries cleaner.
+- **Wildly different scale.** If app A pushes 10x the traffic of every other app combined, dedicated infra is easier to reason about.
+- **Independent ownership.** If two different teams own two apps and can't agree on backend ops, separate them.
+
+### Real numbers
+
+A small VPS (1 vCPU, 2 GB RAM) running the Laravel backend handles bundle distribution for tens of thousands of devices across many apps comfortably. The bottleneck is bandwidth — a CDN in front of bundle storage solves that. Compute is essentially free at this scale; you're paying for storage and egress, both commodity-priced and predictable.
+
+The numbers reality is the opposite of what most teams expect: the *backend* is cheap, the *bandwidth* is the line item. Plan accordingly when you size your CDN budget — DAU × bundle-size × release-frequency is your ballpark monthly egress.
+
+**👉 Multi-app docs: https://nativeupdate.aoneahsan.com**
+
+#NativeUpdate #Architecture #MultiApp #Aoneahsan #SaaSApp
+
+---
+
+## Post 06 — A quick tour of the Nova admin
+
+`#NativeUpdateInside` 06.
+
+Nova is the admin layer of the Native Update backend. If you've never used Laravel Nova, here's what you get out of the box, no extra UI work.
+
+### What Nova gives you
+
+- A clean, opinionated CRUD interface
+- Resource pages (Apps, Channels, Releases, Devices, etc.) with list / detail / edit views
+- Filters, search, batch actions
+- Permissions (admin / operator / read-only)
+- Activity log (who promoted what, when)
+- Custom Nova actions for domain operations (rollback, promote-between-channels)
+- Dashboards (rollout progress, device distribution)
+
+### The screens you'll use most
+
+**Releases.** A table of every release ever, filterable by app + channel + status. Click a row → full release detail (bundle hash, size, upload time, rollout %, current device distribution). One-click rollback action.
+
+**Channels.** Per-app list of channels and their currently-active release. Promote actions live here.
+
+**Devices.** A telemetry view — one row per device, showing app, current release, last-seen, platform, crash status. Filter by "stuck on old release" or "failed last update apply" to spot rollout issues.
+
+**Apps.** Top-level config. Generate app keys, set CDN base URLs, configure default channel.
+
+### Why Nova vs a custom dashboard
+
+I built `website/` as a marketing/dashboard site too — but Nova covers the *operator* use case (CRUD on releases / channels / devices) better than any custom UI I'd hand-roll. The website is for end-customer-facing dashboards (read-only, polished). Nova is for operations (full power, less pretty, that's fine).
+
+Splitting the UI like this was the right call. Nova handles 95% of operator work in zero UI engineering. The website handles customer-facing work where you'd invest in UI anyway.
+
+### Operator setup in 5 minutes
+
+1. Backend up (`docker compose up`)
+2. `php artisan nova:user` to create your first admin
+3. Log in to `/nova`
+4. Create an App resource for your first app
+5. Generate an app key
+6. Drop the key into your client's `capacitor.config.ts`
+
+You're operational. From there, every release flows through the CLI; Nova is your read/manage UI.
+
+### Why Nova matters for non-technical operators
+
+Release management eventually gets handed off to non-engineering operators — release managers, QA leads, support triaging "what release is this user on?" Nova's CRUD UI works for them without ramping on Laravel. Click, filter, read; never touch SQL or the CLI. That's the right boundary between engineering work (CLI, code) and operational work (Nova).
+
+Nova also makes "who promoted what, when" reviews trivial — every action is logged in the activity log. Auditors love it. You'll love it the first time someone asks "who pushed X at 3 AM?"
+
+**👉 See the Nova screens: https://nativeupdate.aoneahsan.com**
+
+#NativeUpdate #LaravelNova #AdminPanel #Aoneahsan #SaaSApp
+
+---
+
+## Post 07 — How v3.0.0 migration actually went
+
+`#NativeUpdateInside` 07.
+
+Practical retrospective on the v3.0.0 BREAKING release. Not a "we shipped it, all good" puff piece — the actual rough edges and what we learned.
+
+### What changed
+
+v2.x supported two backend postures: Laravel HTTP (canonical) and Firestore-direct (the device read release metadata directly via Firebase SDK). v3.0.0 removed the Firestore path. Single Laravel HTTP backend now. ~3,000 LOC deleted.
+
+### The rough edges
+
+- **Internal types referenced Firestore in places we didn't expect.** First pass missed a couple of `website/src/types/firestore.ts` and `website/src/types/index.ts` files; cleanup commit caught them later.
+- **Tests had implicit Firestore dependencies via mocks.** Removing the path required updating test fixtures, not just deleting the implementation.
+- **Documentation drift.** Some doc pages still referenced "Firestore or Laravel" weeks after the code was gone. Caught in the next audit pass.
+- **Existing v2 integrators on the Firestore path needed a real migration guide** — not "just switch to Laravel," but "here's how to model your existing release data in Laravel's schema."
+
+### What we did to make migration smooth
+
+- Wrote `docs/MIGRATION.md` before shipping the BREAKING release, not after
+- Bumped the major version number (v3.0.0) per semver, not v2.x.something
+- Kept the v2.x branch alive for security patches
+- Documented the new HTTP protocol in detail so integrators with custom backends could update their implementations
+
+### What I'd do differently next time
+
+- **Audit ALL files (not just `src/`) for the removed feature.** The website type files were stragglers; a grep would have caught them in one pass instead of two.
+- **Update the public README + landing page on the same commit as the BREAKING release.** A 2-day window where the README still talked about Firestore caused at least one confused issue.
+- **Ship the migration guide as a release-note GitHub issue too**, not just a markdown file in the repo — discoverability matters.
+
+### Why BREAKING is sometimes the right call
+
+When you're carrying ~3,000 LOC of duplication that complicates every other decision, the cost of "preserving compatibility" is more than the cost of asking integrators to migrate once. v3.0.0's test matrix shrunk by ~40%; new feature velocity went up; doc burden halved. Worth it.
+
+The lesson: don't be precious about BREAKING releases when the alternative is technical-debt accumulation that slows everyone, including future integrators. Major versions exist precisely so you can clean house occasionally.
+
+**👉 v2 → v3 guide: https://nativeupdate.aoneahsan.com**
+
+#NativeUpdate #Migration #Retrospective #Aoneahsan #BestOpenSourceCommunityProject
+
+---
+
+## Post 08 — Performance: how heavy is OTA on your users?
+
+`#NativeUpdateInside` 08.
+
+Honest look at the runtime cost of Native Update on a user's device. The TL;DR: small. The longer answer is worth understanding.
+
+### Bundle download
+
+Typical Capacitor app's JS bundle: 200–800 KB gzipped. On Wi-Fi, that's ~1–3 seconds. On a decent 4G connection, ~2–6 seconds. On 3G, ~10–30 seconds.
+
+Native Update downloads in the background after the app starts (so the user is using the app on the *current* bundle while the next one downloads). The download throttles based on network type — by default, no aggressive cellular usage.
+
+### Disk
+
+Two bundles on disk at any time: the active one and (during transitions) the pending one. ~1–2 MB total. Negligible on any modern device.
+
+### Memory
+
+Effectively zero overhead. The plugin itself is small (a few KB of JS + the native bridges). Bundle application doesn't consume meaningful RAM beyond what running the app already does.
+
+### CPU
+
+Hash verification is the most CPU-intensive operation. SHA-256 over a 500 KB bundle is sub-second on any phone made in the last 5 years. Atomic swap is a file-system rename — instant.
+
+### Battery
+
+Background downloads consume battery proportional to network activity. The plugin's default config avoids cellular unless explicitly opted-in, and respects iOS / Android background-task budgets. A typical OTA download is similar in battery cost to loading a webpage with images.
+
+### Cold-start time
+
+This is where teams often worry, fairly. The plugin runs `checkForUpdate()` early in app launch. The check is a small HTTPS call (a few KB request, a few KB response). On a healthy network: <100ms. On a slow network: it runs async so it doesn't block app start by default.
+
+If `autoCheck: true` is set and a new bundle is available, the download happens in the background; the user starts the app on the current bundle and gets the new one on the next launch. Zero perceived cold-start impact.
+
+### What if the user is offline?
+
+The check fails silently (no network = no new release possible). The user starts the app on the current bundle. No error toast, no broken state. The next time they're online and open the app, the check succeeds and they pick up any pending release.
+
+### The honest worst case
+
+User is on a slow 3G connection, you've configured aggressive cellular downloads, the bundle is 1 MB. You're using ~30 seconds of background bandwidth and a noticeable percentage of their data plan for that release. Don't do this. The defaults exist for a reason — Wi-Fi-only background downloads is the right starting point.
+
+**👉 Performance docs: https://nativeupdate.aoneahsan.com**
+
+#NativeUpdate #Performance #MobileEngineering #Aoneahsan #TopFree
+
+---
+
+## Post 09 — Telemetry, analytics, and what you can actually see
+
+`#NativeUpdateInside` 09.
+
+When you push an OTA release, what can you actually observe? Native Update gives you three categories of telemetry, each useful for a different question.
+
+### Category 1: Release-state telemetry
+
+Per-device: which release ID is currently active, when was it applied, did the application succeed or fail, what's the device's platform / binary version, last-seen timestamp.
+
+This answers: "Is my rollout actually progressing?" "Are some devices stuck on an old release?" "Did a release land on devices that should have rejected it (binary-version mismatch)?"
+
+Surfaced in: Nova admin Devices view, with filters and aggregations.
+
+### Category 2: Apply-failure telemetry
+
+Per-attempted-application: did the bundle download succeed? Did hash verification pass? Did the atomic swap complete? If anything failed, why?
+
+This answers: "Why didn't 5% of devices pick up the new release?" "Is there a download path issue (network, CDN, firewall)?" "Is there a corruption issue (hash mismatches at scale = your CDN is misbehaving)?"
+
+Surfaced in: backend logs + Nova admin failure dashboard. Threshold-based alerting is on the roadmap.
+
+### Category 3: Post-apply runtime telemetry
+
+This is NOT something Native Update provides directly — it's what you get from your existing analytics + error monitoring (Amplitude, Sentry, Mixpanel, your own backend) once tagged with the Native Update release ID.
+
+Pattern:
+
+```ts
+const release = await NativeUpdate.getCurrentRelease();
+Sentry.setTag('nativeupdate.release', release.id);
+Amplitude.setUserProperty('nativeupdate_release', release.id);
+```
+
+This answers: "Did the new release change conversion?" "Are users on the new release crashing more or less?" "What's the per-release retention curve?"
+
+Native Update gives you the release ID; your existing analytics stack does the rest.
+
+### What you don't get out of the box
+
+- A built-in product analytics platform (intentional — use the one you already have)
+- A built-in error monitoring service (intentional — Sentry / Bugsnag / Rollbar do this better)
+- A built-in A/B testing framework (intentional — you can use channels for it, or layer LaunchDarkly / Statsig)
+
+The principle: do release distribution + state observability well; let other tools handle their domains.
+
+### Wiring it all together
+
+Add Sentry. Tag with release ID. Add Amplitude / Mixpanel. Tag with release ID. Now every event in your analytics + error stack is attributable to a specific Native Update release. Combined with Nova's release-state view, you have full observability of every rollout.
+
+**👉 Telemetry docs: https://nativeupdate.aoneahsan.com**
+
+#NativeUpdate #Telemetry #Observability #Aoneahsan #SaaSApp
+
+---
+
+## Post 10 — Roadmap, contribution, and how to get involved
+
+`#NativeUpdateInside` 10 — last in this batch.
+
+Where Native Update is going, and how you can help if you want to.
+
+### Shipped (where we are)
+
+- v3.0.0 single-backend architecture (Laravel HTTP only)
+- Native Kotlin + Swift implementations
+- CLI for full release loop
+- Laravel + Nova reference backend
+- 3 example apps validating the protocol
+- 81 unit tests + Detox E2E suite
+- React marketing/dashboard site with full observability stack (Sentry + Clarity + Amplitude)
+- 7-day full-audit cooldown tracker
+
+### Roadmap (what's next)
+
+- **More example apps** — Vue + Capacitor, Svelte + Capacitor (the protocol is framework-agnostic; the examples should reflect that)
+- **Hosted SaaS option** — for teams who don't want to self-host the Laravel backend. Will be opt-in; self-host stays MIT and primary
+- **More CLI commands** — audit logs export, metrics export, batch operations
+- **Plugin: incremental bundle updates** — instead of pushing the full bundle, push only the diff. Bigger lift, big wins on bandwidth at scale
+- **Plugin: signed bundles** — code-sign-grade integrity on top of the SHA-256 check, for teams with stricter compliance needs
+- **More backend implementations** — reference Express server (currently in example apps) graduating into a maintained alternative backend; potentially a Cloudflare Workers reference
+
+### How to contribute
+
+The project is MIT-licensed. Contributions welcome at every level:
+
+- **Bug reports** — open an issue with a reproduction in one of the example apps. The faster I can reproduce, the faster I can fix.
+- **Documentation PRs** — anything from typo fixes to whole sections. Docs are MD files in `docs/`.
+- **Plugin features** — propose first via an issue (so we don't duplicate effort), then PR.
+- **Backend features** — same flow.
+- **Example apps** — if you've integrated the plugin against a stack we don't have an example for (Vue, Svelte, etc.), a PR adding it is high-value.
+- **Translations** — the marketing site is English-only currently; PRs adding i18n welcome.
+
+### What I'm NOT looking for
+
+- Driveby refactors with no issue link
+- "Add my favorite framework" without an example app to back it up
+- License changes (MIT stays MIT — non-negotiable)
+
+### How to follow
+
+The project ships from a single monorepo. Watching the repo + following the release notes is the highest-signal subscription. The marketing site has a changelog page if you prefer that surface, and the `#NativeUpdate10` + `#NativeUpdateInside` social series cover features and architecture stories as they ship.
+
+**👉 https://nativeupdate.aoneahsan.com — repo, docs, changelog all linked**
+
+#NativeUpdate #OpenSource #ContributingMatters #Aoneahsan #BestOpenSourceCommunityProject
+
+---
+
+## End of Posts Batch 02
+
+10 posts, each 2700–2900 chars. Mark `USED — ` once shared.