FAQ.

Die Kosten für die Entwicklung einer App richten sich grob nach dem Funktionsumfang, der Anzahl der Ansichten, Anbindung externer Dienste und der Menge der in der App oder auf einem Server gespeicherten Daten. Dabei ist es unseren Erfahrungen nach auf längere Sicht nicht relevant, ob Apps für mehrere Plattformen nativ oder mit einem Crossplattform-Ansatz (React Native, Cordova, Xamarin) umgesetzt werden. Für uns steht die Qualität der Apps im Vordergrund weshalb wir grundsätzlich die native Programmierung empfehlen.

Sehr einfache Apps lassen sich für iOS und Android zusammen inkl. Veröffentlichung für 10.000 € umsetzen.

Apple Account

1. Für den Zugriff zum App Store muss zunächst eine Apple-ID angelegt oder eine bereits bestehende als Basis-Apple-ID ausgewählt werden. Die Apple-ID kann hier beantragt werden: https://appleid.apple.com/account und muss ggf. durch ein iOS- oder Mac-Gerät per 2-Faktor-Authentifizierung freigeschaltet werden.
2. Anschließend kann diese Apple-ID in ein Apple-Developer Programm eingeschrieben werden („Enrollment“). Das kann hier durchgeführt werden: https://developer.apple.com/programs/enroll/. Wichtig hierbei: Es sollte in der Regel kein „Individual Developer“ Account, sondern ein Firmen-Account angelegt werden. Dazu wird eine D-U-N-S Nummer benötigt. Diese kann hier angefordert werden: https://www.upik.de/dunsanfordern.html
3. Das Enrollment dauert ein paar Tage. Anschließend ist die Apple-ID für die Nutzung der Apple Developer Platform und für App Store Connect freigeschaltet. In der Apple Developer Platform und im App Store Connect kann uns dann eine Einladung als Entwickler-Account (sprechen Sie hierzu direkt mit Ihrem Ansprechpartner) geschickt werden, so dass wir die erforderlichen Zertifikate, Profile und weiteren Einstellungen vornehmen können.
4. Damit ist die Erstellung eines Apple Accounts erledigt und es können Apps im App Store veröffentlicht werden.

Google Account

1. Für die Veröffentlichung von Android Apps ist lediglich ein Google-Entwickler-Konto notwendig. Dieses kann hier beantragt werden: https://play.google.com/apps/publish/signup
2. Anschließend kann unser Google-Account (sprechen Sie hierzu direkt mit Ihrem Ansprechpartner) über die Play Developer Console eingeladen werden, so dass wir uns im die technischen Details der App-Bereitstellung kümmern können.

Amazon Webservices (AWS) Account

1. Um das Backend bei AWS bereitzustellen, benötigen wir einen Amazon Account, der Zugriff auf die Amazon Web Services (Cloudumgebung von Amazon) hat. Dieser kann hier angelegt werden: https://portal.aws.amazon.com/gp/aws/developer/registration/index.html
2. Wenn der Account eingerichtet ist, muss einmalig eine Zahlungsmöglichkeit hinterlegt werden, damit die kostenpflichtigen Server gestartet werden können. Im ersten Jahr erhalten läuft das sogenannte Free Tier womit alle Basis-Server und Datenbanken kostenlos sind. Während der Entwicklung reicht das Free Tier in der Regel aus, so dass keine oder nur minimale Kosten entstehen.
3. Für die weiter Einrichtug des AWS Accounts sprechen Sie mit Ihrem Ansprechpartner bei uns.

Die Kosten für die Veröffentlichung einer App unterscheiden sich zwischen Android und iOS.

Für Android ist eine einmalige Registrierung eines Entwicklerkontos bei Google Play nötig, die mit einer einmaligen Gebühr von derzeit 25 USD verbunden ist (Stand August 2022).

iOS Apps werden im App Store von Apple veröffentlicht. Hierfür ist ein sogenanntes Enrollment im Apple Developer Program nötig. Dieses ist mit einer jährlichen Gebühr von derzeit 99 USD verbunden (Stand August 2022).

Hinzu kommen nur noch die Aufwände für die Erstellung der Beschreibungstexte, Werbebilder und das Einstellen.

Im Zuge der Digitalisierung und der zunehmenden Disruption bestehender Geschäftsfelder, kommt immer wieder die Frage auf, welche digitalen Geschäftsmodelle gerade im Kontext von Apps und Web-Applikationen realisiert werden können und welche Monetarisierungsmöglichkeiten es gibt.

• Paid: mittlerweile gibt es nicht mehr viele erfolgreiche Apps die von vornherein vor der Benutzung gekauft werden müssen, ohne dass man die Funktionen testen kann, was uns direkt zum nächsten Modell führt, wie Apps eher monetarisiert werden:
• In App Purchase: Um eine Funktion freizuschalten gibt es mittlerweile in vielen Apps die Möglichkeit diese per In-App-Kauf zu erwerben. Hierbei gibt es zwei verschiedene Modelle:
• Abonnements: der Benutzer zahlt in regelmäßigen Abständen für die Erhaltung einer Funktion/einer Leistung, bis dieser das Abonnement kündigt. Die Abonnements sind jederzeit bis zum Ende der aktuellen Periode kündbar. Bei Abonnements gibt es außerdem noch die Möglichkeit eines Testzeitraums. Der Testzeitraum wandelt sich automatisch in ein kostenpflichtiges Abonnement, wenn dieses nicht vor Ablauf des Testzeitraums gekündigt wird.
• Pay Once: Hierbei bezahlt der Benutzer einmalig einen Betrag für eine Leistung
• Platform Business: Mit dem Aufbau einer Vermittlungsplattform können im Rahmen der erfolgreichen Vermittlung zwischen einem Leistungsanbieter und einem Interessenten Gebühren erhoben werden. Alternativ lässt sich bereits die Veröffentlichung von Leistungsbeschreibungen mit entsprechendem Mehrwert monetarisieren, indem dem Leistungserbringer ein entsprechender Mehrwert gegenüber nicht zahlenden Mitbewerbern ermöglicht wird.

Apps mit Inhalten, die redaktionell verwaltet werden, werden in der Regel an ein sogenanntes Content Management System (CMS) angebunden. Das CMS kann hierbei entweder individuell von uns entwickelt werden oder ein existierendes integriert und angepasst werden. Das CMS ist dabei häufig eine Website bei der sich ein Benutzer anmeldet, um dann beispielsweise Artikel, Bilder, Informationstexte oder andere Inhalte der App verändern zu können.

Das CMS wird dabei in der Regel im Internet auf einem Server gehostet. Die Plattform kann z.B. ein einfacher PHP-Webspace mit einer MySQL-Datenbank oder aber eine komplexe Cloud Server Architektur sein, auf der die CMS-Software ausgeführt und die App-Daten gespeichert werden.

Die Höhe der laufenden Kosten einer veröffentlichten App hängen stark von der Art der App ab. Bei iOS-Apps fallen mindestens die jährlichen Gebühren für das Apple Developer Program an. Sofern die Apps ein Backend benötigen, über das Daten verarbeitet und/oder verteilt und gespeichert werden, kommen die Kosten für den Betrieb des Backends hinzu.

Sofern die Apps nativ umgesetzt wurden, gibt es selten Fälle in denen die Apps aufgrund von Betriebssystemupdates nochmal angepasst werden müssen. Bei Crossplattform-/Web-Apps kommt es hingegen schon mal häufiger vor, da dann zum Teil die zugrundeliegende Plattform angepasst werden muss und somit einzelne Schnittstellen nicht mehr unterstützt werden oder aber sich die Art der Programmierung ändert.

Native Apps werden individuell pro Plattform (iOS und Android) mit den jeweiligen Entwicklungswerkzeugen einzeln umgesetzt. Dadurch ist gewährleistet, dass alle Funktionen genau so umgesetzt werden, wie die Entwickler der Betriebssysteme die Programmierung von Apps vorgesehen haben.

Vorteile der nativen Programmierung

• perfekte UI und UX, wie Benutzer es vom jeweiligen Betriebssystem gewohnt sind
• langer Support von entwickelten Apps ohne, dass bei neuen Versionen von Android und iOS Anpassungen gemacht werden müssen
• fühlbare hohe Qualität der Apps

Nachteile der nativen Programmierung

• bei der nativen Entwicklung fallen für beide Betriebssysteme Entwicklungsaufwände an

Bei einer Web App wird die App im Optimalfall einmal mit Web-Technologien (HTML5, CSS und JavaScript) realisiert und dann auf unterschiedlichen Betriebssystemen ausgeführt. Die App läuft sozusagen in einem Browserfenster und die Betriebssystemfunktionen werden über spezielle Schnittstellen heraus aufgerufen und angesprochen.

Vorteile des Web App-Ansatzes

• sehr einfache Apps mit wenigen Funktionen können für mehrere Plattformen verhältnismäßig kostengünstig umgesetzt werden

Nachteile des Web App-Ansatzes

• Fehlender Support durch Betriebssystem-Hersteller
• fortwährender Wartungsbedarf und somit laufende Kosten nach Erstentwicklung durch neue Betriebssystemversionen oder Geräteformfaktoren
• keine Betriebssystemspezifischen Bedienkonzepte kostengünstig realisierbar und somit ungewohnte UI und UX für die Benutzer