В жизни каждого фронтендера наступает момент, когда приходится перейти от родного привычного десктопа на разработку мобильной версии веб-приложения или даже начать работать над mobile-first решением, или еще страшнее — PWA-приложением.

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

Привет! На связи Полина, фронтенд-разработчик в Selectel. Раньше я тоже думала, что адаптив в десктопном браузере абсолютно такой же, как на телефонах. Да и вообще мобильный браузер — это просто браузер поменьше (спойлер — нет). В этой статье я расскажу об их различиях, что с этим делать, как прокинуть localhost на реальный телефон и получить DevTools от браузера в смартфоне, чтобы ловить поменьше багов на проде.

Используйте навигацию, если не хотите читать статью полностью:

• DevTools — это ловушка

• Cначала была Nokia 7110

• Эмулятор, симулятор и PWA

• Проблемы эмуляции, симуляции, DevTools и реальных устройств

• То, что вы не найдете в DevTools

• Что делать

• Заключение

DevTools — это ловушка

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

На одном проекте я делала веб-приложение для криптокошелька. В DevTools эмулировала iPhone и все выглядело отлично! Но когда мы выкатили все на прод, продакт открыл сайт на айфоне, и главная кнопка — «Дать продакту денег» — просто уехала вниз и спряталась под навигационной панелью Safari. Сайт сломался, продакт плакал, а я винила iOS во всех бедах…

Что такое DevTools и симуляция устройств в DevTools

DevTools — это встроенный в браузер инструмент для анализа, отладки и тестирования веб-сайтов. Он позволяет разработчику в реальном времени просматривать и редактировать HTML, CSS и JavaScript, отслеживать загрузку ресурсов и производительность.

Эмуляция устройств в DevTools — это инструмент для адаптивного тестирования. 

Симуляция устройства в DevTools позволяет задать различные варианты viewport, проверить адаптивность на различных размерах экранов, симулировать touch-события вместо кликов.

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

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

Cначала была Nokia 7110

Это был первый телефон с невероятно огромным по меркам 1999 года дисплеем на целых шесть строчек текста. И главное — доступом в интернет со скоростью 10 Кб/с. Сегодня с такой скоростью вы бы загружали 15-секундное видео в низком качестве 13 минут, но тогда это вызывало не «да блин, ничего не грузится», а «вау, интернет в телефоне!». А в этом обзоре можно погрузиться в ностальгию и почитать о Nokia 7110 подробнее.

Начало мобильных браузеров: WAP + WML

Конечно, просто открыть десктоп-сайт на телефоне было невозможно. Помните ограничение в шесть строчек текста на экране? Вот и люди, чей год рождения начинается с «19..», припоминают времена, когда трава была зеленее, а веб на телефонах — без картинок и стилей. Не знаю насчет травы, но с сайтами так и было. Ведь верстали их не с помощью привычного HTML, а на WML — специальном языке разметки для монохромных экранов с низким разрешением.

Чтобы открыть такой сайт с телефона, нужно было явно указать в URL, что нам нужна именно его мобильная версия. Допустим, мы хотели бы зайти на сайт Selectel (если бы он существовал в те времена). Для десктопа писали бы www.selectel.ru, а для мобилки — wap.selectel.ru. Эта приписка wap направляла клиента не на стандартную десктоп-версию, а на отдельную — мобильную, как раз-таки сверстанную на WML. А если у вас есть динозавр, поддерживающий WAP, вы можете попробовать открыть такие сайты сами — список можно найти, например, в тематических сообществах. 

Но нельзя было просто взять и открыть WML-сайт. Железо в телефонах не тянуло IP-адресацию и стандартные протоколы. Поэтому телефону приходилось «звонить» специальному серверу мобильного оператора или WAP-шлюзу, который сам выходил в интернет и передавал телефону мобильную версию сайта — оригинальную или даже самостоятельно адаптированную. 

Я не буду углубляться в сетевой стек, скажу только, что в те времена почти на каждом уровне передачи информации до телефона использовался не обычный десктопный протокол, а его упрощенный мобильный аналог. Для WAP-сайтов тоже существовали свои IDE и DevTools-симуляторы, подробнее можно прочитать в этой статье.

Транскодеры и первые HTML-браузеры

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

Возникла дилемма: заставлять всех делать двойную работу отдельные мобильные версии или создать технологию, которая будет «на лету» адаптировать любой сайт под телефон? Так и появилась Opera Mini. И это была революция — первый мобильный браузер с доступом в «большой» интернет. 

Появление Opera Mini расширило список доступных сайтов, а сам браузер использовал революционную для того времени технологию: все запросы проходили через сервер компании Opera, где полноценные HTML-сайты упрощались и преобразовывались в двоичный формат OBML (Opera Binary Markup Language), а изображения масштабировались.

Браузер клиента получал OBML, после чего мог отрисовать нужный сайт. Да, с точки зрения сети Opera Mini все еще использовала WAP для передачи данных. Но при этом бразуер позволял открывать даже сложные сайты благодаря логике сервера.

Революция смартфонов

В 2007 Apple показала миру первый iPhone, а вместе с ним — полноценный мобильный браузер Safari, поддерживающий HTML и JavaScript на уровне десктопов того времени. Да, на айфоне можно было открыть настоящий сайт с картинками. А все благодаря движку рендеринга под названием Webkit.

Фанфакт: Apple первыми придумали и запатентовали конкретную реализацию pinch-to-zoom, swipe to navigate жесты, а также алгоритм обработки жестов, и интегрировали все это в свой мобильный браузер. После того как Google добавил поддержку этих жестов в свои браузеры, Apple подала в суд на компании, использующие Android. Суд удовлетворил иск Apple к Samsung на более чем 1 млрд долларов за использование «внешнего вида и ощущений» iPhone.

Google при этом приходилось искать обходные пути — использовать для масштабирования кнопки «+» и «-» или двойное нажатие.

Развитие современных движков рендеринга

Google тоже начал использовать Webkit, но через 5 лет выкатил его форк под названием Blink и успешно использует его по сей день. Вы, скорее всего, слышали о нем как о движке Chromium. А вот в Mozilla написали свой движок для рендеринга Gecko. Об этом я узнала случайно — из-за бага, который воспроизводился только в Firefox. Оказалось, Mozilla не только участвует в разработке веб-стандартов, но и активно реализует их в своем движке, выпиливая устаревшие фичи раньше всех.

Несмотря на всю эту инновационность, Mozilla вынуждена использовать на айфонах не свой супер-актуальный по всем веб-стандартам движок Gecko, а яблочный WebKit из-за ограничений платформы. И вообще любые браузеры на айфоне на самом деле — рескин Safari. Apple не разрешает сторонним браузерам использовать для рендера сайтов собственные механизмы.

Появление смартфонов заставило весь мир переосмыслить подход к созданию веб-приложений. Из-за Apple умер Flash ? — он не работал на iPhone. Конечно, не только из-за Apple: технология была закрытой, небезопасной и очень прожорливой. Но принципиальный отказ Apple, задавший тренд, стал для Flash мощным ударом, с которого начался его закат. Решением Apple стала поддержка современных веб-стандартов: HTML5, CSS3, JavaScript.

В 2015 Google объявил мобильную адаптивность фактором ранжирования в поиске. Именно тогда мобильные браузеры полностью догнали десктопные: начали поддерживать современные стандарты HTML5, CSS3, ES6 JS, улучшили производительность и начали на полную использовать уникальные для мобильных устройств API — например, датчики движения и освещения, акселерометр и гироскоп.

Приведу пример. Раньше в поиске Google на телефоне можно было найти карточку какого-нибудь животного, и нажать «View in 3D»  — чем-то это напоминает жутковатый рассказ «Вельд» Рэя Брэдбери, где детская комната силой воображения материализовывала любые пейзажи.

При просмотре AR-сцены браузер задействовал сразу несколько уникальных мобильных API:

• камера — чтобы получить видео и наложить 3D модель на изображение,

• акселерометр и гироскоп — эти датчики помогали браузеру отслеживать положение и угол наклона телефона, чтобы виртуальный лев устойчиво «стоял» на вашем полу и поворачивался, когда вы двигаетесь вокруг него,

• ARCore (Android) / ARKit (iOS) — платформы, доступные именно в мобильных ОС, через браузер анализировали картинку с камеры, чтобы понять геометрию пространства: где пол, стены, поверхности. Это позволяло льву реалистично прятаться за вашим диваном.

А начиная с 2016 года мобильные браузеры начали не просто поддерживать стандарты старших десктоп-братьев, а создавать свои собственные, уникальные или нативные фичи. Браузеры научились работать в фоне с помощью Service Workers, что позволило сайтам работать как приложениям — с синхронизацией в фоне, кэшем и пушами. Да еще и иконку сайта стало возможно установить на главный экран — привет PWA!

Все это звучит очень здорово, но на реальных устройствах создает реальные проблемы. Давайте посмотрим, с чем вы столкнетесь в разработке при использовании одних только DevTools или эмуляторов, и какие специфичные для платформ проблемы возникают при разработке PWA-приложений. Будем рассматривать два самых используемых движка от Google и Apple (по статистике 91% мобильного трафика приходится на Chrome и Safari), сравнивая подход систем Android и iOS в работе с мобильным вебом и PWA.

Эмулятор, симулятор и PWA

Эмулятор — полноценная виртуальная машина с ОС Android, которая имитирует устройство. Например, Android Emulator.

Симулятор — просто программа-имитация реальной ОС. Например, iOS Simulator.

PWA (Progressive Web App) — это веб-приложение, которое поддерживает ряд фичей нативных приложений. Оно может:

• быть установленным на домашний экран и работать в своем инстансе браузера без адресной строки и других вкладок,

• работать оффлайн за счет Service Worker и не крашить свой UI,

• отправлять push-уведомления.

PWA приближает веб-приложения к нативным, но все еще остается вебом.

Полный функционал PWA можно посмотреть и протестировать на вашем устройстве с помощью whatpwacando.today.

Проблемы эмуляции, симуляции, DevTools и реальных устройств

Диапазон устройств

В эпоху ранних Android-смартфонов слабое железо было главным ограничением. Эта проблема никуда не делась, а просто переместилась в бюджетный сегмент.

Вы пишете промо-сайт с яркими анимациями, интерактивным колесом розыгрыша и всплывающим попапом? Поздравляю, он затормозит и умрет на бюджетном TECNO, а вы это даже не заметите! При этом при просмотре с вашего нового iPhone все будет замечательно работать.

А почему для работы сайта нужно мощное железо? Это же все в «крутится в интернетах»

Браузер на телефоне — это не просто «программа для просмотра картинок». Когда вы заходите на сайт, он получает с сервера код, который ему нужно самому превратить в картинку на экране. Этот процесс называется рендерингом. Сайт с анимациями — это не статичная картинка, а целый мультфильм, который браузер должен рассчитать и нарисовать заново 60 раз в секунду.

Процессор отвечает за выполнение кода анимаций, логику интерактивных элементов и расчет изменений на странице. Если он слабый, он просто не успевает все это посчитать, и анимации начинают дергаться.

Видеопроцессор берет готовые расчеты от CPU и превращает их в пиксели на экране. Сложные эффекты, прозрачности и плавные переходы — это его работа. На слабом GPU этот процесс идет медленнее.

Браузер бюджетного Android получает тот же самый тяжелый код, что и браузер iPhone. Но его процессор и видеоядро в несколько раз слабее. Они не справляются с нагрузкой, пытаются все рассчитать, и в итоге страница «тормозит», потому что железо физически не успевает отрисовывать кадры с нужной скоростью.

Так что да, сайт «крутится в интернетах», но вся тяжелая работа по его оживлению ложится на железо вашего телефона.

А если не верите в значительную разницу между производительностью устройств, посмотрите видео:

Казалось бы, Android можно тестировать  в эмуляторе, выставляя для него параметры слабых/бюджетных устройств, но нет. Для сборки системы в эмуляторе используется открытый исходный код из Android Open Source Project. При этом все производители Android-устройств активно игнорируют «чистый» Android и создают свои кастомные надстройки над устройствами.

А в доступном только для владельцев macOS эмуляторе iOS с новыми обновлениями удаляются старые версии iOS, вернуть которые в Xcode можно только через боль, поиск и самостоятельную установку нужных версий.

Производительность

И эмуляторы, и симуляторы, и тем более DevTools будут работать на мощности вашего железа, на котором вы разрабатываете (или уже тестируете) свое веб-приложение. Они не смогут воспроизвести особенности работы телефона.

Возьмем, например, троттлинг процессора. На старом или перегретом устройстве процессор снижает частоту. Ваша плавная 60 FPS анимация в эмуляторе будет дергаться и залипать на реальном телефоне.

Еще бывает нехватка оперативной памяти. Эмулятор щедро использует RAM вашего MacBook. Реальное устройство может в любой момент выгрузить вашу PWA из памяти или убить фоновый процесс Service Worker, чтобы освободить ресурсы для другого приложения. Вы уверены, что ваше приложение корректно восстановится после этого?

Даже если в инструментах эмуляции задавать ограничение ОЗУ, эмуляция будет приблизительной, поскольку реальное управление памятью на Android/iOS сложнее и зависит от многих факторов, включая фоновые процессы системы и алгоритмы оптимизации памяти.

А что насчет различий в GPU? Рендеринг сложного CSS или WebGL может кардинально отличаться по скорости и качеству на разных видеоядрах. Тяжелая анимация, бесконечный цикл или большой JS-бандл быстро превращаются во «фризы» на реальных устройствах.

Эмулятор покажет, что ваш код выполняется, а реальное устройство для тестов — как он выполняется на конкретном железе вашего пользователя.

Ограничения системы / мобильных платформ

Железо стало мощнее, но проблемы остались. Умножим это на современное разнообразие китайских телефонов с уникальными оболочками и модифицированными под них браузерами и получим бесконечное множество проблем.

У Android существует такая штука, как режим Doze — функция Android, которая экономит заряд аккумулятора, когда устройство не используется, находится в неподвижном состоянии и не подключено к зарядке. Система ограничивает доступ приложений к сети и ресурсоемким службам, временно приостанавливает фоновые задачи. Периодически система выходит из режима на короткое время («окна обслуживания»), чтобы позволить приложениям выполнить отложенные действия.

Что это значит для разработчика? Если ваше веб-приложение или PWA кушают много памяти или выполняют фоновые обновления (в случае с PWA), их работа будет ограничена системой.

Еще пример. Есть такое понятие, как выгрузка приложений. Это когда ОС «выбрасывает» из памяти приложение или PWA, если не хватает ресурсов. Safari выгружает вкладки, которые висят в фоне, чтобы освободить RAM. Chrome может выгрузить PWA, если памяти мало или если система считает вкладку неактивной. Мой уже достаточно уставший телефон может перезагружать вкладку каждый раз, когда я из окна браузера переключаюсь в другое приложение и обратно.

Мобильные браузеры агрессивно экономят заряд. Safari и Chrome на Android снижают частоту обновления экрана, замораживают таймеры, ограничивают работу сервис-воркеров в фоне. На ноутбуке в DevTools код работает постоянно, а на телефоне те же задачи могут быть остановлены через 30 секунд, если система решит, что они «слишком дорогие».

И наконец, системные ограничения ОС. На iOS долгое время отсутствовали пуш-уведомления в вебе, а IndexedDB могла очищаться системой без предупреждения. Android позволяет больше, но тоже режет фоновые процессы при низком заряде или переходе в режим энергосбережения. Плюс жесткие правила Apple: все браузеры на iOS обязаны работать на WebKit, что ограничивает поддержку API.

Жесты и системные действия

Эмуляция не воспроизводит сенсорные события. Реальный пользователь может делать pinch-to-zoom, свайп двумя пальцами, поворот устройства. Ваш UI может ломаться при multi-touch, pull-to-refresh, swipe back, pinch-to-zoom, повороте экрана, double touch. Вот парочка реальных issues с GitHub: мерцание  страницы при свайпе и неработающий свайп в Safari.

В эмуляции вы кликаете мышкой — это не воспроизводит весь набор сенсорных сценариев. Может ломаться поведение приложения — слайдеры, случайные сбросы PWA, поломанный интерфейс.

Ограничения Android и iOS

При разработке PWA на Android и iOS надо учитывать также ограничения и отличия работы систем. Для установки PWA на Android есть поддержка нативных баннеров установки. При этом приложение можно распространять через Google Play Store.

У iOS нет нативной поддержки, поэтому пользователю требуется открыть нужный PWA в Safari, самому найти кнопку установки в меню Поделиться.

Push-уведомления полностью поддерживаются в Android, в iOS поддержка появилась только с iOS 16.4 и требует ручной установки PWA на главный экран. При этом даже при выполнении этих условий реализация может сбоить.

Для фоновой синхронизации в Android используют Background Sync API (для отложенных действий при появлении соединения). В iOS такое не поддерживается, поскольку Service Worker убивается при закрытии PWA, делая фоновые задачи невозможными.

Для долговременного хранения данных на Android используется Storage API. Лимиты достаточно большие — около 20–50% от свободного места на устройстве. В iOS такого API нет: система может удалить данные приложения примерно через две недели бездействия, чтобы освободить место.

С использованием системных API тоже есть проблемы — iOS блокирует доступ к низкоуровневым аппаратным API из соображений безопасности и монетизации. Подробный разбор преодоления ограничений Safari для PWA можно найти в этой статье.

То, что вы не найдете в DevTools

Давайте посмотрим на самые распространенные проблемы, которые точно нельзя проверить, уменьшив окно просмотра в браузере или используя симуляцию мобильного устройства в DevTools. 

100vh

На iPhone 100vh включает нижнюю панель браузера. Элементы сайта или приложения, расположенные снизу, могут оказаться скрытыми за панелью и недоступными для пользователя. При этом в DevTools viewport будет отображаться без учета панелей браузера, так как DevTools осуществляет только подмену размеров экрана и User-Agent.

На некоторых устройствах viewport сжимается, а на некоторых фиксированные элементы, например, попапы, шапки и подвалы, сдвигаются. В результате приложением становится невозможно пользоваться. Это известная проблема. Для сравнения поведения мобильных браузеров на разных устройствах есть демо, которое показывает поведение различных единиц измерения высоты окна при изменении viewport.

Использование клавиатуры тоже создает проблемы — viewport сжимается почти в два раза, вместе с ним уезжает и UI веб-приложения. 

Safe area

С появлением iPhone X появилось такое понятие как safe area — безопасная зона экрана, в которую не должны попадать элементы интерфейса, чтобы не перекрывать вырезы, панель с жестами, или закругленные углы. Использование safe area гарантирует, что интерфейс будет корректно отображаться на устройствах с различными вырезами и панелями.

Офлайн и фоновая синхронизация

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

В DevTools можно поставить галочку Offline. Но в реальной жизни связь нестабильна: пакеты теряются, соединение рвется, страницы открываются наполовину. Сервис-воркер может кешировать не все запросы и выдавать пустую страницу. В эмуляторе Android можно подстроить сеть, но настоящие «плавающие условия» будут только на реальном устройстве.

Background Sync позволяет отправлять данные, когда сеть восстановилась. В DevTools вы можете вручную триггернуть sync-событие, но это не эмулирует реальное энергосбережение и ограничения ОС. Как мы помним, на iOS Service Worker в фоне могут быть убиты уже через 30 секунд. На Android работа зависит от режима энергосбережения и уровня батареи. В эмуляторе эти процессы не всегда воспроизводимы — только реальное устройство даст правду.

Push-уведомления

Пуш-уведомления — критичный сценарий PWA. В DevTools пуши эмулировать нельзя. А реальное поведение может создавать проблемы:

• веб-приложение может не инициировать запрос на разрешение на отправку уведомлений, 

• пуши могут не прилетать при заблокированном экране,

• action-кнопки могут вести себя неправильно или отправлять не на целевую страницу веб-приложения,

• на Android пуши работают, но фоновые сервисы могут быть убиты системой,

• на iOS пуши появились только с iOS 16.4 и только если PWA установлена на домашний экран.

Системные API 

iOS ограничивает PWA в API: отсутствуют Web Bluetooth, Web NFC, каналы доступа к датчикам и фоновым задачам. Android/Chrome поддерживает большинство современных Web-API (Bluetooth, NFC, полный доступ к камере, Filesystem API и т.  д.). Также на iOS нет полноценной фоновой синхронизации (Background Sync API) или фоновых задач — все это на Android работает.

Эмуляторы почти всегда возвращают «заглушку» (success без данных или NotSupportedError). В эмуляторе тест пройдет, а на реальном устройстве функция будет недоступна.

Что делать

Правильное решение — взять побольше разных смартфонов и тестировать все на реальном железе. Это позволит также не заливать каждое изменение в дев отдельно. Да и вообще — хочется же видеть все локальные изменения в коде сразу и на телефоне.

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

Чтобы ей воспользоваться:

1. Перейдите в панель управления → Мобильная ферма.

2. Нажмите Создать ферму.

3. Выберите необходимые смартфоны и их количество, а также тип тарификации: поминутную или почасовую. Затем еще раз нажмите Создать ферму.

4. Выбранные смартфоны появятся в списке доступных устройств и будут доступны для работы с ними.

5. Кликните по нужному смартфону. Его экран будет транслироваться в браузер, а вы сможете приступить к тестированию.

Android

Получаем доступ в DevTools Chrome для Android-устройств

Сначала нужно подключиться к телефону по ADB. Подробная инструкция для этого доступна в документации. Но если коротко, то процесс выглядит так: 

1) Через терминал подключитесь к устройству с помощью adb.

2) Перейдите на страницу устройства → нажмите Начать использование (важный шаг, без этого устройство будет висеть, как unauthorized).

3) На своем ПК откройте chrome://inspect/#devices , устройство появляется в списке Remote Target.

4) На устройстве откройте нужный URL в Chrome, URL активной вкладки обновится и на ПК.

5) Нажмите inspect или inspect fallback: на ПК открывается окно, дублирующее экран устройства и Chrome DevTools от браузера телефона.

6) Все вкладки Chrome DevTools работают так же, как для обычного браузера Chrome на десктопе. Стрим в окне Chrome DevTools может не обновляться, смотреть можно на трансляцию в панели управления.

Пробрасываем порт для просмотра localhost

Не хочется ждать, пока пройдет деплой? Можно открыть фронтенд, развернутый локально прямо на устройстве.

1. На локальном ПК разверните ваш фронтенд.

2. На странице chrome://inspect/#devicesвыберите Port forwarding….
   

   

3. В открывшемся окне в первой ячейке введите нужный порт, во второй — IP-адрес и порт. Поставьте галочку Enable port forwarding, нажмите Done.
   

   

4. На странице chrome://inspect/#devices отобразятся проброшенные порты.
   

   

5. На телефоне теперь можно открыть фронтенд, развернутый локально на вашем компьютере.
   
   

   

iOS

Получаем доступ в Safari DevTools для iOS-устройств

Если у вас нет macOS, но есть iPhone и очень хочется протестировать ваше веб-приложение именно на iOS, то этот способ для вас.

Для этого нам понадобится Chii — инструмент удаленной отладки веба на любых устройствах.  Он подойдет даже для Smart TV и Android Auto, так как там тоже есть браузер.

Настройка сервера и окружения

Прежде всего, нужно развернуть сервер в облаке. Пошаговую инструкцию можно найти в документации. В данном случае хватит минимальных ресурсов: фиксированная Shared-конфигурация, 10% vCPU, 512 МБ RAM и 5 ГБ SSD.

Устанавливаем Chii по инструкции из репозитория.

1. Скачаем и установим Node.js:

cd ~
curl -O https://nodejs.org/dist/v16.20.2/node-v16.20.2-linux-x64.tar.xz
tar -xf node-v16.20.2-linux-x64.tar.xz
 
echo 'export PATH=$HOME/node-v16.20.2-linux-x64/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

2. Установим Chii  глобально:

npm install -g chii

3. Установим и используем ufw:

sudo apt update
sudo apt install ufw -y
sudo ufw allow 8080
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status

4. Запустим Chii в фоне, в <server-ip> подставляем публичный адрес сервера:

nohup npx chii start -p 8080 --host 0.0.0.0 -d <server-ip>:8080 > chii.log 2>&1 &

На http://<server-ip>:8080 появится панель Chii.

Работа с устройством

1. На iOS-устройстве зайдите в Настройки → Safari → Дополнения, включите  Веб-инспектор.
   

   

2. В результате имеем iOS с Safari, в котором включен веб-инспектор, и развернутую панель Chii на сервере http://<server-ip>:8080. Если в Safari открыть http://<server-ip>:8080/test/demo.html, то вкладка появится в панели Chii.
   

   

3. Нажимаем inspect для открытой вкладки и получаем почти полноценные DevTools для выбранной вкладки: Elements, Console, Network, Application. При перегрузке вкладки соединение с DevTools может оборваться из-за обрыва ws-соединения DevTools.
   

   

Чтобы Chii мог получить доступ к DevTools той вкладки, которая открыта в Safari, нужно чтобы в HTML-код сайта был вставлен скрипт:

<script src="//<server-ip>:8080/target.js"></script>

Заключение

Если вы пишете веб-приложения под мобилки — расскажите, как вы с этим живете. Делаете ли вы все через реальные устройства? Или до сих пор верите в адаптив в десктопных DevTools и как-то умудряетесь не ловить неожиданные баги?

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

А если у вас все идет гладко — как вы это делаете? Делитесь своими секретами в комментариях.