Wie entscheide ich mich zwischen MonoTouch und Objective-C? [geschlossen]

Nachdem wir heute eine Sitzung auf Mono bei einer lokalen .Net-Veranstaltung absolviert hatten, wurde die Verwendung von MonoTouch als Alternative für die iPhone-Entwicklung "angesprochen". Da es sich in C # und .Net sehr wohl fühlt, scheint es eine ansprechende Option zu sein, trotz einiger Eigenheiten des Mono-Stacks. Da MonoTouch jedoch 400 US-Dollar kostet, bin ich etwas hin und her gerissen, wenn dies der richtige Weg für die iPhone-Entwicklung ist.

Hat jemand Erfahrung mit der Entwicklung mit MonoTouch und Objective-C, und wenn ja, ist die Entwicklung mit MonoTouch viel einfacher und schneller als das Erlernen von Objective-C und im Gegenzug die 400 US-Dollar wert?

Ich habe diese Frage (und Variationen davon) in letzter Zeit oft gesehen. Was mich erstaunt ist, wie oft Menschen antworten, aber wie wenige antworten .

Ich habe meine Vorlieben (ich mag beide Stapel), aber hier beginnen die meisten "Antworten" falsch zu laufen. Es sollte nicht darum gehen, was ich will (oder was jemand anderes will).

So würde ich den Wert von MonoTouch bestimmen - ich kann natürlich nicht objektiv sein, aber ich denke, das ist ziemlich eifrig:

• Ist das zum Spaß oder geschäftlich? Wenn Sie sich in diesem Bereich beraten lassen möchten, können Sie Ihre 399 US-Dollar sehr schnell zurückerhalten.

• Möchten Sie die Plattform von innen nach außen lernen oder möchten Sie "nur" Apps dafür schreiben?

• Gefällt dir .Net genug, dass die Verwendung eines anderen Entwickler-Stacks dir den Spaß nehmen würde? Auch hier mag ich beide Stacks (Apple und Mono), aber für mich macht MonoTouch die Erfahrung so viel mehr Spaß. Ich habe nicht aufgehört, Apples Tools zu verwenden, aber das liegt hauptsächlich daran, dass ich beide Stacks wirklich mag . Ich liebe das iPhone und ich liebe .Net. In diesem Fall war MonoTouch für mich ein Kinderspiel.

• Fühlen Sie sich wohl bei der Arbeit mit C? Ich meine nicht Objective-C, sondern C - es ist wichtig, weil Objective-C C ist . Es ist eine nette, schicke, freundliche OO-Version, aber wenn Zeiger Ihnen die heebie-jeebies geben, ist MonoTouch Ihr Freund. Und hören Sie nicht auf die Neinsager, die denken, Sie sind ein Entwickler, wenn es passiert, dass Sie keine Zeiger (oder C usw.) mögen. Früher bin ich mit einer Kopie der IBM ROM BIOS Pocket Reference herumgelaufen, und als ich Assembler schrieb und meinen Computer in lustige Videomodi zwang und meine eigenen Schriftwiedergabebits für sie und (zugegebenermaßen trashige) Fenstersysteme schrieb, tat ich das nicht. Ich glaube nicht, dass die QuickBasic-Entwickler Trottel waren. Ich warein QuickBasic-Entwickler (zusätzlich zu den anderen). Gib niemals dem Nerd-Machismo nach. Wenn Sie C nicht mögen und wenn Sie keine Zeiger mögen und wenn Sie sich so weit wie möglich von der manuellen Speicherverwaltung entfernen möchten (und um fair zu sein, ist es in ObjC überhaupt nicht schlecht), dann. .. MonoTouch. Und nimm keinen Scherz dafür.

• Möchten Sie Benutzer oder Unternehmen ansprechen? Es ist mir nicht wichtig, aber es gibt immer noch Leute auf Edge, und Tatsache ist: Sie können ein weitaus kleineres Download-Paket erstellen, wenn Sie den Apple-Stack verwenden. Ich habe mit MonoTouch herumgespielt und es gibt eine anständige kleine App, die nach dem Komprimieren auf etwa 2,7 MB reduziert wird (wenn Sie Ihre App zur Verteilung einreichen, komprimieren Sie sie - wenn Apps aus dem Store heruntergeladen werden, werden sie ' re zipped - Wenn Sie also herausfinden, ob Ihre App unter das 10-MB-OTA-Limit fällt, zippen Sie zuerst den Sauger - Sie werden von MonoTouch angenehm überrascht sein. Abgesehen von MT-Glück ist eine halbe Megabyte gegenüber fast drei (zum Beispiel) etwas, das für Sie wichtig sein könnte, wenn Sie Endbenutzer ansprechen. Wenn Sie an Unternehmensarbeit denken, spielen ein paar MB überhaupt keine Rolle. Und, Nur um klar zu sein - ich werde demnächst eine MT-basierte App im Store einreichen, und ich habe keinerlei Probleme mit der Größe. Stört mich überhaupt nicht. Aber wenn das etwas ist, das Sie betreffen würdeSie , dann gewinnt Apples Stack diesen.

• Arbeiten Sie mit XML? MonoTouch. Zeitraum.

• String-Manipulation? Datumsmanipulation? Eine Million anderer kleiner Dinge, an die wir uns mit .Nets Rahmen für alles und die Küchenspüle gewöhnt haben? MonoTouch.

• Internetdienste? MonoTouch.

• Syntaktisch haben beide ihre Vorteile. Objective-C ist in der Regel ausführlicher, wenn Sie es schreiben müssen . Sie werden feststellen, dass Sie Code mit C # schreiben, den Sie nicht mit ObjC schreiben müssten, aber es geht in beide Richtungen. Dieses spezielle Thema könnte ein Buch füllen. Ich bevorzuge die C # -Syntax, aber nachdem ich meine anfängliche Reaktion auf Objective-C überwunden habe, habe ich gelernt, sie ziemlich zu genießen. Ich mache mich in Gesprächen ein bisschen darüber lustig (es ist komisch für Entwickler, die an C # / Java / etc. Gewohnt sind), aber die Wahrheit ist, dass ich einen objektiv-C-förmigen Fleck in meinem Herzen habe, der mich glücklich macht.

• Planen Sie Interface Builder zu verwenden? Denn selbst in dieser frühen Version mache ich viel weniger Arbeit, um meine Benutzeroberflächen mit IB zu erstellen und sie dann im Code zu verwenden. Es fühlt sich so an, als ob in der Objective-C / IB-Vorgehensweise ganze Schritte fehlen, und ich bin mir ziemlich sicher, dass ganze Schritte in der Objective-C / IB-Vorgehensweise fehlen. Bisher und ich glaube nicht, dass ich ausreichend getestet habe, aber bisher ist MonoTouch hier der Gewinner dafür, wie viel weniger Arbeit Sie erledigen müssen.

• Denkst du, es macht Spaß, neue Sprachen und Plattformen zu lernen? Wenn ja, hat das iPhone viel zu bieten, und Apples Stack wird Sie wahrscheinlich aus Ihrer Komfortzone bringen - was für einige Entwickler Spaß macht (Hallo - ich bin einer dieser Entwickler - ich scherze darüber und gebe Apple hat es schwer, aber ich hatte viel Spaß beim Erlernen der iPhone-Entwicklung mit Apples Tools.

Es gibt so viele Dinge zu beachten. Wert ist so abstrakt. Wenn wir über die Kosten sprechen und ob es sich lohnt, kommt die Antwort auf meinen ersten Punkt: Wenn dies geschäftlich ist und Sie die Arbeit bekommen können, werden Sie Ihr Geld sofort zurückverdienen.

Also ... das ist ungefähr so ​​objektiv wie ich sein kann. Dies ist eine kurze Liste dessen, was Sie sich fragen könnten, aber es ist ein Ausgangspunkt.

Persönlich (lassen Sie uns die Objektivität für einen Moment fallen), ich liebe und benutze beide. Und ich bin froh, dass ich zuerst den Apple-Stack gelernt habe. Es war für mich einfacher, mit MonoTouch zu arbeiten, als ich mich bereits in der Welt von Apple auskannte. Wie andere gesagt haben, werden Sie immer noch mit CocoaTouch arbeiten - es wird nur in einer .NET-Umgebung sein.

Aber es gibt noch mehr. Die Leute, die MonoTouch nicht benutzt haben, neigen dazu, hier anzuhalten - "Es ist ein Wrapper bla bla bla" - das ist nicht MonoTouch.

Mit MonoTouch haben Sie Zugriff auf das, was CocoaTouch zu bieten hat, und gleichzeitig auf das, was (eine Teilmenge von) .Net zu bieten hat. Eine IDE, mit der sich einige Leute wohler fühlen (ich bin einer von ihnen), und eine bessere Integration in Interface Builder und obwohl Sie die Speicherverwaltung nicht völlig vergessen, haben Sie ein gutes Maß an Spielraum.

Wenn Sie sich nicht sicher sind, greifen Sie zu Apples Stack (kostenlos) und zum MonoTouch-Evaluierungsstapel (kostenlos). Bis Sie sich Apples Entwicklungsprogramm anschließen, laufen beide nur gegen den Simulator. Dies reicht jedoch aus, um herauszufinden, ob Sie das eine dem anderen vorziehen und ob MonoTouch für Sie die 399 US-Dollar wert ist.

Und hör nicht auf die Eiferer - sie sind in der Regel diejenigen, die die Technologie, gegen die sie schimpfen, nicht benutzt haben :)

In diesem Beitrag gibt es viel Hörensagen von Entwicklern, die MonoTouch und Objective-C noch nicht ausprobiert haben . Es scheinen hauptsächlich Objective-C-Entwickler zu sein, die MonoTouch noch nie ausprobiert haben.

Ich bin offensichtlich voreingenommen, aber Sie können nachlesen, was die MonoTouch-Community vorhat:

http://xamarin.com

Dort finden Sie mehrere Artikel von Entwicklern, die sowohl in Objective-C als auch in C # entwickelt wurden.

Meine Antwort auf eine frühere ähnliche Frage lautet also, Objective-C zu lernen. (Vergessen Sie auch nicht die Debugging-Unterstützung)

Dies wird wahrscheinlich einige beleidigen, aber um ehrlich zu sein, wenn Sie ernsthafte Entwicklungen durchführen wollen, sollten Sie Objective-C lernen. Wenn Sie Objective-C in der iPhone-Entwicklung nicht kennen, ist dies nur ein Hindernis. Sie werden nicht viele Beispiele verstehen können; Sie müssen sich mit den Macken von Mono auseinandersetzen, während Sie, wenn Sie über Kenntnisse in Objective-C verfügen, viel mehr aus der Plattformdokumentation herausholen können.

Persönlich verstehe ich die Position nicht, die besagt, dass Sie die Menge an Informationen erhöhen müssen, die Sie für die Verwendung von Mono gegenüber der Muttersprache der Plattform benötigen. Es scheint mir etwas kontraproduktiv. Ich denke, wenn dies eine sehr teure Angelegenheit ist (Lernen einer neuen Sprache), kann es sich lohnen, einige Zeit mit grundlegenden Programmierkonzepten zu verbringen, damit das Erlernen neuer Sprachen eine ziemlich billige Angelegenheit ist.

Ein anderer Benutzer schrieb auch Folgendes:

Monotouch ist jetzt einfacher für Sie. Aber später schwieriger.

Was passiert zum Beispiel, wenn neue Samen herauskommen, gegen die Sie MonoTouch testen, aber aus irgendeinem Grund brechen müssen?

Wenn Sie bei Mono bleiben, müssen Sie jedes Mal, wenn Sie nach Ressourcen für Frameworks suchen, mental übersetzen, wie Sie sie mit Mono verwenden werden. Ihre App-Binärdateien werden größer, Ihre Entwicklungszeit nach einigen Monaten in Objective-C nicht viel schneller, und andere App-Entwickler haben einen viel größeren Vorteil gegenüber Ihnen, da sie die native Plattform verwenden.

Eine weitere Überlegung ist, dass Sie C # verwenden möchten, da Sie mit der Sprache besser vertraut sind als Objective-C. Die überwiegende Mehrheit der Lernkurve für das iPhone ist jedoch nicht Objective-C, sondern die Frameworks, auf die Sie auch mit C # zugreifen müssen.

Für jede Plattform sollten Sie die Plattform verwenden, die die Designphilosophie dieser Plattform direkt zum Ausdruck bringt - auf dem iPhone ist dies Objective-C. Wenn ein Linux-Entwickler, der an das Programmieren in GTK gewöhnt war, Windows-Apps schreiben wollte, würden Sie ernsthaft empfehlen, C # nicht zu verwenden und sich an GTK zu halten, weil dies für ihn "einfacher" war?

Die Verwendung von Mono ist keine Krücke. Es gibt viele Dinge, die es zum iPhone OS hinzufügt. LINQ, WCF, gemeinsam nutzbarer Code zwischen einer Silverlight-App, einer ASP.NET-Seite, einer WPF-App, einer Windows Form-App sowie Mono für Android und auch für Windows Mobile.

Sie können also eine Menge Zeit damit verbringen, Objective-C zu schreiben (Sie werden aus vielen Studien ersehen, in denen genau der gleiche Beispielcode in C # deutlich weniger zu schreiben ist als in OC) und dann alles für andere Plattformen DUPLIZIEREN. Für mich habe ich mich für MonoTouch entschieden, weil die Cloud-App, die ich schreibe, viele Schnittstellen hat, von denen das iPhone nur eine ist. Das Streaming von WCF-Daten aus der Cloud zur MonoTouch-App ist wahnsinnig einfach. Ich habe Kernbibliotheken, die von den verschiedenen Plattformen gemeinsam genutzt werden, und muss dann nur noch eine einfache Präsentationsebene für die Bereitstellungen für iPhone / WinMobile / Android / SilverLight / WPF / ASP.NET schreiben. Es wäre enorm, alles in Objective-C neu zu erstellen Zeitverschwendung sowohl für die anfängliche Entwicklung als auch für die Wartung, da das Produkt weiterentwickelt wird, da alle Funktionen repliziert und nicht wiederverwendet werden müssten.

Den Leuten, die MonoTouch beleidigen oder unterstellen, dass Benutzer eine Krücke benötigen, fehlt das Gesamtbild dessen, was es bedeutet, das .NET-Framework zur Hand zu haben, und sie verstehen möglicherweise nicht die richtige Trennung von Logik und Präsentation auf diese Weise kann plattform- und geräteübergreifend wiederverwendet werden.

Objective-C ist interessant und unterscheidet sich stark von vielen gängigen Sprachen. Ich mag eine Herausforderung und lerne verschiedene Ansätze ... aber nicht, wenn dies meinen Fortschritt behindert oder unnötige Neucodierungen verursacht. Es gibt einige wirklich großartige Dinge am iPhone SDK-Framework, aber all diese Größe wird von MonoTouch vollständig unterstützt und reduziert die manuelle Speicherverwaltung, reduziert die Menge an Code, die für die Ausführung derselben Aufgaben erforderlich ist, ermöglicht mir die Wiederverwendung meiner Assemblys und hält meine Optionen offen, um auf andere Geräte und Plattformen wechseln zu können.

Ich wechselte. Mit Monotouch kann ich Apps mindestens 3-4 Mal so schnell schreiben (4 Apps pro Monat im Vergleich zu meiner alten 1 pro Monat in Obj C).

Viel weniger tippen.

Nur meine Erfahrung.

Wenn dies die einzige iPhone-App ist, die Sie jemals entwickeln werden, und Sie auch kein Interesse daran haben, Mac-Anwendungen zu entwickeln, dann ist MonoTouch wahrscheinlich die Kosten wert.

Wenn Sie glauben, dass Sie jemals mehr iPhone-Apps entwickeln werden oder jemals eine native Mac-Entwicklung durchführen möchten, lohnt es sich wahrscheinlich, Objective-C und die damit verbundenen Frameworks zu lernen. Wenn Sie ein Programmierer sind, der gerne neue Dinge lernt, ist das Lernen ein unterhaltsames neues Paradigma.

Persönlich denke ich, dass Sie eine bessere Zeit haben werden, wenn Sie nur Objective-C lernen.

Zusamenfassend:

• "Learning Objective-C" ist nicht entmutigend, wie Sie vielleicht denken, Sie können es sogar schon nach den ersten Wochen genießen
• Sie kennen die Syntax "C-Stil" bereits mit vielen * & () {}; überall
• Apple hat die Dinge sehr gut dokumentiert
• Sie interagieren mit dem iPhone so, wie Apple es beabsichtigt hat, was bedeutet, dass Sie die Vorteile direkt von der Quelle erhalten, nicht durch einen Filter.

Ich habe festgestellt, dass Projekte wie Unity und MonoTouch "Zeit sparen" sollen, aber letztendlich müssen Sie ihre domänenspezifische Sprache trotzdem lernen und müssen manchmal die Dinge umgehen. All das wird wahrscheinlich genauso lange dauern, bis Sie die Sprache gelernt haben, die Sie vermeiden wollten (in der Kalenderzeit). Am Ende haben Sie keine Zeit gespart und sind eng mit einem Produkt verbunden.

EDIT: Ich wollte nie etwas Negatives über .NET implizieren. Ich bin zufällig ein großer Fan davon. Mein Punkt ist, dass das Hinzufügen weiterer Komplexitätsebenen, nur weil Sie mit der skurrilen objc-Klammer-Notation noch nicht vertraut sind, für mich nicht wirklich sinnvoll ist.

Update 2019: Es ist 7 Jahre später. Mir geht es immer noch genauso, wenn nicht mehr. Sicher, "domänenspezifische Sprache" war möglicherweise der falsche Begriff, aber ich glaube immer noch, dass es viel besser ist, direkt für die Plattform zu schreiben, mit der Sie arbeiten, und Kompatibilitätsebenen und Abstraktionen so weit wie möglich zu vermeiden. Wenn Sie sich Sorgen über die Wiederverwendung und Nachbearbeitung von Code machen, können im Allgemeinen alle Funktionen, die Ihre plattformübergreifende App ausführen muss, wahrscheinlich mit modernen Webtechnologien ausgeführt werden.

Um zu dem hinzuzufügen, was andere bereits gesagt haben (na ja!): Ich habe das Gefühl, dass Sie die Anzahl der Fehler, über die Sie sich Sorgen machen müssen, im Grunde verdoppeln, indem Sie die in MonoTouch zu den bereits in iPhone OS hinzugefügten hinzufügen. Das Aktualisieren für neue Betriebssystemversionen ist noch schmerzhafter als normal. Yuck, überall.

Der einzige überzeugende Fall, den ich für MonoTouch sehen kann, sind Organisationen, in denen viele, viele C # -Programmierer und C # -Code herumliegen, die sie benötigen auf dem iPhone nutzen. (Die Art von Laden, der bei $ 3500 nicht einmal blinkt.)

Aber für jeden, der von vorne anfängt, kann ich es wirklich nicht als lohnenswert oder weise ansehen.

Drei Wörter: Linq to SQL

Ja, es ist das Geld wert.

Etwas, das ich hinzufügen möchte, obwohl es eine akzeptierte Antwort gibt - wer soll sagen, dass Apple nicht einfach Apps ablehnt, die Anzeichen dafür haben, dass sie mit Mono Touch erstellt wurden?

Ich würde die Zeit in Objective-C investieren, hauptsächlich wegen all der Hilfe, die Sie von solchen Websites erhalten können. Eine der Stärken von Objective-C ist, dass Sie C- und C ++ - Code verwenden können, und es gibt viele Projekte, die gut getestet sind .

Eine andere Sache ist, dass Ihr Code (Sprache der Wahl) von Apple unterstützt wird. Womit entfernt iOS 5.x beispielsweise die Unterstützung für eine Drittanbieterlösung wie MonoTouch? Was sagen Sie dann Ihren Kunden?

Vielleicht ist es besser, eine plattformunabhängige Lösung wie HTML5 zu verwenden, wenn Sie nicht vollständig bereit sind, auf Objective-C umzusteigen?

Ich benutze MonoTouch seit einigen Monaten und habe meine halbfertige App von ObjectiveC portiert, damit ich irgendwann in der Zukunft Android unterstützen kann.

Hier ist meine Erfahrung:

Schlechte Teile:

• Xamarin Studio. Indie-Entwickler wie ich sind gezwungen, Xamarin Studio zu verwenden. Es wird von Woche zu Woche besser, die Entwickler sind sehr aktiv in den Foren, um Fehler zu identifizieren und zu beheben, aber es ist immer noch sehr langsam, hängt häufig, hat viele Fehler und das Debuggen ist auch ziemlich langsam.

• Bauzeiten. Das Erstellen meiner großen (verknüpften) App zum Debuggen auf einem Gerät kann einige Minuten dauern. Dies wird mit XCode verglichen, das fast sofort bereitgestellt wird. Das Erstellen für den Simulator (nicht verknüpft) ist etwas schneller.

• MonoTouch-Probleme. Ich habe Probleme mit Speicherverlusten, die durch die Ereignisbehandlung verursacht wurden, und musste einige ziemlich hässliche Problemumgehungen vornehmen, um die Lecks zu verhindern, z. B. das Anhängen und Trennen von Ereignissen beim Eingeben und Verlassen von Ansichten. Die Xamarin-Entwickler beschäftigen sich aktiv mit solchen Problemen.

• Bibliotheken von Drittanbietern. Ich habe eine ganze Weile damit verbracht, ObjectiveC-Bibliotheken für die Verwendung in meiner App zu konvertieren / zu binden, obwohl dies mit automatisierter Software wie Objective Sharpie immer besser wird.

• Größere Binärdateien. Das stört mich nicht wirklich, aber ich dachte, ich würde es erwähnen. IMO ein paar extra Mb ist heutzutage nichts mehr.

Gute Teile:

• Multi-Plattform. Mein Freund erstellt gerne eine Android-Version meiner App aus meiner Kerncodebasis. Wir entwickeln sie parallel und legen ein Remote-Git-Repository auf Dropbox fest. Es läuft gut.

• .Netz. Das Arbeiten in C # .Net ist viel schöner als Objective C IMO.

• MonoTouch. So ziemlich alles in iOS ist in .Net gespiegelt und es ist ziemlich einfach, die Dinge zum Laufen zu bringen.

• Xamarin. Sie können sehen, dass diese Leute wirklich daran arbeiten, alles zu verbessern und die Entwicklung reibungsloser und einfacher zu gestalten.

Ich empfehle Xamarin auf jeden Fall für die plattformübergreifende Entwicklung, insbesondere wenn Sie das Geld haben, um die Business- oder Enterprise-Editionen zu verwenden, die mit Visual Studio funktionieren.

Wenn Sie ausschließlich eine iPhone-App erstellen, die auf einer anderen Plattform niemals benötigt wird, und Indie-Entwickler sind, bleibe ich vorerst bei XCode und Objective C.

Als jemand mit Erfahrung sowohl mit C # als auch mit Objective-C würde ich sagen, dass Xamarin für die meisten Menschen das Geld wert sein wird.

C # ist eine wirklich gut gestaltete Sprache und die C # -APIs sind ebenfalls gut gestaltet. Natürlich haben auch die Cocoa Touch-APIs (einschließlich UIKit) ein großartiges Design, aber die Sprache könnte auf verschiedene Weise verbessert werden. Wenn Sie in C # schreiben, sind Sie wahrscheinlich produktiver als wenn Sie denselben Code in Objective-C schreiben. Dies hat mehrere Gründe, aber einige Gründe wären:

• C # hat Typinferenz . Die Typinferenz beschleunigt das Schreiben von Code, da Sie den Typ auf der linken Seite einer Zuweisung nicht "kennen" müssen. Es macht auch das Refactoring einfacher und spart mehr.

• C # verfügt über Generika , die Fehler im Vergleich zu gleichwertigem Objective-C-Code reduzieren (obwohl es in Objective-C einige Problemumgehungen gibt, werden Entwickler diese in den meisten Situationen vermeiden).

• Kürzlich hat Xamarin Unterstützung für Async / Await hinzugefügt , was das Schreiben von asynchronem Code sehr einfach macht.

• Sie können einen Teil der Codebasis unter iOS, Android und Windows Phone wiederverwenden.

• MonoTouch implementiert die CocoaTouch-APIs weitgehend auf sehr einfache Weise. Beispiel: Wenn Sie Erfahrung mit CocoaTouch haben, wissen Sie, wo Sie Klassen für Steuerelemente in MonoTouch finden können (MonoTouch.UIKit enthält Klassen für UIButton, UIView, UINavigationController usw.), ebenso wie MonoTouch.Foundation Klassen für NSString, NSData, etc ...).

• Im Gegensatz zu Lösungen wie PhoneGap oder Titanium bietet Xamarin Benutzern eine native Erfahrung.

Jetzt hat Objective-C einige Vorteile gegenüber C #, aber in den meisten Situationen führt das Schreiben von Apps in C # im Allgemeinen zu weniger Entwicklungszeit und saubererem Code und weniger Arbeit beim Portieren derselben App auf andere Plattformen. Eine bemerkenswerte Ausnahme könnten Hochleistungsspiele sein, die auf OpenGL basieren.

Die Kosten für die MonoTouch-Bibliothek spielen keine Rolle. Der Grund, warum Sie Mono nicht für Ihre iPhone-Apps verwenden sollten, ist, dass es sich um eine Krücke handelt. Wenn Sie sich nicht die Mühe machen müssen, die nativen Tools zu erlernen, habe ich keinen Grund zu der Annahme, dass Ihr Produkt einen Download wert ist.

Bearbeiten: 14.04.2010 Mit MonoTouch geschriebene Anwendungen sind nicht für den iTunes Store berechtigt. Das ist so wie es sein sollte. Apple sah viele flache Ports auf dem Mac, die plattformübergreifende Toolkits wie Qt oder die teilweise teilweise Neuimplementierung der System 7-Toolbox durch Adobe verwendeten. Kurz und gut, sie sind einfach nicht gut genug.