Na początku 2018 Mark Gurman, opublikował w serwisie Bloomberg informację o planach umieszczenia w nowych systemach iOS 12 i macOC 10.14 krosplatformowego API. Jednak najnowsze doniesienia sugerują, że nie będzie uniwersalnych aplikacji w tym roku.

Jak by to miało działać?

Już kiedyś napisałem, jak wyobrażam sobie możliwość uruchamiania nowych, dostosowanych aplikacji na obu systemach. Nie będzie to zrobione na zasadach emulacji środowiska iOS w macOS, bo to pochłania zbyt wiele zasobów i nie byłoby wygodne w użytkowaniu.
Powinno powstać uniwersalne API łączące te funkcje interfejsu dotykowego z iOS, które da się w sposób wygodny dla użytkownika zaimplementować w całkiem odmiennym środowisku macOS. Odmiennym, bo „klikalnym”. Mysz i jej wskaźnik nie ma szans zastąpić wielu funkcji z iOS, gdzie używamy wielodotyku. Wsparciem mogą być gesty na gładziku, ale zwolennikom myszek to nie pomoże. Dlatego tak ważny jest dobór wspólnych funkcji.
Wielkość ekranu nie powinna być wielkim problemem. Apple od lat promuje pisanie uniwersalnych aplikacji (dla iPhone i iPada), w których za pomocą Auto Layout i innych sztuczek dostosowuje się rozmieszczenie elementów interfejsu do wielkości i proporcji ekranów. Pojawia się też nowa opcja, ale o tym niżej.
Procesor to też żaden problem. Od samego początku prawie każdy program na iOS daje się uruchamiać w symulatorze w Xcode na macOS. Nie jest to emulator. Do testów Xcode generuje kod dla Intela. Teraz wystarczy, że nowe i przerobione aplikacje będą zawierały w sobie kod na obie platformy. Obecnie na iOS programy zgodne z 32-biotwymi urządzeniami i iOS 10 lub starszym zawierają dwie wersje kodu (32- i 64-bitowego).

Wcale tak być nie musi

Dla wielu deweloperów Auto Layout jest zmorą. Nie potrafią go zrozumieć, prawidłowo używać i nie wykorzystują nawet ułamka jego ogromnych możliwości. Uciekają do rozwiązań uniwersalnych podobnych do tych używanych podczas budowy stron WWW. Tak tworzone programy są w większości produktami aplikacjopodobnymi. Jednak pochłaniają mniej energii i zasobów w firemkach tworzących programy niskobudżetowe. Niestety obecnie nie jest łatwo znaleźć aplikację wykorzystującą poprawnie możliwości iOS i macOS.
Według Johna Grubera Apple może stworzyć uniwersalne API zbliżone w użyciu (od strony programistycznej) do React i innych uniwersalnych potworków stosowanych w sytuacjach, gdy trzeba zrobić uniwersalną aplikację na kilka systemów, niższymi nakładami lub stosowanych przez tych, którym nie chce się uczyć Auto Layout i innych natywnych metod od Apple.
Niestety może to spowodować opóźnienie wdrożenia tego API o rok. I nie musi to być zła wiadomość.

Jakość głupcy!

To też już wiemy, że Apple będzie koncentrował się obecnie na jakości systemów, a nie na ustalonych terminach udostępniania nowych funkcji. Już widzimy, że dość ważne nowości są wprowadzane w „małych” aktualizacjach. Co więcej, jeżeli Apple nie jest pewne ich działania, to potrafi zrezygnować z udostępnienia w finalnej wersji tak, jak to miało miejsce z AirPlay 2 i z Wiadomości w iCloud, na które czekamy już ponad pół roku.
Mam nadzieje, że Apple, nowe prostsze w użyciu i uniwersalne API chce zrobić najlepiej, jak się da. Pozwoli to leniwym programistom na wydajną pracę bez konieczności nadmiernego przemęczania się nauką, a użytkownikom zapewni jakość aplikacji zbliżoną do tych tworzonych w dobrej, applowskiej praktyce programistycznej.
Osobiście nie jestem zwolennikiem takich uproszczeń, ale gdy sobie przypomnę męki przy poznawania Auto Layout, który obecnie bardzo lubię i szanuję, to mogę zrozumieć, że nie każdemu się chce opanowywać tę sztukę.

Czy rzeczywiście poczekamy rok?

Nawet gdy nowe uniwersalne API nie będzie wprowadzone podczas WWDC 2018, to wcale nie musi oznaczać, że będziemy czekać kolejny rok. Apple może zdecydować się na udostępnienie tego API w ramach mniejszych aktualizacji. Jedno jest pewnie, do WWDC 2018 pozostał miesiąc i kilka dni i już wtedy wiele się wyjaśni.