Fotouploads in Ihrer KI-gebauten App – ohne dass alles zusammenbricht

In dem Moment, in dem Ihre App nicht mehr nur aus Text besteht und Nutzer anfangen, Fotos hochzuladen, ändert sich etwas. Bild- und Datei-Uploads hinzuzufügen bedeutet, dass ein Nutzer ein Foto, eine Quittung oder ein Dokument von seinem Gerät in Ihre App schicken kann, die es speichert und später wieder anzeigt – ein Profilbild, ein Kassenbon, ein Foto einer beschädigten Lieferung, ein PDF-Vertrag. Das ist eine dieser Funktionen, die wie ein einziges Häkchen aussieht und sich dann als eine Handvoll Stolperstellen entpuppt. Keine davon ist schwierig. Aber genau die, vor denen einen niemand warnt, tauchen drei Wochen nach dem Launch auf – meist bei Ihrem begeistertsten Nutzer.

Das hier ist ein Rundgang durch das, was tatsächlich passiert, wenn jemand auf „Hochladen“ tippt, die drei Fehler, die später zubeißen, und die genauen Dinge, die Sie Ihrem Builder sagen sollten, damit Sie ihnen gar nicht erst begegnen.

Was passiert eigentlich, wenn man ein Foto in eine App hochlädt?

Ein Foto-Upload löst vier Schritte in dieser Reihenfolge aus: Ihr Handy übergibt die Datei an die App, die App schickt sie an einen separaten Dateispeicher (nicht an die Datenbank), die App speichert einen Link zu dieser Datei neben dem Datensatz, und später ruft sie die Datei über diesen Link ab, sobald jemand den Datensatz ansieht.

So sieht das Schritt für Schritt aus:

Das Handy übergibt Ihrer App die Datei. Ein modernes Handyfoto ist oft 4 bis 12 Megabyte groß. Das ist nicht nichts.
Ihre App schickt diese Datei irgendwohin zur Speicherung – nicht in die Datenbank Ihrer App, sondern in einen separaten Speicher-Bucket, der für Dateien gebaut ist.
Ihre App speichert einen Link zu dieser Datei in der Datenbank, direkt neben dem Rest des Datensatzes (diese Quittung gehört zu dieser Ausgabe).
Wenn später jemand den Datensatz ansieht, ruft die App die Datei anhand dieses Links aus dem Speicher ab und zeigt sie an.

Bei Schritt 2 und 3 passieren die meisten Fehler. Man stellt sich vor, das Foto werde „in der App gespeichert“. Wird es nicht, und sollte es auch nicht. Dateien leben im Speicher; Ihre Datenbank merkt sich nur, wo. Wenn diese Trennung stimmt, wird alles Nachfolgende einfacher.

Sollte man hochgeladene Fotos direkt in der Datenbank speichern?

Nein – und das ist der häufigste Upload-Fehler, den KI-Builder standardmäßig manchmal machen, wenn man nicht ausdrücklich anders sagt. Ein 10-MB-Foto direkt in Ihre Datenbank zu stopfen ist, als würden Sie Ihre Möbel in Ihrer Geldbörse aufbewahren. Die Datenbank ist für kleine, strukturierte Dinge gebaut – Namen, Daten, Preise. Kippt man Fotos hinein, wird sie langsam, Backups blähen sich auf, und eines Tages braucht eine Seite, die früher sofort geladen war, plötzlich sechs Sekunden, weil sie hundert Fotos in voller Auflösung mit sich herumschleppt.

Was Sie stattdessen wollen: Die Datei wandert in den Dateispeicher (Ihr Builder nennt es vielleicht „Storage Bucket“ oder „Blob Storage“), und die Datenbank enthält nur den Link. Fordern Sie es direkt an:

„Speichere hochgeladene Bilder im Dateispeicher, nicht in der Datenbank. Im Datensatz soll nur die Datei-URL stehen.“

Wie verhindert man, dass Nutzer den falschen Dateityp oder eine riesige Datei hochladen?

Sie legen vorab fest, was erlaubt ist – Dateityp, Größenlimit und eine klare Fehlermeldung – und sagen es Ihrem Builder ausdrücklich, denn ohne diese Regeln akzeptiert Ihre App alles, einschließlich Dateien, die den Upload komplett zum Stillstand bringen. Zwei reale Fälle zeigen, warum – beide aus Apps, die im Test einwandfrei liefen:

Eine Frau betreibt ein kleines Catering-Geschäft und hat eine App gebaut, mit der Kunden Fotos von Torten hochladen können, die ihnen gefallen. Alles lief bestens, bis eine Kundin ein 47-MB-Foto direkt von einer Profikamera hochlud. Der Upload hing fest, die Kundin gab auf, und die Betreiberin erfuhr davon in Form von „deine App ist kaputt“. War sie nicht – es war einfach nie ein Größenlimit gesetzt worden, also versuchte die App endlos, eine riesige Datei zu schlucken.

Ein zweiter Fall: Ein Freelancer hat ein Kundenportal gebaut, in dem Leute „ihr Logo“ hochladen sollen. Ein Kunde lud eine .zip-Datei hoch. Ein anderer ein 90-seitiges PDF. Die App akzeptierte alles, weil ihr nie gesagt wurde, was ein Logo eigentlich sein sollte.

Legen Sie diese drei Dinge vorab fest:

Welche Dateitypen? Nur Fotos? Dann JPG und PNG akzeptieren und alles andere mit einer freundlichen Meldung ablehnen.
Wie groß? Ein sinnvolles Foto-Limit liegt bei etwa 5 bis 10 MB. Groß genug für ein echtes Handyfoto, klein genug, um einen kompletten Kameraspeicher-Dump zu stoppen.
Was, wenn es falsch ist? Die App sollte das freundlich mitteilen – „Bitte lade ein JPG oder PNG unter 10 MB hoch“ – statt einfach einzufrieren.

Sagen Sie Ihrem Builder:

„Erlaube nur JPG- und PNG-Bilder bis 10 MB. Wenn jemand etwas anderes oder eine zu große Datei hochlädt, zeige eine klare Meldung statt stillschweigend zu scheitern.“

Warum fühlt sich Ihre App langsam an, wenn sie viele Fotos enthält?

Weil jeder Betrachter jedes Mal das vollformatige Original herunterlädt, nicht eine verkleinerte Kopie – auf seinem Handy, mit seinem Datenvolumen, jedes einzelne Mal, wenn jemand den Datensatz öffnet. Angenommen, jemand lädt ein knackiges 8-MB-Foto hoch, und für sich allein funktioniert es problemlos. Multiplizieren Sie das mit einer Galerie aus zwanzig Fotos, und Ihre flotte kleine App fühlt sich an, als würde man durch Schlamm waten.

Die Lösung hat einen Namen, den es sich zu merken lohnt, denn Ihr Builder wird ihn kennen: ein Thumbnail, oder eine skalierte Version. Die Idee ist, dass Sie das Original behalten, aber zusätzlich eine kleine, webtaugliche Kopie erstellen und diese kleine Kopie in Listen und Vorschauen anzeigen. Das volle Bild lädt erst, wenn jemand es tatsächlich groß sehen will.

„Erzeuge bei jedem hochgeladenen Bild zusätzlich eine kleinere, verkleinerte Version für Vorschauen und Listen. Zeige standardmäßig die kleine Version und lade das volle Bild nur, wenn jemand darauf klickt, um es anzusehen.“

Sie müssen nicht verstehen, wie das gemacht wird. Sie müssen nur wissen, dass es das gibt, damit Sie danach fragen können, bevor sich Ihre App langsam anfühlt, und nicht erst danach.

Ein paar leisere Dinge, die sich zu entscheiden lohnen

Diese drei Entscheidungen bringen Ihre App nicht zum Absturz, wenn Sie sie überspringen, aber sie sind jetzt billiger zu treffen als später nachzurüsten: wer die Datei sehen darf, was mit ihr passiert, wenn der Datensatz gelöscht wird, und ob der Upload auf dem Handy funktioniert.

Wer darf die Datei sehen? Ein Profilbild darf jeder sehen. Ein eingescannter Ausweis oder ein unterschriebener Vertrag nicht. Wenn die Datei privat ist, sagen Sie Ihrem Builder, dass der Link eine Anmeldung erfordern soll, statt eine öffentliche URL zu sein, die jeder öffnen kann. Das ist der Punkt, auf den ich bei allem Sensiblen am stärksten drängen würde.
Was passiert, wenn der Datensatz gelöscht wird? Wenn jemand eine Ausgabe löscht – soll das zugehörige Quittungsfoto mit aufgeräumt werden? Sonst sammeln sich langsam verwaiste Dateien an, für deren Speicherung Sie bezahlen und die Sie längst vergessen haben.
Funktioniert es auf dem Handy? Die meisten Uploads passieren auf Handys, und Handys bieten sowohl „jetzt ein Foto machen“ als auch „aus der Galerie auswählen“ an. Testen Sie beides auf einem echten Handy, nicht nur auf Ihrem Laptop, wo Sie eine Datei immer nur per Drag-and-drop hineinziehen.

Testen Sie es wie ein Fremder

Testen Sie es, indem Sie absichtlich versuchen, es so zu brechen, wie ein echter Nutzer es versehentlich tun wird – ein normales Foto, eine übergroße Datei, der falsche Dateityp, ein Live-Upload direkt von der Handykamera und ein Löschvorgang – bevor Sie es als fertig abhaken:

Laden Sie ein normales Handyfoto hoch. Erscheint es, und ist die Vorschau schnell?
Laden Sie etwas Riesiges hoch. Stoppt die App Sie mit einer klaren Meldung, oder hängt sie sich einfach auf?
Laden Sie den falschen Typ hoch – ein PDF, wo ein Foto erwartet wird. Erklärt die App die Regel?
Öffnen Sie die App auf Ihrem Handy und laden Sie direkt von der Kamera hoch.
Löschen Sie einen Datensatz und prüfen Sie, ob mit der zugehörigen Datei so verfahren wird, wie Sie es festgelegt haben.

Wenn alle fünf Punkte funktionieren, haben Sie die Stolperstellen umschifft, an denen die meisten Leute hängen bleiben.

Uploads sind eine dieser Funktionen, bei denen die Lücke zwischen „funktioniert in der Demo“ und „funktioniert für einen Fremden im Zug mit einem 12-MB-Katzenfoto“ genau aus den oben genannten Entscheidungen besteht. Keine davon ist schwierig. Sie werden nur leicht übersehen – und lassen sich jetzt viel leichter anfordern als später reparieren.

Wenn Sie das Hinzufügen von Uploads bisher aufgeschoben haben, weil es sich nach einem großen technischen Sprung anfühlte: Ist es nicht. Öffnen Sie Ihren Builder, fordern Sie Bildspeicher mit Größenlimit und Thumbnail an, und schauen Sie, was dabei herauskommt. Versuchen Sie dann, es auf Ihrem Handy zu knacken – das ist der eigentliche Test, und er dauert fünf Minuten.