[Alg] Ontwikkelen voor Mac OS

[Verwijderd]

Ik heb een klein software bedrijf wat zich voornamelijk richt op remote desktop en remote assistance. Gebruikersgemak, snelheid, stabiliteit en veligheid staan hoog in het vaandel naast unieke features; remote desktop kan iedereen maken.

Nu is onze software enkel voor Windows. Dit levert geen enkel probleem aangezien Windows verreweg het meest gebruikt wordt. Als ontwerper en programmeur ben ik altijd op zoek naar nieuwe ontwikkelingen, nog voordat klanten ernaar vragen, dat moet in deze tak. Nu Apple overgestapt is naar Intel chips vermoed ik dat Apple veel meer machine's gaat verkopen omdat Windows er native naast kan draaien. Daarom ben ik wat onderzoek begonnen naar de mogelijkheden om een Apple machine te besturen vanaf Windows.

Nu is het zo dat we totaal geen ervaring hebben met Mac OS. Ik heb zelfs nooit een Apple aangeraakt.

Mijn vragen zijn alsvolgt:
- Maakt de migratie naar Intel chips de software ontwikkel mogelijkheden groter omdat er al veel kennis is in de compilerwereld over Intel chips?
- Wat zijn de mainstream talen en ontwikkelomgevingen voor Mac OS? Onze software is geschreven in Delphi (win32) en C# (.NET 2.0). We gaan er vanuit dat er voor beide geen compiler is.
- In hoeverre is .NET mogelijk onder Mac OS X? Heeft Microsoft plannen dit native te ondersteunen nu het processorplatform hetzelfde is en onder vuur ligt met zijn monopolie positie?

Ik kijk uit naar reacties.

[H!GHGuY]

Mac OS is in de kern nog altijd *NIX
met andere woorden wordt er voornamelijk met gcc gewerkt. gcc kan overweg met de meeste processoren dus dat vormt op zich geen probleem.

of m0n0 ook zonder probleem onder Mac OS draait weet ik niet, maar dat kun je denk ik snel uitzoeken op de site. Microsoft zal imo helemaal niet zelf ondersteuning bieden voor andere OS'en.

Wat heb je zelf al uitgezocht. Nu lijkt het me alsof je hier zomaar wat neerplempt en verwacht dat wij alle research doen.

[chem]

De migratie naar intel zal voor de meeste devvers weinig uitmaken. Pas als je op altivec-nivo bezig bent, is er wat veranderd. De meeste profilers kunnen wel vertellen waar je bottleneck zit, en hoe je dat probleem oplost is dan wellicht beter gedocumenteerd voor een x86 dan bij de ppc, maar uiteindelijk lijkt me dat niet veel uitmaken.

De belangrijkste taal onder OS X is Objective-C, en vv binnen het Cocoa-framework. Er bestaat ook het Carbon-framework; dat is wat ouder, procedureler en minder flexibel. Desalniettemin zweren er developers bij Carbon, veelal vanwege de ervaring die ze ermee hebben en doordat het minder flexibel is, is het ook vaak sneller.
Binnen de xCode en Cocoa-frameworks kun je diverse talen door elkaar gebruiken; bv. een ODBC-koppeling in Java, een beeld-compressie rekenaar in C++, je koppeling/logica in Obj-C en een xml-rpc implementatie in Python. Via zgn. bridges wordt dit aan elkaar geknoopt, wat voor jou als developer transparant moet werken.

.NET is er wel via mono, maar ik heb er nog nooit iets van gezien als gebruiker.

Al met al is wat je wil wel te doen; er zijn al VNC-achtige tools die de interface kunnen 'grabben' en aansturen, dus dat component is wel haalbaar. Wat wellicht wat meer wennen wordt is de OS X stijl van werken, de ingebouwde tools (en de verwachting bij gebruikers wat er werkt, bv AppleScript of Automator) etc. Maar, uiteraard heeft Apple sloten aan documentatie over de GUI, de werkwijze, de 'experience' etc. beschikbaar.

Ik zou zeggen; koop voor een prikkie een intel mac mini, en probeer eens wat. Denk je na 6 maanden dat het niks gaat worden, dan verpats je hem - of je zet hem thuis neer

[ Voor 11% gewijzigd door chem op 22-05-2006 21:25 ]

[Verwijderd]

Bedankt voor jullie reacties.

We hoeven ons in de eerste instantie gelukkig niet druk te maken over een user interface omdat de remote applicatie op de achtergrond draait (met een simpel configureer programma welliswaar). Het gaat dus om een slave applicatie die simpelweg client en server kan zijn en een heel scala aan opdrachten uitvoert.

Een nieuwe taal leren zal geen problemen leveren. Kunnen programmeren is kunnen programmeren zeg ik altijd maar Dat de Mac OS variant in een andere taal ontwikkeld wordt is sowieso geen probleem aangezien weinig code van de Windows variant gebruikt kan worden: remote desktop, het emuleren van muis en toetsenbord en de hele bestandsoverdracht afdeling is wezenlijk anders.

Een Mac mini stond al op het verlanglijstje. Die krengen zijn niet duur en erg leuk voor fotobewerking e.d.

HIGHGuY schreef op maandag 22 mei 2006 @ 21:09:
of m0n0 ook zonder probleem onder Mac OS draait weet ik niet, maar dat kun je denk ik snel uitzoeken op de site. Microsoft zal imo helemaal niet zelf ondersteuning bieden voor andere OS'en.

Wat heb je zelf al uitgezocht. Nu lijkt het me alsof je hier zomaar wat neerplempt en verwacht dat wij alle research doen.

Met Mono neem ik geen genoegen: de stabiliteit kan niet gegarandeerd worden en we zouden dan altijd achterlopen. Een reden om C# te willen is door onze kennis en de mogelijkheid om dezelfde code op twee platformen te gebruiken (hoewel onze applicaties in Delphi for Win32 geschreven zijn).

Overigens zou ik het niet vreemd vinden als Microsoft plannen zou hebben om een .NET variant voor Mac OS uit te brengen. Microsoft ondersteunt immers ook Office en aangezien komende versies gedeeltelijk op .NET gaan draaien zou het alleen daarom al niet vreemd zijn om een .NET Framework voor Mac OS uit te brengen.

Ik vraag niet naar onderzoek van jullie en ik heb zelf dus al onderzoek gedaan. Ik stel specifieke vragen. Als je het antwoord niet weet dan antwoord je niet, zo simpel is dat HIGHGuY.


Nu blijft de vraag "wat zijn de mainstream talen en ontwikkelomgevingen voor Mac OS?" over. Apple.com heeft het over Xcode waarin je projecten kunt maken voor verschillende frameworks. Is dit dé ontwikkelomgeving voor Mac OS? En voor de mensen met ervaring met software ontwikkeling onder zowel Windows als Mac OS: zijn we onder Windows (erg) verwend met Visual Studio en/of Delphi?

[Juup]

Verwijderd schreef op dinsdag 23 mei 2006 @ 00:45:
Ik vraag niet naar onderzoek van jullie en ik heb zelf dus al onderzoek gedaan. Ik stel specifieke vragen. Als je het antwoord niet weet dan antwoord je niet, zo simpel is dat HIGHGuY.

Hey hey beetje dimmen he? Uit je startpost bleek ook naar mijn smaak onvoldoende dat je zelf al e.e.a. uitgezocht had. Daar hoef je het niet mee eens te zijn maar HIGHGuY kan zelf wel bepalen of hij wil antwoorden of niet.

On topic:
Apple wil graag dat iedereen die developt voor MacOS dat in Objective-C doet. Dat is fijn voor Apple maar elke developer heeft natuurlijk zijn eigen voorkeur voor programmeertaal en -omgeving. Als je echter diep in de core wil duiken zoals bij VNC dan lijkt me de kans groot dat dit gemakkelijker gaat in Objective-C dan in andere talen.

[Verwijderd]

Juup schreef op dinsdag 23 mei 2006 @ 00:51:
[...]
Hey hey beetje dimmen he? Uit je startpost bleek ook naar mijn smaak onvoldoende dat je zelf al e.e.a. uitgezocht had. Daar hoef je het niet mee eens te zijn maar HIGHGuY kan zelf wel bepalen of hij wil antwoorden of niet.

Oke. Ik had wel onderzoek maar ik kon weinig objectieve informatie vinden. Zoals je zegt leidt Apple je graag naar Objective-C. Ik heb liever geen antwoorden dan dergelijke replies van HIGHGuY.

Juup schreef op dinsdag 23 mei 2006 @ 00:51:
[...]
Apple wil graag dat iedereen die developt voor MacOS dat in Objective-C doet. Dat is fijn voor Apple maar elke developer heeft natuurlijk zijn eigen voorkeur voor programmeertaal en -omgeving. Als je echter diep in de core wil duiken zoals bij VNC dan lijkt me de kans groot dat dit gemakkelijker gaat in Objective-C dan in andere talen.

Objective-C zal geen probleem zijn. Wat ik er tot zover van lees is het C++ in een ander jasje. Ik vraag me overigens af of een remote desktop slave applicatie "diep in de core" is, maar dat terzijde.

Nog twee vragen:
- Is het mogelijk, zonder enge omwegen, om een applicatie voor het Cocoa framework als zgn service te draaien. Service hier net als bij Windows: altijd draaiend ongeacht of er een gebruiker ingelogd is.
- Voor mensen met ervaring met Visual Studio/Delphi én XCode: wat zijn de grootste verschillen en hoe ervaren jullie de verschillen tussen beide?

[MSalters]

Het Cocoa framework is GUI oriented. De klassieke Windows service is GUI-loos; het equivalent daarvan op de Mac is de UNIX deamon. Als ik het me goed herinner is de exacte configuratie wel iets anders (via XML-achtige configuratiebestanden ipv scripts) maar "eng" is het niet te noemen.

De verhalen die ik vanuit Microsoft heb gehoord wezen niet op een port van .NET naar Mac, maar dat waren verhalen vanuit de Visual Studio groep van voor de Intel bekendmaking.

[Gerco]

[off topic]

Met Mono neem ik geen genoegen: de stabiliteit kan niet gegarandeerd worden en we zouden dan altijd achterlopen.

Dat eerste argument is onzin, de stabiliteit van mono kan net zo goed of slecht gewaarborgd worden als die van Microsoft .NET. Wat betreft het tweede heb je gelijk, mono loopt altijd flink achter op .NET, omdat alles opnieuw geschreven moet worden en dat pas kan gebeuren als MS de specs (en dus de software) al gereleased heeft.

Overigens zou ik het niet vreemd vinden als Microsoft plannen zou hebben om een .NET variant voor Mac OS uit te brengen. Microsoft ondersteunt immers ook Office en aangezien komende versies gedeeltelijk op .NET gaan draaien zou het alleen daarom al niet vreemd zijn om een .NET Framework voor Mac OS uit te brengen.

Het lijkt me niet dat Microsoft een .NET framework gaat uitbrengen voor MacOS X, niet binnen afzienbare tijd in ieder geval. Het argument dat MS in .NET ontwikkelt voor Office lijkt me ongegrond. Office voor MacOS X is een heel ander produkt als Office voor Windows en het is dus helemaal niet zeker dat die gedeeltelijk in .NET geschreven gaat worden. Zelfs als dat zo is, lijkt het me niet ondenkbaar dat MS een .NET runtime alleen voor Office gaat meeleveren, niet bruikbaar met andere apps dus.

Microsoft is er helemaal niet bij gebaat dat .NET voor andere platforms uitkomt, sterker nog, ze zijn er bij gebaat dat het niet gebeurt. Voor zover ik weet is de processorarchitectuur ook geen argument om het nu wel/niet te doen, aangezien .NET, net als Java, redelijk onafhankelijk daarvan zou moeten zijn.

Het blijft natuurlijk allemaal koffiedik kijken, MS zou morgen gewoon .NET voor Linux, OS/400 en MacOS X kunnen uitbrengen, maar ik zou er niet op rekenen

[ Voor 18% gewijzigd door Gerco op 24-05-2006 09:01 ]

[Verwijderd]

Nu blijft de vraag "wat zijn de mainstream talen en ontwikkelomgevingen voor Mac OS?" over. Apple.com heeft het over Xcode waarin je projecten kunt maken voor verschillende frameworks. Is dit dé ontwikkelomgeving voor Mac OS? En voor de mensen met ervaring met software ontwikkeling onder zowel Windows als Mac OS: zijn we onder Windows (erg) verwend met Visual Studio en/of Delphi?

Xcode is net als VS/Delphi een volwaardige IDE omgeving en geen texteditor met een compile knopje. Code completion, visual GUI design etc alles zit er in.

[The - DDD]

Verwijderd schreef op woensdag 24 mei 2006 @ 00:02:
[...]

Oke. Ik had wel onderzoek maar ik kon weinig objectieve informatie vinden. Zoals je zegt leidt Apple je graag naar Objective-C. Ik heb liever geen antwoorden dan dergelijke replies van HIGHGuY.


[...]

Objective-C zal geen probleem zijn. Wat ik er tot zover van lees is het C++ in een ander jasje. Ik vraag me overigens af of een remote desktop slave applicatie "diep in de core" is, maar dat terzijde.
...

Ehm, nou..... Ik denk dat je je nog zwaar gaat verbazen over hoe anders Objective-C is ten opzichte van C++. Er is zelfs Objective-C++. Belangrijkste is dat Objective-C veel dynamischer te gebruiken is dan C en C++.


Nog wat handige linkjes:
Darwin port van MONO (Darwin is de opensource basis van de OSX kernel):
http://darwinports.openda...orts/?by=name&substr=mono

Objective C overview, erg waardevol voor proggers met ervaring die even willen zien wat het nou is:
http://developer.apple.co...oa/Conceptual/ObjectiveC/

Hele handige recepten site voor Cocoa development:
http://cocoadevcentral.com/

En als je echt serieus aan de slag wilt met OSX, deze twee boeken beantwoorden al je vragen (te krijgen via een goede boekhandel, Bol, Proxis en ik geloof zelfs play.com):
http://www.bignerdranch.com/products/

[ Voor 31% gewijzigd door The - DDD op 24-05-2006 09:24 ]

[Parcye]

Wat heb je uit eindelijk gekozen?

[-FoX-]

Ik denk dat de meest logische keuze gewoon het Java platform zou zijn.

Internationale support door grote reuzen in de software industrie, multiplatform (write once, run anywhere), op alle markten thuis (mobile, desktop, enterprise, ...), ...

[Verwijderd]

Als je (voor het web) grafisch mooie dingen wilt doen, hou dan de ontwikkelingen van Silverlight van Microsoft eens in de gaten.
Dit zou ook op de mac moeten gaan draaien. Het ziet er veelbelovend uit, vind ik.


edit: hmm dit is een ouder topic zie ik net.

[ Voor 14% gewijzigd door Verwijderd op 25-06-2007 20:54 ]

[Alex)]

Gerco schreef op woensdag 24 mei 2006 @ 08:59:
[off topic]

[...]

Het lijkt me niet dat Microsoft een .NET framework gaat uitbrengen voor MacOS X, niet binnen afzienbare tijd in ieder geval. Het argument dat MS in .NET ontwikkelt voor Office lijkt me ongegrond. Office voor MacOS X is een heel ander produkt als Office voor Windows en het is dus helemaal niet zeker dat die gedeeltelijk in .NET geschreven gaat worden. Zelfs als dat zo is, lijkt het me niet ondenkbaar dat MS een .NET runtime alleen voor Office gaat meeleveren, niet bruikbaar met andere apps dus.

Microsoft is er helemaal niet bij gebaat dat .NET voor andere platforms uitkomt, sterker nog, ze zijn er bij gebaat dat het niet gebeurt. Voor zover ik weet is de processorarchitectuur ook geen argument om het nu wel/niet te doen, aangezien .NET, net als Java, redelijk onafhankelijk daarvan zou moeten zijn.

Het blijft natuurlijk allemaal koffiedik kijken, MS zou morgen gewoon .NET voor Linux, OS/400 en MacOS X kunnen uitbrengen, maar ik zou er niet op rekenen

Ook ik reageer nog even op dit oude topic. Silverlight is - volgens de devvers tenminste - een beperkte versie van het .NET-framework, hetgeen betekent dat het best mogelijk kan zijn dat Microsoft de volgende grote versie van het .NET-Framework ook voor de Mac beschikbaar gaat stellen (al zullen Windows-specifieke zaken dan wel weggelaten worden)

[Gerco]

Alex) schreef op maandag 25 juni 2007 @ 23:53:
Ook ik reageer nog even op dit oude topic. Silverlight is - volgens de devvers tenminste - een beperkte versie van het .NET-framework, hetgeen betekent dat het best mogelijk kan zijn dat Microsoft de volgende grote versie van het .NET-Framework ook voor de Mac beschikbaar gaat stellen (al zullen Windows-specifieke zaken dan wel weggelaten worden)

Ik zie dat verband niet, eerlijk gezegd. Ik denk eerder dat Silverlight met een applicatie specifieke runtime geleverd wordt dan dat er ooit een dotNet.framework op mijn Mac zal staan.

Mocht MS het wel doen, dan juich ik dat van harte toe, vooral als ze er behoorlijke GUI support inbouwen. Gezien de moeilijkheden met Windows Forms zullen ze dat wel niet willen namaken (dan moet je half Windows meeleveren). Misschien komt er iemand met Cocoa#

[Ashtaroth]

Klopt idd, Silverlight draait op een beperkte versie van WPF, waarvan je die runtime installeert. Tijdens de devdays lieten ze een live demo zien waarin een Silverlight applicatie draaide op een Mac die op een Windows machine werd gedebugged.

[MacWolf]

-FoX- schreef op maandag 25 juni 2007 @ 09:18:
Ik denk dat de meest logische keuze gewoon het Java platform zou zijn.

Internationale support door grote reuzen in de software industrie, multiplatform (write once, run anywhere), op alle markten thuis (mobile, desktop, enterprise, ...), ...

Zolang je geen GUI applicaties maakt is Java wat mij betreft ook de beste keuze als je een soort multiplatform service wilt maken. Voor C# ontwikkelaars is Java zeer snel te leren (C# zou je kunnen zien als Microsoft's versie van Java). Mogelijk moet je wel een eenvoudige wrapper maken voor het Windows platform (weet niet of je een Java programma zo als service kan starten). Bij Mac OS X kan je via een shell script de service inladen bij het starten van de computer, hoewel er vast ook een makkelijkere mogelijkheid is.

[Marcj]

MacWolf schreef op dinsdag 26 juni 2007 @ 09:59:
[...]


Zolang je geen GUI applicaties maakt is Java wat mij betreft ook de beste keuze als je een soort multiplatform service wilt maken. Voor C# ontwikkelaars is Java zeer snel te leren (C# zou je kunnen zien als Microsoft's versie van Java). Mogelijk moet je wel een eenvoudige wrapper maken voor het Windows platform (weet niet of je een Java programma zo als service kan starten). Bij Mac OS X kan je via een shell script de service inladen bij het starten van de computer, hoewel er vast ook een makkelijkere mogelijkheid is.

Waarom geen GUI applicaties? Voor de meeste GUI's kun je prima Swing gebruiken (zolang het niet te ingewikkeld wordt). Hiervan is de snelheid vooral sinds Java 6 behoorlijk verbeterd. En anders is er nog SWT...

[MacWolf]

Marcj schreef op dinsdag 26 juni 2007 @ 10:14:
[...]


Waarom geen GUI applicaties? Voor de meeste GUI's kun je prima Swing gebruiken (zolang het niet te ingewikkeld wordt). Hiervan is de snelheid vooral sinds Java 6 behoorlijk verbeterd. En anders is er nog SWT...

Om de simpele reden dat op een Mac een Java GUI applicatie niet 'native' aanvoelt. De kleuren, knopjes en dergelijke zien er net iets anders uit. En om een produkt succesvol op de Mac te verkopen is het heel belangrijk dat de applicatie native aanvoelt. Daar hechten Mac gebruikers zeer veel waarde aan, dat moet je niet onderschatten. Als je een Mac GUI applicatie maakt is het verstandiger om Cocoa te gebruiken en met behulp van Apple's uitstekende tools een interface te maken. Het was vroeger ook mogelijk om met Cocoa Bindings een Aqua interface te ontwikkelen voor een Java applicatie, maar deze functionaliteit wordt uitgefaseerd.

[Marcj]

MacWolf schreef op dinsdag 26 juni 2007 @ 12:34:
[...]


Om de simpele reden dat op een Mac een Java GUI applicatie niet 'native' aanvoelt. De kleuren, knopjes en dergelijke zien er net iets anders uit. En om een produkt succesvol op de Mac te verkopen is het heel belangrijk dat de applicatie native aanvoelt. Daar hechten Mac gebruikers zeer veel waarde aan, dat moet je niet onderschatten. Als je een Mac GUI applicatie maakt is het verstandiger om Cocoa te gebruiken en met behulp van Apple's uitstekende tools een interface te maken. Het was vroeger ook mogelijk om met Cocoa Bindings een Aqua interface te ontwikkelen voor een Java applicatie, maar deze functionaliteit wordt uitgefaseerd.

Wat ik hier juist lees is dat dat wel goed moet zijn met MacOS. Nu heb ik hier zelf geen ervaring mee, maar volgens mij kun je wel met Java een applicatie native laten aanvoelen.

[MacWolf]

Marcj schreef op dinsdag 26 juni 2007 @ 14:37:
[...]


Wat ik hier juist lees is dat dat wel goed moet zijn met MacOS. Nu heb ik hier zelf geen ervaring mee, maar volgens mij kun je wel met Java een applicatie native laten aanvoelen.

Dat is een marketing praatje Er zijn wat handige functies die Apple heeft ingebouwd of Java applicaties iets meer 'native' te laten aanvoelen (via een commandline switch kan je een menu bijv. naar de top verplaatsen, zoals gebruikelijk is bij een Mac applicaties en je hebt bijv. een switch voor de Aqua Look-and-Feel), maar het punt is gewoon dat er niet gebruik gemaakt wordt van de echte native widgets, maar van widgets die erop lijken. Maak je software die voor de grote massa bedoelt is, dan is het wat betreft Mac OS X echt te adviseren om de echte Aqua widgets te gebruiken.

Deze recensie van Delicious Library laat een beetje zien hoe Mac gebruikers naar software kijken:

I'm pointing these things out not because Delicious Monster is unique among Mac developers in the quality of their artwork and their attention to detail, but because they aren't unique. Nearly every popular Mac OS X application is a single-icon drag-installed affair, sporting an attractive icon, distributed in either an internet-enabled or meticulously decorated and arranged disk image. Even open source applications like Fire and multi-platform ports like Mozilla meet this standard on OS X. Heck, even Real gets it right. Real software...think about that!

This is an example of the best kind of peer pressure. There is simply a "climate of excellence" on the Mac platform. Any developer that does not live up to community standards is looked down upon, or even shunned. Commercial, open source, freeware, shareware, it doesn't matter: pay attention to detail, or else.

[-FoX-]

Ik denk dat het allemaal wel meevalt hoor. Zeker omdat Sun zich sinds kort weer meer op de desktop markt focust. De populariteit van andere OS'en neemt ook toe en ik denk dat de volgende versies van Java zeker aan de bruikbaarheid van Java desktop applicaties zullen bijdragen. Als je alleen al kijkt naar de performance improvements die Java6 op het Swing gedeelte haalt, zijn dat zeker mooie vooruitzichten. Nu, eerst moeten ze maar even zorgen dat Java6 deftig op MacOS werkt... is momenteel nog zo instabiel als wat!

[MacWolf]

-FoX- schreef op woensdag 27 juni 2007 @ 10:47:
Ik denk dat het allemaal wel meevalt hoor. Zeker omdat Sun zich sinds kort weer meer op de desktop markt focust. De populariteit van andere OS'en neemt ook toe en ik denk dat de volgende versies van Java zeker aan de bruikbaarheid van Java desktop applicaties zullen bijdragen. Als je alleen al kijkt naar de performance improvements die Java6 op het Swing gedeelte haalt, zijn dat zeker mooie vooruitzichten. Nu, eerst moeten ze maar even zorgen dat Java6 deftig op MacOS werkt... is momenteel nog zo instabiel als wat!

Punt is gewoon dat de standaard Java widgets gewoonweg niet native zijn, hoewel er op dit moment wel 1 manier is om native widgets te gebruiken met Java en dat is gebruik maken van de SWT toolkit ipv Swing (zie: http://www.eclipse.org/swt/). Toch is het maken van een GUI wat omslachtiger in een omgeving als Eclipse t.o.v. Xcode.