Danskere bag iPhone-succes forventer frit lejde fra Apples kodekrav

18. maj 2010 kl. 11:0311
Tvivlen svinder ind hos danske Unity om fremtiden for virksomhedens spilmotor på iPhone-platformen i kølvandet på Apples stramning af kodekravene. Unity har dog ikke fået klar besked endnu.
person
Artiklen er ældre end 30 dage
person

Folkene bag den danskudviklede 3D-spilmotor Unity bliver stadig mere sikre på, at fremtiden tegner lys på trods af Apples seneste stramning af kodekravene til iPhone-platformen.

Det fremgår af et blog-indlæg fra Unity-direktør David Helgason. Unity står bag en spilmotor og udviklingsplatform, som hundredvis af iPhone-spil benytter sig af.

»Selvom vi ikke kan sige præcis, hvordan ToS 3.3.1 (afsnittet med de nye kodekrav, red.) falder ud, er Unity meget forskellig fra Flash, og vi har en stærk tro på, at Unity-udviklere vil gå fri,« skriver Unity-direktør David Helgason i et blog-indlæg.

Med frigivelsen af iPhone OS 4.0 beta til udviklere i begyndelsen af april stod det klart, at Apple havde skærpet kravene til tilladte programmeringssprog på platformen til Objective-C, C++, C og Javascript.

Artiklen fortsætter efter annoncen

Dermed opstod der tvivl om fremtiden for værktøjer som Unity, Phonegap og Adobe Flash Professional CS5, der alle lægger sig ind som et ekstra lag mellem programmøren og iPhone-platformen og rekompilerer 'fremmed' kode til iPhone-kode.

Ville de fortsat kunne bruges som gyldige værktøjer til udvikling af iPhone-applikationer uden risiko for, at applikationerne ville blive afvist ved indgangen til onlinebutikken App Store?

Unity har tidligere oplyst til Version2, at virksomheden har mødtes med Apple for at drøfte konsekvenserne af det opdaterede afsnit 3.3.1 i Apples udvikleraftale. Version2 har flere gange forsøgt at få en uddybende kommentar fra Unity om den seneste udvikling i sagen, hvilket hidtil ikke er lykkedes.

Unity lader dog nu til at være meget fortrøstningsfulde, selvom Apple endnu ikke har givet virksomheden klar besked.

Artiklen fortsætter efter annoncen

Jobs

Dine job
Vis alle

Ifølge Unity-direktøren bestyrkes den tro af, at aktuelle Unity-udviklede iPhone-spil stadig får grønt lys af Apples testere og dermed bliver optaget i onlinebutikken App Store.

Tidligere har Javascript-værktøjet Phonegap fået grønt lys fra Apple, mens Flash-udvikling er blevet afvist.

11 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Køb abonnementFå prøveabonnement

Jobs

Dine job
Vis alle

Fortsæt din læsning

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
2
Niels Dybdahl
18. maj 2010 kl. 12:30

Unitysagen viser hvor grotesk forbuddet mod APIer er. Der er ingen principiel forskel på Unity, Flash og ens egne biblioteker. Men Apple kan selvfølgelig vælge at tillade nogle biblioteker og stadig forbyde andre. Alle programmører bruger selvfølgelig også sine egne biblioteker/APIer og laver dermed "ulovlige" iPhone-programmer, men sålænge man ikke råber op om det, så går det nok. Men Apple opnår det de gerne vil, nemlig at gøre det ekstremt bøvlet at lave programmer som både kan køre på iPhone og på andre systemer.

  • more_vert
    • insert_linkKopier link
4
Stephen Aaskov
18. maj 2010 kl. 13:07

Unitysagen viser hvor grotesk forbuddet mod APIer er. Der er ingen principiel forskel på Unity, Flash og ens egne biblioteker. Men Apple kan selvfølgelig vælge at tillade nogle biblioteker og stadig forbyde andre.

Der er tale om helt forskellige ting:

  • API forbuddet gælder de interne API´er der eksiterer på platformen, men som ikke er åbne for udviklere gennem SDK´et. Hvis man bruger dem bliver app´en ikke godkendt i AppStore.

  • Unity, Flash og ens egne biblioteker er tre forskellige ting, så der er meget stor forskel.

Alle programmører bruger selvfølgelig også sine egne biblioteker/APIer og laver dermed "ulovlige" iPhone-programmer, men sålænge man ikke råber op om det, så går det nok.

Det gør de, og det er der intet forkert i. "Private API" er som ovenfor beskrevet, en helt anden ting. Private i den forbindelse er "Apple private". Det vil sige ikke offentliggjort, ikke supproteret, ikke garanteret virke i fremtiden. Gamle DOS programmører kan her læse "Int 21h"

Men Apple opnår det de gerne vil, nemlig at gøre det ekstremt bøvlet at lave programmer som både kan køre på iPhone og på andre systemer.

1: Vil de det? 2: Gør de nu også det? 3: Hvis ja til 2: De gør så i hvert fald ikke via det du beskriver 4: Kan en Android telefon køre en Symbian applikation?

Det er en falsk præmis, at normaliteten er applikationer der kan køre på flere forskellige systemer. Derfor er din konklusion, at Apple er abnormal, falsk.

Man kan påstå at Apple ikke muliggør cross-platform mobile applikationer, men det er der ikke andre der gør - så heller ikke her er Apple abnormal.

  • more_vert
    • insert_linkKopier link
5
Niels Dybdahl
18. maj 2010 kl. 13:25

Det vil sige ikke offentliggjort, ikke supproteret, ikke garanteret virke i fremtiden. Gamle DOS programmører kan her læse "Int 21h"

Der er vist noget du har misforstået. Int 21h er offentliggjort, supporteret og garanteret at virke i fremtiden. Man kan slet ikke forestille sig en DOS version hvor Int 21h ikke virker mere.

4: Kan en Android telefon køre en Symbian applikation?
Det er en falsk præmis, at normaliteten er applikationer der kan køre på flere forskellige systemer. Derfor er din konklusion, at Apple er abnormal, falsk.

Jeg har ikke lige checket om Android kan køre J2ME applikationer, men formodenlig kan den godt og i så fald kan man godt køre samme applikation på Symbian og Android, hvis den "bare" er skrevet til J2ME.

Men ellers hvis man vil skrive et program som kan køre på flere platforme, så vil man oftest være nødt til at skrive wrappere til den enkelte platform. Wrapperkoden vil så være platformsafhængig, mens størstedelen af ens kode kan så være den samme til alle platforme. Wrapperkoden kan tilgengæld være den samme til flere forskellige programmer. Den kan lægges i et bibliotek og tilgås via et API. Men dette er så vidt jeg har forstået pt ikke tilladt på iPhone.

  • more_vert
    • insert_linkKopier link
6
Stephen Aaskov
18. maj 2010 kl. 13:41

Der er vist noget du har misforstået. Int 21h er offentliggjort, supporteret og garanteret at virke i fremtiden. Man kan slet ikke forestille sig en DOS version hvor Int 21h ikke virker mere.

Fair nok, men der var nu stadig en del af funktionerne der kun var ringe eller slet ikke dokumenteret.

Jeg har ikke lige checket om Android kan køre J2ME applikationer, men formodenlig kan den godt og i så fald kan man godt køre samme applikation på Symbian og Android, hvis den "bare" er skrevet til J2ME

Skal vi så ikke prøve at finde et eksempel på en successfuld j2me applikation Android brugerne er glade for, og ikke ønsker byttet med en native Android applikation.

...Wrapperkoden kan tilgengæld være den samme til flere forskellige programmer. Den kan lægges i et bibliotek og tilgås via et API. Men dette er så vidt jeg har forstået pt ikke tilladt på iPhone

Jo, du kan lave alle de API´er du lyster, og du kan lae alle de wrapperlag du lyster. Men man skal holde sig til C, C++ og Objective-C.

  • more_vert
    • insert_linkKopier link
7
Niels Dybdahl
18. maj 2010 kl. 13:50

Jo, du kan lave alle de API´er du lyster, og du kan lae alle de wrapperlag du lyster

Dette tror jeg også at du har misforstået. I den nævnte 3.3.1 clause står der:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

Du må altså IKKE lave dine egne biblioteker og bruge dem i iPhone programmer. Enhver headerfil er et API, så i praksis holder 3.3.1 ikke. Men den er effektiv til at forhindre større biblioteker som Unity og Flash i at blive udbredt.

  • more_vert
    • insert_linkKopier link
9
Stephen Aaskov
18. maj 2010 kl. 14:19

Du må altså IKKE lave dine egne biblioteker og bruge dem i iPhone programmer. Enhver headerfil er et API, så i praksis holder 3.3.1 ikke. Men den er effektiv til at forhindre større biblioteker som Unity og Flash i at blive udbredt.

Du vil jo misforstå essensen i det her, og åbenbart med den bagtanke at Apple er helt galt på den. Hvis du vil forsvare ovenstående, og påstå at du virkelig mener det - så stopper diskussionen dér.

Enhver headerfil udgør ikke et API, og 3.3.1 handler ikke om biblioteker. Selvfølgelig må jeg lave headerfiler i min iPhone applikation, Xcode autogenererer dem endda.

API´er er i denne sammenhæng applikation<->OS snitflader. Min applikations interne interfaces er ikke API´er i konteksten "licensbetingelser" eller "Apple og udviklere".

Flash er ikke et bibliotek, det er en metaplatform. Unity er ikke specifikt målet i noget, det er ikke engang sikkert 3.3.1 rammer Unity, kun den mest rigide og polemiske udlægning af 3.3.1 vil indbefatte Unity.

Formålet med 3.3.1 er, i modsætning til det du skriver, ikke at forhindre større biblioteker i at blive udbredt. Vi kender ikke formålet, det gør kun Apple. De har så udtalt sig om hvad der ligger bag 3.3.1 og modviljen mod Flash. Men at sige at 3.3.1´s formål er at forhindre større biblioteker i at blive udbredt, er simpelthen forkert.

  • more_vert
    • insert_linkKopier link
10
Niels Dybdahl
18. maj 2010 kl. 14:24

kun den mest rigide og polemiske udlægning af 3.3.1 vil indbefatte Unity.

Forlængelsen af 3.3.1 siger:

3.3.1 ... e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited

Unity er jo netop et layer eller tool imellem Apples grafik API og applikationen. Der er god grund til at Unity har følt sig nødsaget til at spørge Apple om de har en fremtid idet formuleringen ovenfor ikke giver nogen mulighed for det. Men som tidligere nævnt kan Apple selvfølgelig dispensere fra sine egne regler og mon de ikke også gør det her?

  • more_vert
    • insert_linkKopier link
11
Stephen Aaskov
18. maj 2010 kl. 14:46

Genererer Unity ikke C/Obj-c kode og et Xcode project, som så bygges for at resultere i en binær fil?

Edit: Unity bruger Mono AOT til at compilere C# til ARM assembler, som så integreres i XCode projektet.

  • more_vert
    • insert_linkKopier link
8
Niels Dybdahl
18. maj 2010 kl. 14:01

Argumentet bag alt dette er at en applikation skrevet specifikt til en platform vil være bedre end en crossplatform applikation.

Men holder dette i praksis? Smartphones i dag har alle en trykfølsom skærm, (oftest med multitouch), internetforbindelse, telefonforbindelse, bluetooth, GPS, accelerationsmåler, højtaler, kamera. Jeg kan ikke se noget som begrunder at man ikke skulle kunne lave et abstraktionslag til hver smartphone, så man nemmere kan lave et crossplatformsprogram som udnytter denne hardware. Forskellene mellem mobilplatformene er langt mindre end lighederne.

  • more_vert
    • insert_linkKopier link
3
Niels Dybdahl
18. maj 2010 kl. 12:51

http://www.phonegap.com/2010/04/14/... : “PhoneGap is not in violation of the 3.3.1 clause of the license agreement.”

Det gør det ikke just nemt at finde ud af hvilke APIer der er tilladt og hvilke der ikke er.

  • more_vert
    • insert_linkKopier link