'Microsoft overweegt overname van maker developertools Xamarin'

Microsoft zou plannen hebben om de start-up Xamarin over te nemen. Dit bedrijf houdt zich bezig met tools die applicatie-makers in staat stellen om apps te ontwikkelen die op Windows, OS X, Android en iOS kunnen draaien.

Dat zegt CRN, die stelt over bronnen te beschikken. Volgens de site zijn de onderhandelingen al in een vergevorderd stadium, waardoor het aannemelijk is dat er snel een overeenkomst wordt opgesteld. Het is overigens nog niet zeker of Microsoft voor een overname kiest; CRN stelt dat er ook gekozen kan worden voor een grote investering in de start-up.

Xamarin maakt tools waarmee ontwikkelaars hun apps op verschillende besturingssystemen kunnen draaien terwijl zij vanuit één codebase werken. Ondersteunde besturingssystemen zijn Windows, OS X, Android en iOS. De tools van de start-up zijn onder andere te gebruiken in Visual Studio. Waarschijnlijk wil Microsoft de software van Xamarin via een overname dieper integreren in zijn ontwikkeltools voor Windows en Windows Phone, om zo ontwikkelaars ertoe te bewegen om apps uit te brengen voor zijn besturingssystemen.

Reacties (71)

Lijkt me een erg mooie overname voor Microsoft als software fabrikant. Helemaal als je kijkt naar de huidige staat van IDE/SDK's op de mobiele platformen (op windows phone na). Visual studio is gewoon heer en meester in IDE land

Voor de developers zou het helemaal mooi zijn als Xamarin nu helemaal gratis wordt

Als t gratis zou zijn, dan stap ik idd gelijk over! C# is zo veel prettiger dan Java! En Xamarin biedt, in tegenstelling tot veel andere platforms, de complete API van iOS en Android aan. Ze maken t niet abstract, en ze pleiten ervoor om user interfaces niet crossplatform te maken, maar voor elk platform opnieuw te implementeren. Domainmodels en andere code kan je dan delen, de rest pas je aan aan t target platform. Vind ik een heel goede oplossing, die en recht doet aan de developer, en aan de eindgebruiker, aangezien die een zo native mogelijke app krijgt, terwijl de developer veel code kan hergebruiken.

En hoe zijn de ervaringen qua performance?

als het native code aflevert, kan dat alleen maar goed zijn denk ik (tenzij de programmeur er een rommeltje van maakt)

Het hangt van het platform af. Maar het relevante is dat het overal garbage collection gebruikt. Echter werkt die goed, en is het voor de gemiddelde toepassing geen probleem. Unity3D verwerkt de logic ook op Mono. En C#/.Net heeft zeer goede tools om te werken met native-code, mocht je een hotspot nog verder willen optimalizeren

Geweldig! De C# die je schrijft wordt bij het compilen omgezet naar de native taal, dus bijvoorbeeld Objective-C. Hierna wordt de code ook nog eens geoptimaliseerd om ervoor te zorgen dat er geen dubbele code in zit. Het resultaat is een native app die de look, feel en performance heeft van een native app.

Bovendien is Xamarin ook erg snel met updates wanneer er een nieuwe versie voor iOS of Android uitkomt. Hierdoor is de dekking van beide platformen erg volledig!

Na wat Google'n kwam ik hierop uit, wat leesvoer:
http://stackoverflow.com/...performance-of-android-ap

Kwa performance blijft het dan wel hetzelfde, maar omdat je iOS, Android en Windows Phone apps in C# kan schrijven bespaart het een hoop tijd. Als je een beetje snugger bent bouw je de projecten zo op dat je zoveel mogelijk code kan hergebruiken voor de individuele platformen, zo zou je in principe alleen per platform de scherm logica opnieuw moeten schrijven.

Met native code heb je voor de 3 mobiele platformen 3 verschillende talen dus zal je 3 volledige apps opnieuw moeten ontwikkelen.

Het hoeft van mij niet eens gratis te zijn maar gewoon onderdeel maken van Visual Studio vanaf Pro.

Denk dat het te duur word om het onderdeel te maken van de gratis Windows Phone dev tools, maar dat zou natuurlijk helemaal awesome zijn.

Je hebt ook helemaal gelijkwat UI betreft, front end gewoon implementeren volgens de regels van het OS, dan krijg je ook niet dat mensen geen flikker er van snappen (voor spellen misschien minder een issue).

Tsja, als ze het wel in de Express versie aanbieden, zijn er een stuk meer developers aanwezig, die apps maken op basis van Xamarin. Als ze dit niet doen, zullen er een stuk minder (al zullen er ook piraatjes tussen zitten) die de mogelijkheid van Xamarin gebruiken.

Hoe meer mensen er gebruik van maken, hoe meer apps er op Windows Phone uitkomen, hoe meer Windows Phones er verkocht zullen gaan worden (althans, daar ga ik wel vanuit). Zo gek zou ik het niet eens vinden als ze het wel gewoon gratis gaan aanbieden.

Als MS slim is maken ze de Windows Phone compilatie gratis in deze tools. Voor iOS en Android zou ik lekker laten betalen. Wat is het belang voor MS voor applicaties voor iOS of Android?

Als een devoloper gemakkelijk een app op alle platforms kan maken, zal hij dan niet sneller deze oplossing gebruiken? Waardoor apps gelijkertijd kunnen uitkomen?

Xamarin's benadering is dat je de native API's kunt gebruiken. Eenvoudig met dezelfde codebase een applicatie maken voor iOS, Android en Windows Phone is dus niet echt mogelijk. Natuurlijk kun je wel code delen op de achtergrond voor de non-GUI zaken...

Ik geef je +3.
Ik zie in jouw commentaar namelijk de reden waarom deze tool wel goede native apps op verschillende platformen kan leveren die recht doen aan de verwachte gebruikerservaring op elk platform:

Ze maken t niet abstract, en ze pleiten ervoor om user interfaces niet crossplatform te maken, maar voor elk platform opnieuw te implementeren. Domainmodels en andere code kan je dan delen, de rest pas je aan aan t target platform.

[Reactie gewijzigd door Batje4 op 18 maart 2014 21:17]

Xamarin gratis, en dan met Visual Studio. Ja, dan zou ik helemaal blij worden

MonoDevelop is behoorlijk crack software.

Xamarin gratis, en dan met Visual Studio. Ja, dan zou ik helemaal blij worden

Het bedrijf waar ik werk zou graag Xamarin gebruiken voor cross-platform app development, maar aangezien we Visual Studio gebruiken en Xamarin voor Visual Studio nogal prijzig is (€999 per jaar, per developer, en we hebben 3 á 4 developers die het moeten gaan gebruiken), is het er tot nu toe niet van gekomen en doen we app development voor de drie platformen dus maar in verschillende IDE's, programmeertalen en op verschillende machines.

Ik kan uit ervaring vertellen dat de licentie kosten echt niet opwegen tegen de tijdwinst die je boekt bij het gebruik van Xamarin. Er zit natuurlijk wel altijd een learning curve aan vast, maar een goede developer zou dat zich zo eigen moeten maken. En denk dan nog eens aan onderhoudbaarheid bijvoorbeeld... kortom ik zou geen moment twijfelen, maar gewoon er mee aan de slag gaan en bewijzen dat het werkt

Je kunt inmiddels Xamarin Studio gebruiken, is iets minder crack als MonoDevelop maar nog wel best crack. Zo zit er een bug in de laatste versie dat je niet 2x een " achter elkaar kan indrukken zonder dat de IDE crasht

Die bug is nog een overblijfsel uit MonoDevelop. Heeft te maken met US-International (ofwel, Nederlandse) toetsenborden. Je kan je toetsenbord op de gewone US mode zetten, dan werkt het wel.

[Reactie gewijzigd door Wolfos op 19 maart 2014 10:42]

Dank! Heb er nog naar gegoogled maar dat was ik niet tegen gekomen. Bespaart mij weer een hoop frustratie!

Wow, ik volg Miguel de Icaza al lange tijd en ben zeer enthousiast over deze man! (Hij is de oprichter van Xamarin). Xamarin is trouwens het bedrijf dat Mono ontwikkelt, en Miguel is tevens een van de oprichters van Gnome. Het is dus wel grappig dat Microsoft nu interesse in hen heeft.
Xamarin draait dus al een tijdje mee in de software wereld, en een startup is t misschien technisch gezien wel, maar ze komen niet uit de lucht vallen.

Het is natuurlijk mooi als Xamarin overgenomen word en de ondersteuning voor C# op Linux gewoon blijft cq verbeterd wordt. Mono is ook de kern van Xamarin.iOS en Xamarin.Android. Dus het een zonder het ander kan haast niet. Ik zou t ze wel gunnen, maar ik hoop wel dat het niet ten koste gaat van bijv. de ontwikkel tools op OSX/Linux. Maar ik heb t idee dat Microsoft iets minder 'uitroeiend' bezig is de laatste jaren.

Hoe dan ook, goed crossplatform support voor C# is iets om toe te juichen! Zeker op mobile development vlak is t denk ik een levensvatbaar alternatief voor HTML5 apps.

[Reactie gewijzigd door - peter - op 18 maart 2014 20:59]

Ik vermoed dat het Microsoft vooral te doen is om het makkelijker te maken voor developers voor iOS, Android en Windows Phone samen te ontwikkelen, vooral om meer apps voor WP te krijgen.

De vraag blijft: Gaat vanuit belangenverstrengeling nou iOS en Android support achteruit?

Ja of Nee. Nee? Prima.. Ja? Dan kijken mensen graag verder naar iets anders.

Tsja, waarom zouden ze. Ze hebben al C# op WP, dus deze tool is specifiek voor de andere platforms. Is een beetje zonde om t over te nemen en dan t te laten vergaan. Lijkt me niet. Ik denk dat ze veel te winnen hebben bij C# als crossplatform taal bij uitstek. Dat levert veel developers op, die dan ook makkelijk voor WP kunnen gaan, of windows apps. (en Visual Studio gaan kopen bijv).

Ze moeten de API's van iOS en Android blijven onderhouden en up to date houden. Als het een wrapper is. API's kunnen door de tijd nog wel eens veranderen.

Daarnaast waarom zouden ze? Omdat MS het vaker doet met bedrijven die ze over hebben genomen om niet alles meer te gaan supporten. Daarom.

Het lijkt me van niet. Als Microsoft uitsluitend interesse had in een tool om WP apps te maken, dan heeft deze overname geen zin, dat hebben ze namelijk zelf al.

Nee, deze overname past in hun nieuwe strategie van "devices en services". Services betekent dus software aanbieden, ongeacht het platform. In die strategie is iOS en Android geen concurrent, het is gewoon een afnemer van de service.

Microsft gaat zijn geld verdienen met hardware, en software in de vorm van services over de platformen heen, als abbo's. Uiteraard wil men nog een eigen krachtig OS hebben, maar de huidige tijd en hun achterstand in mobiele platformen maakt dit tot een noodzaak.

Dat ook ja. Een 3e engine portatie/compilatie is niet ver meer dan

Uiteraard zal dat de reden zijn Maar dat neemt niet weg dat als ze dit doen c# op Linux een grote boost krijgt. ik ben wel benieuwd Dat en ik wil wel een los app maken

En misschien ook om geen C# developers aan Java te verliezen.

Xamarin gaat nog helemaal niet zo lang mee in z'n huidige vorm (vanaf 2011) maar Miguel de Icaza zat eerst bij Novell waar de focus richting AttachMate ging en hierdoor hun banen en R&D op de tocht stonden. Novell kocht in 2003 Ximian op en maakte toen het Mono (o.a. open source .NET runtime) project groot.

Ik zou t ze wel gunnen, maar ik hoop wel dat het niet ten koste gaat van bijv. de ontwikkel tools op OSX/Linux

Ik denk dat het grootste risicio zal zijn dat als developers eenmaal Xamarin gebruiken, en WP het "gebrek" aan apps daardoor heeft weggewerkt ze Xamarin en daarmee hun support voor Android en iOS laten vallen als een baksteen. De developers kunnen dan over naar de Visual Studio tools omdat ze C# in de vingers hebben.

[Reactie gewijzigd door farlane op 19 maart 2014 09:11]

Het nadeel blijft natuurlijk wel dat je bij de gemiddelde app (connecteren naar een webservice en wat gegevens op en neer sturen) een heel groot deel van je tijd bezig bent met heel platform specifieke zaken zoals het handelen van events, views updaten en dat soort zaken. Je kunt het nog zo goed scheiden als je wil maar waar ik de meeste tijd mee kwijt ben en de meeste code voor schrijf is toch wel het zorgen dat een app er goed uit ziet en alles netjes aan elkaar hangt op alle momenten.

Als dat allemaal platform-specifiek is dan ben je alsnog een hoop tijd kwijt met het opnieuw schrijven van dingen. En ik moet heel eerlijk zeggen dat uiteindelijk niet Objective-C maar alle frameworks en platformeigenaardigheden me heel veel moeite hebben gekost en Objective-C vrij weinig, hoe afwijkend het er ook uit ziet qua syntax als je kunt programmeren is het niet moeilijk om op te pikken. Één minuut Googlen leert je dat een C# Interface in Objective-C een Protocol is.

Blijft wel dat XCode vergeleken met Visual Studio niet echt de meest fantastische IDE is, al wen je er uiteindelijk wel aan. Maar veel debugging tijd gaat op aan het zoeken van de juiste incantatie op je debug commandline terwijl je met VS zo overal doorheen klikt, je hebt zo veel meer informatie onder je vingers. Ook semi automatische refactoring heb ik maar een beetje opgegeven. een tool moet gewoon niet regelmatig crashen tijdens dat soort operaties. Wellicht dat ik AppCode moet gaan gebruiken als ik weet dat er echt een App flink uitgemest moet gaan worden, als iets wel goed is aan JetBrains producten is het refactoring.

Over het algemeen leveren dit soort tools niet de mooiste applicaties op, je kunt altijd zien dat het niet native is. Een van de belangrijkste redenen dat Java op de desktop nooit echt een succes geworden is.

Xamarin is een C# wrapper om de native API's heen van iOS en Android. Het zijn dus echt native apps, geen crossplatform generieke userinterfaces ofzo.

Toch zul je met een generieke wrapper nooit de alle hoeken en gaten van de iOS API kunnen bereiken. Je zult in je code toch genericiteit moeten inleveren om die iOS App te maken die zich werkelijk onderscheid van de rest.

Je onderscheiden met een excellente Cloud service met een generieke app op basis van Xamarin is natuurlijk wel mogelijk.

Toch zul je met een generieke wrapper nooit de alle hoeken en gaten van de iOS API kunnen bereiken.

Kan wel; zelfs nieuwe API's zijn vaak al binnen enkele dagen beschikbaar in Xamarin na een officiële release door Apple. Xamarin is dan ook eigenlijk geen generieke wrapper. Xamarin stelt gewoon de hele iOS and Android API's open, maar in C# ipv respectievelijk Objective-C of Java.

Daarnaast kan je voor zowel iOS als Android zelf wrappers maken voor native code op dezelfde manier zoals Xamarin het zelf doet (hoewel Xamarin daar ongetwijfeld geautomatiseerde tooling voor heeft).

Zie:
- Binding Objective-C
- Binding a Java library

Mocht je dus om wat voor reden dan ook native code willen gebruiken, dan kan je er dus voor kiezen om een Objective-C of Java library te maken met daarbij een C# wrapper om de code binnen C# aan te kunnen spreken.

[Reactie gewijzigd door MacWolf op 18 maart 2014 22:15]

Goed, voordeel is dat je dan een groot deel van je App in C# kunt programmeren, of helemaal in C# maar je GUI code is wel verschillend voor de iOS, Android en Windows Phone versie.

En je moet kennelijk ook de verschillende GUI libaries nog beheersen want dat probleem lost Xamarin niet op? Of wordt er toch stiekem een 'common denominator' Touch/Gui framworkje meegeleverd waarmee je je simpele portable GUI frontend snel in elkaar kunt klikken?

Nadeel lijkt me toch nog steeds de extra overhead om een .NET runtime op iOS en Android te draaien waar Windows Phone dit native kan. iOS target zal overigens wel een of andere vette binary opleveren want volgens mij mag er geen .NET VM op iOS draaien, dat moet allemaal als ARM code opgeleverd worden.

Op Android Draait MonoRuntime naast de Dalvik Engine. deze Communiceren dan met elkaar. vaak is de monoruntime ook sneller dus kan de preformance van xamarin apps op android soms sneller zijn dan de native apps. Kijk maar hier voor meer informatie over de architectuur van xamarin op android:http://docs.xamarin.com/g...er_the_hood/architecture/

voor iOS zit het iets anders in elkaar en word de code gewoon compiled na Native ios (daarvoor heb je ook een mac nodig om te bouwen en debuggen). Dit geeft wel wat meer restricties, Omdat je geen reflection kan gebruiken. Dus geen dynamische code generatie.

maar ja dit betekend dat xamarin ook wel echt native is, voor ios en android. En het enige wat je appart hoeft te bouwen zijn de views. Voor ios kan je zelfs gewoon xcode interface builder gebruiken/ storyboards/ xibs/ of alles in code maakt niks uit!

[Reactie gewijzigd door P34nut op 18 maart 2014 23:18]

En je moet kennelijk ook de verschillende GUI libaries nog beheersen want dat probleem lost Xamarin niet op?

Ja, het is inderdaad wenselijk dat de ontwikkelaar redelijke kennis heeft van ieder platform waar hij een app voor schrijft. Omdat de native libraries "vertaald" worden naar C# libraries en gezien componenten en dergelijke ook in (qua naam) dezelfde namespaces zitten, helpt het als je al kennis hebt van Android en iOS. In dat geval kan je dus snel aan de slag met Xamarin. En je hebt ook nog de mogelijkheid om de standaard apps (Eclipse, Xcode) te gebruiker om UI's op te bouwen, hoewel het natuurlijk ook in code kan.

Het punt wat peter probeert te maken is dat het geen generieke wrapper is. Ik werk nu ruim 2 jaar met de xamarin tooling en het is echt native. Sterker nog, ik zoek vaak native voorbeelden op en herschijf deze dan zelf naar C#. Je kan dus precies hetzelfde als met de native taal.

Ik denk niet dat je helemaal goed in de gaten hebt hoe Xamarin in elkaar steekt. Zoals -peter- aangeeft, zijn user interfaces niet generiek. Je maakt voor elk platform individueel de view-laag. Verder biedt Xamarin een groot deel van het .NET framework aan, en vrijwel directe aanspraak op de native API's van de platformen.

Dit is complete onzin. Je bouwt "aan de voorkant" gewoon native apps. Heb je de app van Rdio wel eens gezien? Met Xamarin gebouwd...

Zolang de (goede) ondersteuning van iOS en Android maar overeind blijven is dit geen probleem. Ik werk nu zo'n anderhalf jaar met het het platform en ik zou niet meer terug willen naar objective C en Java, echt een geweldig platform om mee te werken.

Onlangs hebben ze al hun partnerschap met Microsoft aangekondigd dus een overname komt niet als een totale verrassing.

[Reactie gewijzigd door Strykeforce op 18 maart 2014 20:55]

Gezien de laatste ontwikkelingen op het het gebied van Microsoft apps zal de iOS en Android support wel goed gaan. Ze zien ook wel in dat je daar niet meer omheen kunt. Deze overname stelt ze in staat om nog beter alle platformen te ondersteunen.

Android heeft het grootste marktaandeel en dus ook de meeste apps
als MS er voor kan zorgen dat alle (populaire) apps ook op WP draaien is, heeft WP meer kans om marktaandeel te winnen
de strategie is dan ook vrij eenvoudig: zorg ervoor dat ontwikkelaars werken met een omgeving waar de WP variant van de app bijna vanzelf uitkomt

Ik snap Xamarin niet.. Wat ze doen is ook wat Qt doet. Als de Xamarin makers nou gewoon hadden geholpen met de Qt ontwikkeling en C# bindings hadden gemaakt was dat hele Xamarin project niet nodig geweest en was Qt nog beter.

En Microsoft snap ik daarmee ook niet. Waarom zouden ze dit mogelijk willen kopen. Ze hebben nokia overgenomen wat al eigenaar was van Qt (al een tijdje niet meer, nu is digia het).

Het loopt werkelijk dwars door elkaar heen met als netto effect:
Xamarin en Qt die exact hetzelfde willen. De 1 in C++, de ander in C#.

Het is misschien wel waar dat Qt ook native apps maakt. Maar C++ brengt wel heel wat extra overhead mee dan C# (bv eigen memory management). C++ moet je echt veel meer zelf regelen, en met c# heb je niet alleen een fijne taal, maar ook nog het dotNet framework. Ik denk dat als je snel en goed apps wil maken voor alleen iOS of voor meerdere platforms zal je altijd een stuk sneller zijn met het bouwen ervan met Xamarin, zelfs vergeleken met native development. Ik ken ook wat Objective C ontwikkelaars en Java ontwikkelaars lopers die zijn overgestapt naar xamarin, die zelfs geen c# kennis hadden, maar het toch uiteindelijke fijner vonden om daar mee te ontwikkelen dan native. Dus ja Ik denk gewoon dat c# een betere keuzen is als cross platform native taal in plaats van c++.

Wat je zegt klopt maar tot op zekere hoogte.

Ja, je heb memory management in c++. In Qt is dit dus een heel ander verhaal. Vrijwel alle memory management neemt Qt van je over via qobject (waar zoon beetje alles van overerft). Als je en beetje slim ontwikkeld zie je nooit een delete call.

Komt nog wat bij. Sinds c++11 hebben we smart pointers wat ook veel kopzorgen van memory management voor je oplost.

Wat betreft overhead denk ik dat je kennis wel een update kan gebruiken.

Qt apps voelen vaak toch niet erg native aan. Widgets (knoppen, tekstvelden, etc...) worden wellicht op een native manier "getekend", maar ze maken geen gebruik van de daadwerkelijke native controls van een platform. Maar wellicht zijn er meer goede redenen.

[Reactie gewijzigd door MacWolf op 18 maart 2014 22:38]

Qt apps zijn zeker wel native! Daar waar ze dat niet zijn heb je bugs te pakken.
Als je een app in QtWidgets maakt (dus geen custom widgets!) dan zal die app eruit zien als elke andere app op dat platform.

edit.. jij edit, ik edit

Ja, wat jij nu zegt (native = native eruit zien, maar niet native aanvoelen) zal wel een kweste van opvatting zijn. Het zou niet of nouwelijke moeten schelen met een app die "wel native" is gemaakt. En als er wel verschil in zit heb je een bug te pakken en zou je die moeten melden.

[Reactie gewijzigd door markg85 op 18 maart 2014 22:45]

Zijn edit is vóór jouw oorspronkelijke post

Als Xamarin overgenomen wordt, zal Mono dan nog wel blijven bestaan/zo actief ontwikkeld worden? Ik denk niet dat Microsoft daar direct zo interesse in heeft...

Microsoft zal niet aan Mono komen, dat is open-source en staat los van Xamarin.

Ik verwacht zelf dat Microsoft het volgende zal doen met de eventuele aankoop van Xamarin:
- kosten voor ontwikkelen met Xamarin tools verlagen
- het proces vereenvoudigen waar mogelijk voor poorten van Xamarin iOS & Android apps naar Windows Phone

[Reactie gewijzigd door MacWolf op 19 maart 2014 00:44]

Daar dacht ik dus ook aan. Ze kunnen het ook kopen en vervolgens een stille dood laten sterven.

Ik heb het vroeger ook al eens gebruikt in Visual Studio. Het werkt supergoed en je merkt geen verschil met Android apps geschreven in Java. Enig nadeel is dat de apps groter zijn (+- 2 megabytes aan vereiste dll's) en dat het niet eenvoudig is om talrijke third-party dlls te linken in je project.

Je ziet dat meer in producten.
Embarcadero Delphi XE5 kan ook vanuit 1 code base multi platform compileren en builden.

Ik vind het super, misschien minder kosten, meer mensen die het doorontwikkelen.

(tipje voor studenten kost het 99,-)