Leser
PDF-Betrachter für macOS 15+, gemacht zum Lesen und gebaut mit SwiftUI und PDFKit. Er kann nur anzeigen, nichts bearbeiten.
Leser ist kostenlos, quelloffen (Apache-Lizenz 2.0, siehe LICENSE), werbefrei und übermittelt keine Daten: kein Tracking, keine Analyse, keine eigenen Netzwerkverbindungen. Es nutzt ausschließlich Apple-Frameworks. Wer die Entwicklung unterstützen möchte, kann unter Leser → Über Leser ein freiwilliges Trinkgeld über den App Store geben; es schaltet nichts frei.
Nicht Teil des lizenzierten Werks sind die Kennzeichen des Projekts: der Name „Leser“, das App- und das Dokumentsymbol, die Monogramme und scripts/make_icon.swift, das die Symbole zeichnet. Was damit erlaubt ist, steht in TRADEMARKS.md — kurz gesagt: über Leser reden und die unveränderte App weitergeben ja, eine Abspaltung unter diesem Namen nein. NOTICE hält den Umfang fest und ist nach Abschnitt 4(d) der Lizenz bei jeder Weitergabe mitzuführen. Der Code selbst bleibt frei verwendbar.
Für die Veröffentlichung im Mac App Store liegen unter docs/ die vorbereiteten Texte (app-store.md), die Datenschutzerklärung (datenschutz.md), die Support-Seite (support.md) und die Screenshots. Was sich von Version zu Version geändert hat, steht in CHANGELOG.md (englisch: CHANGELOG.en.md).
Die Oberfläche gibt es auf Deutsch und Englisch. Die Texte liegen im String-Katalog Resources/Localizable.xcstrings; die Schlüssel sind die deutschen Sätze. Neue Texte holt man mit xcodebuild -exportLocalizations -project Leser.xcodeproj -localizationPath <Ordner> -exportLanguage en heraus und trägt die Übersetzung im Katalog nach.
Bauen
Leser ist ein Xcode-Projekt (Leser.xcodeproj, Xcode 27 oder neuer, macOS 15+). In Xcode öffnen und mit ⌘R starten; für einen signierten Build unter „Signing & Capabilities“ das eigene Team eintragen.
Ohne Xcode-Oberfläche:
./build.sh
Das baut build/Leser.app mit xcodebuild (mit derselben Sandbox wie im App Store) und installiert die App nach /Applications. Läuft Leser gerade, wird es vorher beendet und danach wieder geöffnet. Stammt die installierte App aus dem App Store, lässt build.sh sie unangetastet und meldet nur den Build. Nur bauen, ohne zu installieren: ./build.sh --no-install.
Nennt Config/Local.xcconfig eine Team-ID, signiert build.sh mit diesem Team wie beim Archiv für den App Store; Xcode legt das Entwicklungsprofil bei Bedarf an. Ohne Team-ID, oder mit --adhoc, signiert es ad hoc und braucht kein Entwicklerkonto.
Die Versionsnummer (z. B. 1.0) steht im Projekt unter „Version“ (MARKETING_VERSION) und wird von Hand erhöht. Die Build-Nummer in Klammern steht als CURRENT_PROJECT_VERSION in Config/Leser.xcconfig und ist damit eingecheckter Zustand: Xcode und build.sh lesen dieselbe Zahl, sie kann nicht sinken, und im Verlauf sieht man, welcher Commit welchen Build ergeben hat.
Vor jedem Upload in den App Store einmal ./scripts/bump-build.sh ausführen und mitcommitten — App Store Connect verlangt für jeden Upload eine höhere Nummer als für den vorigen. Die eingereichten Stände tragen Tags wie v1.0-build26.
Nachträglich lässt sich die Nummer nicht setzen: CFBundleVersion wird beim Verarbeiten der Info.plist eingesetzt, und ein Skript, das die fertige Plist im Produkt ändert, wird von Xcode danach wieder überschrieben.
Das App-Icon und das Dokumentsymbol werden von scripts/make_icon.swift gezeichnet: das App-Icon in den Asset-Katalog, das Dokumentsymbol nach Resources/PDFDocument.icns. Nach Änderungen an der Zeichnung im Projektordner swift scripts/make_icon.swift ausführen. Das Dokumentsymbol zeigt macOS nur, wenn Leser die Standard-App für PDFs ist, und auch dann meist nur dort, wo es keine Seitenvorschau gibt.
scripts/make_manual.swift zeichnet docs/Leser-Handbuch.pdf, ein dreizehnseitiges Handbuch mit Gliederung und vier Bildschirmfotos aus docs/screenshots/. Es erklärt die Bedienung, dient zugleich als Beispieldokument und ist in den Screenshots für den App Store zu sehen – die Bildschirmfotos im Handbuch zeigen also das Handbuch selbst. Die Texte stehen in docs/handbuch/de.md und docs/handbuch/en.md, das Format ist oben in den Dateien beschrieben. Nach Änderungen im Projektordner swift scripts/make_manual.swift ausführen; swift scripts/make_manual.swift en schreibt die englische Fassung nach docs/Leser-Manual.pdf. Beide Fassungen kopiert das Skript außerdem nach Resources/: Sie liegen im App-Bundle, und „Hilfe → Leser-Handbuch“ öffnet die zur App-Sprache passende direkt in Leser, offline und immer zur installierten Version passend.
Projektstruktur
Sources/Leser/: Quellcode; neue Dateien gehören automatisch zum ProjektResources/: Asset-Katalog mit App-Icon, Monogramme, Lokalisierung, PrivacyInfo.xcprivacyConfig/Info.plist, Config/Leser.entitlements: App-Einstellungen und Sandbox-Berechtigungen (Lese- und Schreibzugriff auf selbst gewählte Dateien, geschrieben wird nur bei „Bild sichern unter …“; das Merken solcher Dateien für Verweise auf andere Dokumente; Drucken)Config/Leser.xcconfig: Build-Einstellungen; bindet optional Config/Local.xcconfig einTests/LeserTests/: Unit-Tests; neue Dateien gehören automatisch zum Test-Targettestdata/: Dokumente zum Ausprobieren von Hand, darunter zwei mit Links zwischen den Dateien (swift scripts/make_link_tests.swift)
Tests
./test.sh
Das führt die Unit-Tests aus (Swift Testing). Sie laufen im Debug-Build von Leser, der eigene Einstellungen hat, und lassen die der installierten App unberührt. Die PDFs, die sie brauchen, erzeugen sie selbst, mit genau dem Text, den Seitenbeschriftungen, Links und Kennungen, um die es im Test geht. Einzelne Gruppen oder Tests: ./test.sh PageReferenceTests oder ./test.sh PageReferenceTests/pageLabelsDecide(). Das vollständige Protokoll steht in .build/test.log.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
