Convert HTML Utility App Mobile

1. Project Overview
This is a fully functional calendar and reminder app for a global user base, currently built as a single-page web app (HTML, CSS, vanilla JavaScript, plus a small number of external libraries) and hosted on a modern static-hosting platform.
It includes an active feature set (a calendar section, reference/content sections, a classifieds section, and a personal module — a private space for reminders, a small income/expense register, saved logins, links, and notes).
We are ready to package this as native iOS and Android apps. Apple Developer Program and Google Play Console accounts are already set up and verified under our ownership.
2. Current State — What Already Exists
• Fully working single-file HTML/CSS/JS web app, live today.
• External dependencies loaded via CDN: two Google Fonts (a rounded display font and a companion body font), a carousel/slider library, and a client-side PDF generation library (for in-app report generation). None require a build step today.
• A built-in personal module using browser IndexedDB for on-device storage of reminders, an income/expense register, saved website logins (with masked passwords), links, and notes — full add/edit/delete already implemented.
• An Export/Import feature producing a single JSON backup file covering all personal-module data — this is the intended bridge format for migrating data into native on-device storage (see Section 4).
• A written internal specification (attached) documenting exactly which features require native infrastructure and why, plus two explicit “Development Note” sections describing security and currency work deliberately deferred from the web build.
3. Goal
Wrap the existing hosted web app so it installs and runs natively on iOS and Android, and implement the specific native capabilities the web version cannot provide — most importantly, reliable reminder notifications that fire even when the app is closed. Everything else in the current web experience should carry over as-is unless noted below.
4. In Scope
4.1 Wrapper
• Wrap the existing hosted site using Capacitor, Cordova, or a comparable wrapper — bidder's choice, provided the result meets current Apple App Store and Google Play guidelines.
• Confirm whether any embedded or linked content requires Google account sign-in (e.g. Google Forms, Sheets). Google blocks OAuth login inside embedded WebViews — any such flow must open in the system browser instead, not the app's internal WebView. Please audit and flag any instance of this during discovery.
4.2 Native Notification Engine (core requirement)
This is the single most important piece of native functionality in this project. All reminders are based on dates already known and stored on the device (birthdays, anniversaries, appointments) — nothing needs to be triggered from a server. These should be implemented as native LOCAL notifications (e.g. Capacitor's Local Notifications plugin), scheduled on-device, firing reliably whether the app is foregrounded, backgrounded, or fully closed, on both iOS and Android. No remote push service (APNs/FCM) or backend is required for this feature. If a future phase adds server-triggered alerts (e.g. broadcast announcements), that would be a separate, explicitly scoped addition — please do not include remote push infrastructure in this quote unless you believe it's genuinely required, and explain why.
• The app's existing calendar-section reminders (currently best-effort web push).
• The personal module's reminder engine: birthdays, anniversaries, appointments, occasions, and program reminders, each with a configurable lead time (same day / 1 day / 3 days / 1 week before).
A single shared native notification-scheduling module should serve both, rather than two separate implementations.
4.3 Personal Module Security Layer (currently deferred, must be built for native)
The web build deliberately ships without a PIN lock, since a forgotten PIN with no recovery path would mean total data loss on a fragile browser-storage backend. This is documented as required — not optional — scope for the native build. Full detail is in the attached spec document; summary:
• PIN lock to enter the personal module.
◦ A recovery key generated once at setup (shown to the user once, theirs to store) — this is what makes a forgotten PIN survivable, following the standard pattern used by password managers.
◦ “Forgot PIN?” flow: verify the recovery key, allow setting a new PIN without losing data.
◦ Auto-lock on idle/backgrounding, reinstated now that there's an actual PIN gate to protect.
• Encrypted backup export/import, using the recovery key (not the PIN) as the encryption key — a 4-digit PIN is too weak to protect a file that might sit in an inbox for years.
4.4 Data Migration
Any data a user has already entered in the web trial (via IndexedDB) should be able to move into the native app's on-device storage (SQLite or equivalent). The existing Export/Import JSON format (already built and working in the web app) is the intended bridge — the native app's first-run flow should be able to import this format. If a different approach is proposed, please explain the trade-off in your quote.
4.5 Store Compliance & Polish
• App icons, launch/splash screens, and permission-usage strings (e.g. notifications, storage) for both platforms.
• Any other tweaks required to satisfy current App Store and Google Play review guidelines — in particular Apple's Guideline 4.2 (“minimum functionality”), which scrutinizes apps that are thin WebView wrappers. Please note in your quote how you intend to address this, given the app does include genuine native functionality (notifications, on-device storage, native UI in the personal module).
5. Explicitly Out of Scope for This Phase
• In-app purchases. Not part of this phase — undecided whether we'll add a premium tier later. Please do not price this in; we may discuss it separately in a future phase.
• Rebuilding or redesigning any existing web functionality that already works — the wrapper should preserve current behavior, not rebuild it.
• Any backend or server component — reminders should be handled entirely via on-device local notifications, with no server dependency.
6. Deliverables
• Signed, submitted builds for both iOS and Google Play.
• Guidance through App Store Connect and Google Play Console submission, remaining engaged through any review feedback until both apps are live.
• Clean, well-commented wrapper source and build instructions sufficient for us to reproduce future updates ourselves.
• A short written note on how the native notification engine and the PIN/recovery-key system work, so we can maintain them going forward.
7. Acceptance Criteria
• Both apps pass Apple and Google review without required resubmissions.
• Reminder notifications (both the calendar section's reminders and the personal module's reminder engine) register and are received while the app is foregrounded, backgrounded, and fully closed, on real devices — for both platforms.
• PIN lock, recovery-key setup, “Forgot PIN?” recovery, and auto-lock all function correctly on real devices.
• Existing web-trial data can be imported into the native app via the Export/Import format without loss.
• No missing assets or library conflicts from the existing external scripts (fonts, carousel library, PDF generation library).
• Clean, well-commented wrapper/build instructions delivered, sufficient to reproduce future updates.
8. Timing
Flexible, but we'd like to reach both stores within the next few weeks. Please quote your realistic timeline alongside price — we are more interested in an accurate, complete quote than the fastest one.