Gian, Nico, was macht ihr im Juni?
Heißt er nach Kalifornien, würde ich sagen.
WDC angucken, würde ich sagen.
Vor Ort?
Warum so ein Geiste?
Ja, da muss man glaube ich dort leben.
Es ist nicht wirklich für alle eine Veranstaltung.
Da reden wir gleich drüber und noch über ein paar andere Themen
beim App Store Tagebuch.
Ja, WDC ist mal wieder, ne?
Ja, das Developer Christmas gleich immer.
Ich hab gehört, die machen ja die letzten Jahre wegen Corona
immer alles nur als aufgezeichnete Videos gemacht.
Aber meine Frage führt tatsächlich daher, dass
es offensichtlich ein paar Leute gibt,
die sich das auch dort vor Ort angucken können.
Es gibt noch keine genauen Details, aber es wird wohl so ein
Screening der vorgezeichneten Videos geben.
Aber ob das so sinnvoll ist, weiß ich auch nicht.
Interessant hab ich irgendwie gar nicht mitbekommen.
Also ich hab zwar schon die Ankündigungen mitbekommen,
aber nicht mitbekommen, dass so was stattfindet.
Erinnert mich tatsächlich ein bisschen an die Google Veranstaltungen.
Ich weiß nicht, ob ihr die Google I/O auch mitverfolgt,
die ja meistens im Mai ist.
Und da ist es, meistens so, es gibt diese,
also Google macht das ein bisschen anders alles.
Also die Developer Struktur ist da aufgeteilt
in Google Developer Groups.
Gibt auch hier einen Karlsruher Meinunggebung,
gibt in Deutschland auch viele.
Und die machen Hauptveranstaltungen und gucken dann zusammen die Google I/O.
Und das erinnert mich jetzt ein bisschen an.
Hab ich auch gerne gemacht.
Also bei uns war das auch immer wieder.
Wir haben auch immer bei uns, also in der Firma, wo ich gearbeitet hab,
auch so eine GGG heißt die, glaub ich, auch irgendwie München, Google,
Die Waller Pass und so weiter.
Und dann gibt's halt auch immer Pizza und Bier und guckt sich das an.
Und gerade so die Keynotes, selbst die App-Idee, die man haben sich bei Android immer angeguckt.
Und umgekehrt natürlich muss man auch kurz mal wissen, was in der Unterwelt abgeht.
Oder in der Hölle abgeht.
Nein, natürlich Spaß.
Wir sehen da sehr ähnlich aus und haben so was immer gemacht.
Du, Nico, ich weiß jetzt glaube ich gar nicht.
Aber Nico, du warst ja mal vor Ort bei der WBC.
Ich war zwei Mal sogar da.
Ich war auch zwei Mal in Kalifornien für die WBC.
Und es ist ja schon ein Unterschied, wenn man vor Ort da ist,
als wenn man wie früher nur die Videos bekommen hat.
Aber heutzutage, wo ja auch diese ganzen Sessions alle online sind,
da ist ja gar nicht so ein großer Unterschied, ob man jetzt vor Ort da im Apple Park die Videos guckt
oder zu Hause die Videos guckt.
Definitiv.
Die Videos hast du recht.
Aber tatsächlich gibt es so einen Tipp unter Leuten, die bei der WBC sind,
dass man, wenn man in der Woche dort ist, die Sessions nicht besuchen soll.
Das ist der Hintergrund, dass man dort ist, man connecten soll, man soll mit anderen Entwicklern sich kennenlernen, sich austauschen. Und das ist so der Hauptvorteil, wenn man tatsächlich vor Ort ist.
Und das ist ja gerade das Lustige, dass dann eben im Phonebook, hey, geh gar nicht zu den Sessions,
obwohl du eigentlich nicht für die Sessions hingehst.
Das heißt, man merkt schon, das ist eigentlich eine reine Connection-Veranstaltung.
Und das fällt halt weg.
Und nicht nur das, sondern was halt, sag ich mal, fast das Wertvollste ist,
eigentlich du kommst halt direkt mit Apple-Engineers in Kontakt.
Richtig.
Und wenn du Probleme hast, von denen du wirklich nicht mehr weiter weißt oder irgendwo einen Bug gefunden hast,
denen zwar irgendwo ein Feedback-System drin ist, bei denen aber halt auch so viele Bugreports bekommst,
dass die da auch schwer mit sich priorisieren tun, dass du denen die Leute da auch irgendwie draufhin, sag ich mal, stupst.
Und dann hast du halt auch gleich einen Apple-Engineer dran und der guckt sich das Problem an.
Also was du auf jeden Fall machen solltest, ist dir ein Demo-Projekt vorbereiten mit wirklich genau dem isoliert, dein Problem, was du hast, und denen halt zeigen.
Und dir Feedback holen und dann kommt halt auch auf das raus, ja, sieht nach einem Bug aus, gib mir mal die Feedback-Nummer, ich schreib's mir auf und so weiter.
Und dann kümmern die sich auch darum.
Also das ist dann, ja.
Die buggen das halt live, die haben ja das System direkt draußen, kann das direkt ausführen.
Genau.
Also die Dabub-VC besteht im Grunde aus drei Teilen.
Die ersten zwei Sessions, die man halt jetzt auch online gucken kann, dann diese Labs, die Nico gerade erwähnt hat, wo man wirklich gute Hilfe bekommt, und die gibt es eben, die Abendveranstaltung.
Ja, diese Labs, die gibt es ja auch remote, also dass du dich dann so ein playback commentieren kannst, glaub ich.
Teils, ja.
Teils, also ich weiß gar nicht, gab's die vorher, also ich weiß natürlich jetzt, in letztes Jahr.
So, ja, nicht.
Die 2 ist jetzt auch wieder Corona, seit Corona.
Und die Frage ist, wird es diese Remote-Labs auch in Zukunft wieder in Person veranstaltet?
Das kann ich mir gut vorstellen.
Also es ist ja tatsächlich in der Community durchaus positiv aufgefasst worden, dass erstens die Videos jetzt kürzer geworden sind.
Und jetzt ist halt nicht mehr so, die Videos sind wirklich auf den Punkt, und das zweite ist eben jetzt die Labs auch tatsächlich remote, zumindest teilweise über Slack eben verfügbar.
Ich denke, dass sie das Beides durchaus beibringen könnten.
Ja, und das hat ja natürlich auch die Vorteile, also einmal, dass man nicht mehr durch die Gegend fliegen muss, und das ist natürlich gut für die Umwelt.
Und zum zweiten, dass ja auch Leute, die sich das aus welchen Gründen auch immer nicht leisten können, nach Kalifornien zu fliegen, das geht wahrscheinlich sogar noch, aber dann da ein Hotel in der Nähe von den Veranstaltungsorten zu bekommen, die in alle überteuert sind, für die ist das natürlich eine sehr große Hürde.
Also für mich würde sich das nie lohnen, dahin zu fahren, weil ich einfach nicht genug Geld mehr in mein Leben mache.
Und wenn ich mal so ein Problem habe, eine Session-Buchung für die 100 Euro, die ich im Jahr dafür bezahle, dann wäre das schon gar nicht ganz cool. Also man kann so ausgehen, einmal WBC mit allem drum und dran bis zu ungefähr 5000 Euro. Das Ticket selbst hat ja 1500 Dollar gekostet. Das ist jetzt auch ja im Grunde kostenlos. Du kannst jetzt ohne ein Ticket kaufen, du musst auch an den Labs teilnehmen. Ja.
Was erwartet ihr denn?
Erwartungen habe ich nicht so viele, das ist immer glaube ich ganz gut, weil dann wird man eher überrascht als enttäuscht.
Ich würde mir persönlich mal wieder was in Richtung NFC wünschen, weil ich glaube das Thema auch bei Apple sehr in den letzten zwei Jahren nicht viel zurück, quasi kann man sagen.
Das ist ja auch in den letzten paar Jahren, wo du auch die Schnitzel zugegeben hast.
Nee, da ist wenig dazugekommen und es ist zwar noch ein bisschen was dazugekommen, aber die Frage ist auch, wie weit, oder man könnte da wahrscheinlich neue LP-Eis bauen und vielleicht auch ein bisschen das noch nutzerfreundlicher gestalten. Aber das wäre so persönlich, was ich mir wünschen würde.
Und ansonsten, ja, wir werden wahrscheinlich viel AR-Kram wieder sehen, so wie jedes Jahr. Mal gucken, was sie dieses Jahr an neuer Technologie in die Richtung rausbringen.
An sich auch immer spannend, wenn wir dann wirklich mal AR-Glasses kriegen. Aber die Rumors sagen ja schon wieder, frühestens 20, was? 24 oder so?
Also die VR-Brille soll ja ein bisschen früher kommen, aber ich bin da jetzt auch aktuell nicht mehr hinterher. Aber ich denke, was man auf jeden Fall sagen kann, was sich ja alle Entwicklerinnen wünschen, ist ja ein stabiles Xcode. Da gibt es ja einige Bugs, dann auch inzwischen tatsächlich stabiles Zwift, also auch Zwift selbst hat schon einige Bugs, die ja nicht so optimal sind. Dann Zwift UI natürlich, da wünscht sich jeder Entwickler, dass einfach mehr reinkommt, mehr Stabilität reinkommt, aber auch mehr Features. Es gibt ja voll viele APIs noch, die kannst du gar nicht ansteuern, wenn du nicht in den UI-Kit oder App-Kit reinläufst. Und so wie bei Previews, speziell damit hatte ich lange Probleme, also dass die nicht immer funktionieren. Ich denke, das sind so die Sachen, wo sich einfach alle wünschen, dass es sich alles einfach verbessert.
Und ich sehe auch hier in unseren Show notes natürlich da so lauter so Sachen, die man sich schon seit Jahren wünschen würde, wie dass man App-Icons einfach ein Bild rein droppt und dann Xcode das einfach selber macht. Und nicht, dass man sich um sowas kümmern muss. Also da gibt es immer so viele Dinge, die man optimieren noch könnte und die Xcode einfach von Bordmitteln auslösen könnte, die natürlich die coole Community mit vielen coolen Tools gelöst hat. Aber am besten ist halt immer noch die On-Bord-Lösung, wenn sie da ist, weil man kann auch nicht jedes Framework oder Tool verfolgen. Man kennt manchmal auch die Tools gar nicht, die da sind, weil da so viel da draußen ist.
oder es gibt einfach Leute, die neu anfangen und die müssen sich damit erstmal befassen, und das ist nicht einfach ein Expo drin.
Also wir hatten es auch vorhin schon ein bisschen mit Google, ich gucke auch gerne die Google I/O, ich entwickle auch gerne in Coplin ein bisschen, dann hab ich versucht ein bisschen Android Entwicklung zu machen.
Und ich finde es auch schön spannend, auch deswegen jeweils die andere Keynote zu verfolgen, weil man dort ein bisschen die Zukunft von der eigenen Plattform sehen kann.
Weil die kopieren sich ja alle gegenseitig. Also wenn Apple jetzt etwas rausbringt mit, keine Ahnung, mit Notification-Updates, dann sind die meist abgeguckt von Android,
und andersrum, wenn du zum Beispiel die Health-Features, du kannst checken, wie viele Stunden du mit deinem iPhone verbringst, das haben die sich auch gegenseitig abkopiert.
Das heißt, wenn du es beim einen siehst, kannst du erwarten, entweder du kommst dieses Jahr oder nächstes Jahr bei uns auch. - War ja auch mit SwiftUI, so SwiftUI ist rausgekommen, und dann, ich glaube, Google war kurz danach mit Jetpack Compose oder so, und dann ähnliches Konzept. Ich habe auch schon aus der Google-Ecke gehört, dass die das alle lieben und natürlich viel arbeitsschmart und cool ist.
Ja, aber da hast du auf jeden Fall recht, dass man sieht da... - Im Sinne wünsche ich mir auch, dass sie was von Android Studio kopieren.
Das Android Studio kann zum Beispiel diese Icon Imports. Android Studio hat auch Safe Resources, das heißt, du kannst, wenn du von deinem String so ein Bild referenzierst in deinem Code, dann erkennt Android Studio, wenn das Bild nicht mehr existiert oder unbenannt wurde, und warnt dich, das ist bei uns immer noch nicht der Fall.
Die Android Entwickler, wo ich gearbeitet habe, haben eh mal über Xcode gelacht, und ich kenne auch das Android Studio Funktion, das die lange noch nicht... - Xcode hat eine viel schönere UI. - Ja, das geht direkt, aber das ist auch alles.
Und auch beim Debugging ist es auch einiges besser. Also zum Beispiel unser Vue Hierarchy Debugging, wo du einfach nur diesen einen Knopf da unten klickst und dann hier was hier sehen kannst, ist einfach ein Traum. Und das raubt jetzt auch in Android Studio nach, aber soweit ich höre, ist es auch nicht so praktisch.
Muss ich aber auch sagen, ich muss sagen, seit SwiftUI habe ich das deutlich weniger benutzt, also in UI Kit hat man das häufiger benutzt. - Bestimmt.
Basiert Android Studio noch auf Eclipse? - Nee, nee, JapBrainz. Die haben mit JapBrainz in Kooperation auch, und JapBrainz entwickelt ja auch Kotlin. Also das ist ja eine Programmi-Sprache, die von JapBrainz entwickelt wird. Und JapBrainz ist auch sehr beliebt gewesen schon lange bei Entwicklern, also was das alles an Refactoring Funktionen zum Beispiel hat, ist echt richtig gut. - Was wir auch noch nicht... - Also damals mit Eclipse habe ich tatsächlich gestartet, mein erstes App-Projekt war ein Android-Projekt, weil ich musste das im Namen der Universität, da musste ich eine App entwickeln, und ich habe wirklich einfach Augenkrebs gekriegt bei dieser UI. Eclipse hat ja so... also ich fand die Eigens nicht schön formuliert, und mir hat es nicht gefallen. Aber JapBrainz ist deutlich besser.
Das gebe ich euch in Ver-recht, also UI-mäßig ist es auf der Apple-Seite immer ein bisschen schöner. Was wir hoffentlich dann auch sehen werden auf der WWDC, ist eine ganz neue Auslegung des App-Stores und hoffentlich auch der Bezahlstruktur, die da kommt, weil viele Antitrust-Verfahren da laufen und auch in verschiedenen Ländern mittlerweile dazu gezwungen wird. - Glaubst du, dass das kommt? - Naja, andere Payment-Systeme, also ich denke man schon, dass da in die Richtung vielleicht irgendwas kommt, weil ich glaube auch, Apple kriegt es trotzdem nicht weg, und lieber machen sie es jetzt selber anstatt, dass sie mit irgendwelchen komischen Gesetzen dazu gezwungen werden, die am Ende vielleicht nur schlimmer für sie sind. Man hat ja auch schon angefangen jetzt mit Small-Business-Programm und so weiter.
Sie haben jetzt auch in Holland gezwungen, haben eine halbgeile Lösung, die eigentlich totale Grütze ist und super unfair. Und da wurden sie auch nochmal gerügt und so. So geht das nicht. Ich hoffe, dass sie da was bringen. Meint ihr wirklich, dass sie es weiter aussetzen werden?
Nee, ich glaube auch, dass sie da versuchen proaktiv den ganzen bisschen Wind aus den Segeln zu nehmen. Wir sind noch sehr viel Wind drin in den Segeln, aber ich glaube, dass sie da proaktiv aus den Segeln gehen sollten.
Also ich hoffe, dass sie es tun, weil so doof kann es auch nicht sein, dass sie sich dann irgendwann dazu zwingen lassen.
Ich kann mir vorstellen, dass sie etwas machen, so was zum Beispiel das Small-Business-Programm haben sie ja gemacht, oder was sie in Holland gemacht haben. Ich kann mir vorstellen, dass sie etwas ändern. Ich bin mir aber nicht sicher, ob sie wirklich externe Payment-Systeme zulassen. Ich fange mir das mal an, dass ich denke, sie werden es so einführen, was auch immer sie dann machen, dass es trotzdem für die meisten sich lohnt, es einfach auf dem App-Store zu belassen. Ich schätze Apple so ein, dass sie versuchen werden, möglichst beim App-Store zu bleiben. Weil die haben immer wieder betont, dass sie das wollen, dass sie das auch für die Sicherheit der Nutzer machen wollen. Ich glaube, die bleiben bei diesem Argument und werden versuchen, das möglichst zu tun.
Dann müssen sie aber auch die Sicherheit der Nutzer durchsetzen, weil das passiert ja auch gerade nicht. Obwohl Apple sagt, das hier ist unser kuratierter Store, der ist sicher, da haben alle super geguckt, gibt es eine ganze Menge Scam-Apps. Und ich spreche jetzt nicht nur von diesen Apps, die sagen, mal App für 100 Euro eine Woche, sondern auch andere Sachen. Da läuft auch gerade eine Klage gegen Apple von dem Entwickler von FlickType. Ich glaube, der hat das erste Keyboard für Apple Watch gemacht.
Dieser Costa, irgendwas heißt der Costa, weiß ich nicht. Der ist auf Kriegsfuß mit Apple da. Das ist ganz witzig, den man aus seinem Twitter rausführt.
Der ist nicht der einzige, auch Großunternehmen wie Spotify. Ich sage nicht. Da kann man jetzt auch letztens die Mac-Apps, die richtig viel Geld machen und die dir kostenlos angeboten werden, dann kommst du in die App rein, wirst mit dem Kaufscreen präsentiert und diese App hat dann den Quit-Button. Du kannst nicht die App schließen, du kannst sie nur noch force-quitten, über den Apfel oben und dann sofort betonen. Aber du kannst den Command-Q nicht mehr und du kannst nicht oben den roten Krass-Quiet-Button. Das ist natürlich nur ein Versehen. Aber das ist so was halt einfach, die sind halt in den Top-Grossing-Apps. Also das musst du dir mal vorstellen, dass da Apple verdient halt dabei schön mit und lässt es halt einfach zu. Aber wie kommt denn sowas durch das App Store? Das fragt man sich auch. Wie kann das sein? Sie testen wohl das Quitten nicht.
Also, oder man hat ja, dass es Absicht ist, dass der Reviewer sagt, ja okay.
Nee, ich glaube nicht, dass es ein Reviewer ist. Es gab auf jeden Fall vor ein paar Jahren ein paar Möglichkeiten zu erkennen, ob diese App jetzt gerade im Review ist oder ob das ein Mensch ist, der sie benutzt, weil er sie gerne benutzen möchte oder sich runtergeladen hat. Und je nachdem würde dann andere die Eier angezeigt werden. Und dann könnte das sein, wenn es im Review ist, dann ist sie schließbar und wenn nicht, dann nicht.
Aber auch dann kann ja Apple im Grunde nicht verhindern, dass es zumindest erstmal in den Store so kommt.
Hab ich aber auch schon bei mir gesehen, dass mein App Store Reviewer meine App-Screenshot zurückgeschickt hat und bei mir ist natürlich Werbung aktiv und da sehe ich auch einmal japanische Werbung. Die machen sich teilweise, dass sie dann GPS faken, sodass dann nicht mehr Copacino bei denen in der Location steht oder San Jose wo die teilweise sitzen. Das ist auf jeden Fall sowas, wo wir dagegen vorgehen. Aber ich kann mir auch vorstellen, dass die halt einfach den Good Case ausprobieren. Die probieren das Payment aus, funktioniert, cool, am Ende des ganzen Testings, was sie da machen, app schließend passt. Aber die haben nie ausprobiert, Payment-Screen und dann kommand cool drücken.
Das ist ja auch plötzlich kein QA Review, die machen ja nicht deine Quality Assurance und testen für dich alles, sondern die prüfen halt, ob das nach den Richtlinien geht oder nicht. Und die haben wohl in den Richtlinien noch nicht stehen, die App darf nicht kreativ sein.
Ja, aber ich finde, das ist jetzt ein Beispiel, aber ich finde, wenn sie sagen, wir machen nur hier die App Stürze nicht ab oder sowas testen, dann dürfen sie nicht sagen, bei uns ist alles so sicher und wir haben so einen tollen, korrektierten Store.
Du wirst es auch nie davon, also 100% das alles schöne Blumenwiesel, wirst du nie hinbekommen. Du wirst immer schwarze Schafe haben und du wirst immer...
Ich wollte davor nicht sagen, dass ich denke, dass sie jetzt alles, dass sie sich halt da ist, sondern ich sage nur, dass es ihr Argument ist. Und sie kann das Argument halt juristisch, sage ich mal, gut nutzen. Ich glaube nicht, dass das auf Stand hält juristisch. Aber ich weiß, ich bin kein Jurist.
Ich bin da offen für mehr, also ich bin immer für Flexibilität, ich bin immer dafür, dass Apple einfach mehr anbietet, dass man sich auch dafür entscheiden kann, hey, ich möchte mein eigenes Bezahlsystem machen. Also ich würde mich freuen. Ich bezweifle nur, dass sie es machen, einfach wegen der Vergangenheit, wie es bisher gelaufen ist. Aber ich lasse mich überraschen.
Die werden das anderen Anbietern schon so schwer wie möglich machen, das ist mir auch klar.
Der Witz dabei ist ja auch, sag ich mal, die 15% oder 30% die wir abgeben, die zahlen wir ja eigentlich auch dafür, dass wir die ganzen Developer Tools und so weiter, alles was da draußen ist und die Engineers, die das machen, bezahlen wir ja damit. Ich meine, wir müssen viel gut zahlen.
Ja, aber ich meine, von denen ist es glaube ich nicht gedeckt.
Ich bin als Indie-Intiker absolut happy, dass Apple das Ganze anbietet und mich stört der Cut, den die da bekommen, überhaupt nicht. Ich glaube der Punkt ist, dass es halt Unternehmen gibt, die könnten ein eigenes Bezahlsystem aufsetzen, weil die so groß sind und die wollen einfach nur diese Flexibilität zu sagen, okay, wir könnten das Apple-System nutzen, aber wir wollen es nicht, wollen unser eigenes, also wollen wir da nicht diesen hohen Cut abgeben. Und das Argument kann ich auch verstehen.
Wenn aber jetzt Kanna und Stripe oder Paypal ankommt und sagt, hier, pack dieses Framework ein und du kannst über uns App Store-Käufe machen, In-App-Käufe machen und bei uns drückst du nur 5% ab, dann würdest du vielleicht überlegen, oder?
Ja, Beispiel, genau das könnt ihr mir vorstellen, dass Apple sagt, okay, ihr dürft euer eigenes Bezahlsystem, aber nur wenn es auch wirklich euer eigenes ist, zum Beispiel. So was in der Art könnt ihr mir von Apple tatsächlich vorstellen.
Aber ich muss auch sagen, da sieht man ja auch schon wieder, dass einfach Konkurrenz belebt den Markt und am Schluss fallen die Preise halt auch einfach. Das ist ja eigentlich auch das Schöne dabei.
Ich meine, Apple kann ja immer noch irgendwie, dann sollen sie ja einen Service-Fee verlangen. Die kann ja dann wirklich, ich meine, so machen sie es ja gerade, dass sie dann irgendwie 27% Service-Fee verlangen und dann die 3% kann sich dann, also im Prinzip ist halt für den jeweiligen nichts gewonnen. Ist halt dann schon ein ziemlich dickes Move, sag ich mal. Aber kann man ja irgendwie machen und man sieht halt einfach, Konkurrenz belebt das Geschäft und wenn Paypal da ist und wir 5% anbieten, dann würde ich auch überlegen, so, hm, also klar, wenn du da irgendwie nur ein paar 100 Euro überliegst, dann läuft das.
Ja, Paypal auch eine Service-Fee vorbei. Vielleicht beschickt ihr Paypal auch eine Service-Fee vorbei.
Natürlich sollen sie ja machen. Ich glaube, das ging in eine andere Richtung, aber, nee, sollen sie ja ruhig machen. Irgendwo müsste ja was bezahlen, aber der Konkurrenz belebt das Geschäft und das ist ja auch gut so. Wir werden es Mitte Juni sehen, ob sich da was tut oder nicht. Ja, zum Thema sehen, was man jetzt schon sieht, ich habe ja auch schon mal über Easter Eggs erzählt. Es gibt wirklich ein Easter Egg von Apple, was im System drin ist. Es gab mal einen Hund namens Clarus, ich weiß nicht, die Hundkuh. Kennt ihr den? Nee, also ich habe das nicht. Auf jeden Fall ist es ein hidden Easter Egg im iPhone-Keyboard, wenn man Clarus eingibt, also C-L-A-R-U-S, kriegt man einen Hund und eine Kuh als Emoji vorgeschlagen. Obwohl das das eigentlich gar nicht als Emoji gibt?
Doch, doch, das wird es einmal raus und man bekommt einen Hund und eine Kuh als Emoji vorgeschlagen. Und es gibt zwar Leute, die sagen, das ist die Reihenfolge falsch herum, aber ich finde es aber lustig, dass Apple auch so im System irgendwas drin ist, dass es irgendwo ein Fond rauskommt.
Der Beispiel des Projekten von QuickTime und DocumentPrivium, bei Mac OS 9 oder 8 oder noch älter.
Wenn das ein bekannter Hund ist, also ich nehme an, ich schreibe da Hachiko rein, ich weiß nicht, ob ihr den kennt, das ist ein berühmter japanischer Hund, dann würde ich auch erwarten, dass ein Hund Emoji kommt.
Nee, aber das ist auf jeden Fall ein E-Stack, was sich irgendein Apple-Ingenieur ausgedacht hat und wahrscheinlich auch das System einfach reingeschmuggelt hat.
Einfach ein Alias für Emojis.
Ja, aber einfach auch witzig zu sehen, dass sowas auch da ist.
Da arbeitet auch noch ein Entwickler wie wir, ne?
Richtig, klar, das ist eigentlich schön reingeschmuggelt, das checkt man im ersten Moment gar nicht, wenn man irgendwie Ahnung vom Apple-System hat und schon lange dabei ist, dann erkennt man es vielleicht wieder.
Ok, auch da habe ich die Erwartungen, also mal ein bisschen mehr auf Framework-Level, also weniger auf was für Produkte wir erwarten oder so, sondern mehr aus Entwicklersicht.
Ich persönlich hoffe schon seit Jahren darauf, dass ein Ersatz für Corelita kommt, dass ein Nachfolger von Corelita kommt, der einfach mehr Swiftie ist, der auch mit Swiftie UI vielleicht perfekt zusammenspielt und nicht mehr diese ganzen, also du musst da so ein Corelita-Modell erstellen, dann hast du ganz viel generierten Code und hast überall Optionals, alles sind Optionals, keine Start-Modellisierung und so weiter.
Und du musst auch, wenn du irgendwie die Daten referenzieren willst, dann musst du nochmal Safe-Object, Safe-Context, Kontext und so weiter, alles ein bisschen kompliziert.
Ich wünsche mir einfach Nachfolger.
Richtig, sorry, da habe ich jetzt auch gerade das Übersprung, das haben wir vergessen zu sagen.
Nee, das ist auch etwas, was ich glaube ich alle wünschen in der Entwicklerwelt, da mal was Neues zu bekommen.
Genau, das und noch ein paar mehr Sachen, ich habe mir das ein bisschen detailliert überlegt, was ich mir wünsche und habe tatsächlich eine Artikel darüber geschrieben, also falls das jemand interessiert auf meinem Blog, dhub.medium.com findet man einen Top 3 Wishlist Webdc und da ist unter anderem, wie ich mir das ungefähr vorstelle, wie so ein Persistence-Framework aussehen könnte im Code, habe ich nicht so viele Gedanken mir gemacht, also ich habe nicht geguckt, ob das auch tatsächlich kompilieren würde, aber so ungefähr denke ich, hier könnte man sich vorstellen, zum Beispiel mit einem Add-Persistence-Ui, so wie man AppStore-Chat für User-Defaults, Add-Persistence und das wird automatisch in Corelita gespeichert.
Verlinken wir den Artikel.
Ich glaube mit Corelita haben wir uns alles schon umgekriegt, komm, geh ärger.
Ja gut, du brauchst aber auch immer wieder die Backwards Compatibility.
Also ich stelle es mir so vor wie das SwiftUI, das baut auf Corelita auf und bietet dir quasi erstmal nicht so viel Funktion wie Corelita, aber das einfache, was du in der Regel brauchst, ist schonmal möglich und in der ersten Version ist es auch sehr einfach, so wie das SwiftUI auch.
Meinst du nicht, aber dann stört das vielleicht ganz nett mal auszuprobieren, aber dann stößt man schon wieder sehr schnell an seine Grenzen, sobald du dann irgendwie...
Ist ja nicht schlimm, solange sie miteinander kooperieren können. Du kannst dann zum Beispiel sagen, ok ich habe hier ein komplexes Model, da habe ich noch extra Corelita-Code, aber dasselbe Model funktioniert auch in SwiftUI, also wie man den SwiftUI die AppDelegate benutzen kann oder die SceneDelegate und so.
Genau so, dass es halt komplizierter wird, sobald man etwas macht, was ihm nicht geht, aber das was geht, das ist auch einfach. Gerade für Einsteiger ist das glaube ich dann ein riesen Wegfall einer Hürde.
Schön wäre es auch, wenn du statt einem Corelita-Modell anlegen und das Ganze dann überall referenzieren, wenn du einfach sagen könntest, ich habe eine Klasse und die wird automatisch in eine Corelita-Datenbank unsichtbar reingeschrieben und dann kann ich der Klasse sagen, ok du bist jetzt private oder du bist shared oder du bist public und dementsprechend würde sie sich dann in den Corelita reflektieren. Das wäre halt cool.
Oder, das ist mein Punkt in meinem Artikel, ein Actor. Weil Actors haben nämlich diese schöne Eigenschaft, das hatten wir ja glaube ich letztes Mal schon, immer wenn du etwas an den Daten eines Actors änderst, musst du einen asynchronen Call machen, du machst dieses Await dann und das hat den Vorteil, dass du eben Thread-Safe bist, dass du eben keine Probleme hast, wenn du gleichzeitig zugriffst.
Und ich habe auch das Gefühl und deswegen habe ich die Hoffnung, dass dieses Jahr diese Library tatsächlich kommt, dass diese Distributed Actors, bei denen wir jetzt mal gesprochen hatten, was jetzt neu kommt in Zwift, dass die viel damit zu tun haben, dass eben Corelita mit iCloud, also der neues Framework mit iCloud auch funktioniert. Weil Distributed Actors ermöglichen nämlich Actors, die eben nicht auf demselben Gerät sein müssen, sondern zum Beispiel auf iCloud sein können.
Ja, könnte das schon so ein bisschen dahin sein, dass das kommt.
Vielleicht mal schon.
Dieses Jahr schon? Weiß ich nicht oder? Vielleicht nächstes Jahr, oder? Ja.
Also ich denke einfach an Zwift.JR zurück, weil Zwift.JR war es auch so, sie haben quasi vorher die Grundsteine gelegt und dann wären wir dabei dieses Jahr so "Ach, deswegen habt ihr so viel Zeit jetzt investiert in dieses Thema in Zwift." Und das Gefühl habe ich gerade auch. Ich weiß nicht, ob es natürlich eine Persistenz-Framework wird, was auch immer dieses Jahr kommt, denke ich, ob es auf jeden Fall etwas mit Distributed Actors zu tun hat, wofür sie es gebraucht haben, was es ist, weiß ich noch nicht.
Gut, haben wir noch was zur WWDC?
Hardware, erwarte die Hardware.
Glaube nicht. Also ich glaube, letztes Mal oder voll letztes Mal wurde der M1-Prozessor vorgestellt, mit den ersten Macs.
Angekündigt?
Angekündigt, ja. Irgendwann wurde der Mac Pro, der Mac Pro wird auch standardmäßig bei der WWDC angekündigt, weil das ein Entwickler Hardware ist. Und ich könnte mir vorstellen, weil sie auch dieses Jahr noch den Mac Pro zu Apple Silicon bringen wollen, dass sie entweder ihn fertig haben oder ihn ankündigen und an Teasern.
Ja, Teaser kann ich mir auch vorstellen.
Eventuell mit einem geupdatierten Prozessor, also mit einem Dual-M1 Max Ultra-Probo.
Ich weiß nicht, ob Double Max.
Sie haben das schon anscheinend gesagt, dass die M1-Reihe zu Ende ist. Also ich glaube, es kommt erst an die M2. Es könnte sein, dass sie bei M1 angefangen haben mit dem Schwächsten und dann sich hochgearbeitet haben und das sie jetzt andersherum machen. Die Regel macht es nämlich andersherum. Sie fangen immer mit dem teuersten Gerät an und dann arbeiten sie sich runter. Kann ich mir vorstellen, dass M2 Ultra zuerst kommt und dann kommt die Nächste.
Würde sie machen, ja.
Ja, also wie gesagt, jetzt könnte ich mir gut vorstellen, dass da noch in die Richtung was kommt. Ist natürlich jetzt für mich nicht interessant, weil teuer wahrscheinlich, aber könnte für einen geankündigt werden, die ein bisschen intensiver programmieren, könnte das vielleicht interessant sein.
Ich glaube mir, ein Entwickler braucht keinen Mac Pro. Das ist was für...
Wenn du hier Android Engine Spiele programmierst, dann vielleicht. Ja, gut, dann ja. Vielleicht richtig so 3D-Kram mit Android Engine. Klar, dann auf jeden Fall. Oder wenn du ordentlich was rausrendern musst. Auf jeden Fall. Aber für eine App in Xcode, da reicht ein gutes Mac Pro.
Das würde ich mir programmieren wahrscheinlich.
Da reicht ein gutes Mac Pro oder auch der Studio Mac jetzt wunderbar aus. Selbst mein Intel Mac reicht immer noch vollkommen aus.
Also für mich ist der neue Studio der neue Mac Pro. Der Mac Pro wird ein echter Mac Pro, den man wirklich nur noch Profis in bestimmten Situationen brauchen. So wie Pixar-Mitarbeiter zum Beispiel. Ich denke immer an Pixar-Mitarbeiter, wenn ich an den Mac Pro denke.
Ich denke, wie Holger schon sagt, auch immer noch an den Android Engine 5 mit diesem Realtime-Lightning, was ich jetzt mal gesehen habe zu Videos drüber. Ist echt brutal, wie die dann zur Runtime die Licht- und Schatten berechnen und so weiter. Klar, dafür brauchst du Power.
Die bietet auch Power zur Runtime.
Ja, genau. Da brauchst du zur Runtime. Da brauchst du auch die guten Presses zu wenden und so weiter.
Hoffentlich sehen wir da vielleicht auch mal. Vielleicht wird ja auch Apple wirklich mal eine Spieleplattform, weil da auf einmal wirklich der gellste Scheiß drauf läuft.
Nein, nein, nein.
Wer weiß?
Die Spieleplattform von Apple haben wir noch nicht ausgetauscht. Das ist die größte Spieleplattform der Welt. Wahrscheinlich. Also gut geschätzt. Aber was größtes wird vielleicht noch.
Ich glaube schon, dass da auch die Entwicklerszene auf einmal merkt, oh cool, die Macs sind schon so stark, da können wir vielleicht auch unsere Gramme anbieten. Und die Android Engine läuft ja auch so drauf. Du kannst deine Binary auch Mac-kompatibel raushauen.
Ja, kommt dann ein Apple TV mit M1-Prozessor, wo dann Android-Channel drauf läuft.
Es gab ja Gerüchte mal, dass Apple eine Alternative zu einem Nintendo Switch rausbringen könnte. Gerade mit M1-Prozessor. Aber ich glaube, ehrlich gesagt, ich hatte letztes Jahr noch so die Hoffnung, aber inzwischen bin ich mir nicht so sicher.
Und das kommt dazu, dass der Mac-Markt wahrscheinlich noch kleiner ist als der PC-Markt. Der wird aber größer. Gerade seit dem M1, der Mac war ja früher, also ich sag's ganz ehrlich, ich hab's niemandem empfohlen, weil es einfach super schnell einen langsamen Prozessor hatte. Inzwischen empfehle ich fast jeder Person einen MacBook Air, du kannst damit sogar coden. Das ist überhaupt kein Thema. Und deswegen gibt es die anderen Macs aus meiner Sicht, die auch schnell genug sind.
Ich hab vor meinem 16 Zoll hatte ich einen MacBook Air 13 Zoll mit AI7 gehabt und das hat wunderbar ausgereicht. Das Display war schlecht, aber das hat echt 7 Jahre gute Arbeit geleistet.
Ich kann dir mal vorstellen, dass ich in meinem 2016 Touchbar Pro gegen einen MacBook Air tausche.
Es gibt einfach mehr günstige Macs, die auch Leute interessieren. Meine Frau hat jetzt auch einen MacBook Air. Sie benutzt das fast gar nicht, aber das sei ihr lieber als so ein 400-500 Euro Laptop.
Gut, wir haben noch einiges auf der Agenda stehen und müssen noch ein bisschen vorankommen. Eine kleine News wollte ich noch, die ich schön fand und entdeckt hab, die auch schon wieder ein bisschen älter ist.
Ich habe hier ein cooles Ding, mit Shortcuts kann man sich Watchfaces zu Zeit und Ort anlegen. Du gehst zum Fitnessstudio und wählst deine Uhr und zeigst dir deinen Sportwatchface an. Oder du gehst in die Arbeit und zeigst dir deinen Arbeitswatchface mit Kalender oder was man da so haben will.
Du kannst dir den Shortcut an und sagst, wann er auf dem Internet ausgelöst werden kann. Wo kann man die Zeiten oder Orte festlegen?
Da haben wir verlinkt. Da könnt ihr euch angucken. Das ist einfach aufzusetzen. Zwei oder drei Aktionen sind das in Shortcuts bauen und dann gibt es vielleicht auch was vor, gefertigt im Artikel. Finde ich ganz gut. Dann kommen wir mal zu euch. Was hast du denn Neues?
Bei Bits und so wurde meine App Second Clock vorgestellt. Das ist eine Mac App, die eine zweite Uhrzeit von der zweiten Zeitzone darstellt. Da Timo Hetzel sein großer Fan ist von diesen Swatch Beats Internetzeit, habe ich die da mal ein und dann hat er gleich natürlich vorgestellt. Die App hat mir aber auch immer noch private Nachrichten mit Bugs geschickt, die er gefunden hat. Und ich habe natürlich auch selber noch wieder Bugs gefunden. Und ich habe in den letzten Wochen immer mal wieder viele kleine Updates gemacht, um diese Bugs zu beheben. Und ich bin, also Facebook oder Meta geht ja so vor, die schreiben in jedem Update, machen alle zwei Wochen ein Update und in jedem Update steht drin, wir haben Bugs gefickt.
Ich habe mir vorgenommen, einen speziellen Bug zu fixen, habe den dann schön lösen können und habe dann das Update in die Store geschickt, damit auch viele Leute so schnell wie möglich Freude haben. Weil ich da gar nicht in der Erwartung war, wieder lange an der App zu schrauben, sondern einfach nur, der Bug ist weg und kann jetzt benutzt werden. Und habe dann einen neuen Bug gefunden, manchmal am gleichen Tag und habe den dann gesorft und habe dann das hochgeschickt. Und so sind es teilweise einfach mal drei Updates in die Store gelandet.
Du kannst nur eins in der Pipeline haben, aber du kannst mehrere vorbereiten. Und dann wollte ich einfach wissen, wie ihr mit sowas umgeht. Wenn ihr einen Bug habt, der nervig ist, fixet ihr den sofort oder wartet ihr zwei Wochen bis euer nächstes Update in die Planmäßige in die Store?
Gut, dass du fragst. Ich habe nämlich auch gerade sehr, sehr viele Updates bei mir rausgehauen, bezüglich neuen Sprachen eingeführt, wo ich dann auch im zwei bis drei Tagesrhythmus einen Update rausgehauen habe. Aber nicht so schnell ging es dann nicht, aber ich habe mich um eine neue Sprache gekümmert, habe geguckt, passt alles, sieht alles gut aus, klingt alles plausibel, habe es dann rausgehauen und mittlerweile habe ich Reviews bekommen, dass Leute sich beschweren, dass ich meine Apps so häufig update. Und die das dann nervig finden. Was ich vielleicht nachvollziehen kann, wenn man sagt, ich veränder jetzt jeden Tag die UI und man findet die Funktion nicht wieder. Aber es waren einfach nur Translations, die ich sage mal, wenn du die App weiter so benutzt, hast du davon nichts mitbekommen, außer dass Leute nicht die automatischen Updates haben, sondern jedes Mal abklicken wollen oder abklicken wollen.
Dann ist man vielleicht genervt. Aber ich bin auch nicht mehr so ein, ich habe das automatisch an, weil das spart einfach Zeit.
Es gibt auch viele Leute, die aus Datengründen, also die zum Beispiel ein LTE-Router oder so was haben und die halt kontrollieren wollen, wie oft wieviel geupdatet wird.
Es gibt auf jeden Fall Leute, die immer noch updateen und ich würde da ein bisschen referenzieren, was große Unternehmen machen. Und dabei meine ich jetzt, ich glaube du hast das auch schon an Tinder erwähnt, an die Kurven, an der Tweet, aber es gibt auch andere, Facebook und viele weitere Unternehmen, die machen tatsächlich regelmäßig Updates.
Ich vermute, dass die intern mit Sprints arbeiten. Für die hat es sicherlich den Grund, dass sie nicht öfter updateen, weil sie natürlich immer vorher einen schönen Test machen müssen, einen Testlauf und dann macht es natürlich keinen Sinn jeden Tag einen Riesen-Testlauf zu machen.
Und die machen dann so zwei-wöchige oder einwöchige oder drei-vierwöchige Sprints. Und ich persönlich finde das auch privat, ganz natürlich, also deine Frage zurück. Ich persönlich verfolge eigentlich so Semantic Versioning.
Das heißt, ich sage mir, okay, ich mache nur alle x Tage oder Wochen ein Update und sammle dann immer, außer ich hätte einen Bug, was eben so ein Hotfix braucht, wo die Leute wirklich dann gehindert werden, ein bisschen das Feature zu nutzen, was wirklich die Leute stört, dann würde ich das sofort fixen.
Das wäre für mich ein Hotfix, das heißt Version 1.0.1 zum Beispiel, während ich, wenn ich wöchentlich Updates mache, in der Regel dann 1.1.0 mache, weil dann eben Features dazu kommen.
Gut, aber der Zeitraum hat jetzt erstmal nichts mit Semantic Versioning zu tun. Also, ich meine, du sagst ja bei Semantic Versioning, du hast einmal die drei Zahlen, die erste ist die Major, die Minor und dann kommt der Hotfix und ich meine, eine neue Sprache zu hinzufügen, ja, kann ich auch eine Woche stretchen, aber bei mir ist es halt auch so, wo ich mir denke, ja cool, bringst du das halt raus, weil du was du halt durch regelmäßige Updates machst, ist der Appstore-Algorithmus belohnlich dafür. Du rankst besser, wenn du häufig updatest. Ist die Frage, okay.
Wenn du häufig oder wenn du regelmäßig?
Wo ist der Unterschied zwischen häufig und regelmäßig? Wenn du in einer Woche jeden Tag einen Update rausbringst und in drei Wochen nicht. Ist das gut oder wäre es besser, wenn du jede Woche einen Update rausbringst? Das weiß man halt nicht genau, es ist auf jeden Fall gut, wenn du mindestens einmal im halben Jahr einen rausbringst und nicht erst nach drei Jahren wieder. Klar, dann bezinkst du wahrscheinlich im Ranking.
Also, wenn du wöchentlichen Update rausbringst, bist du bestimmt immer noch ganz gut mit dabei.
Ja, ja, du bist auch wahrscheinlich monatlich oder dreimonatlich noch gut dabei. Das hat eine Blackbox, man weiß es nicht, ich kenne es nur von diesen ganzen ASO-Techniken, die man da im Netz liest, da sagt er, ja, regelmäßiges Updaten bringt was.
Also ich betrachte es auch aus der Seite, wie bei Großunternehmen, dass du eigentlich bei jedem Update testen willst, ob dein App-Update noch richtig funktioniert. Deshalb würde ich durchaus eher mehr Features zusammenpacken. Das verhindert auch, dass man eben wegen einem kleinen Fixen einen Release macht, wo dann was anderes zerstört wird, also so als Niemethack. Und deswegen, ich teste lieber, bevor ich release, nochmal den Haupt-Use-Flow und darauf habe ich keine Lust, das jeden Tag zu machen, deswegen lieber so einen festen Tag.
Gut, aber du weißt aber auch an, an was du gearbeitet hast und du weißt auch, wenn du an dem Modul nicht gearbeitet hast, dann wird auch nichts kaputt gegangen sein.
Also, aus Erfahrung muss ich sagen, das denke ich immer, aber am Ende kommt dann doch irgendwas anderes. Ich ändere doch vielleicht hier noch eine Seite Code, dann ist ja noch ein kleines Refactoring und dann kommt da wieder noch was raus.
Richtig, das muss man vermeiden, dass man sich nicht durch die Code besser durchgeht und dann so kleine Änderungen. Klar, das gibt es direkt, aber klar, wenn du mit mehreren Leuten dran arbeitest, dann hast du halt die Gefahr, dass du halt was kaputt machst und das sollte durchgetestet werden, weil da hast du dann doch Seiteneffekte, dass irgendwelche Dinge, die da drüben gebaut wurden, auf einen Auswirkungen auf Modul C haben oder so. Das ist auf jeden Fall.
Also wenn du jetzt deine App jetzt vorgestellt wurde gerade in einem Podcast, da wurde ein Fehler entdeckt, dann würde ich auch sofort ein Update rausbringen. Und wenn ich dabei und wenn ich wüsste, jetzt die nächsten Tage kommen viele neue Nutzer und ich entdecke Fehler, dann würde ich auch die ganze Zeit neue Updates rausbringen. Ich denke, das ist eine Sondersituation, aber in der Regel hat man ja gar nichts davon, wenn man jeden Tag ein Update rausbringt, weil ja gar nicht so viele Nutzer wirklich davon profitieren. Deswegen, ich würde es in der Regel hinauszögern, in Sonderfällen natürlich kann man ja ein paar Updates.
Und meine andere Frage, die App war ja jetzt die ganze Zeit für 99 Cent drin? Hast du mal den Preis erhöht?
Nee.
Ich habe es auch gekauft, weil es so günstig ist.
Ich habe auch drei Euro. Deswegen kannst du gleich mal hochstellen. Kannst du mal drei Euro für verlangen. Ich glaube, das kannst du mindestens dafür verlangen. Ich nutze die App ja tatsächlich. Ich will immer wissen, wie viel du hast, das ist jetzt gerade in Japan. Deswegen, ich denke, wenn man die App braucht, dann zahlt man auch zwei, drei Euro. Aber deine Entscheidung natürlich.
Hätte dir ja mal dein App Store, wie heißt das hier, deine App Store Fee bezahlt, plus noch ein gutes Essen.
Es gibt tatsächlich ähnliche Apps inzwischen im App Store, die genauso viel kosten und mehr Funktionen haben. Deswegen will ich den Preis jetzt nicht da in der Konkurrenz...
Aber ey, du hast die Swatch Beats oder gibt es da auch noch eine?
Ich habe die Swatch Beats.
Und ich habe ein hässliches Icon, das muss ich noch mal ändern irgendwann.
Da habe ich dann auch noch was Schönes dazu, zu generell Design. Das können wir dann später noch darüber reden. Vielleicht hilft das dir auch.
Ja.
Judy, dann wäre das so weit von dir und dann abdecken.
Das wäre weit von mir. Mehr habe ich im App Store nicht gemacht.
Wie viele Downloads hast du bekommen?
Ah, was ist das denn?
So sind es irgendwie 1000, 100, weiß ich nicht.
Kann ich nachher... App Units oder Sales?
App Units müsste es sein. Aber ja, das ist ja eigentlich bei dir. Die sollten ja mit Sales gleichzeitig in Sync sein.
Ich gucke mal, die letzten 30 Tage. 40 Units.
40. Hättest du mal drei Euro rausgemacht, dann hättest du 120 Euro, nicht 40.
Na ja, kannst du immer noch erhöhen. Du wirst ja jetzt wahrscheinlich durch die paar Downloads vielleicht auch übergerankt.
Das wäre schön.
Judy, hätte ich mal eine Frage. Wie schaut es bei euch aus mit Akkuverbrauch unter iOS 15.4?
Habe ich nichts mit.
Bei mir ist es sehr schlecht geworden. Ich muss sagen, mein iPhone XS Max, was locker eineinhalb Tage bis zwei Tage gehalten hat,
ist jetzt am Abend schon bei 20 Prozent. Und dann habe ich es genauso benutzt wie vorher. Was mich ein bisschen ärgert, muss ich sagen.
Ich habe auch tatsächlich, ich weiß nicht, an welchem Abdeck es liegt, aber in letzter Zeit geht man auch schneller zur Leige.
Ich habe auch an mehrere Leute berichtet.
Also schneller zur Leige heißt, ich habe nicht mehr abends 75 Prozent, sondern noch mal 30 oder so.
Das finde ich ein bisschen nervig. Und ja, das ist halt auch immer einerseits möchte man schnell updaten und möchte auch, dass sie neuesten und latest stuff haben.
Aber das ist halt auch immer so Dinge, die man leider sich damit holt.
Und da kommt es halt bei Apple einfach nicht mehr zurück, außer mit gewissen Jailbreak Tools.
Und wenn man sich diese SHSH Blobs irgendwie mal abspeichert oder so, kann man noch zurückgehen.
Aber oft ist es halt nicht mehr möglich. Und man ist da gefangen.
Das ist halt die andere Seite der Medaille.
2 Euro ist es jetzt.
Sehr gut. Kauffolger, Kauffolgers App. Ihr macht ihn jetzt doppelt so reich.
In einem Monat wird es 4 Euro kosten. Also jetzt.
Genau, jetzt muss ich sagen. Schauen wir mal auch schon gerade über die Finanzen reden.
Und wir haben ja auch schon über den Kleinen Unternehmer geredet, der in Deutschland bis 22.000 Euro ist.
Bitte nicht mich fest nageln, selber nachgucken. Ich glaube 20 oder 22.000 Euro, die man im Jahr verdient, bleibt man umsatzsteuerfrei.
Und man muss diese nicht aufführen. Sobald man über diesen Betrag hinauskommt.
Das gilt an erster für das nächste Jahr. Also zum Beispiel ich bin letztes Jahr jetzt über 22.000 Euro gekommen.
Dann muss ich jetzt dieses Jahr theoretisch bin ich umsatzsteuerpflichtig.
So jetzt gibt es aber bei Apple und also du musst dir vorstellen, du deine Geschäftsbeziehung mit Apple ist ein B2B-Geschäft.
Ein Business-to-Business-Geschäft. Die Leute, die im App so deine App runterladen, das sind eigentlich nicht deine Kunden.
Das sind Apples Kunden. Apple bezahlt dich sozusagen für die Dienstleistung. Auch wenn du sag ich mal den generellen Kundenkontakt machst und mit den Leuten kommunizierst und so weiter.
Aber rein rechtlich bist du nicht der Leistungsempfänger. Und der Kunde ist nicht der Leistungsempfänger. Du bist nicht der, der die Leistung gibt, sondern der, der die Leistung gibt.
So und da gibt es ein Verfahren, das nennt sich, also Apple führt in dem Fall sowieso die Umsatzsteuer ab.
Und da gibt es ein Verfahren, das nennt sich das Reverse-Charge-Verfahren.
Sodass du dem deutschen Staatssachs, pass auf, Apple hat hier bereits die Umsatzsteuer für mich abgeführt.
Und du schreibst dann sozusagen an Apple eine Rechnung.
In der drauf steht, hallo ich habe hier, ich berechne Ihnen für die Leistung so und so viel Euro. Und dann schreibst du noch einen Zusatztext raus und hier ist, ist dank hier Reverse-Charge-Verfahren Paragraf blablabla.
Müßst jetzt nochmal nachgucken, wie der Text genau heißt. Ist keine Steuer dabei.
Und damit diese Rechnung schickst du an Apple und tust sie dir in deine Buchhaltungssoftware rein.
Und somit ist es dann für dich und für den Steuerberater und für den Steuer, für den Fiskus ist es damit abgegolten.
Und du musst keine Umsatzsteuer zahlen. Und was dann natürlich der schöne Nebeneffekt ist, dass du dich auch vom Finanzamt, wenn du über dein Jahr hinweg so wenig Umsatzsteuer anfällt, dann auch einfach davon befreien lassen kannst.
Das ist mir tatsächlich neu, ich bin auch noch selbst in der Unternehmerregelung drin. Aber heißt das dann, ich schicke tatsächlich eine Rechnung an Apple und ist es nicht irgendwie automatisiert, habe ich dann irgendwie Formulare in der Suche geladen?
Nein. Nein, du hast hier developer.apple.com/context/finance.
So und dann gehst du da drauf und dann logt man sich ein und dann kannst du nämlich, wir können ja alle gemeinsam gerade machen, kommst du auf einen Contact-Sheet von Apple Finance, da sagst du Select Option und dann sagst du Invoicing Apple for apps.
Tatsächlich. Und dann gibt es ein Formular, da hängst du ein PDF dran, wo genau das drauf steht. Du bekommst keine Antwort von Apple, du bekommst glaube ich eine automatisierte E-Mail zurück, ja haben wir erhalten, wir melden uns, aber im Prinzip melden sich nicht.
Aber es geht eigentlich nur darum, dass du diese Rechnung an Apple schickst und deine Buchhaltungssoftware ein, sozusagen mit dem, was du von Apple bekommen hast, verrechnest und sagst hier ist der Beleg dazu, Apple hat ihn bekommen und das selbe gilt auch mit Werbung bei Google.
Also du bist genauso bei Google, du verkreibst ja nicht die Werbung, es macht Google, du bist sozusagen nur der Werbeflächenanbieter und Google bezahlt dich dafür, also ist auch ein B2B Geschäft.
Das muss ich aber nur machen, wenn ich umsatzpflichtig bin.
Genau, das bist du erst ab 22.000, auch bevor, denn dem bist du in der Kleinunternehmerregelung, was wahrscheinlich die meisten betreffen wird, aber wenn man darüber hinaus geht.
Ist das eine persönliche Frage, ist das unabhängig, wenn ich mehrere Unternehmen habe, sind die unabhängig?
Also ich bin nämlich umsatzsteuerpflichtig mit meiner Solaranlage, da bin ich umsatzsteuerpflichtig, mit meinem App Store eigentlich nicht, weil da verdiene ich ja nichts mehr, das ist jetzt eigentlich nur Hobby.
Das kommt wahrscheinlich auch an, wenn du die russische Person bist, wenn du persönlich die russische Person bist, kann ich mir durchaus vorstellen, dass du das dann machen müsstest.
Aber musst du wirklich mit deiner Solaranlage, du machst das doch nicht 22.000 Euro im Jahr.
Nein, aber wenn ich umsatzpflichtig bin, kann ich die Mehrwertsteuer zurückbekommen, das waren irgendwie 5.000 Euro und ich bin dann für 5 Jahre umsatzpflichtig und muss 5 Jahre lang 200 Euro bezahlen an Umsatzsteuer, also uns 5.000 Euro, das heißt ich habe insgesamt 3.000 oder 4.000 Euro plus, weil ich die umsatzpflichtige Mehrwertsteuer wieder bekomme.
Ich verstehe, du hast jetzt ein Unternehmen angemeldet für deine Solaranlage, ja, aber dann kannst du doch trotzdem jetzt hingehen und sagen, den Finanzaufrag passen auf, da fällt so wahrscheinlich so wenig umsatzsteuer an, stellen sie mich mal frei.
Ich könnte ein kleines Unternehmen auch für die Solaranlage beantragen, aber dann würde ich die Mehrwertsteuer von Kauf der Solaranlage anziehen.
Ah, ok, interessant.
Und da das ein großer vierstelliger Betrachter mit der mittleren vierstelligen Betracht ist und das auf jeden Fall mehr ist als für 5 Jahre lang die Umsatzsteuer abzuführen, ich muss ja umsatzsteuer auf meinen selbst verbrauchten Strom-Editor bezahlen, auf den Strom den ich nicht verkaufe.
Du bist dein eigener Kunde.
Ich bin mein eigener Kunde, genau.
Ich meine, du holst dir die Elektronen aus der Sonne, dann hält die noch mal schön die Hand auf.
Ja, genau, hier auch kein Gespräch mit eurem Steuerberater, kein Financial-Advice von mir.
Les euch selber rein.
Wir haben hier auch noch einen Artikel dazu, das habe ich auch darüber gefunden, hat einer hier geschrieben, wie man das macht.
How to invoice Apple.
Ist nicht so schwierig, wenn man das einmal gemacht hat, muss man halt jetzt jeden Monat machen und einfügen.
So, ich hatte dann jetzt ein bisschen Updates zu meinen Apps, da habe ich auch wieder viel, viel passiert.
Ich habe jetzt mal meinen ersten Content-Marketing gemacht, in dem ich mir einen Tutorial erstellt, also ich habe ja schon Content-Marketing gemacht mit meinem YouTube-Kanal, der schon ein bisschen eingeschlafen ist, wo ich eigentlich wieder was machen musste.
Da habe ich jetzt einen Tutorial in einem Blog auf meiner Webseite gepackt, und zwar ein Tutorial über wie man sich eine NFC-Business-Karte bastelt, die unabhängig von einer App ist, also die dann auf Android funktioniert und das dann zusammen mit Google Drive funktioniert oder mit seinem eigenen Server, wenn man das möchte.
Verlinken wir, habe ich den Weg in den letzten so geguckt, ob das so geht und habe ich herausgefunden, geht und habe ich auch schon auf ein paar diversen sozialen Medien gepackt wie Reddit oder so und habe da auch schon positives Feedback von bekommen,
weil da sind einige Firmen da draußen, die wollen dir einen NFC-Tag für 20 Euro oder sonst irgendwas verkaufen und die bieten dir dann halt einen irgendeinen Service, aber im Prinzip das einzige, was du brauchst, ist ein V-Card-File auf deinem Server legen.
Und so ein NFC-Business-Karte macht halt schon was her, einfach hier tab, boom, hast du meine Business-Karte, kannst abspeichern, ohne dass du irgendeinen Service hast, wo du dich anmelden musst, der deine Daten hat, der, weißt du, mit deinen Daten schuldrig umgeht oder so.
Und du bist halt einfach, sag mal, was Google dann da zweist, Google Drive, aber ich kenne mal, Google Drive kann man eigenmaßen gut vertrauen, was das angeht vielleicht an, was Google mit Daten macht, weiß man wieder nicht, aber mit Security hoffe ich doch mal, dass das vielleicht jetzt gut passt.
Solltest vielleicht das Feature oder dein Blogartikel auf Japanisch übersetzen lassen, weil ich weiß zufällig, dass in Japan, wenn man sich kennenlernt, eine Kultur vorherrscht, dass man Visitenkarten austauscht.
Ist ja bestimmt auch in Japan so, aber ich meine, das sind ja auch unter Agents und Businessleuten und Leuten.
Also ich habe schon mehr Visitenkarten bekommen, einfach von Leuten, die ich noch mal getroffen habe und die haben mich dann auch angeguckt, wo ist deine Visitenkarte, im dem Sinne.
Genau und schön, dass du sagst, ich habe mir jetzt auch zu diesen, wo du jetzt sagst, Visitenkarten, ich habe mir, ich weiß nicht, ob du das schon mal erzählt hast, ich habe mir aus China direkt custom-made NFC-Tags bestellt oder auch erst mal Testmuster bestellen lassen, die sehen.
Ich sage es euch mal so, das sind so kleine Dinger hier, das sind so wie so ein App-Logo in der Größe, das waren jetzt die Testinger, da ist ein NFC-Tag drin, die sind so mit Epoxidharz überzogen und sind auch feste, also die, das mag nicht, ne, einfach beidseitig hier wie so ein Chip, den man hier, wenn man so hört, ein bisschen hartplastik, so ähnlich.
Da habe ich jetzt, die werden nicht so aussehen, die werden ein bisschen besser und größer sein mit so einem Bändchen, aber es ist jetzt für mich Werbematerial, die kosten mich tausend Stück ungefähr 700 Euro oder 800 Euro mit Versand, die direkt aus China gekommen sind.
Die müssen jetzt höchstwahrscheinlich auch morgen ankommen und ich mich auch schon drauf freue, weil dann kann ich auch ein paar Mal einen Urlaub vielleicht verteilen an neue, neue potenzielle Kundschaft.
Die sind ja schon bespielt. Ne, die bestiebe ich dann selber neu, natürlich mit meinem Appstore-Link, den ich auch, wo ich vielleicht auch noch drauf kommen will, ist, dass du Appstore-Links machst, das kannst du im Appstore Connect dir machen und zwar in den Analytics kannst du dir Track-Links machen, das weißt du, ok, woher hat derjenige deine App runtergeladen, also das kannst du auch ein bisschen messen, was deine Werbe-Kampagne so gebracht hat.
Das sollte man auf jeden Fall machen, diese Campaign-Links und die werde ich dann aufspielen und dann gebe ich die Dinge raus und sehe dann, ok, so und so viele haben es runtergeladen. Ich denke mal, jeder, der so einen NFC-Tag kriegt, wird es auch runterladen.
ob es dann wirklich zu einem Sale kommt oder zu einer Conversion sozusagen, wenn man runterlädt und dann bezahlt, weiß ich nicht, aber kann ja sein.
Kann man denn mit deiner App, wenn man nicht bezahlt diese NFC Decks beschreiben?
Natürlich kann man das.
Dann musst du erstmal gucken ob die Leute das tatsächlich kaufen.
Richtig, es ist ja auch erstmal Werbematerial, ich verdiene ja auch daran, wenn die Leute nur die Werbung sehen,
aber ich meine es ist auch immer schön, dass man so ein Ding einfach rumgeben kann und Leute das cool finden und vielleicht auch einfach in die App entdecken und sehen, ach, da sind ja noch mehr Features und hier, ich kann da noch mehr entdecken und ach ja, dann schmeiß ich doch mal ein bisschen Geld ein und hier hast du verdient.
Das sind halt Effekte, die kann ich jetzt noch nicht messen, aber ich glaube es ist ganz cool, wenn man so ein Ding einfach mal in die Hand geben kann, weil du halt einfach die Leute in das Feld einbringst und dafür interessiert sich und können sich selber ihre Businesskarte daraus bauen und macht halt was her.
Genau, da ist auch, wenn man so überlegt, ich meine, wenn das Ding mich 70-80 Cent pro Stück kostet, ist es halt, mein Werbeklic kann auch so viel kosten, dann geb ich dir lieber so einen NFC-Tech raus, statt dass ich jetzt Google oder Apple irgendwie 70-80 Cent dafür geb, dass ich einen Klick bekomme.
Dann haben die Leute wenigstens was davon, oder?
Genau, dann haben die Leute wenigstens was davon und dann weiß ich, wird sich diejenige Person auch damit beschäftigen.
Genau, und das zu Self-Promotion, das habe ich jetzt auch weiterhin gemacht mit, meine App weiter auf mehrere Sprachen übersetzt, was natürlich mit Party Crouch und DeepL zusammen, was auch soweit ganz funktioniert.
Ich habe zwischendurch zwei, drei Nachrichten von Dürsam bekommen, dass da so ein bisschen Sachen schiefklingen, um die ich mich dann auch kümmern werde, also wo ich auch schon gesagt habe, ja schicken wir mal deine Translation, ich verbessere das dir.
Die meisten haben schon gesagt, im Grunde schon gut, an manchen Stellen klingt das halt wirklich gar so machine translated und falsch.
Ja, einfach, dass es halt schon mehr hat.
Nichtsdestotrotz, man darf ja auch Übersetzungen nicht nur als Übersetzungen sehen, sondern Übersetzungen sind natürlich auch ASO, also App Store Search, Engine Optimization, weil pro jede Sprache, die man macht, also nicht nur in der App, sondern auch in der App Store, die man lokalisiert, bekommt man natürlich mehr Keywords.
Und deine Keywords sind Apptitel, Subtitle und die Keywords, die Hundertzeichen, die man bekommt und die sollte man natürlich auch nutzen und in verschiedenen Sprachen suchen verschiedene Leute unter verschiedenen Begriffen auch.
Und du erhöhst halt einfach deine Reichweite an Bezugbegriffen, die Leute, die Leute dich halt im App Store finden können.
Und da nutzt man dann natürlich auch viele dieser ASO Tools, da habe ich jetzt auch in letzter Zeit noch einige ausprobiert.
Ich sage jetzt mal so fünf, die ich benutzt habe und zwar AppFollow, AppFigures, AppTweak und AppLizer und ich würde mal sagen so AppFigures und AppTweaks sind so die Marktführer.
AppFollow kommt danach, AppTweaks ist eher die günstigste Variante und dann bist du schon zwischen 50 und 100 Euro im Monat los.
Was die machen ist, du gibst ihnen sozusagen deine Apptage und die connecten sich komplett mit deinem App Store Connect und die zeigen dir dann also was mit deine Sales und deine Statistiken und kannst du Reviews bearbeiten.
Und zwar sozusagen den Layer on top auf App Store Connect und was sie dir halt anbieten ist, diese ganze Keyword Researching.
Und da gehst du natürlich mit deinen Keywords hin, die du hast im Kopf und sagst hier zum Beispiel, weiß ich nicht, für meine NFC-Karte habe ich zum Beispiel Visitenkarte drin.
Und dann guckst du nach, okay, ist es überhaupt was die Leute suchen und da kriegst du dann zum Beispiel so für Visitenkarte auf Deutsch kriegst du einen Popularity Score und einen Competition Score.
Also sozusagen wie populär ist das Keyword und wie viel Konkurrenz hast du in dem Markt, also wie viele Apps gibt es da und wie schwierig ist es für dich da irgendwie nach oben in der Platzierung zu kommen.
Visitenkarte ist halt ein stark belegtes Keyword, aber andererseits ist es halt auch wirklich was, was du mit meiner App machen kannst.
Also musst du überlegen, Leute suchen vielleicht nicht nur nach Visitenkarte, sondern nach NFC-Visitenkarte und dann kannst du sie zeigen dir auch live an, wie ist dein Ranking in diesem Ding und das ist dann auch wie du es machst.
Du gibst Keywords da rein, so wie du denkst, dass Leute deine App suchen und tracks sozusagen dein Ranking, wie ob du durch deine ASO was machst, also deine Veränderung der Keywords, ob du im Ranking steigst oder fällst.
Und da sollte man auch im Kopf behalten, dass man vielleicht Keywords sich ausgedacht hat.
Zum Beispiel, ich hatte mir überlegt, dass ich also zum Beispiel das NDEV Format, dieses Format, wie du es auf einem NFC-Chip speicherst, ist mal gemacht für mich ausentwickelt, dass ich jetzt nicht absolut Sinn dieses Keywords benutzen.
Aber dann gibst du mal dieses Keyword da rein und dann steht da Popularity 5.
Das heißt, keiner sucht danach.
Warum solltest du diese vier Buchstaben dafür verschwenden für etwas, was eh keiner sucht?
Jeder, der irgendwie NDEV eingibt, würde auch NFC eingeben. 5 auf einer Skala von? 5 bis 100. Also Popularity 100 ist, wenn du Instagram hast. Instagram hat Popularity 100.
Und ich glaube, unter 5, also ich rede jetzt gerade von AppFigures, die anderen haben ein ähnliches Ding, was diese Popularity und Competitiveness angeht.
Genau, und da sollte man auf jeden Fall gucken, such dir Keywords, wo die Competition noch, sag ich mal, im 50er Bereich liegt und die Popularity hoch ist.
Zum Beispiel habe ich ein gutes Keyword gefunden auf Englisch, das nennt sich Decode, weil Decodieren, da bin ich jetzt auch erst am Anfang nicht drauf gekommen.
Decode suchen, also eine gute Popularity hat aber auch noch nicht so eine hohe Competition.
Und das ist dann halt diese Kategorie, wo du gut ranken kannst, weil wenn du darüber nachdenkst, du suchst nach einer App, was machst du? Scrollst 5, 6, 7, 8 Apps und dann war's es.
So, und dann bist du raus. Wenn du auf Platz 20 mit deiner App bist, dann wirst du nicht runtergehen.
Ohne Tasche keine Competition.
Ja, genau.
Kann man denn auch die Conversion tracken, also dass du dann siehst, ok, bei diesem Keyword, Decode zum Beispiel, haben sie so viel Prozent, dann hat sich meine App runtergeladen?
Leider nicht, weil sag ich mal, die ganzen ASO-Tools, die da irgendwie drauf machen, ist natürlich die Scraping ab den App Store und versuchen da ihren Algorithmus aufzulegen und irgendwie rauszurechnen.
Ich glaube auch diese Competitiveness und Popularity sind dadurch auch berechnet.
Auf welchen? Weil die Relevanz ja auch natürlich wichtig ist, weil wenn du dann in den Ergebnissen auftauchst bei vielen Suchen, aber am Ende für die Suchenden jeweils nicht relevant zu sein scheinst, dann bist du wahrscheinlich trotzdem nicht runtergeladen.
Richtig, du solltest natürlich nicht Keywords wählen, die völlig daneben sind. Also du solltest nicht Instagram bei mir reinschreiben, nur weil ich hoffe, dass irgendwelche Leute bei meiner App stolpern.
Was vielleicht auch funktionieren kann, aber man sollte Competitiveness sowieso nicht annehmen, also du solltest nicht, weiß ich nicht, Nintendo oder Pokemon oder sonst irgendwas, also Pokemon vielleicht, wenn du irgendwie schon in die Richtung gehst, aber du solltest halt nicht die Konkurrenz taggen damit.
Kann man sich viel drüber durchlesen und dann habe ich mich auch so ein bisschen gefragt, was diese ASU-Tools machen, ist natürlich den App Store Scraping. Und da habe ich ein schönes Paper gefunden von einem Studenten.
Scraping heißt, die Daten irgendwie sich zu holen. Genau, die Daten zu holen, weil es gibt eigentlich keine offizielle API, es gibt irgendeinen RSS-Feed, der ist sehr abgestumpft, du kannst dir irgendwie die Top 100 Apps ausgeben lassen und das war es irgendwie.
Aber du willst ja nach Kategorien suchen, du willst gucken, wie du gerankt bist, du willst Suchbegriffe eingeben und gucken, wie du für Suchbegriffe gerankt bist.
Habe ich ein schönes Paper von einem Bachelor-Arbeit von einem Studenten aus der Uni Uin gefunden, habe ich auch verlinkt.
Der nennt sich Entwickler einer Web Scraping-Plattform für mobile Anwendung, der halt einfach in seiner wettbewerbsgeschriebenen Arbeit geschrieben hat, wie man den App Store oder den Google Play Store mit verschiedenen Techniken scrapt und sich sozusagen da hinter die Kulissen schauen kann, wie es diese ASU-Tools machen kann.
Und natürlich kann man sich da auch selber Daten mit basteln. Habe ich jetzt auch so ein bisschen in so ein kleines Tool für mich gemacht, einfach weil es mich interessiert hat.
Es ist auch keine Magie dahinter, man muss das halt einfach nur mal ein bisschen mit rumspielen. Die ASU-Tools bieten natürlich viel mehr Power nach dahinter.
Also benutzt ihr da die HTML-Ansicht, wie wir sie im Web sehen, oder gibt es da noch eine XML-Ansicht, was man da zu kriegen kann? Da gibt es mehrere Dinge, da gibt es RSS-Feeds, da gibt es irgendwelche Legacy-APs, wo du teilweise JSON und XML zurückkriegst. Dann kriegst du, hatte ich jetzt auch mal ausprobiert, das JSON-Haus, das ist in QuickType rein, wo wir auch schon mal drüber geredet haben, QuickType-RO, lässt dir das in 12 Klassen generieren, schmeißt es dir in ein Projekt und machst mal einen Call dahin und dann kriegst du da auch die Daten zurück.
Da muss man schon mehrere Formate passen können um das alles unterzulernen.
Genau, also da gibt es, wie gesagt schaut euch diese Bachelorarbeit an. Ist zwar ein bisschen lang zu lesen.
Ich hab jetzt auch noch nicht alles durchgelesen, aber einfach mal so durchstreuen ist ganz interessant zu sehen.
Wie das so allzu allz, also einigermaßen gut dokumentiert. Ist komplett auf Deutsch. Also passt ja für unsere Audiens auch.
Für den Play Store stehts zum Beispiel, dass man erst mal anfängt ein HTML Dokument zu lesen
dann eine JavaScript Funktion aus diesem HTML Dokument zu starten und dann kriegt er entweder direkt Jason zurück
oder noch eine Funktion die dann Jason zurück gibt.
Genau und das ist ja auch so. Das ist ein so mehrschrittiger Prozess dener wollen.
Genau, das ist ja auch das was die App Stores wollen, dass sie das auch irgendwie nicht publik eigentlich machen.
Aber der finnische Hacker kommt halt irgendwie an die Daten, weil die App Stores sind öffentlich, also kannst du nicht alles verstecken.
Aber sie machen es ja mit solchen Obscurity Kram oder Security by Obscurity irgendwie auch schwierig das rauszupassen.
Dass es halt nicht jeder irgendwie so machen kann.
Na ja, es braucht ein bisschen AHA um so was zu basteln.
Dafür bezahlt man jetzt sich diese App Figures und weiß nicht was, weil die auch diese Arbeit machen.
Richtig, die machen das für dich und ja die können schon teuer werden.
Also wenn du da 120 Euro im Monat ausgibst, das sind dann auch schon 1300, 400 Euro im Jahr, die man dann nur für sowas ausgibt.
Man muss mal gucken ob es wirklich ein Mehrwertverein bringt und ob man das machen möchte.
Man sollte auf jeden Fall das einfach mal ausfesten, man kann die alle mal für ein, zwei Wochen ausprobieren.
Da auch gucken, dass man einfach die Tests da drauf macht, wiederkündigt und einfach alle Tools ausprobieren.
Die haben alle unterschiedliche Ansätze und auch Visualisierungsmöglichkeiten und so weiter.
Aber es ist auch einfach spannend zu sehen, was man da alles machen kann.
Genau, dann habe ich in dem ganzen Zuge, wie ich meine App vermarkte ja jetzt mit Abos und so weiter, habe ich auch jetzt bei mir Trials eingebunden.
Also Probar, wo das man meine App einfach mal drei Tage ausprobieren kann.
Ja und Transout führt zu Einnahmensteigerung, weil halt einfach Leute jetzt ausprobieren können.
Vielleicht weil ihnen die App gefällt oder vielleicht weil sie einfach verpennen, sich abzumelden.
Aber leider spielt man halt mit solchen Dingen, aber es funktioniert halt auch leider. Aber das verpennt man ja auf der Weile, die können ja dann doch irgendwann. Genau und die holen sich auch ihre Kohle teilweise wieder zurück.
Also ich kriege auch über meinen Portal der Conversion, wo wir schon drüber geredet haben, also mit QConversion.io, sehe ich auch, da gibt es, ja ich habe bestimmt am Tag irgendwie zwischen, ja, um die 50 Dollar Refund.
Wobei einer sagt, oh das wollte ich nicht, dann hol ich das dann wieder. Ist auch okay, kann man das auch machen.
Ich will da auch eigentlich niemanden zu zwingen und so weiter, du hast ja auch genug Tools, da wieder von Apple das zurückzuholen.
Der eine oder andere würde auch sagen, ja gut die drei Euro sind mir jetzt auch wurscht.
Aber es führt auf jeden Fall dazu, dass man die Einnahmen erhöht und was auch schön ist.
Und da gibt es noch ein schönes Ding, was da jetzt nämlich passiert ist. Ihr kennt ja, dass wir vielleicht alle eine Kreditkarte an unserem Apple Zeug dranhängen, aber es gibt auch genug Leute, die haben einfach keine Kreditkarte und die haben halt irgendwie gut haben dran oder die Kreditkarte ist abgelaufen und so weiter.
Und sobald du dann aus dieser Trial rausläufst, möchte der App Store dich ja eigentlich sozusagen, du gehst brechen und sagst, okay jetzt möchte ich brechen.
So, aber wenn du keine, du läufst aber nicht in den Sorgerein, dass du so einen Zwang hast, dass Apple sagt, okay du musst es jetzt bezahlen, sondern Apple sagt hier, wenn du dein Konto wieder auflädst mit irgendeiner Karte, dann wird es brechen.
Und du nennst dich Billing Retry State, also das heißt, du gehst von deinem Trial in ein Billing Retry State und das ist zum Beispiel so, was ich bei mir gesehen habe, viele Leute aus Indonesien, die zum Beispiel keine Kreditkarte haben, da reinlaufen, die probieren eine App aus, lassen sie dann irgendwie liegen und haben das Apple nicht abgeschlossen.
Aber es wird auch nicht abgeschlossen, weil sie in diesem Billing Retry State hängen.
So und dann kommt die Magie dieser Plattform wie Conversion oder RevenueCat dazu, ist es die, das erkennen, ist der Server seitlich, der gibt so einen Billing Retry State und dann kannst du eine Automation aufsetzen, die deinem Kunden eine Push-Nacht schickt und sagt, hey, hier habe ich jetzt zum Beispiel gemacht, die sagt, hey etwas ist schiefgelaufen, dann machst du die App auf.
Dann bekommst du einen Alert gezeigt, der sagt, hey, es stimmt was mit deinem Billing nicht, guck doch mal in den App Store und dann kannst du auf den Knopf drücken und dann bist du in den App Store geschmissen und dann kommst du genau zu deinen Zahlungsinformationen und da steht dann halt, hey, weiß nicht, Kritikkarte ist abgelaufen oder gut haben nicht ausreichen, sodass du vielleicht nochmal aus diesem Billing Retry State nochmal irgendwie zwei, drei rausholst und halt deine Einnahmen steigern kannst.
Und ich glaube, wenn man sich sowas selber bauen will, das ist eigentlich fast unmöglich oder der Aufwand von Indien-Wickel ist viel zu hoch, da macht halt auf so ein System, was man da von außen schließen kann, extrem viel Sinn.
Auf jeden Fall.
Und ich glaube auch, weil jeder irgendwie auch, ich würde fast jeden empfehlen, der irgendwie auch jetzt mit Apps erst anfängt und irgendwie klein anfängt, nutzt ein System, die wollen erst Geld haben, sobald du 10.000 Dollar an Sales hast im Monat.
Das heißt, bis du 10.000 Dollar hast, das muss man erst mal schaffen und ist nicht so einfach, aber so lange sind die kostenlos und die bieten einen echten guten Service an.
Man kann natürlich auch noch extra Geld reinschmeißen, wenn man irgendwie Sonderfunktionen wie API von denen haben will, aber was man als kleine Indien-Wickel nicht wirklich brauchen kann oder nicht wirklich braucht.
Klingt sinnvoll auf jeden Fall.
Und zudem, jetzt reden wir ja so lange, wir reden monolog, aber es ist ja auch ein echt spannendes Zeug dabei, die auch für den genannten Hörer wichtig sind und natürlich auch unsere Hörerinnen, um die nichts zu vergessen.
Habt ihr schon mal von, jetzt um darauf zurückzukommen, nochmal zu Geld verdienen mit Apps von paywallscreens.com gehört?
Nein.
Können wir mal zusammen draufklicken, das ist eine Webseite, die dir Paywalls anzeigt von erfolgreichen Apps und zeigt dir ungefähr an, was die so verdienen.
Und dann siehst du, es ist ganz vorne ein YouTube-Premium mit 76 Millionen Euro im Monat und du siehst einfach dazu einen Screenshot dieser Paywall.
Woher wissen die, wie viel die verdienen?
Die haben natürlich auch Schätzungen und die hängen natürlich auch an diesen Payment-Systemen von irgendwas mit dran, von Revenue Cat oder sonst was.
Wo die Daten genau herkommen, weiß ich nicht, aber ich denke mal, die werden schon nicht ganz unecht sein, die Daten.
Interessant wäre ja vor allem, wenn du zum Beispiel bei YouTube mehrere Screenshots hättest, von deren Paywalls, so über die Zeit, und dann die Veränderung sehen könntest.
Weil wenn ich jetzt YouTube vergleiche mit meinen Apps, ist das ein bisschen unfair.
Natürlich, der Vergleich ist einfach auch mega unfair, aber man kann sich auch einfach mal Apps angucken, die auch weiter unten sind, die irgendwie so 10-20.000 Euro im Monat machen oder weniger.
Oder auch einfach mal nur angucken, dass es QR-Code-Reader da draußen gibt, die eine halbe Million Euro im Monat machen.
Das war so die QR-Code-Reader, die halt ganz oben im Ranking sind. Und da sieht man auch schon wieder, wie wichtig es ist, dass du im Ranking weit oben bist, weil wenn du im Ranking weit oben bist, macht es den Unterschied aus, ob du 1000 Euro oder mal eine halbe Million im Monat verdienst.
Und ganz unabhängig davon, was die verdienen, ist ja einfach nur schön. Also hier sind jetzt ganz viele Paywall-Screens, die man einfach direkt sehen kann.
Richtig einfach ein Ideengeber sein.
Genau, das ist erstmal ein Ideengeber, was andere so machen und dieses aufbereiten.
Und was du dann auch natürlich machen kannst mit diesen Services wie Conversion oder Revenue Cat, ist, dass du dir ein A/B-Testing baust, dass du guckst.
Du baust verschiedene Versionen deiner Paywall, vielleicht auch mit unterschiedlichen Preisen und lässt dann Experimente laufen über einen Monat oder so und kommst dann vielleicht zum Ergebnis, hey Paywall A, konvertiert besser als Paywall B. Und dann kannst du halt deine Schlüssel draus ziehen und sagen, ok, dann nutze ich jetzt Paywall A, weil die läuft besser.
Aber ist auf jeden Fall cool zu sehen, diese Webseite, ich fand das eine sehr, sehr gute Resource einfach nur mal zu sehen.
Paywall-Screens, genau.
Und ich glaube, da hängt dann auch noch so ein Service dahinter, ich glaube, da ist Superwall, die dir dann genauso was anbieten.
Ein Framework, was du rein in deine App einmachst und dann kannst du diese Paywall sozusagen live bearbeiten und dann halt publishen und kannst sofort eine neue Paywall in den Leuten zeigen.
Und die wollen halt auch dafür Geld haben, aber auch eigentlich ganz interessanter Service, einfach um deine Paywall so live zu bearbeiten.
Und jetzt komme ich noch vielleicht, ich kürze mal noch so ein bisschen ab, dann wie misst man auch so was, dass du, wie deine Conversion funktioniert und da hast du, G hat mich auch da gebracht, über diese Google Analytics, die man ja vielleicht durch, weiß ich, eingebaut hat, auch mit Google App zusammen, wo man dann irgendwie trackt, ok, wo klicken die Leute hin und dann kannst du halt auch so Sachen tracken wie Conversion mit Funnels heißen, wie Trichter, stell dir das nicht vor und am Schluss der Trichter, der läuft dünn zusammen und ja, du hast sozusagen eine große Menge, die reinkommt und dann hast du irgendwie am Schluss halt,
kann man sich vorstellen, wie 100% deiner Leute, die downloaden, sehen dein Onboarding so und 90% sehen deinen Payment Screen und 1% kauft so.
Dann hast du so ein Funnel, wie du siehst, ok, wie dein Userstrom sozusagen durch diesen Trichter geht und kannst halt dir sozusagen ja, Metriken oder Dinge ausrechnen, die du dann halt schön auch in Excel schießt oder so machen kannst, wie deine Conversion Rate ist.
Und dann kannst du halt auch durch Veränderungen dann irgendwann am Schluss messen, ok, was funktioniert jetzt besser.
Also Trichter, deswegen, weil du hast eine hintereinander durchgeführte Menge von Aktionen, eins zum Beispiel App starten, das andere dein Screen öffnen, das andere dein App kaufen zum Beispiel.
Und wenn die hintereinander ausgeführt werden, das ist dann ein Funnel und dann kannst du eben sehen, an welchen Schritten die Nutzer abspringen und nicht mehr dieser vordefinierten, die gibst du selber an, diese Aktion, nicht mehr diesen Aktion folgt, sondern eben woanders hingeht und dann eben deswegen fällt aber dann die Leute abspringen und am Ende nur noch vielleicht 3% dieser gesamten Funnel, die du definiert hast, durchgelaufen sind.
Ja, genau.
Und dann kann man sich halt auch verschiedene Funnel definieren. Du hast dir zum Beispiel Funnel für App geöffnet und ein App gekauft, du kannst dir aber auch Funnel definieren für ok, ich hab jetzt einen Nutzer, der ist wiederkehrend, der hat jetzt mein App wieder mal geöffnet, den kannst du irgendwie erkennen mit einem anderen Event und dann kannst du so viel erstellen, wie du willst und dann kannst du einfach dir selbst Fragen beantworten.
Und dann haben sich viele meine Nutzer befolgt eigentlich diese Ansammlung von Aktionen hintereinander. Und so kann man auch nicht nur mit Payment, sondern auch zum Beispiel aus dem Screen und du weißt, wie viele Leute gehen eigentlich hier, nachdem sie das hier gemacht haben, in die Einstellung und ändern die Einstellung.
Ja, das sind auf jeden Fall sehr, sehr mächtige Tools, die man auch von Google teilweise kriegt, die aber auch meiner Meinung nach schwer zu verstehen sind und schwer, also dass so viel Zeug drin ist, das man da ansetzen kann und man muss schon wieder ein halbes Analytics-Studium dafür machen, bis man überhaupt überreißt, dass dieses Ding alles erkannt hat.
Das ist dann für die, die Vollzeit diesen Job machen.
Richtig, richtig und dann halt auch für, sag ich mal, wahrscheinlich für verschiedene Manager und so weiter, irgendwelche Daten rausziehen, dass sie sagen können, hier ist spreadsheet, guck, da so performt unsere App. Was ich...
Genau, das sind halt so für alle Einsteigende nicht aus, das ist eine der ersten Dinge, die man tun kann, um sich selbst Fragen zu beantworten.
Was für mich halt die Analytics bringen, ist, dass ich jetzt halt sehe, ok, wie viele Nutzer benutzen, Funktionen so überhaupt, lohnt es sich da Zeit reinzustellen.
Dass ich halt einfach gucke, ich suche nach dem Event und sehe jetzt, ah, 50 Nutzer suchen, oder zum Beispiel bei meinen Webhooks, die ich eingebaut habe. Das nutzen User, aber es nutzt halt wirklich der kleinste Prozentensatz, also wirklich paar User nutzen, aber für die ist es wahrscheinlich auch super wertvoll.
Also du bringst mir eine neue Option in deine App rein und du packst die irgendwo in die Einstellung rein und dann kannst du auch einfach durch diesen Event, ob diese Option aktiviert wurde, einfach nur feststellen, ob die Leute das überhaupt finden. Also auch für UX, also für bessere User Experiments ist das ganz nützlich, sich hier manchmal anzugucken, nutzen die Nutzer überhaupt denn dazu und wenn nicht, dann weißt du, ok, vielleicht solltest du irgendwas an deinem UX sein.
Genau, und da kommen wir auch nochmal ganz kurz zum allerletzten Punkt, den ich jetzt noch habe, der auch vielleicht lärmvoll für den ein oder anderen sein kann, der sich mit Design auch manchmal schwer tut und zweitens, habt ihr schon mal von der 60/30/10-Regel gehört?
Ich habe sogar mal davon geschrieben, also tatsächlich, vor zwei, drei Wochen erst in einer Artikel habe ich sie erwähnt.
Ah, den habe ich nicht gesehen, aber ich habe diese 60/30/10-Regel auch vor einiger Zeit mal entdeckt und habe sie hier auch in die Show notes einfach mal reingedroppt. Ist einfach eine schöne, den Artikel, den wir verlinkt haben, ist einfach, du solltest dich auf drei bis vier Farben aussuchen und dann ist deine dominante Farbe sozusagen 60%, deine dominante, nicht kontrastlich, was ich uehr, oder auf jeden Fall deine secondary color ist 30% und deine accent color ist 10% und an diesen Artikel sieht man auch wirklich schön, wie man aus einem falschen Beispiel mit dieser 60/30/10-Regel auf einmal ein sehr ansprechendes Design rauskriegt.
Und der eine oder andere, wer sich da immer ganz gut tut in so was Design und so was intuitiv macht, tut sich da vielleicht leicht, aber wenn man dann, sag ich mal, diese 60/30/10-Regel sich mal anguckt, vielleicht nicht mit deinem Design so gut auskennt und vielleicht daran hält, dann kriegt man am Ende vielleicht ein besseres Ergebnis raus.
Was ich auf der Seite gerade offen habe, da sieht man oben einmal das Beispiel und unten das Ergebnis, wie es aussieht. Und da kann man schon einfach sagen, das sieht schon sehr, sehr viel besser aus. Also einfach cleaner, deutlich uesichtlicher, weniger in your face und ja.
Die Idee ist, jetzt nur drei Farben zu benutzen und eben eine Farbe, 60% des Screens für den Verlass, die andere 30 mit der 110 und dadurch wird das einheitlicher alles.
Und witzigerweise habe ich das ja in meiner App eigentlich, also in meiner NFC App eigentlich genauso umgesetzt, ohne dass ich von dieser 60/30/10-Regel wusste.
Ich habe auch halt genau meine Akzentfarbe, die du siehst, die macht halt 10% aus und dann hast du halt diese zwei Grundfarben aus dem System, also entweder schwarz oder weiß und dann halt irgendwie Grauton.
Und diese Regel ist auch, also es kommt aus der Farbtheorie und die ist auch nicht erfunden worden, sondern die wurde experimentell oder empirisch einfach extrahiert und dann hat man nachgeguckt, warum sehen denn diese Designs besonders schön aus?
Dann hat man versucht, die Regeln rauszufinden, woran man sich dann später orientieren kann, was ausregeln. Und einer von diesen 60/30/10-Aufteilungen von Farben.
Das ist ein Wunder, dass dir deine App schon schön vorkam vorher und dann am Ende, dass es sich darauf hinaus lief, dass es so ungefähr 60/30/10 ist.
Gut, das war es auch jetzt von mir. Die hat da bestimmt auch ein paar Neuigkeiten, oder?
Ja, ich bin ja jetzt auch vor allem mit dabei und ich war einfach auch mal zusammen was bei mir so gab, das ist jetzt ziemlich viel passiert im letzten Monat, seit der letzten Folge.
Und ich fange mal mit Bahti Crouch an, also sind wir in den Podcast eingestiegen, ich habe einen neuen Bahti Crouch Release gemacht in der Version 4.10.0 bzw. über Homebrew installiert in 4.10.2.
Da gab es nämlich keine Homebrew Probleme bei der Veröffentlichung, die ich dann beheben musste und es hat zwei Situationen gebraucht.
Aber es ist diese Version und im Grunde schafft die Einfachkompatibilität mit Xcode 13.3, was leider nicht automatisch gegeben ist, weil ich eine Library verwende namens Swift Syntax von Apple in Bahti Crouch selbst, um Swift Code zu analysieren.
Das ist für diese Bahti Crouch Inum, für alle die Bahti Crouch schon mal genutzt haben. Um diese zu lesen, verwende ich aktuell noch Swift Syntax und diese ist leider mit jeder neuen Swift Version, muss man die quasi ablehnen.
Genau, das habe ich auch live gemacht in meinem Stream, also wir können auch den Stream gerne verlinken, falls jemand quasi sehen möchte, wie ich diese Release gemacht habe, wie ich diese Probleme mit dem Xcode 13.3 gemacht habe.
Dann bin ich ja sowieso, ich bin ja auch in den Back reingelaufen, dass mit Xcode 13.3 nicht funktioniert hat und habe dir natürlich sofort geschrieben.
Richtig, ja. Aber was ist hier los, warum geht das nicht? Sie hat quasi reingelaufen, den Abblick gemacht bei Xcode 13.3. Genau, um bei meinen Streams zu bleiben, ich habe auch eine kleine Änderung in meinen Streams vorgenommen.
Ich hatte Mittwochs und Freitags gestreamt und ja, die Learning war einfach für mich, das hat zu viel Zeit gefressen letzten Endes, wenn ich an zwei verschiedenen Tagen gemacht habe.
Ich wollte ja, also mein Ziel war ja ein Tag in der Woche, also 20% meiner Arbeitszeit für dieses Streaming aufzuwenden, um einfach öffentlich einerseits Bahti Crouch Release, aber andererseits eben auch einfach dazu seine Fragen zu beantworten.
Man kann auch bei mir einfach live reinschalten und mir das Riftcode schicken, also GitHub Giz zum Beispiel.
Und ich gucke das mir einfach an, rewiel das ein bisschen, refaktoriere das ein bisschen, genau da freue ich mich gern, wenn da jemand reinschaltet, das macht mir Spaß.
Deshalb gerne das machen, jedenfalls habe ich dann eine Änderung vorgenommen, ich habe mir dann gedacht, okay, ich will jetzt eine Overhead loswerden, diese Vorbereitung für den Stream,
und dann nach dem Stream auch mal einen Tweet machen und so ein bisschen eben auf Social Media auch zu verbreiten, was ich gemacht habe.
Und ich habe das jetzt auch Freitag verlegt, das heißt ich stream jetzt 2-mal am Freitag, die nächsten 2 Wochen nicht,
also da stream ich nur Freitag Nachmittags, statt Freitag Morgen Freitag Nachmittag, weil wir jetzt gerade den fasten Montage anhaben, aber in 2 Wochen dann wieder 2-mal ganz normal Freitag Morgen und Nachmittag. So und dann habe ich auch im Stream einen neuen Release gemacht von einem Tool, was wir glaube ich hier noch nicht erwähnt haben, das nennt sich AnyLint, auch das können wir verlinken, wo ich den Stream, auch das Tool selbst, kennt ihr AnyLint?
Nein, ich kenne das auch noch nicht, nee.
Okay, also AnyLint ist einfach ein Tool, was ich mir geschrieben habe, weil ich früher, Zwiflint kennt ihr aber?
Auch nicht, auch nicht.
Okay, also Zwiflint ist ein Linter, ein Linter ist, ja das erkenne ich gern, also ein Linter ist ein Tool.
Lass mich kurz nur an den, die, die Analogie kommt, der Linter ist eigentlich, du hast
ja Fussel am Pulli.
Hast du schon mal, es gibt so Dinger, da kannst du Fusseln mit dem, mit einem Pulli, mit so
'nem Gerät wegmachen.
Das ist ein Linter.
Das hat doch was mit dem Rollen geführt.
Nein, das ist nicht, aber es gibt so richtig, die das so abrasieren.
Das sind Rasierer, die nur am Pulli benutzen.
Das ist ein Linter.
Und jetzt darfst du weiter machen.
Okay.
Stell dich vor du arbeitest in einem Team und das sind 15 Entwickler.
Oder Entwicklerinnen.
Und dann hat jeder dieser, dieser Entwicklerinnen, hat eine andere Vorstellung davon, wie man
zum Beispiel Sachen identieren soll.
Also ob du zwei Leerzeichen oder vier Leerzeichen machst.
Vielleicht hat jeder andere Vorstellung.
Oder ja, genau.
Oder jeder hat eine andere Vorstellung davon, wo die geschweifelten Klammern kommen und
ob dann eine geschweifelte Klammer, wie zum Beispiel Irv, irgendwas geschweifelte Klammer
auf, ob dann eine leere Zeile kommt oder nicht.
Und dann gibt es tausende solcher Themen, wo man sich sagt, okay.
Ja, aber da gibt es die richtigen und die falschen.
Also Leerzeichen ist ja schonmal falsch.
Also wie geht man das im Linter und was richtig ist?
Genau.
Das Problem ist dann, da gibt es eine große Diskussion um was ist denn jetzt das Richtige.
Und diese Diskussion.
Wenn ich meise die Leute raus, die falsch machen.
Und dieser Linter gibt einem dann Inexcode, so wie er selbst immer Warnings anzeigt, kann
der Linter dir dann Warnings anzeigen.
Hey, du hältst dich nicht an diese origine Regeln.
Und das ist ein Linter.
Und Swift Linter ist der, ich würde sagen, der beliebteste Linter für Swift Entwickler,
der am weitesten verbreitet ist.
Und wer das noch nicht verwendet, gerne mal auschecken.
Wurde von Realm entwickelt, glaube ich.
Ein Datenbankentwickler.
Und wird auch von der Community stark mitgehend.
Ich habe auch selber ein paar Regeln mal geschrieben vor ein paar Jahren.
Jedenfalls gibt es dann eine Funktion, dass man auch selbst Regeln schreiben kann.
Das nennt sich dann custom rules.
Und das funktioniert in Swift Linter so, dass du eine regular expression angeben kannst,
um eben eine bestimmte Struktur zu prüfen.
Das ist nicht für alle Regeln implementiert, aber für einige Regeln kann es automatisch,
die Warnings, also die Fehler, die, die Violations, die auftreten, die kannst du automatisch korrigieren.
Das nennt sich dann autocorrect, aber neuerdings heißt es, glaube ich, fix.
Also Swift Linter minus fix.
Und das kannst du bei deinen eigenen Regeln auch nicht definieren.
Auch wenn es etwas ganz einfaches ist.
Wie zum Beispiel gesagt, ich will niemals leere Zeile haben, dann habe ich eine Befehlung
von Klammer auf.
Das kannst du dir relativ leicht in Regex machen.
Und eigentlich kannst du dann auch relativ leicht, indem du in so einer Capture-Drop bestellt hast,
in Regex, das klingt jetzt ein bisschen kompliziert, aber das ist einfach eine Klammer auf und dann
kannst du dir dann auch ein paar Dinge definieren, die du nicht verstanden hast.
Also, ich kann dir jetzt ein paar Dinge definieren, die du nicht verstanden hast.
Und dann kannst du dir dann auch ein paar Dinge definieren, die du nicht verstanden hast.
So, kommen wir zu einem anderen wöchentlichen Punkt. Und zwar hatte ich mir ein Ziel vorgenommen.
Ich weiß nicht, ob ich das jetzt mal erwähnt habe, aber ein Ziel von mir ist auch, dass ich gerade schon erwähnt, dass ich Artikel schreibe.
Und ich versuche jede Woche ein Artikel zu schreiben. Und in der Zeit habe ich das bisher hinbekommen.
Also einfach nur, will einfach nur sagen, dass es bisher gut geht.
Allerdings muss ich auch sagen, dass ich ungefähr einen ganzen Tag brauche, um für ein Artikel zu schreiben.
Also ich versuche es mit was jetzt zu machen, wo ich ja nicht mehr streame. Und in der Regel brauche ich da 6 bis 8 Stunden, bis ich da alle...
Also ich denke mir, okay, ich weiß schon, was ich schreiben will. Ich kann es kurz runterrotzen sozusagen.
Und dann kann ich mir dann auch ein paar Dinge anstellen, so hey, das hier ist der richtige Weg oder das hier wurde dort aus dem und dem Grund gemacht. Und dann will ich aber auch sichergehen, dass es auch stimmt, was ich sage und dann korrigiere ich das. Und dann dauert es am Ende doch ein bisschen länger als gedacht.
Genau, aber ich habe eben zwei Artikel geschrieben, zum Thema Streaming. Also ich habe einen zu meiner Hardware, den ich benutze, einen zu meiner Software.
Falls jemand an Streaming auch interessiert ist, ist glaube ich ein guter Einstieg. Dann einmal dieser Evolution Artikel, den ich schon gerade erwähnt habe.
Und auch schon erwähnt, den Top 3 Lab Lab DC-Wish ist. Das sind die vier Artikel, die ich geschrieben habe.
Und ich suche eben ab jetzt auch weiter jede Woche ein Artikel rauszubringen. Die Hardpoint Media Network, falls jemand es noch nicht kennt, die hat mit J.I.G. Hut.
Der Streaming Artikel ist in zwei Teilen?
Der ist aktuell in zwei Teilen. Also dass es zwei werden, wusste ich schon wegen Hardware Software. Ich habe noch einen Teil zu Settings, also welche Einstellungen ich habe.
Zum Beispiel welche Auflösungen ich benutze, warum und welche Schriftgröße ich in Xcode benutze und so weiter. Aber ich habe noch ein paar Tipps auf Lager, über die ich vielleicht noch schreibe. Es könnte noch 4, 5, 6 Artikel werden.
Ich habe gehört, der Holger hat sich auch sowas bei sich eingebaut. Was mit deinen Hue-Lights.
Genau, ich mache Videospielstreams, immer Dienstags abends zur Zeit. Und manchmal auch so aus der Reihe. Und da kann man über Chatkommandos meine Lampen im Hintergrund hier steuern.
Aber die Software ist sehr sehr teuer dafür und deswegen habe ich nur die Trial Version und deswegen gehen nur 5 Farben.
Hey, immerhin 5 Farben.
Ja, reicht doch.
Ja, reicht doch. Ist halt totaler Spaß.
Ich finde es einfach cool, dass wir Zuschauer, das ist cool an Twitch, weil die Leute live sind. Du kannst dich halt als Teil des Streams führen, wenn du sowas eben machst.
Ja.
Ja, finde ich ganz cool. Jetzt kommen wir aber zu meiner App, habe ich ja schon ein bisschen erwähnt und ich glaube, ich hatte noch nie über meine App gesprochen, nur dass ich an einer arbeite und das ist ein bisschen so die Nachfolge von Bati Crouches.
Und weil ich noch keine finalen Namen habe, also ich habe eine Idee, aber man könnte sie noch ändern, wenn nicht einfach mal Bati Crouch Gui App, weil das nämlich eine grafische Oberfläche von Bati Crouch quasi wird mit ein paar Zusatz-Videos.
Bati Gui.
Bati Gui. Also ich habe schon einen Namen, den will ich auch eigentlich verwenden. Ich muss nur noch ein bisschen Geschäft betreiben, deshalb im nächsten Podcast dann wahrscheinlich einen Mitnamen.
Genau, man sollte auch gucken, dass sowas wie solche Namen, die man sich ausdenkt in manchen anderen Sprachen, nicht irgendeine Beleidigung bedeuten.
Also er hat zum Beispiel Audi mit dem Audi e-tron gemacht und ich glaube irgendwie auf Französisch heißt eigentlich e-tron irgendwie Arschloch, was nicht so gut ist.
Da ist es ein bisschen anders.
Nee leider nicht, französische Kollegen haben gesagt, man sollte mal aufpassen, gerade wenn man so eigenen Namen benutzt, ob die nicht im Ausland irgendwie eine Beleidigung sind.
Genau, jedenfalls habe ich meine App jetzt einen großen wichtigen Meilenstein erreicht.
Das heißt, eine der Hauptfunktionen, die ich da einbauen wollte, ist jetzt quasi verwendbar und ich habe auch einen ersten Test eingeladen, nämlich den Nico.
Und der hat auch schon versucht die App quasi zu testen und dann habe ich direkt einen Pack gefunden.
Den habe ich auch jetzt erst heute Morgen gefixt, das heißt, ich habe noch keine Chance da nochmal rüber zu gucken.
Aber ich freue mich einfach, dass ich diesen wichtigen Meilenstein erreicht habe, weil da war viel technisches, was technische Hürden, die ich da nehmen musste, gerade mit Zertifikaten, mit Xcode Extensions.
Und genau, weil ich so eine grafische Oberfläche für BodyCloud baue und BodyCloud ändert ja Swift Datei, also man hat eine Swift Datei und dann kann man eine Übersetzung da rein machen und dann wird es direkt in die Swift Datei eingesetzt.
Deshalb habe ich da eine sogenannte Xcode Source Editor Extension geschrieben.
Das ist eine besondere Form eines Extensions, die man eben direkt in Xcode im Editor Menü finden kann.
Weil in der Swift Datei geht man nach oben auf Editor und dann findet man meine App dort aufgelistet, direkt in Xcode und kann die eben ausführen.
Und das gibt mir die Möglichkeit, eine Swift Datei zu bearbeiten, ohne die Edit Historie zu verlieren.
Also BodyCloud kann auch schon eine Swift Datei bearbeiten, allerdings passiert es, indem die Datei komplett neu geschrieben wird und dann, wenn man gerade in dieser Swift Datei ist, kann man nicht mehr rückgängig machen. Also Command Z funktioniert dann nicht mehr. Und mit einer Xcode Extensions geht das eben.
Das ist eine der Vorteile, die man abhaben soll.
Genau, da hatte ich aber einige Probleme. Unter anderem war der Bug, den Nico gefunden hat, einfach nur, dass meine Extension dort nicht aufgetaucht ist in Xcode.
Die ist einfach nicht aufgetaucht, obwohl ich alles versucht habe, richtig zu machen. Ich bin allen Anleitungen gefolgt, ich bin auch allen D-Bug-Tipps, allen Apple-Tipps gefolgt und ich habe es einfach nicht hinbekommen.
Auch nach drei Tägigen rumprobieren und wir vermuten jetzt, ich habe auch mit ein paar Leuten aus Twitter geschrieben, die auch schon mit Xcode Extensions was gemacht haben, wir vermuten, dass es einfach an Testflight liegt. Also ich habe Nico über Testflight eingeladen, Testflight ist Apple's App, um Beta-Software an Tester zu schicken und es scheint wohl einfach nicht zu gehen, dass man Xcode Extensions über Testflight anbietet.
Das wäre eigentlich eine gute Frage für so eine WWDC-Session.
Genau, so eine Lab. Also ich wünsche dem jetzt wahr, man sollte nicht immer auf die Lab, die sie warten müssen. Es wäre besser, wenn es irgendwie möglich wäre, das offiziell bestätigt zu machen.
Du kaufst mit deiner jährlichen Mitgliedschaft einmal so einen First-Level-Support, wo du relativ nah an Engineers rankommst, wenn du denen vorbeschreibst, was dein Problem ist. Ich habe einen Bugreport gemacht, aber ich kann das auch mal. Kannst du mal versuchen, kommst du da an jemanden ran?
Ja, das mache ich vielleicht. Also ich habe meine App exportiert, als eine eigenständige App, wie man es außerhalb des Apps anbieten kann. Ich habe die auch notarisiert, das ist eine besondere Zertifizierungsmöglichkeit, was man machen muss, wenn man eine App startet. Das ist nicht so, dass die nicht unsicher ist, das kennt bestimmt jeder schon. Wenn es Nico schickt, habe ich das notarisiert.
Das ist das Ding, dass du Apple beweist, dieses Binary kommt von dir. Und wer das runterlegt, wird es abgeprüft und dann sagt er, es kommt von dem Entwickler, den kennen wir, aber kannst du das aufmachen oder nicht? Wenn die dich nicht kennen würden, dann würden die sagen, du kannst das nicht aufmachen, du musst über dieses Gatekeeper-Ding gehen und trotzdem öffnen.
Genau, dennoch öffnen heißt das dann. Und das wollte ich nicht, auch wenn es eine Kleinigkeit ist, auch wenn es so Tester sind. Und ich habe das tatsächlich schnell hinbekommen, dank Fastlane. Also Fastlane kann man wirklich nur empfehlen. Die haben nämlich auch eine Action, die heißt notarized. Und solange man da seine App Store Connect API Key mit reingibt, ist da eine Anleitung dazu. Und das war jetzt nicht so schwer. Funktioniert das. Und tatsächlich hatte ich die Befürchtung, dass die Notarisierung dann auch von Apple mit abwarten geprüft werden muss oder so. Das ist nicht der Fall, das ist tatsächlich ein automatisches System. Was Fastlane genau macht, weiß ich nicht, aber 3 Sekunden später war es notarisiert.
Fastlane und Quarky immer gut. Fastlane benutze.
So, dann das nächste auch wieder mit Source Editor Extension. Ich glaube da gibt es irgendwie viele Bugs in Xcode, damit zusammenhängt. Mein Xcode ist nämlich so, immer wenn ich ein Bild mache, meine App, die ich entwickle, die Baticorch SCUIA sozusagen, hängt mein Xcode für ca. 15 Sekunden einfach. Ich kann dann keine Datei wechseln, ich kann nichts machen in Xcode. Mein System funktioniert noch, also nur Xcode hängt. Aber es ist trotzdem relativ nervig und ich habe auch da schon ein bisschen umgesucht und herauskam, dass wenn ich meine Xcode Source Editor Extension nicht mehr in meine App verlinke, also wenn ich diese Dependency da entferne, dann ist es nicht mehr der Fall. Das heißt, direkt mit der Editor Extension zusammen, da scheint Xcode einfach nicht viel zu testen.
Ist das nicht vielleicht sogar ein Showstopper? Also dass du sagst, ok, du kannst das Produkt nicht raushauen? Ich würde das vielleicht schon haben, ja, 15 Sekunden. Oder ist das nicht so, wenn ich es benutze, dann ist es nicht so?
Wenn du es benutzt, ist es nicht so. Wenn ich dieses Projekt bilde, die Baticorch SCUIA App bilde, dann hängt das für mich.
Da kann ich nur sagen, Gott sei Dank habe ich meine App komplett modularisiert. Das heißt, ich habe ganz viele kleine Module, die ich unabhängig vom eigentlichen App-Projekt bilden kann.
Das heißt, ich arbeite 90% der Zeit in den kleinen Module und da hängt das nicht, weil da ist die Extension nicht verlinkt. Wenn ich aber meine App bilden will, um dann in der gesamten App mal zu testen, ob alles geht, dann hängt es mal ein bisschen.
Ich habe eine Frage zu den Extensions. Gibt es da gute Tutorials da draußen oder ist das alles schwierig? Ich empfehle da einfach direkt die NSHIPster. Falls ihr NSHIPster nicht kennt, das ist eine Sammlung von richtig guten Tutorials. Da gibt es eine Extrosource Edited Extensions Tutorial. Kann ich nur empfehlen.
Also das ist wirklich gut zusammengefasst, auch was die Limitations sind, weil es gibt viele. Man kann fast nichts machen mit Extrosource Edited Extensions, aber das, was man machen kann, reicht mir schon.
Sehr gut.
So, dann habe ich in den letzten Tagen, nachdem mein großer Meilenstein abgeschlossen war, ein großes Refactoring gemacht von meiner App-Architektur. Und in dem Zusammenhang habe ich mir, weil ich benutze die TCA Architektur, also die The Composable Architecture.
Und da habe ich mir im Detail angehend, das ist wirklich ein komplexes Thema, was wir vielleicht in der Zukunft mal besprechen können. Aber ich benutze eben das, auch von Point3 übrigens. Und da braucht man verschiedene Typen. Das ist wahrscheinlich auch bei Viper und anderen Architekturen wie Airbnb, R.I.B.
Das ist auch nicht anders, aber auch mehrere Dateien für jedes Feature, was man entwickelt sozusagen. Und ich hatte keine Lust, diese Dateien jedes Mal manuell zu schreiben, weil es wirklich viele kleine Sachen immer gleich sind.
Also habe ich mir ein Swift-Script geschrieben, was diese Dateien automatisch für mich erstellt. Und um Swift-Scripten zu schreiben, brauchen wir Swift-SH. Also Swift-SH können wir gerne wieder verlinken. Und dieses Swift-Script da erzeugt mir einfach alle Dateien, die ich eben brauche.
Und dieses Swift-Script nimmt auch eine Parameter an, dass ich den Namen meines Features angeben kann, dass er dann eben in den Dateien die richtigen Namen verwendet überall. Und ich habe hier wirklich alles verlinkt. Ich habe mal meinen Skript, so wie es aktuell aussieht, extrahiert für alle, die vielleicht auch so einen Swift-Script schreiben möchten. Das können wir gerne in den Showmode verlinken, das könnt ihr dann kopieren. Also meine Dateien, die könnt ihr dann natürlich löschen, meine Strings, die ich da drin habe, aber die Anfangsstruktur, die ist glaube ich ganz praktisch, weil das eben dieses Parameter entgegennehmen und auch eine Fehlermeldung zeigen, wenn man sie falsch verwendet und so weiter habe ich schon dort implementiert.
Hättest du das nicht eigentlich auch mit Xcode-Templates machen können?
Vielleicht, ich habe Xcode-Templates einmal verwendet und aus irgendeinem Grund hat es mir nicht gefallen. Ich kann dir aber nicht mehr sagen, wieso. Ja, ich hatte auch mal Xcode-Templates auch mal gebaut. Ich glaube, da bist du hier natürlich flexibler, was das angeht.
Also hier kann ich wirklich alles machen, aber sicherlich könnte man auch ein Xcode-Template machen. Kann man da mehrere Dateien auf einmal stellen lassen?
Ja, doch glaube ich sogar, weil ich das mit C++ gemacht habe, weil mich das mit dem Header-File und Implementation-File schreiben immer genervt hat und dass du da auch so viel Boilerplate hast. Und dann kannst du dir auch C++-Dateien raus generieren. Ich glaube, das geht schon, ja.
Mein Ziel ist mit dieser Generate.Swift, aber theoretisch könnte ich da auch alles andere machen. Ich könnte auch irgendwelche Sachen ersetzen lassen und so weiter. Das ist einfach ein Skript, was ich für mich geschrieben habe. Dann könnte ich alles einbauen, was ich möchte.
Dann ein Teil von diesem Refactoring war auch eben, ich habe schon vorhin erwähnt, ein bisschen Error-Handling habe ich mir einen eigenen Typ geschrieben und ich würde gerne meinen Typ, die Idee, die ich habe kurz erläutern.
Also das Problem, was ich sehe mit Standard-Error-Typen in Swift ist, erstens, dass man, wenn man einen Error-Code dort eingeb, nehme zum Beispiel 9001, ich glaube, das habe ich schon bei Apple gesehen, den Error-Code 9001, wenn ich den jetzt irgendwo als Error rein mache, ich habe irgendwo einen Error, wenn ich eine Strings-Datei lese zum Beispiel.
Wenn ich jetzt sage, ok, Error 9001, ich konnte die Strings-Datei nicht lesen, dann will ich aber am Ende wissen, als Entwickler, wo genau der Call auch stattgefunden hat, der dann eben die Strings-Datei lesen einfach hat.
Ich weiß aber nur, wo der Fehler aufgetrieben ist, ich weiß nicht, von wo der Call kam. Und das ist so ein Problem, was ich mit Error-Handling mit Standard-Codes habe.
Das Zweite ist, dass wenn man mit Error konfrontiert, dann ist es tatsächlich so, wenn man sich dieses Error-Protokoll anschaut, der erwartet eine Error-Description vom Typ String-Optional.
Das heißt, bei Default ist es dann so, wenn man keine Error-Description für seine eigenen Errors, die man sich definieren kann, aber keine angibt, kriegt man keinen Fehler.
Das heißt, viele Entwickler, ich habe das auch schon auf dem Code gesehen, auch in OMSource Tools, definieren sich zum Beispiel eine Enum, sagen ok, das sind alle Error-Fälle, die aufdrehen können, und das war's. Das sind nur die Cases, die die dann auflisten.
Und dann, wenn am Ende der Error auftritt in einer App und die erprinten das mit Error, also Print Error, dann steht am Ende nur, hey, der Typ, also der Typ der Datei, der ist Enums, zum Beispiel String-Parting Error, und dann steht da -1 oder Case 1, Case 2, Case 3.
Da gibt es keine Beschreibung, also der Nutzer, der Nutzer, der am Ende hat keine Ahnung, was eigentlich schiefgelaufen ist.
Und man sollte aber eigentlich diese Error-Description immer anbieten, für alle Fälle, die man da immer hat.
Würde dann aber nicht reichen, dass man einfach sagt, Debug-Description-Convertible, und dass du dann sagst, gibt's eine Debug-Description an, und dann einfach auf Switch Self und dann sagst, ich misse deine Error-Cases und hausse dann natürlich eine vernünftige Debug-Description zu deinem jeweiligen Errorhaus. Also so kenne ich das, dass man das auch machen kann.
Du meinst mit Debug-Descriptions, dass du selber Strings definierst, die dann eben die -
Genau, du schreibst dann in dein Enum noch rein und switchst dann halt auf Self und sagst, gibst du für jeden Error noch an, ok, was könnte der Fehler sein?
Ja, das ist ja die Lösung. Das Problem ist nur, dass du niemals an ein Enum hast, was du uns anbieten solltest, was du uns überschreiben solltest. Ich hab das oft gesehen und wollte mich einfach selbst an einen und -
Also du willst dich eigentlich selber dazu zwingen sozusagen, deine Faulheit, sag ich mal, überwinden und dem durchführen.
Moment ist es einfach nur, der definiert sich für eine Error Description haben. Genauso wie Error. Heißt auch genau gleich. Aber es ist von Typ string und nicht string option.
Das zweite ist, das hat eine ID. Und als ID definiere ich mir meinen Buchstaben und dann kann ich, wenn ich einen Error habe, der zum Beispiel, ich habe ein string parsing error, und der hat einen Case, der nochmal ein anderer Error ist.
Also ich kann ja beim string parsing noch einen untererror haben, von irgendwo anders. Dann kann ich nämlich dessen ID, mit der ID von meinem string parsing error, in diese ID kombinieren und dann kann ich am Ende, wenn ich einen Error sehe, den mir ein Nutzer meldet.
Dann steht da nicht nur Error Code 9001, sondern da steht dann Error, ich benutze den Buchstaben für Error A, B, C. Dann weiß ich, okay, Top Level A und dann 2. Level B, 3. Level C. Und ich gebe meinem Top Level Typ noch meinen extra Namen, dass ich weiß, wo der Einstieg ist. Also ich werde wahrscheinlich noch eine Artikel drüber schreiben, wo ich das mit dem Detail erkläre, aber ich habe mir einfach so einen Helpful Error Typ definiert, der eben einerseits identifiable ist, ich nenne es eben ID, diesen Code, und der eben diese Error Description zu einem richtigen Spring macht. Könnte auch sein, dass ich eine Library am Ende draus mache, dann braucht da niemand groß meine Artikel zu lesen, sondern kann einfach die Library kopieren.
Cool.
Genau, das war Teil des Refactorings. Noch eine Sache mit Refactorings, ich habe schon vorhin erwähnt. Ich habe Linter. Die mag ich sehr und ich habe tatsächlich mehrere Linter aufgesetzt. Also NG Linter habe ich schon vorhin erwähnt.
Aber ich habe auch Swift Format. Das ist ein Linter von Apple. Ganz offiziell. Das ist so nicht so ganz offiziell der Format, den man verwenden soll. Also Apple sagt das noch nicht. Das Ziel ist aber schon langfristig so weit ich richtig gelesen habe im Swift Forum, dass es immer ins Teil von Swift werden soll.
Also es wird dann automatisch mit Swift geschippt und dann kann man es einfach nur scharf schalten und dann linse der den Code und passt praktik in eine bestimmte Struktur. Im Moment ist aber noch ein Library auf GitHub von Apple. Swift Minus Format und da hab ich eben ein paar Regeln mit definiert.
Und das gleiche hab ich auch mit SwiftLint gemacht, ich hab da SwiftLint in mein Projekt aufgesetzt
und bei SwiftLint ist es so, dass es eine DV-Altszeit von Regeln - es gibt über 200 SwiftLint Regeln muss man auch erst mal dazu sagen -
ich hab so rund 50-60 entsprechend eingeschaltet und man kann aber noch ganz viel als sogenannt Opt-in-Regeln noch zusätzlich einschalten.
Und ich hab in meinem Projekt so angefangen, ich hab alles was es Opt-in gibt, hab ich reingemacht und hab Stück für Stück rausgemacht was mir nicht gefallen hat, das einfach nicht meiner Struktur entspricht.
Und so hab ich dann am Ende der SwiftLint konfiguriert.
Und sowohl das als auch Swift Format in meiner App konfiguriert hab ich gedacht hey das will ich auch in meiner Open Source App haben
und dann hab ich in meinem nächsten Stream genau dasselbe was ich in meiner App gemacht hab auch in meinem Open Focus Timer angewandt, das heißt wen es interessiert wie ich das gemacht hab, Swift Format und SwiftLint anzuwenden, das ist auch in einem meiner Streams verlinkt. Genau, könnt ihr auch meinen YouTube Kanal OpenFocusTimerFolge16 könnt ihr es nachschauen. - Verlinken wir. - Genau, das ist so was ich so gemacht hab seit der letzten Folge als nächstes werd ich an der UI weiterarbeiten, ich hab noch einige Konfigurationen, die noch keine UI haben, die muss ich noch bauen für meine App.
Größtenteils die Logo, die ist jetzt fertig wie gesagt mein Meilenstein ist durch.
Dann hab ich vorhin ein Logo design zu lassen, also ich wollte das immer selbst designen, aber ich glaube Profis können das dann doch besser und bevor ich jetzt eine Woche darum interviere und so viel Zeit verliere wieder, ist glaube ich für den ersten Aufschlag macht das denn das sich mal design zu lassen und da hab ich auch letztens eine App gesehen, da wurde verlinkt, dass jemand auf Fiverr da kommt, also wie Fiber mit DoppelR, oder ist es doch Fiber? - So wie 5 Dollar. - Fiverr, ok, Fiverr, ok, fiverr.com sozusagen. - Komische Name. - Und da kann man eben viele Designer finden, die relativ günstig, also ich hab erfahren so circa 30 Euro jetzt praktisch gesehen, nicht 5 Euro wenn man ein bisschen intervieren möchte auch, kann man sich eine App eiken designen lassen und das sieht auch ganz gut aus wenn man die richtige Person findet und das werd ich wahrscheinlich mal ausprobieren.
- Genau das hatte ich auch vorhin mit meinem Logo. - Hab ich gesehen auf Twitter, das fand ich auch lustig, weil ich hatte 3 Tage vorher glaube ich mit Nico auch schon darüber gesprochen, dass ich das auch vorhin hatte.
Ich war mir nicht sicher, ich hab vielleicht Nico mit dir noch mal gesehen, aber unabhängig, lustig, kleines Lieblings.
Genau und mein Ziel ist tatsächlich bis zur nächsten Folge dieses Podcasts meine App in einer Version draußen zu haben, die ich dann auch erwähnen kann, die man vielleicht noch unterlangen kann.
Ob ich dann öffentlich schon veröffentlicht hab oder ob ich dann noch eine Bieter-Version irgendwie auf Test-File bekomme, mal schauen, aber es soll dann benutzbar sein und testbar sein.
Du kannst ja vielleicht hier sogar im Podcast einen Link durchgeben, den man nur hier hören kann, dann kannst du dir mal so einen Vorbieter-Test machen mit den paar, die sag ich mal nicht mit der ganzen Horte da draußen, sondern nur mit ein paar.
Möglicherweise, schauen wir mal wie weit die bis dahin kommen. Das wär's von mir sozusagen, was seit der letzten Folge passiert ist.
Ja sehr, sehr viel auf jeden Fall. Das ist was bei uns mittlerweile passiert und wir machen das monatlich, da kommt da einiges zusammen. Vor allem wir reden ja jetzt noch ein Stück weiter über Swift-Evolution News.
Was hast du denn da noch schönes neues gefunden?
Okay, ich konzentriere mich tatsächlich jetzt auf ein Thema, hauptsächlich damit wir nicht zu viel ausarten und es gibt ja auch meinen Newsletter, wo ihr wenn ihr den Detail gehen wollt folgen könnt.
Und die große Sache, die jetzt aktuell in der Swift-Evolution Community diskutiert wird, sind Regular Expressions. Wir haben es vorhin schon davon und tatsächlich ist es so, dass aktuell an einem riesigen Swift-Overhaul zu Regular Expressions gearbeitet wird.
Und es ist Teil von einem großen String-Processing-Improvement, also alles was mit Strings zu tun hat und was mit Stringverarbeiten zu tun hat, soll in Swift richtig geil werden.
Und Teil davon sind eben so Regular Expressions. Und die Vorgeschichte dazu beginnt mit einer Library-App, die rausgebracht hat vor etwa vier Monaten.
Es nennt sich Swift Experimental String Processing. Da haben sie einfach ganz viel rumgespielt mit verschiedenen Algorithmen, verschiedenen APIs und so weiter.
Und ein bisschen quasi ausgetestet, was so möglich ist. Und daraus sind jetzt sechs ganze Swift-Evolution Proposes geplant, die dann Stück für Stück in die Swift-Sprache reinkommen sollen und die ersten zwei sind aktuell im Review und sollen auch heute, also heute endet der Review-Prozess der ersten zwei.
Das heißt nicht, dass es heute schon beschlossen wird, sondern es kann auch sein, dass es in die Revision geht.
Heute ist Ostermontag für die Leute, die es später...
Genau, heute, 18. April.
2022.
Genau.
Und ich beginne mal mit dem ersten Regular Expression-related Thema und zwar SE-0350, das nennt sich "ReggEx Type and Overview".
Das ist also seine erste Propose, der da gestellt wird und da wird einfach der ReggEx Type, der neue Typ für Regular Expressions, der NS-Regular Expression ersetzen soll, vorgestellt.
Und das heißt einfach "ReggEx" und er akzeptiert einen Generic, der nennt sich "AnyReggEx Output", das heißt, man kann, wenn man ReggEx definiert, gleich sagen, was man als Output erwartet.
Genau, man kann auch gar kein Output erwarten, dann sagt man gar nichts.
Aber im Grunde kann man auch sagen, hey, ich habe eine Regular Expression, die hat drei sogenannte Capture Groups, also Capture Groups sind die Möglichkeit, um in Regular Expression Teile eines Strings aufzusplitten oder einzufangen.
Also ich glaube, eine NS-Regular Expression-Intellation kann ich hier, glaube ich, jetzt nicht geben, in der Kürze, aber alle, die es kennen, müssen wissen, was eine Capture Group ist, auf jeden Fall kann man das jetzt leichter definieren.
Und diese erste Propose handelt einfach nur vom ReggEx-Typen selbst und gibt eine Übersicht, was noch sonst kommen soll, also diese anderen fünf Proposen wären dort auch schon angeschnitten, dass man so ein bisschen einen Überblick bekommt. Und wen es interessiert, wirklich diesen speziellen Propos auf jeden Fall durchzulesen, das ist sehr interessant.
Der zweite Propos, der direkt damit zusammenhängt, ist SE0351, also eine Zahl höher, und nennt sich ReggEx Builder DSL.
Und das ist richtig interessant, weil das ist jetzt quasi eine Möglichkeit, um einen ReggEx zu bauen, wie man in SwiftUI eine View baut.
Also man kann mit dieser Propose, wenn es akzeptiert wird, kann man schreiben "ReggEx" geschrieben auf, so wie man das bei einer SwiftUI View macht, und dann kann man da drin definieren, Stück für Stück, wie das ReggEx quasi strukturiert sein soll, wie die Stringe strukturiert sein soll, die man lesen möchte.
Ach das ist ja geil.
Genau, und dann gibt es da so Möglichkeiten, wie du sagst, okay, ReggEx geschrieben auf, und da drin heißt es Capture geschrieben auf, und dann schreibst du da einfach Punkt hin zum Beispiel, oder in Buchstaben, und dann capturierst du alles, was eben dem matcht.
Und bei ReggEx gibt es eben diese Punkt*, Punkt Plus, und so weiter, das alles braucht man nicht auswendig zu lernen, weil man kann jetzt einfach Typen benutzen wie Zero or More, dann sagt man okay, Null oder mehrere, und dann kann man sagen, welche Zeichen man da erwartet, oder One or More, und so weiter. Das heißt, man kriegt dann am Ende eine Struktur, die aussieht wie in einer SwiftUI View, die so Stück für Stück eingeidentet ist, und kann relativ übersichtlich sehen, wie die Struktur des Strings ist, was man erwartet. Es wird ziemlich leserlich.
Kurze Frage, krieg ich dann auch so ein Output wie mit SwiftUI Previews, dass ich sehe, okay, du hast das, ich kenne, ich kenne es zu Seiten wie reggex.com oder so, wo du da deine ReggEx eingibst und deinen Text, den du dann haben willst, und wo du dann siehst, wie dein ReggEx sich zu dem Textbeispiel, was du hast, verhältst, also so, dass du halt direkt live debuggen kannst und sagst, ah nee, da stimmt noch was nicht, kriegst du dann auch Live Previews?
Also ist ein Proposal nicht erwähnt, so was, weil man könnte sich da vielleicht schreiben, indem man sich einfach in SwiftUI, eh, in View definiert, einfach in der Text, und dann schreibt man in die Preview einfach den Text, den man testen möchte.
Richtig, dann kann man sich auch gleich so wie seit reggex, dann macht der, dann highlightet der ja, okay, das Wort würde ich jetzt gerade dazu, weil wenn man mal reggex halt zum Beispiel aufmacht, ich weiß nicht, reggex hat dort kommen, dann sieht man diese Struktur, ist Klammer Ecke Klammer auf A bis Z halt im Großbuchstaben, und dann dieses Backslash W, der highlightet dir jetzt gerade jedes Capital Word sozusagen im Text.
Ja, Backslash W zum Beispiel, das alle Wörter, also alle Buchstaben und so weiter definiert, das kann man eben Punkt mit Punkt Wörter hinschreiben, das ist dann viel leserlicher.
Genau, das ist nämlich das, was die meisten an reggex läuten, also das ist ja auch da, wo die Leute immer sagen, ja, reggex ist voll die Magie, weil du musst halt erstmal dieses kryptische, was auch immer da steht, verstehen oder auch wissen, was die einzelnen Commands da sozusagen bedeuten und so weiter.
Und ein Vorteil davon ist auch, das ist das gleiche wie bei so viel, man kann jetzt Teile extrahieren, du kannst jetzt sagen, hey, zum Beispiel wenn du ein E-Mail matchen möchtest mit einem reggex, kannst du sagen, hey, das was vorher E-Mail ist, extrahier ich in eine reggex Pattern, das was nach diesem Add ist, extrahier ich in die andere, und dann matche ich das zusammen, also du kannst Stück für Stück extrahieren, und du kannst auch wieder verwenden. Du kannst dann zum Beispiel Domain reggex schreiben, was eben den Teil nach dem Add matchen kann, und du kannst irgendwo anders wo du wieder Domains brauchst wieder verwenden, und das ist echt ganz praktisch.
Genau, es gibt auch eine TriCapture, also es gibt nicht nur Capture, sondern auch ein Type-TriCapture, und es hat hier noch eine Transform, das heißt man kann etwas, was man auffängt, direkt in einen anderen Datentypen umwandeln. Beispiel, du hast irgendwo ein String, wo irgendwo Datum drin steht, und dann sagst du, hey, an dieser Stelle warte ich in Datum, also mach ich keinen Capture, einfach nur gib mir den String von Datum, sondern sagst TriCapture und transform zu einem Date, dann gibst du dir einen Date-Initializer mit, und der macht dir direkt aus einem Date, und am Ende, was du als Capture-Typ bekommst, ist eben ein Date.
Es gibt auch eine Struktur, die nennt sich Choice-Off, da kann man eben mehrere Möglichkeiten machen, dass es eine Äquivalenz zu, bei reggex gibt es diese Klemmen auf, und dann kann man mit so einem langen Strich x oder y oder also dieses Oderstrich, kann man eben mehrere Pfade gehen, und das wird mit Choice-Off gemacht. Wer das in Detail sehen möchte, sollte sich auf jeden Fall den Propos angucken, auf jeden Fall wird sich bei reggex viel vereinfachen und es gibt viel Neuerungen dort auf jeden Fall zu sehen.
Megaspannend, also finde ich cool, das könnte echt was verändern.
Aber das sind jetzt die ersten?
Haben die das nicht auch? Ich meine, die sind ja bestimmt die ersten, die das machen. Haben sie nicht auch so etwas abgeguckt?
Was sie jetzt machen mit der Result-Bilderstruktur, das was wie SwiftUI aussieht, das kenne ich nicht woanders. Dass sie jetzt natürlich für reggex eine besondere Sprachfunktion einbauen, das gibt es natürlich in anderen Sprachen. Ich komme gleich zu einem, was es in anderen zum Beispiel gibt.
Ich würde dich auch nochmal kurz, weil du in DSL gesagt hast, dass Domains-Bizifik-Language, dass da sozusagen eine Sprache gebaut wird, die, was ich mal anders, oder genau so, dasselbe Ergebnis rauskommt, aber eine andere Sprache ist, die mehr auf die Domain sozusagen angepasst ist, oder besser dadurch ist.
Genau, also ich nenne DSL immer zusammengefasst, eine Sprache in einer Sprache.
Genau.
und dann baust du dir innerhalbdessen noch mal eine andere Sprache für eine bestimmte Funktion.
Das sind die ersten zwei Proposes, die ich gerade erwähnt habe.
Es werden wie gesagt noch vier weitergekommen.
Aber nur ein weiteres ist jetzt gerade richtig in der Diskussion.
Denen sich Regex Literals Pitch ist noch in den Swift-Wurms zu finden, das ist noch kein offizieller Proposal.
Und da geht's darum, wie du eine Regex erstellst, ohne Regex-Klammer auf und dann die Pattern anzugeben.
Sondern direkt als Literal, so wie du auch Gänsefischchen schreiben kannst für eine String.
Du schreibst ja auch nicht mal Stringklammer auf, sondern schreibst einfach nur Gänsefischchen um,
und das gleiche ist auch mit Regexes gehen.
Und da inspiriert man sich bei anderen Sprachen wie bei Pearl und bei Ruby und sagt, ok, wenn du eine Slash schreibst und dann eine String und dann mit Slash endest, dann gehen wir davon aus, dass das eine Regex ist und wandeln das eben in Regex. Das ist der aktuelle Vorschlag. Das ist Slash, dann String und Slash. Und da gibt's auch viel Kritik. Das heißt, es kann darauf hinauslaufen, dass es doch irgendwie anders heißt, doch den Attentivvorschlag. Dieses Hashtag Slash, so wie bei Strings, du auch Escaping verhindern kannst, wenn du Hashtag Gänsefischchen machst. Aber wer sich dafür interessiert, einfach die Diskussion auschecken. Das ist auf jeden Fall eine der Sachen, die von anderen Sprachen inspiriert sind und noch kommen könnten.
Genau, dann zum anderen Thema noch kurz zusammengefasst. Also ich überspringe alles andere bei Swift Evolution.
Aber es gibt ein paar kleine Zitalverbesserungen. SE347 nennt sich Type Inference from Default Expressions, ist akzeptiert und verbessert einfach für Parasituationen.
Den Swift Code ist wirklich ein Detailthema. Das gleiche SE0352 implicitly opens existentials. Ist gerade noch im Video, also bis heute bis zum 18. wird wahrscheinlich akzeptiert werden und verbessert auch wieder eine Kleinigkeit in Swift, in die man in seltene Situationen einlaufen könnte. Aber solche Kleinigkeiten summieren sich eben derzeit auf und dann wird Swift für alle besser.
Wer sich mehr interessiert, es gibt noch ein paar Verbesserungen für Low-Level Programming, für Top-Level Concurrency gab's eine Repropose und es gibt auch für Linux-Libraries eine Verbesserung. Kann man alles finden auf apple.github.io/swift-evolution
Genau und wer es noch mal ausführlich hat, definitiv Github abonnieren, dann kann man es noch ganz genau nachvollziehen. Und da sind auch noch mal die Links dazu drin zu den jeweiligen GitHub-Seiten, die man sich dann angucken kann.
Und natürlich auch Beispiele, weil das gerade alles schön veranschaulicht.
Ja, das glaube ich auch, weil die zwei letzten Sachen gerade auch sehr kurz abgehandelt ist, muss man sich dann auch noch mal im Detail selber angucken.
Also vielleicht vergehe ich da gar nicht so im Detail auch ein Newsletter drauf ein, ich muss mir noch angucken, ob das App-Entfitter überhaupt relevant ist, weil ich versuche wirklich nur das, was wirklich relevant ist dort auch zusammenzufassen.
Ich habe immer Angst vor Break-Videore-Expressions.
Also wenn du erstmal diese Struktur siehst, ich glaube, viel mehr Leute werden Regex verwenden und man wird auch gar nicht mehr groß wissen, dass es ein Regex ist oder so.
Ist auf jeden Fall deutlich netter aus.
Genau. Soviel zu Swift Evolution News.
So und was hat, wir wissen ja, es gibt ja Dinge in dieser Folge, die einfach gar nichts mit Professionalität zu tun haben, das sind nämlich unsere Jingles.
Und wir haben ja jetzt schon festgestellt, dass wir ja von unserem zweieröchentlichen Rhythmus, schon jetzt auf den monatlichen Rhythmus gegangen sind, und auch sozusagen kein Framework der Woche mehr haben, sondern haben wir uns jetzt dazu entschieden, wir machen ein Framework der Folge.
Und wir gucken mal, ob wir das schiefe gesingen lassen oder ob wir weiterhin Jihad singen lassen wollen oder ob wir da vielleicht doch noch mal irgendwann ein Jingle draus machen.
Aber ich meine, heute wird das jetzt noch genau so passieren.
Studieren wir jetzt mal ein neues Ding ein. Wie wird es denn heißen? Das Framework der Folge.
Wir überlegen uns dann noch was Besseres, glaube ich.
Nicht zum Namen, aber zum, wie wir das melodisch aufbereiten.
Genau. Jihad, was hast du mitgebracht?
Also ich habe mir ein App rausgesucht tatsächlich. Es ist eine Open-Source-App.
Es nennt sich CodeEdit und das Ganze ist entstanden als Community-Projekt. Und zwar hat jemand namens Austin Condev einfach einen Design-Prototypen entwickelt für einen Code-Editor, der quasi alle anderen Sprachen auch noch unterstützt, die Xcode eben nicht unterstützt, für den Mac als native App.
Der war nämlich genervt von den ganzen Electron-basierten Apps, die sehr viel Memory verbrauchen können, dessen Design mir auch nicht gefallen hat.
Dann habe ich gedacht, hey, es gibt doch die TextEdit-App auf dem Mac und es gibt Xcode, warum mischen wir die nicht und machen quasi eine App, die so einfach ist wie TextEdit, aber eben mehr kann, so wie ein Code-Editor.
Der hat das Ganze CodeEdit auch als Mischung von Xcode und TextEdit genannt und hat das Ganze komplett durchdesigned mit einem kompletten Prototypen und hat einen Twitter-Post gemacht, den wir auch verlinken können am 15.3., also relativ genau einen Monat her.
Ach, das ist doch gar nicht so alt, krass. Genau, das ist erst ein Monat alt, dieses Projekt. Und seitdem haben 13 Leute aus der Community an dieser App mitentwickelt und es hat bereits 7000 Sterne.
Also sehr viele Leute wollten genau so etwas haben. Unter anderem wird es auch gesponsert von fünf Unternehmen. Das ist auch ein bisschen Geld bekommen, das ist jetzt noch nicht so viel, aber ein Projekt, das erst ein Monat alt ist und schon 7000 Sterne hat, ist auf jeden Fall etwas, was man sich am Anfang möchte.
Und ich sehe, der Jihad ist auch schon Contributor.
Ich habe da zwei Ideen geäußert und die hatten noch keine Auswahl, ob du zwei Spaces oder vier Spaces nehmen willst. Uh, da fängt ja gleich wieder wichtiges Diskussion an. Tabs, Tabs, Tabs. Auch Tabs.
Auch Tabs kann man da einbauen. Das coole ist an diesem Projekt, es ist vollständig in Swift geschrieben und es benutzt sogar SwiftUI und das Design ist sehr ähnlich zur Xcode von dem Produkt, was er gemacht hat.
Und das bedeutet, alle App-Entwickler, die mit Swift quasi schon entwickeln, werden sich da relativ schnell reinfinden können. Und wenn ihr jetzt eine neue Option hinzufügen wollt, nämlich ihr wollt Tabs haben statt Spaces, dann könnt ihr relativ einfach an die Einstellung da diese Option hinzufügen und dann im Code-Editor eben diese Option verwenden und schon ist dieses Feature in diesem Editor drin.
Das coole ist, ich habe da eben diese kleinen Hilfestellungen, die ich dazu beigestellt habe, da habe ich dann schon erfahren, dass die wirklich sehr offen sind für die Community, die nehmen relativ schnell Leute auf und die sind sehr, sehr happy bei allen, die mitmachen. Aber der Editor funktioniert auch schon. Es gibt noch keinen Release tatsächlich. Kein offiziellen Bild, der neutralisiert ist und so weiter. Aber man kann das Problemlos auschecken und bauen, das läuft auch problemlos auf dem neuen Xcode und die Grundfunktion eines Editors sind auch schon da. Das heißt, man kann das eigentlich schon verwenden. Das kurze ist, wenn einem irgendwas nicht gefällt, fügt man die Funktion einfach selbst hinzu.
Und das heißt für alle möglichen Sprachen. Also, benutzen Sie eine Bibliothek für Sprachen, die dann zu Zeitleitung machen oder ist das alles selbst implementiert? Weißt du das so?
Wir haben jetzt in einer Library, die heißt highlight.js aktuell, aber ich kann mir gut vorstellen, dass mit der Zeit es ausgetauscht oder ergänzt wird und weiterführt oder vielleicht noch eigene Implementation dazu. Die haben halt versucht am Anfang möglichst schnell ein Ergebnis zu bekommen, deswegen haben die auch für den Editor einen OMSource Tool genommen, für den Editor. Aber es kann langfristig sein, dass komplett alles selbst implementiert wird. Im Moment setzen sie auf highlight.js.
Krass, ich weiß nicht, irgendwie ist es mir auf Twitter wirklich weggekommen, aber ich habe da nie drauf geguckt. Das ist ja eigentlich richtig geil, also das klingt richtig gut.
Das Design ist wirklich sehr ähnlich zu Xcode.
Und das kannst du auch ganz normal Textfiles mit bearbeiten und so weiter. Ich meine, Twitter kann dann auch so Funktionen kriegen, wie sie Sublime Text haben. Wahrscheinlich wird es eine ganze Zeit dauern, bis sie da überhaupt hinkommen.
Ich denke, das ist genau das Ziel, dass du sowas wie Sublime Text, was hier auf dem C oder so geschrieben hast, und was eben auch was kostet, das ist nicht Open Source. Und sowas wie Atom, was ja von GitHub ist, was aber auf Electron basiert, dass du das eben alles ersetzt mit einem Editor, der in die Natur geschrieben ist und der alles kann, was die Community an Features einbaut.
Ja, ich habe als ich das letzte Mal, also ich benutze normalerweise für kleinere Sachen immer TextMate, der ist auch schon sehr alt und immer noch ums Post gegangen. Und letztens habe ich, ich glaube das war für Tele-Twitter, für meine PHP-App, da wollte ich ein bisschen was Professionelles haben, dann habe ich für PHP, glaube ich, Visual Studio Code oder sowas benutzt.
Ja, was auch glaube ich da draußen immer noch, das ist eigentlich alles, das ist, also Visual Studio Code ist auch massiv, also ist auch einfach Powerful ohne Ende, also da kannst du, klar, da hängt auch Microsoft dahinter.
Ja, allerdings muss man, das war schon sehr, sehr alt. Ja, das ist erstens anders, man ist es nicht gewohnt, aber vor allem ist es ja ein richtig feature-rich IDE, ja, wir sind kurz eine wichtige IDE, integriert mit dem Environment, während Code Edit soll tatsächlich wie möglich ein Editor, also auf Editor-Niveau bleiben, das heißt es startet einfach schneller, das ist insgesamt einfach schneller, das ist so für schnelle Bearbeitung glaube ich ganz wichtig.
Ich weiß aber auch, dass es zum Beispiel so bleibt, man hat auch, glaube ich, IDE-Features, da kannst du auch teilweise Sachen drin kompilieren und so weiter.
Ja, bin mir sicher, dass Code Edit das mit der Zeit auch bekommt, weil wenn jemand das will, bauen die es ein, aber ich denke die werden es nur dann einbauen, wenn es die Startzeit zum Beispiel nicht beeinflusst und solche Sachen. Wenn ich Xcode starte, der braucht ein paar Sekunden und Code Edit geht dann schneller.
Xcode macht einfach zu viel auf einmal und Code Edit ist dann einfach so eine kleine Alternative und es ist ein cooles Projekt, wer da zuteilnehmen möchte und sich einfach mal angucken möchte, kann man relativ einfach Sachen beisteiben.
Sehr cool, also ich werde jetzt mal auf jeden Fall angucken und gucke, ob ich damit dann TextMate ersetze für die meisten Sachen. Ich denke mal jetzt im ersten Schritt wirst du es noch nicht damit machen. Nein, am Anfang noch nicht, natürlich, klar, es kann auch sein, dass ich für einfache Texte trotzdem TextMate benutze.
Das ist noch nicht mal im Early Alpha. Es funktioniert durchaus, was zum Beispiel fehlt, es gibt so einen Theming Editor, die Ansätze davon, dass du deine eigenen Farben definieren kannst, aber es gibt noch keinen Standard Theme für Light Mode zum Beispiel.
Wenn du das machst, dann sieht dein Text relativ hell aus und kannst fast nicht lesen. Solche Baustellen gibt es auf jeden Fall noch, aber gerade auch deswegen will ich das hier empfehlen, weil dann die Community noch dazu beitragen kann, dass solche Sachen einfach gefixt werden, dass es möglichst schnell in einen Zustand kommt, wo man das auch schon mal verwenden kann.
Ja, geil. Sehr cool. Dann klappen wir langsam das Tagebuch zu oder? Ja, das ist eine ganz schön lange Folge, wir waren pika paka voll, aber das ist auch gut so.
Natürlich haben wir jetzt auch mehr Content und dann kaufen wir das auch vielleicht mehr Feedback und da haben wir jetzt eine E-Mail für euch, die nennt sich nämlich Feedback@AppStore-Tagebuch.de und da könnt ihr uns Fragen, Wünsche, Anregungen teilanonym stellen. Ihr schreibt einfach rein, wenn ihr nicht genannt werden wollt oder wenn ihr uns beleidigen wollt. Aber ihr dürft auch was Nettes schreiben.
Die E-Mail kommt euch bei uns allen an, je nachdem wer dann schnell das kriegt, von dem kriegt ihr dann eine Antwort. Oder von allen und von gar keinem. Die kommt dann auf Nettigkeit, der E-Mail an dir schreibt.
Ja, und dann könnt ihr uns sagen Hallo, Name und dann wissen wir, wen ihr meint. Und wie immer natürlich der Hinweis darauf, dass wir uns freuen über Bewertungen auf Apple Podcasts oder auf Spotify, weil Bewertungen machen Podcasts sehr glücklich.
Gut, dann fahr ich jetzt mal das Auto ab und bis zum nächsten Mal. Ciao. Bis dann. Ciao.
Das App Store-Tagebuch ist ein Projekt von Nico und Holger. Die Links zu dieser Sendung wie auch den Link zu dem Intro von Luke Hash findet ihr auf AppStore-Tagebuch.de.