Однако не всё так просто. Помимо идентичных задач, есть и платформозависимые, когда подходы на iOS и Android ощутимо различаются: работа с UI, обращение к hardware-компонентам вроде камеры или сенсоров, и так далее. В итоге благие намерения «давайте из двух кодовых баз сделаем одну» нередко заканчивались тем, что баз становилось три (общая, которая используется обеими платформами, и две специализированные). На трёх разных языках. Компании обнаруживали, что результат противоположен ожиданиям, и разочаровывались.
Спасибо, статья хорошая, добавил в закладки.
В отличие от Google и Facebook, которые зарабатывают на рекламе и хотят увидеть себя на как можно большем числе устройств, Apple не заинтересован в кросс-платформенной разработке (в Apple «кросс-платформенный» означает iOS + macOS + watchOS + tvOS).
Наоборот — компании нужен эксклюзивный функционал для своих пользователей, который затратно повторить на других платформах. И на очередной WWDC в июне выйдет ещё несколько новых фреймворков (и обновлений старых), которые кросс-платформенные решения не смогут быстро реализовать.
А игнорировать iOS не получится — пользователей iOS меньше, но денег они приносят больше. Избавиться от нативной разработки не удастся, пока жив Apple.
Если не ошибаюсь, то приложения на ведре уже больше денег приносят или сопоставимо. Ну если не считать конечно количество прибыли на пользователя. По поводу "эксклюзивный функционал для своих пользователей, который затратно повторить на других платформах" можно хоть один пример того, что трудно повторить на андроиде и эпл специально какие-то палки в колеса вставляет? Насколько я знаю им пох, лицензия разработчика стоит $100 в год, неважно на чем ты писать будешь на реакте или нативе. Собрать ты все это сможешь все равно только на маке, если без боли в заднем проходе, и только если заплатил соточку
// Подождите, мы оказывались недовольны, если из двух кодовых баз получалось три, а нам предлагают сразу же именно так и сделать. В чём тогда смысл вообще?
Идея-то была в том, что из двух кодовых баз предполагается выделить общую абстрактную часть, не зависящую от конкретной платформы. Если действительно следовать принципам "чистой архитектуры" от дядюшки Боба (Роберта Мартина, не путать с Джорджем), то у нас получается, что у нас на каждую платформу есть две кодовых базы - с привязкой к фреймворку и полностью абстрактная логика. И переход на 3 базы означает экономию на одной абстрактной базе, которую все сейчас пишут заново.
Но есть две проблемы:
1. Практическое отсутствие действительно чистой архитектуры. Я работал в командах, которые декларировали чистую архитектуру под Андроид, но на деле это была просто удобная распилка на небольшие классы - но в каждом слое была привязка к конкретному фреймворку (Android). В то время, как "фреймворк - это деталь реализации" (с) Роберт Мартин в книге "Чистая архитектура". Следовательно, нет чистой абстрактной кодовой базы, которую можно было бы сделать общей, вообще нет привычки писать полностью оторвавшись от Андроида - отсылки к контексту и конкретным либам можно встретить на любом этапе логики.
2. в Андроид и iOS исторически сложился разный конкретный принцип "пиления" на отдельные классы - то, что называют "чистой архитектурой" из п.1 (которая, как я пояснил, часто не является чистой, так как в абстрактном слое нужна полная отвязка от платформы, от конкретных либ, даже от Rx, как бы это ни было тяжело). К примеру, в нашей команде iOS упарывался в хорошем смысле по VIPER, а Андроидеры фигачили разновидности MVC-MVVM.
Поэтому, когда Андроид-девелопере садились пилить на Xamarin, они писали общую часть по своим принципа, а iOS-отдел - хотел писать по своему. Это и создает дополнительные проблемы в кроссплатформе - столкновение "архитектурных привычек"
Универсальный-то выход по Роберту Мартину, который выстрадал свою точку зрения за десятки лет программирования (он кодил еще в 60х) - в таком пилении на классы, в такой архитектуре, в которой есть чистая логика, не привязанная к платформе, с объявленными интерфейсами, и блок реализации на конкретном фреймворке, платформе, устройстве. Тогда нам будет без разницы, какая ось победила в этом десятилетии и куда еще клиент хочет портировать свою программу - нам надо будет взять только часть кода, привязанную к конкретной реализации, и сделать ее для новой платформы.
"он кодил еще в 60х"
Сергей, ну Вы сравнили, мамонта из 60-х и современные практики разработки :) Это как авто на паровом двигателе сравнивать с Теслой.
Сейчас разработка ПО ускоряется, никому эти вот архитектуры не всрались:
"в таком пилении на классы, в такой архитектуре, в которой есть чистая логика, не привязанная к платформе, с объявленными интерфейсами, и блок реализации на конкретном фреймворке, платформе, устройстве"
Пока Вы будете писать свою идеальную архитектуру, конкуренты уже запустят продукт и словят хайп и бенефиты. А под конец разработки Вашей идеальной архитектуры придет Product Owner и своими бизнес-требованиями разнесет эту архитектуру в неудачную поделку. Или при тестировании выяснится, что надо все переделывать из проблем с производительностью или совместимостью.
Касательно iOS/Android, если приложение позволяет использовать Cordova или React Native - тут можно сэкономить на кодовой базе, если нет - то лучше и не пытаться.
Абсолютно точно!
Всё уже давно придумали, сделали, причём и код и UI, поддерживают не только Android и iOS, но так же весь десктоп и встраиваемые системы.
Технология проверенная десятилетиями.
Другое дело, что построена не на ванильных котлино-свифтовых-дарто-жс-жабах, а на языке, который, как известно, за 21 день не изучить - C++
Называется фреймворк Qt.
Code less, create more, deploy everywhere!
А сколько мегабайтов рантайма у qt под Андроид и как дела с нативно выглядящим UI?