HelioPeak bauen: Lektionen aus der unabhängigen iOS-Entwicklung

Einige Monate Abende und Wochenenden, sechs Sprachen, drei Plattformen, ein Entwickler. Das ist in einem Satz die Geschichte hinter HelioPeak. Dieser Artikel handelt davon, wie diese Geschichte in der Praxis war.

Er ist etwas persönlicher als die anderen Artikel dieser Serie. Ich versuche ehrlich zu sein darüber, was ein Solo-Projekt in dieser Zeit bedeutet, ohne die typischen Klischees von "folge einfach deiner Leidenschaft" oder "es kostet weniger, als du denkst". Beide sind meist falsche Vereinfachungen. Die Realität ist nuancierter, mühsamer und heimlich befriedigender, als heroische Erzählungen vermuten lassen.

Für jeden, der selbst überlegt, etwas zu bauen, hoffe ich, dass dieser Artikel informativ ist. Für jeden, der einfach neugierig ist, wie man eine App von Grund auf baut, hoffe ich, dass er interessant ist. Für jeden HelioPeak-Nutzer: Hier ist etwas vom Kontext, der hilft zu verstehen, warum die App so ist, wie sie ist.

Der Ausgangspunkt

Ich bin kein ausgebildeter Swift-Entwickler. Mein Hintergrund ist IT, Infrastruktur, Systemarchitektur, nicht mobile Entwicklung. Ich hatte noch nie eine iOS-App vor HelioPeak veröffentlicht. Meine Swift-Erfahrung beschränkte sich auf einige Stunden Experimentieren mit SwiftUI in 2024, hauptsächlich aus Neugier.

Trotzdem wollte ich eine spezifische iOS-App machen: einen anständigen PVOutput-Client für mich selbst. Die bestehenden Apps machten nicht genau das, was ich wollte: Es fehlte die iPad- und Mac-Unterstützung, die ich wollte, die spezifischen Funktionen, die ich erwartete (Notes, Jahr-für-Jahr-Vergleiche, hervorgehobener Specific Yield), und meine eigene Sprache neben Englisch. Da ich genug technischen Hintergrund habe, um sie nicht unmöglich zu finden, entschied ich an einem Abend im Januar 2026, eine zu machen. Was sie inzwischen geworden ist.

Die KI-Unterstützung

Ohne Claude (das KI-Tool, das ich verwende) hätte dieses Projekt wahrscheinlich nicht existiert. Nicht weil die KI alles für mich gemacht hat, sondern weil sie die Lernschwelle niedrig genug machte, um Abende durchzuhalten, an denen ich nach einem Arbeitstag keine Energie hatte, ein Swift-Tutorial zu lesen. Die KI senkte die Sprunghöhe.

Was die KI in der Praxis tut: Boilerplate generieren (alles, was SwiftUI für einen neuen Bildschirm, eine Ansicht, eine Komponente erwartet), Übersetzungen zwischen Frameworks vorschlagen (wie sich ein UIKit-Setup zu SwiftUI ändert), Architektur-Überlegungen vorschlagen (ist lokaler oder globaler Zustand hier besser, sollte ich ein ObservableObject oder ein @State verwenden, wie behandle ich diesen Fehlerfall?), Fehlermeldungen entschlüsseln.

Was die KI nicht tut: Architekturentscheidungen für mich treffen (ich muss die Kompromisse verstehen), Bugs in meinem eigenen Code finden (ich muss laufen lassen und debuggen), die Erfahrung von Tests auf echtem Gerät ersetzen (ein Simulator lügt über Leistung, Widgets, Berechtigungen), die Produktrichtung bestimmen (die KI kann einmal eine Frage mit möglichen Vorschlägen stellen, aber die Wahl bleibt bei mir).

Wahrscheinlich hat die KI meine Produktivität verdoppelt oder verdreifacht. Sie hat meine Arbeit nicht ersetzt. Es ist eine wichtige Unterscheidung, weil einige Artikel über "KI-unterstützte Entwicklung" in 2026 den Eindruck erwecken, dass ein Nicht-Entwickler mit Prompts in einem Wochenende zu einer Live-App kommen kann. So ist es nicht. Der schwierige Teil bleibt: das Problem verstehen, entscheiden, was zu tun ist, verifizieren, dass das, was die KI vorschlägt, wirklich Sinn macht, und das debuggen, was weiterhin schief geht. Dieser Teil ist nicht einfacher geworden.

Was ich in der Produktionsplanung unterschätzt habe

Einige Dinge, die ich zu Beginn des Projekts gravierend unterschätzt habe, die jedes neue Indie-Projekt vielleicht unterschätzt:

Internationalisierung. Sechs Sprachen von Anfang an. Eine fundamental richtige Produktwahl (was eine breitere globale Basis vom ersten Tag an hat), aber ich habe die Betriebskosten enorm unterschätzt. Jede neue UI-String muss durch sechs Übersetzungen gehen. Jede Änderung kann eine Übersetzung in einer Sprache brechen, wenn man nicht aufpasst. Strings in Swift werden nicht je nach aktiver Sprache interpoliert, so dass ein falsch platzierter Platzhalter einen Crash auf Deutsch verursachen, aber auf Englisch funktionieren kann. Die Überprüfung jedes Releases in allen Sprachen mit Testszenarien ist anstrengend.

Apples App Store-Prozess. Meine erste Einreichung wurde von einer Developer Review abgelehnt, die ich nicht erwartet hatte (zur Handhabung von Background-Tasks und Datenuploads). Ich brauchte drei Iterationen, bevor ich die erste Version live bekam. Jedes folgende Release war reibungsloser, aber die Periode vom ersten Submit bis zum ersten App-Store-live war zwei Wochen länger als geplant.

Datenschutz-Compliance. Datenschutzrichtlinie, App Tracking Transparency, Privacy Nutrition Labels, API-Manifeste: alles Anforderungen, die klein erscheinen, aber Stunden Arbeit erfordern und regelmäßige Updates von Apple erhalten, die alte Vereinbarungen brechen. Ich habe mehr Zeit mit Datenschutz-Compliance-Formularen verbracht als mit dem Schreiben der Notes-Funktion.

Marketing und Entdeckung. Eine gute App zu machen ist eine Sache. Leute zu finden, die sie nutzen wollen, ist eine andere. Ich habe viele Abende mit Foren-Posts, dem Kontaktieren von Bloggern, Antworten auf Reddit und Anpassen der App-Store-Beschreibungen verbracht, ohne klar sagen zu können, welche dieser Aktivitäten wirklich etwas bewirkt hat. Indie-Apps leben oder sterben mehr durch Mundpropaganda und zufällige Listen-Einschlüsse als durch traditionelles Marketing.

Was ich an technischen Details unterschätzt habe

Einige technische Lektionen, die erst während des Wegs klar wurden:

Tests auf echtem Gerät sind unersetzlich. Was auf dem Mac-Simulator gut aussieht, scheitert manchmal auf einem echten iPhone. Der Simulator hat nicht das thermische Throttling des echten Geräts, zeigt nicht die echten Akkuprobleme mit Widgets, die sich aktualisieren, zeigt nicht das echte Netzwerkverhalten außerhalb des Heim-WLANs. Ich habe während der Pendelfahrt zur Arbeit Bugs auf meinem iPhone gefangen, die ich am Schreibtisch nie gesehen hätte.

Widgets sind schwieriger, als sie scheinen. iOS-Widgets sind ein eigenes Nebenprojekt mit eigenem Lebenszyklus, eigenen Speichergrenzen, eigenem Zeitrahmen und eigenem Daten-Vor-Berechnungs-Paradigma. Sie live wirken zu lassen, erfordert eine Pre-Rendering-Architektur in der Haupt-App, die schnell komplexer wird als der Hauptbildschirm selbst.

Die Lokalisierung von Daten, Zahlen und Währungen ist ein Minenfeld. "5.400 kWh" im niederländischen/deutschen Format bedeutet 5400; "5,400" im englischen/amerikanischen Format bedeutet auch 5400; aber "5,400" im französischen/italienischen Format bedeutet 5,4. Eine einzige falsche Interpretation, und Sie erhalten Produktionszahlen, die in einer Sprache einen Wert haben, der 1.000-mal niedriger ist. Ich habe mehr Zeit mit dem Debuggen dieser Fehler verbracht, als ich zugeben möchte.

Apples Swift Charts ist brillant, aber unvollständig. Apples Framework für Charts in SwiftUI ist elegant für Standardfälle, aber es fehlen die Randfälle (benutzerdefinierte Labels an spezifischen Datenpunkten, nicht standardmäßige Tooltips, bestimmte Zoom-Typen). Ich musste mehrere Fälle mit benutzerdefinierten Overlays über SwiftUI Charts lösen, was funktioniert, aber kompliziert ist.

Was ich über Indie-Preisgestaltung gelernt habe

Mein Ansatz zur Preisgestaltung von HelioPeak hat sich im Laufe der Zeit geändert, und die Daten haben mich einige Dinge gelehrt.

Beim ersten Launch im April 2026 war der IAP bei 2,99 €. Es war zu niedrig. Ich bemerkte in den Daten, dass die zahlenden Nutzer aktiver und engagierter blieben, aber die zahlende Gruppe klein war, weil der Preis selbst "nicht sehr wichtig" signalisierte. In Version 2.0 erhöhte ich ihn auf 6,99 €, und zu meiner Überraschung änderte sich die Konversionsrate kaum, aber die Einnahmen pro Nutzer mehr als verdoppelten sich. Bestehende Nutzer mit dem alten Preis behalten ihren Unlock; neue Nutzer zahlen den neuen Preis.

Drei Reflexionen daraus:

Zu niedrig beim Launch. Rückblickend hätte ich höher anfangen und es mit Qualität rechtfertigen sollen. "2,99 €" klingt billig. "6,99 €" klingt seriös. Der Unterschied ist psychologisch, nicht wirtschaftlich.

Ehrlich beim Relaunch. Einen Preis retroaktiv für bestehende Nutzer zu erhöhen, ist heimtückisch. Es prospektiv zu halten (alte Nutzer behalten ihren alten Preis, neue Nutzer zahlen den neuen) ist der einzige ehrliche Weg. Alles andere bricht das Vertrauen.

No-Subscription-Commitment. Ich glaube nach einigen Monaten weiterhin an mein ursprüngliches Commitment (einmaliger Kauf, kein Abonnement für die Kernfunktionen). Es ist ein Geschäftsmodell-Trade-off, der einschränkt, wie aggressiv ich wachsen kann, aber die Nutzer über die 25-jährige Lebensdauer der Solaranlage respektiert.

Was ich über Konversionsraten gelernt habe: Der Prozentsatz der kostenlosen Nutzer, die zu zahlenden konvertieren, ist niedrig (zwischen 3 und 8 % laut meinen Daten), was typisch für eine Indie-App ist. Die meisten Nutzer bleiben im kostenlosen Tarif. Und das ist okay. Eine Indie-App braucht keine Massen-Konversion, sondern eine stabile, engagierte Basis von Nutzern, die die App schätzen und gelegentlich zahlen. Das ist, was HelioPeak zu haben scheint.

Was ich über die Nutzer gelernt habe

Einige Beobachtungen über die HelioPeak-Nutzerbasis, die überrascht oder meine Erwartungen bestätigt haben:

Sie sind älter, als ich dachte. Das Durchschnittsalter der Käufer, die ich durch Feedback in Foren gesehen habe, liegt bei etwa 50, nicht 30. Es ergibt rückblickend Sinn: Solarmodule sind eine langfristige Investition, und Haushalte, die Module haben, tendieren zu etablierten Personen mit Wohneigentum. Die demografischen Daten ändern, wie ich App-Copy und Artikel schreibe: weniger Fachjargon, mehr Erklärung, mehr Links zu Hintergrundinformationen.

Sie haben echte Qualitätsansprüche. Die HelioPeak-Bewertungen sind detailliert, technisch kompetent und spezifisch im Feedback. Menschen aus dieser Demografie schreiben nicht "5 Sterne, gute App", sie schreiben "5 Sterne, schätze besonders das iPad-Layout, aber Funktion Y könnte folgendermaßen verbessert werden". Das verlangt Ernstnahme und führt die Roadmap stärker als Bewertungen von jüngeren Nutzern mit weniger tiefgreifenden Apps.

Sie sind community-orientiert. Ein signifikanter Teil der HelioPeak-Nutzerbasis ist über Foren-Threads (Tweakers, PVOutput-Forum) gekommen, statt über traditionelles Marketing oder ASO im App Store. Menschen aus der Solar-Community geben ihr Wissen an andere Solar-Nutzer weiter, und ein guter Pitch in einem aktiv gepflegten Foren-Thread bringt mehr stabile Nutzer als eine Reddit-Ads-Kampagne.

Sie sind treu, wenn man es richtig macht. Die Abwanderung ist gering. Nutzer, die nach einigen Monaten bei der App bleiben, bleiben oft Jahre. Es bestätigt eine breitere Erfahrung in der Indie-Landschaft: Wenn Ihre App einem Bedürfnis entspricht und ihre Nutzer respektiert, ist das Problem nicht die Bindung, sondern die Akquisition.

Die kleinen Lektionen, die ich unerwartet wertvoll fand

Einige praktische Dinge, die meinen Workflow durch ihre Einführung mehr verbessert haben, als ich erwartet hatte:

Ein Commit-Skript schreiben. Statt git commits manuell zu machen, habe ich jetzt ein Skript, das die Änderungen validiert, den Commit macht, auf GitHub hochlädt und ein dSYM für das Crash Reporting an Sentry sendet. Die zwei Stunden, dieses Skript zu schreiben, haben in dem letzten Jahr Dutzende von Stunden gespart.

TelemetryDeck von Anfang an integrieren. Ich hätte vom ersten Tag an mit Analytics begonnen, nicht von einer späteren Version. Die ersten Wochen produzierten Daten, die wertvoll gewesen wären zu behalten, und ich habe sie verloren, weil ich noch nicht herausgefunden hatte, wie ich sie sammeln kann, ohne meine eigenen Datenschutzprinzipien zu verletzen. (Schließlich habe ich es herausgefunden; siehe Die Datenschutzfrage.) Diese verlorenen Daten sind verloren.

Notizen an mich selbst im Code. Kleine Kommentare // HACK: oder // TODO: nach Release X überprüfen im Code sind zu einem unschätzbaren Projektgedächtnis geworden. Für ein Projekt, das monatelang mit häufigen Pausen aktiv ist, bin ich ohne diese Spuren nicht in der Lage, mich zu erinnern, warum ich eine spezifische Entscheidung getroffen habe.

Mit echten Nutzern testen, bevor man wirklich bereit ist. Die offene TestFlight-Beta, die ich Mitte des Projekts gestartet habe, hat Bugs gefangen und Feedback gegeben, das ich in meinen eigenen Tests nie gefunden hätte. Beta-Nutzer nutzen die App anders als ich, und diese Unterschiede sind, wo die Bugs sind.

Was übrig bleibt

In diesem Moment habe ich einige hundert HelioPeak-Nutzer, mit guten Bewertungen im App Store, einer aktiven Community auf Tweakers, und einer ausreichend langen Backlog-Liste von Funktionen, die ich bauen möchte. Die Einnahmen reichen noch nicht aus, um daraus eine Vollzeitarbeit zu machen (ich hoffe, dass es irgendwann möglich ist), aber sie sorgen dafür, dass das Projekt sich selbst finanziert und schrittweise wächst.

Was ich vor allem aus diesem Projekt mitnehme:

Mit etwas anfangen, dessen Notwendigkeit Sie selbst spüren. Die Energie und Motivation, sich monatelang zu halten, kommen nur, wenn das Problem wirklich Ihres ist.

Mit realistischen Zeitschätzungen rechnen. Die Sache dauert immer zwei- bis dreimal so lange, wie ich dachte, dass sie dauern würde. Es ist kein Pessimismus, es ist Realismus.

Den Iterationszyklus kurz halten und sich nicht zu sehr um die Perfektion in Version 1 sorgen. Eine unvollkommene Version 1, die auf dem Markt ist, justiert sich über Feedback. Eine perfekte Version, die nie auf den Markt kommt, lernt nichts.

Mit Datenschutz und Qualität im Kopf von Anfang an bauen. Es ist einfacher, es beim ersten Mal richtig zu machen, als später nachzurüsten. Und das Vertrauen der Nutzer, einmal gewonnen, ist nach einer schlechten Entscheidung schwer wiederzuerlangen.

Und keine Angst haben, ehrlich darüber zu sein, was Ihre App nicht tut. Jede App hat Grenzen, und Nutzer respektieren einen Entwickler, der über seine Grenzen klar ist, mehr als einen, der etwas vorgibt, was er nicht ist.

Zum Abschluss

HelioPeak ist keine Erfolgsgeschichte im finanziellen Sinne (noch nicht), aber sehr wohl im persönlichen Sinne: Ich habe etwas gebaut, das ich wollte, ich habe es in sechs Sprachen, auf drei Plattformen, pünktlich veröffentlicht, und es wird von echten Menschen geschätzt. Ob es sich in den nächsten Jahren auch finanziell lohnt, hängt von Dingen außerhalb meiner Kontrolle ab (die Solar-Wirtschaft geht weiter, die Nutzer kommen weiterhin über Mundpropaganda). Aber das Ergebnis des Lernens und der Handwerkszufriedenheit existiert bereits, und niemand wird es mir wegnehmen.

Für Leser, die überlegen, selbst etwas Ähnliches zu bauen, mein letzter Rat ist einfach: Fangen Sie an. Die Distanz zwischen "ich habe eine Idee" und "ich habe eine erste Version" ist viel länger, als Sie denken, aber die Distanz zwischen "ich habe eine erste Version" und "ich habe etwas, dem Menschen vertrauen" ist beherrschbar, wenn die erste Distanz bereits zurückgelegt ist. Der schwierigste Teil ist anzufangen. Alles andere ist eine Frage des Erscheinens jeden Abend mit genug Energie, um nur eine Sache mehr zu tun.

Das, wahrscheinlich, ist die größte versteckte Lektion der unabhängigen Entwicklung: Bauen an sich lohnt sich bereits, unabhängig davon, wo es am Ende landet.