nextcloud/ios

<explanation>

1. Identify project type and purpose

- This is a native iOS client application for Nextcloud (“Nextcloud iOS app”) plus a set of Apple app extensions:

• Main iOS application (“iOSClient”)

• File Provider Extension (+ UI)

• Share Extension

• Notification Service Extension

• Widget Extension

• Widget Dashboard Intent Handler

- Purpose: allow users to browse, upload, sync, share files and view dashboards on a Nextcloud server, plus support push notifications and Today widgets.

2. Analyze the file structure

- Top‑level folders correspond to Xcode targets:

• Brand – shared assets, launch screens, common code (e.g. Database.swift, NCBrand.swift)

• ExternalResources – helper classes (e.g. NCApplicationHandle.swift)

• File Provider Extension & File Provider Extension UI – app extension to expose Nextcloud files in the iOS Files app

• Share – share extension UI and logic for sharing to Nextcloud

• Notification Service Extension – intercept and decrypt FCM push notifications

• Widget – Today/Lockscreen/Home Screen widgets with Intent definitions (multiple widget providers: Dashboard, Files, Lockscreen, Toolbar)

• WidgetDashboardIntentHandler – custom Siri/Shortcuts handler for widget intents

• iOSClient – main app, subdivided into modules (Login, Main, Files, Media, Assistant, Settings, Networking, Data, Utilities, Viewer, etc.)

• Tests – unit, integration, UI tests

- CoreData or some local database is managed by NCManageDatabase+*.

- Networking layer under iOSClient/Networking handles WebDAV, E2EE, uploads, downloads, synchronization.

- App uses Firebase (GoogleService‑Info.plist) for push.

3. Review README insights

- Confirms full‑blown iOS file manager with extensions

- Mentions Firebase for notifications

- Testing relies on a local or CI Nextcloud server via WebDAV/OCS APIs

- Architecture not diagrammed, but many Xcode schemes map to targets.

4. Designing the system diagram

a. Main components (each as a distinct box):

1. iOSClient (Main App)

– UI Modules (Login, Main TabBar, Files, Media Viewer, Activity, Settings…)

– Networking Layer (NCNetworking + sub‑modules: WebDAV, E2EE, Upload, Download, Sync)

– Data Layer (NCManageDatabase + CoreData)

– Utilities (caching, deep link handler, encryption, helpers)

2. File Provider Extension

– FileProviderDomain, Enumerator, Item, Utility

– UI Extension (DocumentActionViewController)

3. Share Extension

– NCShareExtension (UI + data source delegates + networking)

4. Notification Service Extension

– NotificationService.swift (decrypt/enrich incoming push)

5. Widget Extension

– WidgetBundles: Dashboard / Files / Lockscreen / Toolbar

– Intent definitions + providers + views

6. WidgetDashboardIntentHandler

7. External Services

– Nextcloud Server (WebDAV/OCS API)

– Firebase Cloud Messaging

b. Relationships and data flow

- iOSClient UI ⇄ Networking ⇄ Nextcloud Server

- Networking ⇄ Data Layer for caching/sync (write/read)

- Extensions (File Provider, Share, Widget, Notification) share code from Brand, ExternalResources, and common frameworks in iOSClient (Networking, Data)

- Push: Nextcloud Server → Firebase → Notification Service Extension → App/UI

- Widget: Widget Extension pulls data from local cache (Data Layer) or directly via Networking to server depending on widget provider

- Share Extension: invoked by system share sheet, uses Networking to post to Nextcloud Server, updates Data Layer

- File Provider Extension: mounted into Files.app, uses FileProvider APIs to enumerate, download, upload via Networking/Data Layer

c. Architectural patterns / principles

- Modular target‑based separation (one Xcode target per extension/feature)

- MVC for UI modules (ViewControllers + DataSource + Models + Networking)

- Single networking façade (NCNetworking) with extension methods for each API concern

- Centralized local persistence (NCManageDatabase)

- Dependency reuse: extensions leverage common code via shared frameworks/files in the repo

d. Key technologies & frameworks

- Swift, Objective‑C bridging headers (for E2EE, passcode)

- UIKit, WidgetKit, FileProvider, Intents frameworks

- CoreData or SQLite wrapper in NCManageDatabase

- Firebase Cloud Messaging for push

- WebDAV/OCS over HTTPS

- SwiftLint, GitHub Actions for CI

5. Guidelines for tailoring diagram to this project

- Full‑stack mobile architecture emphasis: clearly separate the Main App from each App Extension target

- Show the central Networking and Data layers as shared services consumed by all targets

- External boxes: Nextcloud Server API and Firebase Cloud Messaging

- For extensions, indicate the host process (“Files.app” for File Provider) or system components (“Share sheet” for Share Extension, “Notification Center” for Notification Extension, “Home Screen” for Widget)

6. Diagram best practices

- Use clear labels on each box: target name, role (e.g., “File Provider Extension – provides cloud files in Files.app”)

- Draw directional arrows for data flows: e.g., UI → Networking → Server; Server → FCM → Notification Extension → App

- Color‑code shapes:

• Main App (blue)

• Extensions (green)

• Shared services/libraries (purple)

• External systems (orange)

- Use different shapes or styles to distinguish layers:

• Rectangles for targets

• Rounded boxes for shared libraries/services

• Cylinders for local database

7. Emphasis on detail

- Capture every Xcode target as a separate component

- Illustrate how each extension reuses common code (Networking, Data, Utilities)

- Show all external dependencies (Nextcloud server, Firebase, system host apps)

- Ensure directional arrows indicate not just “calls” but also “data sync” and “push events”

- Provide a legend for colors and shapes to keep the diagram self‑contained

</explanation>