Interne Apps sind Anwendungen, die ein Unternehmen für die eigenen Beschäftigten baut und außerhalb von App Store und Google Play verteilt. Auftragsverwaltung im Außendienst, Scanner im Lager, Prüfprotokolle in der Fertigung, ein schlanker Vertriebszugriff auf das CRM: der Nutzerkreis ist bekannt, die Geräte sind bekannt, und die App hängt an Systemen, die es nur bei Ihnen gibt.
Der schwierige Teil ist selten die Entwicklung. Er beginnt danach: Wie kommt die App auf die Geräte, wer bekommt welche Version, und was passiert damit, wenn jemand das Unternehmen verlässt.
Was interne Apps von Consumer-Apps unterscheidet
Eine Consumer-App kämpft um Millionen anonymer Nutzer. Ihre interne App bedient dreihundert Servicetechniker, deren Namen in Ihrem Verzeichnisdienst stehen. Das verändert jede Entscheidung.
Der Nutzerkreis ist bekannt. Sie wissen, welche Geräte im Einsatz sind, welche Android-Version darauf läuft und ob im Lager überhaupt Netz vorhanden ist. Ein Feature für ein Gerätemodell zu bauen, das niemand hat, ist reine Verschwendung.
Die Verteilung ist kontrolliert. Statt einer Veröffentlichung im Store läuft die Auslieferung über eine App-Verwaltung oder einen privaten Unternehmenskatalog. Sie entscheiden, wer die App sieht und welche Version aktiv ist.
Die App hängt an Bestandssystemen. ERP, CRM, Personalsystem, Ticketsystem. Die Anmeldung läuft in der Regel über Ihren Identity Provider, also Microsoft Entra, Okta oder Google Workspace. Genau an dieser Stelle scheitern Projekte am häufigsten, nicht am App-Design.
Sie müssen nachweisen, was passiert. Personenbezogene Daten in einer App bedeuten Rechenschaftspflicht nach Art. 5 DSGVO. Wer hat wann worauf zugegriffen, und wie werden die Daten wieder entfernt.
Nativ, Cross-Platform, PWA oder Low-Code
Es gibt keinen richtigen Ansatz, nur einen, der zu Ihrem Anwendungsfall passt.
Native Entwicklung
Getrennte Apps für iOS (Swift) und Android (Kotlin). Beste Leistung, voller Zugriff auf Kamera, Bluetooth, NFC und Hintergrunddienste. Richtig für alles, was offline funktionieren muss oder Hardware ansteuert, etwa Handscanner in der Logistik. Der Preis: zwei Codebasen und zwei Kompetenzen im Team.
Cross-Platform-Frameworks
React Native, Flutter und .NET MAUI decken beide Plattformen aus einer Codebasis ab. Der Leistungsabstand zur nativen App ist für Formulare, Listen, Freigaben und Kommunikation nicht mehr spürbar. Für die große Mehrheit der internen Apps ist das die vernünftige Voreinstellung.
Progressive Web Apps
Eine Webanwendung mit Startbildschirm-Symbol, Offline-Cache und Push. Keine Store-Verteilung, kein Signierzertifikat, läuft auf jedem Gerät mit aktuellem Browser. Ideal für Dashboards, Nachschlagewerke und Genehmigungsprozesse. Sobald Sie Kamera in Serienqualität, Bluetooth-Peripherie oder echte Hintergrundverarbeitung brauchen, stößt der Ansatz an Grenzen.
Low-Code-Plattformen
Power Apps, AppSheet oder Mendix erlauben es Fachabteilungen, einfache Erfassungsformulare selbst zu bauen. Das funktioniert erstaunlich gut für abgegrenzte Prozesse. Es funktioniert schlecht, sobald jemand die Anwendung zwei Jahre später warten soll. Behandeln Sie Low-Code als Prototypenwerkzeug, und legen Sie vorher fest, ab welcher Nutzungszahl die IT übernimmt.
Wie die App ohne öffentlichen App Store auf die Geräte kommt
Vier Wege stehen zur Verfügung. Die meisten Unternehmen kombinieren die ersten beiden.
- Privater Unternehmenskatalog. Ein eigener, von der IT kuratierter App-Katalog, in dem Beschäftigte freigegebene Anwendungen selbst installieren. iOS, Android und Webanwendungen in einer Oberfläche. Der richtige Weg für alles, was optional ist.
- Stille Installation über MDM. Die App wird ohne Zutun der Nutzer auf registrierte Geräte geschoben. Unter iOS muss sie dafür als Custom App im Apple Business Manager hinterlegt sein, unter Android als private App in Managed Google Play. Der richtige Weg für Pflichtanwendungen: VPN, Sicherheitsagent, interne Kommunikation.
- Direkte Installation per APK oder IPA. Datei verteilen, Nutzer installiert. Keine Infrastruktur nötig, aber auch kein Aktualisierungsmechanismus, keine Nutzungsdaten und ein reales Risiko manipulierter Builds. Für einen Test mit fünf Personen vertretbar, für einen Rollout nicht.
- Vorkonfiguration über Managed App Configuration. Server-URL, Mandant und Funktionsschalter werden vom MDM gesetzt, bevor die App das erste Mal startet. Der Nutzer öffnet sie und ist bereits verbunden. Unter iOS als AppConfig, unter Android als Managed Configuration. Der am häufigsten übersehene Punkt, obwohl er die meisten Supportanfragen der ersten Woche verhindert.
Wo der Unterschied am deutlichsten wird, ist bei Frontline-Mitarbeitern. Ein Techniker im Kundendienst, eine Pflegekraft auf Station oder eine Verkäuferin auf der Fläche hat keine zwanzig Minuten für eine Einrichtung. Das Gerät muss beim Schichtbeginn funktionieren. In Filialen und Werkstätten läuft die Anwendung häufig im Kiosk-Modus, damit das Gerät während der Schicht auf genau eine App festgelegt ist.
Interne Apps auf privaten Geräten
Nicht jede Person bekommt ein Diensthandy. Sobald die interne App auf einem privaten Gerät laufen soll, ändert sich die Verwaltung grundlegend. BYOD gilt dabei nur für iOS und Android. Windows-PCs und Macs werden als unternehmenseigene Geräte verwaltet.
Unter Android liegen Arbeits-Apps und Arbeitsdaten in einem Arbeitsprofil, einem von Android selbst durchgesetzten getrennten Bereich. Die Apps erscheinen mit Aktenkoffer-Symbol in einem eigenen Reiter. Die Admin-Konsole listet ausschließlich die im Arbeitsprofil installierten Anwendungen; was privat installiert wurde, erscheint dort nicht. Beim Austritt wird das Arbeitsprofil entfernt, und Android selbst begrenzt den Löschbefehl auf genau diesen Bereich. Ein Zurücksetzen des privaten Geräts auf Werkseinstellungen ist nicht möglich.
Unter iOS installiert die Registrierung ein Verwaltungsprofil, das die Verwaltung auf die vom Unternehmen verteilten Apps und Konten bezieht. Über die Managed-Open-In-Regeln bleiben Unternehmensdokumente in verwalteten Apps und wandern nicht in private Anwendungen. Beim Austritt werden die verwalteten Daten entfernt.
Ein Punkt, der in Gesprächen mit dem Betriebsrat regelmäßig auftaucht: eine Standortermittlung existiert im BYOD-Modus nicht. Weder unter Android noch unter iOS. Das ist keine abgeschaltete Option, sondern eine im privaten Modus nicht vorhandene Funktion. Auf unternehmenseigenen Android-Geräten dagegen sind periodische Ortung und Geofencing verfügbar und müssen entsprechend vereinbart werden.
Für die Entwicklung heißt das vor allem eines: testen Sie früh in einem echten Arbeitsprofil. Anwendungen, die den Systembrowser aufrufen, Dateien mit anderen Apps teilen oder einen eigenen Zertifikatsspeicher mitbringen, verhalten sich dort anders als auf einem unverwalteten Gerät.
Sicherheit, DSGVO und der Betriebsrat
Die technischen Grundlagen sind unstrittig und sollten von Anfang an stehen, nicht nachträglich eingebaut werden.
- Anmeldung über den Identity Provider mit Single Sign-on und Mehrfaktor-Authentifizierung für alles, was auf Personaldaten oder Finanzdaten zugreift
- Verschlüsselung im Ruhezustand und im Transport, über die Schnittstellen der Plattform statt über Eigenbau
- Per-App-VPN, damit der Datenverkehr der internen App durch Ihr Netz läuft, auch im WLAN eines Hotels
- Regeln gegen Datenabfluss: Einschränkung der Zwischenablage zwischen verwalteten und privaten Apps, Begrenzung der Teilen-Funktion
- Selektives Löschen beim Austritt oder Geräteverlust, ohne private Inhalte anzutasten
Dazu kommen zwei Themen, die in Deutschland über den Projekterfolg entscheiden und in englischsprachigen Leitfäden nie vorkommen.
Der Auftragsverarbeitungsvertrag. Jeder Dienstleister, der über Ihre App personenbezogene Daten verarbeitet, braucht einen AVV nach Art. 28 DSGVO. Das gilt für die MDM-Lösung ebenso wie für das Analysewerkzeug im App-SDK. Ein eingebundenes Crash-Reporting-SDK mit Serverbetrieb außerhalb der EU ist der häufigste Fund im Datenschutz-Audit einer internen App.
Der Betriebsrat. Nach § 87 Abs. 1 Nr. 6 BetrVG hat der Betriebsrat ein erzwingbares Mitbestimmungsrecht bei jeder technischen Einrichtung, die objektiv geeignet ist, Verhalten oder Leistung zu überwachen. Auf die Absicht kommt es nicht an. Eine App, die Auftragszeiten erfasst, erfüllt dieses Kriterium in aller Regel. Ohne Betriebsvereinbarung kein Rollout. Wer den Betriebsrat in der Konzeptphase einbindet und offenlegt, welche Daten erhoben werden und wie lange sie gespeichert bleiben, verliert zwei Wochen. Wer es nach dem Entwicklungsbudget versucht, verliert das Projekt.
Betrieb: Versionen, Tests, Ablösung
Eine signierte App ist noch keine betriebene App.
Aktualisierungen. Sicherheitskorrekturen gehen sofort raus, Funktionsänderungen gestaffelt: erst eine Testgruppe, dann Abteilung für Abteilung. Eine MDM-Lösung kann eine Mindestversion erzwingen und den Zugriff auf Unternehmensressourcen sperren, solange eine veraltete Version läuft. Das ist der einzige Mechanismus, der eine gemischte Geräteflotte tatsächlich auf einen Stand bringt.
Tests. Unter iOS deckt TestFlight interne und externe Testgruppen ab, unter Android leisten die internen Testkanäle der Google Play Console dasselbe. Für Apps außerhalb der öffentlichen Stores kann Ihr Unternehmenskatalog einen Beta-Kanal parallel zur Produktivversion führen. Testen Sie dabei bewusst auf dem ältesten noch aktiven Gerätemodell, nicht nur auf dem Diensthandy des Projektleiters.
Überwachung. Absturzrate, Startzeit und Anmeldeerfolg. Der letzte Wert ist der wichtigste und wird am seltensten gemessen: eine App, die nach einem Zertifikatswechsel im Verzeichnisdienst niemanden mehr anmeldet, ist für die Fachabteilung ausgefallen, auch wenn kein einziger Absturz gemeldet wird.
Ablösung. Wenn eine App das Ende ihres Lebenszyklus erreicht, nehmen Sie sie aus dem Katalog, veröffentlichen eine letzte Version mit Hinweis auf die Nachfolgeanwendung und deinstallieren die alte über das MDM. Sonst laufen drei Jahre später noch Geräte mit einer Anwendung, die auf eine abgeschaltete Schnittstelle zeigt.
Interne Apps sind der Weg, über den Ihre Systeme bis in den Servicewagen, das Lager und die Station reichen. Die Technik dafür ist ausgereift. Anspruchsvoll bleibt der Betrieb: aktuell halten, sauber verteilen, beim Austritt zurücknehmen. Genau dort setzt eine App-Verwaltung an.
Häufige Fragen
Was ist eine interne App?
Eine interne App ist eine Anwendung, die ein Unternehmen für den eigenen Betrieb entwickeln lässt statt für den öffentlichen Verkauf. Sie bildet einen konkreten Arbeitsprozess ab, etwa Auftragsabwicklung, Inventur, Prüfprotokolle oder interne Kommunikation, und wird privat über Managed Google Play, den Apple Business Manager oder eine MDM-Lösung an die Beschäftigten verteilt.
Wie kommt eine interne App ohne App Store auf die Geräte?
Über drei Kanäle: einen privaten Unternehmenskatalog zur Selbstinstallation, eine stille Installation über das MDM auf registrierte Geräte, und die Vorkonfiguration per Managed App Configuration, damit die App beim ersten Start bereits verbunden ist. Die öffentlichen Stores kommen nicht infrage, weil eine interne App nicht für die Allgemeinheit bestimmt ist.
Nativ oder Cross-Platform für interne Apps?
Nativ liefert die beste Leistung und vollen Zugriff auf Gerätefunktionen, was bei Kamera, Biometrie, Bluetooth-Peripherie und Hintergrunddiensten zählt. Cross-Platform mit Flutter oder React Native spart Zeit und Budget, wenn dieselbe Anwendung unter iOS und Android laufen muss. Für die meisten internen Anwendungen ist Cross-Platform die pragmatische Wahl, nativ bleibt den leistungskritischen Fällen vorbehalten.
Was gilt für interne Apps auf privaten Geräten?
Unter Android läuft die App im Arbeitsprofil, einem von der Plattform getrennt gehaltenen Bereich; unter iOS wird sie als verwaltete App ausgewiesen. In beiden Fällen bezieht sich die Verwaltung auf die geschäftliche Seite, und beim Austritt wird nur diese entfernt. Eine Standortermittlung gibt es im BYOD-Modus nicht. Da eine solche Lösung dennoch geeignet sein kann, Verhalten zu erfassen, ist der Betriebsrat nach § 87 BetrVG zu beteiligen.