Apple scherpt programmeerregels iPhone OS 4 aan

Apple heeft de regels omtrent ondersteunde programmeertalen voor de nieuwste versie van zijn iPhone OS aangescherpt. Ontwikkelaars mogen volgens de nieuwe licentie alleen nog maar software schrijven in C, C++ of Javascript.

De nieuwe license agreement stelt dat iPhone-software alleen in Objective-C, C, C++ of Javascript mag worden geschreven. Virtual machines, zoals Java, waren in het verleden al niet toegestaan, maar deze wijziging betekent dat ontwikkelomgevingen die een andere programmeertaal omzetten naar C, ook niet meer mogen.

Dit is slecht nieuws voor Adobe, dat in zijn aankomende CS5-softwarepakket een speciale functie heeft opgenomen om iPhone applicaties in Flash te schrijven. Flash CS5 krijgt een Packager for Iphone, waarmee applicaties die in Actionscript 3 zijn geschreven, worden gecompileerd naar native iPhone-applicaties. Het lijkt erop dat Adobe's plannen door de nieuwe bewoording in de ontwikkelaarsovereenkomst worden geblokkeerd. Overigens is Adobe niet het enige bedrijf met een dergelijke applicatie. Via het Monotouch-ontwikkelpakket kunnen ontwikkelaars .NET-applicaties die in C# zijn geschreven, compileren voor iPhone OS.

Adobe zegt op de hoogte te zijn van de nieuwe overeenkomst, maar gaat vooralsnog door met de ontwikkeling van Flash CS5 met iPhone compiler.

Reacties (253)

[Roytoch]

Dikke bakzooi, die vendetta die Apple tegen Adobe lijkt te voeren. Komt de gebruiker echt niet ten goede... Ik wil goede apps, het interesseert me niet zoveel met welke taal deze is gemaakt, als het maar werkt.

[robin1979]

Dat is juist het probleem. Wellicht zie je de resultaten van een slecht geschreven app niet gelijk, maar met het oog op multitasking is het wel vervelend als er een 'flash' app op de achtergrond even de CPU zit vol te stouwen (of andere instabiliteit veroorzaakt).

Ik kan deze regels alleen maar toejuichen op een apparaat als een telefoon.

[Virtuozzo]

Daar heeft het allemaal niks mee te maken, op geen enkel vlak. Het is een leuk argument à la marketing, maar uiteindelijk komt het gewoon neer op zaken doen.

Ik was een tijdje bezig met een post om zaken in perspectief te plaatsen, maar kwam al surfend op een andere site terecht waar iemand anders al haarscherp de vinger in de wond stak. Hij presenteert het als mening, maar met een klein beetje historisch overzicht alsmede een klein beetje zakelijk inzicht kom je op dezelfde fundamentele conclusies terecht. Hij gaat niet in op wat dit voor het core business model betekent, of zelfs voor aanverwante modellen, maar dat is dan ook een heel andere discussie.

Link.

Quote:
"by raganwald

Getting away from the frenzied rhetoric, my opinion is that what Apple really wants to prevent is people releasing multi-platform compilers. So taking Flash as just one example, if I can build one app and the compiler can make me an iPhone executable, an Android executable, and so forth, Apple don't want that.

In my experience so far with such "cross platform compatibility layers," they always produce results that water down each platform's individual strengths and differentiations. And of course, instead of the developer being locked into the phone platform, they are locked into the compatibility layer's platform.

Adobe's Flash compiler is a classic maneuver to "commoditize your complements," as Joel put it so well. Apple don't want to be commoditized, especially if it means having apps that don't take advantage of the iPhone's strengths.

Adobe want to lock developers into Flash and commoditize everything else as Flash-delivery devices. Apple want to commoditize applications and lock developers into their APIs."

[TDeK]

Alsof je native geen slechte code kunt schrijven... Zo'n compiler kan iig nog zo gemaakt worden dat veel gemaakte inefficiënties eruit worden gehaald.
Maar dit bewijst maar weer eens hoe diep de haat tussen Apple en Adobe is. Vind ik niet erg, moet niks hebben van Adobe, maar dit gevecht begint nu ook de klanten (aan beide zijden) te raken, en dat is echt slecht.

[Reactie gewijzigd door TDeK op 23 juli 2024 03:32]

[vgroenewold]

Natuurlijk kan dat, maar denk je niet dat de kans op fouten vele malen groter wordt als je van het 1 naar het ander gaat? Om maar niet te beginnen over efficient programmeren. Volgens mij is er geen compiler die zo netjes alles in een andere taal weet om te zetten. Waarom ze dat perse blokkeren, geen idee, maar het is tot aan 4.0 nog steeds mogelijk (toch?) en vanaf 4 niet meer, veel schade zal dat niet opleveren... je kan alleen niet in de achtergrond draaien e.d. en dat is wellicht 1 van Apple's redenen.

[.oisyn]

Natuurlijk kan dat, maar denk je niet dat de kans op fouten vele malen groter wordt als je van het 1 naar het ander gaat?

Dat denk ik idd niet. Waarom zou dat in hemelsnaam wel zo zijn? De fouten zitten in de originele programmacode, en het idee is dat een transcompiled stuk code nog steeds hetzelfde doet als voorheen. Als het wat anders gaat doen dan is de code generator sowieso stuk.

Volgens mij is er geen compiler die zo netjes alles in een andere taal weet om te zetten.

Dat soort compilers zijn er anders zat. Sterker nog, strict gezien werkt elke compiler zo omdat er gecompileerd wordt naar een intermediate taal die een VM of processor snapt.

Wat ik vooral frappant vind is dat code die ik zelf in C intyp blijkbaar wel mag, ook al is die code exact identiek aan de code die een flash to C compiler heeft gegenereerd wat volgens Apple dus niet mag .

En als efficientie een argument was geweest dan hadden ze Objective-C ook niet toegelaten, en Javascript al helemaal niet.

[Reactie gewijzigd door .oisyn op 23 juli 2024 03:32]

[newinca]

Wat ik vooral frappant vind is dat code die ik zelf in C intyp blijkbaar wel mag, ook al is die code exact identiek aan de code die een flash to C compiler heeft gegenereerd wat volgens Apple dus niet mag .

Die identieke flash code wordt niet naar even efficiente C gecompileerd, maar wordt gelinkt met een loodzware Flash support library en een eindeloze reeks function call naar die library. Het geheel is een stuk minder efficient dan jouw originele C code.

En als efficientie een argument was geweest dan hadden ze Objective-C ook niet toegelaten, ...

ObjC is een oneindig veel efficienter dan Flash. En CocoaTouch is ook ObjC, dus de meest efficiente manier om te interageren met het OS.

... en Javascript al helemaal niet.

Nog eens een voorbeeld van het niveau van de Tweakers journalisten hier: Javascript is niet toegelaten in een App. Het is enkel toegelaten als WebApp.

[Reactie gewijzigd door newinca op 23 juli 2024 03:32]

[.oisyn]

Die identieke flash code wordt niet naar even efficiente C gecompileerd, maar wordt gelinkt met een loodzware Flash support library en een eindeloze reeks function call naar die library. Het geheel is een stuk minder efficient dan jouw originele C code.

Dat is compleet besides the point. Het punt is dat jij exact identieke C code kunt produceren. Als je dat met de hand doet, dan mag dat van Apple. Maar als gelijke code uit een transcompiler is komen rollen, dan mag het niet meer. Figures.

[Reactie gewijzigd door .oisyn op 23 juli 2024 03:32]

[newinca]

Het punt is dat jij exact identieke C code kunt produceren. Als je dat met de hand doet, dan mag dat van Apple. Maar als gelijke code uit een transcompiler is komen rollen, dan mag het niet meer. Figures.

Jouw punt is een utopie.

In de praktijk zal de overgrote meerderheid van de gegenereerde C code er uit zien als een sequence van library calls. Het is best mogelijk dat er hier en daar een berekening in zie die dat niet nodig heeft, maar dat doet er niet toe als je als doelt hebt om te detecteren of de code een Flash translation is.

[.oisyn]

Mijn punt is geen utopie, mijn punt wordt misgeïnterpreteerd door jou. Het gaat er helemaal niet om dat het detecteerbaar is. Waar het om gaat is dat een programmeur dezelfde code kan schrijven als een generator, hoe goed of slecht deze ook is.

Maar goed, het is inmiddels wel duidelijk dat het Apple gewoon om vendor lock-in te doen is. Ze willen geen transcompilation omdat ze geen crossplatform code op hun platform willen. Ze willen dat Apple applicaties uniek zijn.

[MacWolf]

En als efficientie een argument was geweest dan hadden ze Objective-C ook niet toegelaten, en Javascript al helemaal niet.

Ik begrijp niet precies wat je hier mee bedoelt. Onder Mac OS X worden alle native applicaties in Objective-C geschreven. Apple's Cocoa / Cocoa Touch API's zijn in Objective-C geschreven. Het zou juist erg inefficiënt zijn om een andere taal dan Objective-C te gebruiken, gezien andere API's veel beperkter zijn onder Mac OS X (je krijgt minder out-of-the-box en moet meer zelf implementeren, met alle mogelijke fouten die daarbij kunnen optreden).

[.oisyn]

Objective-C resolved alle object function calls @ runtime. Dat is per definitie minder efficient dan code die statisch gelinkt wordt, zoals met C en C++ het geval is.

[newinca]

So fucking what?

Als een C of C++ programma wil interageren met een ObjC API zal het overgrote deel van de tijd zowiezo in een ObjC environment gebeuren. Dat is het enige wat telt.

[.oisyn]

So fucking what?

God zeg, heb ik een Obj-C evangelist op de teen getrapt ofzo? Ik zeg dat het minder efficient is (feit) maar dat het Apple sowieso niet om performance te doen was. Ik probeer het verder niet af te zeiken ofzo, grow up zeg.

[corani]

Persoonlijk denk ik dat 99% van de code die in een andere taal dan Objective-C geschreven wordt, en vervolgens vertaald wordt, beter zal werken dan hand geschreven Objective-C

Serieus, heb je wel eens naar dat gedrocht van een taal gekeken? Je moet een goeroe zijn om daar geen slechte code, vol met memory holes, mee te schrijven. Handmatig memory-management is zo 1980... Het is niet voor niets dat naar Apple niemand Objective-C gebruikt...

[MacWolf]

Serieus, heb je wel eens naar dat gedrocht van een taal gekeken? Je moet een goeroe zijn om daar geen slechte code, vol met memory holes, mee te schrijven. Handmatig memory-management is zo 1980... Het is niet voor niets dat naar Apple niemand Objective-C gebruikt...

Objective-C is geen gedrocht, het is juist een zeer elegante taal. Memory leaks zijn eenvoudig te voorkomen als je de paar regels in acht neemt die er zijn (alleen release doen als je zelf alloc / copy of retain gebruikt). Daarnaast zijn er mogelijkheden voor automatisch geheugenmanagement, vooral in Objective-C 2.0. In Objective-C (standaard) kunnen eventueel autorelease pools gebruikt worden.

Je praat duidelijk als iemand die geen ervaring heeft met die taal.

[Milt]

Sorry hoor, maar Objective-C een elegante taal noemen gaat echt te ver! Als je er even mee aan het werk bent gaat het best maar de syntax is verre van elegant. Ik prefereer dan toch echt Java of C# ofzo. Ik verkies zelfs nog C++ boven Objective-C.

[MacWolf]

Misschien vind je de syntax niet mooi, dat is een kwestie van wennen. De taal is echter (naar mijn mening) wel degelijk elegant om verschillende redenen:
- Er is echt sprake van object oriëntatie, objecten sturen berichten naar elkaar - er kunnen berichten gestuurd worden naar objecten die niet bestaan en de app crashed dan niet. Bij goed gebruik kan dit heel krachtig zijn.
- Methodes zijn zelfbeschrijvend. Wanneer je een methode ziet als [NSString stringByReplacingOccurencesOfString:withString:] weet je precies wat voor parameters ingevuld moeten worden. In Java zou een dergelijke methode er bijvoorbeeld zo uitzien: String.Replace(str1, str2). Zonder documentatie is het niet duidelijk welke waarde op de eerste parameter gezet moet worden en welke op de tweede. Gelukkig helpen IDE's vaak hiermee (hovering pop-ups), maar in Obj-C is dit niet nodig.
- Concepten als categories waarmee je op zeer eenvoudige manier Apple's API kan uitbreiden met eigen functies of zelfs bugs oplossen door een eigen implementatie te maken van bestaande methodes.
- Echt sprake van MVC wanneer gebruik wordt gemaakt van Interface Builder. Er wordt geen code gegenereerd, de interface wordt echt opgeslagen in een stream en bij het starten van de app weer 'uitgepakt'. Via messaging is deze losse koppeling mogelijk.

Ik kan nog wel een tijdje doorgaan zo, maar het moge duidelijk zijn dat als men enige ervaring opgedaan heeft met Objective-C dat het een hele mooie elegante taal is om in te werken. Ik moet wel toegeven dat de leercurve erg hoog is - deze taal is wat lastiger om te leren als bijv. Java, VB.NET of C#.

[Xthemes.us]

Hangt maar net af van je standpunt. Zoals je zelf al aangeeft gebruik je niks van adobe dus vind het wel amusant.

Ik als persoon die niks van Apple wil gebruiken (en ook niks van hun gebruikt) en eigenlijk liever niks van Adobe gebruiken.. maar ik kan niet om flash heen kan dit dan wel weer op prijs stellen.

Als dit zowel Apple als Adobe klanten kost kan ik er alleen maar om lachen. (Dus nogmaals, hangt puur af van je standpunt )

[Rynus_Rein]

Niet alleen Adobe wordt hierdoor getroffen, zoals genoemd mag nu ook Monotouch niet meer wat de populaire Unity 3D engine (cross-platform 3d engine, ook iPhone, d.m.v. Mono -> opensource .NET implementatie) op de iPhone behoorlijk de nek om zal draaien.

Way to go apple...

[David Mulder]

Sorry, maar de hele applicatie wordt vertaald naar C (of objective C eigenlijk) en daarna gecompileerd, er draait geen flash meer. Met andere woorden, er is geen echt verschil meer.

[robin1979]

geen echt

'Geen echt' houdt in dit geval in dat de applicatie een stuk groter/logger is, en daardoor meer resources nodig heeft, dan een applicatie zonder tussenlaag.

In theorie is het allemaal heel mooi, praktisch zijn er gewoon goede bezwaren tegen te maken.

Maar het mooie van vrije marktwerking, ben je het er niet mee eens? Neem je een andere optie, niemand die je dwingt een iPhone te gebruiken.

[Verwijderd]

'Geen echt' houdt in dit geval in dat de applicatie een stuk groter/logger is, en daardoor meer resources nodig heeft, dan een applicatie zonder tussenlaag.

Nonsens, wat dan met de "overhead" van objective C/C++ boven C? Wat met de overhead van C over Assembler? Daarnaast is deze theoretische stelling niet omzetbaar in de praktijk. Time-to-market is veel belangrijker dan een iets loggere app. Daarnaast is het ook perfect mogelijk om een applicatie in C te maken die trager/groter is dan C#/Java/Flash applicatie. Een taal dwingt je namelijk niet een goed design te voorzien in je programma.

Maar het mooie van vrije marktwerking, ben je het er niet mee eens? Neem je een andere optie, niemand die je dwingt een iPhone te gebruiken.

Nee, Als ontwikkelaar (die geld wilt verdienen) moet je naar de markt luisteren en Apple heeft nu eenmaal een zeer groot aandeel in de smartphones / mobile apps markt. Ze doen hier gewoon een lock-out van andere dev-tools en verplichten zo de Apple tools te gebruiken. Je kan Apple niet verplichten tools beschikbaar te stellen voor alle platformen, maar ik vindt niet dat ze andere bedrijven mogen uitsluiten wel zulke tools te maken/verkopen.

[Qreed]

Nonsens, wat dan met de "overhead" van objective C/C++ boven C? Wat met de overhead van C over Assembler? Daarnaast is deze theoretische stelling niet omzetbaar in de praktijk. Time-to-market is veel belangrijker dan een iets loggere app. Daarnaast is het ook perfect mogelijk om een applicatie in C te maken die trager/groter is dan C#/Java/Flash applicatie. Een taal dwingt je namelijk niet een goed design te voorzien in je programma.

Niet echt nonsens: Als de performance van een applicatie compleet met het design te maken zou hebben, dan zou het iPhoneOS in Java gemaakt zijn, de kernel van Windows7 in C# en de laatste idTech engine met Flash of Silverlight.

Inderdaad, een onervaren programmeur kan ook door C++ te gebruiken een gedrocht van een applicatie maken, maar dat heeft dan niet aan de efficiëntie van de taal gelegen. Met de meeste interactieve applicaties merk je (visueel) nauwelijks een verschil tussen een efficiënte en minder efficiëntere taal. Maar dit komt ook omdat er effectief maar heel weinig functionaliteiten gelijkertijd uitgevoerd worden.
Flash, Java, .NET ..., ... hebben allemaal effectief meer instructies nodig om een bepaalde actie uit te laten voeren. Dit is niet erg in de meeste gevallen, maar op zo'n "apparaatje" als de iPhone kan dat best een hoop schelen.

[Dykam]

Toelichting op dat de kernel van W7 in C# zou zijn. De reden is niet de performance, de reden is dat ze dan in 1 keer de miljoenenregelige codebase van de vorige versies droppen. Dat is economisch niet mogelijk. Maar als ze het zouden herschrijven in C#, het zou waarschijnlijk vele malen sneller zijn door het betere, vernieuwde ontwerp. Daarbij is al vaak bewezen dat het verschilt in snelheid tussen JIT'd en native talen niet per defenitie altijd in dezelfde ligt. Er zijn veel gevallen waar JIT'd talen sneller kunnen zijn. Wat vaak gerelateerd is aan slimme aanpassingen door de JIT aan het platform waar het op draait.

[Verwijderd]

Niemand gaat een kernel schrijven om op een JIT compiler te draaien. Niet in de echte wereld, althans.

[Dykam]

Zie mijn antwoord op dmystic, dat gebeurt dus wel .

[dmystic]

nog klein nadeeltje waarom het niet logisch zou zijn om W7 in C# te schrijven, je moet je interpreter op de een of andere manier toch draaien(omdat C# niet naar machinetaal compiled naar maar bytecodes) dus kan je ook geen heel OS erop baseren, tenzij je natuurlijk zon interpreter in c++ bv schrijft, en de rest daar bovenop, maar dat zou ook niet h elemaal practisch zijn

[Dykam]

Om daar op in de gaan, er zijn meerdere projecten die daar juist om mikken. Buiten dat .Net niet met een interprenter werkt, maar met een JIT, wordt dit probleem opgevangen doordat, in plaatst van Just In Time compilatie, Ahead Of Time compilatie te gebruiken. De JIT en de garbage collector worden vanuit CIL naar voor een machine native instructies gecompileerd op een ander systeem. Dit wordt gestart als booter, waarna de eventueel dan geJITte kernel het overneemt. Dit is een van de manieren waarop dit mogelijk is.

Voor referentie, zulke projecten zijn o.a. Mosa en Renraku.

[Reactie gewijzigd door Dykam op 23 juli 2024 03:32]

[Verwijderd]

- Als je een applicatie in Monotouch schrijft, dan wordt dit min of meer gecompiled naar Objective-C. Het draait niet op de CLR zoals .NET.

- Er is geen reden waarom Java of .NET trager zou moeten zijn dan bijvoorbeeld C++. Dat heeft dan vooral met de limitaties van de huidige JIT compilers te maken. Maar een integer bij een andere integer optellen zal in .NET of Java precies dezelfde instructies opleveren als bij C++.

- Microsoft heeft ook een OS kernel geschreven in C#: Singularity.

- Silverlight is blijkbaar snel genoeg voor applicaties op WP7, waarom zou het dan te traag zijn voor de iPhone? Maar alweer: Monotouch is geen Silverlight die op de iPhone draait, het is gewoon gecompiled naar code die de iPhone slikt.

[t-h]

- Silverlight is blijkbaar snel genoeg voor applicaties op WP7, waarom zou het dan te traag zijn voor de iPhone? Maar alweer: Monotouch is geen Silverlight die op de iPhone draait, het is gewoon gecompiled naar code die de iPhone slikt.

Microsoft vindt het snel genoeg (ze zouden gek zijn om van hun eigen platform/taal te zeggen dat het niet zo is). Dat betekent misschien dat Apple meer eisen stelt, en hoe terecht die zijn daar mogen de gebruikers (lees: totaal niet de developers) hun oordeel over vellen. Dat is ook marktgericht werken.

[berend_engelbrecht]

Ik ben het met je eens dat dit pure concurrentievervalsing is van apple. Ze hebben op de markt van de smartphones marktdominantie en daar maken ze nu nog meer misbruik van. Het was al moeilijker om voor de iphone software te ontwikkelen dan voor andere smartphone-platforms, om deze redenen:
- Je kan als ontwikkelaar niet vrijelijk je eigen applicaties op je eigen standaard iphone uitproberen, dat kan met android en windows mobile wel.
- Apple bedrijft volstrekte willekeur in het toelaten van applicaties tot de itunes store en er zijn legio voorbeelden van kleine softwareontwikkelaars die uitgesloten worden zonder dat ze er wat tegen kunnen doen.

Daar komt nu dus ook nog vendor lock-in voor de tools bij. Jammer dat Neelie Kroes geen eurocommisaris op dit gebied meer is, dit soort praktijken zijn m.i. een flinke boete waard. Ook zou een gedwongen verdere openstelling van hun platform voor de iphone/ipad net zo'n goede maatregel zijn als dat voor Windows was.

Voor alle mensen die het verhaal ophangen dat apple het belang van de klanten en/of de stabiliteit van het systeem als reden heeft: waarom is javascript dan wel toegestaan? Dat is een interpreted language en juist langzamer/volumineuzer dan de JIT-compiled talen die nu uitgesloten worden. Op het gebied van javascript-executie is wel grote vooruitgang geboekt zodat de inefficiency een stuk kleiner is dan vroeger, maar dat geldt ook (en in meerdere mate) voor de nu uitgesloten tools.

[Tjeemp]

Zo ver ik weet ben je gewoon in staat om je eigen applicaties (die nog niet in de AppStore staan) op je iPhone te installeren en te testen. Via iTunes kun je namelijk gewoon pakketjes toevoegen aan je app-list van builds van je app.

Ik vraag me af of het niet een beetje een tafereel is dat we bij andere dingen ook zien. Het feit dat het vertalen van code meestal een rommel oplevert. Het is volgens mij nooit zo clean als origineel gebouwd is.

[Verwijderd]

Gelukkig niet...
Hoewel... ik ben stiekem toch ook wel benieuwd wat er nu precies allemaal veranderd zal zijn bij de iPhone4

[Skohsl]

Als alles via Flash gaat, dan worden ook de slechte eigenschappen van een in flash geprogrammeerde programma meevertaald. En Flash is nou niet het beste/efficientste dat er ooit gemaakt is. Het is dus helemaal niet vreemd dat Apple wat meer controle wil hebben over de programmeertaal, want als een programma langzaam loopt, dan ligt het altijd aan het apparaat en niet het programma, daar gaat de gemiddelde gebruiker in ieder geval niet vanuit. Het zou dus als slechte reclame voor Apple uit kunnen pakken. Maar inderdaad, het is niet mogelijk om alle slechte code te weren, maar het loont de moeite om het te proberen.

[Punksmurf]

In dat geval kan je beter de kern aanpakken en logge, slecht werkende programma's verbieden. Iets waar ze bij Apple ook niet vies van zijn.

Ik vind het maar wat jammer. De iPhone vind ik een geweldige telefoon maar die hele policy van dit mag niet en dat mag niet daar word ik goed ziek van. Gelukkig lijkt WP7 een goed alternatief te worden (hoewel ik ook nog niet helemaal overtuigd ben), dus ik hoop dat er wat mooie toestellen zijn om uit te kiezen tegen de tijd dat mijn huidige contract afloopt .

[PPie]

Waarom denk je dat WP7 een alternatief gaat zijn?
MS lijkt alle dingen te kopieren waar mensen over vielen bij de iPhone.
(Geen Copy/Paste, Multitasking, Side load van apps, andere app store, memory card slot, (zeker in het begin) geen Flash, skinning, meerdere Hardware opties, etc...)
Dit zullen ze bij dit ook wel gaan doen.
(Alleen dan natuurlijk alleen C# gebruiken en misschien C/C++)

[SunnieNL]

Microsoft heeft al lang vermeldt dat silverlight de way to go is voor de applicaties op wm7. Dus dat houdt in dat er geprogrammeerd moet worden in dotnet

[Punksmurf]

Het is er nog niet, maar naar het zich laat aanzien luisteren ze in ieder geval naar de community, in ieder geval alvast aangaande de eerste twee punten die je aanhaalt.

Ik hoop dat ze zich betreffende de rest ook nog gaan bedenken...

Maar je hebt gelijk, ze zijn vooralsnog wel erg bezig met Apple te imiteren.

Flash (als browser-plugin) op m'n telefoon hoeft van mij niet zo nodig, trouwens. Op m'n telefoon kan ik prima zonder.

Enigszins verder off topic, maar ik heb ook geen idee wat ik anders moet kiezen.
• De huidige WinMo is brak en geen uniforme implementatie
• BlackBerry is geen optie want daar moet je weer een apart abonnement voor hebben
• mijn vroegere ervaring met Palm is verschrikkelijk, ken het nieuwe OS niet maar de toestellen die ze nu maken vind ik alvast ontzettend lelijk (itt vroeger)
• Android is zo'n beetje anders op elke telefoon (zie ook huidige WinMo) plus dat ik niet m'n data in de cloud wil hebben maar gewoon op m'n telefoon zelf en daarnaast heb ik ook niet al teveel op met het alles overheersende Google.

Maar goed, dat is misschien een discussie die beter op het forum gevoerd kan worden.

[Finraziel]

Hmm, je moet het natuurlijk zelf weten met android, maar dat het anders is op elke telefoon valt volgens mij heel erg mee... Sure, er zitten wat verschillen in maar die zijn relatief beperkt, meestal is het niet veel meer dan een andere homescreen (wat weinig impact heeft, voornamelijk licht cosmetisch) en wat extra gadgets. Het is absoluut niet zo dat de complete interface anders is zoals dat bij veel winmo devices is (waar touchflo 3d en dat gedrocht van samsung compleet andere ervaringen dan vanilla winmo bieden bv).
De google cloud hoef je verder absoluut niet te gebruiken, ik snap nooit zo waarom mensen altijd denken dat je een google account MOET hebben, want dat is gewoon niet waar... Ik maak er zelf wel met veel plezier gebruik van, maar het hoeft niet.
Het niet op hebben met Google... tja, dat is puur een gevoel, daar kan ik ook niks over zeggen, da's persoonlijk... Behalve dan dat android niet exclusief van google is maar van de open handset alliance, google is natuurlijk wel erg actief met het promoten van android.

[Nibbz]

je vergeet Andriod hier

[Punksmurf]

Hell no, dat vind ik echt helemaal niks. Niks geen uniforme implementatie, wildgroei aan versies en alles aan je Google-account gekoppeld. Je data hangt ergens in de cloud, dus als je geen verbinding hebt kan je je email niet lezen.

Dan nog liever de iPhone, al heb ik onderhand echt genoeg van dat gezanik van Apple over wat ik wel en niet met m'n telefoon mag.

[Verwijderd]

Je mag alles met je iPhone, jailbreak em en leef je uit. Garantie is een ander punt

[_Noldy]

Jippie, een telefoon kopen om vervolgens te hacken en dan eindelijk aan normaal gebruik toe zijn. Precies wat de consument wil.

[vgroenewold]

Dit was precies hetgeen je standaard moest doen met WM telefoons...

[Left]

In C kun je ook erg slechte programma's schrijven, daar zijn er genoeg van.

Als je het mij vraagt wil Apple gewoon geen Flash toestaan omdat je daarmee apps kan draaien buiten hun AppStore om. En dat betekent gemiste inkomsten.

[ZpAz]

Dit ging over flash apps die in de app-store geplaatst zouden worden, deze worden dan vertaald naar C++? code ofzo.

[newinca]

Als je het mij vraagt wil Apple gewoon geen Flash toestaan omdat je daarmee apps kan draaien buiten hun AppStore om. En dat betekent gemiste inkomsten.

Volgens mij heb je er niets van begrepen.

[Verwijderd]

Je comment slaat de plank flink mis want er is een wereld van verschil tussen een scripttaal zoals AS3 en een volwaardige programmeertaal als C/C++. Met een voornaam verschil een heel ander memory management.
Het zegt dan ook absoluut niets over de kwaliteit van de compiler die ze gebouwd hebben en dus is het ook redelijk vaag waarom Apple hier tegen zouden zijn.
Sterker nog het is bijzonder kortzichtig om volledig gespecialiseerde ontwikkelplatformen af te keuren die juist wat gebruikersvriendelijker zijn in het ontwerpen van apps. Het lijkt me geen blocking van Adobe maar meer een soort te voorzichting willen zijn omwille van de kwaliteit van de apps.

[appel437]

Als alles via Flash gaat, dan worden ook de slechte eigenschappen van een in flash geprogrammeerde programma meevertaald. En Flash is nou niet het beste/efficientste dat er ooit gemaakt is.

effiecientie komt niet uit de taal, dat is een misverstand. heel veel mensen denken dat simpele talen efficienter zijn, en voor kleinere toepassingen is dat zeker zo. maar ik durf te wedden dat als jij een app moet maken in een simpele taal zoals deze dat die voor jou zo onoverzichtelijk wordt dat je inefficiënte code schrijft.

efficiëntie komt namelijk door inefficiënte compilers of door inefficiënte code. en bij high-level talen heb je vaak te maken met inefficiëntere compilers, maar ook veel meer overzicht. en door die toename van overzicht kun jij makkelijker betere code schrijven, die vervolgens sneller zou zijn als jij die in een taal als assembly had gemaakt.

[kiang]

het wordt niet vertaald naar C: de app wordt geschreven in flash en gecompileerd voor het iPhone platform. Vertalen naar C/C++ en dan compileren zou een omweg zijn die Apple niet kan verbieden (want dan zou je gen GUI-builders meer mogen gebruiken: deze 'vertalen' namelijk ook code)

[PPie]

Probleem is dat Flash dan dus een soort metaplatform is.
Nadeel daarvan is dat het per definitie achter het OS aanloopt met ondersteunen van nieuwe dingen en juist niet de interessante, platformspecifieke meerwaarde biedende dingen zal ondersteunen...

[the_shadow]

Voor het zelfde geld bied de compiler van Adobe hier wel ondersteuning voor. Vergeet niet dat een goede compiler alles uit de kast haalt om zo optimaal mogelijke code voor het doelplatform te genereren.

[newinca]

Vertalen naar C/C++ en dan compileren zou een omweg zijn die Apple niet kan verbieden (want dan zou je gen GUI-builders meer mogen gebruiken: deze 'vertalen' namelijk ook code)

Jongen, lees regel 3.3.1 er zelf eens op na.

Vertalen naar C/C++ is PRECIES wat Apple verbiedt. En, ja, dat betekent ook dat GUI builders niet toegelaten zijn, tenzij ze een en ander kunnen verbergen of tenzij ze geen code genereren, zoals de GUI builder van Apple zelf.

[bglnelissen]

@GreatSlovakia
Ik denk dat je de spijker op z'n kop slaat. Maar het stuur je het "project" met code (bijv. Objective-C) naar apple of het gecompileerde eindproduct?

Als je een gecompileerd eindproduct moet afleveren kan je als nog met je flashtools gaan developen.

Dit is dus een essentieel verschil.

[riezebosch]

Toch is het best prettig wanneer al die "template apps" nu ook verdwijnen. Als je zoekt op "fifa" krijg je zoveel keer dezelfde fanclub app voor verschillende clubs in de resultaten...

[Erwin_Br]

Ik kan deze regels alleen maar toejuichen op een apparaat als een telefoon.

Toejuichen? Ik weet niet of je wel eens gehoord hebt van bijvoorbeeld de game engines Torque en Unity... Zij worden nu ook slachtoffer. En dat terwijl talloze games in de app store zijn gebouwd in deze engines. Zombieville (unity engine) is notabene een app die door Apple ooit als aanrader op de front page van de store heeft gestaan! Enorm populair!

[Verwijderd]

Als dat het was dan zou een Iphone niet eens kunnen multitasken. Het is gewoon puur de strijd tussen Apple en Adobe en om de kwaliteit van apps hoger te krijgen.

[Edo1987]

Oeh, de mantra wordt weer 'opgedreund': Adobe Flash vreet teveel CPU, te buggy, te log, ouderwets, enz....

[roy-t]

Het slaat ook eerlijkwaar nergens op, is dit uberhaupt nog wel legaal? Philips kan toch ook niet zeggen dat op zijn nieuwe dvd-speler alleen films gemaakt door Steven Spielberg mogen spelen? Waar slaat dit op, en waarom komt Apple er waarschijnlijk toch weer mee weg?

De AppStore geeft Apple al de mogelijkheid om alles te verbieden wat ze niet leuk vinden, maar nu is zelfs de oorspronkelijke programmeertaal een issue geworden, ondanks dat je er in de binaries echt niet meer wat van gaat merken.

[resma]

Apple was de firma die ooit Microsoft probeerde belachelijk te maken om de gesloten en beperkte structuur van haar producten. Apple was de firma die het 'beter deed', zelfs technische documentatie meeleverde bij haar producten en probeerde zoveel mogelijk de boel 'open' te houden.

Inmiddels is Apple Microsoft ver voorbij gestreefd op het vlak van gesloten, beperkt en gereguleerd.

Ze maken mooie producten, die ook meestal heel goed werken, maar daar gaat het met name de early adapters van Apple producten al lang niet meer om. Het gaat erom gezien te worden, liefst als eerste, met een nieuwe Apple gadget. Wie geeft er anders ongezien en ongeprobeerd 500 euro voor een apparaat zoals de iPad, terwijl er nog geen informatie over kinderziekten e.d. beschikbaar zijn?

Ben je gemiddelde consument, dan zie je in Apple producten mooi uitziende en goed werkende spullen, verdiep je je wat meer in de materie en bekijk je het vanuit de ogen van een programmeur of Tweaker, dan zie je een zeer gesloten platform met diverse ridicule door Apple opgelegde beperkingen.

Ik hoop dat toch binnenkort de EC eens de praktijken van Apple onder de loep neemt.

[Dreamvoid]

Apple was de firma die ooit Microsoft probeerde belachelijk te maken om de gesloten en beperkte structuur van haar producten. Apple was de firma die het 'beter deed', zelfs technische documentatie meeleverde bij haar producten en probeerde zoveel mogelijk de boel 'open' te houden.

Apple heeft een hoop gedaan, maar dat nooit. Het heeft in zijn commercials altijd de draak gestoken met Windows dat traag, instabiel, complex en onveilig zou zijn - niet dat het gesloten was. Mac OS was ook historisch veel meer gesloten dan Windows, daar is pas met OS X verandering in gekomen. Documentatie van API's voor devs was traditioneel een drama. Apple is heel opportunistisch wat betreft open technologie: als ze iets zelf beter kunnen bouwen dan de concurrentie, doen ze het gesloten - zo niet, dan nemen ze bestaande open technologie.

[DLGandalf]

kijk even naar deze keynote:
http://www.youtube.com/wa...iQA6KKyJo&feature=related
Ergens halverwege het filmpje tiert jobs over vrijheid en speelt de underdog positie tegenover BigBlue. "Future Freedom in the information age" schreeuwt hij, volgens mij doel je dan wel een beetje op openheid. Nu zijn zelf op de top van verschillende branches en vertonen ze dezelfde arrogante houding. Niet dat ik medelijden heb met adobe, want ik zie dat heel graag verdwijnen, maar wat is het volgende wat moet verdwijnen in apples ogen?

[Reactie gewijzigd door DLGandalf op 23 juli 2024 03:32]

[k995]

Hij doelt op de 1984 reclame denk ik echter was dat ( vermoedelijk) gericht tegen IBM.

En het is idd ironisch dat Jobs zelf aan de leiding staat van apple als het bedrijf meer en meer richting IBM/1984 gaat waar hij zich ooit tegen afzette. Ach ja :

http://i.bnet.com/blogs/jobs-1984.jpg

het pas nog ook.

[TDeK]

Ik hoop dat toch binnenkort de EC eens de praktijken van Apple onder de loep neemt.

Ik ga er al bijna vanuit dat dat eraan zit te komen. Ben benieuwd hoe de PR afdeling dat op gaat pakken, want van dat soort slechte publiciteit zijn ze daar niet zo gediend.

die ook meestal heel goed werken

Voor veel gebruikers houdt het daar op; men is dan tevreden. En Apple geeft lange support op hun producten.
Maar is Apple echt zo'n 'fashion statement' dan? Heb dit zelf eigenlijk nooit zo ervaren...

[Het.Draakje]

Steeds weer hetzelfde verhaal in een ander jasje:

Hoe je het wendt of keert, zolang dit niet door een monopolist wordt gedaan is het 'wettelijk geen probleem. En Apple is geen monopolist, niet op computer- en niet op telefoongebied dus mag het gewoon.

Verder is "rididule beperkingen" alleen maar een mening, die niet door iedere Tweaker en/of programmeur gedeeld wordt.

[blouweKip]

De EC grijpt alleen maar in als de marktwerking in gevaar is, en hoezeer de microsoft fanboys dat misschien willen vanuit een misplaatst sentiment: dat gaat niet gebeuren.
Overigens ben ik ook niet zon fan van de microsoft-manier van lock-ins die apple hanteert op hun mobiele devices dus prefereer ik android/megoo en arm/linux tablets over apple telefoons/tablets.

Wat betreft flash snap ik het wel, flash zuigt op niet windows platformen, het is trage meuk die aanvoelt alsof het beta software betreft, het hogged resources en verpest de user experience, ongeacht welke andere motieven apple hierbij misschien heeft: adobe moet eerst orde op zaken stellen en fatsoenlijk software afleveren.

Overigens: als je je "ergert" aan gesloten systemen waarom dan die eenzijdige focus op apple, consoles gaan daar nog veel verder in, tip: koop het niet als je het niet leuk vind.

[Reactie gewijzigd door blouweKip op 23 juli 2024 03:32]

[Roytoch]

Ik zag je tweet hierover eerder dan dit bericht, en kon het niet plaatsen, nu wel, haha.

Ja, als gebruiker kan ik een 'goede gebruikerservaring' enzo alleen maar toejuichen maar dit gaat echt te ver... Helemaal als de flash > iphone conversie gewoon nette snel genoege code oplevert, dan kan je daar toch niet moeilijk over gaan lopen doen als Apple zijnde...

[maceddy2004]

Sja, maar een 'Hello World' omgezet met dat progje wat dan 4MB is.. Lijkt mij ook niet echt lekker....

*probeert bron nog even te vinden*

[_beevee_]

Wat een onnozel voorbeeld. Zinvol zou zijn als je bijvoorbeeld een game zou vergelijken die 'oorspronkelijk' met (final release van) Flash CS5 en dezelfde game "oorspronkelijk" in Object-C geprogrammeerd zou vergelijken. Ook de O-C game zal gebruik maken van game libraries.

En laat die bron maar weg want die kan alleen maar gebaseerd zijn op beta code waar Adobe al van aangaf dat de final compactere code zou opleveren.

[Reactie gewijzigd door _beevee_ op 23 juli 2024 03:32]

[.oisyn]

Als je die in C geschreven Hello World applicatie linkt met een hele uitgebreide runtime die vanalles en nogwat kan dan wordt ie ook heel groot.

[Roytoch]

Ja maar wat nu als die 4MB de dingen zijn die altijd worden toegevoegd? Dan zou het verschil op een applicatie van 50MB wellicht nog steeds 4MB zijn, en dan praat je al heel anders.

[Virtuozzo]

Natuurlijk is dat legaal. In de VS (net als in de meeste economische zones elders) zijn de rudimentaire regels aanverwant aan dit soort zaken a) afkomstig uit oudere tijden en b) structureel vaag.

Apple's systeem, model, markt, software, services, commerciële modellen, etcetera. Apple's regels. Dat is ook de focus van Apple: een set van eigen gesloten niche marken met een hoge mate van interne diversiteit en een extreem hoge drempel tot "leakage" vanuit Third Party commerciële systemen / modellen / services.
Kan ze niet kwalijk genomen worden, het is zaken doen in het verlengde van de traditionele geesten van bijvoorbeeld onze patent systemen, dezelfde fundamentele insteek kwa gedachtengoed.

Al ziet menigeen dit als "slecht", en al raakt dit menige ontwikkelaar in zijn beurs, Apple zal hier prima mee weg komen. Vergeet niet dat Apple's markten en services nogal "inclusive" zijn. Eenmaal aan boord, is de overstap naar iets anders altijd meer kostbaar dan het accepteren van bepaalde beperkingen. In Nederland is dat niet zo expliciet, in tegendeel tot bijvoorbeeld de amerikaanse markt waar Apple zeer sterk staat kwa bindingen.

Om in perspectief te zetten, er was eens een keer een presentatie van Apple, waar een soort via dialoog weergegeven werd tussen een PC en een mac gebruiker. De PC gebruiker ratelde voort over drives en geheugen en modificaties. De mac gebruiker had als enige maar simpele repliek: "I have a mac".
Twintig of meer jaar later heeft die gebruiker nog steeds een mac. Zijn vrouw ook, zijn kids krijgen als onderdeel van hun tuition fee van de universiteit een iPad, en zijn bedrijf is gevuld met meer macs, waar ze heel trouw zijn aan het model waar ze voor gekozen hebben, omdat het ten slotte niet alleen hun platform van keuze is, maar ook hun eigen markt an sich.

Vergeet ook niet dat Apple een in wezen zeer amerikaans bedrijf is, zeker in hun gedachtengoed, iets wat zich vertaald in een zeer begrijpelijke neiging to isolationisme en protectionisme (zoals Jobs een paar jaar terug op een bijeenkomst goed weergaf met de uitspraak "our stuff, our market, our rules").

[Reactie gewijzigd door Virtuozzo op 23 juli 2024 03:32]

[Verwijderd]

Apple is meer ruzie aan het maken de laatste tijd (Google anyone?). Ik eigenlijk benieuwd naar hun motieven hierachter.. Dat flash gebant word snap ik wel, maar er is natuurlijk een zekere symbiose tussen Apple en Adobe (een groot deel van de creatieve / grafische wereld draait op Apple+Adobe combinaties)...

Waar willen ze heen met deze strijd? Ik zie overigens ook niet een probleem in het hercompileren naar native code, immers haal je hiermee de 2 bezwaren weg: Apps moeten door de AppStore review heen en Apps draaien niet op ene VM die veel te zwaar is / batterij zuipt..

[TDeK]

Zou het misschien kunnen zijn dat zo'n gecompileerde app van binnen zulke obfuscated code bevat dat Apple hier geen quality-check meer op kan uitvoeren?

[Dreamvoid]

Apps draaien niet op ene VM die veel te zwaar is / batterij zuipt.

Waarom hebben Blackberries (waar elke app in een eigen Java VM draait) dan de langste accuduur van zo'n beetje alle smartphones?

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 03:32]

[newinca]

Omdat BlackBerrie apps zo goed als niet zwaar doen?

Seriously...

[k995]

Dell ook een tijdje geleden. Hmm merk ergens een patroon op.

[Whieee]

Apple is meer ruzie aan het maken de laatste tijd (Google anyone?). Ik eigenlijk benieuwd naar hun motieven hierachter.. Dat flash gebant word snap ik wel, maar er is natuurlijk een zekere symbiose tussen Apple en Adobe (een groot deel van de creatieve / grafische wereld draait op Apple+Adobe combinaties)...

Steeds meer grafici kiezen tegenwoordig voor Windows, omdat Adobe de laatste jaren geen enkele moeite doet om fatsoenlijke Mac versies te maken. Apple heeft al vanaf OSX 10.0 aangegeven dat Carbon een 'transitional' API was, en dat Cocoa de toekomst was; Adobe bleef stug bij Carbon. Adobe heeft er tot CS3 over gedaan om universal binaries te bouwen, mede doordat Adobe niet naar Xcode wilde. Apple biedt nu native 64bit, OpenCL, etc. Adobe laat het grootschalig na om er goed gebruik van te maken.

Catch my drift?

[spostma]

Waarom ze zich zo verzetten tegen Adobe is mij een raadsel. Wat zou het hele Mac platform vandaag zijn (of misschien wel heel Apple) als Adobe niet continu geinvesteerd had in creative software voor het Mac platform.
Als Adobe omgekeerd een vendetta tegen Apple wil voeren stoppen ze onmiddelijk met support van de hele suite voor OSX. Houden ze zelf niet veel omzet over, maar dat zal wel een poot onder Apple vandaan schoppen.

[Reactie gewijzigd door spostma op 23 juli 2024 03:32]

[TDeK]

Dan blijft iedereen een oude (wel werkende versie) van een Adobe apkket gebruiken. Andersom gaat dit niet op, aangezien iPhone users wel actief updaten naar OS4 zodat ontwikkelaars wel met de nieuwe voorwaarden mee moeten (gaat harder dan de afname van users die oude Adobe software gebruiken).

[Reactie gewijzigd door TDeK op 23 juli 2024 03:32]

[Verwijderd]

Dan stop Adobe toch met support. Denk dat de aandeelhouders van Adobe daar moeilijker over gaan doen, dan die van Apple. Voor Adobe is het 35% van de omzet en Apple bouwt de software dan zelf wel.

Trage zooi van Adobe met een ouderwetse interface van Mac OS 9.

[blouweKip]

Probeer maar eens flash (apps) te gebruiken onder osx (of onder linux) dan krijg je enigzins een idee waarom flash niet zo populair is, overigens is flash origineel ontwikkeld door macromedia, welke opgekocht is door adobe, adobe's eigen software heeft geen last van de beperkingen die flash heeft.
Jammer opzich want de flash authoring tools zijn best netjes.

[Metro2002]

Je kan zeggen wat je wilt van flash maar sinds versie 10 werkt het best aardig onder linux (rond de 40% cpu gebruik bij films in hoge resolutie in Youtube) en het beste van alles: het werkt uberhaupt !

Adobe doet in elk geval zijn best om het echt crossplatform te maken, in tegenstelling tot bv MS Silverlight wat gewoon voor geen meter werkt onder linux (plus dat het ALTIJD een versie achterloopt)

Vind het van Apple dan ook echt een rare stap die ze nu maken, waarom zou je zo'n regel opnemen, wat schiet je daar mee op. Een geconverteerd programma mag niet maar een lomp geschreven programma direct in C mag wel? Wat bereik je er dan mee.

Die geslotenheid en beperking van Apple is voor mij echt een reden om het voorlopig nog maar mooi bij Linux te houden. Ik bepaal graag zelf wat mijn pc wel en niet toestaat of wat er wel of niet aan apps op mijn telefoon komt.

[Verwijderd]

Als het niet werkt dan verwijderen ze het toch gewoon mijn part is het geschreven in Lua en dan omgezet naar c idc zolang het maar werkt!

[Mathijs]

Het zou mooi zijn wanneer adobe ze eens een hak terug zou zetten en flash uit zou brengen voor de iphone via cydia of rock. Dan is er ineens een heel belangrijke reden bijgekomen om te jailbreaken.

Ik wordt inderdaad ook moe van dat dit mag niet dat mag niet gedoe.

Wat nu trouwens wanneer een ontwikkelaar na de vertaling naar C de code van comments voorziet en zegt dat hij het direct zo geschreven heeft?

[topaj]

Ik ben het dit keer ontzettend eens met Apple. en wel om de volgende redenen:
1. Alle ontwikkelaars die ooit eens een Hello World flash game hebben gemaakt, gaan massaal met zijn allen de appstore volpompem met rotzooi
2. Er gaan bedrijven komen die voor $ 2 je flash game wel willen hosten, en evt. omzetten.
3. Dit zijn niet optimaal C geschreven applicaties, dus dat gaat zuigen.
4. We hebben al 200 000 applicaties, waarvan 80% troep is, dus meer troep hoeft er wat mij betreft niet meer bij
5. Als ontwikkelaars echt zo lui zijn om Cocoa te leren, dan zijn ze het niet waard om de App Store vol te donderen met troep
6. Hoe lang gaat het approval proces dan wel niet duren??

Btw, hoe is apple eigenlijks van plan te detecteren of het door bijv. Flash is gemaakt??

Voor Android, die nog flink van apps moet hebben om iPhone OS in te halen, kan die hulp wel gebruiken

[Reactie gewijzigd door topaj op 23 juli 2024 03:32]

[- peter -]

Onzin.

1. Daar moeten ze 99$ voor dokken, dus nee dat doen ze niet 1,2,3. Die tools om flash of c# naar objective-C om te zetten zijn ook niet gratis. dus nee.
2. Dat zou kunnen, mooi toch. Levert geld op. Meer keus voor de eindgebruiker.
3. Om zo'n framework te bouwen moet je wel een aardig goede programmeur zijn. Aangezien het framework door dat soort mensen ontwikkeld wordt, zal de code die eruit komt rollen juist zeer goed zijn.
4. Misschien moet apple dan eens een goed filtersysteem gaan aanbrengen waardoor je de troep eruit filtert. Liever op troep filteren dan op development-environment.
5. Lui? Je moet eens een code-base hebben van hier tot tokio voor je domain-model en dan dat allemaal overporten naar Objective-C... Dat is pas weggegooid geld. Als developer kan je echt niet alleen voor Iphone ontwikkelen tegenwoordig. Zeker niet als straks WP7 mee gaat doen. Wil je een groot marktaandeel, dan moet je cross-platform werken.

[EoG]

Ik ben het niet met je eens.

Niet alle apps worden toegelaten tot de Appstore (en ja, er zijn natuurlijk ontzettend veel nutteloze apps die wel worden toegelaten), je spreekt zelf al over het approval proces

Er zijn genoeg talentvolle Flash "programmeurs" die wel kwaliteit leveren en vaak zelfs zeer interessante en/of vermakende progjes afleveren. Daarnaast heb jij het voornamelijk over games; maar kijk eens naar de potentie van Flash; short films, applicaties zoals agenda's en dergelijke (kan altijd verbeterd worden op persoonlijke wensen).

Hoe Apple van plan is dat te detecteren?...plugin?

[_beevee_]

Voor grote bedrijven is het niet zo'n probleem om meerdere versie in meerdere talen te bouwen. Maar de meeste bedrijven hebben maar een beperkt budget en willen graag een toepassing die eenmaal gebouwd is op alle moderne platforms kunnen aanbieden.
O.a. Flash maakt dat mogelijk via AIR, FlashPlayer of Flash IDE iPhone packager.

Dus vanuit een ontwikkelaars perspectief en hun (MKB) klanten is dit een achteruitgang.

Ad 3. Maak je jezelf nu wijs dat iedere app die rechtstreeks in object-c geschreven is automatisch geopitmalisserd is? ... de Flash object-c libraries zullen dat daarentegen automatisch wel zijn

[jj71]

1. Alle ontwikkelaars die ooit eens een Hello World flash game hebben gemaakt, gaan massaal met zijn allen de appstore volpompem met rotzooi

Nogal een onzinnig argument. Jij bent dus bang dat het "te makkelijk" wordt om een iPhone app te maken? Apple controleert alle apps al zo streng, je hoeft niet bang te zijn dat de app store volgepompt wordt met rommel.

2. Er gaan bedrijven komen die voor $ 2 je flash game wel willen hosten, en evt. omzetten.

Nou en? Wat is daar tegen?

3. Dit zijn niet optimaal C geschreven applicaties, dus dat gaat zuigen.

Hoe weet je dat? Dat is helemaal niet noodzakelijkerwijs zo.

4. We hebben al 200 000 applicaties, waarvan 80% troep is, dus meer troep hoeft er wat mij betreft niet meer bij

Dat heeft helemaal niets te maken met waar het onderwerp over gaat (in welke taal de apps geschreven worden).

5. Als ontwikkelaars echt zo lui zijn om Cocoa te leren, dan zijn ze het niet waard om de App Store vol te donderen met troep

Tsjonge, wat een nonsense, daar kan geen zinvol antwoord op gegeven worden.

6. Hoe lang gaat het approval proces dan wel niet duren??

Waarom zou dit het approval proces langer maken? Apple kijkt niet naar de source code van ingeleverde apps.

[marsian]

het lijkt bijna opzet! Adobe pesten ofzo. Of hebben ze hiervoor een goede reden?

[Mektheb]

Flash is oud en slurpt veel kracht, verder zijn er genoeg alternatieven en als ze kunnen kiezen voor wat anders hebben ze weer een eigen deeltje markt erbij, inplaats van de 100 en 1 die wel voor adobe kiezen

[RM-rf]

In dit geval zouden bv applicaties die via de Flash ontwikelomgeving ontwikkeld zijn als 'port' voor de iPhone zelf niet meer flash gebruiken maar omgezet zijn..

Apple zal het doen om te voorkomen dat er veel snel en makkelijk ontwikkelde applicaties beschikbaar zijn die echter meestal weinig optimale performance hebben en waarschijnlijk ook qua uitvoering een 'snel-en-goedkoop' ontwikkeltraject hebben (wat meestal ook wel iets kan zeggen over de 'kwaliteit' van dat soort apps)..

natuurlijk is het ook qua machtspositie van apple zo dat ze concurrentie vrezen van een sterke ontwikkelomgeving die eigendom zou zijn van een stevige concurrent, wat Adobe nu eenmaal is... 'native' iPhone ontwikelaars hebben hierdoor minder concurrentie te vrezen.

Het is natuurlijk een beslissing die Apple _kan_ nemen doordat ze al een enorm sterke machtspositie hebben op de markt van mobile Apps én een groot aanbod... daardoor heben ze ook de ruimte..

wél maakt het imho des te duidelijker dat er geen goede legale wijzes bestaan om buiten de door apple beheerste App-store zelf applicaties te kunnen installeren op de iPhone...
an sich vind ik het niet eens zó erg dat Apple bepaalde 'voorwaardees' stelt die in veel opzichten voor gebruikers ook zo hun voordeel kan hebben (nl. dat deze duidelijke native ontwikkelaars bevoordeeld, wat toch meestal ook 'betere' apps oplevert qua performance en design en uitwerking)
echter zou het vanuit concurrentieoogpunt wél zinnig zijn als men via anti-trust-wetgeving toch ook probeert te bereiken dat apple iig legale wegen toelaat voor mensen om dan ook applicaties van derden te installeren buiten de App-store en haar regels en voorwaarden om, desnoods zelf in een sterkere sandbox oid, of ingeperkte rechten

[Reactie gewijzigd door RM-rf op 23 juli 2024 03:32]

[chrisO]

Maar een applicatie geschreven in ActionScript (Flash) die mbv die packager wordt gecompileert naar native iPhone Applicaties zijn GEEN Flash meer en slurpt dus ook niet veel kracht meer!

[oxo]

Precies!

En op http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/ is een aantal voorbeelden te vinden van apps die al in de appstore staan en gecompileerd zijn vanuit een prerelease versie van Flash CS5. Keurige apps als je het mij vraagt.

[OddesE]

...en slurpt dus ook niet veel karcht meer vind ik wel heel kort door de bocht! Ook in C kun je trage apps bouwen hoor!

Maar ik ben het met marsian eens dat dit lijkt op Adobe pesten...

Misschien is het dat dus wel?
Zoals ik hierboven al eerder zei komen we er denk ik alleen achter door te kijken naar de product portfolio's van deze bedrijven en eventuele andere overeenkomsten die ze hebben (geprobeerd?) te sluiten en op zoek te gaan naar het strategische belang van Apple om Flash buiten te sluiten (en daarmee Adobe onder druk te zetten).

Hoe dan ook denk ik dat dit een bedrijfspolitieke maatregel is en geen technische, hoezeer Apple ook probeert om het onder die noemer te 'verkopen' aan het publiek.

[PatrickH89]

Mits er verantwoord geprogrammeerd wordt valt dit meestal wel mee. Het ligt meer aan incompetente programmeurs dan aan Adobe zelf denk ik.

Dus stel dat iedereen lekker in Javascript rotzooi gaat programmeren gaan ze dit soort applicaties ook blokkeren in de toekomst? ^^

[Verwijderd]

En dat is wat Apple en ook het merendeel van de gebruikers niet kan appreciëren. Als Apple mij een snelle telefoon beloofd dan wil ik dat aan die belofte gehouden wordt. Kan mij het een ruk schelen dat Apple dat niet kan garanderen omdat de verantwoordelijkheid bij de devs valt. Moest ik apps schrijven zou ik niet liggen optimaliseren tot perfectie maar ik verwacht het als consument wel van zo'n apparaat.

Een telefoon is zo'n belangrijk apparaat dat het gewoon perfect moet werken. Je wil echt niet voor hebben dat je 112 nodig hebt maar dat je eerst moet herstarten omdat er geen geheugen meer vrij is. Met een computer steekt het allemaal niet zo nauw maar een telefoon wordt beschouwd als een lifeline, die moet dus perfect werken.

[.oisyn]

Leuk antwoord, maar compleet niet relevant, om twee redenen: native applicaties zijn niet per definitie snel, en flash applicaties zijn niet per definitie langzaam. Als efficientie echt zo'n groot punt was geweest dan hadden ze Objective-C en Javascript development ook aan banden gelegd.

[ZpAz]

Heb je benchmarks ofzo van dat 'Objective-C' zoveel trager zou zijn dan bijvoorbeeld C++? Of verwacht je dat iedereen in ASM moet gaan schrijven.

[Reactie gewijzigd door ZpAz op 23 juli 2024 03:32]

[newinca]

... dan hadden ze Objective-C en Javascript development ook aan banden gelegd.

Ten eerste: ObjC is stukken sneller dan Flash. In de meeste gevallen even snel dan C: het is slechts een dunne wrapper, tenzij je aggressief aan introspectie e.d. gaat doen. NextStep op een 25MHz machientje was meer dan snel genoeg en ook in ObjC geschreven.
Ten tweede: alle high-level API zijn ObjC en dus is het de natuurlijke taal om apps te schrijven.
Ten derde: Javascript is NIET toegelaten voor apps. Enkel voor WebApps. Maar dat had het genie dan dit artikel geschreven heeft natuurlijk niet opgemerkt.

[Reactie gewijzigd door newinca op 23 juli 2024 03:32]

[_beevee_]

Flash is bij de tijd en is zeer krachtig.
Er is geen enkel volwaardig alternatief.

Overigens gaat het hier om de Flash IDE die Native iPhone apps compileeert en niet iets dat FlashPlayer gerelateerd is.

[Hellsystem]

Geen enkel volwaardig alternatief voor flash? Misschien moet je eens onderzoeken wat je met Silverlight kan In Microsoft Expression Blend 3 bijvoorbeeld

[Punksmurf]

Ik denk (denk, want ik kan zo gauw geen bron vinden) dat de marktpenetratie van Flash hoger is dan die van Silverlight, dus wat dat aan gaat is Flash beter. Flash is ook laagdrempeliger dan Silverlight.

Daartegenover staat dat Silverlight voor zover mij bekend is wel een stuk krachtiger is.

[Hellsystem]

Tja het is maar net wat je wilt ontwikkelen, maar bijvoorbeeld een simpele banner. Maak je sneller in Silverligt dan in Flash, Flash maakt (volgens mij) niet zelf de layers aan voor de objecten die je gebruikt. Dit is iets wat silverligt wel doet

En dan er bij je hoeft in sommige gevallen geen lijn code te typen om mooie effecten aan dingen te geven ...

[Reactie gewijzigd door Hellsystem op 23 juli 2024 03:32]

[Punksmurf]

Banners maken doe ik sowieso niet aan

Het feit dat ik Flash laagdrempeliger noem komt voornamelijk doordat ik weet dat er massa's (en dan ook massa's) aan informatie en tutorials te vinden zijn online. Veel zijn overigens wel van discutabel niveau maar dat geeft wel aan dat vrijwel iedereen er mee kan werken. Vervolgens kan je dan makkelijk doorgroeien tot het professionele gebied. Voor Silverlight is dat aanbod toch wel een stuk kleiner, waardoor je toch een stukje hoger instapt. Dat is ook niet direct slecht, het heeft daardoor toch minder het imago van een prutswerk .

offtopic:
Objecten staan in principe wel allemaal op hun eigen laag, al zie je dat in de Flash IDE niet. Niet dat je je daar doorgaans druk over hoeft te maken. Volgens mij is het wel mogelijk om voorgeprogrammeerde effecten en transities te gebruiken (transities zitten in ieder geval in FlexBuilder, daar kan je gemakkelijk wisselen tussen div viewstates) zonder extra code maar ik heb daar eerlijk gezegd geen kaas van gegeten. Ik werk vrijwel nooit in de IDE, als programmeur zit ik gewoon in de code te wroeten.

Moet zeggen dat ik geen ervaring heb met Silverlight (anders dan als eindgebruiker). Ik zou niet eens weten waar ik moest beginnen. Ik ben al lang voornemens het eens uit te zoeken maar het komt er maar niet van.

Ik zit ook wel lekker comfortabel vastgeroest in m'n Flash/Flex-wereldje waar ik alles onderhand perfect weet te vinden dus daarom kan ik allicht geen al te accurate vergelijking trekken.

[DeFeCt]

Afgezien van het feit dat Silverlight inderdaad een volwaardig alternatief is draait het volgens mij ook niet op de iPhone?

[RM-rf]

SVG wél en HTML5+SVG bieden weinig meer dat Flash niet kan ...
wél heeft Flash een zeker voordeel van een sterk ontwikkelplatform dat onder ontwikkelaars erg populair is en de mogelijk biedt op een snelle wijze applicatie's te ontwikkelen...
grotendeels ook via een zeer 'visuele' werkwijze met drag-and-drop, waarbij veel minder programmeerkennis benodigd is om toch snel resultaten te bereiken..

Dat is natuurlijk ook een deel van de kritiekpunten op flash... niet eens dat Flash zelf per definitie altijd slecht is, maar door de lage drempel zullen ok veel minder optimale ontwikelaars er gebruik van maken en deze ook snel toepasingen maken die de gebruikers eerder veel ergernis kunnen opleveren of weinig 'usabel' zijn ...

ondanks dat Flash wél gebruikt kan worden voor kwalitatief hoogstaande apps, die goede performance hebben en een hoge usability hebben is het helaas niet zo dat alle beschikbare flash-content aan zulke eisen kan voldoen.
en dan kan ook de 'onderkant' qua flash-apps voor veel mensen hun 'beeld/vooroordeel' gaan bepalen over wat flash doet.

[Mathijs]

Plus het feit dat het weer MS vendor lock-in betreft.

[_beevee_]

Nee er is geen volwaardig alternatief en dat is spijtig ik wou dat er 'tig' waren. Met volwaardig bedoel ik ook cross platform in de meest actuele versie. Overigens ben ik zeer gecharmeerd van Silverlight en volg het op de voet maar in mijn ervarign heeft Flash nog steeds een streepje voor wat betreft features én beschikbaarheid/penetratie.

[Supremo]

En wie zegt dat dat ook geldt voor de packager?

Ook wel grappig om te zien hoe mensen niet weten hoe ze snel ze moeten reageren op een 3-strikes wet, maar vrijheid voor je iPhone links laten liggen.

[blouweKip]

Het gaat om keuze, apple opereert in een markt met voldoende keuze, apple ontneemt niemand zn keuzevrijheid en probeert niet a la microsoft de keuzevrijheid op andere platformen negatief te beinvloeden.

De 3-strikes wetgeving komt direct voort uit de pogingen van een andere grote actor (mediakartels) om de marktwerking te beinvloeden dmv disproportionele maatregelen, dat treft een heleboel mensen die er niet voor kiezen.

[Virtuozzo]

Voorzichtig, zowel Apple als Microsoft hebben belang bij activiteiten die invloeden vanuit andere platformen beperken. Kanttekening is wel dat het nu op heel andere markten dan de systemen gaat, en daar heeft Microsoft baat bij een hogere diversiteit, terwijl Apple baat heeft bij een stricte controle en zelfs beheer van eventuele diversiteit.

http://www.joelonsoftware.com/articles/StrategyLetterV.html
Een goede insteek hierbij.

http://www.joelonsoftware.com/articles/Platforms.html
Van hier af wordt het plaatje duidelijker.

[himlims_]

"instabiel en bron van potentiële fouten/gevaren" wat de 'kwaliteit' van apple niet ten goede komt.

[Blokker_1999]

Alsof je bij apps geschreven in C geen fouten kunt maken ... . Alles hangt af van de persoon die de software schrijft.

[OddesE]

Sterker nog, je kunt waarschijnlijk veel gemakkelijker veel ernstiger fouten maken als je in C programmeert. C is een low-level taal die bijna directe controle over de hardware geeft. ActionScript is een scripttaal die door een interpreter wordt geinterpreteerd 9of door een translator wordt gecompileerd naar een native taal).

[arjankoole]

Alsof je bij apps geschreven in C geen fouten kunt maken ... . Alles hangt af van de persoon die de software schrijft.

In de regel zijn C coders wel een stuk beter in software schrijven, dan flash-bouwers. (niets slechts over flash bouwers overigens, maar doorgaans zijn dat meer grafici dan coders, ieder z'n vak)

[Verwijderd]

En nu gaan die flashbouwers dus knoeiapps met C in elkaar prutsen. Beter?

[arjankoole]

De kans dat ze zover komen dat ze daadwerkelijk het ding kunnen submitten naar de appstore is een stuk kleiner dan. Die drempel is veel te hoog voor iemand die kan ontwerpen en niet programeren.

Kans is dan zeer groot dat ze dan gewoon het coden door een programeur laten doen. Wat denk ik gewoon een goeie app zal leveren.

[Verwijderd]

En dán staat Apple klaar met hun kwaliteitscontrole.

[Dannydekr]

Het geldt ook voor Javascript, en andere converters. In de praktijk moet echter nog blijken of ze alle apps tegen gaan houden die gebruik maken van dergelijke converters (is vrijwel niet te controleren namelijk). Waarschijnlijk is het een soort 'beveiliging' zodat ze altijd kunnen zeggen tegen developers "je hebt er zelf voor getekend".

[Reactie gewijzigd door Dannydekr op 23 juli 2024 03:32]

[newinca]

In het overgrote deel van de gevallen is het heel eenvoudig te controleren: je kijkt of de app gelinkt is met bepaalde support libraries.

Voor Flash is dat een no-brainer: zelfs voor een hello world app voegt dat automatisch tientallen MB extra toe.

[Verwijderd]

- Betere ervaring voor klanten
- 'T is van hun dus ze mogen doen wat ze willen
- Er zijn toch maar enkele duizenden apps op de velen die zo worden gecompileerd

Als je nog niet overtuigd bent, kan je de comments doorlezen met andere redenen die appleboys uit hun duim zuigen.

[vgroenewold]

Leuk om het zo weg te zetten natuurlijk, maar vooral je 3e punt is denk ik een reden waarom ze dit zo gemakkelijk doen. 95% van alles apps worden, volgens mij, gewoon in Objective-C, danwel C geprogrammeerd. Wellicht heeft men gemerkt dat die overzettingen vanuit andere talen, slordige code opleverde wat wellicht weer heel irritant is om te reviewen en fouten in de code alleen maar vergroot. Maar zoals gezegd, 95% van de developers boeit dit dus zowiezo al niets en zo ja, dan zorg je er gewoon voor dat je je app niet met OS4 compileert, probleem opgelost.

[Verwijderd]

Nee nee, je hoorde nieuwe redenen uit je duim te zuigen. Ik had al enkele standaard antwoorden gegeven om jullie moeite te sparen.

[vgroenewold]

Maar geef eens tegengas dan met goede, niet uit de duim gezogen argumenten... dat is namelijk pas echt een discussie.

[newinca]

- Betere ervaring voor klanten

Absoluut!

- 'T is van hun dus ze mogen doen wat ze willen

Inderdaad.

- Er zijn toch maar enkele duizenden apps op de velen die zo worden gecompileerd

Gelukkig maar.

[Het.Draakje]

Neem de link uit dit artikel en klik even door. (Why did they change section 3.3.1)

Goede analyse en als gebruiker zeg ik, prima actie.

Ik heb liever een goede applicatie die consistent werkt volgens de richtlijnen zoals het OS dit oplegd dan een fit-all-os-almost.

Want dat is het nadeel van multi platform ontwikkeling, ieder platform heeft zijn eigen eigenaardigheden die dan niet (of slecht) ondersteund worden. Voor een Windows gebruiker zou dat bijv. in kunnen houden dat F1 iets anders zou betekenen dan "Help".

Voor iPhoneOS zou het kunnen inhouden dat multi touch niet ondersteund wordt omdat het in Windows Mobile ook niet kan.

[Verwijderd]

Want C, C++ en JS zijn geen multi platform programmeertalen... Duizenden programma's zijn multiplatform en werken op elk OS even goed. Heeft enkel te maken met hoe veel moeite de programmeur wil investeren.

Apple kan beter browsers verbieden want HTML is nog meer multi platform. Ze zouden iHTML kunnen "uitvinden" zodat het volledig op de iWhatever kan toegepast worden.


Hoe ver gaan jullie toch met zo'n technische zever op een site met technici.

[Verwijderd]

De marktwaarde van Adobe omlaag brengen zodat Apple Adobe voor een zacht prijsje kan overnemen.

[OddesE]

Optie 1. Plausibel denk ik, maar wel een beetje gezocht. Adobe is meer dan alleen flash.

Alsnog de eerste enigszins logische verklaring gebaseerd op bedrijfspolitiek en niet op technische (non) argumenten, en daarmee voor mij al veel aannemelijker dan het 'gebruikerservaring' onzin smoesje van Apple zelf.

[Virtuozzo]

Adobe heeft een zeer sterke vertegenwoordiging binnen wat Apple als haar eigen markt beschouwd, afkomstig uit het tijdperk van polarisatie met name in de grafische industrie, het is behoorlijk vroeg voor Apple om een dergelijk potentiële route te nemen .. maar in de tussentijd is er niks mis mee om Adobe uit balans te houden. In de tussentijd loopt Adobe tegen een aantal drempels op bij hun streven naar meer diversiteit en met name platform/service diversiteit.

Op zich geen uitzonderlijke situatie, al met al is het meer een zakelijk conflict waarbij het gegeven "Flash" een klein onderdeel van het geheel is, een wat breder perspectief is niet verkeerd.

We zullen zien. Het zou voor Apple niet verkeerd zijn om zowel volledig domein te hebben over haar eigen platform, zowel uit product als service invalshoek. Het geeft ze redundantie in gegarandeerde markten.

[DeFeCt]

Dat idee heb ik ook... Maandag wordt CS5 gelanceerd, het staat m.i. knap lullig dat Adobe met een feature komt waar je dus schijnbaar niks aan hebt. Doet Apple leuk zo even voor het weekend.

[-GSF-JohnDoe]

Hoe kan apple dit controleren. Moeten ontwikkelaars ook de sourcecode vrijgeven? Anders is het toch lastig om te zien van welke taal native code afhankelijk is.

[leuk_he]

Je kunt ook aan gecompileerde programma's zien dat ze met een bepaald framework gebouwd zijn. Apple staat nu ook al bepaalde frameworks niet toe. Dit doet apple door simpelweg "strings" uit de executable te extraheren.

Dus als in een "iphone" app ergens een sstring "CS5 Adobe packager" staat zal het worden afgewezen in de store. Nu ook kun je dit omzeilen al dev door bepaalde strings te vervormen in je framework.


Maar het waarom apple dit niet wil is me onduidelijk.

[OddesE]

Zoek redenen in de bedrijfspolitieke hoek. Eén plausibele optie is inmiddels genoemd:

Agressieve overname. Zodra ze Adobe overgenomen hebben werkt Flash "ineens" wel op de iPhone...

Andere verklaringen? Roept u maar!

[Dingen]

Maar het waarom apple dit niet wil is me onduidelijk.

Omdat je op deze manier ook in Windows iPhone apps kunt ontwikkelen.

[newinca]

Bingo!

Op dit moment is iPhone OS mijlenver de meest populaire App development platform.

Het is niet meer dan logisch dat ontwikkellaars hier eerst voor targetten voor ze concurrerende platforms aanpakken. Door Flash uit te sluiten wordt dat een stuk lastiger.

Slimme zet.

[arjankoole]

Hoe kan apple dit controleren. Moeten ontwikkelaars ook de sourcecode vrijgeven? Anders is het toch lastig om te zien van welke taal native code afhankelijk is.

even een voorbeeldje op een willekeurige linux machine:

user@host ~> strings </pad/naar/binary>
/lib/ld-linux.so.2
libpthread.so.0
pthread_attr_init
pthread_attr_destroy
pthread_create
pthread_attr_setstacksize
_IO_stdin_used


dat geeft al leuk wat weg.

[PrisonerOfPain]

Dergelijke symbols zitten toch ook gewoon in een naar C gecompileerde taal?

[arjankoole]

het is ook alleen maar ter illustratie dat er in een binary wat achtergrond informatie staat. (tenzij je 'm stripped)

[Dingen]

Je kan aan de binary met een hexeditor zien of de Flash Player is meegebakken.

[_beevee_]

De FlashPlayer wordt niet meegebakken, maar uiteraard wel een flash-features specifieke library en die zal zeker te dedecteren zijn.

[Hellsystem]

Nou het lijkt me dat apple de sourcecode wel/wil kan zien Anders zou je er altijd alsnog zooi in kunnen stoppen

[Verwijderd]

Het lijkt me dat je als developer gewoon geen risico wil nemen dat je app geweigerd of teruggetrokken wordt voor/uit de appstore.

[Verwijderd]

Hoe herkent een virusscanner een virus? Patroon herkenning in de binaries

[Dark_man]

Ik snap niet dat Adobe dit zomaar pikt?

Photoshop is toch HET programma die mede verantwoordelijk is voor het success van de Macintosh?

Dan kan Adobe toch ook gewoon de ontwikkeling van Photoshop voor Mac gewoon stoppen?

[Verwijderd]

Daar zit Apple niet zo mee hoor. Ze maken gewoon iets als Paint.net en dan zegt Steve Jobs: "What iPaint does is extraordinary, you can manipulate your photos!"
En dan zijn er genoeg mensen die zeggen dat het beter werkt dan Photoshop.
Zeggen sommigen: "het heeft niet zo veel functies als Photoshop"
Zeggen de iPaint gebruikers: "Dat is zo gedaan om iPaint stabiel te maken" en later krijgt iPaint toch wel het kloon-gereedschappen of mag je eindelijk aan curves trekken, gaat iedereen zeggen dat Apple goed bezig is.

[oxo]

Leuk geprobeerd jongen. Maar als je ziet dat Apple wel deglijk zeer professionele programma's maakt voor beeld, film- en audiobewerlking, denk ik dat ze inderdaad in staat zijn om ook een Photoshop alternatief te maken waar professionals mee kunnen leven. Kijk naar Aperture, Final Cut studio en Logic. Stuk voor stuk volwaardige professionele programma's.

Der bestaan trouwens geruchten dat Apple bezig is de hoofd applicaties uit de Creative Suite in eigen huis te ontwikkelen. het zou me niet verbazen als dat inderdaad het geval is.

[Verwijderd]

Ach, ja joh wat jammer nu dat je een PC hebt.

Laten we wel zijn in Aperture 3 mogen en kunnen we inderdaad al meer bewerkingen uitvoeren dan er mogelijk zijn in Lightroom 3 (beta) en Final Cut Pro wordt door vele Pro's inderdaad liever gebruikt dan Adobe Premiere.

Bovendien de Adobe Creative Suite kost een lieve duit, dat wil je niet weten!!!
En iedere anderhalf jaar wordt je door Adobe verplicht een nieuwe versie te kopen....
Ik zou blij zijn als Appel voor een appel en een ei een volledige Photoshop kloon weet te maken

[blouweKip]

Lagere afschrijving/TCO, eindelijk iemand die het licht heeft gezien

[PrisonerOfPain]

Het enige probleem daar mee is natuurlijk dat ze dan zichzelf ook flink in de polsen snijden omdat ze een redelijk stuk markt zien verdwijnen. Daar in tegen blijkt in mijn omgeving wel dat vrijwel iedere mac gebruiker die ik ken dat doet omdat 'ie in de grafische sector zit.

[ArgantosNL]

daar hebben ze meer zich zelf mee dan adobe.
mensen kunnen gewoon omschakelen naar een ander OS.
anders zouden ze in eens alles moeten gaan converteren met alle gevolgen van dien.

[Osxy]

Je vergist je hier erg in, een groot deel van de grafische wereld draait op macs.

Zij zullen niet 123 pc's kopen omdat Adobe geen Mac software meer maakt.

[Menesis]

Dat was toch vroeger? Ik ken eigenlijk maar 1 programma dat alleen voor mac bestaat en niet voor windows en dat is Logic (muzieksoftware)

[oxo]

+ Final Cut Studio (een van de meest gebruikte editing programa's) en Aperture (tegenhanger van Lightroom van Adobe).

[Erwin_Br]

En Final Cut.

Ik geef je gelijk, trouwens. Ik heb ook de indruk dat steeds meer studio's overschakelen naar Windows. Daar draait de CS suite lekker in 64-bit mode en kun je meer geheugen gebruiken. In on-screen tutorials e.d. zie je ook steeds vaker de Windows versie. En dan heb ik het niet over YouTube filmpjes, maar over bedrijven als DigitalTutors, Lynda, etc...

[Reactie gewijzigd door Erwin_Br op 23 juli 2024 03:32]

[Verwijderd]

Microsoft heeft vooral met Windows 7 een sterk os in de hand, het ziet er allemaal erg gelikt uit en het werkt heel snel en goed. Mac OSX heeft dit ook, maar, de drempel naar Windows is lager. (Je zit niet vast aan 1 leverancier voor hardware ed.)

[Verwijderd]

Het verschil zit hem niet in de beschikbare software, maar in de gebruiksvriendelijkheid van OSX. Dat is tegelijkertijd de reden dat Apple door velen wordt vereerd.

[Verwijderd]

Toch is dit iets wat Windows 7 óók heel goed doet.

[newinca]

Het verschil zit hem niet in de beschikbare software, maar in de gebruiksvriendelijkheid van OSX. Dat is tegelijkertijd de reden dat Apple door velen wordt vereerd.

Werkelijk? Dat is nieuw!

Het zelfs al zou het zo zijn, het is irrelevant: er zijn ontelbare designers, computer analfabeten, die heel hun leven enkel en alleen Mac gebruikt hebben, nooit iets anders gekend hebben.

Je zou als werkgever oliedom moeten zijn om die plots om te scholen naar een ander platform, met andere short-cuts (en minder stabiel en minder gebruiksvriendelijk en meer virussen etc.)

[resma]

Omdat Adobe een commercieel bedrijf is (net als Apple overigens) en dus niet uit principiele overwegingen een besluit kan nemen.

Zouden ze dat wel doen, en zouden ze CS5 voor Apple bijvoorbeeld eens een paar maandjes vertragen, dan wordt het een hele interessante zaak, want ik denk dat de CS suite voor de meeste (ook commerciele) grafische bedrijven toch meer meerwaarde heeft dan het Apple platform...

[ocdaan]

Dat kan Adobe wel doen maar dan verliezen ze direct de helft (?) van hun afzetmarkt... lijkt me niet handig dus

[_beevee_]

mja misschien als ze nu aankondigen dat het onzeker is - gezien Apple de deur dicht houdt voor Adobe - of er na CS5 nog Adobe software voor de Mac uitkomt dat menig design bureau bij de volgende Mac vervangingsronde nog voor Mac's kiest. Dat bijvoorbeeld in combinatie met speciale actiepakketten van gecertificeerd top-notch PC hardware met Adobe CS6 voorgeïnstalleerd of zo .... wie weet

[MSalters]

Designers kiezen voor Macs omdat Photoshop erop draait, niet andersom. Windows werd meteen een stuk populairder onder designers toen Photoshop voor NT beschikbaar kwam (mede omdat NT destijds multitasking en stabiel was, en Mac OS9 niet).

Anderzijds zou ik als Adobe niet zover gaan. Ik zou het meer zoeken in een publiek statement dat je Grand Central en andere Apple technologie niet ondersteund, maar wel DirectX 11. Zet Apple weg als een tweederangs platform, legacy.

[Ford Prefect]

Ik denk dat de invloed en macht van DTP hoek de laatste jaren behoorlijk is afgenomen in Apple land. Vroeger waren het vooral de DTP-ers en muzikanten die Apple groot hielden. De 'normale' gebruiker is nu een veel grotere userbase. De ontwikkeling van Adobe apps op OSX is de laatste jaren zowiezo al tergend traag.

Ik denk niet dat eindgebruikers echt wakker liggen van dit nieuws, zei willen gewoon snelle en goede apps hoe ze verder worden gemaakt zal ze een rot zorg zijn

Trouwens OS9 had wel degelijk iets van preemptive multitasking maar het was echt beroerd uitgevoerd waardoor een crashende applicaties in 9 van de 10 gevallen een reboot van je Mac inhield.

[Noxious]

Daar zat ik dus ook aan te denken, de Mac is vooral bekend geworden als grafisch platform bij het grote publiek, vooral vanwege Photoshop.

Van die oude liefde lijkt niet veel meer over te zijn.

[OddesE]

Dat is optie 2:

Apple en Adobe hebben ruzie over een ander product (zoals Photoshop) en Apple oefent nu druk uit door Flash te bannen van de iPhone.

Meer verklaringen??

[badflower]

volgens mij schrijft Adobe hun software niet specifiek voor de Mac, maar in eerste instantie voor Windows. Daarna compileren ze het voor Mac, met als gevolg dat het merkbaar trager werkt - of in ieder geval slomer aanvoelt - op dat platform (ik spreek uit ervaring).

Dan maakt Adobe ook nog eens een zeer brakke flash player voor de Mac. Eigenlijk zelfde verhaal, in eerste instantie geschreven voor Windows, daarna gecompileerd voor Mac: heel erg brak - neemt vaak 80%-90% resources als er bijv. een flash banner op een webpagina staat

Dus de relatie Apple <> Adobe is gewoon niet goed. Adobe profiteert van het Mac platform, maar vertikt het om goede software te leveren. Waarschijnlijk is de Apple markt dus toch gewoon te klein voor Adobe.

Ik kan me voorstellen dat Apple het een beetje met Adobe gehad heeft. Dus Apple heeft nu als strategie om niet meer afhankelijk te zijn van Adobe mbt rich internet, en switched naar HTML5.

Maar ik kan me bijna niet voorstellen dat wat in dit artikel staat besloten is door Apple om Adobe dwars te zitten. Ik denk dat ze alleen optimaal geschreven apps willen nu ze multi-task gaan toestaan....

[blouweKip]

Dus de relatie Apple <> Adobe is gewoon niet goed. Adobe profiteert van het Mac platform, maar vertikt het om goede software te leveren. Waarschijnlijk is de Apple markt dus toch gewoon te klein voor Adobe.

Ik vermoed idd dat dat de primaire reden is, ik kan me ook voorstellen dat apple geen zin heeft adobe nog meer marktmacht te geven op de platformen die apple uitbrengt, afhankelijk zijn van een software huis welke jou platform als 2e keus behandeld lijkt me iets wat niemand graag zou willen.

[field33P]

Achja, Apple maakte toch al Flash onmogelijk, dus wat geeft het?

[PatrickH89]

Ja, maar dus niet als de code uit Flash dus gecompileerd wordt voor de iPhone lijkt me. Ik vind het een beetje zonde. Ik vraag me eigenlijk ook wel af wat het praktische nut hiervan is, als deze al bestaat..

[OddesE]

Ik denk dat je (we) op zoek moeten naar het strategisch belang van Apple in deze?

Heeft Apple misschien zelf een product (in de maak) dat concurreert met Flash?

Zijn er wrijvingen tussen beide bedrijven?

Probeert Apple wellicht druk op Adobe uit te oefenen om op een ander vlak (Photoshop?) iets af te dwingen van Adobe? Iets van: Als jullie Photoshop versie X niet snel porten naar MacOS versie Y dan laten wij geen Flash op de iPhone toe? Ik kan me herinneren dat in het verleden Apple zich nogal geergerd heeft aan Adobe omdat het een aantal applicaties levert die heel veel gebruikt worden op Macs (Photoshop o.a.) maar Adobe niet snel genoeg wou porten naar nieuwe versies van Mac OS, wat de positie van Apple bedreigde...

Of is het misschien nog iets anders?

Eén ding lijkt me vrij zeker worden door dit nieuws... dit heeft bijna niets met techniek te maken en lijkt meer op een 'crusade' tegen Flash en/of Adobe...

* OddesE vindt het niet erg en hoopt alleen maar dat dit leidt tot minder Flash en meer HTML (5) op de gemiddelde webpagina

[Verwijderd]

Adobe heeft er zelf alleen maar voordeel bij om de nieuwste versies van Photoshop ook meteen voor MacOS beschikbaar te hebben omdat de meeste grafische designers voor zover ik weet gebruik maken van macs...

[Roytoch]

Plus de CS4 werkt prima op 10.6.2, zal ook CS5 wel doen. Ik denk dat dat het dus niet is.

[Virtuozzo]

Heh, dat plaatst een serie user posts van oud macromedia medewerkers die bij adobe actief waren en hun afscheid posts maakten omdat ze bij Apple gingen werken, twee à drie jaar geleden, misschien toch in een interessant ander daglicht

Edit. Na wat navraag her en der.. iWork later dit jaar, interessante featureset met een eerste stap tegen Adobe's huidige software portfolio. Al is er nog geen openlijke bevestiging, de eerste hints van een Apple versie van alvast Dreamweaver beginnen op te duiken.

[Reactie gewijzigd door Virtuozzo op 23 juli 2024 03:32]

[Flow]

Flash CS5 krijgt een Packager for Iphone, waarmee applicaties die in Actionscript 3 zijn geschreven, worden gecompileerd naar native iPhone-applicaties.

Dus dan had het waarschijnlijk wel gewerkt op de iPhone

[The Elementz]

Ik heb voor school een keer gebruik gemaakt van de sleur-en-pleur methode met Netbeans om een Java interface op te bouwen. Toen ik daar de code van zag, dacht ik mijn hemel wat een zooitje.

Met Eclipse heb ik alles handmatig gecoded en ik kan zeggen dat het aantal regels behoorlijk verschilt. mijn applicatie deed hetzelfde als die van Netbeans, maar was kleiner, minder code en persoonlijk duidelijk ingericht (code moet voor mij netjes staan).

Ik heb zelf met AS3 goede ervaringen met de performance. Ik heb een quiz framework gebouwd die zijn content uit een XML-document haalt. Dit was voor een proof-of-concept. Uiteindelijk heb ik geadviseerd om de output van een cursus in HTML en JavaScript te doen.

Met de timeline bepaal je per frame wat de bezoeker te zien krijgt. De frames en keyframes vormen de uiteindelijke basisstructuur van de applicatie of animatie. Ik heb hier weinig ervaring mee en kan er niet lekker mee werken. Het lijkt mij dat deze methode de meest buggy programma;s opleveren. Wellicht dat iemand hier meer over weet

Ik een voorstander van zo min mogelijk conversies van een taal naar een ander. Je kan niet verwachten dat een compiler van de conversie alles goed overzet. Ik vind dat de mensen die applicaties voor de iPhone willen schrijven de taal leren. Ik heb VB.net op het mbo gehad en thuis was ik bezig met C, C# en php. De manier van een statement schrijven is even wennen en na een beetje oefenen moet dit geen probleem meer zijn. Tijdens mijn mbo-stage moest ik met C++ werken en op het HBO met Java. Met beide talen ben ik aan de gang gegaan en wat simpels gemaakt. Ik maakte de applicatie steeds complexer tot wat ik had wat ik wilde. Ik keek in het begin veel naar de syntaxen, maar dat wordt met de tijd steeds minder.

Meestal als ik aan het surfen ben en mijn browser crashed, dan is bijna altijd Flash de oorzaak. Het is dat ik voor bepaalde sites flash nodig heb, anders had ik definitief vaarwel gezegd tegen Flash. Met dit oogpunt kan ik Apple's punt wel begrijpen.

@ Punksmurf
Je hebt heIemaal gelijk. Ik heb alleen een vergelijking gemaakt tussen de talen en heb derest buiten beschouwing gelaten. Ik heb wel meer ervaring met AS x.x buiten deze twee projecten.
Verder heb ik eens meegemaakt dat een update van de Java Runtime engine de applicatie niet meer werkte. Terug naar een eerdere versie werkte weer perfect. Het is ook mogelijk dat je code (deels) onbruikbaar is binnen dezelfde omgeving. Tevens het concept dat je hebt uitgedacht om iets te realiseren bestaat nog, alleen krijgt het een andere invulling in de code. Het is makkelijk gezegd dan gedaan.

Dat met flashbrowser is idd totaal ongerelateerd. Ik ga ervan uit dat er een relatie is tussen de Flash en Flash-plugin. In mijn beleving vind ik Flash gewoon vervelend en die ervaring trek ik door naar Flash. Wellicht niet helemaal terecht.

@CT
Ik ben het helemaal met je eens. Het handmatig coderen van knoppen is niet handig en niet verstandig. Het kostte me ook heel veel tijd om dat goed te coden, terwijl het droppen van item 1000x sneller is. Het gaf me wel vergelijkingsmateriaal met de output van netbeans. Als je in projecten werkt met tijdsdruk ga natuurlijk niet weer het wiel uitvinden.

@Beide
Tijdens mijn HBO study ben ik niet verder gegaan met programmeren. Ik vond het toch niet bij mij passen om continue te coden. Dus heb ik maar alle andere richtingen gedaan op programmeren na

GreetZ

[Reactie gewijzigd door The Elementz op 23 juli 2024 03:32]

[Punksmurf]

Ik heb hier weinig ervaring mee en kan er niet lekker mee werken.

Dat is duidelijk, want anders zou je die tijdlijn gewoon niet gebruiken. Het enige waar wij de tijdlijn voor gebruiken is animaties (waar dat ding ook voor is).

Ik ben het er mee eens dat een extra vertaalslag nooit ten goede kan komen (het resultaat is op zijn best even goed), maar verder klets je een beetje onzin. Twee projectjes doen in een onbekende omgeving noem ik niet direct 'goede ervaring'.

Ik vind dat de mensen die applicaties voor de iPhone willen schrijven de taal leren.

Leuk dat je dat onderbouwt aan de hand van de syntax, maar wat je blijkbaar nog niet doorhebt is dat de syntax maar een klein deel uitmaakt van het verschil.
Naast de compiler maak je immers ook (meestal) gebruik van diverse frameworks voor bijvoorbeeld grafische elementen, gebruikersinvoer, gui, geluid en netwerken. Je zal ook daar mee moeten leren omgaan.

Als jij als developer bijvoorbeeld al veel ervaring hebt met framework dat Adobe biedt met Flash/Flex (of dat van Unity, of wie dan ook) dan is het natuurlijk uitermate praktisch dat je daar ook mee kan werken als je een applicatie voor de iPhone (of welk platform dan ook) wil ontwikkelen. Overschakelen naar xCode in dit geval betekent niet alleen wennen aan een nieuwe syntax, maar ook het leren werken met nieuwe frameworks. Daarnaast is al je oude code onbruikbaar, wat natuurlijk erg vervelend is als je een applicatie op meerdere platforms wil uitbrengen.

Meestal als ik aan het surfen ben en mijn browser crashed, dan is bijna altijd Flash de oorzaak.

Totaal ongerelateerd. We hebben het hier niet over een browser met een plugin-architectuur maar over native applications.

[CT]

..en dan wil ik nog toevoegen dat je schoolvoorbeeld met een sleep-en-drop omgeving (in dit geval Netbeans met swing) totaal anders is dan Eclipse. Dit zijn ook al twee verschillende omgevingen en twee verschillende grafische schillen op java.

En daarbij is het 'RAD' ontwikkelen van een GUI heel erg prettig. Wacht maar tot je ergens moet werken en er tijdsdruk is - maar je wel overzicht wilt behouden.
Dan ga je echt niet handmatig knopjes programmeren in een GUI - als je weet dat de klant volgende week alle knopjes op een andere plek wilt.

Dan boeit dat beetje extra overhead code totaal niet.

Verder als aanvulling op Punksmurf is het echt een ellende om als bedrijf ineens al je programmeurs te moeten 'omscholen' of te 'ontslaan' omdat ze geen iphone app kunnen bouwen, nieuwe hardware kopen of nog erger, het verplicht moet gaan uitbesteden.

[Twazerty]

Je bent in Netbeans niet verplicht om de grafische designer te gebruiken. Onzin om zo de vergelijking met Eclipse te maken. In Netbeans kun je net als in de meeste andere IDE's met het handje je grafische interface opbouwen.

[wheeler]

Interessant leesvoer voor wie verder kijkt dan "Apple pest Adobe"

http://fbindie.posterous....oper-agreement-has-nothin

[- peter -]

Mooie!

Als het waar zou zijn, zou dat echt ontzettend short-sighted zijn denk ik. Ik bedoel, welke .Net developer gaat nu straks zijn applicatie naar de IPhone brengen? Nu kan het nog met monotouch. Maar dan?

Het lijkt me dat apple op die manier developers verliest, en zodoende zelfs de gave WP7 applicaties niet in een of andere vorm zal krijgen op hun eigen platform.

[WFG]

Volgens mij is dat artikel 'spot on'. Het gaat niet om Adobe, maar om het makkelijk kunnen distribueren van Apps naar alle mobiele platformen.

Wat een van de voordelen van het iPhone OS, de hoeveelheid apps, in gevaar brengt.

[Reactie gewijzigd door WFG op 23 juli 2024 03:32]

[Virtuozzo]

Veel sterke punten daar ja, interessant. goed gevonden link. Merci.

[- peter -]

Dit is echt absurd.

Lijkt erop dat ook projecten zoals Unity, en MonoTouch hiermee gebanned worden.
Oftewel, C# op IPhone.

Echt ziek. Het is toch belachelijk dat Apple gaat bepalen in hoeverre je frameworks mag gebruiken? Een reden des te meer om toch naar android over te stappen.

[Reactie gewijzigd door - peter - op 23 juli 2024 03:32]

[arjankoole]

Nee, dat doet 't niet perse.

En het hoeft niet eens een slecht ding te zijn. Ik zie liever een App die gebouwd is in C dan eentje die gebouwd en dan geconverteerd is in flash. Dat laatste zal in vrijwel alle geval een kwalitatief mindere oplossing zijn dan de eerste.

[_beevee_]

Misschien wel eerder het tegendeel. De c-library met flash specifieke features is door en door getest door zeer professionele ontwikkelaars dat zal eerder voorkomen dat een slechte app ontwikkelaar brakke apps gaat opleveren. En dan heeft Apple nog altijd de mogelijkheid om brakke apps te weigeren ongeacht met welek tools ze gebouwd zijn.

[Dreamvoid]

Dit is precies hetzelfde argument dat de alles-in-assembly adepten altijd gebruikten. Je hebt wel heel veel vertrouwen in de programmeerkunsten van C programmeurs...

[arjankoole]

Dit is precies hetzelfde argument dat de alles-in-assembly adepten altijd gebruikten. Je hebt wel heel veel vertrouwen in de programmeerkunsten van C programmeurs...

Is dat zo gek? Het merendeel van wat ik gebruik is in C, C++ of objective-C gemaakt. Naar mijn beleving willen de jongere programeertalen het zo makkelijk mogelijk maken, maar doen daar alle concessies aan goed. Maak je een foutje? de IDE fixed 't wel voor je. Echt inhoudelijk, goed, en secure programeren zie je daardoor veel en veel minder.

[buzzin]

Tja....kijken iPhone gebruikers....of liever Apple gebruikers hier van op?
Het is al jaren bekend dat Apple alles aan banden legt tot aan het absurde aan toe.....dus doe normaal, dit is geen schokkend nieuws. Eerder het zoveelste bewijs dat Apple je geen vrijheid geeft.....

Als je die vrijheid wel wilt hebben kun je prima iets kopen waar geen Apple logo op staat....

[vgroenewold]

Lees eerst gewoon eens rustig waarom Apple dit doet of zou doen, er zitten nadelen aan vast, maar lang niet zo dramatisch als je het nu stelt. Gebruikers merken hier echt nauwelijks tot niets van.

[- peter -]

Wat dacht je van alle Unity3d games? Zijn er nogal wat die vrij hoog staan in de ranking. En die zijn geschreven middels Unity3d, die weer gebruik maakt van Mono. Oftewel C#. Oftewel een vorm van crosscompiling. Dat gaat er dus ook allemaal uit,

[Erwin_Br]

Wat dacht je van alle Unity3d games? Zijn er nogal wat die vrij hoog staan in de ranking. En die zijn geschreven middels Unity3d, die weer gebruik maakt van Mono. Oftewel C#. Oftewel een vorm van crosscompiling. Dat gaat er dus ook allemaal uit,

Juist! En vergeet ook de Torque engine niet.

Ik durf te stellen dat de meeste games uit de app store niet native in Xcode zijn ontwikkeld, maar middels game engines zoals Unity en Torque.

[blouweKip]

Dan kom je uit bij linux want windows komt ook niet echt ver op al die gebieden (vendor lock-in central).
Overigens zijn de beperkingen voornamelijk aanwezig op hun mobiele platformen dus het valt allemaal wel mee

Maar ja, ik besef terdege dat het praten tegen een muur is op het hedendaagse t.net