Aplikacje na iPhone OS tylko w Objective-C

2010-04-12

Apple więcej nie wpuści do App Store aplikacji napisanych inaczej niż za pomocą ich SDK. Koniec z generatorami kodu, koniec z nadziejami Adobe na narzędzie generujące z Flasha aplikacje iPhone.

Odbywa się na ten temat wielka awantura. Nieco zabawna, bo patetyczne odwołania do ideałów wolności i otwartości padają ze strony pracowników Adobe, która to firma nic wspólnego z wolnością i otwartością nie ma — więcej, której celem jest wprowadzanie własnych rozwiązań zamiast otwartych standardów. Reakcja niektórych była mało profesjonalna.

Większość dyskusji odbywa się w chmurach (strategie, otwartość, wolność, rynki), a tymczasem zapomina się (jakże typowe) o użytkowniku.

Nie da się pisać aplikacji „cross-platform” używając magicznego zestawu narzędzi. Takie programy zawsze będą działać źle, sprowadzając wszystkie wspierane platformy do wspólnego mianownika i nie zachowując się poprawnie na żadnej. Istnieje wiele przykładów: w mniejszym lub większym stopniu niezależność próbują osiągnąć Adobe AIR, Qt, wxWidgets, FLTK. Nie znam jednak aplikacji „cross-platform”, która działałaby poprawnie. Zawsze są niedociągnięcia, które robią się szczególnie uciążliwe dla tych, którzy przyzwyczajeni są do bogatszych w funkcjonalność systemów.

Dobrym przykładem w tej dyskusji są zresztą aplikacje Adobe dla Mac OS X. Unikam ich, jeśli tylko mogę, bo żadna nie działa dobrze. Poza gwałtem na moim komputerze, typowym dla Windows, ale nieznanym w świecie Mac OS (installery, wgrywanie plików gdzie się da, własne systemy aktualizujące, itp) całe GUI nie zachowuje się dobrze. Przewijanie nie działa tak jak gdzie indziej, okienko File|Open nie pozwala na „wrzucenie” pliku z innego miejsca, przykłady można mnożyć. Świetnie podsumował to Merlin Mann:

Because, with Adobe apps, everything from installation through activation through re-activation through software updates through more re-re-reactivations through (HEY! more updates!) is like a giant rectal exam. That I paid for.

Apple (Steve Jobs) ma sporą historię wyrzucania „poprawnych politycznie” rozwiązań do kosza, gdy uważa, że nie służą użytkownikowi. W MacOS X jest pełno przykładów: co, wszystkie aplikacje nie są w /usr/bin?! System plików nie rozróżnia dużych i małych liter?! Nie ma init tylko jakieś launchd?! Kto w ogóle słyszał o Objective-C?! Wszystkie te decyzje wywoływały kiedyś oburzenie zatwardziałych UNIXowych tradycjonalistów. Wszystkie też okazały się korzystne dla platformy i dla tego, co widzi użytkownik.

W tym przypadku chodzi o to samo. Och, owszem, na pewno jest drobna przyjemność z dania prztyczka w nos Adobe, ale główny cel punktu 3.3.1 EULA SDK jest inny. Apple wkłada mnóstwo wysiłku w zrobienie dobrej platformy dla aplikacji i nie chce, by ktoś sprowadzał ją do wspólnego mianownika z innymi. Żadna automatycznie generowana aplikacja nie będzie tak zintegrowana z platformą jak ta napisana przy pomocy narzędzi Apple.

Co więcej, dla Apple nie jest dobrze mieć pośredników pomiędzy sobą a programistami. Wyobraźmy sobie sytuację, gdy Apple wprowadza nowe API, chociażby do akcelerometru — a potem musi czekać aż Adobe wyda kolejną wersję swoich narzędzi zanim programiści będą mogli z tego API skorzystać. A może nigdy nie wyda, skoro takie API istnieje tylko na iPhone?

Jako programiście nie podobają mi się ograniczenia wprowadzane przez Apple. Jako użytkownikowi iPhone jednak — zupełnie mi nie przeszkadzają, a nawet jestem z nich zadowolony. Dzięki nim będę miał aplikacje działające szybko, poprawnie i pasujące do platformy.


Komentarze

Ta, jasne :). Multitaskingu też nie ma, żeby polepszyć UX... A nie, sorry - jednak się okazało, że hardware iP sobie poradzi z wielozadaniowością! Czary?

Adam2010-04-12

Adam: nie rozumiem co chcesz powiedzieć.

Jeśli pytasz o moje zdanie, to multitaskingu na iPhone nie było, bo Apple nie wiedziało jak zrobić go tak, żeby nie był równie beznadziejny co na innych platformach.

„hardware iP, który sobie nie radzi z wielozadaniowością” to jakaś oczywista bzdura i nie przypominam sobie by Apple kiedykolwiek coś takiego mówiło.

Jan Rychter2010-04-12

a widzisz - a mi jako programiscie rowniez sie to podoba. nie mam nic przeciwko konkurencji - czesto bywa ona dobra, mobilizujaca, ale juz w appstore sa aplikacje napisane dzieki wspanialemu flash-to-iphone compiler i ich jakosc jest straszna. np. aplikacja metronom (mozna sie domyslic do czego sluzy) zajmuje 8 MB, dziala wolno a ludzie po jailbreaku moga rowniez stwierdzic, ze to memmory hog - w przypadku wprowadzanego multitaskingu to ile pamieci zra inne aplikacje ma juz znaczenie - taki prosty metronom dziala na granicy otrzymania ostrzezenia o braku pamieci (pozostawia bodajze 3 MB RAMu wolnego). ktos pokusil sie o napisanie jej odpowiednika z uzyciem objective-c i narzedzi apple - aplikacja "wazy" 300 KB. to daje poglad na to jakiej jakosci bylyby aplikacje owej konkurencji i o ile pogorszylby sie wizerunek platformy jako takiej (przeciez uzytkownik nie wie czy aplikacja zostala napisana za pomoca flash'a czy nie - dla niego - "wszystkie nowe" ssa), co byloby niekorzystne dla reszty developerow aplikacji na iphone'a.
no i oczywiscie 99.9% aplikacji byloby skaczacymi kuleczkami, kolejnymi ifart'ami i naprawde niczym innym niz tylko zapychaczem miejsca - a patrzac na (przyznam - daleki od idealu) sposob prowadzenia appstore (akceptacje, sama konstrukcja appstore) - to rowniez odbiloby sie na reszcie developerow.

btw. slyszeliscie historie, ze adobe przygotowalo swego czasu flash'a na iphone'a? w testach wyszlo, ze pozostawienie animacji flashowej wlaczonej skracalo czas pracy na baterii do ok. 0.5h. a adobe nadal uwazalo, ze wtyczka ta powinna zostac wprowadzona w kolejnym update'ie systemu. co ciekawe tez nie byli oni zainteresowani napisaniem aplikacji do appstore (w odpowiedzi dostali taka propozycje od apple - wraz ze wskazowka aby do grafiki uzywac GPU, a nie tak intensywnie CPU) ktora firmowaliby swoja marka, a ktora umozliwialaby obsluge flasha.

cross-platform sie sprawdza, ale jedynie w niewielkiej ilosci przypadkow, do ktorych na pewno nie mozna zaliczyc GUI aplikacji. no i dodatkowo ten cross-platform musi byc dobrze napisany.

pendowski2010-04-12

Czy możesz podać źródło historii o tym, że Apple miało zaproponować Adobe napisanie aplikacji do obsługi flasha? Nigdy się nie natknąłem na żadną informację o tym.

Poza tym w całej aferze z 3.1.1 niepokojące jest bardziej kolejne rozmyte kryterium przy wpuszczaniu do AppStore'a. Wpis w postaci


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

nie specyfikuje co jest już "compatibility layer". Czy jeżeli napiszę własną bibliotekę widgetów to jest już źle? A jak dodam tam własną abstrakcję do warstwy sieciowej, bo stwierdzę, że potrzebuję jedną konkretną ścieżkę i łatwiej mi korzystać z własnej klasy? A czy jak przykryję całe API swoimi funkcjami? Prawie na pewno odpowiedź na pierwszą propozycję to "nie" a na ostatnią już "tak". Tylko kiedy są to jeszcze biblioteki wspomagające ponowne wykorzystanie kodu, a kiedy compatibility layer to już może być kwestia sporna.
Kuba Bogaczewicz2010-04-12

compatibility layer oznacza, ze piszesz bibloteke ktorej potem linkujesz, zamiast do SDK apple'a. np. biblioteke widgetow w stylu wx, tyle ze na platformy np. iphone i android. wiem, ze przyklad jest sredni chociazby dlatego, ze android smiga na java'ie, ale to taki abstrakcyjny przyklad. sek w tym, ze podobnie uczynilo adobe - tworzac warstwe posrednia pomiedzy flashem, a iphone'em - piszac aplikacje we flashu "linkujesz" do ich bibliotek (ktore z kolei operuja na iphone'owym API), a nie do oryginalnego SDK. i tak masz np. flashButton w AS zamiast NSButton w objective-c. i to jest ten layer. niestety w wiekszosci przypadkow nie mozesz napisac "nie mozesz uzywac warstwy posredniej firmy adobe" - musi byc ogolnie w miare ogolnie, zeby dokumentu nie musiec aktualizowac co 2 dni.
a co do twoich pytan - we wszystkich przypadkach powiedzialbym nie, bo natualnym jest ze tworzysz swoje klasy, biblioteki nawet dla usprawnienia pracy. czym innym jest jednak taki np. cocos2d dla iphone'a uwalniajacy cie od wywolywania funkcji opengl "recznie", a czym innym kompilator od adobe.

co do historii - wybac - nie pamietam juz gdzie pierwotnie trafilem na ta historie, ale spotkalem sie z nia kilkakrotnie. nawet mozna ja wygooglowac - http://www.reddit.com/r/apple/comments/a0cqa/fight_for_flash_on_the_iphone_gets_dirty/c0jt7fj

pendowski2010-04-14