abhi5515521c/estatesync_ios

1. Overall shape

- EstateSync is a two-tier property management system:

- a native iOS SwiftUI client for tenants/owners,

- a Node.js/Express API backed by Prisma and either SQLite by default or MySQL optionally.

- The app is centered on remote data access; the iOS layer does not appear to own persistence beyond client-side models/services.

2. Client application boundary

- The iOS app lives under Estatesync/Estate-sync and is built with SwiftUI.

- The client boundary is organized into:

- Core for shared models, API access, colors/fonts,

- Features for screen-level modules,

- SharedUI for reusable controls and navigation.

- This is a classic presentation + view model structure, with feature-specific state logic separated from views.

3. Primary UI composition

- EstatesyncApp.swift and ContentView.swift are the app entry points.

- SharedUI/Navigation/MainTabView.swift suggests the main shell is tab-based, likely switching between dashboard, listings, payments, maintenance, and profile.

- SharedUI/Components/FloatingLabelTextField.swift indicates a reusable input component used by auth or profile forms.

4. Client feature modules

- Features/Auth handles sign-in/authentication UI and state.

- Features/Dashboard contains the tenant dashboard and its view model, likely aggregating current lease, next payment, and maintenance status.

- Features/Listings handles property browsing/listing views.

- Features/Payments handles payment history or upcoming payments.

- Features/Maintenance handles maintenance request creation and request lists.

- Features/Profile contains user account/profile display.

5. Client data and state layer

- Core/Models/Models.swift contains shared data structures used by the SwiftUI screens and API decoding.

- Core/Models/Database.swift likely abstracts local database/configuration concerns, but the repo strongly suggests the client primarily consumes backend data rather than owning its own database.

- Each feature has a corresponding ViewModel, which is the main state boundary between network/data and the SwiftUI view.

6. Client-to-backend communication

- Core/Services/APIService.swift is the integration point to the backend API.

- The README explicitly says the app targets an API URL such as http://localhost:5050/api, so the mobile app depends on a configurable base URL.

- This service layer is the key architectural seam: UI/ViewModels call into APIService, which exchanges JSON with the backend.

7. Backend service boundary

- The backend is under backend/ and uses Express (server.js) as the HTTP layer.

- Prisma is the persistence abstraction in backend/prisma/schema.prisma, with seed.js for initial data loading.

- The backend is therefore the system of record for users, properties, listings, leases, payments, and maintenance requests.

8. Data model and seeded domain

- The CSV files at the repo root map directly to the business entities:

- users,

- properties,

- property listings,

- lease agreements,

- payments,

- maintenance requests.

- The seed process imports these datasets into the database, which means the repo is designed to come up with realistic tenant/property data immediately after schema push + seed.

9. Role-based access and business flows

- The README calls out RBAC for Owners and tenants, so the backend likely controls access to owner/admin versus tenant views.

- The most important cross-cutting flows are:

- login/authentication,

- dashboard aggregation,

- property/listing browsing,

- payment retrieval,

- maintenance request retrieval/submission.

- These are domain flows rather than isolated screens, and they likely converge on the same API and database tables.

10. Database strategy

- Default persistence is SQLite via DATABASE_URL="file:./dev.db", minimizing setup for local development.

- The same Prisma schema can target MySQL when pointed at a MySQL connection string, which makes the backend portable across environments.

- That means the persistence boundary is Prisma-first, with the database engine swappable underneath.

11. Startup and deployment model

- Backend startup is npm run dev from backend/, with schema provisioning done by prisma db push and seeding by prisma db seed.

- The iOS app is launched separately from Xcode via Estatesync.xcodeproj.

- This is a loosely coupled local-dev architecture: mobile client and API run as separate processes, linked only by HTTP.

12. Repo layout note

- There are two similarly named app trees: Estatesync/Estate-sync/... and PropManage/PropManage/....

- They appear to contain the same SwiftUI feature structure, suggesting either a duplicated copy, an in-progress refactor, or a legacy/current app layout.

- For diagramming, treat them as the same client architecture unless the project intentionally uses both.

13. Best diagram boundaries

- Draw three main boxes:

- iOS SwiftUI app: Views, ViewModels, shared UI, APIService, models.

- Express/Prisma backend: API server, business logic, auth/RBAC, seed/schema.

- Database: SQLite default or MySQL optional.

- Show CSV seed files feeding only the backend database initialization path, not the iOS client.