Glossar

App-Entwicklung, verständlich erklärt.

Fachbegriffe, die in Gesprächen über Apps und Software immer wieder fallen, in ein bis drei Sätzen. Für alle, die eine App weiterentwickeln lassen oder ein Team verstärken wollen, ohne selbst Entwickler zu sein.

Sprachen und Frameworks

Flutter: Ein Framework von Google, mit dem aus einer Codebasis Apps für iOS und Android und auch Weboberflächen entstehen. Das spart ein zweites Team und hält beide Plattformen auf demselben Stand.
Dart: Die Programmiersprache hinter Flutter. Von Google entwickelt, gut lesbar und darauf ausgelegt, dass Apps flüssig laufen.
Swift: Apples Programmiersprache für Apps auf iPhone, iPad und Apple Watch. Sie kommt zum Einsatz, wenn eine App nativ entsteht oder eine Flutter-App Funktionen braucht, die nur iOS bietet.
SwiftUI: Apples Baukasten für Oberflächen in Swift. Bildschirme werden beschrieben statt Schritt für Schritt zusammengesetzt, das macht sie leichter änderbar.
Kotlin: Die Programmiersprache für native Android-Apps, auch auf dem Server einsetzbar. Sie kommt für Android-Funktionen und für Backend-Dienste zum Einsatz.
TypeScript: JavaScript mit Typen. Fehler fallen schon beim Schreiben auf statt erst beim Nutzer. Deshalb ist es Standard für größere Weboberflächen und für Dienste auf node.js.
node.js: JavaScript auf dem Server. Gut geeignet für schlanke Dienste und Schnittstellen, die eine App mit Daten versorgen.
Firebase: Ein Paket von Google-Diensten für Apps: Datenbank, Anmeldung, Dateispeicher, Push-Nachrichten. Es spart eigenen Server-Aufwand, bindet aber an Google.
Supabase: Eine quelloffene Alternative zu Firebase auf Basis der Datenbank PostgreSQL. Sie lässt sich auch selbst betreiben, etwa auf Servern in der EU.
Appwrite: Ebenfalls eine quelloffene Plattform für App-Backends mit Anmeldung, Datenbank und Dateispeicher, die man selbst betreiben kann.

Architektur und Code

Architektur: Wie die Software geschnitten ist. Sie entscheidet, ob das nächste Feature leicht oder teuer wird.
Modul: Ein abgegrenzter Teil der App mit klarer Aufgabe, zum Beispiel Anmeldung oder Auftragsverwaltung. Gute Module lassen sich ändern, ohne dass an anderer Stelle etwas bricht.
Monorepo: Mehrere Apps in einem gemeinsamen Projekt, damit gemeinsamer Code nur einmal existiert. Sinnvoll, sobald aus einer App mehrere werden.
Melos: Ein Werkzeug, das ein Monorepo mit mehreren Flutter- und Dart-Paketen verwaltet: gemeinsame Befehle, Versionen und Tests über alle Pakete hinweg.
State-Management: Wie die App ihre Daten und Zustände verwaltet, damit Bildschirme testbar bleiben.
BLoC: Ein verbreitetes Muster für State-Management in Flutter. Es trennt die Logik strikt von der Oberfläche: Ereignisse gehen hinein, Zustände kommen heraus.
Riverpod: Eine weitere Lösung für State-Management in Flutter. Sie stellt Daten und Abhängigkeiten dort bereit, wo sie gebraucht werden, und lässt sich gut testen.
Technische Schulden: Abkürzungen im Code, die später mit Zinsen zurückgezahlt werden. Jede Änderung wird dann ein bisschen teurer, bis jemand sie abbaut.

Auslieferung und Qualität

CI/CD und Pipeline: Ein automatischer Ablauf, der die App baut, testet und in die Stores lädt. Jeder im Team kann ihn starten.
DevOps: Alles, was eine App vom Code bis in die Stores bringt: Pipeline, Signierung, Store-Upload und die Werkzeuge dafür. Bei Apps geht es vor allem darum, dass jede Version auf demselben Weg ausgeliefert wird.
Codemagic: Ein Dienst für CI/CD, der auf Flutter-Apps zugeschnitten ist. Er baut iOS- und Android-Versionen in der Cloud und lädt sie in die Stores. Niemand im Team muss dafür einen Mac bereithalten.
Code Review: Vier-Augen-Prinzip, bevor Code zusammengeführt wird. Fehler fallen früh auf, und das Wissen verteilt sich im Team.
Pull Request: Der Vorschlag, eine Änderung in den Hauptstand zu übernehmen, inklusive Review. Bei GitLab heißt er Merge Request.
Merge: Das Zusammenführen einer Änderung in den Hauptstand des Codes, meist nach dem Review eines Pull Requests. Erst danach gehört sie zum Stand, aus dem das nächste Release entsteht.
Diff: Die Aufstellung der Unterschiede zwischen altem und neuem Code: welche Zeilen dazukommen, wegfallen oder sich ändern. Im Review liest das Team vor allem diese Aufstellung.
Unit-Test: Ein automatischer Test für ein kleines Stück Logik, etwa eine Berechnung. Er läuft in Sekunden und schlägt an, sobald eine Änderung etwas kaputt macht.
Widget-Test: Ein automatischer Test für einen Teil der Oberfläche in Flutter. Er prüft, ob ein Bildschirm das Richtige anzeigt und auf Eingaben richtig reagiert.
Integrationstest: Ein automatischer Test, der die App auf einem Gerät oder Emulator durchspielt, etwa vom Login bis zum abgeschickten Formular. Er prüft, ob alle Teile zusammen funktionieren.
Release: Eine Version der App, die bei den Nutzern ankommt.
TestFlight: Apples Dienst, um eine neue Version der App an Tester zu verteilen, bevor sie im App Store erscheint. Das Gegenstück bei Google ist der interne Test in der Google Play Console.
Google Play Console: Googles Verwaltung für Apps im Play Store. In der Console reicht das Team neue Versionen ein und verteilt sie an interne und geschlossene Testgruppen. Das Team pflegt den Store-Eintrag und liest Auswertungen.
Signierung: Der digitale Nachweis, dass eine App wirklich vom Herausgeber stammt und unverändert ist. Ohne gültige Zertifikate und Schlüssel nimmt kein Store ein Update an.

Mobile und Geräte

Offline-First: Die App funktioniert ohne Netz und gleicht ab, sobald wieder Verbindung da ist. Erfassungen landen zuerst auf dem Gerät, damit nichts verloren geht.
Erfassung im Feld: Daten aufnehmen über Foto, Standort, NFC und Zeitstempel, auch ohne Netz.
NFC: Near Field Communication: Funk über wenige Zentimeter. Ein Handy liest damit einen Chip aus, etwa an einem Gerät, einer Tür oder einem Ausweis. Die App auf dem Handy erkennt am Chip, wo und woran gerade jemand arbeitet.
Cross-Platform: Eine Codebasis für mehrere Plattformen, etwa iOS und Android, statt zwei getrennter Apps. Mit Flutter kommt die Weboberfläche noch dazu.
Native Entwicklung: Eine App direkt in der Sprache der Plattform bauen, also Swift für iOS und Kotlin für Android. Sinnvoll, wenn eine App sehr eng an das Gerät gebunden ist. Auch in Flutter-Apps kommen native Teile vor, etwa für besondere Hardware.
Flutter Web: Flutter für den Browser. Aus derselben Codebasis wie die App entsteht eine Weboberfläche, etwa für den Innendienst, mit denselben Datenmodellen und Regeln.

Anbindung

API: Eine Schnittstelle, über die zwei Programme miteinander sprechen, etwa die App mit dem Server. Sie legt fest, welche Daten man wie abfragen und senden kann.
REST: Die verbreitetste Art, eine API zu bauen. Daten werden über einfache Webadressen abgefragt und geändert, ähnlich wie beim Aufruf einer Webseite.
Backend: Der Teil einer Software, der im Hintergrund auf einem Server läuft: Daten speichern, Regeln prüfen, Dienste anbinden. Die App ist die Oberfläche, das Backend die Maschine dahinter.
Authentifizierung: Die Prüfung, wer sich anmeldet, etwa per Passwort, Code oder Link per E-Mail. Für Apps gibt es fertige Dienste wie Firebase Auth, Supabase oder Appwrite, die das sicher übernehmen.

Zusammenarbeit und KI

Teamverstärkung: Ein erfahrener Entwickler arbeitet für eine Zeit im bestehenden Team mit: in dessen Sprint, Repository und Abläufen. Anders als eine Agentur übernimmt er nicht das Projekt, sondern baut mit.
Zwei Systemhälften: Weboberfläche für den Innendienst und App fürs Feld, gleichwertig und aus derselben Datenquelle.
Sprint: Ein fester Arbeitszeitraum von meist zwei Wochen. Das Team setzt sich ein Ziel und zeigt am Ende ein Ergebnis vor. Danach plant es, was als Nächstes kommt.
Coding-Agent: Ein Werkzeug wie Claude Code oder Codex, das im Repository selbstständig arbeitet. Es liest den Code, plant eine Änderung, schreibt sie mit Tests und Dokumentation und führt die Prüfungen aus. Was es anfassen darf und was vor dem Merge gelten muss, steht im Harness.
Harness: Feste Regeln und Prüfungen für jeden, der Code schreibt, Mensch oder Modell. Dazu gehören Konventionen, Tests vor jedem Merge und Grenzen für das, was ein Agent nicht anfassen darf. Regeln und Prüfungen liegen als Dateien im Repository.
Claude Code: Der Coding-Agent von Anthropic, der im Terminal und im Editor arbeitet. Er liest Code, schlägt Änderungen vor und führt Aufgaben aus. Wie jedes Modell braucht er einen festen Rahmen und geprüfte Ergebnisse.
Codex: Der Coding-Agent von OpenAI. Er übernimmt Aufgaben im Repository, etwa Änderungen umsetzen oder Tests schreiben. Auch hier prüft ein Mensch die Ergebnisse, bevor sie zusammengeführt werden.
CodeRabbit: Ein KI-Dienst, der Pull Requests automatisch prüft und Anmerkungen schreibt. Er ersetzt das Review durch Menschen nicht, findet aber vieles früh.
Board: Die Tafel mit den Tickets eines Teams, etwa in Linear oder Jira. Sie zeigt, was ansteht, woran gerade jemand arbeitet und was fertig ist.
Ticket: Eine einzelne Aufgabe mit Beschreibung, zuständiger Person und Status, etwa in Linear oder Jira. Am Ticket sieht das Team, wie weit die Arbeit ist.

Tools und Kommunikation

Linear: Ein Werkzeug für Aufgaben und Projektplanung: Tickets, Sprints und Fahrpläne an einem Ort, schnell und übersichtlich.
Git: Das Werkzeug zur Versionsverwaltung von Code. Jede Änderung ist nachvollziehbar, mehrere Entwickler arbeiten parallel, und jeder frühere Stand lässt sich wiederherstellen.
GitHub: Eine Plattform für Git-Projekte mit Pull Requests, Reviews und automatischen Abläufen (GitHub Actions). Hier liegt der Code vieler Teams.
GitLab: Eine Alternative zu GitHub, die sich auch selbst betreiben lässt. Änderungen laufen dort als Merge Requests, Pipelines sind eingebaut.
Slack: Ein Chat für Teams mit Kanälen nach Themen. Kurze Wege statt langer E-Mail-Ketten.
Discord: Ursprünglich für Gaming-Communities gedacht, heute auch in vielen Entwicklerteams als Chat mit Sprachkanälen im Einsatz.
Microsoft Teams: Chat, Videocalls und Dateien von Microsoft in einer Anwendung, verbreitet in Unternehmen mit Microsoft 365.
Repository: Der Ort, an dem der gesamte Quellcode eines Projekts mit seiner Geschichte liegt, meist bei GitHub oder GitLab. Wer Zugang hat, sieht jeden Stand und jede Änderung.

Gespräch

Reden wir darüber, was Du als Nächstes bauen willst.

Dreißig Minuten per Video. Du erzählst, was ansteht und wie Dein Team heute arbeitet. Ich sage Dir, ob und wie ich mitarbeiten kann. Danach weißt Du, ob es passt.

Gespräch vereinbaren Anfrage schreiben