Swift lernst du schnell, den Bestand nicht
Neue Oberflächen beschreibst du mit SwiftUI, die Anwendung darunter ist meist älter, und zwischen fertiger App und Veröffentlichung liegt eine Prüfung durch Apple.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Zwischen Kursbeispiel und Job liegen zwei Welten
Wer über einen Kurs einsteigt, baut eine kleine App mit SwiftUI, und das funktioniert erfreulich schnell. Im Job trifft er dann auf eine Anwendung, die vor der Umstellung entstanden ist: Oberflächen mit UIKit, teilweise noch Objective-C, eine gewachsene Struktur und Bibliotheken, die seit Jahren mitlaufen. Beides gleichzeitig zu bedienen ist der Normalfall und nicht die Ausnahme.
Die zweite Welt ist die Auslieferung. Eine App ist nicht fertig, wenn sie auf deinem Gerät läuft. Die App muss signiert, über eine Testverteilung an Prüfer gegeben und schließlich zur Prüfung eingereicht werden, und dabei fragt Apple nach Angaben zur Datennutzung und lehnt regelmäßig ab, wenn etwas nicht passt. Für viele Einsteiger ist das der erste Kontakt mit einer Freigabe, über die sie nicht selbst entscheiden.
Dazu kommt die Gerätewirklichkeit. Bildschirmgrößen, ältere Systemfassungen, wenig Speicher, unterbrochene Verbindungen, ein Anruf mitten im Ablauf. Eine App, die nur im Simulator und nur im Idealfall geprüft wurde, fällt genau an diesen Stellen auf, und zwar bei Nutzern, die eine Bewertung schreiben.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Weg in sechs Schritten
Die ersten drei Schritte kannst du allein gehen. Ab dem vierten brauchst du entweder ein Projekt im Haus oder eine eigene App, die tatsächlich veröffentlicht wird.
- 1
Swift lernen und dabei den Compiler ernst nehmen
Optionals sind kein Ärgernis, sondern der Kern der Sprache, denn sie zwingen dich, den Fall ohne Wert zu behandeln, bevor er auftritt. Dazu Protokolle statt Vererbung, Fehlerbehandlung mit throws und der Unterschied zwischen Wert- und Verweistypen.
Geschafft, wenn: du erklärst, warum ein Wert kopiert und ein anderer geteilt wird
- 2
Oberflächen mit SwiftUI beschreiben
Eine Ansicht ergibt sich aus ihrem Zustand, und Änderungen am Zustand zeichnen sie neu. Genau hier steigen Einsteiger aus, weil sie versuchen, die Ansicht direkt zu verändern. Bau ein Formular, eine Liste mit Nachladen und eine Detailansicht, das deckt den Großteil ab.
Geschafft, wenn: deine Oberfläche folgt dem Zustand, ohne dass du sie anfasst
- 3
Daten holen und Fehlerfälle zeigen
Ruf eine echte Schnittstelle asynchron ab und bau von Anfang an drei Zustände: lädt, hat Daten, ist gescheitert. Ergänze eine lokale Ablage, damit beim nächsten Start etwas da ist. Fast jede Bewertung im Store, die von Abstürzen spricht, hat hier ihre Ursache.
Geschafft, wenn: die App zeigt bei abgeschaltetem Netz etwas Sinnvolles
- 4
Sich in eine bestehende Anwendung einarbeiten
Nimm ein UIKit-Projekt und verstehe die Lebenszyklen der Bildschirme, die Navigation und die Stellen, an denen der Zustand liegt. Kommt dazu noch Objective-C, brauchst du keine tiefe Kenntnis, aber du musst den Code lesen und die Verbindung zwischen beiden Welten verstehen können.
Geschafft, wenn: du baust eine neue Ansicht in eine ältere App ein
- 5
Auf Geräten prüfen, nicht im Simulator
Erst auf echter Hardware zeigen sich Ladezeiten, Speicherverhalten, Verbindungsabbrüche und die Wirkung großer Schriftgrößen. Nimm dir eine ältere unterstützte Systemfassung dazu, weil ein Teil deiner Nutzer nicht aktualisiert.
Geschafft, wenn: die App bleibt auf einem älteren Gerät bedienbar
- 6
Veröffentlichen und die Prüfung einplanen
Für die Verteilung brauchst du eine kostenpflichtige Mitgliedschaft im Entwicklerprogramm, Zertifikate und Profile für die Signatur. Danach folgt die Prüfung durch Apple entlang veröffentlichter Richtlinien, samt Angaben dazu, welche Daten deine App erhebt. Plan Ablehnungen als Normalfall ein und nicht als Rückschlag.
Geschafft, wenn: eine App von dir liegt öffentlich oder im Firmenkatalog vor
Sechs Stufen von der Sprache zur veröffentlichten App
- 01 Swift mit Optionals, Protokollen und Fehlerbehandlung lernen.
- 02 Oberflächen mit SwiftUI aus dem Zustand heraus beschreiben.
- 03 Daten aus dem Netz holen und Fehlerfälle sichtbar machen.
- 04 Sich in eine bestehende UIKit-Anwendung einarbeiten.
- 05 Auf echten Geräten und mit Bedienhilfen prüfen.
- 06 Signieren, verteilen, einreichen und die Prüfung einplanen.
Was du am Ende dieses Wegs kannst
Die Punkte unten sind das, was in Ausschreibungen für diese Rolle regelmäßig auftaucht, unabhängig davon, ob die App im eigenen Haus benutzt oder im Store verkauft wird.
Swift jenseits der Beispiele
Du arbeitest mit Optionals, Protokollen und Fehlerbehandlung und weißt, wann eine Struktur und wann eine Klasse die richtige Wahl ist, weil das Kopierverhalten den Unterschied macht.
Oberflächen beschreiben
Du baust Ansichten mit SwiftUI aus dem Zustand heraus, statt sie Schritt für Schritt zusammenzusetzen, und erkennst, warum eine Ansicht nicht neu zeichnet, wenn sich der Zustand ändert.
Im Bestand arbeiten
Du findest dich in einer UIKit-Anwendung zurecht, verstehst die Lebenszyklen der Bildschirme und kannst neue Teile in SwiftUI daneben setzen, ohne die bestehende Anwendung anzufassen.
Daten und Netz
Du rufst Schnittstellen asynchron ab, behandelst Zeitüberschreitungen und fehlende Verbindung als normale Fälle und speicherst lokal, damit die App auch in der U-Bahn etwas anzeigt.
Veröffentlichen
Du kennst den Weg von der Signatur über die Testverteilung bis zur Einreichung, weißt, welche Angaben zur Datennutzung verlangt werden, und planst die Prüfzeit ein, statt sie zu vergessen.
Bedienbarkeit ernst nehmen
Du prüfst deine App mit vergrößerter Schrift und mit der Sprachausgabe, weil beides zur Grundausstattung der Plattform gehört und in vielen Häusern inzwischen abgenommen wird.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was den Alltag ausmacht, und was Leute falsch erwarten
Erwartet wird das Bauen neuer Bildschirme. Tatsächlich geht der größere Teil der Zeit in die Fälle daneben: Was passiert bei abgelaufener Anmeldung, bei einer Antwort ohne Inhalt, bei zwei parallelen Anfragen, bei einem Wechsel in den Hintergrund mitten im Vorgang. Eine App ist zu einem guten Teil eine Zustandsverwaltung mit Bildschirm daran.
Der zweite große Anteil ist die Auslieferung. Fassungsnummern, Testverteilung, Rückmeldungen aus dem Prüfteam, Absturzberichte aus dem Feld, Nachbesserungen für eine neue Systemfassung im Herbst. Anders als im Web kannst du eine fehlerhafte Auslieferung nicht in zehn Minuten zurücknehmen, weil zwischen dir und den Nutzern eine Prüfung liegt.
Unterschätzt wird die Zusammenarbeit mit dem Backend. Sehr viele App-Fehler sind in Wahrheit Fragen an die Schnittstelle: Welche Felder können fehlen, was bedeutet dieser Zustandswert, wie sieht die Antwort bei fehlender Berechtigung aus. Wer diese Fragen früh stellt, spart sich Nachbesserungen, die durch die Prüfung müssen.
Der Weg hinein, und was die Ausstattung kostet
Für diese Rolle brauchst du einen Mac, weil die Entwicklungsumgebung nur dort läuft, und ein Testgerät, das nicht das neueste Modell sein muss. Dazu kommt die kostenpflichtige Mitgliedschaft im Entwicklerprogramm, sobald du außerhalb deines eigenen Geräts verteilen willst. Das ist die einzige Rolle in diesem Bereich mit einer nennenswerten Einstiegsausstattung, und sie gehört in die Planung.
Fachlich kommen die meisten aus einer anderen Entwicklungsrichtung, häufig aus dem Web oder aus Java. Zertifikate spielen keine Rolle, gefragt ist eine App, die man herunterladen oder wenigstens auf einem Gerät sehen kann. Eine kleine, fertige und wirklich veröffentlichte App wiegt mehr als drei angefangene Projekte mit größerem Funktionsumfang.
Wer über plattformübergreifende Wege einsteigt, etwa mit React Native, kommt schneller zu einem Ergebnis auf beiden Systemen, lernt aber die Plattform selbst nur an der Oberfläche kennen. Für Stellen, die ausdrücklich iOS suchen, ist der direkte Weg über Swift der tragfähigere. Für Häuser, die eine App für beide Systeme mit einem kleinen Team brauchen, ist es umgekehrt.
Woran sich zwei Leute mit gleicher Berufsdauer unterscheiden
Der erste Unterschied ist der Umgang mit Zuständen. Wer den Zustand an einer Stelle hält und die Oberfläche daraus ableitet, hat eine App, die sich erweitern lässt. Wer den Zustand über mehrere Bildschirme verteilt und ihn hin und her reicht, sucht nach einem Jahr Fehler, die nur in bestimmten Reihenfolgen auftreten.
Der zweite ist die Bereitschaft, Absturzberichte zu lesen. Aus dem Feld kommen Meldungen mit Gerät, Systemfassung und Stelle im Code, und darin steckt fast immer ein Muster: ein Modell, eine bestimmte Sprache, ein bestimmter Übergang. Wer diese Berichte regelmäßig durchgeht, findet Fehler, die im eigenen Test nie auftreten.
Der dritte ist Bedienbarkeit. Vergrößerte Schrift, Sprachausgabe, Kontraste und Bedienung mit einer Hand kosten in der Umsetzung wenig, wenn man sie von Anfang an mitdenkt, und sind später mühsam nachzurüsten. In Häusern, die für Kunden ausliefern, wird das inzwischen abgenommen.
Wohin die Rolle führt
Drei Richtungen sind üblich. Die Vertiefung in die Plattform, also Hintergrundverarbeitung, Datenhaltung, Erweiterungen wie Widgets und die Anbindung an weitere Apple-Geräte. Die Verbreiterung auf beide Systeme, entweder über eine zweite Plattform oder über einen plattformübergreifenden Ansatz. Und der Weg in Richtung Architektur, sobald aus einer App eine Produktfamilie mit gemeinsamen Bausteinen wird.
Nicht zur Rolle gehört die Verwaltung von Apple-Geräten im Unternehmen, also Verteilung, Richtlinien und Geräteverwaltung. Das ist ein eigener Beruf mit eigenen Werkzeugen, auch wenn beide Seiten sich beim Ausrollen einer Firmen-App zwangsläufig begegnen.
Zur Statistik weiter unten: Es sind Bruttomonatsverdienste in Vollzeit ohne Sonderzahlungen, das Weihnachts- und Urlaubsgeld fehlt darin. Der Median ist dabei die aussagekräftigere Zahl, weil einzelne sehr hohe Verdienste den Durchschnitt nach oben ziehen. Das Anforderungsniveau Spezialist beschreibt den Zuschnitt der Stelle und nicht die Zahl deiner Berufsjahre.
Dazu passende Kurse
Den Einstieg gibt es als Kurse, in denen du die Sprache der Apple-Plattform von Grund auf lernst , mit SwiftUI und dem Bestand daneben.
Die amtlichen Zahlen zu dieser Rolle
Eine Zelle für App-Entwicklung gibt es in der amtlichen Systematik nicht, und erst recht keine je Plattform: iOS und Android stecken beide in der allgemeinen Zelle für Softwareentwicklung. Die häufig gestellte Frage, welche der beiden Plattformen besser bezahlt wird, lässt sich aus dieser Statistik deshalb nicht beantworten. Was den Verdienst in dieser Rolle sichtbar prägt, ist etwas anderes: iOS-Stellen konzentrieren sich auf wenige Branchen und auf große Städte, und die Zelle zeigt einen bundesweiten Wert über alle Regionen hinweg. Weihnachts- und Urlaubsgeld sind in den Monatswerten nicht enthalten.
Amtliche Medianverdienste, April 2025
Brutto im MonatStatistisches Bundesamt, Verdiensterhebung. Vollzeit, ohne Sonderzahlungen. Die Hälfte der Beschäftigten verdient weniger als der Median, die andere Hälfte mehr.
KldB 43413, Durchschnitt 6.238 €, gerundet rund 72.000 € im Jahr ohne Sonderzahlungen
- Vollzeitbeschäftigte, Bruttomonatsverdienst ohne Sonderzahlungen. Weihnachts- und Urlaubsgeld, Prämien und Boni sind nicht enthalten, der Jahresverdienst liegt also über dem Zwölffachen.
- Das Anforderungsniveau beschreibt den Zuschnitt der Stelle, nicht die Berufserfahrung. Fachkraft, Spezialist und Experte sagen etwas über die Komplexität der Tätigkeit aus, nicht über Dienstjahre.
- Die Erhebung geht regional nur bis auf die Bundeslandebene. Für einzelne Städte gibt es keine amtlichen Zahlen, weil der Zufallsfehler zu groß wäre.
Quelle: Statistischer Bericht Verdienste , Statistisches Bundesamt (Destatis). Den eigenen Fall prüfst du im Entgeltatlas der Bundesagentur für Arbeit . Beachte dort: Entgelte oberhalb der Beitragsbemessungsgrenze sind der Statistik nicht bekannt, bei gut bezahlten IT-Rollen steht deshalb nur eine Untergrenze.
Wo du genau das übst
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
Häufige Fragen
Brauche ich wirklich einen Mac?
SwiftUI oder UIKit lernen?
Was kostet die Veröffentlichung im App Store?
Lohnt sich React Native oder ein anderer plattformübergreifender Weg?
Passt thematisch dazu
Wenn eure App nicht im Store, sondern im Unternehmen verteilt wird, gehört dazu die Frage, wie Firmen-Apps auf die Geräte kommen .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Von der ersten Ansicht bis zur eingereichten App
Bei cmt lernst du Swift und SwiftUI der Reihe nach und siehst dabei auch die ältere Welt, die dich in fast jedem Projekt erwartet.