Es ist vollbracht...

Ein weiterer Punkt, den ich im Rahmen des Flutter-Projekts ESP32-Cam austesten wollte, war das Deployen der App, neben den klassischen Stores von Apple und Google, in weitere App Stores wie: Amazon Store (Android Version), Microsoft Windows Store und für Linux in snapcraft.io, dem App Store für snap basierte Pakete.

Da Flutter neben iOS und Android auch Desktop-Betriebssysteme wie MacOS, Windows und Linux unterstützt, ist dies machbar. Folgende Belange sind aber zu bedenken:

Spezifische Funktionen, wie z.B. eine einheitliche Bezahlfunktion über alle Stores hinweg ist eine Herausforderung. Die ESP32-Cam App hat eine Bezahlfunktion für Apple und Google implementiert, die eine Spende für das Projekt ermöglicht. Dieser freiwillige Obulus ist aber mit keiner Funktionalität der App verknüpft. Für die restlichen Varianten habe ich den Spenden-Dienst Buy Me a Coffee eingebunden.

Bei Zahlungsdiensten ist überhaupt Vorsicht an den Tag zu legen, da dies ein Punkt ist. der bei einer App-Review leicht Ärger machen kann. Für Apple und Google sind nur direkte oder indirekte Zahlungen über das jeweilige hauseigene Zahlungssystem möglich. Mit indirekten Zahlungen sind Flutter-Plugins á flutter-stripe gemeint, die zwar eine einheitliche Zahlung für iOS und Android anbieten, dies aber einhergehend mit dem Wermutstropfen, Geld an Apple/Google UND Stripe anteilsmäßig abführen zu dürfen.

Abhängig von der App, respektive der Anzahl der verwendeten Plugins kann die Unterstützung über die verschiedenen Betriebssysteme hinweg einiges an Mehrarbeit nach sich ziehen, da Plugins in den wenigsten Fällen für alle Plattformen zur Verfügung stehen.

Im Fall der ESP32-Cam App war dies nur die Methode, die den Pfad der Bilder für das jeweilige OS ermittelt, um dort auf Knopfdruck Bilder der Kamera speichern zu können. Für die mobilen OS-Varianten kam das Plugin image_gallery_saver_plus zum Einsatz, für die Desktop Varianten war dann OS-spezifischer Code von Nöten. z.B die Windows-Variante

String getWindowsPicturesPath() {
  final pathPtr = calloc>();
  // KnownFolderId for Pictures
  final result = SHGetKnownFolderPath(
    GUIDFromString(FOLDERID_Pictures),
    0,
    NULL,
    pathPtr,
  );

  if (result == S_OK) {
    final path = pathPtr.value.toDartString();
    calloc.free(pathPtr);
    return path;
  } else {
    calloc.free(pathPtr);
    return "";
  }
}

Und wenn man legis artis programmiert, dann sollte man diese OS-Spezifika alle derart trennen, sodass z.B. beim Android-Build der Windows-Code nicht eingebunden wird. Da Dart/Flutter keine Makros kennt, á C, ist die Trennung etwas eine Spielerei.

Zurück zu den Erfahrungen mit dem Deployment der App in die einzelnen Stores:

Apple: Das Apple-Review-Team hatte zwei Punkte moniert. Da sie diese Art von App nicht direkt testen können, wollten sie ein Video von der App samt Kamera in Aktion. Beim zweiten Punkt hatte ich einen Schreck bekommen. Die App wurde aus Copyright-Gründen aus dem Store entfernt - meine App könnte ja Rechte von Espressif verletzten. Diese mögliche Tatsache wird einem juristisch ausformuliert um die Ohren gehauen.

Als Entgegnung wurde eine Architektur-Beschreibung der App abgeliefert, dass diese nur auf einen Webserver, der auf der ESP32-Cam läuft, zugreift, und somit keine Rechte jeglicher Art verletzt werden sollten. Dem Einspruch wurde stattgegeben und per Button in der Apple-Store Oberfläche konnte ich die App wieder in den Store einbringen.

Dies war eine harte Lernkurve, aber nun ist es klar, wie man bei Apple diese Art von Hardware-App einbringen sollte.

Google Play: Keine Besonderheiten, außer dass das Durchwinken der App über eine Woche gedauert hat.

Windows Store: Keine wirklichen Probleme, der Store ist etwas bürokratisch gestaltet - was da alles an Forms ausgefüllt werden will. Wenn man dies noch nie getan hat, dann sind einige Iterationsschleifen vonnöten, bis dem Store alles passt.

snapcarft.io: Der Store an sich war keine Herausforderung - eher die fummelige snapcraft-Umgebung, die zum Bauen eines snap Pakets von Nöten ist. Das hat mich doch einiges an Zeit gekostet.

Und bei jeder Herausforderung gibt es einen finalen Endgegner, und den hätte ich so nicht erwartet, der Amazon Store:

Aus den Erfahrungen mit dem Apple Store habe ich wohlweislich Video und Architekturbeschreibung mitgeschickt. Diese Info hat aber scheinbar keiner gelesen. Die App wurde im Store-System mit einem legal issue markiert - Rechte am generischen Begriff ESP32. Also etwas frustriert einen Support-Case eröffnet und nochmals alle Informationen eingebracht und betont, dass diese App in den anderen Stores zur Verfügung steht.

Fast zwei Wochen ist nichts passiert - case is pending. Dann habe ich den KI-Chat-Bot von Amazon gefragt. Dieser hat gemeint, er verstehe meine Frustration - aber vielleicht verletzte ich Richtlinien von Amazon, die für Apple und Google kein Problem seinen. Amazon und Copyright, und päpstlicher als der Papst - selten so gelacht.

Die KI hat aber einen guten Tipp gegeben - ich sollte mich an das Amazon-Entwickler- Forum mit meinem Problem wenden. Getan, aber meine Problembeschreibung war dann schon ehrlicherweise ein rant. So ein Beitrag im Forum muss aber von einem Moderator freigschaltet werden. Nur diese Freischaltung war dann für die nächsten Tage im Status pending.

Meine emotionale Ausgeglichenheit, was den Amazon-Store betrifft, ist auf nicht jugendfreies Niveau an Invektiven gerutscht. Aber das Posting hat intern was ausgelöst - nach 4 Tagen ist dann die App mit einer Entschuldigung ob der Verzögerung freigeschaltet worden.

Was noch fehlt? Zwei Punkte:

App-Store Screenshots sollten grafisch aufbereitet werden, nicht nur der reine Screenshot - und diese Spielchen für alle Stores in den der vom Store geforderten Auflösung.

Eine Flutter App ist in der Desktop-Umgebung, was das Fenster betrifft, in der die App läuft, doch etwas ein Fremdkörper.

Um diese Manko zu beseitigen gibt es Flutter-Plugin wie bitsdojo_window, das die Anpassung des Windows ermöglicht.