Apple inför märkliga villkor i licensen, stoppar alla alternativa vägar?

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.

Gruber har skrivit en intressant och läsvärd artikel i ämnet där han sätter in det hela i ett lite större sammanhang.

Daring Fireball: Why Apple Changed Section 3.3.1

Han har nog rätt i stora drag.

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.

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?

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.

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.

Med "implementation" menar jag just en kompilator. Det måste väl gå att anropa Cocoa, så länge calling conventions mm stämmer någorlunda.

Säkerligen ingen slump nej!

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.

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.

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.

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.

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.

Ars Technica har en stor artikel om detta:

Apple takes aim at Adobe... or Android?

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

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.

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.

iofs helt riktigt, säge rinte emot dig hä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.

De kräver inte källkoden, bara det färdiga programmet.