Kostenberechnung einer App

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Mal so ganz brutal gesagt:

    Wenn ich nicht in der Lage bin nach einem Pflichtenheft die Zeit die ich für diese Software brauche berechnen zu können, dann habe ich noch nicht die nötigen Kentnisse um meine Arbeit auf dem Markt anzubieten und sollte erstmal noch weiter lernen und eigene Apps schreiben um dieses Wissen zu erlangen.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Mal so ganz brutal gesagt:
    Wenn ich nicht in der Lage bin nach einem Pflichtenheft die Zeit die ich für diese Software brauche berechnen zu können, dann habe ich noch nicht die nötigen Kentnisse um meine Arbeit auf dem Markt anzubieten und sollte erstmal noch weiter lernen und eigene Apps schreiben um dieses Wissen zu erlangen.

    ohne das jetzt auf dem Fragesteller übertragen zu wollen (ich kenne ihn nicht). Ich sehe das etwas differenzierter.
    Es gibt auch Programmierer/Studenten, die Spaß an der Sache habe und kreativ sind. Und so fehlt dann zum Beispiel das Wissen das ganze wirtschaftlich zu kalkulieren. Und wenn sie Pech haben, werden Sie. bis sie sich denn über ihren tatsächlichen Wert bewußt werden entweder ausgenutzt und "verbrannt".

    Somit hat der Fragesteller unter Umständen alles, was ein guter Programmierer benötigt. Er muss jetzt nur noch etwas anderes wissen. Nämlich, wie man eine Kostenkalkulation durchführt, die einem eine wie auch immer gewünschte Existenz ermöglicht und entsprechende Nachfrage findet (und da wären wir dann bei Punkt 3, dem Marketing). Weiter wie ein verrückter Apps schreiben hilft ihm da wenig.

    Nebenbei: Wenn zwei Partner sich finden, um eine Firma zu gründen, gibt es häufig einen der tolle Ideen hat und den anderen, der diese Ideen verkaufen kann.
    Gibt es nur einen davon, muss dieser erst das fehlende Wissen einkaufen oder angeleitet werden. Selten gibt es kreative und sachlich wirtschaftlich denkende.
    (he. war das mit apple nicht genauso?)

    Aber egal. Nur der Vollständigkeit halber, es gibt noch eine Funktionspunkte Berechnung oder Analyse, die fußt auf Erfahrungswerte (Kosten je Funktion, die Tiefe/Details kann man selbst wählen). Problem ist aber die ständige Evaluation der Projekte ohne die man keine Kostenberechnung durchführen kann.
    Plan ist also, das mit jedem Projekt eine genauere Kalkulation möglich ist.

    Ist eigentlich ganz nett, oben wurden ja auch grobe Varianten davon angesprochen (je View, etc.). Aber noch ein weiteres kleines Problem ist da: Jedes Jahr ein neues IOS, wieder 4.000 neue Apis...., also was ich meine: 4000 unbekannte Variablen, also wacklige Datenbasis (da muss dann ein Senior Projekt Manager die Zahlen liefern)

  • Thallius schrieb:

    Mal so ganz brutal gesagt:

    Wenn ich nicht in der Lage bin nach einem Pflichtenheft die Zeit die ich für diese Software brauche berechnen zu können, dann habe ich noch nicht die nötigen Kentnisse um meine Arbeit auf dem Markt anzubieten und sollte erstmal noch weiter lernen und eigene Apps schreiben um dieses Wissen zu erlangen.


    Schöne heile Welt. Leider sieht die Praxis eher so aus, dass es eigentlich so gut wie nie ein Pflichtenheft gibt. Ich weiss schon gar nicht mehr wie ein Pflichtenheft überhaupt noch mal aussieht.

    Wenn man Glück hat, dann bekommt man eine kurze Beschreibung zum Thema der App und evtl. sogar ein Workflow der einzelnen Screens mit einem Interface Design.

    Daraufhin soll man dann bitte eine Schätzung abgeben, mit welchem Aufwand sich die App wohl realisieren lässt.

    Wenn man nicht schon einige Apps realisiert hat, dann halte ich eine Schätzung mit diesem Vorgaben für sehr schwierig.

  • MCDan schrieb:

    Thallius schrieb:

    Mal so ganz brutal gesagt:

    Wenn ich nicht in der Lage bin nach einem Pflichtenheft die Zeit die ich für diese Software brauche berechnen zu können, dann habe ich noch nicht die nötigen Kentnisse um meine Arbeit auf dem Markt anzubieten und sollte erstmal noch weiter lernen und eigene Apps schreiben um dieses Wissen zu erlangen.


    Schöne heile Welt. Leider sieht die Praxis eher so aus, dass es eigentlich so gut wie nie ein Pflichtenheft gibt. Ich weiss schon gar nicht mehr wie ein Pflichtenheft überhaupt noch mal aussieht.

    Wenn man Glück hat, dann bekommt man eine kurze Beschreibung zum Thema der App und evtl. sogar ein Workflow der einzelnen Screens mit einem Interface Design.

    Daraufhin soll man dann bitte eine Schätzung abgeben, mit welchem Aufwand sich die App wohl realisieren lässt.

    Wenn man nicht schon einige Apps realisiert hat, dann halte ich eine Schätzung mit diesem Vorgaben für sehr schwierig.


    Ist aber doch egal ob komplettes Pflichtenheft oder nur eine wage Angabe. Wenn der Kunde noch nicht schriftlich niedergeschrieben hat was eigentlich will, dann ist das für mich ja sogar noch besser. Dann mache ich eine Schätzung nach seinen Angaben und rechne einen Tag drauf für das Erstellen des Pflichtenheftes. Dort schreibe ich dann auf was in meinem Preis alles drin ist und wenn er mehr will muss er später noch nachzahlen. Ohne schriftlich festzulegen was die App genau können muss werde ich kein Projekt anfangen. Das ist ja Harakiri, denn dem Kunden fällt dann immer wieder was neues ein das er gerne noch hätte oder was das er dann doch gerne anders hätte etc. Auf der Basis kann man keine für beide Seiten zufriedenstellende Lösung finden.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    MCDan schrieb:

    Thallius schrieb:

    Mal so ganz brutal gesagt:

    Wenn ich nicht in der Lage bin nach einem Pflichtenheft die Zeit die ich für diese Software brauche berechnen zu können, dann habe ich noch nicht die nötigen Kentnisse um meine Arbeit auf dem Markt anzubieten und sollte erstmal noch weiter lernen und eigene Apps schreiben um dieses Wissen zu erlangen.


    Schöne heile Welt. Leider sieht die Praxis eher so aus, dass es eigentlich so gut wie nie ein Pflichtenheft gibt. Ich weiss schon gar nicht mehr wie ein Pflichtenheft überhaupt noch mal aussieht.

    Wenn man Glück hat, dann bekommt man eine kurze Beschreibung zum Thema der App und evtl. sogar ein Workflow der einzelnen Screens mit einem Interface Design.

    Daraufhin soll man dann bitte eine Schätzung abgeben, mit welchem Aufwand sich die App wohl realisieren lässt.

    Wenn man nicht schon einige Apps realisiert hat, dann halte ich eine Schätzung mit diesem Vorgaben für sehr schwierig.


    Ist aber doch egal ob komplettes Pflichtenheft oder nur eine wage Angabe. Wenn der Kunde noch nicht schriftlich niedergeschrieben hat was eigentlich will, dann ist das für mich ja sogar noch besser. Dann mache ich eine Schätzung nach seinen Angaben und rechne einen Tag drauf für das Erstellen des Pflichtenheftes. Dort schreibe ich dann auf was in meinem Preis alles drin ist und wenn er mehr will muss er später noch nachzahlen. Ohne schriftlich festzulegen was die App genau können muss werde ich kein Projekt anfangen. Das ist ja Harakiri, denn dem Kunden fällt dann immer wieder was neues ein das er gerne noch hätte oder was das er dann doch gerne anders hätte etc. Auf der Basis kann man keine für beide Seiten zufriedenstellende Lösung finden.

    Gruß

    Claus


    Das hast Du vollkommen recht Claus! Das mag in der App-Entwicklung richtig Sinn machen und so konsequent zu sein, finde ich sehr gut!
    Ich mache hauptsächlich Web- /Shopdesign und Plugin-Entwicklung. Da kommt des öfteren mal einer um dei Ecke mit "Mach doch mal schnell". Ja, das ist mein Fehler, da fehlt mir sicher die Konsequenz dabei.
    Ich bin gegen Signaturen!!!

  • brainray2000 schrieb:

    Ich fand kürzlich diesen Kalkulator nicht so schlecht:

    andreasley.ch/en/costcalculator/


    Als Autor dieses Rechners freut es mich ungemein, das zu hören. :)
    Es gibt übrigens auch eine deutschsprachige Variante: andreasley.ch/de/kostenrechner/

    mattik schrieb:

    Mit fehlt die Checkbox für extra Käse.


    Die Kategorie "Klischees" habe ich absichtlich weggelassen. ;)

    mattik schrieb:

    Kurz: Nein.
    Lang: Bestimmt gut gemeint, aber nein.


    Ich bin offen für konstruktive Kritik!

    macmoonshine schrieb:

    Ich habe da mit Punkten verzierte Quader, die wesentlich genauer in der Berechnung sind.


    Link or it didn't happen. ;)
    Nein, natürlich ist der Rechner nicht genau; kann er ja auch gar nicht sein (was du wüsstest, wenn du dir die FAQ-Seite angeschaut hättest). Für technisch ahnungslose Kunden ist es aber zumindest mal ein Anhaltspunkt, und darum ging es mir.

    SteveJ schrieb:

    Könnten wir mal eine Arbeitsprobe sehen?


    Das lässt sich auf jeden Fall arrangieren. 8)
    Der Rechner ist nicht ausschliesslich auf meine Dienstleistungen bezogen und ich nehme auch keine Aufträge an, bei denen Qualität unwichtig ist. Der Punkt ist aber der: Die meisten Kunden verstehen nicht, dass zusätzliche Features bei gleichbleibendem Budget immer einen negativen Einfluss auf die Qualität haben. Mein Ziel mit dem Rechner war, das einigermassen leicht verständlich (und interaktiv) zu erklären.

  • Naja, ich habs mir gerade mal kurz angesehen. Es ist gut für Kunden damit die mal von dieser "Ich kriege ja meine App für 500 Euro" vorstellung wegkommen aber mal ganz im Ernst: Push-Support kostet 5000? Das wäre ja mal einfach rund gerechnet locker 8 Projekttage. Was soll ich in der Zeit dann da alles machen? Oder ein Webview für 2k? DA müßte ich dann 2-4 Tage dran programmieren.... Soviel Kaffee kann ich gar nicht trinken und Zigaretten rauchen um das so lange raus zu zögern.

    Dafür mann ich nicht pauschal 1000 Euro für einen Screen nehmen. Ich hatte mal eine App die hatte 3 absolute Custom-Screens. Da hat alleine das Design 10 Tage gedauert und musste ständig mit dem Auftraggeber abgesprochen werden. Ich hatte auch schon Apps die hatten eine Standard Tabbar mit 5 Tabs und je einem 3 stufigen Navi-Stack, also 15 Screens die ich aber in 1 Tag fertig hatte.

    Es geht nunmal vorne und hinten nicht das man das automatisch ermittelt. Es geht nur über Wissen, Kommunikation und das Können des Entwicklers dieses zu vermitteln. Das lernt man aber aben nicht mal eben auf YouTube. Dazu muss man in der Lage sein sich einen Anzug anzuziehen, souverain auzutreten und rhetorisch gewandt zu sein. Das ist es was dir letztlich das Geld bringt. Nicht Deine Programmier-Kenntnisse sondern wie Du Dich verkaufst. Und das geht nur über Seblstbewußtsein und Erfahrung.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Push-Support kostet 5000? Das wäre ja mal einfach rund gerechnet locker 8 Projekttage. Was soll ich in der Zeit dann da alles machen?


    Der Rechner bezieht sich nicht nur auf die Programmierung:
    • Abklärung (welche Infrastuktur ist bereits vorhanden? mit wem wird die Server-Schnittstelle abgesprochen? etc.)
    • Konzeption (was wird wann wie oft an wen gepusht? ) und festhalten im Pflichtenheft
    • Design der Screens, um Push-Einstellungen in der App zu verwalten
    • Vorbereiten einer Testumgebung und entsprechender Provisioning Profiles und Zertifikaten
    • ggf. Erstellung von Icon(s) und Soundfile(s) für Push-Empfang
    • Umsetzung der Push-Funktionalität in der App
    • Testing auf Staging- und Produktionsumgebung
    • Bugfixing
    • Dokumentation des Codes, der Prozesse, Testprozeduren und -ergebnisse
    • Planung der Erneuerung der Zertifikate
    Sind da 5-8 Tage wirklich zuviel?

    Es ist aber natürlich so: Der Rechner basiert auf meinen persönlichen Erfahrungen an meinem Arbeitsort. Ich fände es sehr spannend, verschiedene "Sets" von Preisen anzubieten, je nach Land/Region. Dafür wäre aber entsprechendes Datenmaterial nötig, das ich (noch?) nicht habe.

    Und natürlich, schlussendlich ist eine automatische Berechnung bei derart komplexen Projekten nie möglich. Aber noch unbefriedigender als eine inakkurate Schätzung ist die Antwort "das kommt darauf an", mit der die meisten Kunden verständlicherweise gar nichts anfangen können.
    Unabhängig davon ist ein kompetentes, professionelles Auftreten natürlich sinnvoll; das versteht sich von selbst.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von a.ley ()

  • a.ley schrieb:

    mattik schrieb:
    Mit fehlt die Checkbox für extra Käse.


    Die Kategorie "Klischees" habe ich absichtlich weggelassen.

    mattik schrieb:
    Kurz: Nein.
    Lang: Bestimmt gut gemeint, aber nein.


    Ich bin offen für konstruktive Kritik!


    Mit dem "gut gemeint" wollte ich sagen, dass ich die Intention nachvollziehen kann, so etwas zu machen: Aufwands- und Kostenschätzung ist ohnehin schwierig, mit wenig Erfahrung und bei neuen Projekten erst recht, und es ist noch einmal schwieriger, das Interessenten zu kommunizieren. Irgend etwas, was einen groben Anhaltspunkt bieten könnte, klingt da schon verlockend.

    Mit dem "Extra Käse" und "aber nein" meinte ich, dass ich glaube, dass so etwas mit konkreten Zahlen grundsätzlich nicht funktionieren kann, weil Softwareentwicklung prinzipiell anders ist als viele andere Dienstleistungen, sich also z.B. von einer Pizzazusammenstellung grundlegend unterscheidet:

    Einerseits weil Softwareentwicklung im Idealfall keine Wiederholungen und Standardfälle kennt, die man händisch bearbeiten müsste. Deren Automatisierung ist ja gerade Gegenstand der Informatik. Die Realität passt zwar nicht immer auf das Ideal, aber tendenziell sind Standardsachen nur ein kleiner Teil der Arbeit - zumindest bei meinen Projekten geht der Hauptteil der Arbeit und Mühe für die projektspezifischen, individuellen Dinge drauf. Und gerade die lassen sich nicht in Standardpreisen greifen. Beispiel Bluetooth: Ich hatte Projekte, in denen ich nach 3 Stunden damit fertig war und welche, bei denen ich Monate damit verbracht habe. Gleiches gilt für 3D. Das ist sehr individuell.

    Der andere Unterschied zur Pizzabestellung ist, dass Kunden am Anfang oft nicht genau wissen, was sie brauchen. Sie kennen ihr Problem oder ihre Idee und haben vielleicht eine Vorstellung davon, wie sie es haben wollen, aber meistens muss da gemeinsam eine Lösung erarbeitet werden, die nicht selten ganz anders aussieht als sie es sich ursprünglich vorgestellt haben - weil die ursprüngliche Lösung nicht funktioniert, weil sie mit den gegebenen Mitteln nicht umsetzbar ist, weil es eine andere, bessere Lösung gibt oder sonstwas. Beratung, gemeinsame Erarbeitung der Anforderungen und Skizzierung der Lösung ist bei mir oft Teil des Projektes oder ein separates Vorprojekt.

    Das Problem dabei: Sobald man dem Kunden eine Zahl genannt hat, ist die dort eingebrannt. Dabei ist es egal, ob man dazu sagt, dass das nur eine grobe erste Schätzung sei. Die Zahl ist drin, auch wenn sich alles drumherum ändert. Das kann sehr kontraproduktiv sein. Daher bin ich grundsätzlich sehr vorsichtig geworden, frühzeitig konkrete Zahlen zu nennen.
    Multigrad - 360°-Produktfotografie für den Mac

  • mattik schrieb:

    ich glaube, dass so etwas mit konkreten Zahlen grundsätzlich nicht funktionieren kann


    Danke für dein Feedback.
    Ich bin völlig deiner Meinung, dass eine verbindliche Berechnung auf diese Weise nicht möglich ist. Ich bin aber nicht davon überzeugt, dass es auch als ersten Anhaltspunkt nicht taugt. Oft habe ich erlebt, dass Kunden mit komplett unrealistischen Vorstellungen zu uns gekommen sind (im extremsten Fall um den Faktor 100 zu tief). Generell sehe ich den Trend, dass der Aufwand für die Erstellung einer professionellen App massiv unterschätzt wird. Ich glaube, dass der Kostenrechner in diesen Situationen helfen kann. Ich habe aber generell sehr darauf geachtet, die Texte so zu formulieren, dass klar ist, dass es sich nur um eine allererste Schätzung handelt. Im FAQ ist zudem festgehalten, dass eine individuelle Beurteilung des Projekts immer notwendig ist.

    Nebenbei: Für meine eigenen Apps stimmen die Zahlen erstaunlich gut. Es würde mich sehr interessieren, um wieviel die Berechnung bei konkreten Projekten von euch abweicht.

    mattik schrieb:

    Sobald man dem Kunden eine Zahl genannt hat, ist die dort eingebrannt.


    Dieses Risiko besteht natürlich - aber nicht nur beim Rechner, sondern generell bei der Softwareentwicklung. Kaum jemand weiss, was ein Change Request ist und weshalb es extra kostet, mitten in der Umsetzung gewisse Funktionen wieder anzupassen. Wenn ein Kunde also tatsächlich nicht in der Lage ist, solche grundlegenden Probleme zu verstehen, ist es dann nicht von Vorteil, das schon vor Projektstart zu wissen?

    Alles in allem: Ja, es ist ein etwas heikles Projekt und die Diskussion zeigt, dass es einen Nerv trifft. Noch überzeugen mich aber die negativen Argumente nicht genug, um die Seite wieder vom Netz zu nehmen.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von a.ley ()

  • Dann mal zur konstruktiven Kritik:

    Mit drei Betriebssystemversionen bekommt man niemals eine Abdeckung von 90% hin. Nicht unter Android.
    Aktuell ist 4.4.3 und die Verbreitung von Systemen unter 4.0 liegt mit Stand vom 4. Juni noch bei über 15%.
    (Deckt die API Level 19 bis 15 ab, also fünf Systemversionen.)

    Die Aussage
    Die Entwicklungsaufwände für die verschiedenen Plattformen sind vergleichbar. Eine Wahl von zwei Plattformen verdoppelt somit den Aufwand.

    halte ich für komplett falsch.
    Diverse Berichte zeigen auf, dass für die Entwicklung auf Android ungefähr die zwei- bis dreifache Entwicklungszeit draufgeht wie für die Entwicklung auf iOS.

    Das liegt unter Anderem in dem beschissenen Updateverhalten der Hardwarehersteller begründet, die in der Hoffnung auf einen höheren Neugeräteverkauf auf die Aktualisierung ihrer alten Geräte verzichten. Und natürlich daran, dass es 'aktuelle' Geräte mit 1200x960 Pixeln bei 640dpi genauso wie 'aktuelle' Geräte mit 800x640 Pixeln auf 160dpi gibt.

    Links or it didn't happen?
    stevecheney.com/why-android-first-is-a-myth/
    techcrunch.com/2014/04/06/the-fallacy-of-android-first/
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Marco Feltmann schrieb:

    Mit drei Betriebssystemversionen bekommt man niemals eine Abdeckung von 90% hin. Nicht unter Android.


    Das stimmt.
    Wobei es bei Android auch schwieriger zu sagen ist, was eine Betriebssystemversion ist und "API Level" sind unbedarften Kunden kein Begriff. Wenigstens fragt heute niemand mehr nach Gingerbread-Kompatibilität...
    Sowieso ist es natürlich falsch, die Enduser einfach auf Versionen aufzuteilen, da je nach App die potentiell interessantesten Nutzer vielleicht in den nicht unterstützten 10% zu finden sind. Ich habe mir diese Fragen auch gestellt und schlussendlich einfach die pragmatischste Variante gewählt, nur eine Versionsauswahl für alle drei Plattformen anzubieten, die halt im Zweifelsfall nicht ganz korrekt ist.

    Ich werde die FAQ entsprechend ergänzen und versuchen, eine bessere Formulierung als diejenige mit den "Versionen" zu finden. Danke!

    Diverse Berichte zeigen auf, dass für die Entwicklung auf Android ungefähr die zwei- bis dreifache Entwicklungszeit draufgeht wie für die Entwicklung auf iOS.


    Ein wesentlicher Grund, dass ich ausschliesslich für iOS entwickle, liegt darin, dass ich mich nicht mit der Fragmentierung und den Vendor-spezifischen "Verbesserungen" herumschlagen will. Das ist ohne Frage ein noch ungelöstes Problem und erhöht den Zeitaufwand.
    Gleichzeitig habe ich aber auch festgestellt, dass Android-Entwickler und -Benutzer weniger hohe Erwartungen haben. Die Qualität und visuelle Attraktivität von Android-Apps liegt im Allgemeinen unter derjenigen von iOS-Apps – aber von den mir bekannten Android-Usern wird das als normal empfunden. Mit einer mässigen App sind im Android-Store noch immer 5 Sterne zu holen. Gleichzeitig gibt es auch unter Android eine aktive Community, viele bestehende Komponenten auf Java-Basis und die Weiterentwicklung des Android Studio macht sichtbare Fortschritte.

    Aber ja, ich bin auch der Meinung, dass, verglichen mit iOS, der Programmier- und Testaufwand für Android höher ist – wenngleich ich Faktor 1.5 für realistischer halte. Der Aufwand für Konzept, Planung und Dokumentation ist ungefähr gleich hoch und für das GUI-Design und Deployment sogar etwas geringer. Alles in allem vielleicht x1.3 und ja, es stört mich, dass ich das nicht berücksichtigt habe. Aber aufgrund der inhärenten Ungenauigkeit des Rechners empfinde ich das als tragbaren Kompromiss zugunsten der Vereinfachung.

    Ich werde mir auch hier überlegen, wie ich das in den FAQ sinnvoll erklären kann.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von a.ley ()

  • Marco Feltmann schrieb:


    Diverse Berichte zeigen auf, dass für die Entwicklung auf Android ungefähr die zwei- bis dreifache Entwicklungszeit draufgeht wie für die Entwicklung auf iOS.

    Das liegt unter Anderem in dem beschissenen Updateverhalten der Hardwarehersteller begründet, die in der Hoffnung auf einen höheren Neugeräteverkauf auf die Aktualisierung ihrer alten Geräte verzichten. Und natürlich daran, dass es 'aktuelle' Geräte mit 1200x960 Pixeln bei 640dpi genauso wie 'aktuelle' Geräte mit 800x640 Pixeln auf 160dpi gibt.


    und das sich das ganze in jedem Android system anders verhalten kann
    zB schon paar mal erlebt das Apps funktionieren und dann das ganze mal auf ein HTC geschoben wo Sense wieder sein ganz eigenes Süppchen kocht usw.
    Ich weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. :saint: