ismailhrifat/dashtype

1. DashType is a native macOS text-expander built in Swift/SwiftUI. The repo is split into a UI/application layer and a separate core domain package, with Xcode as the primary build system and a SwiftPM package manifest alongside the Xcode project.

2. The core boundary lives under Sources/DashTypeCore. It contains the snippet domain model, folder organization, matching logic, local store, and the transfer document used for import/export. This is the repo’s main non-UI subsystem and is where snippet data rules are centralized.

3. The app boundary lives under Sources/DashTypeApp. This layer owns the macOS experience: dashboard, settings, menu bar UI, snippet editor, and authentication sheet. These views orchestrate user actions but rely on core types for snippet data and matching.

4. Text expansion is the runtime hot path. User keystrokes in other apps are observed through macOS Accessibility permissions; the trigger text is matched against stored snippets, then the replacement engine performs the expansion. The TextExpansionController and TextReplacementEngine are the key pieces bridging system input events to snippet output.

5. Snippet commands are part of the expansion pipeline rather than the UI. The editor exposes command-aware content such as {cursor}, {clipboard}, and {addtext}, and the core matcher/store/processing layer must preserve these semantics when a trigger is resolved into final inserted content.

6. Local storage is the default data boundary. The app is described as local-first, so snippets and preferences live on the Mac and are available offline. SnippetStore and AppPreferences are the most likely persistence anchors, with rich text and plain text both preserved for each snippet.

7. Cloud sync is optional and isolated behind CloudSyncManager and CloudSyncAuthSheetView. The README specifies Firebase Authentication plus Cloud Firestore, with email/password sign-in, one-time merge on first enablement, conflict handling that prefers newer snippet versions, and background upload when connectivity returns.

8. The app has a clear system-permission boundary. PermissionManager handles Accessibility access, while LaunchAtLoginManager manages startup behavior. These concerns affect whether expansion can run at all and whether the app remains active in the background.

9. The UI is organized around a dashboard/settings workflow plus a menu bar presence. DashboardView manages snippet/folder browsing, SnippetEditorView and MarkdownTextEditor handle snippet authoring, SettingsView exposes app controls, and MenuBarContentView supports running the app without a full window.

10. Import/export is a separate data-transfer path. SnippetTransferController and SnippetTransferDocument provide snippet backup and migration between Macs, distinct from cloud sync because it is user-initiated and file-based rather than continuous.

11. The app entry point is split between DashTypeApp.swift and AppDelegate.swift, reflecting a modern SwiftUI app with some AppKit lifecycle integration. That split is typical for macOS apps that need menu bar, launch-at-login, or accessibility-related behavior beyond pure SwiftUI.

12. Tests are concentrated on the core layer in Tests/DashTypeCoreTests, covering matcher, store, and command processing behavior. That placement reinforces the architecture: business rules are expected to stay stable independently of the macOS UI.

13. Supporting infrastructure includes Config/ for plist and entitlements, Assets.xcassets for app icon/resources, and Tools/generate_app_icon.swift for asset generation. The presence of GoogleService-Info.plist in config is the main external-service indicator, tying the app to Firebase for sync.