iPhone OS 4.0 - kitiltják a keresztfordítókat?

Címkék

Az új funkciók mellett egy kevésbé reklámozott változás is történik az iPhone háza táján. Az új fejlesztői licencfeltételek szerint:

  • Egy alkalmazás kizárólag dokumentált, nyilvános API-kat használhat.
  • Egy alkalmazás kizárólag C / C++ / Objective-C vagy a beépített WebKit motor által végrehajtott Javascript nyelven írt kódot használhat arra, hogy a dokumentált nyilvános API-kat felhasználja.
  • Az alklamazásokat eredetileg is a fent megadott nyelveken kell kifejleszteni, nem használhat "közbenső fordító- vagy kompatibilitás-rétegeket".

Ezzel a lépéssel az Apple feltehetőleg a hamarosan megjelenő Flash CS5 Iphone-ra exportáló funkcióját illegálissá tenni. Emellett azonban már olyan bejáratott és sok fejlesztő által használt eszközöket is kitilt, mint pl.

Jelenleg teljes a bizonytalanság, hogy pontosan mit jelent, illetve mit fog jelenteni ez a változtatás, esetleg változhatnak-e a licencfeltételek az iPhone OS 4 végleges változatának megjelenéséig.

Hozzászólások

Höh, ennyit a Free Pascal/iPhoneról is... Köszönjük Apple.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Már látom a kígyózó sorokat az OpenMoko bolt előtt.

Véleményem szerint ez annyit fog jelenteni, hogy a CS5-ben készült Flash-es vackokat kivágják, míg a natív ObjC-s vackot beengedik és a többieket sem piszkálják. Erre jó az Apple "nem adunk magyarázatot" politikája. Nem kell indokolni, hogy a CS5 miért nem és a Unity/Mono/XMLVM miért igen. :)
Úgy látszik SJ megtalálta az Antikrisztust az Adobe személyében... Vajon mikor borulnak mégis egymás keblére?! :)))

"Egyébként az nem megoldás, ha a keresztfordító az egyik engedélyezett nyelvre fordít, és azt fordítja tovább a hivatalos apple-féle fordítóval?"

XMLVM ezt csinálja. Mono-nak is van ilyen módja. Unity Monora épül.

Lehet úgy érteni, hogy ezt szabad, meg úgyis, hogy nem.

Szerintem egyébként az verte ki a biztosítékot, hogy a Flash-esek gyakorlatilag teljesen kikerülték az Apple toolchaint, és így Windows-on is lehetett (volna) iPhone App-ot fejleszteni.

Üdv,
Gergely

Most ez komolyan meglep valakit? Eddig is koztudott volt, hogy az Apple foggal-korommel ragaszkodik a rendszerehez, es semmitol sem riad vissza, hogy elerje a celjat (barmilyen kodos vagy esszerutlen legyen is az).

Aki komoly uzleti tevekenyseget epit Apple termekekre, az magara vessen. Tudta, mit csinal, most ne sirjon a szaja. Igen, az Apple meg egy nagysagrenddel a Microsoft alatt van. Nala lejjebb mar nem hiszem, hogy lehet menni.

"Komoly üzleti tevékenységről" írt, nem magyar viszonyok között jelentősnek mondhatóról.
A cikket író, Apple termékekre fejlesztő kisg is írja:
"vagy a nyílt forráskódú XMLVM, melyet mi is aktívan fejlesztünk és használunk".
Nem mindegy, hogy ezek után egy pár 10 millió forintos projektet kell-e kukázni, vagy pár 10 millió dollárosat.
Az AppStore csak a kkv. és az alattiaknak fő tevékenység. Annál magasabb szinten legfeljebb kiegészítő tevékenység.

Nem tudtam, hogy a komoly üzleti tevékenység néhány 10 millió dollárnál kezdődik és pár százezer esetleg millió az ma már gyíkfing kategória.

De akkor legyen az Adobe. Most éppen háborúzik az Apple-lel - ez lenne a "magára vessen"? - de gondolom, előtte azért jókora zsét leakasztott a Mac platformon is. (Vagy ezért vessen magára?)

Azt viszont felháborodva utasítom vissza, hogy leszólod a kkv-k üzleti tevékenységét! :-)

KisKresz

Ott kezdődik. Az AppStore pedig nyilvánvalóan a kicsiknek jó. Egy globális világcég számára nem probléma, hogy egymaga megoldja a szoftvereinek a terjesztését és még sápot sem kell úgy fizetnie az Almának.
Nem szégyen a kkv, az Apple is garázsban kezdte, ahogy a Google vagy HP és sok más neves vállalkozás. Csak vannak akik továbbfejlődnek. :-D

Kicsit megtévesztő a cím... A keresztfordító (cross-compiler) az, ami más architektúrára és/vagy oprendszerre fordít, mint amin fut. Pl: x86-OSX -> arm-OSX, vagy akarmi-linux -> x86-win32. :)
Szerintem az összes iphone fordító keresztfordító, gondolom nem magán a telefonon fut a fejlesztőkörnyezet...
Ha meg tévedtem, javítsatok ki! :)

"Az alkalmazásokat eredetileg is a fent megadott nyelveken kell kifejleszteni, nem használhat "közbenső fordító- vagy kompatibilitás-rétegeket".

Ugye a forráskódot nem kell átadni?
Akkor meg a toolchain készít oC kódot, és az almás meg bek@phatja.

Mondjuk nem értek az iPhone-ra fejlesztéshez, de gondolom az iPhone-ra fordított alkalmazások is valamiféle gépi kódok. Ebben az esetben az Apple reverse engineering nélkül (ami gondolom jogi problémákat vet fel) hogyan tudja megállapítani, hogy az adott alkalmazás milyen fejlesztőeszközzel, nyelven készült és milyen API-kat felhasználva készült?

--
Falu

Ezzel nem tudom milyen bizonyítékhoz fog jutni. OK, látja a szimbólumtáblát, meg magát az assembly kódot is, látja milyen libeket használ. Ez a Flashes LLVM fordítós megoldás esetében valóban megmutathatja, hogy nem az engedélyezett fordítót használták.

Konkrétan az XMLVM esetében, ahol Objective C-re fordítunk, semmi olyat nem fog látni, ami arra utalna, hogy a licenccel ellentétes dolgot tennénk.
Azok az XMLVM specifikus szimbólumok, amiket látni fog pedig, "originally" Objective-C-ben, XCode alatt készültek, többek között az én két kezemmel. A többi kódrésznél pedig eléggé filozófiai jellegű a vita, hogy mit tekintünk "originally"-nak, és mit nem.

Mindettől függetlenül az Apple korábban is nyugodt szívvel mondjuk 10 hónapig nem engedett be egy alkalmazást az AppStore-ba, mert csak, pedig tényleg csak hivatalos toolchaint használt. (Konkrét példa, konkrét magyar fejlesztőtől az IVSA konferencián.)
Ez az új rész a licencben csak egy további indok, amivel megakadályozhat a stratégiájának nem kedvező fejlesztéseket.

Üdv,
Gergely

PS: Ezzel az assembly betéteket is bannolták? Az inline assembly vajon a C-nyelv részét képezi szerintük, mert a GCC elfogadja? Vagy mindenkinek mostantól az általuk adott OS4-ben megjelenő "optimalizált" algoritmusokat kötelező használnia?

Amig a forrast nem kell kiadni (ami durvan jogot sertene igy nem fog megtortenni) es a fent vazoltak alapjan nem dontheto el egyertelmuen melyebb analizis nelkul, hogy miben irodott (mert pl. ObjC wrapper), addig ezen a reszen at fog csuszni. Viszont az ismertebb wrapperek/cross compilerek (mono, FPC, flash ize) kiszurheto egy szimbolum tabla ill. hasznalt apik analizisevel.

Amugy igen, ez volt a celja ugy sejtem. Foleg ugy sejtem, hogy az Adobe arcon rugasa es az elharapozott privat api hasznalat miatt leptek ezt meg. Ez az egesz Adobe utalat addig ment, hogy kirugtak minden appot ami RTMP-t hasznalt. :)

Szemet huzas, de ez van, lehet naluk anyazni, vagy elfogadni. Van elonye is, es hatranya is. Boven. Hallottam mar Android fejlesztot irigykedni App Store miatt, de forditva is, iPhone developert anyazni az Apple elfogadasi mechanizmusaert. :)

---
pontscho / fresh!mindworkz

Amig a forrast nem kell kiadni (ami durvan jogot sertene igy nem fog megtortenni) es a fent vazoltak alapjan nem dontheto el egyertelmuen melyebb analizis nelkul, hogy miben irodott (mert pl. ObjC wrapper), addig ezen a reszen at fog csuszni. Viszont az ismertebb wrapperek/cross compilerek (mono, FPC, flash ize) kiszurheto egy szimbolum tabla ill. hasznalt apik analizisevel.

Ha a generált objc kódra ráküld az ember egy obfuscatort (feltéve, hogy a wrapper forrása is megvan), akkor a szimbólumokból sok nem látszik, tényleg csak annyi, hogy engedélyezett API-kat hív vagy sem. Ha valamiért sikerülne nekik a jelenlegi XMLVM fordító mintáit felismerni, még mindig olcsóbb írni egy Java source -> ObjC source fordítót (jelenleg az XMLVM bytekódból fordít), mint több emberévnyi fejlesztést átírni ObjC-be. Az ilyen módon forrássorról - forrássorra átfordított kódot szerintem esélytelen megfogni.

Persze mindez akadémiai vita, hiszen a "nincs rajta sapka" elv alapján a TOS akárhanyadik pontja szerint dönthetnek úgy, hogy egy adott alkalmazást nem fogadnak el, ill. később eltávolítanak.

Szemet huzas, de ez van, lehet naluk anyazni, vagy elfogadni. Van elonye is, es hatranya is. Boven. Hallottam mar Android fejlesztot irigykedni App Store miatt, de forditva is, iPhone developert anyazni az Apple elfogadasi mechanizmusaert. :)
Előnye azok számára van, akik eddig is C / C++-ban / ObjC-ben fejlesztettek. Mindenki más veszít vele. A felhasználók is.

Azt senki ne próbálja meg beadni, hogy a sok Flashes alkalmazás az mennyire ártott volna a platformnak. Kicsit kellett volna módosítani az AppStore szabályokon, hogy kezelje a néhány nagyságrenddel több alkalmazást, és kész.

Meg röhögnöm kell a "cross-platform alkalmazások nem olyan jók" rizsán is. Mind a MonoTouch, mind az XMLVM az UIKitet használja, úgy ahogy az a dokumentációban meg van írva. Unity3D-t nem ismerem, de felteszem a korábbi szabályok alapján sem engedték volna be az appokat, ha nem felelt volna meg a Human Interface Guidelinesnak. A szar programozó bármilyen nyelven szart fog írni, felesleges ráfogni egy eszközre.

Jaj és a multitasking, hogy a cross-platform appok majd leszívják az akkut? Nem azért van a nagyon fejlett OS, hogy ezt ne hagyja? Ki kell lőni a rosszalkodó appokat és kész (memóriazabáláskor simán meg is teszi). Arról nem beszélve, hogy a jelenlegi 80 milliós eszköz piac jelentős részén nem is fogják soha támogatni a mulititaskot, mert nem elég erős a processzor szerintük...

Az a tény, hogy az Android Market egy röhej, és "gondos munkával" sikerült olyan felhasználóbázist felépíteni, akik nem szívesen fizetnek appokért, tény. Még nagyobb gáz, amit most lehet hallani, hogy majd operátorok (mint a Vodafone) fognak üzemeltetni AppStore-okat Androidhoz.

Ettől teljesen független, hogy jelentős kockázatot kell vállalnod iPhone-ra fejlesztéssel, hiszen _bármikor_ dönthet úgy az Apple, hogy az alkalmazásod mostantól sérti az érdekeit. Esetleg csak simán visszatartja addig, amig a saját megoldása ugyanarra az ötletre elkészül...stb.

Nyilván egy ekkora piacot, pláne ennyire szívesen vásárlót, nem lehet figyelmen kívül hagyni. De amig ennyire bizonytalan egy iPhone-os fejlesztés, mi mindenképpen úgy fogunk tervezni, hogy az iPhone nélkül megérje megcsinálni, és az iPhone meg vagy bejön, vagy nem.

Üdv,
Gergely