C#, WCF und Microsoft - Zukunftsaussichten/Alternativen?

Artchi

Wenn es schon so weit ist, das MS das SDK von Xamarin für Windows Plattformen nutzen muss, dann zeigt es, dass das Interesse von MS ja noch geringer ist, als von mir angenommen.

Das wäre ja dann wirklich die Kapitulation und eine reine Alibi-Geschichte. Nach dem Motto: "Was habt ihr denn? Da ist doch ein CLR. Aber Geld stecken wir halt nicht mehr rein."

Das finde ich noch erschreckender.

Übrigens, wo ist denn für Xamarin die Desktop-GUI-API? GTK# hängt immer noch auf Vesion 2.x. Das Gtk# 3.x ist irgendwo bei einem Hobby-Entwickler, der keine Zeit für ein Production-Release hat. WPF wird wohl kaum laufen?

Ich finde pers. Mono und Xamarin sehr beeindruckend. Aber es ist leider für Windows kein Ersatz.

Prof84

asc schrieb:

Gibt es irgendeine Alternative zu WCF die mit einer PCL (Portable Class Library) über WPF, WinRT, WP, Xamarin (iOS, MacOS, Android...) hinweg
a) Sinnvoll läuft
b) Zumindest automatische Wrapper generiert, das man händisch nicht jede einzelne Eigenschaft einzeln abrufen muss

Das hat auch mit WCF nicht funktioniert, wenn das die Frage war.

asc

Prof84 schrieb:

asc schrieb:

Gibt es irgendeine Alternative zu WCF die mit einer PCL (Portable Class Library) über WPF, WinRT, WP, Xamarin (iOS, MacOS, Android...) hinweg
a) Sinnvoll läuft
b) Zumindest automatische Wrapper generiert, das man händisch nicht jede einzelne Eigenschaft einzeln abrufen muss

Das hat auch mit WCF nicht funktioniert, wenn das die Frage war.

Sag bitte, in wie fern das nicht hätte funktionieren sollen. Durch die PCLs und den Profilen _vor_ den neuen WP-Profil und vor ASP.Net konnte man mit einer Codebasis für den Servicelayer (Client und Server) alle .Net Technologien von MS und Xamarin erreichen - und das dank "Add Service Reference" auch mit Wrappergenerierung.

asc

Artchi schrieb:

Wo benutzt denn bitte MS Xamarin?

MS steht als Kunde auf der Xamarin-Seite, ich kenne nicht die konkreten Projekte, könnte mir aber vorstellen das die neuen iOS-Anwendungen ggf. dies nutzen. MS schreibt ja nicht nur Anwendungen für Windows.

Artchi schrieb:

MS wird wohl Xamarin nur als User benutzen, um für iOS und Android z.B. Skype zu entwickeln. Mehr eine pragmatische Lösung, als eine Strategie.

Muss man nun eine spezielle Definition für "nutzen" machen, wenn MS Kunde von Xamarin ist, sehe ich zumindest den Begriff als passend an. Ich behaupte nicht das Xamarin die eigenen SDKs ersetzt, wohl aber das MS die Xamarin-SDK auch "benutzt".

asc schrieb:

Nicht nur ich, auch der Rest des Internets (schau mal auf Channel 9, heise usw.) ist sehr enttäuscht, das in Sachen WPF sehr wenig kommt. Ist ja auch kein Wunder, wenn die Strategie von MS eher Modern-UI mittels HTML5 ist.

Ich sehe nicht das HTML5 eine höhere Priorität als .Net von Seiten Microsofts geniest. Dazu gibt es eindeutig zu viele Quellen für die Unterstützung der Modern-UI von .Net.

asc schrieb:

Desktop-Strategie? Da liest man eher in der MSDN (!), das man als C++ler sich mal wxWidgets oder Qt anschauen soll (das Zitat werde ich noch heute Abend raussuchen!).

Wäre schön, aber ich kann das hier sogar glauben, da sie für den Desktop kein UI-Framework mehr aktiv im nativen Bereich weiterentwickeln.

asc schrieb:

.NET 4.0 muß auf Windows 8.x vom Anwender freigeschaltet werden, obwohl es mit ausgeliefert wird. Denn .NET 4.5.1 ist ja Default in Win 8.x.

4.5.1 sollte abwärtskompatibel zu 4.0 sein (nur das 4.5.1 die 4.5er Erweiterungen komplett ersetzt).

Mechanics

Ist etwas Offtopic, aber ich seh ein Problem damit, dass sich hier in dem Bereich alles viel zu schnell verändert. Ich war vier Jahre .NET 2.0 Entwickler, hatte aber in den letzten Jahren kaum noch was damit zu tun. Ich bin absolut nicht up to date. Ich hab mir privat noch so ein bisschen WPF und WCF und Linq angeschaut, aber ich kann der Diskussion hier kaum folgen. Die ganzen MVVM und ORM Frameworks im .NET Bereich sind eh komplett an mir vorbeigegangen. Würde ich jetzt wieder als C# Entwickler anfangen, müsste ich mich selbst fast schon als Anfänger einstufen, obwohl ich vor paar Jahren noch problemlos behauptet hätte, erfahrener .NET Entwickler zu sein. Und jetzt ist nicht mal klar, inwiefern das alles überhaupt weitergeführt wird und evtl. hab ich nichts verpasst, weil das alles in paar Jahren eh irrelevant sein wird. Das finde ich an diesen Microsoft Umgebungen problematisch...

Mechanics schrieb:

Ist etwas Offtopic, aber ich seh ein Problem damit, dass sich hier in dem Bereich alles viel zu schnell verändert.

Das hat nichts mit dem Bereich an sich zu tuen. Schau Dich mal in der Welt um. Es leben noch Menschen die in der Zeit vor dem Computer geboren wurden und so mancher von uns hat sogar noch die Zeit vor dem Internet selbst miterlebt. Wir leben in einer extrem rasanten Epoche des Informationszeitalters und ja, es verändert sich verdammt schnell.

Die Computerwelt ist im Zentrum dieses Prozesses. Es stimmt, wenn Du Dich ein paar Jahre nicht mit einem Thema beschäftigst, dann bist Du raus. Das ist gleichzeitig das Gute und das Schlechte an unserem Beruf. Man muß sich ständig weiterentwickeln. Wer das nicht kann/will der ist absolut falsch hier. Ich machte den Job gerade deswegen weil ich ständig gefordert bin.

Mechanics schrieb:

Die ganzen MVVM und ORM Frameworks im .NET Bereich sind eh komplett an mir vorbeigegangen.

Ich weis, kleinlich, aber MVVM ist ein Design-Pattern und hat primär nichts mit .NET an sich zu tuen. Wie alle Design-Patterns ist es ein Sprachunabhängiges Konzept.

Mechanics schrieb:

Würde ich jetzt wieder als C# Entwickler anfangen, müsste ich mich selbst fast schon als Anfänger einstufen, obwohl ich vor paar Jahren noch problemlos behauptet hätte, erfahrener .NET Entwickler zu sein.

Das stimmt aber ebenso für fast alle andern Sprachen und Entwicklungsumgebungen und ist absolut kein .NET eigenes Problem. Ich habe nach 10 Jahren mal wieder php programmiert und da ist absolut alles Anders...

Dabei solltest Du eines beachten: Theoretisch könntest Du immer noch mit dem Wissenstand von .Net 2.0 arbeiten. Problemlos. Die könntest nach wie vor Windows.Forms benutzen, auf Linq oder EntityFramework verzichten usw. Dein Wissen ist zwar alt, aber immer noch im Rennen. Du würdest halt nur auf eine ganze Reihe sehr guter Neuerungen verzichten. An der Stelle unterschätzt Du die Abwärts-Kompatibilität von .NET. 2.0 ist die Basis, 3.0 und 4.0 sind in erster Linie Erweiterungen, zusätzliche Pakete die Du nutzen kannst, aber nicht musst. Diese haben 2.0 nicht ersetzt, sondern erweitert. Die guten alte System.Collection ist immer noch da, auch wenn man dringend dazu angehalten ist statt dessen System.Collection.Generics zu benutzen.

Mechanics schrieb:

Das finde ich an diesen Microsoft Umgebungen problematisch...

Was hat das mit Microsoft zu tuen? Apple ist kein bischen anders, eher schlimmer. Die verändern ihre APIs und ihr XCode so oft das sie nicht mal die eigenen Tutorials up to date gehalten bekommen. Wenn Du in einer Umgebung/API arbeitest bei der sich seit Jahren nichts verändert hat bist Du wahrscheinlich in einer evolutionären Sackgasse und weißt es nur noch nicht.

Mechanics

loks schrieb:

Das hat nichts mit dem Bereich an sich zu tuen.

Jein. Natürlich entwickelt sich in der IT alles relativ schnell. Ein guter Informatiker/Entwickler sollte aber immer gefragt sein, und nicht nur, wenn er die neuesten Buzz Words und Frameworks kennt, die sich alle paar Jahre ändern. In anderen Bereichen ist die Entwicklung nicht so schnell. Ist bei mir in der Arbeit nicht so schnell. Wir entwickeln in Ruhe unsere Software und da ist es wichtig sich mit der Thematik und der Software auszukennen und nicht jedes halbe Jahr ein neues Framework zu lernen. Würde ich jetzt einen anderen Job als C++ Entwickler suchen, hätte ich jetzt nicht wirklich irgendwelche Probleme damit. Würde ich hingegen wieder einen Job als .NET Entwickler haben wollen, würde der Chef dann schon vergleichen und schauen, dass ein anderer Bewerber im Gegensatz zu mir ja schon die allerneuesten Frameworks kennt und vielleicht auch billiger ist, weil er keine Berufserfahrung hat.

loks schrieb:

Ich weis, kleinlich, aber MVVM ist ein Design-Pattern und hat primär nichts mit .NET an sich zu tuen.

Ich hab ja auch explizit von MVVM Frameworks geschrieben. Mit dem Pattern hab ich kein Problem, als ich mit WPF rumgespielt habe, hab ich sowas noch von Hand implementiert. Mittlerweile gibts da aber schon ein dutzend Frameworks und wenn ich mir die Diskussionen bei mycsharp.de so anschaue, braucht man ohne sich in so einem Framework auszukennen mit WPF gar nicht erst anzufangen.

Mechanics schrieb:

Ein guter Informatiker/Entwickler sollte aber immer gefragt sein, und nicht nur, wenn er die neuesten Buzz Words und Frameworks kennt, die sich alle paar Jahre ändern.

Ja, aber ein guter Informatiker zeichnet sich dadurch aus das er sich schnell und sicher in neueste Frameworks einarbeiten kann. Und längst nicht alles Neue fällt nur unter "BuzzWord". In den letzten Jahren sind da auch einige wirklich gute Neuerungen hinzugekommen. Linq ist eine davon, ich würde heut nicht mehr darauf verzichten wollen. Und in Folge davon das EntityFramework bei dem ich ganz besonders den CodeFirst-Ansazu liebe. Nicht weil es tolle BuzzWords sind, sondern weil es Frameworks sind die meine Produktivität massiv erhöhen weil sie die Banalitäten von mir fernhalten die ich früher noch aufwendig von Hand selbst implementieren musste.

Und um es nicht immer nur auf MS zu beziehen... Ich kann mich noch an die Zeit erinnern wo Java auch nur ein neues, hippes "Buzzword" war. Hmm...

Mechanics schrieb:

Wir entwickeln in Ruhe unsere Software und da ist es wichtig sich mit der Thematik und der Software auszukennen und nicht jedes halbe Jahr ein neues Framework zu lernen.

Das ist natürlich vollkommen korrekt, jedoch darf man auch nicht ins andere Extrem verfallen. Was, wenn es ein neues Framework gäbe das nach einer kurzen Umstellungsphase eure Produktivität und Softwarequalität um 50% erhöhen würde?

Natürlich muß man nicht jeden Trend mitnehmen, aber das bedeutet nicht das man die Trends komplett ignorieren darf.

Mechanics schrieb:

Würde ich jetzt einen anderen Job als C++ Entwickler suchen, hätte ich jetzt nicht wirklich irgendwelche Probleme damit.

Stimmt natürlich, aber selbst da könnte es Dir passieren das man Bewerber vorzieht die bereits sicher in C++11 sind. Bist Du das? Ein Kollege von mir mit gut 15 Jahren Berufserfahrung C++ sucht seit Monaten nen Neuen Job. Bisher hagelt es da nur Absagen. C++ wird noch lange am Markt bleiben, aber wenn man "nur" C++ beherrscht ist das möglicherweise einfach nicht genug.

Mechanics schrieb:

Würde ich hingegen wieder einen Job als .NET Entwickler haben wollen, würde der Chef dann schon vergleichen und schauen, dass ein anderer Bewerber im Gegensatz zu mir ja schon die allerneuesten Frameworks kennt und vielleicht auch billiger ist, weil er keine Berufserfahrung hat.

Und was ist mit dem Entwickler der die gleiche Berufserfahrung hat, aber nicht die letzten Jahre der Entwicklung verpasst sondern mitgenommen hat und daher schlicht qualifizierter ist?

Unser Wissen hat eine extrem kurze Halbwertszeit. Wenn Deine Berufserfahrung egal in welchem (Softwareentwicklungs-)Bereich bereits mehrere Jahre alt ist, dann ist diese weitestgehend wertlos.

Artchi

Ich kann Mechanics und loks Argument unterschreiben. Der Grund ist, das es darauf ankommt, ob man ein neues Projekt startet (auf der grünen Wiese) oder ob man ein altes System warten muß.

Wenn Meschanics einen .NET-Job suchen sollte, muß er Alt-Systeme suchen, denn die werden selten Cutting-Edge-Technik einsetzen, sondern selbst gestrickte Technik. Warum? Weil es den heutigen Kram damals noch nicht gab. Und das was funktioniert und Mannjahre Entwicklung und somit Geld investiert wurde, wird man nicht der neuen Technik wegen ersetzen.

Javas Hibernate ist ein gutes Beispiel. Damals haben wir uns sowas wie Hibernate selbst entwickelt. Zurückblickend eine echt schlechte Lösung. Dann tauchte Hibernate auf. Wir haben natürlich weiter unsere Lösung benutzt. Weil es natürlich trotzdem funktioniert. Und jeder wusste wie es zu bändigen ist.

Neue Systeme wurden aber bei uns dann mit Hibernate umgesetzt. Weil es in der Zwischenzeit viel besser wurde und wir kein Geld mehr in unsere alte Lösung stecken brauchten.

Heute, 14 Jahre später, ist Hibernate unter Java uninteressant. Warum? Weil die Java Plattform selbst heute ein O/R-Mapping-API mitbringt.
Neue Projekte werden dann wohl die Java-eigene Lösung benutzen. Alt-Projekte weiterhin das selbst gestrickte oder das Hibernate... je nach dem.

So ist es auch mit dem MVVM-Framework für .NET.

Übrigens, in C++ das gleiche Spiel. Jeder hat doch damals seinen eigenen Smartpointer. Dann hat man Boost dafür benutzt. Heute sind sowohl die eigenen und Boosts Smartpointer uninteressant... weil heute in der C++-Standard-Lib.

Aber Alt-C++-Systeme werden wohl eher nicht C++ 11 nutzen. Warum auch das bisher funktionierende risikoreich umstellen.

Wer sich nicht mit neuesten Techniken auskennt, kann auf jeden Fall in Alt-Systemen sein Know-How ausspielen. Denn wer z.B. heute von der FH/Uni kommt und "nur" die neuesten Technologien kennt, wird gegen einen alten Haudegen im Nachteil sein, wenn er in einem Alt-System Hand anlegen muß.

Mechanics

loks schrieb:

Ja, aber ein guter Informatiker zeichnet sich dadurch aus das er sich schnell und sicher in neueste Frameworks einarbeiten kann.

Ja, das seh ich schon auch so, da brauchst du jetzt nicht versuchen, mich zu überzeugen

loks schrieb:

Unser Wissen hat eine extrem kurze Halbwertszeit. Wenn Deine Berufserfahrung egal in welchem (Softwareentwicklungs-)Bereich bereits mehrere Jahre alt ist, dann ist diese weitestgehend wertlos.

Das ist eben, was mich stört. Ich will das nicht so sehen. Das macht eigentlich auch keinen Sinn. Das einzige, was eine kurze Halbwertszeit hat, ist das Wissen über konkrete Produkte. Es wird nur vor allem problematisch, wenn das Produkt an sich einen so großen Teil der Arbeit ausmacht. Und das war in der .NET Klitsche, in der ich gearbeitet habe auch tatsächlich so. Wir waren einfach zu klein, große Projekte zu bekommen. Und bei kleinen Projekten macht das Framework natürlich einiges aus. Wenn wir eine Auftragsarbeit für einen ebenfalls kleinen Kunden machen, der maximal 5 Tage Arbeit bezahlen will, und wir einen großen Teil der Arbeit mehr oder weniger umsonst erledigen können, weil wir mit ORM + WPF und Databinding schon 90% erschlagen haben und dann nur noch ein bisschen Business Logik dazu kommt, dann ist es für solche Firmen perfekt. Nur ist es halt keine besonders interessante Arbeit, weil es nur noch darum geht, sein Framework etwas umzukonfigurieren. Da ist keine Berufserfahrung gefragt, sondern wer sich aktuell mit der neuesten Version des Frameworks auskennt.

@Artchi: aber der Smartpointer macht in einem C++ Programm kaum etwas aus. Das ist nur ein technisches Hilfsmittel. In .NET/Java machen die Frameworks aber viel mehr aus, weil man in vielen kleineren Projekten damit schon einen Großteil der Funktionalität erschlagen kann.

Mechanics

Artchi schrieb:

Heute, 14 Jahre später, ist Hibernate unter Java uninteressant. Warum? Weil die Java Plattform selbst heute ein O/R-Mapping-API mitbringt.

Ich seh darin eigentlich auch nur eine Bestätigung meiner Aussage. Hat sich jetzt effektiv so viel geändert? Auch 20 Jahre später reden wir immer noch über ORM. Einer kommt vielleicht frisch von der Uni und kennt nur das Standardframework. Der andere hat früher selber eins geschrieben und versteht deswegen viel besser, wie das alles funktioniert und was es da für Probleme und Lösungsmöglichkeiten gibt. Natürlich wär der auch nur dann ein wertvoller Mitarbeiter, wenn er sich auch die neuen Sachen anschaut und benutzt, wenn sie besser sind und sich nicht querstellt und sagt, brauchen wir alles nicht, hab ich schon vor 20 Jahren alles selber geschrieben.

Prof84

asc schrieb:

Prof84 schrieb:

asc schrieb:

Gibt es irgendeine Alternative zu WCF die mit einer PCL (Portable Class Library) über WPF, WinRT, WP, Xamarin (iOS, MacOS, Android...) hinweg
a) Sinnvoll läuft
b) Zumindest automatische Wrapper generiert, das man händisch nicht jede einzelne Eigenschaft einzeln abrufen muss

Das hat auch mit WCF nicht funktioniert, wenn das die Frage war.

Sag bitte, in wie fern das nicht hätte funktionieren sollen. Durch die PCLs und den Profilen _vor_ den neuen WP-Profil und vor ASP.Net konnte man mit einer Codebasis für den Servicelayer (Client und Server) alle .Net Technologien von MS und Xamarin erreichen - und das dank "Add Service Reference" auch mit Wrappergenerierung.

Es ist ein Trugschluss, dass Du auf jeder Ebene über Libs und Frameworks eine Abstraktion so vornehmen kannst, dass dort jede Plattform läuft!
s. Gödel'sche Unvollständigkeitssätze.

Xamarin ist deshalb nie konfliktfrei gelaufen. Weil die Weiterentwicklung iOS, MacOS, Android... prioritär außerhalb zur MS Umgebung lief. Deshalb konnte WCF nicht so abstrahiert werden, das sie Low-Level-Entwicklungen für Plattform ablösen konnten.

Und deshalb werden noch ganze Völkerstämme von IT-Managern Scheiße schreien, dass sie sich jemals auf Cloud Computering eingelassen haben.

asc

Prof84 schrieb:

Es ist ein Trugschluss, dass Du auf jeder Ebene über Libs und Frameworks eine Abstraktion so vornehmen kannst, dass dort jede Plattform läuft!

Dann frage ich mich warum das schon bei mehreren Frameworks und Sprachen dies erfolgreich praktiziert wurde (u.a. bei Java). Es mag immer mal kleine Probleme geben (ins besondere wenn spezielle Funktionalitäten benötigt werden), möglich ist das Zusammenspiel aber dennoch.

Und wenn der Trend weiterhin bei Xamarin so ist, wie bislang rückt sogar die Möglichkeit in den Fokus zumindest bei den Mobilen Plattform 100% des Codes zu teilen (Mit Xamarin 3 gibt es einen gemeinsamen UI-Wrapper für iOS, Android und Windows Phone).

hustbaer

asc schrieb:

(Mit Xamarin 3 gibt es einen gemeinsamen UI-Wrapper für iOS, Android und Windows Phone).

Jetzt brauchen sie nur noch eine günstige (EDIT: nicht zu schlimm kastrierte /EDIT) Indie-Einsteiger-Lizenz.

Th69

Ich arbeite seit 2 Wochen jetzt auch mit Xamarin.Forms und bin recht zufrieden mit deren Benutzung (und deren Update ist auch super: wenn ich nicht weiterkam mit einem Control und dessen Custom Rendering, gab es ein passendes Update dazu ;-). Es fehlen zwar noch ein paar Controls (z.B. ImageButton oder NumberTextBox o.ä), aber ich bin zuversichtlich, daß das nach und nach reinkommt.

hustbaer schrieb:

asc schrieb:

(Mit Xamarin 3 gibt es einen gemeinsamen UI-Wrapper für iOS, Android und Windows Phone).

Jetzt brauchen sie nur noch eine günstige (EDIT: nicht zu schlimm kastrierte /EDIT) Indie-Einsteiger-Lizenz.

Naja, es gibt eine Indie-Lizenz für $299 pro Jahr. Allerdings auch pro Plattform. $299 wäre ja noch akzeptabel, aber da es ja ohne mehrere Plattformen wenig Sinn ergibt, wäre man sicher schnell bei knapp $900 (für Android, iOS und Windows Phone). Das ist für Indie nicht geeignet und meiner Meinung nach kann man sich dann auch gleich die Business-Lizenz für $999 holen, durch die man sogar die Visual Studio Integration bekommt.

asc

oni schrieb:

...Indie-Lizenz für $299 pro Jahr...pro Plattform. ...meiner Meinung nach kann man sich dann auch gleich die Business-Lizenz für $999 holen, durch die man sogar die Visual Studio Integration bekommt.

Dumm nur das diese ebenso pro Plattform kostet. Sprich man zahlt _pro_ Plattform zusätzliche 700$.

hustbaer

oni schrieb:

Naja, es gibt eine Indie-Lizenz für $299 pro Jahr. Allerdings auch pro Plattform. $299 wäre ja noch akzeptabel, aber da es ja ohne mehrere Plattformen wenig Sinn ergibt, wäre man sicher schnell bei knapp $900 (für Android, iOS und Windows Phone).

$299 pro Jahr pro Mann pro Plattform.

pro Jahr ist OK, weil es sich ja nur auf Updates bezieht (perpetual license).
pro Mann ist auch OK, als Indie ist man ja oft alleine. Und wenn nicht, kann man auch dementsprechend mehr riskieren/investieren.
pro Plattform ist wie du auch selbst schreibst bereits etwas lästig, denn für zumindest zwei Plattformen wird man wohl entwickeln wollen.

Dummerweise ist aber die Indie Lizenz auch noch stark kastriert - Visual Studio Support, WCF und SqlClient wären schon sehr nett. Auf Headless Builds und Email Support könnte ich dagegen vermutlich verzichten.
(Vorausgesetzt mit "Email Support" ist gemeint dass man Dinge per Email fragen kann die man nicht versteht bzw. nicht selbst hinbekommt, und nicht dass man Antworten auf Reports von echten Bugs bekommt.)

Das ist für Indie nicht geeignet und meiner Meinung nach kann man sich dann auch gleich die Business-Lizenz für $999 holen, durch die man sogar die Visual Studio Integration bekommt.

Wieso "gleich"?
Die Business-Lizenz ist genau so pro Jahr pro Mann pro Plattform. Nur halt weniger kastriert.
D.h. statt ~$900 darfst du dann ~$3000 zahlen. *

=> Eine weniger kastrierte Indie-Lizenz wäre wünschenswert. Die dürfte dafür gerne mehr "Bedingungen" haben, wie z.B. ein Revenue-Limit und/oder ein beim Start eingeblendetes Logo/Wasserzeichen.

*: OK, wenn man mehr auf einmal kauft gibt's nen 10% Rabatt. Also sind es "nur" ~$800 bzw. ~$2700

Th69

Mit einem MSDN-Abo die Business-Lizenz sogar für nur $1.399 (für Android und iOS zusammen): https://xamarin.com/MSDN (s. "Special pricing for individuals and teams"). Für einen Indie-Entwickler sicherlich immer noch zu hoch, aber für Firmen rechnet es sich.

Sorry, hatte wohl einen Knick in der Optik xD Dachte die 999 wären für alle Plattformen.