Beeinflusst die App Größe die Downloads? So verkleinern Sie APK und IPA

Wie setzen Sie das konkret um? Wir, Talha Aslan und Team, behandeln die Größe in jedem Projekt der App Entwicklung als Produktkennzahl. In diesem Leitfaden zeigen wir, wie Sie Ihre APK (das Android Paket) und Ihre IPA (das iOS App Archiv) verkleinern. Beginnen Sie zunächst mit dieser kurzen Liste:

1. Messen Sie die echte Downloadgröße in der Play Console und in App Store Connect.
2. Prüfen Sie, ob Sie bei Google Play mit einem Android App Bundle veröffentlichen.
3. Holen Sie Bilder, Schriften und Videos aus dem Paket und komprimieren Sie sie.
4. Entfernen Sie Bibliotheken und SDKs, die Sie nicht mehr nutzen.
5. Verlagern Sie große optionale Inhalte aus der Erstinstallation.
6. Messen Sie bei jedem Release erneut und vergleichen Sie mit der Vorversion.

Was unterscheidet Downloadgröße und Installationsgröße?

Wer diese beiden Werte verwechselt, optimiert oft am falschen Ende. Die Hilfeseite von App Store Connect beschreibt die Downloadgröße als komprimierte Größe der App, die über Mobilfunk oder WLAN übertragen wird. Die Installationsgröße ist dagegen der Speicherplatz, den die App auf dem Gerät belegt. Sie erscheint außerdem im Informationsbereich der Produktseite.

Nutzer sehen also zwei Zahlen zu zwei verschiedenen Zeitpunkten. Beim Download denken sie an Datenvolumen und Wartezeit. Nach der Installation denken sie an den Speicher. Apple weist zudem darauf hin, dass freigegebene Apps mit DRM verschlüsselt und neu komprimiert sind. Deshalb kann die endgültige Größe über der hochgeladenen Datei liegen, und niemand kann sie vorab exakt bestimmen.

• Downloadgröße: Das verkleinerte, komprimierte Paket, das über das Netz kommt.
• Installationsgröße: Der gesamte Platz nach dem Entpacken; meist größer als der Download.
• Updategröße: Was bestehende Nutzer für eine neue Version laden; dazu später mehr.

Kurz gesagt: Sie sollten alle drei Werte getrennt beobachten.

Was sagen Google und Apple offiziell zur App Größe?

Bei Google steht die klarste Aussage im Android Leitfaden zum Verkleinern von Apps. Dort heißt es, dass Nutzer zu groß wirkende Apps meiden, vor allem in Schwellenmärkten mit instabilen Verbindungen oder knappen Datentarifen. Zudem beeinflusst die Paketgröße laut Leitfaden Ladezeit, Speicherverbrauch und Akkuverbrauch.

Apple spricht über Größe eher anhand technischer Grenzen und Warnungen. Die Produktseite im App Store zeigt eine Installationsgröße, die vom betrachtenden Gerät abhängt. Ein iPhone Nutzer sieht also keine allgemeine Zahl, sondern den Wert für sein eigenes Modell. Somit wird jede überflüssige Datei auf jedem Gerät zu sichtbaren Kosten.

Allerdings veröffentlicht keine der beiden Plattformen eine Formel wie „jedes zusätzliche Megabyte kostet so viele Installationen“. Deshalb nennen auch wir keine solche Zahl. Stattdessen empfehlen wir, Größenänderungen und Conversion Rate im Store gemeinsam in Ihrer eigenen App zu beobachten. Der Abschnitt zur Messung zeigt das Schritt für Schritt.

Welche Warnungen sehen Nutzer beim Download über Mobilfunk?

Am greifbarsten wirkt die Größe über Warnungen, die Mobilfunknutzer sehen. Die Hilfeseite der Play Console zu Größenlimits erklärt, dass Nutzer ab einer bestimmten Größe bei Installation über mobile Daten einen nicht blockierenden Hinweis sehen. Diesen Schwellenwert gibt die Seite derzeit mit 200 MB an.

Bei Apple zeigt App Store Connect ein gelbes Warnsymbol neben dem Build, sobald eine Gerätevariante das Limit für Downloads ohne WLAN überschreitet. Apple schickt dem Entwickler dann auch eine E-Mail. Die Hilfeseite nennt dafür ebenfalls 200 MB. Beide Plattformen können diese Werte allerdings ändern. Prüfen Sie daher den aktuellen Wert immer auf den offiziellen Seiten.

Warum ist die Warnung so wichtig? Weil Nutzer spontan entscheiden: im Bus, im Laden oder direkt nach dem Tippen auf eine Anzeige. Bietet der Store an, auf WLAN zu warten, fällt das Aufschieben leicht. Ein Teil dieser aufgeschobenen Downloads endet nie. Wenn Sie Nutzer über bezahlte Anzeigen gewinnen, landet dieser Verlust also direkt in Ihren Akquisekosten.

Wie empfindlich reagiert Ihre Zielgruppe auf die App Größe?

Die Größe trifft nicht jede Zielgruppe gleich. Wer ein neues Smartphone mit viel Speicher und stabilem WLAN nutzt, bemerkt ein paar Megabyte mehr vielleicht nicht. Nutzer mit Einsteigergeräten, kleinen Datentarifen oder ständigen Speicherwarnungen reagieren dagegen deutlich empfindlicher.

Raten Sie hier nicht, sondern schauen Sie in die Daten. Die Play Console zeigt den Anteil aktiver Geräte mit wenig freiem Speicher. Daran erkennen Sie, wie viele Ihrer Nutzer Platzprobleme haben. Außerdem zeigen die Aufschlüsselungen nach Land und Gerät in beiden Konsolen, welches Gewicht einfache Geräte in Ihrer Zielgruppe haben.

• Hohe Empfindlichkeit: Apps für den Massenmarkt wie Shopping, Lieferdienste, Kundenbindung und öffentliche Dienste.
• Mittlere Empfindlichkeit: Termin und Buchungsapps für eine klar umrissene Kundengruppe.
• Geringere Empfindlichkeit: Interne Firmenapps, deren Installation verpflichtend ist.

Also gilt: Je breiter Ihre Zielgruppe, desto mehr zählt jedes Megabyte.

Was bläht die App Größe am stärksten auf?

In den Paketen, die unser Team prüft, kommt der Ballast selten aus einer einzigen Quelle. Meist summieren sich mehrere kleine Gewohnheiten. Die folgende Liste zeigt, worauf wir bei einer Größenanalyse zuerst schauen:

• Unkomprimierte Bilder: Große PNG Exporte direkt aus der Designdatei und ungenutzte Dichtevarianten.
• Eingebettete Videos und Animationen: Ein einziges Onboarding Video kann einen großen Teil des Pakets belegen.
• Schriftfamilien: Die komplette Familie im Paket, obwohl die App nur zwei Schnitte nutzt.
• Bibliotheken von Drittanbietern: Schwere Bibliotheken für eine einzige Funktion und SDKs, die dieselbe Aufgabe doppelt erledigen.
• Native Bibliotheken: Eigene Kopien für jede Prozessorarchitektur, oft noch mit Debugsymbolen.
• Generierter Code: Laut Google kann generierter Code, etwa aus Protocol Buffers, die App erheblich vergrößern.
• Sprachressourcen: Übersetzungsdateien aus Bibliotheken für Sprachen, die Sie gar nicht anbieten.

Welcher Punkt bei Ihnen dominiert, sollten Sie messen statt raten. Der nächste Abschnitt erklärt, wie.

Wie messen Sie die echte App Größe?

Beginnen Sie mit den Store Konsolen, denn sie liefern die Zahl, die Nutzer sehen. Laut Hilfe der Play Console zeigt die Seite zur App Größe unter Android Vitals die Downloadgröße, einen Vergleich mit ähnlichen Apps, den Verlauf und den Anteil aktiver Geräte mit weniger als 2 GB freiem Speicher. Gerade dieser letzte Wert verrät viel über Ihre Zielgruppe.

Unter iOS öffnen Sie in App Store Connect den Reiter mit den Build Metadaten und gelangen dort zur Tabelle der App Dateigrößen. Sie listet Download und Installationsgröße für jede Gerätevariante. Vor dem Release liefert der App Thinning Size Report in Xcode dann geschätzte Werte pro Gerät direkt aus Ihrem Archiv.

1. Notieren Sie Download und Installationsgröße der aktuellen Version aus der Store Konsole.
2. Öffnen Sie das Paket mit dem APK Analyzer in Android Studio Ordner für Ordner.
3. Tragen Sie die zehn größten Dateien und die fünf größten Bibliotheken in eine Tabelle ein.
4. Wiederholen Sie die Messung nach jeder Optimierung und halten Sie den Unterschied fest.

Zum Beispiel genügt eine Tabelle mit den Spalten „Version, Downloadgröße, Installationsgröße, größter Posten“ für den Anfang.

Wie verkleinert das Android App Bundle die App Größe?

Die offizielle Dokumentation zum Android App Bundle beschreibt es als Veröffentlichungsformat, das Ihren gesamten kompilierten Code und alle Ressourcen enthält. Die Erstellung und Signierung der APKs übernimmt dann Google Play. Google Play erzeugt daraus optimierte APKs für jede Gerätekonfiguration. Somit lädt jedes Gerät nur den Code und die Ressourcen, die es braucht.

In der Praxis bedeutet das: Ein Smartphone mit hoher Pixeldichte überspringt Bilder für niedrige Dichte. Ein Gerät mit deutscher Systemsprache lädt keine japanischen Ressourcen. Dieselbe Logik gilt für native Bibliotheken bestimmter Prozessorarchitekturen. Statt einer riesigen APK erhält also jeder Nutzer ein Paket, das zu seinem Gerät passt.

Für neue Apps verlangt Google Play das App Bundle Format. Trotzdem begegnen uns ältere Projekte, die noch mit APKs veröffentlichen. Laut Hilfe der Play Console gelten für diese Apps ältere und engere Größenlimits. Wenn Sie ein älteres Projekt übernehmen, prüfen Sie daher zuerst das Veröffentlichungsformat.

Was entfernen R8 und das Ressourcen Shrinking unter Android?

R8 ist das Android Werkzeug, das ungenutzten Code entfernt, Klassen und Methodennamen kürzt und den Rest optimiert. Laut Googles Leitfaden entfernt R8 bei aktivierter Codeverkleinerung im Release Build zunächst ungenutzten Code. Danach entfernt das Android Gradle Plugin die Ressourcen, die nur dieser tote Code verwendet hat.

Diese beiden Schritte lohnen sich vor allem in Projekten mit vielen Abhängigkeiten. Denn selbst wenn Sie nur einen kleinen Teil einer Bibliothek nutzen, landet ohne Verkleinerung die ganze Bibliothek im Paket. Allerdings kann die Verkleinerung Abstürze zur Laufzeit auslösen, weil Klassen, die Ihre App per Reflection aufruft, versehentlich verschwinden.

• Aktivieren Sie die Verkleinerung zuerst in einem Testtrack, nie direkt in der Produktion.
• Übernehmen Sie alle Keep Regeln, die Ihre Bibliotheken empfehlen.
• Testen Sie Zahlung, Login und Benachrichtigungen im verkleinerten Build.
• Bewahren Sie die Mapping Datei auf, damit Absturzberichte lesbar bleiben.

Wie wir die Absturzüberwachung aufsetzen, zeigt unser Beitrag zu Absturzrate, Crashlytics und Store Grenzwerten im Detail.

Wie blähen Bilder die App Größe auf und was hilft?

Bilder sind der Posten, den unsere Prüfungen am häufigsten finden, und zugleich der am schnellsten behobene. Googles Leitfaden empfiehlt die Umwandlung in WebP. Dieses Format unterstützt verlustbehaftete und verlustfreie Kompression sowie Transparenz. Android Studio kann außerdem BMP, JPG, PNG und statische GIF Dateien direkt in WebP umwandeln.

Der zweite Schritt sind Vektorgrafiken. Für Icons und einfache Illustrationen ersparen sie Ihnen ein eigenes PNG für jede Pixeldichte. Allerdings rendern Vektoren laut Leitfaden bei großen Bildern langsamer. Nutzen Sie sie deshalb nur für kleine Grafiken.

Der dritte Schritt ist die Frage, ob das Bild überhaupt ins Paket gehört. Kampagnenbanner, Produktfotos und Blogbilder ändern sich häufig. Laden Sie sie vom Server, dann schrumpft das Paket, und Sie tauschen Bilder ohne neues Release. Die Grundprinzipien der Kompression gleichen dem Web; unser Leitfaden zur Bildoptimierung erklärt sie ausführlich.

Wie viel Platz belegen Bibliotheken und SDKs?

Jedes SDK wirkt für sich klein, doch die Summe kann überraschen. Analyse, Werbung, Zahlung, Chat, Karten und Absturzberichte bringen jeweils eigene Abhängigkeiten mit. Diese Abhängigkeiten überschneiden sich zudem oft oder erledigen dieselbe Arbeit doppelt.

Ein Beispielszenario: Stellen Sie sich eine E-Commerce App mit zwei Analyse SDKs, zwei Bibliotheken zum Laden von Bildern und einem ungenutzten Chatmodul vor. Ihr erster Schritt ist dann eine Bestandsaufnahme. Schreiben Sie auf, welches Team welches SDK aus welchem Grund eingebaut hat. Danach entfernen Sie, was niemand braucht.

Auch Googles Leitfaden empfiehlt, unnötigen Bibliothekscode zu entfernen und leichtere, mobil optimierte Alternativen zu wählen. Er erwähnt außerdem, dass neuere Android Versionen einen eingebauten Bilddecoder haben. Eine eigene Bibliothek nur zum Dekodieren von GIF oder WebP ist dann vielleicht überflüssig. Ein klarer Messplan erleichtert es zudem, doppelte Analyse SDKs zu streichen. Dabei hilft unser Beitrag dazu, welche Events Sie mit Firebase Analytics messen sollten.

Warum machen native Bibliotheken eine App größer?

Native Bibliotheken sind Dateien in C oder C++, die für jede Prozessorarchitektur einzeln kompiliert sind. Spiele Engines, Bildverarbeitung und manche Sicherheitsbibliotheken enthalten solche Dateien. Weil jede Architektur eine eigene Kopie braucht, kann eine einzelne universelle APK ihren Umfang vervielfachen.

Das App Bundle löst den Großteil davon, denn es liefert nur die passende Architektur aus. Darüber hinaus nennt Googles Leitfaden zwei weitere Schritte. Erstens: Entfernen Sie Debugsymbole aus Release Builds. Zweitens: Packen Sie native Bibliotheken unkomprimiert. Dann muss das System sie bei der Installation nicht kopieren, und auch Updates fallen kleiner aus.

Fragen Sie sich außerdem, welche Architekturen Sie wirklich unterstützen müssen. Eigene Builds für alte Geräte, die in Ihrer Zielgruppe kaum vorkommen, erhöhen den Wartungsaufwand. Treffen Sie diese Entscheidung trotzdem auf Basis gemessener Daten. Schließen Sie echte Nutzer nicht nur wegen ein paar Megabyte aus.

Wie verkleinern Sie die IPA unter iOS?

Unter iOS heißt der zentrale Mechanismus App Thinning. Der App Store schickt jedem Gerät nur die Architektur und Auflösungsvarianten, die es braucht. Damit das zuverlässig funktioniert, sollten Ihre Bilder in Asset Katalogen liegen. Lose in Ordnern abgelegte Bilder profitieren nicht davon.

1. Verschieben Sie Bilder in Asset Kataloge und hinterlegen Sie für jede Auflösung die richtige Variante.
2. Erzeugen Sie mit dem App Thinning Size Report in Xcode geschätzte Größen pro Gerät.
3. Entfernen Sie ungenutzte Swift Pakete und Frameworks aus dem Projekt.
4. Verlagern Sie eingebettete Videos und große Audiodateien auf einen Server oder in Hintergrundassets.
5. Prüfen Sie in App Store Connect die Variantentabelle auf ein Warnsymbol.

Apples Seite zu maximalen Buildgrößen nennt eigene Obergrenzen für die ausführbare Datei und für die unkomprimierte App. Diese Grenzen sind allerdings technische Decken. Das Ziel, das für die Nutzererfahrung zählt, liegt weit darunter. Orientieren Sie sich deshalb an vergleichbaren Apps und an Ihrer eigenen Vorversion.

Wie funktioniert die Auslieferung auf Abruf unter Android?

Nicht jeder Nutzer braucht jeden Inhalt am ersten Tag. Unter Android heißt die offizielle Lösung Play Feature Delivery und Play Asset Delivery. Laut Dokumentation können Sie mit Play Feature Delivery Funktionsmodule hinzufügen. Diese kommen unter Bedingungen, die Sie festlegen, oder Nutzer laden sie später zur Laufzeit.

Play Asset Delivery ist Googles Lösung, um große Mengen an Assets flexibel auszuliefern, vor allem für Spiele. Die Hilfe der Play Console listet dafür verschiedene Auslieferungsarten: bei der Installation, direkt danach und auf Abruf. Jede Art hat eigene Größenlimits. Weil sich diese Limits ändern können, prüfen wir die Werte in jedem Projekt auf der offiziellen Seite.

• Gute Kandidaten: Selten genutzte Adminbereiche, zusätzliche Sprachpakete, fortgeschrittene Spiellevel und hochauflösende Medien.
• Schlechte Kandidaten: Login, Bezahlvorgang und der Kernablauf, den jeder Nutzer in der ersten Minute braucht.

Kurz gesagt: Betrachten Sie die Erstinstallation als kleinstes Paket, mit dem Nutzer die App öffnen und ihren Nutzen erleben.

Wie trennen Sie große Inhalte auf Apple Plattformen ab?

Lange bot Apple für große Inhalte eine Technik für Ressourcen auf Abruf. Die Seite von App Store Connect zu den Limits dieser Ressourcen erklärt jedoch, dass Apple diese Technik inzwischen abkündigt. Stattdessen empfiehlt Apple den Umstieg auf das Framework Background Assets.

Mit Background Assets verwalten Sie große Inhalte getrennt vom App Paket und laden sie im Hintergrund. Auch Apples Seite zu Buildgrößen verweist auf dieses Framework, um größere Assets außerhalb des Builds bereitzustellen. Somit starten Nutzer mit einem kleinen ersten Paket, und zusätzliche Inhalte kommen bei Bedarf.

Ein Punkt ist dabei wichtig. Bei Apps mit solchen Assets kann Apple auf der Produktseite eine Größe mit dem Zusatz „bis zu“ anzeigen, die wesentliche Asset Pakete einschließt. Wer Pflichtinhalte nur in den Hintergrund verschiebt, verkleinert die Zahl im Store also nicht. Der echte Gewinn entsteht erst, wenn Sie wirklich optionale Inhalte abtrennen.

Sind plattformübergreifende Apps bei der App Größe im Nachteil?

Frameworks wie React Native und Flutter bringen ihre eigene Laufzeitumgebung ins Paket. Daher kann eine sehr einfache plattformübergreifende App größer starten als derselbe Bildschirm in nativem Code. Wächst die App, schrumpft dieser Startnachteil jedoch im Verhältnis zur Gesamtgröße.

Nach unserer Erfahrung entscheidet die Projektdisziplin, nicht das Framework. Unkontrolliert ergänzte Pakete, unkomprimierte Bilder und überflüssige Schriften vergrößern Apps in jeder Technologie. Treffen Sie die Technologiewahl also nicht allein wegen der Größe.

Wenn Sie die Vor und Nachteile genauer kennen möchten, helfen unser Leitfaden zu React Native und unser Beitrag dazu, ob Flutter zu einer Business App passt. In beiden Frameworks können Sie die meisten Schritte aus diesem Leitfaden anwenden.

Beeinflusst auch die Updategröße Ihre Nutzer?

Ja. Nutzer laden Ihre App einmal, Updates dagegen viele Male. Ist jedes Update schwer, schalten manche automatische Updates ab oder warten auf WLAN. Dann bleibt ein Teil Ihrer Zielgruppe auf einer alten Version.

Nutzer alter Versionen verpassen Fehlerbehebungen und neue Funktionen. Folglich steigen Supportaufwand und Absturzrate. Muss eine kritische Korrektur alle erreichen, brauchen Sie einen Mechanismus für erzwungene Updates. Wie Sie ihn richtig aufbauen, erklären wir in unserem Beitrag App Update erzwingen.

Damit Updates klein bleiben, sollten Sie große, unveränderte Dateien nicht bei jedem Build neu erzeugen. Eine große Datendatei, die jeder Build neu schreibt, kann das Differenzupdate aufblähen, obwohl sich ihr Inhalt nicht ändert. Auch Googles Rat, native Bibliotheken unkomprimiert zu packen, zielt auf kleinere Updates.

Wie schneiden die Methoden zum Verkleinern von APK und IPA im Vergleich ab?

Die folgende Tabelle fasst die Methoden zusammen, die wir bei der App Größe am häufigsten einsetzen: nach Plattform, erwarteter Wirkung und Aufwand. Die Spalte zur Wirkung ist ein Startwert aus der Praxis, keine Garantie. Prüfen Sie sie deshalb immer mit Messungen im eigenen Projekt.

Wie Sie sehen, kommen die schnellsten Gewinne meist aus den Zeilen mit geringem Aufwand. Deshalb empfehlen wir, dort zu beginnen.

Welche Fehler bei der App Größe sollten Sie vermeiden?

Eine kleinere App ist ein sinnvolles Ziel. Falsch umgesetzt schadet die Verkleinerung jedoch der App selbst. Diese Fehler sieht unser Team in übernommenen Projekten am häufigsten:

• Verkleinern ohne Test: Codeverkleinerung aktivieren und ohne Test von Zahlung oder Login veröffentlichen.
• Überkompression: Bilder so stark komprimieren, dass Produktfotos verschwimmen und Screenshots im Store billig wirken.
• Alles auf den Server: Selbst Inhalte für den ersten Start müssen erst laden, und Nutzer starren auf einen leeren Bildschirm.
• Einmalige Aktion: Die Größe einmal senken und danach in späteren Releases nicht mehr beachten.
• Nur eine Zahl beobachten: Die Downloadgröße senken, während Installations oder Updategröße unbemerkt wächst.

Zum Beispiel: Wenn Sie die Bilder des Begrüßungsbildschirms auf einen Server verlagern, sehen Nutzer mit schwacher Verbindung zuerst eine leere Fläche. Die Gründe für frühe Abwanderung behandeln wir in unserem Beitrag dazu, warum Nutzer Apps in den ersten 7 Tagen löschen.

Wie messen Sie den Effekt der App Größe auf Downloads?

Ob eine Größenänderung wirkt, zeigt nur ein Vorher und Nachher Vergleich. Beobachten Sie dafür die Akquisedaten im Store, also den Anteil der Besucher der Produktseite, die installieren, zusammen mit Ihren Releasedaten.

1. Halten Sie die Conversion Rate der Produktseite für die vier Wochen vor der Größenarbeit fest.
2. Notieren Sie das Datum, an dem Sie den kleineren Build veröffentlichen.
3. Halten Sie andere Faktoren wie Werbebudget, Screenshots und Beschreibung möglichst konstant.
4. Vergleichen Sie dann die folgenden vier Wochen mit den vorherigen.
5. Beobachten Sie im selben Zeitraum Deinstallationsrate und Bindung in der ersten Woche.

Berücksichtigen Sie zudem saisonale Effekte. Feiertage, Schulferien und Kampagnenwochen verschieben die Nachfrage von selbst und können den Größeneffekt überdecken. Wählen Sie daher Vergleichszeiträume mit ähnlichen Kalenderbedingungen. Außerdem lohnt ein Blick auf die Länder: In Märkten mit vielen Einsteigergeräten zeigt sich der Effekt oft deutlicher.

Ein Beispielszenario: Sie nehmen das Intro Video aus dem Paket und lassen die Screenshots im selben Zeitraum unverändert. Dann können Sie die Veränderung der Conversion Rate mit mehr Sicherheit der Größe zuordnen. Ändern Sie mehrere Dinge gleichzeitig, wissen Sie nicht, welcher Schritt gewirkt hat.

Wie passt Größenoptimierung zur App Store Optimierung?

Die Größe ist keine isolierte Zahl auf der Store Seite. Sie ist eines der Signale, die Nutzer vor der Entscheidung abwägen. Titel, Icon, Screenshots, Bewertung und Beschreibung wecken Interesse. Die Größe beeinflusst dann die Frage „jetzt installieren oder später?“. Somit kann ein unnötig schweres Paket eine starke Store Seite schwächen.

Deshalb sehen wir die Arbeit an der Größe als technische Seite der App Store Optimierung. Text und Bilder der Store Seite behandeln wir in unserem Leitfaden zur ASO. Planen Sie beides gemeinsam, dann wird mehr von dem Traffic, den Sie bezahlen, zu Installationen.

Wir empfehlen außerdem, die Größe vor dem Start einer Werbekampagne zu prüfen. Denn Anzeigen erreichen Nutzer genau in dem Moment, in dem sie am schnellsten entscheiden. Eine Warnung zum Mobilfunkdownload kann dann einen Teil jedes bezahlten Klicks verschenken.

Wie gehen wir in Ihrem Projekt mit der App Größe um?

Wir, Talha Aslan und Team, sprechen über die Größe am ersten Tag, nicht am Ende. Stehen Technologie, Bildsprache, SDK Liste und Serverinhalte schon in der Konzeptphase fest, bleibt das Paket im Store von selbst schlank. Wir messen und dokumentieren die Größe bei jedem Release. Wächst sie in Richtung eines Limits, suchen wir die Ursache und beheben sie.

Wir entwickeln Ihre App und bringen sie in die Stores. Android App Bundle, App Thinning unter iOS, Inhalte auf Abruf und die Messung gehören für uns selbstverständlich dazu. Planen Sie eine neue App, oder bremst die Größe Ihrer bestehenden App die Downloads? Dann fordern Sie auf unserer Seite zur App Entwicklung ein Angebot an. Gemeinsam legen wir Umfang und Zeitplan für Ihr Projekt fest.