- Ingemar Ragnemalm
- Medlem ●
- Linköping
Den här artikeln rapporterar något som inte alls låter trevligt:
Adobe Apps: Easier to Pass Through the ‘i’ of a Needle? | Gadget Lab | Wired.com
Enligt artikeln har Apple infört följande paragraf:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
Detta är grovt formulerat. Vi får alltså inte använda andra programmeringsspråk, och inga bibliotek för korsplattformsutveckling...?
Detta kan ha att göra med Apples ambitioner att få bort Flash, men samtidigt sätter de upp spärrar så att inga alternativ kan komma in heller. (Och skall de stoppa onödigt batterislukande så kan de stoppa JavaScript med en gång!)
“So much for programming language innovation on the iPhone platform” said Joe Hewitt, developer of the Facebook iPhone app, via Twitter. “I’m upset because frankly I think Objective-C is mediocre and was excited about using other languages to make iPhone development fun again. It’s so hard to reconcile my love for these beautiful devices on my desk with my hatred for the ugly words in that legal agreement.”
Jag håller med varenda ord. Försöker Apple stoppa all utveckling utanför de egna dörrarna? Jag hoppas att det i slutändan bara handlar om att stoppa Flash kombinerat med klumpiga lagparagrafer som täcker in alldeles för mycket.
Det låter extremt måste jag säga, men inte förvånande. Apple vill ha total kontroll och så länge de kommer undan med det så kommer de att utöka kontrollen.
Han har nog rätt i stora drag.
Laddar man inte upp sin app i kompilerad form? Hur kan någon (Apple) isf ens veta vilket språk man använt?
Det är helt riktigt; så länge man gör det så måste man ha väldigt stor frihet vad gäller både språk och korsplattformsbibiliotek (så länge de länkar statiskt). Det jag är en liten aning rädd för är om Apple skulle få den vansinniga idén att kräva in källkod och själva utföra kompileringen när appen laddas upp till App Store.
Jag hoppas att allt egentligen handlar om att stoppa klumpiga eller direkt osäkra lösningar som t.ex. utför någon form av konvertering av koden på iPhonen själv, eller liknande. Men det finns lite för många frågetecken.
Det kan mycket väl vara så att det är svårt att veta vilket språk som använts, men som utvecklare måste du ju godkänna licensavtalet, och du blir därmed juridiskt bunden, och ansvarig, för överträdelser.
Alla företag vill innerst inne ha monopol, så länge det är deras eget, och Apple är inget undantag.
Det kan mycket väl vara så att det är svårt att veta vilket språk som använts, men som utvecklare måste du ju godkänna licensavtalet, och du blir därmed juridiskt bunden, och ansvarig, för överträdelser.
Japp. Och hur kul är det med ett avtal som alla kommer att överträda, mer eller mindre? Frågan är vad som egentligen är tillåtet.
Adobe med.
Adobe vill inte hjälpa till att skriva apps til iPhone, de vill vara med på kakan.
Gamla kodare slipper lära sig nytt med. Det är ju bra.
Jag förstår inte ditt inlägg. Vad är det du menar är bra? Vad menar du med att gamla kodare slipper lära sig nytt?
Var det inte det som var meningen att de som skrivit Flash-saker i åratal skulle kunna fortsätt med det. Det är ju rätt många som är inkörda på det.
Tanken är fin men i praktiken innebär det ju att där rök kontrollen och där rök att man använder Apples developer-kit.
I praktiken innebär det också att Adobe verkligen försöker att sprattla istf att lägga sig ner och dö - poäng till Adobe för att de försöker.
Bara funderar på hur skulle Apple hålla koll på det här? Anställa Flash-folk som sitter och går igenom appsen innan de lägger ut dem.
Suck, inte nu igen...
Nu inför vi lite reality check i diskussionen:
Är du medveten att det går 100 Flash Player-installationer på varje iPhone/iPad ?
H_U_N_D_R_A
Är du medveten om att Flash Builder står för mindre än 5% av Adobe intäkter?
Adobe skulle gärna vilja kunna köra Flash Player på iPhone, men även om Flash skulle vara helt borta från browser-marknaden om några år (vilket jag inte tror) så skulle inte det vara någon katastrof för Adobe.
Vad den här diskussionen handlar om är huruvida utvecklare ska vara begränsade till några få språk som Apple förespråkar och vad det har för konsekvenser för utvecklare.
Den diskussionen berör visserligen Adobe, men är ofantligt mycket större än så, eftersom det berör alla utvecklare av mobila applikationer.
Vad den här diskussionen handlar om är huruvida utvecklare ska vara begränsade till några få språk som Apple förespråkar och vad det har för konsekvenser för utvecklare.
Den diskussionen berör visserligen Adobe, men är ofantligt mycket större än så, eftersom det berör alla utvecklare av mobila applikationer.
Japp, det är vad jag också tycker är den stora grejen: Att Apple skulle låsa ute alla valmöjligheter och innovationsmöjligheter. Dock tror jag inte Flash är irrelevant; Det är troligen Flash som orsakat dessa villkor, och det kanske är enbart Flash som kommer att drabbas i praktiken.
Juridiskt bunden känns ju en smula tveksamt. Om jag tar hem en open source-implementation av Ruby, ändrar lite i den, döper om till "Objective-C", gör tillgängligt för allmänheten, och sen kodar i detta språk, har jag då brutit mot avtalet?
Men då måste du ju ha en compiler och/eller länka till någon form av "translation layer".
En sak jag tycker är intressant är att den här informationen kommer nu, och att Adobe lanserar CS5 på måndag. Det tror jag inte är en slump.
Nja, för att följa den här diskussionen så måste man nog ha en klar uppfattning om vad ett programmeringsspråk är, det är bara något som gör det praktiskt för en människa att skriva någon form av språk/kod som sedan omvandlas/kompileras till mer maskinnära kod.
Givet att kompilatorn förstår programmeringsspråket kan man skriva kod i många olika språk och ändå få ut exakt samma maskinnära kod.
Vitsen med det är dels att många olika utvecklare kan bidra (för ingen utvecklare kan behärska mer än ett fåtal programmeringsspråk) och sedan är också olika språk mer eller mindre bra på olika saker.
Om man t.ex. jämför med OS X så har utvecklare kunnat komma in från andra miljöer och ändå fortsätta jobba med sina språk, t.ex. C, C++, Java, Python, Ruby, PHP, Perl etc. etc. och därmed har Apple kunnat attrahera utvecklare på ett sätt som annars inte varit möjligt. Den mångfalden har också gjort att utvecklare kunnat blanda och välja det som varit mest lämpat. Inte minst har det gjort att Mac OS X har kunnat tilltala extremt många programmerare från annan bakgrund.
Det Apple nu tycks vilja göra är att begränsa utvecklarnas möjligheter ganska radikalt, och framför allt tror jag det handlar om att vilja låsa in utvecklare.
Tänk såhär: Om det gick att skapa program som gick enkelt att kompilera till olika plattformar, med hjälp av något mellanlager, varför skulle då en utvecklare vilja göra sitt program bara för iPhone OS?
Och, i nästa steg, om alla viktiga program finns för alla mobilplattformar, varför ska då en mobilköpare välja en iPhone (ok det finns säkert andra skäl, men mjukvaran är viktigare än hårdvaran)
Därmed Apples beslut (tror jag). De vill utnyttja det försprång de tagit. Många utvecklare väljer ju den populäraste plattformen och utvecklar sitt program där, sen räcker inte resurserna, eller kunskapen, för att samtidigt skapa och underhålla samma program för andra plattformar, i och med att det inte kan göras med samma programmeringsspråk. (nu är det inte bara språket det hänger på, men det är en viktig del)
Att göra kod som är körbar på flera plattformar är precis det som Adobe håller på med med sitt open screen project, vilket gör det möjligt att utveckla för många plattformar samtidigt.
Skulle det bara röra Adobe vore det skit samma, för de tjänar inte huvuddelen av sina pengar på vare sig utvecklingsverktyg eller Flash, och de kan till nästa release koda om Flash Builder till att mata ut saker i HTML5, JS, SVG etc. och tjäna precis lika mycket pengar på det.
Men rent principiellt är frågan viktig för utvecklare, för det går stick i stäv mot vad som varit trenden under en lång tid.
Det är också, på längre sikt, intressant för kunderna, de som köper telefoner, för det minskar mångfalden och konkurrensen.
Jag hoppas memark och Ingemar fyller på, för som utvecklare har de säkert fler bra exempel på varför det är viktigt.
Jag hoppas memark och Ingemar fyller på, för som utvecklare har de säkert fler bra exempel på varför det är viktigt.
Det var en bra genomgång!
För mig är det viktigt att få välja språk själv. Jag kan många språk, men språket är ett verktyg, jag vill välja det som jag trivs bäst med, som jag är produktiv med, och som passar problemet. Dessutom utvecklas språken fortfarande väldigt snabbt, och att stänga dörren för nya språkvarianter är som att stanna klockan. Som att bestämma att den enda bil som är tillåten på vägarna är Trabant.
Efter Apples många svängar så har jag helt tröttnat på att göra min kod beroende av Apple. Det har alltför många gånger gjort ont att ha Apple-beroende kod. Det är självklart att ha ett lager mellan som helt enkelt skyddar mig mot hastiga förändringar; det är lättare att uppdatera mellanlagret än hela programmet. Det ger så klart korsplattformsmöjligheter också, men också möjligheten att göra snyggare lösningar än Apple gör. (CG eller CA, till exempel, är rätt risiga men inte så svåra att lägga ett bekvämare lager på.)
Ett problem som är nog så viktigt är att det begränsar program och spel som (relativt) smärtfritt kan portas till iPhone OS. Om programmet inte redan är skrivit i något av de tillåtna programspråken måste det skrivas om, även om det kanske hade gått att återanvända helt utan några eller med väldigt få ändringar. Är det ett stort program inser man snart vilket omfattande merarbete det innebär. Om man ska fortsätta använda den ursprungliga källkoden i andra sammanhang har man dessutom två kodbaser som ska vidareutvecklas parallellt, det kan vara avgörande för om ett program portas eller inte.
Ett problem som är nog så viktigt är att det begränsar program och spel som (relativt) smärtfritt kan portas till iPhone OS. Om programmet inte redan är skrivit i något av de tillåtna programspråken måste det skrivas om, även om det kanske hade gått att återanvända helt utan några eller med väldigt få ändringar.
Du kan inte återanvända mycket kod alls, om du inte får göra kompatibilitetslager utan måste stöpa om det fullständigt för att jobba direkt mot NS och Core. Det är bara att börja om från början.
Jag har portat program från Mac till Windows, och från Classic till Carbon. Det går, men det är mycket jobb, alltid mer än man tror. Porta Carbon till NS är praktiskt taget omöjligt utan mellanlager. Man får isolera vad man kan som inte är GUI och skriva om resten helt.
Är det ett stort program inser man snart vilket omfattande merarbete det innebär. Om man ska fortsätta använda den ursprungliga källkoden i andra sammanhang har man dessutom två kodbaser som ska vidareutvecklas parallellt, det kan vara avgörande för om ett program portas eller inte.
Och detta löser man ju just med kompatibitetslager av ett eller annat slag. Helt normalt sätt att jobba.
Du kan inte återanvända mycket kod alls, om du inte får göra kompatibilitetslager utan måste stöpa om det fullständigt för att jobba direkt mot NS och Core. Det är bara att börja om från början.
Jag har portat program från Mac till Windows, och från Classic till Carbon. Det går, men det är mycket jobb, alltid mer än man tror. Porta Carbon till NS är praktiskt taget omöjligt utan mellanlager. Man får isolera vad man kan som inte är GUI och skriva om resten helt.
Jag är osäker på om du säger emot eller håller med mig, möjligen skulle jag ha varit tydligare med att jag främst menade modeller och annat som inte är GUI-relaterat.
Och detta löser man ju just med kompatibitetslager av ett eller annat slag. Helt normalt sätt att jobba.
Det finns en annan lösning som jag brukar förespråka. Ett bra exempel är Transmission där allt som hör till vad programmet gör ligger i ett bibliotek, skrivet i C och som är relativt enkelt att hålla till olika system. Därefter är själva programmet, det grafiska gränssnittet, helt och hållet byggt för respektive plattform. T. ex. Cocoa, GNOME och Qt. Så länge man kan anropa biblioteket är det inga större problem att lägga till fler frontar. På så vis kan man dra nytta av de specifika saker som varje plattform är bra på medan den största delen av programmet är portabelt.
Jag är osäker på om du säger emot eller håller med mig, möjligen skulle jag ha varit tydligare med att jag främst menade modeller och annat som inte är GUI-relaterat.
Ingetdera, jag försökte bara bearbeta (men håller i första hand med). För det är helt sant att portning försvåras, när alla sätt att förenkla portning uttryckligen förbjuds. Men min erfarenhet är att APIer ofta är större problem än språk.
Det här är ett problem för alla och borde anmälas till konkurrensverket.
I korthet: minskad konkurrens mellan programspråk är minskad konkurrens, som leder till högre priser och sämre kvalitet.
Mer i detalj:
Anledning 1. Alla programspråk är inte likvärdiga.
De har olika styrkor och svagheter. C/C++ och Objective-C är bra på vissa saker men inte alla.
Vi kan ta ett exempel, traditionell Artificiell-Intelligens, ex söka kortaste resväg. Ett sådant problem löser man enligt min och mångas mening gärna i en dialekt Prolog eller Lisp. Vill man göra det i C kommer det innebära fler kodrader.
Fler kodrader innebär större risk för buggar och en högre kostnad, det är väldokumenterat.
Vem kommer få betala den högre kostnaden?
Konsumenter.
Leder det här till minskad innovation?
Ja, eftersom möjligheten att vara kreativ och välja nya tekniker går bort. För ex webb-applikationer kom för några år sedan ett nytt programspråk Ruby och en ny idé som hette Rails som blev populärt för att det gick snabbare att göra webb-applikationer. Snabbare innebär också billigare. Sådan innovation kan inte ske med apples nya policy.
Anledning 2. Minskad konkurrens mellan utvecklare.
Du vill anlita en konsult för att göra ett program. Med Apples nya policy har du färre att välja på eftersom de som inte är experter på C/C++/Objective-C inte kan konkurrera. Vem kommer få betala den högre kostnaden?
Konsumenter.
Leder det här till minskad innovation?
Ja, eftersom möjligheten att vara kreativ och välja nya tekniker går bort.
Det är detta som jag allra mest vänder mig emot, att inte få lov att utvärdera och välja verktyg efter behov. Man får ett multiverktyg från Apple, men ibland är det där multiverktyget inte praktiskt eller bekvämt.
Troligen är det en teoretisk fråga eftersom Apple troligen inte kan se vilket språk jag använder och inte heller de inkompilerade mellanlager som jag använder, men det är obehagligt att ljuga och att veta att Apple kunde slänga ut mig när som helst om de visste hur jag jobbar - utan hänsyn till hurvida mina program är bra eller dåliga utan bara för att jag inte går snyggt i ledet!
Ars Technica har en stor artikel om detta:
His Jobsness svarade med två korta mail på en utvecklares klagomål om 3.3.1, se mer här: Tao Effect Blog Blog Archive Steve Jobs’ response on Section 3.3.1
We think John Gruber’s post is very insightful and not negative:
Daring Fireball: Why Apple Changed Section 3.3.1
Steve
We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.
Språk blir som sagt svårt att urskilja, men i övrigt borde det väl räcka för Apple att inspektera bundlen? Kika efter vilka komponenter man skickat med och/eller fritextsöka lite grand. Kanske inte som löpande kontroll mot allt, men just för att sätta dit folk som använt Adobe Packager t ex.
Mycket från Apple sida tror jag handlar om att de inte känner sig nöjda med "write once - put on all platforms".
För deras del innebär det att det kommer ut apps som är anpassade till minsta gemensamma nämnare för att passa så många lurar som möjligt. Alltså bli iPhone's sär-egenskaper inte alls tillgodosedda utan det blir ungefär som alla de skit-java-apps man kunde ladda ner förr.
Anpassade till alla så att de inte passade någon.
Man tryckte på helt olika knappar i olika telefoner för att fixa samma sak, enbart vissa spel var avsedda för joystick - det fanns ju inte på alla telefoner...
Summan av kardemuman var rena skräpet.
Vidare har Apple anfört att för att klara av att köras under multitasking i OS 4 så måste appen vara skriven med Apple SDK. Exakt varför är inte klart för mig då jag inte är proffs inom programmering utan enbart en lekman.
Vidare har Apple anfört att för att klara av att köras under multitasking i OS 4 så måste appen vara skriven med Apple SDK. Exakt varför är inte klart för mig då jag inte är proffs inom programmering utan enbart en lekman.
Det är för att det inte finns multitasking för tredjepartsprogram i iPhone OS 4, enligt ordets egentliga betydelse. Istället för att processen fortsätter att köra som man hade kunnat förvänta sig så pausas den och sedan tillåts bara vissa funktioner som Apple tillhandahåller att köra, hittills totalt sju olika. Det ger en illusion av multitasking (som förvisso kommer att fungera utmärkt i väldigt många fall) men är det inte på något sätt.
Mycket från Apple sida tror jag handlar om att de inte känner sig nöjda med "write once - put on all platforms".
För deras del innebär det att det kommer ut apps som är anpassade till minsta gemensamma nämnare för att passa så många lurar som möjligt. Alltså bli iPhone's sär-egenskaper inte alls tillgodosedda utan det blir ungefär som alla de skit-java-apps man kunde ladda ner förr.
Anpassade till alla så att de inte passade någon.
Man tryckte på helt olika knappar i olika telefoner för att fixa samma sak, enbart vissa spel var avsedda för joystick - det fanns ju inte på alla telefoner...
Summan av kardemuman var rena skräpet.
Men neka då för att det är dåliga program! Se till resultatet, inte verktygen!
Vidare har Apple anfört att för att klara av att köras under multitasking i OS 4 så måste appen vara skriven med Apple SDK. Exakt varför är inte klart för mig då jag inte är proffs inom programmering utan enbart en lekman.
Men om jag använder ett annat språk, som anropar Apples SDK korrekt, och jag gör en app som utnyttjar iPhonens egenheter på ett bra sätt och med bra prestanda, vad tusan är det jag gör för fel??? 3.3.1 säger att jag inte får.
Men neka då för att det är dåliga program! Se till resultatet, inte verktygen!
iofs helt riktigt, säge rinte emot dig här.
Men om jag använder ett annat språk, som anropar Apples SDK korrekt, och jag gör en app som utnyttjar iPhonens egenheter på ett bra sätt och med bra prestanda, vad tusan är det jag gör för fel??? 3.3.1 säger att jag inte får.
Men Apple vill väl ha såväl app som källkoden ?
Det innebär ju att Apples programmerare om de vill ha den 100%iga kontroll de säger sig vilja ha måste anställa ett par brighta personer som kan programmeringsspråket x.
En eller flera person per utvecklingsmiljö - för det finns väl inte bara Apple SDK och Adobes grejer eller?
Om jag vill programmera i assembler på iPhone/iPad och skriver en app undrar jag om de har lust pjöja igenom assemblerkoden för att kolla den.
Jag kan ju ha fel om att de vill ha källkoden.
Men Apple vill väl ha såväl app som källkoden ?
Det innebär ju att Apples programmerare om de vill ha den 100%iga kontroll de säger sig vilja ha måste anställa ett par brighta personer som kan programmeringsspråket x.
En eller flera person per utvecklingsmiljö - för det finns väl inte bara Apple SDK och Adobes grejer eller?
Om jag vill programmera i assembler på iPhone/iPad och skriver en app undrar jag om de har lust pjöja igenom assemblerkoden för att kolla den.
Jag kan ju ha fel om att de vill ha källkoden.
De kräver inte källkoden, bara det färdiga programmet.