Постбраузерная эпоха

Почему поддержка iPad-приложений на Mac может изменить то, как мы работаем за компьютером и планшетом — колонка менеджера по продукту vc.ru.

Если верить книге журналиста Брайана Мерчанда об истории создания iPhone, в компании было два отдела, которые параллельно работали над прототипами будущего смартфона.

Отдел, который хотел собрать телефон на базе популярного в те времена iPod, предлагал использовать Linux. Вторая команда сосредоточилась на адаптации OS X (старое название macOS) под работу с сенсорным экраном.

Победила команда OS X, которая предложила более гибкое и масштабируемое решение: в iPhone использовали то же ядро, что и в настольной операционной системе, которое позволяло довольно быстро переносить компьютерные приложения на смартфон.

Одним из ключевых преимуществ первого «iPhone, работающего на OS X» стал браузер, который, по словам Джобса, не уступал десктопному. Он загружал полноэкранные (а других и не было) версии страниц, поддерживал несколько вкладок, историю посещений и жесты.

Что ещё важнее, полноценный браузер давал возможность работать на смартфоне так же, как и на компьютере: читать новости, заказывать одежду в интернет-магазине, проверять ленты в соцсетях. Всё через единую точку входа.

Вместе с браузером и ядром настольной системы Apple попыталась перенести и десктопные сценарии работы. Например, вместо приложений предлагала разработчикам выпускать специальные веб-версии страниц, которые можно сохранять как иконки на рабочем столе — аналог ярлыков в OS X, ведущих на конкретные страницы в Safari.

Довольно скоро стало очевидно, что простой перенос десктопных сценариев на мобильные платформы не сработает. Использовать Safari для любых целей на маленьком экране неудобно, медленно и сложно.

Не помогали и веб-приложения: они полностью зависели от качества интернет-соединения, не отличались отзывчивым интерфейсом и не могли хранить информацию на устройстве.

Решением проблемы стал запуск App Store и концепция «для решения определённой задачи есть определённое приложение». Это изменило не только сценарии использования смартфонов, но и рынок приложений для мобильных устройств.

Каждый сервис стремился стать монополистом одной функции, разрабатывая нативные и быстрые приложения для iPhone.

Нативные приложения победили в удобстве веб-версии сайтов. Появились сценарии, в которых браузер вовсе не участвует: переход по ссылке на видео в Telegram сразу открывает его в приложении YouTube, ссылка на новость в соцсети открывает приложение издания (если, конечно, оно есть) и так далее.

Сейчас роль браузера в мобильной операционной системе заметно ослабла. Не у всех пользователей он попадает даже в пятёрку наиболее часто используемых инструментов на смартфоне. На мобильных платформах наступает постбраузерная эра.

Что происходило в это время с macOS? Операционная система продолжала жить в концепции «для всего есть браузер». Поэтому львиную долю времени работы за компьютером пользователи по-прежнему проводят именно в нём.

У приложений для компьютера сложился имидж инструментов, нужных либо для решения сложных задач, либо для того, что приходится постоянно держать в фоне, — мессенджера, почты.

Поэтому сторонние сервисы и компании особенно не стремились выпускать приложения для macOS. Спрос на них был неоднозначным даже с учётом понятного списка продуктовых преимуществ, сформированного мобильными платформами, — быстрый доступ, высокая скорость работы, вовлечённость пользователей, наличие уведомлений.

Впрочем, универсальное решение есть. Можно выпустить единое приложение, которое может сразу работать на мобильных и десктопных платформах. Практически об этом же способе разработки говорил Джобс на презентации первого iPhone, предлагая создавать приложения «для Web 2.0 и Ajax».

Например, можно использовать Electron. Кросс-платформенный фреймворк позволяет создавать приложения при помощи веб-технологии, — проще говоря, упаковывать веб-версии сервисов в отдельные продукты. На Electron работают Atom, Slack и даже Skype.

Плюсов много: быстрая разработка, единая команда программистов, одновременная поддержка сразу всех платформ — от Android до macOS. Такое кросс-платформенное приложение минимизирует потери бизнеса от того, что на одной из платформ приложение менее востребовано, чем на другой.

Правда, во всём этом списке достоинств есть один существенный недостаток: проблемы с оптимизацией. Для каждого приложения в Electron запускается свой отдельный браузерный движок Chromium, не отличающийся экономным расходованием ресурсов компьютера. Два-три одновременно открытых Electron-приложения могут довольно быстро «съесть» оперативную память устройства.

Проблем с эффективностью использования ресурсов компьютера не возникает у нативных приложений для macOS, которые оптимизированы для работы в операционной системе Apple. Они быстрые и лёгкие, однако для их создания придётся нанимать отдельный штат разработчиков, что зачастую слишком дорого для бизнеса.

Apple предлагает свой вариант решения проблемы. На WWDC 2019 компания анонсировала Project Catalyst — возможность быстрого переноса iPad-версии приложении на Mac. Достаточно поставить галочку в Xcode, настроить строку меню и адаптировать экраны, чтобы на выходе получить готовое macOS-приложение.

Таким образом Apple преследует три цели:

На мой взгляд, от этой затеи Apple изменится восприятие iPad и работы на компьютере.

Apple уже несколько лет создаёт из iPad полноценную альтернативу компьютера и стремится превратить его в главное устройство посткомпьютерной эры.

Всё, что для этого требуется, — сделать так, чтобы у пользователя, который выбирает в магазине устройство для повседневных задач, не оставалось весомых доводов в пользу покупки компьютера. То есть нужно сделать iPad — устройство, созданное на базе iPhone, — как можно более похожим на Mac по функциональности.

Apple уже решает эту задачу с точки зрения операционной системы. Компания постепенно переносит ключевые десктопные сценарии работы на планшет.

В последних версиях ОС на iPad появились быстрые сочетания клавиш, поддержка нескольких окон, проводник файлов, скачивание документов в Safari, подключение внешних накопителей.

Однако при этом не решалась другая важная проблема — планшету не хватало приложений, которые по функциональности как минимум не уступают полноценным веб-версиям сервисов и как максимум могут сравниться с производительностью немногочисленных, но весьма удобных приложений для macOS.

Зачастую текущие iPad-приложения больше похожи на перевёрстанные приложения для iPhone. Что вполне логично: разработчики часто создавали их на базе смартфон-версий — с ограничениями маленьких экранов, без учёта преимуществ физической клавиатуры и одновременной работы с несколькими приложениями.

Поддержка iPad-приложений на Mac должна поменять этот цикл разработки. iPad отдаляется от iPhone и становится ближе к Mac. Поэтому приложения для iPad и Mac теперь должны разрабатываться одновременно и совсем не на основе iPhone.

Разработчикам придётся создавать приложения, которые будут одновременно обладать преимуществами планшетной платформы и решать задачи десктопного уровня. В противном случае у пользователя просто не будет мотивации открывать приложение вместо браузера.

Успех инициативы Apple будет зависеть от того, как много разработчиков смогут выпустить качественные и полноценные приложения для iPad и Mac.

Например, это получилось у команды Jira. Их приложение для iPad удобнее и быстрее веб-версии сервиса. Зачастую я предпочитаю создать задачу на планшете, чем открывать медленную веб-версию сервиса на компьютере. Поэтому перенос такого приложения на Mac положительно скажется на моих сценариях работы.

Чем больше подобных приложений будет, тем быстрее мы почувствуем изменения. Браузер уйдёт на второй план, работа на компьютере превратится в постоянное переключение между приложениями, а iPad сможет решать все повседневные задачи, из-за которых раньше приходилось использовать компьютер.

#macos #mac #ipados #ipad #колонка