native-update 1.4.7 → 1.4.9

package/docs/CHANGELOG.md

@@ -5,6 +5,22 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.4.9] - 2026-03-11
+
+### Added
+- Firestore-backed manifest reads through `backendType: 'firestore'`
+- Secure manifest lookup support via `apiKeys/{apiKey}/manifests/{channel}`
+- Concrete no-cost backend implementation guide for `website + Firestore + Google Drive`
+
+### Changed
+- Website dashboard publish flow aligned to Google Drive asset uploads plus Firestore manifest publishing
+- Website dashboard configuration/docs now recommend Firestore instead of the old `/api/updates` path
+- Package config types now expose Firestore configuration for production app integration
+
+### Fixed
+- Manifest publishing now writes the full manifest shape to both secure and compatibility Firestore paths
+- Google Drive asset uploads now preserve correct filenames for ZIP bundles and generated manifest files
+
 ## [1.4.5] - 2026-02-25
 
 ### Changed

package/docs/examples/firebase-backend-example.md

@@ -0,0 +1,27 @@
+# Firebase Backend Example
+
+This example describes a serverless backend approach using Firebase services for manifests and bundle delivery.
+
+## What It Covers
+
+- Firestore-backed manifest strategy
+- Cloud Functions integration pattern
+- Firebase-centric deployment approach
+
+## Recommended Setup Flow
+
+1. Start with baseline architecture docs:
+   https://nativeupdate.aoneahsan.com/docs/server-requirements
+2. Review backend template guidance:
+   https://nativeupdate.aoneahsan.com/docs/guides/BACKEND_TEMPLATES_GUIDE
+3. Apply rollout and channel strategies:
+   https://nativeupdate.aoneahsan.com/docs/guides/channel-management
+
+## Related Docs
+
+- Dashboard Guide:
+  https://nativeupdate.aoneahsan.com/docs/guides/dashboard-guide
+- End-to-End Workflow:
+  https://nativeupdate.aoneahsan.com/docs/guides/end-to-end-workflow
+- Security Best Practices:
+  https://nativeupdate.aoneahsan.com/docs/guides/security-best-practices

package/docs/examples/node-express-backend-example.md

@@ -0,0 +1,28 @@
+# Node.js + Express Backend Example
+
+This example shows a self-hosted backend for serving update manifests and bundles using Node.js + Express.
+
+## What It Covers
+
+- Bundle upload endpoint
+- Manifest responses for client update checks
+- Local file-based storage flow for development
+
+## Recommended Setup Flow
+
+1. Understand server requirements:
+   https://nativeupdate.aoneahsan.com/docs/server-requirements
+2. Review backend patterns:
+   https://nativeupdate.aoneahsan.com/docs/guides/BACKEND_TEMPLATES_GUIDE
+3. Apply security requirements before production:
+   https://nativeupdate.aoneahsan.com/docs/BUNDLE_SIGNING
+   https://nativeupdate.aoneahsan.com/docs/guides/security-best-practices
+
+## Related Docs
+
+- Deployment Guide:
+  https://nativeupdate.aoneahsan.com/docs/guides/deployment-guide
+- CLI Reference:
+  https://nativeupdate.aoneahsan.com/docs/cli-reference
+- Troubleshooting:
+  https://nativeupdate.aoneahsan.com/docs/guides/troubleshooting

package/docs/examples/react-capacitor-example.md

@@ -0,0 +1,29 @@
+# React + Capacitor Example App
+
+This example demonstrates the frontend integration of `native-update` in a React + Capacitor application.
+
+## What It Covers
+
+- Plugin initialization in app startup
+- Checking for updates
+- Downloading and applying OTA bundles
+- Basic troubleshooting flow
+
+## Recommended Setup Flow
+
+1. Install and configure the plugin:
+   - https://nativeupdate.aoneahsan.com/docs/getting-started/installation
+   - https://nativeupdate.aoneahsan.com/docs/getting-started/configuration
+2. Implement update checks:
+   - https://nativeupdate.aoneahsan.com/docs/examples/basic-usage
+3. Review advanced patterns:
+   - https://nativeupdate.aoneahsan.com/docs/examples/advanced-scenarios
+
+## Related Docs
+
+- End-to-End Workflow:
+  https://nativeupdate.aoneahsan.com/docs/guides/end-to-end-workflow
+- Live Updates API:
+  https://nativeupdate.aoneahsan.com/docs/api/live-update-api
+- Troubleshooting:
+  https://nativeupdate.aoneahsan.com/docs/guides/troubleshooting

package/docs/guides/no-cost-backend-implementation-plan.md

@@ -0,0 +1,77 @@
+# No-Cost Backend Implementation Plan
+
+This document is the concrete production plan for the `website` sub-project using a no-cost backend built from browser code, Firestore, and Google Drive.
+
+## Architecture
+
+- Dashboard: `website`
+- Metadata backend: Firestore
+- Bundle storage: user-owned Google Drive
+- App manifest read path: `apiKeys/{apiKey}/manifests/{channel}`
+- Compatibility read path: `manifests/{appId}_{channel}`
+- Human discovery endpoints: `/sitemap`, `/feed`
+- Machine discovery endpoints: `/sitemap.xml`, `/feed.xml`
+
+## Publish Flow
+
+1. User signs into the website dashboard.
+2. User connects Google Drive.
+3. User uploads a ZIP bundle from the dashboard.
+4. The website computes bundle checksum and manifest metadata in-browser.
+5. The website uploads the ZIP and generated manifest JSON to Google Drive.
+6. The website writes build history to Firestore.
+7. The website updates both manifest documents:
+   - `apiKeys/{apiKey}/manifests/{channel}`
+   - `manifests/{appId}_{channel}`
+8. Apps configured with `backendType: 'firestore'` read the latest manifest and download the published ZIP from Google Drive.
+
+## Firestore Collections
+
+- `apps/{appId}`
+  - dashboard-owned app registry and channel settings
+- `builds/{buildId}`
+  - uploaded build history, Drive URLs, release notes, checksums
+- `apiKeys/{apiKey}`
+  - secret lookup key metadata for manifest access
+- `apiKeys/{apiKey}/manifests/{channel}`
+  - primary manifest document for app update checks
+- `manifests/{appId}_{channel}`
+  - compatibility manifest document for existing readers
+
+## Security Model
+
+- Firestore rules allow public read only for manifest documents that apps need.
+- App, build, and API key documents stay owner-restricted.
+- Browser code does not hold server secrets.
+- Google Drive is used because the asset owner controls storage without paid compute.
+
+## Website Responsibilities
+
+- Keep dashboard configuration examples aligned with Firestore backend usage.
+- Keep upload flow routed through `uploadBundle()`.
+- Keep footer links to `/sitemap` and `/feed`.
+- Keep `scripts/generate-sitemap.mjs` current whenever routes or public content change.
+
+## Package Responsibilities
+
+- Support Firestore manifest reads through `backendType: 'firestore'`.
+- Accept `firestore.projectId` and optional `firestore.apiKey` in public config types.
+- Preserve HTTP backend support for users who self-host.
+
+## When A Separate Backend Is Justified
+
+Only add Laravel or another backend if one of these becomes mandatory:
+
+- server-held private signing keys
+- private asset proxy/download authorization
+- scheduled rollout jobs or cleanup tasks
+- heavy processing such as delta generation outside the browser
+
+## Production Checklist
+
+- Dashboard can connect Google Drive
+- ZIP publish updates Firestore manifest documents
+- App config snippets use `backendType: 'firestore'`
+- `/sitemap`, `/sitemap.xml`, `/feed`, and `/feed.xml` build successfully
+- Firestore rules are deployed
+- Google OAuth and Firebase environment variables are configured

package/docs/guides/no-cost-firestore-google-drive-backend.md

@@ -0,0 +1,60 @@
+# No-Cost Backend Architecture
+
+This project's recommended zero-cost backend uses:
+
+- `website/` as the dashboard and publishing UI
+- Firestore for manifest metadata and rollout state
+- Google Drive for bundle and manifest file storage
+- direct browser uploads instead of server-side processing
+
+## Why this architecture
+
+- avoids Firebase Functions and other paid compute
+- keeps bundle ownership in each user's own Google Drive
+- uses Firestore's free tier for lightweight manifest reads
+- supports staged rollout metadata without custom backend code
+
+## Publish flow
+
+1. User signs in to the website.
+2. User connects Google Drive.
+3. User uploads a ZIP bundle.
+4. Website calculates SHA-256 and generates a file manifest in-browser.
+5. Website uploads the bundle and generated manifest JSON to Google Drive.
+6. Website writes the published version into Firestore.
+7. Apps read Firestore manifests and download the bundle from Google Drive.
+
+## Firestore documents
+
+Recommended secure path:
+
+- `/apiKeys/{apiKey}/manifests/{channel}`
+
+Backward-compatible path:
+
+- `/manifests/{appId}_{channel}`
+
+The dashboard publishes both today. New integrations should prefer the API key path.
+
+## Operational limits
+
+- bundle files must be reachable by the app, so Google Drive files are published with direct-download access
+- there is no trusted server for private signing keys, cron jobs, or private bundle proxying
+- if you later need private downloads, server-side signing, scheduled jobs, or delta generation, add a real backend
+
+## Required dashboard capabilities
+
+- app creation with generated API keys
+- Google Drive connect/disconnect
+- ZIP bundle upload and publish
+- rollout editing in Firestore
+- copy-paste integration config for apps
+
+## Production checklist
+
+- connect Google Drive before first publish
+- publish ZIP bundles only
+- keep API keys out of public repos
+- sign bundles client-side or via CLI if you need signature verification
+- verify Firestore rules before launch
+- test download/install flow on real devices

package/package.json

@@ -1,10 +1,10 @@
 {
   "name": "native-update",
-  "version": "1.4.7",
+  "version": "1.4.9",
   "engines": {
     "node": ">=24.13.0"
   },
-  "description": "Foundation package for building a comprehensive update system for Capacitor apps. Provides architecture and interfaces but requires backend implementation.",
+  "description": "Capacitor update plugin with live updates, app update checks, app reviews, and support for HTTP or Firestore-backed release delivery.",
   "type": "module",
   "main": "dist/plugin.cjs.js",
   "module": "dist/esm/index.js",