С начала века разработка мобильных приложений значительно увеличивалась из года в год. В первом квартале 2020 года в Apple App Store было примерно 1,8 миллиона приложений, а в Google Play Store — примерно. 2.5 миллиона. Что еще более важно, все признаки говорят о том, что эта тенденция будет продолжаться, и поскольку COVID-19 затрагивает каждый бизнес любого размера, реальность такова, что все компании теперь развивают мобильное присутствие в дополнение к одному в Интернете. Единственными крупными игроками в сфере разработки мобильных приложений остаются Android и iOS, на которые в совокупности приходится около 98% от общей доли рынка мобильных операционных систем. Два крупных игрока, контролирующих рынок, могут почувствовать объединение, которое может привести к основанному на стандартах подходу для разработчиков. К сожалению, два доминирующих игрока превратились сплошные проблемы для разработчиков.
Для разработки на обеих платформах требуются две отдельные команды. Эти команды обычно разрабатывают одно и то же, используя разные языки и фреймворки. Это приводит к значительной избыточности и увеличивает общие затраты на разработку ваших мобильных приложений. Даже с точки зрения пользовательского интерфейса каждая платформа начала адаптировать дизайн другой, и в результате разрыв и различия между ними сократились.
Instagram для iOS и Android (пример)
Сообщество вмешивается в гонку
В последние годы между Google и Apple была такая жесткая конкуренция, что они не заботились о стандартах для этих двух платформ. Из-за этой проблемы мобильное сообщество было вдохновлено вмешаться и создать фреймворки, такие как Cordova, Ionic или NativeScript. Другие компании также начали разрабатывать свои кроссплатформенные фреймворки, такие как Microsoft Xamarin, Adobe Ionic и Facebook ReactNative, что заставило Google и Apple столкнуться с новой реальностью.
Все упомянутые выше фреймворки дали преимущество наличия одного кода для обеих платформ и, в некоторых случаях, одного языка как для Интернета, так и для мобильных устройств. Это огромное преимущество. К сожалению, у этого преимущества есть и обратная сторона, а именно более низкая производительность и точность пользовательского интерфейса.
Ответ Google и Apple на кроссплатформенные решения
В последние годы все больше и больше крупных компаний склоняются к ReactNative / Xamarin или другим кроссплатформенным решениям для своего бизнеса. Они делают это, потому что не могут позволить себе собственное решение, поэтому вместо этого идут на компромисс в пользу более экономичного кроссплатформенного решения. Альтернатива — отсутствие мобильного присутствия, и это компромисс, с которым не могут мириться большинство компаний. Давайте посмотрим, что Google и Apple сделали в этой сфере:
1. Swift
Исторически Apple застряла в разработке и продвижении собственных систем, в основном для решения проблем безопасности и поощрения покупки их оборудования. Однако в современную эпоху наблюдается рост программного обеспечения с открытым исходным кодом и снижение лояльности к бренду, когда многие пользователи переходят между платформами и операционными системами (например, с телефона Android на рабочий стол Windows на часы Apple). Apple, похоже, решила продвигать Swift как язык за пределами своих платформ. По состоянию на 2015 год Swift является языком с открытым исходным кодом. В рамках этого Apple выпустила двоичные файлы Swift для использования в Ubuntu.Опять же, сообщество подхватило это и настаивало на кроссплатформенной разработке. Swift можно использовать для написания серверного кода с помощью Vapor, и вы даже можете портировать Swift в Windows и Android.
2. SwiftUI
В 2019 году Apple выпустила SwiftUI с целью использования единой платформы на всех платформах Apple. Это отличается от нынешней системы, в которой есть WatchKit для watchOS, AppKit для macOS и UIKit для iOS и tvOS. Это важно для разработчиков, работающих в экосистеме Apple, поскольку это объединяет платформы и упрощает создание приложения для всех из них. Опять же, еще до выхода из бета-версии сообщество Swift создало способ запуска SwiftUI в браузере. Еще неизвестно, воспользуется ли Apple этим сами, но это еще одна ступенька для Swift к работе на всех платформах.
3. Flutter
В мае 2018 года, через три года после того, как Facebook выпустила ReactNative, Google выпустила Flutter. Flutter — это набор инструментов пользовательского интерфейса Google для создания скомпилированных в собственном коде приложений для мобильных устройств, Интернета и настольных компьютеров из единой кодовой базы. Flutter — это бесплатный и открытый исходный код. Flutter отличается от большинства других вариантов создания мобильных приложений, поскольку Flutter не использует ни WebView, ни OEM-виджеты, поставляемые с устройством. Вместо этого Flutter использует собственный высокопроизводительный движок рендеринга для рисования виджетов.Flutter быстро стал очень популярным и теперь конкурирует с ReactNative по популярности. «Google Trends» Звучит здорово, правда? Обратной стороной Flutter является то, что он использует Dart в качестве языка, поэтому разработчикам нужно будет изучить новый язык, чтобы начать создавать приложения Flutter.
Flutter еще молод, и ему не хватает больших производственных приложений, полностью построенных на Flutter. Во многих отношениях Flutter еще предстоит проявить себя.
4. Kotlin
Через несколько лет после того, как Apple анонсировала Swift, на Google I / O 2017 Kotlin был представлен в качестве официального языка разработки для Android. В 2018 году Kotlin был самым быстрорастущим языком на GitHub с количеством разработчиков в 2,6 раза по сравнению с 2017 годом, и это четвертый по популярности язык программирования согласно опросу разработчиков Stack Overflow 2020.Почему это важно? Потому что это еще один шаг к кроссплатформенности. Kotlin работает на стороне сервера, а команда разработчиков языка Kotlin работает над мультиплатформенным проектом Kotlin, который позволит разработчикам использовать Kotlin для разработки под iOS. Кроме того, сообщество создало Ktor: фреймворк для простого создания подключенных приложений — веб-приложений, HTTP-сервисов, мобильных и браузерных приложений. Работа на всех платформах — явная цель для Kotlin — https://kotlinlang.org/ Идея мультиплатформенности Kotlin интересна тем, что она не влияет на способ построения пользовательского интерфейса в iOS. Вы по-прежнему будете использовать свою родную среду разработки для создания пользовательского интерфейса и использовать Kotlin для бизнес-логики своего приложения. Еще один интересный факт: количество рабочих мест для разработчиков Kotlin для Android выше, чем у Swift, по данным LinkedIn.
Из приведенных выше примеров видно, что и Google, и Apple могут использовать выбранный ими язык на нескольких платформах. Google пошел дальше и также разработал свою многоплатформенную структуру с Flutter. И Kotlin, и Swift необходимо найти решение для кроссплатформенности, иначе языки уступят место JavaScript из-за его популярности и того факта, что ReactNative улучшает свою производительность и пользовательский интерфейс.
5. Declarative UI
В последние годы и Google, и Apple позаимствовали декларативную систему пользовательского интерфейса из Интернета, используя ее во фреймворках Flutter, Jetpack Compose и SwiftUI. Это означает, что в будущем разработчику Swift больше не нужно понимать структуру Android XML, а разработчику Android больше не нужно знать, как работать с файлами XIB или раскадровками.
Создай код один раз, запускай везде?
Некоторые будут утверждать, что пользовательский интерфейс iOS и Android никогда не сойдется, и вам все равно нужно будет написать конкретный код для интерфейса каждой платформы. Я склонен с этим согласиться, хотя такие фреймворки, как Flutter и ReactNative, также смогли решить эту проблему. Даже если пользовательскому интерфейсу по-прежнему необходимы знания о конкретной платформе, появившиеся в последнее время декларативные структуры пользовательского интерфейса, вероятно, решат эту проблему, упростив понимание и написание кода одним разработчиком для обеих платформ. А как насчет остальной части приложения? Многие разработчики считают, что бизнес-уровень, сетевой уровень, уровень сохраняемости и уровень представления не должны дублироваться для обеих платформ. Kotlin Multi-Platform, похоже, решает эту проблему, но пока еще рано выносить вердикт по этому поводу. Как и большинство из нас, я жду, чтобы увидеть, какое решение окажется победителем в этой гонке. Но я думаю, мы все согласимся с тем, что рационально и эмоционально «один раз учись, создавай где угодно» — лучший подход, чем «создавай один раз, запускай везде». У нас не может быть универсального решения для всех платформ, но как минимум нам следует иметь тот же язык и модели.
