Создать браузер для ios
Работающий стартап, это тот, который построенный на принципах стратегии MVP (Minimum Viable Product). Такой подход позволяет вам проверить ваш продукт перед запуском его в широкие массы.
После запуска MVP изучаете реакцию вашей аудитории и рынка на него, меряете покупательских спрос. Как результат, вы получаете первые плоды от продаж, первый пользовательский опыт, первый отзыв о продукте / сервисе. У вас вырисовывается полное представление о проекте, и о том, что с ним дальше делать: в каком направлении развиваться и развиваться ли вообще.
Ниже мы детально рассмотрим как механизм MVP может помочь в сборе информации и превращении ее в ценностное предложение. И помните, что как стратегический предприниматель, лучше выбирать такой способ разработки продукта, который покажет результаты в первые дни работы. Пссс… правильный ответ — веб-приложение;)
Запуская технический продукт, который не имеет никакой взаимосвязи с камерой или микрофоном смартфона, подумайте о том, чтобы начать все-таки с веб-приложения. Функционально браузеры быстрее развиваются чем мобильные приложения, и соответственно количество пользователей у них больше. При создании приложения лучше задействовать принципы MVP. Также не забывайте, что оно должно запускаться в Chrome или Safari.
Приложения подобные Uber или Instagram напрямую зависят от функциональности девайса (геолокация), но есть много других продуктов, которые не нуждаются в взаимодействии с API устройства. А благодаря адаптивному веб-дизайну такие приложения получают межплатформенную доступность и корректно отображаются на экранах разного разрешения.
Существует десятки технических методов разработки мобильных приложений. Различия между ними сводятся к скорости написания приложения, стоимости, и к качеству конечного продукта. Понимание различий между ними, пожалуй, сложная задача.
Итак, давайте рассмотрим четыре популярные технологии создания мобильных приложений, а также их основные различия. Это поможет определить практичный способ верификации бизнес-идеи и облегчит конструирование будущего продукта. Возможно, веб-приложение (а не нативное мобильное приложение) поможет сократить расстояние между MVP и запуском полноценного проекта.
Эта относительно новая технология, разработанная Google. Она позволяет мобильным устройствам добавлять веб-сайт или веб-приложение на домашний экран смартфона и дальше использовать его в оффлайн-режиме.
Для превращения веб-приложения в прогрессивное веб-приложение, вам нужно добавить в него значок для главного экрана, манифест веб-приложения и рабочие службы — все это позволит сайту загружаться быстрее, работать в оффлайн-режиме и отправлять push-уведомления. Обратите внимание, что при загрузке прогрессивного веб-приложения в браузере телефона устройству предлагается добавить сайт на главный экран.Прогрессивные веб-приложения не полностью поддерживаются на устройствах iOS, но, надеюсь, это изменится в ближайшем будущем.
- Позволяет получать push-уведомления;
- Приложения могут работать в оффлайн-режиме;
- Базовые сайты получают лучшее ранжирование в поисковых системах.
- Эта технология — это просто оболочка браузера, а не полнофункциональное приложение, поэтому технически это все еще веб-сайт;
- Пользователи не получат опыт работы с нативным приложением (анимация, производительность), поскольку пользовательский интерфейс — это просто полноэкранное окно браузера без строки URL, которая может работать в автономном режиме;
- Плохая совместимость (по-прежнему недоступна на iPhone и iPad).
Washington Post одна из первых медиакомпаний, использующих прогрессивное веб-приложение для увеличения охвата веб-сайта.
Прогрессивные веб-приложения — отличный способ дополнить веб-сайт или веб-приложение, расширяя его охват. Они могут улучшить глобальный пользовательский опыт с устройствами, которые их поддерживают; однако, поскольку эта технология не распространена, ее следует рассматривать как дополнительное средство увеличение охвата веб-сайта, а не как способ трансформации веб-сайта в мобильное приложение.
Apache Cordova — это платформа для создания мобильных приложений с использованием HTML, CSS и Javascript.
Приложения, созданные с использованием Apache Cordova, работают во встроенной среде браузера (WebView) на мобильных платформах Android, iOS и загружаются из App Store или Google Play Store. Приложение запускается с помощью ярлыка, который расположен на главном экране, и взаимодействует с API-интерфейсами смартфонов, функциями девайса (геолокация, камера и т. д.).
Пользовательский интерфейс приложения, созданного с помощью этой инфраструктуры, не будет таким гладким, как в родном (native) приложении. Внешний вид интерфейса аналогичен интерфейсу веб-сайта (задержка нажатия на 300 мс, фантомные клики при прокрутке и так далее). Конечно, есть модули и фреймворки, которые предлагают компоненты пользовательского интерфейса. Модули разработанные так, чтобы быть похожими на собственные приложения, но они все еще не дотягивают до опыта взаимодействия с родным приложением.
Помимо Cordova, есть и другие популярные платформы — Ionic и PhoneGap. Для примера того, как такое приложение выглядит и работает, можно скачать приложение для Национального музея афроамериканской истории и культуры.
Это приложение было создано с использованием Ionic framework и предлагает следующие возможности:
- Поиск / исследование конкретных объектов в музее;
- Видео дополненной реальности;
- Обмен через социальные сети;
Недавним примером гибридного приложения, которое мы создали в Ezetech для Tickfinity — TicketNetwork POS для мобильных устройств (видео).
- Высокая скорость разработки;
- Написаны с помощью HTML, CSS, Javascript, что обеспечивают кросс-совместимое iOS, Android и веб-программное обеспечение (требуется только один веб-разработчик);
- Доступны фреймворки, которые эмулируют пользовательские элементы UI (например, кнопки, меню и так далее);
- UX близок к нативному опыту с использованием элементов UI, которые имитируют поведение обычного приложения;
- Доступ к API-интерфейсу смартфона ( камера, push-уведомления, геолокация и другие).
- UX не так хорош, как в родных приложениях (задержки на клики 300 мс, фантомные клики при прокрутке);
- Чем сложнее приложение, тем медленнее оно работает из-за использования различных оболочек и библиотек;
- Не работает в офлайн режиме;
- Анимации трудно реализовать в UI.
Этот вариант подходит для MVP простых веб или мобильных приложений. Если у вас уже есть веб-приложение, построенное с помощью Javascript, вы можете использовать существующий код. Проще говоря Apache Cordova хорош для быстрого создания недорогих мобильных приложений со стандартными функциями.
React — отличный выбор, если ваше веб-приложение построено с помощью React.js. Это относительно новая технология в мире гибридных приложений, и миграция из существующего веб-приложения в мобильное может пройти довольно быстро. В результате вы получаете мобильное приложение, которое использует собственные компоненты ОС вашего смартфона (кнопки, входы и другие функции устройства). Производительность хорошая, потому что исходный код конвертируется в собственное мобильное приложение, а не работает во встроенном окне браузера.
Некоторые примеры приложений, использующих React Native:
- Высокая скорость разработки для веб-приложений на основе React;
- Веб-приложение, созданное с помощью React.js, может быть легко преобразовано в мобильное приложение React Native, а некоторые исходные коды можно повторно использовать;
- Собственный пользовательский опыт;
- Приложение выглядит и воспринимается как родное мобильное приложение для конкретной платформы;
- Низкие затраты на разработку;
- Эксперты в React Native обычно могут создавать приложения для Android и iOS.
- Относительно новая технология (ограниченные решения с открытым исходным кодом);
- Ограничено в отношении визуального дизайна;
- Не подходит для сложных проектов, таких как мобильные игры или приложения, требующие высокой нагрузки (значительные вычисления).
React Native — самая популярная технология для разработки гибридных мобильных приложений. Она используется крупнейшими цифровыми корпорациями и имеет много преимуществ. Это хороший вариант, если вашему приложению не требуется поддерживать несколько соединений с сервером в реальном времени или выполнять сложные вычисления. Технология по прежнему новая, и не так много библиотек и модулей с открытым исходным кодом, как для собственных технологий разработки мобильных приложений, но она быстро развивается.
Создание родных (native) приложений для каждой платформы — лучший выбор с точки зрения производительности и качества продукции, но это также и самый дорогой подход. Если у вас уже есть веб-приложение, вам нужно будет только создать мобильные клиенты для мобильного приложения Android и iOS, которые будут подключены к тому же бэкенду, что и ваш веб-клиент. Незначительные изменения могут быть все еще необходимы на бэкенде, но это не займет много времени.
Обычно вам нужно как минимум 2 разработчика — разработчик iOS, который работает над iPhone-приложением с использованием Objective-C или Swift, и разработчика Android, который будет использовать Java или Kotlin. Поэтому стоимость разработки будет выше, чем в любом из вышеперечисленных подходов.
В то же время гибкость такого подхода заключается в том, что вы сначала можете разработать начальную версию только для одной платформы, и позже добавить другую. Первую платформу, можно определить исследуя целевую аудиторию с помощью Mapbox.
Несколько примеров нативных мобильных приложений:
Coinbase: одно из самых популярных приложений для торговли криптовалютами.
Uber: самое популярное приложение для транспортировки.
- Многие модули и библиотеки доступны для решения общих задач разработки;
- Хорошая производительность и отличный пользовательский интерфейс на всех мобильных платформах;
- Позволяет приложению получать доступ ко всем устройствам разрешенным производителем;
- Может работать в офлайн режиме и хранить данные на устройстве.
- Более высокие затраты по сравнению с разработкой гибридных приложений;
- Различные стеки технологий для разных платформ (требуется больше разработчиков).
- Обратите внимание, что лучше всего создавать нативное приложение c нуля, только если у вас есть на это ресурсы. Технологии для создания таких приложений уже давно существуют, что дает множество модульных решений, а также сообществ с открытым исходным кодом, доступных разработчикам для эффективного решения проблем.
Есть два основных варианта, которые хорошо подойдут для перехода из веб-приложения в мобильное — разработка гибридного приложения и запуск с нуля (разработка нативного приложения).Если функциональность вашего продукта не слишком сложна, и вы просто хотите предложить мобильным пользователям лучший опыт, вы должны использовать React Native (если сайт на реакте) или Apache Cordova для разработки вашего гибридного приложения. Это оптимальный вариант, если у вас ограничен бюджет и вам нужна поддержка на Android и iOS.
Для сложных приложений, которые должны выполнять сложные вычисления, поддерживать соединение в реальном времени с сервером и предлагать пользователям уникальные функции, которые требуют постоянного взаимодействия с другими приложениями, лучше использовать нативную разработку. В этом случае вы сможете создать приложение с наиболее важным функционалом и улучшать его по мере роста вашего бизнеса.
Что касается разработки прогрессивного веб-приложения, то это достаточно новая технологическая парадигма. Такое приложение хорошо подойдет для расширения охвата вашего ресурса, но до полноценного мобильного приложения ему еще далеко.
App Store – не в пример более богатый магазин приложений, чем Google Play, во всех смыслах. Он не только приносит больше доходов, чем его конкурент, но и содержит больше эксклюзивных приложений. Просто исторически так сложилось, что разработчикам было банально выгоднее размещаться в App Store, где аудитория более платёжеспособна, чем в Google Play. Но, несмотря на это, многие веб-сервисы не спешат создавать приложения для iOS в силу тех или иных причин. Поэтому я предлагаю сделать всю работу за них, тем более что это не так уж и сложно.
Превратить веб-сайт в приложение со специфическим интерфейсом, по щелчку пальцев само собой, нельзя. Для этого нужно привлекать UX- и UI-дизайнеров, которые будут работать над созданием оформления приложения. Однако сделать из обычного сайта прогрессивное веб-приложение без адресной строки и лишних элементов, характерных только для сайтов, вполне можно. Рассказываю, как именно.
Как сделать PWA на iOS
Для этого нам потребуется приложение «Быстрые команды», которое доступно в App Store , и собственно команда с незамысловатым названием Make app from URL, которую можно скачать по этой ссылке . Завершив предварительную подготовку, переходите к следующему этапу:
- Скопируйте адрес сайта, который хотите превратить в PWA;
- Откройте «Быстрые команды» и запустите Make app from URL;
- Назовите будущее приложение, вставьте URL и добавьте картинку (её можно скачать либо с сайта, либо из Google);
- Затем скачайте профиль (без него ничего не получится) и установите его;
- Вернитесь на рабочий стол, найдите приложение и запустите его.
Если вы не понимаете, что такое прогрессивные веб-приложения , или PWA, у нас был на эту тему очень подробный пост, который можно почитать вот здесь . Не пренебрегайте им, обязательно ознакомьтесь – некоторые моменты, которые там описаны, вас наверняка удивят.
Обратите внимание, что прогрессивное веб-приложение, которое получилось благодаря быстрой команде, лишено адресной строки и других лишних элементов, которые отвлекают от чтения и сбивают с толку. Несмотря на это, вы можете авторизоваться со своей учётной записью, открыть и прочитать любую статью, познакомиться с авторами и вообще делать всё, что могут делать посетители классического сайта.
Как удалить профиль на iOS
Если и когда приложение вам надоест, вы наверняка захотите удалить не только его, но и профиль, который обеспечивает его работу. Это сделать очень просто:
- Перейдите в «Настройки» и откройте «Основные»;
- Пролистайте вниз и откройте раздел «Профили»;
- Отыщите в списке нужный профиль и откройте его;
- Нажмите «Удалить» и подтвердите удаление.
Сам профиль абсолютно безобидный и бояться его не нужно. Он нужен для того, чтобы сайт превратился в PWA и начал работать, собственно, как PWA. Если при первоначальной настройке отказаться от него, то ничего не выйдет. Приложение просто не установится и не появится на рабочем столе. Это никакой не джейлбрейк и вообще не вредоносный компонент. Поэтому можете смело его ставить. Тем более что удалить его можно в любой момент.
Меня зовут Евгений, я Full Stack JS разработчик, текущий стек Node.js + React + React Native. В разработке я более 10 лет. В мобильной разработке пробовал разные инструменты от Cordova до React Native. Получив опыт работы с Cardova, я понял, что мне хотелось бы создавать нативные интерфейсы, на мой взгляд WebView не должно быть всем приложением. Но это не значит, что его не надо использовать вовсе.
По приглашению коллег из Сбербанка, в этом посте хочу рассказать про гибридные мобильные приложения. При правильном подходе, это отличный способ быстро реализовать идею в виде хорошо работающего продукта, достаточного для первого запуска вашего стартапа.
Также немного расскажу о том, как вы можете использовать WebView и как его могут использовать против вас злоумышленники. Примеры в статье будут показаны с использованием фреймворка React Native, но те же идеи можно реализовать и без него.
Немного про стартапы
Начну с принципиальных отличий в запуске стартапов у нас и на Западе, расскажу, как здесь может помочь WebView, дам рабочие примеры взаимодействия веб и нативных элементов, а также советы по технике безопасности при взаимодействии со сторонними приложениями.
Как правило, чтобы стартап стал успешным, ему нужно быстро запуститься. Потеряешь время – и конкуренты тебя обойдут. Это понимают и у нас, и на Западе. Но российский подход к запуску, как правило, гораздо основательнее — в плохом смысле этого слова.
Все неудачные российские стартапы начинаются и развиваются примерно по одному сценарию. Наиболее частые ошибки связаны со стратегическим планированием развития программного продукта. Руководство думает, что запуск возможен только после 110%-ной реализации всей функциональности и всех нюансов. При таком подходе быстро возникает дефицит бюджета, поскольку расходы на разработку высокие, а доходов от стартапа еще нет. Поиск дополнительных инвестиций, бесконечный круг утверждений и переработок занимает кучу времени, продукт появляется у конкурента. Все, марафон проигран.
Европейские и американские стартапы действуют иначе. Для начала они ограничиваются только мобильной веб-версией с минимально достаточной функциональной частью. Ее можно смотреть и с десктопов, и с мобильных устройств. И на этом этапе проект готов к запуску! После запуска для мобильных устройств делается приложение.
Как правило, по основным возможностям приложение не отличается от веб-версии. Оно расширяет возможности взаимодействия с пользователем, например посредствам пуш-уведомлений. Такой подход обеспечивает выполнение основного условия — быстрый запуск, быстрое получение первой прибыли. Доходы с первого этапа можно инвестировать в развитие. В дальнейшем проект может масштабироваться и развиваться как угодно без дефицита бюджета, бесконечно выполняя итерационный подход для добавления нового функционала и развития пользовательского интерфейса.
Предлагаю подробнее рассмотреть тот этап, когда уже есть мобильная версия сайта и нужно разрабатывать приложение для мобильных устройств. Итак, мы сделали сайт, а значит занимались разработкой серверного API, интерфейса и бизнес-логики. Два из трех компонентов –
— интерфейс и логика — присутствуют и в мобильном приложении. Согласитесь, не хочется писать их заново.
Объединяем лучшее от нативных и веб-приложений
Есть инструменты, ориентированные на разработку нативных приложений. Другие предназначены для веба. Преимущество нативных приложений в том, что они могут использовать весь функциональный потенциал телефона. Но разрабатывать их по сравнению с веб-приложениями довольно сложно. Веб дает возможность простого старта, но сильно ограничивает возможности приложения.
* для уменьшения тавтологии веб-приложениями я назову мобильные приложения, основная часть логики и интерфейса которых реализована на стороне браузера
Объединить все достоинства нативных приложений и веба позволяют гибридные приложения, которые создают с помощью компонента WebView. Конечно, найдутся дотошные разработчики, которые категорически против WebView в любых его проявлениях. Они аргументируют это тем, что приложение должно сразу быть полностью нативным, чтобы можно было использовать все возможности мобильного устройства, а также обеспечить комфортную производительность пользовательского интерфейса. Но во многих случаях, когда возможностей мобильной версии сайта вполне достаточно, можно сократить время первого запуска, сделав гибридное приложение, и заменять его на нативное постепенно.
Гибридные приложения — это не всегда что-то плохое и не расширяемое. Они могут быть удобными и производительными. При грамотном использовании такой подход помогает получить достаточное время на разработку качественного приложения, а не выпускать нативное приложение на скорую руку.
Есть несколько ситуаций, в которых целесообразно использовать гибридные приложения. Они хороши в качестве временной заглушки для быстрого старта — когда у нас готова мобильная версия сайта, а мобильное приложение нужно было «вчера». Такое приложение можно создать за несколько часов, запустить в продакшн. Пользователи получат возможность работать с мобильным приложением, а вы — возможность работать над более полноценной версией в менее жестких временных рамках (если это нужно).
Вот пример. Недавно коллегам срочно понадобилось мобильное приложение. В веб-версии у него было восемь пунктов меню, и мы их отобразили через WebView. А потом по одному пункту заменяли. Так получилось выпустить приложение не через месяц-три, а буквально за несколько дней. После постепенно переводили его на натив.
Гибридное решение не всегда временное. Его возможности позволяют переиспользовать в приложении кодовую базу, созданную ранее для веб-версии. К примеру специфичные анимации уже созданные на Canvas. Также WebView удобен, когда используется какой-то сторонний сервис. Еще один вариант – когда у вас есть сложный интерфейс, который проще подключить через WebView.
Как использовать WebView
Возьмем популярный сценарий. Мы хотим использовать мобильную версию сайта и нативное меню. Мы создаем нативное приложение с меню, но вместо контента подключаем мобильную версию сайта через WebView (пока что без каких либо изменений).
На гифке можно увидеть 2 меню. Правое меню является частью сайта, реализованное на веб, слева нативное меню, реализованное внутри мобильного приложения. Чтобы получить первое приближение к нативному приложению, нам достаточно просто скрыть то меню, которое реализовано на веб. Вот сколько кода нужно, чтобы через WebView отобразить веб-версию внутри приложения:
Следующий пример – о том, как нативная часть может взаимодействовать с вебом.
Робот нарисован на Canvas, это часть веб-сайта. А переключатель к нему построен на нативном UI. На разных телефонах он будет выглядеть по-разному. Мы можем управлять движениями робота при помощи переключателя. Можно и наоборот – какими-то элементами веб-интерфейса влиять на приложение. В React Native для этого предусмотрено специальный API для взаимодействия между вебом и нативной частью.
Ниже код для использования этой анимации. Layout — все пространство. Picker — нативная часть, которая может выбирать из dropdown варианты состояния робота. WebView — контейнер для отображения веба, внутри которого отрисовывается робот.
Подобные кейсы возникают часто. Например, мы сделали приложение для тестирования и аттестации стоматологов. Для каждого варианта ответа в тесте внутри вопросов рисовалась анимация, реализованная посредствам Canvas на вебе. Задача состояла в том, чтобы создать мобильное приложение, с этим тестированием. Использовав WebView, мы смогли отображать анимации из веба, тогда как остальной интерфейс мы построили нативно. Анимация отлично работала даже на старых смартфонах.
Как делаются инъекции
До 2013 года браузер Opera использовал собственный движок Presto, но потом его перевели на движок Blink от Google. Многих пользователей это очень расстроило. Свет на причины этого перехода проливает видео «Зачем опере вебкит». Главные виновники — большие корпорации типа Google или Facebook, которые не тестировали код своих продуктов в Opera и запрещали отображение страниц в этом браузере, ссылаясь на то, что он не достаточно популярен у пользователей.
Например, заходишь на Gmail через Opera и видишь: «Ошибка JavaScript». Пишешь в саппорт, получаешь ответ: «Opera у нас не поддерживается, мы не будем писать под нее код». Сначала компания Opera нанимала разработчиков, чтобы писать инъекции – специальный код, который встраивался в Gmail и позволял ему работать в Opera. Но постепенно таких сайтов, как Gmail, становилось все больше. Opera сдалась и сменила движок.
Так о чем это я? Ах да самое время поговорить об инъекциях:
На гифке – пример инъекции, которая изменяет поведение сайтов. Допустим, у нас есть чужой сайт, и мы делаем инъекцию стилей – скрываем правое меню и слайдер, выезжающий справа. Это – инъекция стилей. Логика работы сайта не меняется, только отображение.
Код, написанный зеленым, — инъекция. Она скрывает элементы, на них нельзя нажать, с ними нельзя взаимодействовать. С виду получается полностью нативное приложение, без веб-элементов управления.
Следующая инъекция интереснее. Допустим, у нас есть мобильное приложение, а в нем — встроенный мобильный браузер.
Человек переходит по ссылке, и мы запросто подставляем ему страничку Фейсбука, в которой нужно ввести логин и пароль. Если человек его вводит – приложение его перехватывает. Вот код:
Такой код называется инъекцией логики. Обычно он сложнее, но не намного. То есть утащить пароль проще, чем скрыть элементы управления.
Минутка паранойи: браузеры, встроенные в приложения
Как известно, во многих приложениях есть встроенные браузеры (WebView) — например, ВКонтакте, Telegram, Gmail, WhatsApp и так далее. Крупным компаниям мы можем доверять, но WebView используется и огромным количеством приложений с малым количеством звезд и сомнительными авторами — к примеру QR-ридерами, файловыми менеджерами, оболочками для камер и т.п… Устанавливаешь приложение, читаешь через него код, нажимаешь на ссылку, вводишь конфиденциальные данные — и у приложения, как показано в предыдущем примере, появляется доступ к ним. А потом уже не отследишь, куда эти данные утекают. Поэтому для открытия ссылок пользуйтесь только браузерами, которым доверяете.
Есть сайты, которые запрашивают логин и пароль каждый раз. А есть такие, которые делают это редко — раз в месяц, раз в год. Как ни странно, второй вариант безопаснее с точки зрения утечки данных через WebView. Например, ты заходишь на сайт с какого-то левого браузера. Сайт требует логин и пароль, и тебе не кажется это странным – он всегда так делает. А в случае, когда авторизация требуется редко, это заставит насторожиться.
Интересно, что двухфакторная авторизация от такой атаки не защищает – только от кражи пароля. Дело в том, что после подтверждения тебе в ответ возвращается токен, который, в свою очередь, двухфакторной авторизации уже не имеет, и его легко перехватить. То есть если ты ввел логин и код с СМС один раз, то браузер получает токен, который можно использовать многократно. С этим подтвержденным токеном он может делать что хочет, в течение времени, пока токен остается актуальным. В общем, не стоит слишком доверять встроенным браузерам.
Познакомиться с примерами из этого поста можно через демо-приложения. На ОС Android нужно скачать Expo Project — инструмент для работы с JavaScript и React Native. После установки Expo останется только считать QR-код:
С устройствами под iOS сложнее: компания Apple запретила распространять приложения таким образом. Так что любопытствующим придется собрать приложение из исходников на GitHub. Спасибо за внимание!
В только что вышедшей iOS 11.3 практически незаметно начали работать Progressive Web Apps. Настала пора разобраться с тем, как PWA работают в новой версии операционной системы и какие ограничения накладываются на такие приложения.
В iOS 11.3 Apple незаметно добавила поддержку базового сета технологий Progressive Web Apps (PWA). Настало время посмотреть, как они работают, каковы их плюсы и минусы и что вам нужно знать, если у вас уже есть опубликованное PWA.
Для PWA нет единого или точного определения. В целом это приложение, созданное при помощи веб-технологий, которое может работать оффлайн. Его можно по желанию установить в операционную систему, где оно будет выглядеть и вести себя так же, как и все остальные приложения.
В процесс при этом не вовлечены магазины приложений, только Edge/Windows 10 сейчас размещает PWA в магазине. Это значит, что теперь вы можете устанавливать приложения на iOS без необходимости получать одобрение App Store. Apple не упомянула об этой возможности только потому, что не хотела запутать пользователей. Даже в заметках о релизе Safari не упоминалось об этой возможности.
Но ведь Apple и создала PWA?
До того, как команда Chrome придумала термин PWA, идея принадлежала Safari и оригинальной iPhone OS. В 2007 Стив Джобс анонсировал “ещё одну вещь” на WWDC: разработка приложений для оригинального iPhone была основана как раз на веб-технологиях. Напомним, что App Store не было в оригинальном плане, а нативный SDK не был доступен в течение первого года существования устройства. С точки зрения Apple, даже сегодня PWA — это просто “веб-приложение с домашнего экрана”, а иконку называют WebChip. Можете посмотреть мою презентацию с Fluent Conference, я упоминаю это на 10:50.
Приложение не проходит тест качества App Store, верно?
Да, все правильно. Но приложение будет работать на основе модели безопасности браузера или веб-платформы. Это означает, что вы можете “публиковать” приложения, которые не будут одобрены в магазине, например, внутреннее приложение для ваших сотрудников, но у вас не будет доступа к чисто нативным функциям: FaceID на iPhone X или ARKit. Либо вам придется подождать, пока веб-платформа начнет поддерживать эти новые функции.
PWA может запускаться внутри Safari, как любой сайт, или в полноэкранном режиме, как любое другое приложение в системе. Если вам интересно, используют ли PWA Web View, то это не так для Safari или установленнии иконкой, но Web View используется при работе в других браузерах или в приложении Facebook.
Возможности PWA на iOS
С Web Platform на iOS вы можете получить доступ к:
- геолокации
- сенсорам
- камере
- аудиовыходу
- синтезу речи (только с подключенной гарнитурой)
- Apple Pay
- WebAssembly, WebRTC, WebGL и другим экспериментальным функциям.
Ограничения по сравнению с нативными приложениями
- Приложение может хранить данные и файлы не больше чем на 50 МБ.
- Если пользователь не использует приложение несколько недель, iOS удалит все файлы приложения. Иконка будет доступна на домашнем экране, но приложение будет скачиваться снова.
- Отсутствие доступа к некоторым функциям: Bluetooth, серийному номеру, Beacons, Touch ID, Face ID, датчику высоты, информации о батарее.
- Отсутствие работы в фоновом режиме.
- Отсутствие доступа к приватной информации (контакты, background location) и к нативным социальным приложениям.
- Отсутствие доступа к платежам внутри приложения и другим сервисам Apple.
- На iPad отсутствует доступ к оконному отображению, PWA будет занимать весь экран
- Отсутствие пуш-оповещений и интеграции с Siri
Что PWA могут на Android, но не на iOS
- На Android вы можете хранить более 50 МБ.
- Android не удаляет файлы, если вы не используете приложение, но файлы могут быть удалены при отсутствии свободной памяти. Если пользователь часто использует PWA, приложение может запросить постоянное место для хранения.
- Доступ к Bluetooth для устройств BLE.
- Web Share для доступа к собственному диалоговому окну
- Распознавание речи
- Фоновая синхронизация и пуш-оповещения
- Баннер веб-приложения, который пригласит пользователя установить приложение
- Ограниченная кастомизация Splash Screen и ориентации
- С WebAPK и Chrome пользователи не могут установить больше одной копии PWA
- С WebAPK и Chrome PWA появляются в настройках, и вы можете видеть статистику использования данных, на iOS все находится в разделе Safari
- С WebAPK и Chrome PWA управляет запросами для своего URL, поэтому ссылка на PWA откроется в отдельном окне, а не в браузере.
Что PWA могут на iOS, но не на Android
- Пользователи могут менять название иконки перед установкой
- Пользователей можно настраивать в профиле конфигурации, поэтому корпоративные пользователи могут получать ссылки на PWA от компании. Safari называет эту функцию WebChip, но это не соответствует Web App Manifest.
Как установить PWA без App Store?
Приложение будет выглядеть, как любая другая иконка на экране. Для неё не будет доступно меню 3D Touch. И если вы установите то же самое PWA снова, у вас будет еще одна иконка, указывающая на то же приложение.
Во многих веб-приложениях есть ссылка на установку нативного приложения из App Store, и она остается в PWA, как в примере с Tinder:
У меня уже есть PWA, будет ли оно работать на iOS?
Ваше PWA будет сразу доступно для установки после того, как ваши пользователи обновят систему до iOS 11.3. Вам не нужно будет подстраиваться под iOS, но все не всегда будет работать, как задумано.
При нажатии Login или Continue открывается окно Safari, поэтому PWA оказывается бесполезным
Я писал об этом статью раньше, и многие баги и сложности бета-стадии остались в финальной версии.
Что не будет работать
- display: fullscreen и display: minimal-ui не будут работать на iOS, fullscreen будет вызывать новое окно, а minimal-ui станет ссылкой на Safari. Вы можете приблизиться к fullscreen (панель статуса будет над вашим приложением) при помощи расширения экрана cover-fit.
- Если вы полагаетесь на фоновую синхронизацию, вам нужно будет иметь решение для резервного копирования.
- Нет возможности зафиксировать ориентацию PWA.
- theme-color для стиля панели статуса не будет работать; вы можете использовать метатег для белых или черных панелей статуса, а также трюк с CSS/HTML для эмуляции theme-color.
- Если ваше PWA не поддерживает жесты или кнопки в интерфейсе, пользователь не сможет переключаться между экранами.
- Ваша иконка для Android будет ужасно выглядеть на iOS, так как Apple не поддерживает прозрачные иконки.
- iOS берет иконки не из Web App Manifest, а по ссылке из apple-touch-icon. Если вы не предоставите ссылку, вместо иконки будет использоваться скриншот.
- Splash screen отсутствует, поэтому многие цветовые свойства из манифеста игнорируются.
- События из манифеста не будут работать, поэтому если вы отслеживаете установку через эти каналы, они не будет работать на iOS (но вы можете отслеживать через navigator.standalone).
О чем нужно помнить
- PWA не сохраняет состояние между сессиями, и если пользователь выйдет из PWA, оно перезапустится с самого начала при возвращении, поэтому, если вы хотите, чтобы пользователь подтвердил получение письма, SMS или совершил двухфакторную аутентификацию, вам нужно будет продумать правильное решение.
- У PWA нет скриншотов, поэтому они отображаются как белые экраны.
- В полноэкранном режиме есть много багов, поэтому не полагайтесь только на Safari при тестировании.
- Если вы хотите использовать выемку на iPhone X, вам нужно будет внести изменения в HTML и CSS. Если вы не сделаете все правильно, может произойти странное.
- Иногда при установке на домашний экран не используется манифест, поэтому на экране оказывается только ссылка.
- Safari и ссылка на домашнем экране используют одну и ту же регистрацию Service Worker и кэшированные файлы. Safari View Controller поддерживает Service Workers и сохраняет кэш, но он удаляет все данные после закрытия сессии.
- Chrome, Firefox и использующие WebView приложения не поддерживают Service Worker-ы, поэтому файлы не устанавливаются. Я думаю, что для WKWebView нужен API, чтобы владелец приложения решал, что делать с Service Worker.
- Чтобы избавиться от багов Service Worker, вам нужно установить Safari Technology Preview или Safari 11.1, доступные с обновлениями macOS 10.11.5, 10.12.6 и 10.13.4.
- Service Workers можно отключить в настройках.
- Если открыть несколько PWA в одно время, в панели задач iOS будут показаны приложения-“призраки” без иконки и названия.
Разработчики популярных веб-ресурсов стараются сделать все возможное, чтобы клиентам было комфортно потреблять предоставляемый контент. В частности, нередко можно встретить, что из сайта они создают отдельное приложение. С помощью приложения можно информировать посетителей о новинках, если подключить всплывающие уведомления, либо использовать его как метод дополнительного продвижения. В общем, преимуществ у такого подхода много.
Что для этого нужно, сложно ли сделать такое приложение и какие знания для этого потребуются? Поговорим об этом в сегодняшней статье.
Зачем создавать из сайта приложение
Мы давно привыкли говорить «веб-приложение», подразумевая под этим простое приложение. Чаще всего приложения похожи по функциональности на обычные мобильные версии сайта, но все-таки есть некоторые отличия. В полномасштабном приложении мы получаем доступ к различным функциям, которые на сайте попросту отсутствуют. Например, это может быть функция встроенных уведомлений, хотя сейчас и такое можно спокойно организовать через браузер.
Приложения из сайтов популярны среди новостных ресурсов и других веб-сайтов, насыщенных контентом. Если вы столкнулись с тем, что вам нужно конвертировать сайт, но до сих пор не уверены, нужно ли вам это, то давайте разбираться в преимуществах такого подхода.
- Приложение из сайта – это то, что нужно для хорошего ресурса. Когда пользователь читает что-либо на странице браузера, то он может спокойно перемещаться между вкладками. В приложении такого не будет – таким образом, посетитель с большей вероятностью останется на ресурсе на долгое время.
- Мобильные приложения позволяют использовать такие функции, как push-уведомления, повторяющиеся подписки и т.д.
- Не стоит забывать и том, что миллионы пользователей ежедневно посещают Google Play и AppStore. Если там будет лежать ваше веб-приложение, то посещаемость сайта может заметно вырасти.
Что для этого нужно?
Разработка собственного приложения из веб-сайта – довольно сложная задача, которая требует особых знаний в области программирования. Для самостоятельного изучения вы можете найти много гайдов по данному вопросу, но не факт, что они легко дадутся. В этом деле довольно много нюансов, которые будут посильны только специалисту.
Если самостоятельно сделать его не получается, то надо ли непременно искать программиста? Да, но только тогда, когда нужен высококачественный продукт со своими фишками. В противном случае можно обратиться к онлайн-сервисам, которые выполняют конвертацию сайта в приложение всего за несколько минут. Кроме того, если ваш сайт работает на CMS WordPress, то его можно легко преобразовать в приложение. Сделать это можно с помощью специальных сервисов и плагинов, распространяющихся как в бесплатном, так и платном доступе.
Лучшие сервисы для создания приложения из сайта
Обратите внимание на то, что ни один бесплатный сервис не сможет обеспечить высокую функциональность вашему приложению. Обычно они предназначены для того, чтобы сделать что-то простое, приближенное к демоверсии. Если нужно получить функциональный продукт для широкой аудитории, то лучше обратиться к специалисту либо к платным сервисам.
Подробнее о них мы и поговорим далее – рассмотрим как профессиональные решения, так и более простые.
Tadapp Native
Tadapp Native – это лучшее решение для тех, у кого нет времени ждать. Сервис заверяет, что может создать приложение для Android и iOS всего за 5 минут и бесплатно опубликовать его в Google Play. Единственное, с чем могут возникнуть проблемы, так это с адаптацией сайта. Если ее нет, то конвертация, вероятнее всего, пройдет некорректно.
Особенности:
- возможность подключения бесплатных push-рассылок;
- личный кабинет позволяет управлять сразу несколькими приложениями;
- доступна возможность загрузить собственный экран загрузки приложения, иконки;
- есть техподдержка – скорость ответа составляет около 2 часов.
Стоимость: от 890 рублей
Ссылка на официальную страницу: Tadapp Native
Appmaker
Appmaker – сервис с 14-дневным пробным периодом, во время которого пользователю предоставляется возможность создать из сайта полноценное приложение на платформе iOS или Android. Appmaker предлагает 3 варианта создания приложений: на WordPress, c WooCommerce и в виде Web App (веб-версия). На официальном сайте можно найти истории успешных компаний, которые использовали данный сервис.
Особенности:
- поддерживает более 2000 различных плагинов;
- работа с WordPress и WooCommerce;
- пробный период;
- круглосуточная поддержка.
Стоимость: от $9.90
Официальная страница: Appmaker
Appverter
Appverter – это профессиональный сервис для тех, кто не хочет тратить свои деньги впустую. Он предлагает пользователям переложить свою проблему на высококвалифицированных специалистов. Всего за $50 можно получить полноценное Android-приложение из сайта; для iOS эта цена возрастает до $100.
Особенности:
- быстрая разработка за 1 день;
- уникальное приложение – никаких шаблонов;
- консультация и поддержка входят в стоимость;
- есть тариф со 100% гарантией публикации;
- некоторые тарифные планы включают пункт «Публикация под ключ».
Стоимость: от $50
Официальная страница: Appverter
AppPresser: плагин для WordPress
AppPresser – это сервис, позволяющий создавать мобильные приложения для Android и iOS с использованием собственного компоновщика. Хотя сам плагин и является бесплатным, тарифные планы сервиса начинаются от $19 в месяц. Для работы с ним не нужны особые знания в программировании. Если вы хорошо владеете WordPress, то с данным инструментом не возникнет никаких проблем.
Особенности:
- возможность создавать приложения из любого сайта на WordPress;
- работает как конструктор: масса различных настроек;
- на официальном сайте есть документация на английском языке.
Стоимость: от $19
Официальная страница: AppPresser
MobiLoud: плагин для WordPress
MobiLoud – это еще одно решение для веб-ресурса, созданного на WordPress. Он очень похож на предыдущий сервис, но здесь есть некоторые отличия. MobiLoud предоставляет несколько «предустановок» приложений, которые можно использовать в зависимости от того, какие функции необходимо реализовать. Второе отличие – стоимость, и она заметно выше.
Особенности:
- 100% синхронизация приложения с сайтом;
- возможность создать приложение менее чем за сутки;
- приложение от MobiLoud часто монетизируются;
- есть бесплатная демоверсия;
- отличная кастомизация.
Стоимость: от $200
Официальная страница: Mobiloud
Создаем приложение из сайта
Лучшие сервисы мы рассмотрели, теперь давайте воспользуемся одним из них и попробуем создать приложение на основе веб-сайта. Для примера возьмем сервис Appmaker с бесплатным пробным периодом.
Чтобы сделать приложение, выполним следующее:
- Переходим на официальную страницу и на главной выбираем «Get Started for Free».
- На отобразившейся странице нам предлагают ввести URL веб-сайта на WooCommerce. Если у вас его нет, то просто введите любой другой адрес – это требуется, чтобы перейти на нужную нам страницу.
- Выбираем, на основе чего будет создано приложение. Если сайт не на WordPress или WooCommerce, то жмем «Create web app».
- Вам будет предложено зарегистрировать аккаунт – заполняем все нужные поля и идем дальше. В новом окне вводим адрес сайта, который нужно преобразовать, а также указываем свою электронную почту. Затем жмем «Proceed».
- В результате перед нами отобразится окно конфигурации. Процесс создания приложения может занять некоторое время – все зависит от веса сайта.
Как только создание приложения будет завершено, будет предоставлена ссылка на скачивание файла. На этом все!
Читайте также: