Uniwersalne aplikacje niepokoją mnie, bo można to zrobić dobrze lub po Microsoftowemu, a dodatkowo wciąż sprawdza się powiedzenie cioci z ameryki reklamującej środki do prania: „Co jest do wszystkiego, to jest do niczego”.

Idą święta, czyli marcepan

Wczoraj Bloomberg ujawnił informację o projekcie „Marzipan”. Ma on pozwolić w nadchodzących systemach na uruchamianie tej samej aplikacji na macOS i iOS. Apple rzekomo dostarczy narzędzi do tworzenia programów działających w środowiskach z interfejsem dotykowym lub klikanym. Brzmi strasznie dla każdego, kto próbował pracować dotykowo lub rysikiem na Windows Surface – Tragedia.

Informatorzy Bloomberga zastrzegają, że program o kodowej nazwie „Marzipan” wciąż ewoluuje i może zostać zamknięty. Apple chce przy jego pomocy ożywić rynek aplikacji na macOS, co również świadczy o tym, że komputery wciąż są dla nich ważne.

Za przykład uzasadniający aplikacje uniwersalne podano oficjalnego klienta Twittera. Na iOS wydawane są częste aktualizacje, na macOS znacznie rzadziej.

Uniwersalne aplikacje już są!

Nie mam na myśli tych na iPada i iPhone’a, ale na iOS i tvOS. Przykładem niech będzie moje RadioOnTV. Jeżeli wyłączyć funkcje niedostępne w tvOS, to reszta kodu pokrywa się niemal w 99%. A przecież oba systemy są obsługiwane w bardzo odmienny sposób.

Na szczęście tvOS został od początku projektowany tak, aby mieć, jak najwięcej wspólnego z iOS. Choć interfejs został przystosowany do obsługi pilotem beż żadnych kompromisów i ukłonów w stronę CocoaTouch (interfejsu z iOS), to jeżeli nie planujemy używania wielodotyku, kod programu może być niemal identyczny. To rzeczywiście ułatwia i przyśpiesza pisanie programów pomimo tak odmiennego wyglądu tych środowisk.

Dodatkowo Apple dał możliwość tworzenia zestawów aplikacji, tak aby klient, kupując wersję na iOS, otrzymywał gratis tą na tvOS i odwrotnie. Takiej możliwości nie mamy w ducie macOS – iOS, a od tego można by zacząć.

Uniwersalność „na maksa” – zło wcielone

Na przykładzie Microsoftu wyraźnie widać, że tworzenie uniwersalnych aplikacji dla środowisk klikalnych i dotykowych jest bardzo trudne. Im się to po prostu nie udało. Jeszcze trudniejsze jest napisanie uniwersalnego systemu. Fani Microsoftu pewnie przymykają oko na problemy z obsługą Surface (tak jak my na niektóre wpadki Apple), ale nawet i im wyrywają się podczas pracy stłumione przekleństwa.

Uniwersalne aplikacje… może to nie takie głupie?

Nawet taki amator jak ja potrafi napisać (prosty) program na obie platformy (macOS i iOS), aby było w nim 85% kodu wspólnego. Tak powstał mój Piston Calc. To naprawdę nie jest trudne. Różnice są jedynie w obsłudze interfejsu. I są one niestety duże. Interfejs macOS zaprogramowano (nie piszę o wyglądzie, a o metodach i API, jakie są użyte) za czasów NeXTStep. Zrobiono to dobrze, ale tylko pod obsługę myszki. Potem dodano funkcje dla gładzika i gesty.

CocoaTouch, czyli dotykowy interfejs iOS powstał znacznie później i miał za zadanie połączyć jak najlepsze wrażenia z użytkowania ze sprzętem o znikomych możliwościach. Jak wiemy, udało się to bardzo dobrze, ale głównie dzięki uproszczeniom. Dlatego obsługa nawet pozornie takich samych elementów na iOS i macOS od strony programowej jest tak różna. Np. tekst wyświetlany na iOS obsługuje się klasą „label”, która na macOS nie istnieje. Obsługa list przewijanych jest pozornie zbliżona, jednak ma sporo odmienności. Tak czy siak, większość programu może być identyczna, a kompilator sam sobie poradzi z tworzeniem kodu na odpowiednie procesory. Dodatkowym ułatwieniem jest możliwość tworzenia aplikacji na wiele platform w jednym projekcie w Xcode. Części wspólne „podłączamy” do wszystkich „targetów”, a różne do konkretnych systemów. W programie dodajemy warunki sprawdzające, na który „target” program jest kompilowany i wybierające odpowiednie elementy z tych różnych. Interesujące, czy to był problem dla programistów Twittera?

Jak to zrobić dobrze?

Jednak uniwersalne aplikacje w stylu tych, tworzonych za pomocą rzekomego projektu „Marzipan” nie są pozbawione sensu. Znów niech za przykład przyjdzie Twitter. Jego wersja na macOS wygląda jak żywcem przeniesiona z iOS. Mnie to trochę drażni, bo wolę, gdy aplikacja pasuje do systemu, ale jednak w takim zastosowaniu się sprawdza. Zdecydowanie bardziej pasują mi takie podobieństwa, niż tworzenie na macOS aplikacji webowej zapakowanej w „skórkę” z programem, gdy ta sama firma na iOS wypuszcza prawdziwy program. Tak jest z Todoist.

Problemy

Klikanie z macOS na iOS jest bardzo trudno przenieść, widać to po dobrej, ale jednak nie aż tak przyjemnej, obsłudze drag&drop w iOS 11.

Jednak w drugą stronę może być łatwiej. Jeżeli zrezygnujemy z kilku gestów wielodotyku, to resztę funkcji daje się zaimplementować w macOS. Być może projekt „Marzipan” pozwoli na używanie tych samych API co na iOS przy obsłudze wybranych funkcji interfejsu. Pamiętajmy, że wiele API i to tak zaawansowanych, jak Metal (grafika 3D) jest w zasadzie identyczna od strony programisty na obu platformach.

Teraz wystarczy zebrać funkcje interfejsu iOS, które się da bez uszczerbku dla wrażeń użytkownika zagospodarować na macOS i do macOS dodać interfejsy API zgodne z iOS. Brzmi prosto, będzie proste do użycia dla dewelopera, ale aby to zrobić dobrze, programiści i projektanci w Apple muszą się trochę nagłówkować.

Efekty mogą być pozytywne. Może w końcu Slack na macOS przestanie się uruchamiać minutę, a Todoist zacznie działać jak prawdziwy program.

Ujednolicenie systemów?

Nie, nawet jeżeli dostaniemy możliwość tworzenia uniwersalnych aplikacji, to będzie to tylko furtka dla pewniej części programów, tych raczej prostszych, choć użytecznych i popularnych. Dodatkowo po to się robi taką furtkę, aby systemy nadal były różne. Nawet Cook w wypowiedziach podkreślał, że nie da się zrobić dobrze jednego uniwersalnego systemu, zachowując pozytywne wrażenia użytkownika. Jeżeli myślicie inaczej, to kliknijcie się w głowę!