Forsigtig glæde hos danske Unity efter Apples opblødning af kodekrav

Verden ser lidt mere betryggende ud for danske Unity, efter Apple har sagt OK til Phonegap trods de nye kodekrav til iPhone. Intet er dog sikkert endnu, påpeger Unity.

Hos danske Unity tolker man det som et godt tegn, at Apple nu har lovet udviklerne bag iPhone-værktøjet Phonegap, at de ikke bukker under for de nye og strammere koderegler i iPhone OS 4.0.

Unity står bag en 3D-spilmotor, som hundredvis af iPhone-spil benytter sig af.

Med frigivelsen af iPhone OS 4.0 beta til udviklere i sidste uge kom det frem, at Apple havde indskærpet kravene til tilladte programmeringssprog på platformen til Objective-C, C++ og C, samt Javascript.

Det satte blus under spekulationerne om, hvorvidt værktøjer som Unity, Phonegap og Adobe Flash Professional CS5, der lægger sig ind som et ekstra lag mellem programmøren og iPhone-platformen, ikke længere vil kunne bruges som værktøjer til udvikling af iPhone-applikationer.

Hos Unity er man derfor glad for nyheden om, at Phonegap, der står bag et værktøj til iPhone-udvikling med Javascript, har fået grønt lys fra Apple.

»Vi var glade for at se det - det tyder jo meget godt,« skriver kreativ direktør i Unity, Nicholas Francis, i en e-mail til Version2.

Unity: Dejligt med grønt lys for Phonegap

Han understreger, at Unitys egne skøn af situationen lige nu i princippet ikke er mere værd end spekulationerne fra brugere af internetfora verden over, hvor betydningen af Apples nye regler i øjeblikket diskuteres heftigt.

Men det er et betryggende tegn, at Phonegap har klaret frisag, vurderer Nicholas Francis.

»Phonegap har fået grønt lys, og vi skal ind og mødes med Apple omkring det (de nye regler, red.). Begge dele tyder på, at Apples fokus er at sikre sig, at de ting, der kommer på App Store, er af en høj teknisk kvalitet. Det synes vi jo er dejligt,« skriver Nicholas Francis.

Unity har møde med Apple i næste uge, hvorefter Unity ved, hvor softwarevirksomheden står i forhold til de nye regler.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (20)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Deleted User

Apple tilbyder et stort marked for spirende udviklere. Dog bør det slås fast at det marked er på et ekstremt usikkert grundlag, hvor Apple til hver en tid kan vælge at lukke for hele forretningsmodellen, efter humør. Vi bryder os ikke om det du laver: Lukket. Du laver det i et forkert sprog: Lukket. Vi synes det er fedt det du laver, så det vil vi også: Lukket. Jeg er ikke længere overrasket når Apple lukker for projekter, og synes ærligt talt at udviklingshuse selv er ude om det, når Apple lukker dem ude.

  • 0
  • 0
#2 Jakob Damkjær

Det har været Apple politik at det ikke er tilladt St ha fortolkede sprog på iphonen.

Denne stramning er en direkte konsekvens af de fortolkede miljøer der har floreret på iphonen.

Derfor har de fortolkede sprogs udviklere taget en risici ved at udvikle til iphonen. At der så er nogen fortolkede miljøer der får lov til at overleve er det eneste inkonsistente ved Apples stramning....

At det så er nødvendigt for at opretholde at de fortolkede miljøer bliver væk og ikke kan snige sig ind af bagvejen igen bliver der lukket for alternative programerings sprog er ærgeligt men det var ingen hemlighed at de fortolkede milijøer levede på lånt tid.

  • 0
  • 0
#4 Jakob Damkjær

Soft keyboardet virker rigtig godt ;)

lidt træning og man skriver ret ubesværet.

Men når man skriver i en bil så misser man fra tid til anden de små fejl som spellcheckeren laver...

/Jakob

ps! Ville ønske at version2s Mobile interface havde kommentar funktion...

  • 0
  • 0
#6 Jakob Damkjær

flash flash flash flash flash

Adobe CD5 iPhone flash App converter

metaplatform = > apps der ikke udnytter enkelte platformes specifikke features

For at lukke for flash App converter er det nødvendigt med 3.3.1

utilsigtet skade ved 3.3.1 < fordel ved ikke at ha flash

flash på nogen mobilplatform er dårlig.

easy peasy

Hvis man påstår at flash er godt på desktoppen, så har man det åbenbart fint med 100% lockin til Adobe og så er man ikke interesseret i et internet der er baseret på åbne standarter så som HTML5 CSS3 og JavaScript.

Noget som alle burde ha interesse i og ikke bare på mobil platformen.

Det hænger alt sammen sammen, jo størrere udbredelse flash får jo mindre udbredelse får HTML5/CCS3/JavaScript. Derfor er Adobes forsøgte annektering af iPhonen og andre mobil platforme en direkte udløber af deres succesrige strategi med at placere et adobe meta lag mellem designer indhold og kode på alle internet sites med noget medie indhold.

Adobes metalag er direkte antagonistisk ifht et åbent standartbaseret medie rigt internet (animationer, menysystemer, video osv). Men det er åbentbart mere interessant at bashe Apple for at de forsøger at udbrede det standartbaserede internet, end fx at indse at Android heller ikke burde acceptere flash hvis de vil opretholde nogen konkkurancemægsig fordel for devices med Android.

Men Google er vel ligeglade hvem der sælger hardwaren, sålænge det ikke er bing der laver søgningerne eller iAd der presentere reklamerne...

Hvilket bringer os til den mystiske skillevej som Google befinder sig i pt. Skal vi satse på flash eller åbne standarter..... tænke tænke tænke... For Google har bragt sig i alliance med to antagonistiske platforme:

På den ene side HTML5/CSS3/JavaScript gennem deres store arbejde med webkit og standart udvalget og deres HTML5 video service på YouTube og på den anden side Adobe med propietær platformen flash...

Så i nær fremtid vil vi se om Google vælger at spille på begge heste og om det er muligt eller hvilken side de vælger...

/Jakob

PS! lad os spole tilbage og huske hvem der først fik youtube til at encode i h.264.... iPhone YouTube App der kom med den første iPhone... The start of the end of the flash domination of the intertubes.

PPS! linux: platform open standarts open

windows: platform closed standarts closed

Android: platform open standarts open (unless mobile operator wants platform closed, then platform closed)

iPhone: platform closed standarts open

Mac OS X: platform semiclosed (many core parts open) standarts open

Where you wana go today ? tomorrow ?

  • 0
  • 0
#7 Stephen Aaskov

Har du nogen eksempler på at det er sket? Hvodan kan Apple lukke for det hele efter humør, og hvad i alverden skulle få dem til det.

Du kan skrive om din egen fantasi på dette site, men når du formulerer dig som du gør kræver det at dine udsagn uderbygges. Så værsgo, kom med nogle facts.

  • 0
  • 0
#8 Stephen Aaskov

Hvad har kode konverteret fra et fortolket sprog til native kode med det at gøre?

Unity slipper jo tilsyneladende også udenom Apple´s regler. Husk, at reglerne ikke er blevet "opblødet", men at tolkningen er (tilsyneladende) blevet lidt mere afklaret. Denne afklaring er, at reglerne ikke var helt så drakoniske som de oprindeligt blev fremstillet.

  • 0
  • 0
#9 Deleted User

Har du nogen eksempler på at det er sket? Hvodan kan Apple lukke for det hele efter humør, og hvad i alverden skulle få dem til det.

De nye regler er indført for at folk der laver ting i flash bliver nødt til at lave det specifikt til iphone. Jeg er sikker på at en masse virksomheder har fået problemer med dette, og som artiklen viser giver det også potentielt problemer for folk der bruger platforme som Unity. Da Apple introducerede Ipadden introducerede de samtidigt en e-boghandel. Pludseligt blev en eksisterende boghandel ramt af deres non-compete klausul der siger at man ikke må duplikere funktionalitet som Apple allerede har i systemet. De blev derfor pålagt at fjerne funktionalitet for at kunne køre videre.

Apple fjernede for nyligt en masse halvlumre programmer, fordi det ikke var tilpas sobert. Man skal ikke kunne se porno på deres mobile platforme. Sjovt nok har de stadigvæk både en browser og en Playboy applikation tilgængelig. Man kan argumentere frem og tilbage om man synes det er i orden at de holder den "ren", men faktum er at de pludseligt har lukket for en masse programmer "efter humør".

  • 0
  • 0
#10 Jesper Lund Stocholm Blogger

Hej Jakob,

Soft keyboardet virker rigtig godt ;)

lidt træning og man skriver ret ubesværet.

Ja, soft-boardet er rigtigt lækkert til det meste.

Men når man skriver i en bil så misser man fra tid til anden de små fejl som spellcheckeren laver...

Ja, jeg kan blive fuldstændig sindssyg over, at den laver idiotiske fejl - såsom:

me -> mé on -> ón at -> St as -> A's

:-)

  • 0
  • 0
#11 ab ab

Der er i mine øjne ingen overraskelse i, at brug af PhoneGap er tilladeligt efter den ændrede passus 3.3.1: PhoneGap er jo netop baseret på, at man bundler JavaScript-ressourcer i et native runtime, som eksponerer API-wrappers til JavaScript-ressourcerne, som afvikles via en UIWebView-control i applikationen.

Det er præcis det, Apple siger, man godt må gøre:

Applications must be originally written in Objective-C, C, C++, or [b]JavaScript as executed by the iPhone OS WebKit engine[/b]

Appcelerator Titanium forfølger grundlæggende samme design som PhoneGap, men har så vidt jeg kan forstå ved overgangen fra 0.8 til 1.0 valgt at udskifte brugen af UIWebView-kontrollen med noget uspecificeret, der gør, at JavaScript bliver afviklet som native kode (det kan enten være JavaScript -> Objective C krydsoversættelse eller JavaScript -> optimeret bytecode, som afvikles i en native runtime fortolker).

Der er altså en væsentlig nuance til forskel mellem PhoneGaps designfilosofi og Appcelerators tilsvarende:

I used to put Appcelerator’s Titanium tool in the category of “a commercial PhoneGap”. Historically, their technical approach has been similar, namely the “leverage WebKit and build a native application” model.” (..) With the recent introduction of Titanium 1.0, Appcelerator has graduated to a model where they cross-compile JavaScript/HTML/CSS into native code for iPhone and Android — no longer relying upon the WebKit engine at run-time. Development is still done in JavaScript, HTML and CSS, however the resulting application runs much faster because the code is translated to “equivalent” native code, including access to device level features such as GPS, accelerometer, Camera — even UI “gestures”.

Kilde: http://www.linux-mag.com/id/7719

Som folk vil huske, skriver Apple eksplicit følgende i 3.3.1:

Applications that link to Documented APIs [b]through an intermediary translation or compatibility layer[/b] or tool are prohibited

Et program udviklet med brug af MonoTouch befinder sig i mine øjne ligeledes ovre i det "utilladelige kontinuum" jfr. den reviderede 3.3.1-passis i den forstand, at det oprindelige sprog vil være C#, som overhovedet ikke er nævnt blandt de tilladte sprog:

Applications must be [b]originally written[/b] in Objective-C, C, C++, or JavaScript

ANSCAMobiles Corona er "endnu mere forbudt" i den forstand, at ikke alene afvikler de et "forbudt sprog" nemlig Lua. De gør det minsandten også via et mellemliggende kompatibilitetslag, som linker direkte til iPhone-API'et.

Det har imidlertid ikke forhindret seriøse spiludviklere som EA, Gameloft, Tapulous og ngmoco i at udvikle prisvindende spil til platformen ved brug af et tilsvarende design, så Apple-apologetikernes argument om, at virkelige gode iphone-applikationer nødvendigvis skal være i overensstemmelse med 3.3.1 udstilles som hule og åbenlyst forkerte.

Kilde: http://blog.anscamobile.com/2010/04/lua-the-lingua-franca-of-iphone-games/

Programmer udviklet med brug af Unity3D baserer sig på MonoTouch, og de vil derfor være lige så forbudte, som MonoTouch måtte vise sig at være.

Adobe's AIR ved jeg ikke så meget om, men jeg har indtryk af, at de ikke en gang krydsoversætter kildekode med gcc som mellemmand, men derimod genererer eksekverbare filer bestående af et AIR runtime i maskinkode og en SWF-ressource oven på, som så fortolkes under afvikling. Hvis dette er tilfældet, er det selvfølgelig endnu mere ovre i det ikke tilladte kontinuum.

En Delphi-oversætter til iphone - som Allen Bauer i forbindelse med den nuværende kontrovers har givet udtryk for, at hans firma overvejede at udvikle - ville formodentlig generere eksekverbare filer i ren ARM-maskinkode på baggrund af Pascal-kildekode. Og det ville selvfølgelig også være forbudt, da Pascal jfr. 3.3.1 er et "forbudt sprog" på iPhone.

  • 0
  • 0
#12 Jacob Avlund

Men når man skriver i en bil så misser man fra tid til anden de små fejl som spellcheckeren laver...

Hvad er der specielt ved at skrive i en bil? Med mindre man gør det ude i trafikken selvfølgelig, men det ville jo være totalt uansvarligt og ulovligt oveni.

  • 0
  • 0
#13 Stephen Aaskov

En Delphi-oversætter til iphone - som Allen Bauer i forbindelse med den nuværende kontrovers har givet udtryk for, at hans firma overvejede at udvikle - ville formodentlig generere eksekverbare filer i ren ARM-maskinkode på baggrund af Pascal-kildekode. Og det ville selvfølgelig også være forbudt, da Pascal jfr. 3.3.1 er et "forbudt sprog" på iPhone.

Så skulle de hellere generere C-kode ud fra Pascal kilden - så er man ved at være inde i varmen. Desuden vil Apple ikke have en jordisk chance for at opdage det.

Så må Allan Bauer jo vurdere hvad der er lettest, at compilere Delphi Pascal til ARM maskinkode, eller generere C kode ud fra Delphi Pascal kildetekst.

At opgaven ikke er triviel, giver jo ingen ret til at kritisere Apple. Det er tudekikseopførsel.

  • 0
  • 0
#14 Rasmus Schultz

JIT er jo ikke det samme som "fortolket".

Unity bruger mig bekendt ikke fortolkede sprog - kildekoden bliver så vidt jeg ved kompileret og afviklet på Mono, der jo compiler det til maskin-kode inden det afvikles.

Så der er et ekstra abstraktions-lag mellem den oprindelige kildekode og den maskin-kode der bliver afviklet på processoren, men det er vel ikke desto mindre stadig maskin-kode der bliver afviklet.

  • 0
  • 0
#15 ab ab

Så skulle de hellere generere C-kode ud fra Pascal kilden - så er man ved at være inde i varmen. Desuden vil Apple ikke have en jordisk chance for at opdage det.

Så må Allan Bauer jo vurdere hvad der er lettest, at compilere Delphi Pascal til ARM maskinkode, eller generere C kode ud fra Delphi Pascal kildetekst.

At opgaven ikke er triviel, giver jo ingen ret til at kritisere Apple. Det er tudekikseopførsel.

For det første er det relativt trivielt at krydsoversætte Pascal til Objective C i forhold til den udfordring, der ligger i at oversætte Pascal til optimeret ARM-kode. Med andre ord kunne Allen Bauer & Co. med lethed lade deres Pascal-oversætter producere Objective C-kode.

Jeg tror imidlertid ikke, at de vil gøre det. Man kan ikke fortænke Embarcadero i at trække følehornene til sig, når Apple så klart har markeret, at de fra den ene dag til den anden kan finde på at rive det økonomiske grundlag fuldstændig væk under en branche eller et delmarked om du vil for leverandører af udviklerværktøjer og abstraktionslag.

Hvis Apple reelt havde haft brugsoplevelsen som deres hensigt med ændringen og havde ønsket at afbalancere denne med et hensyn til leverandører af (kryds)oversættere og frameworks, så ville de have indført nogle QA-retningslinier og procedurer, der klart definerede, hvad der skal til for at få certificeret sit udviklingsværktøj til iPhone-platformen.

  • 0
  • 0
#16 Stephen Aaskov

For det første er det relativt trivielt at krydsoversætte Pascal til Objective C i forhold til den udfordring, der ligger i at oversætte Pascal til optimeret ARM-kode. Med andre ord kunne Allen Bauer & Co. med lethed lade deres Pascal-oversætter producere Objective C-kode.

Ja, og hvad er problemet så?

Jeg tror imidlertid ikke, at de vil gøre det. Man kan ikke fortænke Embarcadero i at trække følehornene til sig, når Apple så klart har markeret, at de fra den ene dag til den anden kan finde på at rive det økonomiske grundlag fuldstændig væk under en branche eller et delmarked om du vil for leverandører af udviklerværktøjer og abstraktionslag.

Apple har været helt klare i mælet fra dag 1. omkring udviklingsmiljøer. At man så vælger at lave alternative udviklingsmiljøer er ensbetydende med at løbe en risiko. End of story. Der er intet nyt i Apple´s udmelding for dem der hidtil har gjort som Apple har anbefalet. Embarcadero må finde på noget andet end at snylte på Apple´s investering.

  • 0
  • 0
#17 ab ab

Ja, og hvad er problemet så?

Problemet er dels, at sådan krydsoversættelse ikke er tilladt ifølge ordlyden i Apples nye SDK-betingelser og dels, at Apple klart og tydeligt har demonstreret, at de fra den ene dag til den anden er villige til at knuse tredjeparts udviklerværktøjer på iPhone-platformen.

Embarcadero må finde på noget andet end at snylte på Apple´s investering.

Et udsagn som dette ignorerer efter min mening den betydelige samfundsgevinst, vi har oplevet ved at alle frit kunne anvende og udvikle værktøjer til platforme som internettet og den oprindelige IBM PC takket være åbne standarder eller mere eller mindre frit tilgængelige specifikationer.

I modsætning til dig mener jeg, at tredjeparts producenter af værktøj til en platform tilfører platformen værdi i form af valgfrihed for forbrugeren. Især hvis de leverede værktøjer kan indgå smertefrit i den resterende arkitektur takket være interoperabilitet, datastandarder og platformkompatibilitet.

Det er fint, at en producent som Apple arbejder på at gøre internet-enheder til en endnu mere tilgængelig og integreret del af folks hverdag, men det er efter min mening ikke til gavn for forbrugerne og dermed samfundet, hvis Apple får lov at etablere sig som global smagsdommer for indhold og værktøjer på den platform, som meget af fremtidens internetforbrug vil udfolde sig på.

  • 0
  • 0
#18 Stephen Aaskov

I modsætning til dig mener jeg, at tredjeparts producenter af værktøj til en platform tilfører platformen værdi i form af valgfrihed for forbrugeren. Især hvis de leverede værktøjer kan indgå smertefrit i den resterende arkitektur takket være interoperabilitet, datastandarder og platformkompatibilitet.

Den almindelige forbruger vil ikke have valgfrihed, men let tilgængelig funktionalitet der giver vedkommendes liv merværdi.

Jeg er også fuldstændig ligeglad med, hvordan mine skruetrækkere og skiftenøgler er produceret - jeg er også ligeglad med valgfrihed mellem flere producenter. Jeg vil bare have en skruetrækker der af rette type og til den rette pris.

Det er fint, at en producent som Apple arbejder på at gøre internet-enheder til en endnu mere tilgængelig og integreret del af folks hverdag, men det er efter min mening ikke til gavn for forbrugerne og dermed samfundet, hvis Apple får lov at etablere sig som global smagsdommer for indhold og værktøjer på den platform, som meget af fremtidens internetforbrug vil udfolde sig på.

Så er det jo bare, at folk kan vælge en anden platform.

Hvis iPhone er så elendig som mange her påstår, og det er et stort tab at platformen ikke kan afvikle Java - så vil kunderne nok sive, både fra platformen og appstore.

Indtil da kan man for min skyld sagtens sidde og interpolere sin paranoia ud i en fremtid man mener at kende. Men lad dog være med at angribe en given platform og leverandør så kategorisk og hadsk som det er tilfældet her. Og overvej da særdeles de tekniske argumenter, inden der deles diverse platheder ud. Forummet her skulle forestille at være det professionelle IT-Danmark der udveksler holdninger.

  • 0
  • 0
#19 ab ab

Den almindelige forbruger vil ikke have valgfrihed, men let tilgængelig funktionalitet der giver vedkommendes liv merværdi.

Til den rette pris. Det er meget muligt, men valgfrihed og/eller demokratisk ansvarliggørelse er de eneste metoder, vi som samfund kender til vedvarende at sikre borgere og forbrugeres adgang til ovenstående.

I øvrigt er det tankevækkende hvordan du i det ovenstående indlæg bruger halvdelen af pladsen på at påstå, at forbrugerne er ligeglade med valgfrihed og i næste halvdel af indlægget skriver, at hvis forbrugerne er utilfredse, kan de jo bare skifte platform.. Det virker lidt selvmodsigende, ikke?

  • 0
  • 0
#20 Stephen Aaskov

I øvrigt er det tankevækkende hvordan du i det ovenstående indlæg bruger halvdelen af pladsen på at påstå, at forbrugerne er ligeglade med valgfrihed og i næste halvdel af indlægget skriver, at hvis forbrugerne er utilfredse, kan de jo bare skifte platform.. Det virker lidt selvmodsigende, ikke?

Det synes jeg nu ikke. Valgfrihed i konteksten var valgfrihed omkring applikationer på en given platform - dér mener jeg forbrugerne hellere vil have funktionalitet end valgfrihed. Det er så ensbetydende med, at en leverandør har truffet nogle valg.

Hvis forbrugeren ikke er enige i de valg, er det forbrugeren frit for at vælge et andet produkt (hvor der er truffet nogle andre valg).

jeg skrev jo også at forbrugeren ikke vil have valgfriheden, ikke at han/hun er ligeglad med den. Når forbrugeren fravælger for komplekse løsninger, er det at forholde sig til niveauet af valgfrihed.

Jeg har fravalgt noget valgfrihed, fordi jeg ikke laver min egen Linux distribution.

Det betyder jo netop ikke at jeg er ligeglad med valgfrihed, tværtimod - jeg ser det bare ikke nødvendigvis som en positiv ting.

  • 0
  • 0
Log ind eller Opret konto for at kommentere