Своим опытом и знаниями с участниками будут делиться не только сотрудники Яндекса, которые делают приложения для миллионов пользователей, но и приглашенные специалисты. Мы не обойдемся только теорией. Будет много практики и командной работы над настоящими продуктами. Как всегда, обучение бесплатное, а всем иногородним студентам Яндекс оплатит проезд и проживание. Если вы еще не отправили заявку, есть немного времени это сделать. Занятия стартуют 3 июля и закончатся 23 сентября — в день двадцатилетия Яндекса.
В мобильной разработке одни из самых горячих споров ведутся вокруг нативной и гибридной разработки. Мы решили дать трём преподавателям «Мобилизации» порассуждать на эту тему. Получилось небольшое интервью, которое может быть интересно как новичкам в разработке, так и тем, кто уже определился со своим выбором.
Юрий Подорожный. Руководитель службы разработки мобильных геоинформационных сервисов Яндекса. Работает над Яндекс.Картами и Яндекс.Метро. Занимается мобильной разработкой более восьми лет. Основатель студии Any Void, которая в 2014 году стала частью Яндекса.
Сергей veged Бережной. Руководитель отдела разработки поисковых интерфейсов, в Яндексе с 2005 года. Успел поработать над Поиском, Почтой, Поиском по блогам, Я.ру, Картинками, Видео. Помимо этого, активно занимается развитием внутренних инструментов для создания сайтов.
Лола Кристаллинская. Руководитель департамента дизайна, работает в Яндексе с 2008 года, отвечает за найм, управление и развитие дизайнеров, коммуникации и образовательные программы департамента и всю экосистему дизайна в компании. С Лолы начался коллектив дизайнеров и исследователей дизайна Яндекса. До прихода в компанию руководила отделом создания сайтов Студии Артемия Лебедева.
Лола Кристаллинская:
Давайте для начала дадим определение, что вообще такое нативная и гибридная разработка и в чем между ними разница?
Юрий Подорожный:
В 2007 году появился iPhone, в 2008-м Apple дала возможность под него делать приложения, что и стало отправной точкой нативной разработки. Это компилируемый язык программирования со средой разработки, ограниченной какой-то одной мобильной платформой. Objective-C и Swift для iOS, Java — для Android. Приложения создаются на одном из этих «родных» языков по законам определенной платформы.
В части программирования это было что-то революционно новое?
Юрий:
Конечно, нет. Сам термин «нативная» возник просто на контрасте с гибридным подходом.
Сергей Бережной:
Под гибридной разработкой мы подразумеваем способ писать приложения, когда оно полностью или частично рендерится и работает с помощью веб-технологий. То есть внутри используется что-то, реализованное с помощью HTML, CSS, JavaScript.
Юрий:
На самом деле чистое веб-приложение сейчас не сделать. Веб-вью все равно нужно положить внутрь iOS или Android-приложения, то есть в любом случае нужен контейнер, который написан с помощью Java, Swift или Objective-C. Значит, все равно будет какой-то процент нативного кода. Чистые веб-приложений были, наверное, только первый год существования iPhone, когда еще нельзя было создавать их со стороны. И Apple тогда продвигала тему, чтобы разработчики делали веб-приложения. Кстати, эта функция есть до сих пор. Заходишь в Safari, нажимаешь на экран «домой», на рабочий стол добавляется иконка, по сути, это и есть чистое веб-приложение. Только его, конечно, не распространишь через Store.
Сергей:
Сейчас есть целый ряд фреймворков, платформ типа PhoneGap/Cordova, в которых, условно говоря, уже написан этот фрагмент кода. Ты просто берешь их за основу и разрабатываешь на них, сочетая с веб-элементами на свое усмотрение.
Юрий:
Гибридный подход возник, наверное, из естественного желания сэкономить время и ресурсы, когда мобильная разработка начала набирать обороты. Например, есть некая молодая ОС, есть целый спектр технологий, которые пришли из веба, и у многих возникает соблазн, почему бы их не использовать. Но, честно говоря, не знаю зачем. На мой взгляд, ни одно нормальное приложение с помощью веб-технологий не сделать.
Гибрид для простых задач, натив — для сложных
Лола:
В таком случае актуальна ли вообще проблема выбора? Например, я менеджер, у меня есть продукт и мне нужно сделать мобильную версию. Как принимать решение, что для меня лучше — гибридная разработка или нативная?
Сергей:
Нужно исходить из задачи, необходимых выразительных средств для ее реализации и имеющихся ресурсов. Если в жизни просят сыграть музыку, а у вас есть только краски, то будет тяжело. Если нужно в реальном времени обрабатывать видео с камеры, сделать 3D-анимацию и подобные сложные вещи, то без ядерных технологий нативной платформы не обойтись. И, наоборот, если вашему приложению в качестве выразительных средств достаточно простого черно-белого карандаша, то веб-технологии могут сэкономить время и деньги.
Юрий:
Согласен, все зависит от задачи. Но, на мой взгляд, веб уместен лишь в нескольких случаях. Например, если это совершенно новый продукт и пока не понятно, воспримет ли его рынок, нужен ли он кому-то или нет, то есть задача — протестировать некую гипотезу. Или если это просто отображение контента в небольшом количестве и не предполагается активного взаимодействия с интерфейсом, переходов между экранами и разделами. Например, приложение Meduza. Заходим на экран новости, это как раз веб-вью. У них простая верстка, точно такая же, как для веба, им даже контент готовить не надо, в мобильной версии все сразу отображается.
Сергей:
По задаче сайты могут быть совершенно разными. Помните, в свое время был выбор между тем, делать флэш-сайты или HTML-сайты. И все говорили, если хотите, текст, нарисованный по кругу, видео внутри и чтобы все было красиво, то нужно делать только флэш. Так и здесь.
Юрий:
Есть, конечно, удачные примеры гибридных приложений. Например, интересная модель у Basecamp: часть навигации реализована нативно, для того, чтобы переходы осуществлялись быстро и плавно, а отображение контента в списке задач сделано на HTML, благодаря чему у них одинаковые шаблоны для тачовой и мобильной версий. Но у нас в Яндекс.Картах всегда был нативный подход, потому что сделать приложение с картами, которое будет производительным и удобным, с помощью веб-технологий просто невозможно. Единственное место, где мы используем веб, это вывод лицензионного соглашения.
Скованные гайдлайнами
Лола:
В идеале все, конечно, должно идти от смысла, от того, что и зачем тебе нужно, какой продукт и что для него важно. Но мы живем в реальном мире, где не у всех и не всегда в принципе есть выбор. У кого-то не хватает денег, чтобы нанять целую команду разработчиков, поэтому приходится быть изобретательным. Какие еще факторы играют роль при выборе технологии?
Сергей:
Если бы у меня было бесконечное количество денег, я бы нанял трех разработчиков, которые сделали бы хорошие нативные версии под все платформы. Но я слишком жадный, чтобы позволять себе такое расточительство. Гибридный подход позволяет сэкономить: сделать один вариант и использовать его везде. Но если в дальнейшем задача усложнится, и появится необходимость, например, сделать наложение картинок на видео в реальном времени, то все равно придется потратиться на трех разработчиков.
Кроме того, встает вопрос, хотите ли вы трижды рисовать разный дизайн для каждого приложения. Ведь гайдлайны операционных систем сильно отличаются друг от друга, и как лебедь, рак и щука двигаются в разные стороны в мелочах. Если внимательно прочитать гайды Windows Phone, Android и iOS, то окажется, что нужно хорошо продумать, как ваша пользовательская задача будет оптимально решаться на каждой из платформ.
Лола:
Если приложение сделано не по гайдам, то проверку в Store не пройти?
Юрий:
Можно, конечно. Далеко не все приложения, прошедние проверку в Apple, соответствуют дизайнерским гайдлайнам. Никто особо не следит за соблюдением этих правил.
Сергей:
Но мы же говорим о приложениях A+ и AAA-класса, о высшей лиге. Если такие делать, то вопрос о нативном дизайне для каждой платформы обязательно встанет.
Лола:
А общий дизайн невозможен в нативной разработке: если просто свои кнопки и контролы?
Сергей:
Смотря к какому лагерю вы относитесь. Некоторые считают, что приложение должно быть внутри платформы. Альтернативная точка зрения – каждый бренд должен выглядеть на всех платформах одинаково. Если посмотреть на Instagram или Facebook, то это как раз примеры борьбы бренда за самоидентификацию по отношению к платформам. Они специально дизайнят свои приложения так, чтобы те выглядели по-особенному и везде одинаково.
Как делают приложения в Яндексе
Лола:
Для многих тот факт, что Facebook разочаровались в веб-технологиях и перешли на нативную разработку, стал доказательством превосходства последней. Насколько это обосновано?
Сергей:
Это как раз история про то, что хорошо быть Facebook, когда можно нанять сколько угодно программистов, чтобы сделать продукт отдельно для всех платформ. Кстати, в ответ на такой шаг некие ребята, чтобы попиарить свою студию, сверстали фейсбучное приложение на веб-технологиях без всех тех недостатков, из-за которых Facebook сменили подход. То есть здесь всё не так однозначно. Может быть, ваше веб-приложение тормозит не потому что веб-технологии плохие, а потому что у вас программист не сделал всё что мог.
Юрий:
У Facebook в первой версии было полностью нативное приложение, потом они перешли на HTML, пару лет пожили с двумя звездочками в Store, потому что продукт реально тормозил, все их ругали, в итоге вернулись к нативу. Вот живая иллюстрация того, как из благих намерений хочешь сделать хороший интерфейс на веб-технологиях, но в итоге все равно упираешься в низкую производительность или недостаток средств для развития.
Лола:
Но поисковое приложение Яндекса, например, сделано гибридно. Почему, если столько недостатков у веб-технологий?
Сергей:
Наши сервисы в основном решают информационные задачи, поэтому и интерфейсы могут быть проще, чем в случае с развлекательными игровыми продуктами. Так что мы не сильно упираемся в производительность. А выразительные средства веб-технологий при умелом использовании не такие уж и скудные. Кроме того, гибкость гибридного подхода позволяет не переписывать полностью какие-то наработки, сделанные ранее в вебе, которых у нас довольно много, и их переделка потребовала бы больших трудозатрат. А так мы экономим время и деньги.
Но сложно приходится нашим дизайнерам — им нужно создавать интерфейсы, которые будут восприниматься пользователями как «общий интерфейс Яндекса» независимо от платформы.
Юрий:
Помимо UI, есть еще вопрос удобства пользователя. И у каждой платформы свой UX. Пользователи ожидают, что хорошее приложение будет удобным и будет следовать их привычкам.
Лола:
Как вы в своих продуктах решаете проблему баланса между удобством пользователей и единством бренда?
Юрий:
Два года назад эта проблема в Яндексе была более явной. Все приложения сильно отличались между собой по стилистике. В итоге мы разработали свои общие для всех интерфейсные гайды, выбирая наиболее удачные паттерны из всех мобильных гайдлайнов, а иногда и придумывая свои, лучшие. Но процесс внедрения новых правил очень длительный, с огромным количеством подводных камней и пока не завершен окончательно.
Сергей:
Основные движущие факторы наших экспериментов с технологиями — это оптимизация трудозатрат на разработку и желание предоставить пользователям качественный продукт. Изначально мы делали наше поисковое приложение нативно, но столкнулись, например, еще с такой проблемой, как синхронизация команд и релизов. Даже если изначально вы решили потратиться на разных разработчиков под три разные платформы, то в дальнейшем рискуете столкнуться с проблемой управления. Как сделать так, чтобы новый UI, новые фичи на этих платформах везде обновлялись в одно время, и чтобы у них было действительно синхронное понимание этого интерфейса?
Как показывает практика, в крупных компаниях все это превращается в разные кланы разработчиков: одни делают мобильную версию приложения, другие — тач-версию сайта, третьи — десктопную версию, кто-то создает приложение для Android, а кто-то — для Windows Phone. И нужен менеджер 80-го уровня, чтобы синхронизировать все эти пять команд между собой. А подход единого кода, следовательно, единой команды, помогает избавиться от подобной путаницы.
Юрий:
На мой взгляд, это не проблема, а условие задачи. Например, когда мы в Яндекс.Картах делаем какую-то новую штуковину, то сначала отрабатываем ее на одной платформе, а потом уже, собрав все грабли, добавляем на все остальные.
Что нужно знать разработчику, чтобы начать делать приложения
Лола:
Насколько разнится порог вхождения у нативной и гибридной технологий? Вообще, какая база должна быть у программиста, чтобы уйти в мобильную разработку?
Юрий:
Разработчик нативных приложений должен знать Objective-C, или SWIFT, или Java, или C++. Но, на мой взгляд, на каком языке писать, дело наживное, ключевое здесь — базовые знания программирования. Все, с кем я в своей жизни делал приложения, были студенты без мобильного опыта, но с хорошим бэкграундом. Все остальное постигается на практике. Попадешь в хорошую команду профессионалов, вырастешь на порядок быстрее.
Сергей:
Если у человека есть опыт разработки интерфейсов с помощью HTML, CSS или JavaScript, то придется глубже погрузиться в специфику именно мобильных браузеров. Если мы говорим об интерфейсах, то это паттерны взаимодействия — больше пальцами, меньше с клавиатурой. Своя специфика внутри Runtime JavaScript и CSS для мобильных браузеров, но отличий в последнее время все меньше. Как правило, разработка под мобильные проще, чем под широкий спектр десктопных браузеров, потому что у них, как относительно новой технологии, более современная реализация именно веб-стандартов. Но сейчас по мере того, как мобильные платформы стареют, начинают возникать те же проблемы, что на десктопе, когда есть клиенты со старыми браузерами, которые какие-то вещи не поддерживают.
Лола:
А есть у программистов деление на мобильных и не мобильных? Например, на рынке дизайна сейчас это уже обязательный дополнительный скилл. Может быть, ты действительно каждый день не имеешь дела с мобильными интерфейсами, но без базовых знаний мобильного дизайна уже почти невозможно пройти собеседование и отбор.
Юрий:
Программирование имеет такое огромное поле применения, что человек, который занимается разработкой на C++ каких-то серверных компонентов, может вообще ничего не знать про мобильную разработку, писать, к примеру, какой-нибудь банковский софт и комфортно себя чувствовать.
Сергей:
Согласен, разрабатывать под микроконтроллеры или пользовательские интерфейсы — вещи действительно очень разные, и перепрыгнуть из одной лодки в другую не так-то просто. Но если говорить о мобильной разработке, то в Яндекс мы берем людей, которые верстают наши сайты сразу под декстопные и мобильные версии. То есть они должны понимать, как наша верстка, наш HTML, CSS и JavaScript будут работать в десктопных браузерах, а как в мобильных, какие есть особенности и нюансы. Получается, как с дизайнерами, дополнительный скилл фронтенд-разработчика.
Лола:
А внутри мобильной сферы насколько жесткое деление специалистов в зависимости от платформы?
Юрий:
Android и iOS — две совершенно разные истории. При желании, конечно, можно научиться делать и то, и другое. Но среди тех, с кем я работал, не было ни одного, кто менял бы платформы.
Сергей:
Каждая платформа — это достаточно глубокая экосистема, и для работы нужен хороший практический опыт. Но думаю, стажера со знанием андроидных технологий и желающего изучить эппловские, в команду, которая занимается iOS-приложениями, мы легко возьмем. Разница все же не такая большая, как между программированием микроконтроллеров.
Адаптивная верстка — не панацея
Лола:
Я слышала, что для бедных, но хитрых, есть еще такая вещь, как адаптивная верстка, которая сразу и для веба, и для мобильных.
Сергей:
Есть технологическая возможность сделать интерфейс на веб-технологиях так, чтобы он вел себя по-разному на десктопе и на мобильных, и чтобы мог адаптироваться под них. Но, к сожалению, резиновость некоторых изделий не бесконечна, и та вариативность, в пределах которой может быть эта адаптивность, весьма ограничена. Главное преимущество такой резиновой верстки в том, что вы один код сверстали и везде его используете.
В Яндексе мы делаем немного по-другому: есть общие куски, которые мы используем везде, а есть те, которые должны быть разными, под разные размеры, их мы пишем отдельно. Таким образом мы пытаемся усидеть на двух стульях: взять и реиспользование кода, которое есть в концепции адаптивности, и привнести более тонкую адаптивность конкретными переопределениями для тачовых и для десктопных платформ.
Лола:
Давайте резюмируем, как менеджеру, дизайнеру и разработчику учитывать все эти нюансы?
Сергей:
Я рекомендую не быть упоротыми фанатиками и каждый раз осознанно делать выбор, имея в голове как можно более широкий контекст и принимая во внимание все факторы. Не мыслить типа «Раз Facebook перешел с гибридного подхода на нативный, значит, и нам нужно» или «Раз Яндекс верстает свою выдачу в приложении на веб-технологиях, значит, и нам надо делать так». Нужно погрузиться в тему.
Юрий:
А для этого нужно как минимум понимать и в том, и в другом. Понимать, как устроен мир, как это работает, потому что единственно правильного подхода нет. Вполне можно делать нативное приложение, в котором какие-то интерфейсы и разделы будут сделаны на вебе, и тем самым местами упрощать себе жизнь. Нужно разбирать каждую задачу индивидуально, и только потом принимать решение. Волшебной таблетки здесь не существует.
Комментарии (32)
KamiSempai
20.04.2017 16:57Так ведь в Facebook сейчас React Native используют. Разве это не разновидность кроссплатформенной разработки?
MikhailMKZ
20.04.2017 17:30Как я понял, Facebook разрабатывает React Native и использует его в своих приложениях, но они не целиком написаны на React Native.
React Native Showcaseipavlenko
20.04.2017 19:22Многие забывают, что React Native это технология, предназначенная для организации композиции нативных UI-элементов. И это иногда даёт overhead на разработчиков больше, чем при разработке гибридных. Ибо там они вольны ваять красоту без ограничений и сверстать могут любой макет, и лишь при обращении к устройству им нужен нативный код. А вот задание сверстать согласованый макет на React Native порой несёт сюрпризы.
Nakosika
21.04.2017 12:15Брешут. Вот только на днях заопенсорсили либу для натива, довольно серьезную, которую используют для многопоточного рендеринга карточек в ленте. На реакте производительности не хватит в принципе.
vintage
20.04.2017 19:41+2Вполне можно делать такую резину, которая и на маленьком экране не выпирает и на большом не выглядит по
дебильномумобильному. Например: http://mol.js.org/app/supplies/
ad1Dima
21.04.2017 07:50Возможно ссылка работала, но сейчас если оно выглядит не то что бы по-мобильному
а как-то тоже не ок
passerby
21.04.2017 10:34+2Всегда интересовало, почему ваши приложения такие э-э… активнопотребляющие ресурсы? И медленно работающие. Во всяком случае под Андроид.
Яндекс-такси — батарейку съедает прямо а глазах. Только запустишь — сразу настолько активно что-то делает, что индикатор оставшейся энергии щелкает по одному проценту в 30 секунд. Если закрыть (свернуть) приложение, то постоянно использует запросы геолокации. Пока полностью принудительно не остановишь работу в настройках системы. Убер и гетт — так себя не ведут. В итоге пользуюсь убером.
Яндекс-навигатор. Стартует очень долго. При работе раскаляет телефон до такой степени, что появляется системное сообщение о том, что батарея имеет недопустимую температуру и необходимо выключить телефон. И это после каких-то получаса работы. Тот же османд по несколько часов без проблем работает, ничего не перегревая. Телефон в это время работает от авто-зарядки.
И вишенка на торте — оба этих приложения каким-то образом перезапускают друг друга. Т.е. если принудительно завершить одно из них, то через некоторое время оно опять оказывается запущено. Если остановить оба (настройки-приложения-остановить) — то тогда действительно все завершается.
То, что приложение активно, определяю по запросам разрешения обратиться к запрещенным для приложения ресурсам. Например — запрещаю яндекс-такси использовать «сведения о местоположении». И при попытке яндекс-такси получить это самое местоположение — появляется системное уведомление о том, что яндекс-такси пыталось это сделать.vintage
21.04.2017 10:40А чем вы это запрещаете?
passerby
21.04.2017 10:43+2Я не запрещаю. Просто заметил, что кто-то с некоторой периодичностью использует GPS, решил выяснить кто. Вот таким образом нарушитель моего спокойствия и нашелся.
passerby
22.04.2017 10:42Извините, только сейчас заметил — прочитал ваш вопрос как «зачем», а не «чем». Подумал, что вы спрашиваете, зачем я вообще запрещаю использование GPS на телефоне. На это и ответил, что не запрещаю в общем и целом.
Теперь правильный ответ — в этом конкретном случае запрет устанавливал какой-то штатной приблудой, которая выдает разрешения приложениям и контролирует использование. Андроид 5.vintage
22.04.2017 22:58А как она называется или где её найти?
passerby
24.04.2017 13:51У меня в «шторке» постоянно висит. Называется «Контроль разрешений».
В списке установленных сторонних приложений ее нет.
Есть в запущенных есть, запущена как служба PermControlService.
Повторюсь — отдельно не ставил, было в прошивке.
Zalina
22.04.2017 01:38Антон, а можете прислать модель вашего устройства? Я передам разработке.
passerby
22.04.2017 10:49Если бы конкретная модель телефона имела значение, я бы и не писал даже. Дело в том, что подобное поведение замечено более, чем на одной модели. Ощутимо более.
Но если вам это поможет, то в последний раз ваш навигатор раскалил телефон FLY Octa IQ4511.
Вы же сообщите о результатах, да? Или просто так, из вежливости, спросили?
Plesser
21.04.2017 12:29А Вы случайно не думали написать какое нибудь руководство для обучающихся у вас и доступное всем остальным?
arestov
21.04.2017 14:21Судя по всему под гибридным подходом имеется именно PhoneGap/Cordova. Было бы интересно есть ли реальный опыт использования js + native views например: react native, titanium appcelerator или nativescript. Странно, что обошли эту тему стороной
veged
21.04.2017 17:31такого опыта не так много, т.к. в большинстве случаев мы используем или полностью нативные или html+css+js технологии
serjoga
26.04.2017 07:13+1Обзор не серьезный. Много воды и не о чем.
Сейчас есть проекты crosswalk, wk-webview, ionic2, которые вывели гибридную разработку совсем на другой уровень. (Не вижу упоминания об этом)
А если вам нужна 3д анимация и прочие рил-тайм штучки, пожалуйста, пишите нативный плагин и продолжайте разработку на веб технологиях. Тогда вам не нужно в штат 3 девелопера нативщика. Можно использовать фриланс, аутсорс или 1 адекватного программиста, который напишет нужный плагин когда это потребуется.
veged
26.04.2017 08:58да, вы правы, материал рассчитан на более широкий круг читателей и не содержит многих технических подробностей
crosswalk и ionic2, это конкретные способы разрабатывать на платформе Cordova, а wk-webview подразумевается, в том числе, когда мы говорим о кастомных гибридных архитектурах
подробнее про это и про то, какие части можно делать в виде нативных плагинов, мы говорим на самой Школе Разработки Интерфейсов (https://academy.yandex.ru/events/frontend/shri_msk-2017/)
FluorescentHallucinogen
26.04.2017 17:04На самом деле чистое веб-приложение сейчас не сделать.
Сделать
Веб-вью все равно нужно положить внутрь iOS или Android-приложения, то есть в любом случае нужен контейнер, который написан с помощью Java, Swift или Objective-C.
Не нужен.
Есть такая штука — прогрессивные веб-приложения (progressive web apps, PWA) и WebAPK. Советую почитать, что это такое.
Поэтому на вопрос
Натив или гибрид?
ответ будет — прогрессив.
Есть технологическая возможность сделать интерфейс на веб-технологиях так, чтобы он вел себя по-разному на десктопе и на мобильных, и чтобы мог адаптироваться под них. Но, к сожалению, резиновость некоторых изделий не бесконечна, и та вариативность, в пределах которой может быть эта адаптивность, весьма ограничена.
Так и количество различных зарекомендовавших себя макетов интерфейса (layouts), используемых в современных приложениях, тоже не бесконечно. Есть готовые решения, например: https://polymerelements.github.io/app-layout/
Кроме того, встает вопрос, хотите ли вы трижды рисовать разный дизайн для каждого приложения. Ведь гайдлайны операционных систем сильно отличаются друг от друга, и как лебедь, рак и щука двигаются в разные стороны в мелочах. Если внимательно прочитать гайды Windows Phone, Android и iOS, то окажется, что нужно хорошо продумать, как ваша пользовательская задача будет оптимально решаться на каждой из платформ.
Есть Material Design, который является кроссплатформенным: https://material.io/guidelines/platforms/
Forum3
26.04.2017 17:04Кратко:
— если нужны вычислительные ресурсы = натив
— если отображение текстовой информации + немного графики = гибрид
todoer
26.04.2017 17:05Андроид-разработчикам я бы рекомендовал держаться от любых web view подальше, если не хотите быть заблокированными в Google Play за нарушение Spam provision of the Content Policy:
Do not post an app where the primary functionality is to provide a web view of a website not owned or administered by you (unless you have permission from the website owner/administrator to do so)
И пусть вас не смущает уточнение в скобках — мне известно уже два приложения, заблокированных за показ OAuth-страницы в web view.ad1Dima
27.04.2017 09:34+1И пусть вас не смущает уточнение в скобках — мне известно уже два приложения, заблокированных за показ OAuth-страницы в web view.
Без подробностей, выглядит как вброс. Кого именно заблокировали, с каким комментарием, и т.д.
Гугл последнее время стал пристальное внимание уделять используемым логотипам и брендам: требуют подтверждающего письма что вам разрешили использовать бренд, заказали это приложение.
Don_Eric
а почему не рассматривается кроссплатформенная разработка, а только гибридная на веб технологиях?
Zalina
Это отдельная большая тема. Но рассказать об опыте Яндекса в этом — хорошая идея. Попробуем!