Комментарии 75
Если тенденция сохранится, то веб-приложения и станут новыми нативными, а браузеры превратятся в среду для исполнения JS и рендеринга HTML (или того, что придет им на смену)
Так не произойдёт ни в ближайшее время, ни в обозримом будущем. Вендоры (Apple, Google, Microsoft и др.) всегда будут продвигать свои способы не только оптимизации приложений (из-за которых нативные приложения всегда будут работать на порядок быстрее и экономичнее по отношению к заряду аккумулятора), но и свои способы взаимодействия с пользователем. Последние всегда будут отличаться, и не только из-за ограничений патентов на тот или иной способ, но и потому что каждый вендор будет стремиться реализовать свой собственный уникальный интерфейс, который по их мнению должен быть лучше (не без оснований можно быть уверенным), чем у конкурентов.
В итоге, продвигая свою платформы, вендоры будут всячески тормозить процессы стандартизации и развития браузерных технологий. Такое поведение мы можем наблюдать на примере скорости развития JavaScript (то огромное количество новых возможностей, что в нем появилось за последние 20 лет) и скорости появления новыхкостылей фреймворков, что только подчеркивают всю обреченность такого подхода.
В итоге, продвигая свою платформы, вендоры будут всячески тормозить процессы стандартизации и развития браузерных технологий. Такое поведение мы можем наблюдать на примере скорости развития JavaScript (то огромное количество новых возможностей, что в нем появилось за последние 20 лет) и скорости появления новых
Как раз таки Google активно продвигает идею веб-приложений как замену нативных — прочитайте про Progressive Web Apps.
Просто Google умеет очень хорошо монетизировать веб, но не нативные приложения.
Просто Google умеет очень хорошо монетизировать веб, но не нативные приложения.
А вы почитайте про Instant Apps.
Гугл вообще редко складывает яйца в одну корзину. Кто выиграет в этом соревновании — пока непонятно.
Гугл вообще редко складывает яйца в одну корзину. Кто выиграет в этом соревновании — пока непонятно.
Просто оставлю это здесь https://developers.google.com/web/progressive-web-apps/. Весело получается когда вендор браузера и платформы одно и тоже лицо.
НЛО прилетело и опубликовало эту надпись здесь
Пожалуйста, не надо, я и на десктопе уже вдоволь настрадался с этими тормозящими и жрущими оперативу «веб-приложениями»™, автор теперь хочет чтобы я и на мобильнике страдал?
мы наблюдаем становление ботовИ как обычно игнорируется, что подобные боты существуют ещё с 80-х, я сам их клепал и юзал вместо браузера на мобильнике лет восемь назад будучи ещё школьником. (С музыкой, правда, боты раньше вроде не работали, но всё-таки)
Стараюсь использовать нативные приложения, даже если это просто какой-то вебвью для сайта. Зашёл в плэй, нашёл и установил навсегда. Закладки менее удобны. Что до чат ботов, то даже гуглом и навигацией по целевому сайту обычно быстрее заказать такси или пиццу, не говоря о нативном приложении.
Это всё влажные мечты руководителей компаний, желающих сэкономить на нативной разработке :)
НЛО прилетело и опубликовало эту надпись здесь
Как только требования повышаются (работа с железом, геолокация, нагруженные вычисления, гироскоп, аудовход и проч.),
Фиг с ним с железом, дайте мне хоть что то сделать оффлайн! Этим, кстати, бывает и разработчики нативных приложений грешат, я уж не говорю про браузерные приложения, которые без интернета превращаются в тыкву.
Очень надеюсь что всё будет как раз наоборот. Веб вымрет наконец и останутся нормально написанные нативные приложения заточенные под конкретную платформу, а не фонгапы, ксамарины и прочая кроссплатформенная вебдванольная ерунда.
Что-то я себе не очень представляю безболезненный переход от таких языков как Java(Kotlin) и Swift на JavaScript
Если браузеры принципиально не изменятся сами, то не дай бог…
По своему опыту. Скайп, es проводник, навител, PowerAmp, курсы валют, калькулятор, вайбер, мобайл VoIP, букинг — всё нативное. В браузере, да, бывает — брожу по сайтам. Я, наверно, какой-то неправильный юзер.
Он считает: у многих, кто говорит об этом, есть личная заинтересованность в выживании нативных мобильных приложений.А тех, кто подобные статьи пишет, можно обвинять ровно в том же — они заинтересованы как раз в веб, а так же в основании, на котором можно заказчику оправдать, разработки его проекта как веб-приложения или на каком-то «фонгепе», которое будет тормозить, выедать батарею, греть девайс и полностью зависеть от того, какой браузер и какой версии установлен на смартфоне.
Ладно хоть в ведре теперь в основном хром, а в версиях до лолипопа каждый производитель пихал туда свою реализацию браузера и по этой причине такое приложение могло вовсе не работать и приходилось (или так оно и осталось?) в приложение тянуть еще и браузер свой. Это я еще не говорю за полную ущербность самой системы. На примере андроида: ОС запускает ява-машину, в ней запускает приложение веб-браузер, затем в этом браузере запускается конечное приложение. Это как запускать на компе виртуальную машину, а в ней уже запускать игру и ожидать, что производительность будет хотя бы сравнима с запуском напрямую.
Браузерные/фонгепные аппы в андроиде видно сразу по корявому интерфейсу и тормозам, они всегда ущербные. Пока браузер не станет ОС, такого не будет, а когда станет, то еще придется вытеснить с рынка существующие ОС, иначе повторит судьбу винды.
Пока браузер не станет ОС, такого не будет, а когда станет, то еще придется вытеснить с рынка существующие ОС, иначе повторит судьбу винды.
У Firefox OS не вышло… Хотя система была весьма занятная, по случаю пришлось попробовать ее, когда угрохал свой основной девайс. Немного даже писал под нее, ради интереса… Честно говоря и уходить то не хотелось, но не устроили некоторые характеристики самого девайса.
Движение идёт с двух сторон. Браузер стаёт всё более похож на native (webassembly, webgl), а разработка под native движется в направлении универсальности(Qt/QML,Xamarin,...). В результате не исключено что native и «браузерные» подходы сольются. Представим себе, что Qt/QML приложение (нормальное, с применением C++) можно будет запустить в браузере и это будет нормально работать. Где тогда разница между native и браузером?
Разница между native и браузером в том, откуда берётся код/ресурсы — непосредственно из интернета или в основном с локальных носителей. Интернет никогда не будет так же быстр и надёжен как локальные носители, так что какой-то элемент native всегда будет.
Разница между native и браузером в том, откуда берётся код/ресурсы — непосредственно из интернета или в основном с локальных носителей. Интернет никогда не будет так же быстр и надёжен как локальные носители, так что какой-то элемент native всегда будет.
НЛО прилетело и опубликовало эту надпись здесь
Не знаю в какой вселенной у вас браузер всё больше приближается к нативным приложениям.
Почему у меня экселевский файлик из недавной статьи https://habrahabr.ru/post/320116/ на десктопе открывается и отрисовывается мгновенно и вызывает лишь небольшой всполох на графике загрузки процессора, а если его открыть из онлайн экселя, приходится ждать полторы минуты, пока браузер усердно поедает ОДНО ядро из четырех?
Как была скорость браузеров во всем, что отличается от отображения текста, не выше улитки, так и осталась.
Почему у меня экселевский файлик из недавной статьи https://habrahabr.ru/post/320116/ на десктопе открывается и отрисовывается мгновенно и вызывает лишь небольшой всполох на графике загрузки процессора, а если его открыть из онлайн экселя, приходится ждать полторы минуты, пока браузер усердно поедает ОДНО ядро из четырех?
Как была скорость браузеров во всем, что отличается от отображения текста, не выше улитки, так и осталась.
Где тогда разница между native и браузером?Разница в том, что одно будет выжирать батарейку за час, а другое за два.
Все эти бесконечные слои абстракций современные устройства «перемалывают» неплохо, но чудес ведь не бывыет — если делается дополнительная работа, то требуется больше энергии.
Так что приложения, в которых люди будут зависать часами всегда будут нативными.
P.S. Правда есть и такие нативные приложения, которые жрут больше браузерных (Facebook, например) — но это уже и разряда «сдуру можно и х$й сломать».
одно будет выжирать батарейку за час, а другое за два.с чего бы? Если это так сейчас — не значит, что так будет всегда.
если делается дополнительная работа, то требуется больше энергии.Если. Дополнительная работа не обязательна, тем более не обязательно её выполнять на мобильном устройстве.
Дополнительная работа не обязательна, тем более не обязательно её выполнять на мобильном устройстве.Это, я извиняюсь, как? Web — это по определению ненативный (с точки зрения CPU) код. И кто-то, как бы, должен его транслировать. Эта разница и чисто теоретически никуда деться не может, а практически — разница в лучшем случае в 20-30% обеспечена (это в теории, в будущем, когда webassembly получит популярность), а практически — речь скорее идёт о 3-10 разах сегодня (через asm.js). Причём это очень условно «web-технлогия» — скорее это способ загнать нативный код «в прокрустово ложе web'а». Использование же разнообразных фремворков доводит разницу до десятков раз! При этом в случае с настольным устройствами и даже всякими ноутами это может быть не критично (экран ноута может больше жрать, чем CPU!), то в случае с мобильгиками всё это сразу превращается в «удар по батарейке».
Но на мобильных устройствах нет проблем выдать «настоящий» мобильный код.
Web — это по определению ненативный (с точки зрения CPU) код
Это не так. Сейчас web де-факто ненативный, но нет никаких фундаментальных причин, что бы так было всегда.
Эта разница и чисто теоретически никуда деться не можетМожет, и консорциум крупных игроков уже занялся технической реализацией этой идеи.
Если в вебе будет нативный код, зачем тогда вообще браузер? Запустил на операционке и работай, зачем лишние прослойки, которые сами по себе создают дополнительные сложности? Какие преимущества могут дать браузеры по сравнению с чистой OS? Зачем продираться через тернии прослоек к OpenGL? К другому железу? Если просто собрал, запустил и работает? Я не с целью потроллить, но реально обсудить.
Какие преимущества могут дать браузеры по сравнению с чистой OS? Зачем продираться через тернии прослоек к OpenGL? К другому железу? Если просто собрал, запустил и работает? Я не с целью потроллить, но реально обсудить.Чтобы «два раза не вставать». Операционок типа много, а Web — один. Только нифига это не работает. Web-приложения работают везде — но везде одинаково убого.
Через эти «качели» индустрия регулярно проходит. Когда персональные компьютеры только-только появились тоже подобные попытки были (P-код, SCUMM и т.д. и т.п.), но после появления стандарта (вернее двух: Windows и MacOS) всё это постепенно отошло на второй план.
На рынке мобильных платформ тоже всё давно устаканилось, так что вряд ли сейчас это заинтересует кого-то, кто может разрабатывать нативные вещи на языка типа C/C++/Fortran/etc (а другие с webassembly не работают, JavaScript туда не засунуть).
Если в вебе будет нативный код, зачем тогда вообще браузер?
Я об этом и говорю:
В результате не исключено что native и «браузерные» подходы сольются.
Браузер — это универсальный формат, если аналогичный универсальный формат для нативных приложений удастся внедрить — разницы не будет.
Если аналогичный универсальный формат для нативных приложений удастся внедрить — разницы не будетЭтот поезд уехал очень и очень давно.
Топ-менеджмент, руководящий разработкой браузеров из Apple, Google, Mozilla, и Microsoft категорически против. Не в духе «это несвоевременно», а в духе «только через мой труп».
Я собственно участсовал в попылке продвинуть нечто подобное лет 7 назад. Заявление в духе «открытый Web никогда не будет привязан ни к одной ISA» было произнесено в весьма категоричной форме и за прошедшие 7 лет ничего не изменилось. А если вы готовы ограничиться одним «магазином» (неважно — Chrome Web Store или addons.mozilla.org), то вы немедленно теряете самое главное преимущество: возможность использовать всё это на миллиардах устройств.
Эту организационную проблему, возможно, удастся обойти через webasm. Я вижу следующий механизм: сначала внедряется компилируемый формат webasm, приобретает распространение, но браузеры всё ещё вынуждены компилировать это все либо траслировать (2018-2019). В любом случае скомпилированное представление будет кешироваться. Далее остаётся один шаг — кешировать скомпилированное представление на стороне «веб-сайта» и, соответсвенно, поддержать его загрузку на стороне браузера (2020-?). Всё, native web готов. Такими маленькими шагами шансов на внедрение больше, имхо.
Эту организационную проблему, возможно, удастся обойти через webasm.Собственно webasm и появился как ответ на этот ультиматум.
Далее остаётся один шаг — кешировать скомпилированное представление на стороне «веб-сайта» и, соответсвенно, поддержать его загрузку на стороне браузера (2020-?).Мы всё равно остаёмся с промежуточным, ограниченным, байткодом и по-прежнему не можем использовать даже все возможности CPU (не говоря уже обо всём остальном, что можем нативное приложение).
А также появляется куча проблем с приватностью, безопасностью и прочим (так как раздавать бинарники по-прежнему нельзя, то «сервис компиляции» должен быть предоставляться кем-то ещё).
Всё, native web готов.Неа. Уже 7 лет прошло с момента появления работающего решения — за это время много чего произошло, но главное — разработчики уже давно «забили» на Web и клепают нативные решения.
Тот факт, что ограничение «чисто организационное» не делает его фигнёй. Иные «организационные» решения сложнее изменить, чем своротить горы.
Сейчас web де-факто ненативный, но нет никаких фундаментальных причин, что бы так было всегда.Нежелание разработчиков браузеров это допускать — фундаментальная причина или нет?
Может, и консорциум крупных игроков уже занялся технической реализацией этой идеи.Вы бы хоть первую фразу из статьи, на которую вы ссылаетесь прочитали, а? Низкоуровневый бинарный компилируемый формат — изобретён как раз из-за категорического нежелания допускать нативный код в Web.
Нежелание разработчиков браузеров это допускать — фундаментальная причина или нет?Организационная.
Вы бы хоть первую фразу из статьи, на которую вы ссылаетесь прочитали, а? Низкоуровневый бинарный компилируемый формат — изобретён как раз из-за категорического нежелания допускать нативный код в Web.
Хамства не надо. Низкоуровневый бинарный компилируемый формат — это по сути технический способ сделать универсальный native, чем по сути native web и должен быть. Нужно просто договорится, в каком формате native должен быть описан. На практике, наверное, можно будет даже для разных платформ разный код отдавать, как это сейчас по сути делается под разные браузеры (или аналогично разные версии эппов под разные платформы в магазине приложений). Главное только что бы платформа понимала, что ей отправляют нативный код и как его запускать.
Низкоуровневый бинарный компилируемый формат — это по сути технический способ сделать универсальный nativeНе бывает. Либо у вас native, в том или ином виде, либо у вас бинарная трансляция. Которая требует в разы больше ресурсов. Особенно для использования в виде «запустил, посмотрел, закрыл».
На практике, наверное, можно будет даже для разных платформ разный код отдаватьНельзя. Тут как раз мы упираемся в «несерьёзную» «организационную» проблему, описанную выше. Из-за которой Native Client был ограничен Chrome Web Store (а потом и удавлен ибо только в Chrome Web Store он мало кому нужен). Реакция разработчиков из Mozilla Foundation по уровню истерики напоминала реакцию сторонников Клинтон на инагурацию Трампа.
В результате сегодня Web принудительно загнан в рамки, в которых он гарантированно проигрывает по скорости и энергопотреблению нативным приложениям.
Либо у вас native, в том или ином виде, либо у вас бинарная трансляцияПо-любому появится JIT compilation, а там и до AOT и прекомпилированных объектов рукой подать.
Тут как раз мы упираемся в «несерьёзную» «организационную» проблему, описанную выше.
Думаю, постепенно это решиться само собой.
По-любому появится JIT compilation, а там и до AOT рукой подать.webassembly изначально затачивается под AOT, не в этом дело. AOT никогда не сравнится с нативным кодом просто потому, что железо меняется, а консорциумы, разрабатывающие всё это — отстают. Отстают не на месяцы — на годы.
прекомпилированных объектовА вот этого — не будет.
На основании чего вы так думаете? Посмотрите, чёрт побери, сюда — и обратите внимание на дату! Всё ваши чудеса, о которых вы тут вещаете, уже были реализованы — много лет назад! Удивительное рядом… но оно — запрещено!!!Тут как раз мы упираемся в «несерьёзную» «организационную» проблему, описанную выше.Думаю, постепенно это решиться само собой.
Pазработчикам сказали: «память — поглощать, баратейку — жрать, нативному коду не бывать» — и точка. Усё. То, что было разработано с тех пор даже близко не приближается по степени удобства и эффективности к тому, что было реализовано семь лет назад (скоро уже восемь). Но зато — кроссплатформенность, нету нативного кода, нирванна.
AOT никогда не сравнится с нативным кодом просто потому, что железо меняетсяЧто мешает развитию AOT вместе с железом?
Удивительное рядом… но оно — запрещено!!!
То, что один раз усилиями отдельного игрока не отдалось пропихнуть идею, ещё не значит, что никому и никогда это не удастся. Может быть теперь время пришло.
Что мешает развитию AOT вместе с железом?Грубо? WHATWG. SSE2 — 2001й год, NEON — 2009й, WebAsseembly — 2014й. Задержка — порядка 10 лет. А у нас тут уже всякие новые новые плюшки на походе — которые тоже будет 10 лет стандартизовываться.
То, что один раз усилиями отдельного игрока не отдалось пропихнуть идею, ещё не значит, что никому и никогда это не удастся.Может кому-нибудь в следующем тысячелетии и удастся, но для этого сначала новые игроки должны появиться. Существующим — это не нужно. У Гугла, как я уже сказал, альтернативная технология есть, Apple и Microsoft — всячески стараются загнать всех в свои магазины, а Mozilla — вечный «борец за чистоту Web'а». И? Кто остался? Кто будет вашу идею пропихивать и, главное, зачем?
Может быть теперь время пришло.Наоборот. Время уже почти ушло. Приход смартфонов Web-технологии уже просрали, теперь осталось дождаться пока Android придёт на десктоп — и всё: смысла во всех этих прослойках не будет снова.
Самой популярной операционной системой в мире всегда будет веб
ВНЕЗАПНО
Мы тоже согласны с этой точной зрения. Например весь наш проект (PushAll) задумывался с той лишь целью, чтобы можно было не городить приложение чисто ради пушей, т.к. 90% всего плейстора это веб-вью + пуши. Если отделить пуши в отдельное приложение и предоставить их в любом удобном для пользователя виде на любой платформе, то мы получаем, что пользователь может кликать по пушу и попадать на сайт, хорошо адаптированный для мобильного устройства, или кликнув на компьютере — для ПК. Иначе сейчас имеем например ситуацию, когда есть инстаграм, у которого из поддержки только мобилки, растянутое на айпаде и нет возможности управлять всем с компьютера, даже нормально смотреть кто тебе что там поставил. Многие компании пилят чисто приложения — и с компьютера они недоступны, и все это под фразы, что компьютером сейчас никто не пользуется.
Соглашусь с вами. Сейчас делаю небольшой сервис, который хорошо работает в браузере, но единственное что надо, это пуши пользователям. Хотел уже завернуть все это дело в phonegap и сделать пуши, но вспомнил про одного вашего конкурента, пробую юзать сторонний сервис. Единственное, что — устанавливать стороннее приложение и там регистрироваться, немного сложновато для некоторых пользователей.
А про какого конкурента? Не знаю ни одного который бы поддерживал и веб-пуши и мобильные уведомления на Android, iOS плюс у нас и телерам бот есть.
И у нас нет регистрации — точнее есть вход через гугл аккаунт в один клик, и опционально есть рега, но ей пользуется менее 1% человек
И у нас нет регистрации — точнее есть вход через гугл аккаунт в один клик, и опционально есть рега, но ей пользуется менее 1% человек
Pushbullet — есть все, кроме telegram бота. Так же вход через аккаунт гугла. Возможности у вас похожи, я смотрел вас тоже, но не только на российскую аудиторию хочу ориентироваться.
Так пока да :) к слову можно и то и то брать. К слову у пушбулета вроде как веб пушей нет. У них именно расширение только под браузеры. Плюс приложение перегружено. И там разве можно выборочно отправлять уведомления отдельным пользователям канала или списку людей из канала? У них вроде каналы всегда на всех идет рассылка.
Мы сделаем поддержку английского на всем сайте в течении пары месяцев скорее всего.
Пушбулет сильно не из той оперы. У них таки сервис для шаринга пушей с телефона на комп. Каналы это отдельная функция дополнительная.
Мы сделаем поддержку английского на всем сайте в течении пары месяцев скорее всего.
Пушбулет сильно не из той оперы. У них таки сервис для шаринга пушей с телефона на комп. Каналы это отдельная функция дополнительная.
Мне нравится его уровень концептуализации. Боты — это новые закладки. Но, на самом деле, если так рассуждать, то нативные приложения — это ни что иное, как толстые закладки. Боты — тонкие, а приложения — толстые. Вообще всё, что как-то работает с вебом, — это в каком-то смысле закладки. Просто сам веб устроен таким образом, что в нём нельзя сделать ничего концептуально иного, кроме ресурсов и закладок на эти ресурсы. Можно лишь по-разному распределять функциональность. Если оттянуть большую часть в сторону веб-ресурса, то получится связка ресурс + тонкая закладка (текстовый бот/приложение в браузере). Если же оттянуть значительную часть функционала в сторону клиента, то получится связка ресурс + толстая закладка, называемая нативным приложением.
Хм… Беда в том, что если у вас не супер-пупер-дупер офигенная команда и куча денег на разработку — то browser-like приложение будет кривым недобраузером.
Характерный пример — приложение aliexpress, в котором даже табов (чуть ли не основной функционал для современного браузера) нет. И осовная польза от него — скидки за заказ в мобильном приложении. Найти товар на сайте и заказать через приложение — оригинально-с.
Так что если ваше приложение построено вокруг webview — это повод задуматься, нужно ли оно вообще.
Более того, даже если у вас супер-пупер-дупер офигенная команда и куча денег на разработку, то приложение всё равно будет голимым куском говна. Характерный пример — приложение Youtube. Если я при просмотре ленты добавляю какое-нибудь видео в список "Посмотреть позже", а затем перехожу на экран, где этот список отображается, то это видео, только что добавленное через соседний экран, я в этом списке вот так вот сразу не вижу. Чтобы его увидеть, мне нужно вручную сделать рефреш.
«Средний американец скачивает 0 приложений в месяц» — вы уверены?
Во-первых: «Most smartphone users download zero apps per month» переводится на русский не как «средний пользователь смартфона скачивает 0 приложений в месяц», а как «большинство пользователей смартфонов скачивает 0 приложений в месяц».
При этом среднее число установок в расчёте на 100 пользователей составляет примерно 110 (1 приложение — 8,4%, 2 приложения — 8,9%, 3 приложения — 6,2%, 4 приложения — 3,7%, от 5 до 7 приложений (берём среднее, 6) — 4,8%, 8 и более приложений (закрываем интервал по аналогии с соседним, то есть предполагаем, что этот интервал — от 8 до 10 приложений в месяц, и берём его середину — 9) — 2,4%. В итоге, перемножив число приложений на проценты, получаем 110 приложений, которые приходятся на 100 пользователей смартфонов, или в среднем — 1,1 приложение в месяц).
То есть по-настоящему «средний» пользователь смартфона всё-таки скачивает по одному приложению в месяц! И, кстати, вот что на том сайте пишут (немного вольный перевод с помощью гугля):
Что привело к сокращению числа скачиваний? На мой взгляд, прежде всего — падение интереса ко всему новому. Приложения, конечно, обладают некоторой новизной, но их объединяет нечто большее — платформа, и раз уж пользователь знаком с платформой, принципами её работы и основными параметрами приложений, создаваемых для этой платформу, он сделает вполне логичный вывод, что и остальные приложения от известных ему не сильно отличаются. То есть, впервые купив себе телефон с андроидом, человек может скачать сотню однотипных программ (ну, например, фоторедакторов), однако в какой-то момент он достигает состояния насыщения, становится гораздо более разборчив, а следовательно — перестаёт бездумно устанавливать программы по пачке в день (и действительно, те 2/3 респондентов, которые заявили, что в среднем устанавливают в месяц 0 программ, вполне себе могут устанавливать программы — просто не чаще 1 программы в 2-3 месяца… вы себе на компьютере чаще программы новые устанавливаете?).
Первый телефон на андроиде появился у меня лет эдак 6 назад. Сегодня моему рабочему смартфону 3 года, он пережил 2 замены аккумуляторов (живут как раз в районе года, потом начинают греться и терять ёмкость) и штуки три — переустановки системы. Сколько приложений я скачал за 3 года жизни последнего моего смартфона — ну, может, штук 100, не больше. Причём как скачивал — когда купил телефон три года назад, закачал всё, что хотел (на 6 или 7 экранов по 20 иконок, причём это — с нативными приложениями — специально их сейчас пересчитал, оказалось немногим больше 40 штук), а перед переустановками андроида просто чистил список оставляемого софта (сначала в топку полетели не понравившиеся приложения, потом — игрушки, под конец — то, что не использую, а устанавливал — чтобы посмотреть, что это за оно).
Сегодня я придерживаюсь стратегии минимализма: всё, чем не пользуюсь, стараюсь удалить или отключить. После крупных „удалялок“ софта делаю хард ресет, чтобы „накатить“ чистую систему, и уже поверх неё — нужные мне приложения. Результат — смартфон живёт, здравствует (и, надеюсь, будет продолжать меня радовать своей работой ещё пару-тройку лет). Да, бывает, раз в 3-5 месяцев я узнаю про какую-то программу, которая может оказаться полезной мне — устанавливаю, тестирую, а потом — решаю, оставлять или нет после очередного хард-резета…
Кстати, я свой смартфон в ближайшее время менять не собираюсь — по своим параметрам модель будет давать фору многим собратьям среднего ценового сегмента ещё пару лет как минимум… Конечно, смартфон „держит заряд“ только один день, телефонные разговоры не записывает (для телефонного общения ведь можно и простую „трубку“ купить, верно? и заряд она будет держать не часы, а недели), но от него это и не требуется…
Во-первых: «Most smartphone users download zero apps per month» переводится на русский не как «средний пользователь смартфона скачивает 0 приложений в месяц», а как «большинство пользователей смартфонов скачивает 0 приложений в месяц».
При этом среднее число установок в расчёте на 100 пользователей составляет примерно 110 (1 приложение — 8,4%, 2 приложения — 8,9%, 3 приложения — 6,2%, 4 приложения — 3,7%, от 5 до 7 приложений (берём среднее, 6) — 4,8%, 8 и более приложений (закрываем интервал по аналогии с соседним, то есть предполагаем, что этот интервал — от 8 до 10 приложений в месяц, и берём его середину — 9) — 2,4%. В итоге, перемножив число приложений на проценты, получаем 110 приложений, которые приходятся на 100 пользователей смартфонов, или в среднем — 1,1 приложение в месяц).
То есть по-настоящему «средний» пользователь смартфона всё-таки скачивает по одному приложению в месяц! И, кстати, вот что на том сайте пишут (немного вольный перевод с помощью гугля):
«Это не значит, что приложения не являются полезными, просто более половины американских пользователей смартфонов (по данным ComScore) работают с приложениями каждый день. И это не вызвано тем, что они слишком дороги: большинство приложений являются бесплатными, а цены на приложения, как известно, начали соревноваться в гонке на понижение сразу после того, как App Store дебютировал. Так в чем же дело? Одним из возможных объяснений этого является то, что людям просто не нужно множество приложений, а приложения, которые уже у людей есть, подходят для большинства функций. Почти все владельцы смартфонов используют приложения, и „ошеломляющие 42% всего времени, потраченного на приложения смартфона, происходит в работе с одним, наиболее часто используемым приложением“, сообщает ComScore. Новые приложения приходят и уходят, особенно игры, но, возможно, прорывные приложения будут все более редкими. Посмотрите на топ-25 наиболее часто используемых приложений: в основном это зрелые компании, такие как Facebook, Google, Pandora и Yahoo.
Другой вероятной причиной является то, что всё ещё нелегко найти и загрузить новые приложения. App Store от Apple получил критику за свои негодные функции обнаружения, заставляющие пользователей в значительной степени полагаться на топ-25 списков, плохой поисковой системы, а также несколько функций редактирования. В основном, это помогает богатым становятся богаче, и затрудняет новым умным приложениям сделать так, чтобы их заметили. Apple имеет право гордиться своим приложением по установке программ — это было одним из самых важных изобретений в истории программного обеспечения, и Google сделал приличную работу копирования. Но есть, конечно, место для совершенствования.
Что привело к сокращению числа скачиваний? На мой взгляд, прежде всего — падение интереса ко всему новому. Приложения, конечно, обладают некоторой новизной, но их объединяет нечто большее — платформа, и раз уж пользователь знаком с платформой, принципами её работы и основными параметрами приложений, создаваемых для этой платформу, он сделает вполне логичный вывод, что и остальные приложения от известных ему не сильно отличаются. То есть, впервые купив себе телефон с андроидом, человек может скачать сотню однотипных программ (ну, например, фоторедакторов), однако в какой-то момент он достигает состояния насыщения, становится гораздо более разборчив, а следовательно — перестаёт бездумно устанавливать программы по пачке в день (и действительно, те 2/3 респондентов, которые заявили, что в среднем устанавливают в месяц 0 программ, вполне себе могут устанавливать программы — просто не чаще 1 программы в 2-3 месяца… вы себе на компьютере чаще программы новые устанавливаете?).
Первый телефон на андроиде появился у меня лет эдак 6 назад. Сегодня моему рабочему смартфону 3 года, он пережил 2 замены аккумуляторов (живут как раз в районе года, потом начинают греться и терять ёмкость) и штуки три — переустановки системы. Сколько приложений я скачал за 3 года жизни последнего моего смартфона — ну, может, штук 100, не больше. Причём как скачивал — когда купил телефон три года назад, закачал всё, что хотел (на 6 или 7 экранов по 20 иконок, причём это — с нативными приложениями — специально их сейчас пересчитал, оказалось немногим больше 40 штук), а перед переустановками андроида просто чистил список оставляемого софта (сначала в топку полетели не понравившиеся приложения, потом — игрушки, под конец — то, что не использую, а устанавливал — чтобы посмотреть, что это за оно).
Сегодня я придерживаюсь стратегии минимализма: всё, чем не пользуюсь, стараюсь удалить или отключить. После крупных „удалялок“ софта делаю хард ресет, чтобы „накатить“ чистую систему, и уже поверх неё — нужные мне приложения. Результат — смартфон живёт, здравствует (и, надеюсь, будет продолжать меня радовать своей работой ещё пару-тройку лет). Да, бывает, раз в 3-5 месяцев я узнаю про какую-то программу, которая может оказаться полезной мне — устанавливаю, тестирую, а потом — решаю, оставлять или нет после очередного хард-резета…
Кстати, я свой смартфон в ближайшее время менять не собираюсь — по своим параметрам модель будет давать фору многим собратьям среднего ценового сегмента ещё пару лет как минимум… Конечно, смартфон „держит заряд“ только один день, телефонные разговоры не записывает (для телефонного общения ведь можно и простую „трубку“ купить, верно? и заряд она будет держать не часы, а недели), но от него это и не требуется…
Вот как раз одна из ключевых проблем нативных приложений: если сходить на 100 сайтов, то система медленнее работать не станет, а если установить для «попробовать» 100 приложений, то падение производительности может быть существенным. Каждое нативное приложение несёт в себе рекламный или следящий модуль, которому очень хочется всё знать, все они подписываются на всевозможные события, при подключении к сети дружно начинают ломиться, чтобы отдать статистику, обновить данные и т.п. По крайней мере, для андроида 4-х это так. Средний пользователь никогда не будет делать полных сбросов к заводским настройкам, он будет страдать от тормозов, а потом купит новый аппарат, и на него устанавливать будет уже по-минимуму, тем более, что ключевые социальные сети обычно предустановлены.
Судя по данным в этой же статье, по сто приложений уже давно никто не устанавливает. Поэтому проблема надумана.
Возможно, неудобства, связанные с установкой, являются одной из причин того (хоть и не главной). Когда установка как таковая станет процессом размытым, легковесным и скрытым от глаз пользователя, похожим на посещение сайта, есть шанс, что приложения будут запускать чаще. Так, бытует мнение, что средний пользователь посещает как раз порядка 100 сайтов в месяц.
Главная причина, думаю, всё таки в том, что пользователю редко нужно множество похожих программ. По своему опыту и моих знакомых — это один браузер, один навигатор, один калькулятор, один (максимум — несколько) текстовых редакторов. Если телефон используется геймером — ну может пяток игрушек. Сайты всё таки намного более разнообразны, чем программы, в сотню сайтов в месяц верю. В сотню программ — нет :)
НЛО прилетело и опубликовало эту надпись здесь
Коллеги, честно, уровень знаний многих из вас реально зашкаливает. Это не сарказм и не наезд. Приятно читать было. НО НО НО вы забываете одну простую вещь — сегментация рынка была есть и будет.
Какие бы технические преимущества не имели нативные апы… они не нужны в массовом бизнесу… они нужны для закрытия специализированных задач, бесспорно… а вот для закрытия самых простых задач — мобильного обслуживания своего конечного потребителя, они бизнесу не нужны… и для массового круга других вопросов тоже… Тут выше кто то сказал — что мол наконец бизнес начинает понимать, что за нативные апы надо платить больше. Да не начал он это понимать, потому что НЕ нужно это бизнесу — платить больше, я вам как основатель двух работающих самостоятельно и владелец еще одной нетехнологических компаний говорю. Всегда искал и буду искать способ платить меньше или вообще не платить, чтобы закрыть ту проблему которая у меня есть, а не запустить ракету в космос, где все четыре ядра будут загружены и батарея будет в два раза дольше жить… бла бла бла :) ну честно :)…
Поэтому мой третий стартап, то есть текущий, и уже технологический — Mobsted Inc, занимается почти два года уже законченной платформой для решения именно этой проблемы. Клиенты вроде бы и хотят получать сервис с экрана на ладони, но качать, ставить и регаться не хотят. Бизнес вроде бы и хочет "обслуживать" клиентов со смартфона, но стоимости разработки и поддержки ТУПО НЕОКУПАЕМЫ даже для компаний с оборотом 10-20-30+ млн рублей в месяц и даже с 200+ оборотом есть несколько клиентов которые это поняли и ушли на нас! И вот об этот простой факт все технические аргументы просто, извините, но в хлам ломаются.
НО НО НО вы забываете одну простую вещь — сегментация рынка была есть и будет.Авторы обсуждаемой тут статьи тоже об этом забывают.
Всегда искал и буду искать способ платить меньше или вообще не платить, чтобы закрыть ту проблему которая у меня есть, а не запустить ракету в космос, где все четыре ядра будут загружены и батарея будет в два раза дольше жить… бла бла бла :)Это зависит от бизнеса, сошласитесь? Если мой банк-клиент будет работать в 10 раз дольше и жрать батареи в 10 раз больше — я вполне переживу. Это ж мой телефон на целых 10 минут в неделю меньше проработает — это не проблема ни разу. А вот если у меня будет в 2 раз дольше работать приложение, с которым я работаю постоянно (да госсподи… читалка книг какая-нибудь), то я поищу что-нибудь другое.
Подавляющему большинства бизнеса не нужны программы, с которыми пользователь будет работать часами — тут вы правы. Но утверждать на этом основании, что нативные приложения умрут… Два платформы, где они были запрещены… BlackBerry и Windows Phone 7 — не подскажете, где они?
Это зависит от бизнеса, сошласитесь?
Да, 100% зависит от бизнеса. Я и говорю — не нужны массовому бизнесу. Я и не утверждаю что они вымрут, все равно будут кейсы где либо к железу нужен доступ, либо например к контактам очень нужен (это даже chrome на ведре не дает сейчас, что нам например рушит часть кейсов для PWA). Речь о том что, золотой век апов завершился
Два платформы, где они были запрещены… BlackBerry и Windows Phone 7 — не подскажете, где они?
Не согласен с примером! (1) BB просто очень долго держались за свой BBM, а приложения можно было еще и на Symbian ставить, что я и делал, и где они? Там другие совершенно причины провала. (2) история себя не всегда повторяет, и с ростом мобильных скоростей и возможностей браузера причиной очередной "бизнес ошибки" уже может быть не тупость человеческая, а чистый технологический distrupt, каким бы заезженным в стартаперских кругах не был этот термин.
BB просто очень долго держались за свой BBM, а приложения можно было еще и на Symbian ставить, что я и делал, и где они?Уничтожены по воле владельца вместе с компанией. Ещё в 2010м у Symbian'а было почти 50 процентов рынка, но его убили как раз в угоду Windows Phone 7.
с ростом мобильных скоростей и возможностей браузера причиной очередной «бизнес ошибки» уже может быть не тупость человеческая, а чистый технологический distrupt, каким бы заезженным в стартаперских кругах не был этот термин.Теоретически — не исключено. А практически — попытки внедрить платформы без поддержки нативного кода продолжаются уже не первое десятилетие и на том погорели уже много компаний, а успеха всё нет. Поддержка всяких интерпретаторой и JITов — хорошо, невозможность использовать BLAS == смерть платформе.
а вот для закрытия самых простых задач — мобильного обслуживания своего конечного потребителя, они бизнесу не нужны…
Бизнесу не нужны лояльные клиенты? Например, службе такси не нужен клиент, который будет запускать приложение "*Такси", а не гуглить «такси» и переходить на первый попавшийся сайт?
Когда речь идет о PWA приложениях, то есть обеспечивается повторяемость входа (это один из принципов progressive), то я считаю что не нужны. Ну и плюс (1) лояльность клиента не достигается ОДНИМ фактором, и апы это микро способ способ поднять лояльность и это не есть точка продаж для апа имхо,… мы пока сталкиваемся только с вопросами типа — что я могу сэкономить — от не тратить бумагу и время до быстрее получать оплаты (2) статистика говорит, что уровень отказа 95% в среднем после установки и первого запуска. Причины разные, от клиент забыл где оно и как оно, до не понравилось — то есть — воронка продаж и до установки то тяжелая, а после дак вообще ахтунг… вспомните недавно Волож младший — как не бились, не более 10% выручки из апов, а косты не адекватные, и тоже ушел на web apps.
Я не понимаю людей, которые категорично занимают определенную сторону в вопросе и рассматривают все с одной стороны. Какое приложение нужно, можно выявить только исходя из политики, сферы деятельности вашей организации(организациям одной сферы деятельности вообще могут понадобится разные виды приложения), учитывая, что я занимаюсь нативной разработкой под Android и iOS, понимаю, что не всегда у организации есть средства на такую разработку(т.к. порой она обходится в несколько раз дороже), либо она вовсе им ненужна, в некоторых случаях вполне подойдет kordova, xamarin и прочие технологии. Бывают моменты, когда приложение лучше не делать вообще, чем сделать его не нативным, приложения в которых важна высокая скорость, четкость и плавность анимации, надежность, устойчивость к высоким нагрузкам, все то, что не могут дать кросплатформенные, браузерные аналоги. И вообще в последнее время чувствуется тенденция перехода работы с приложениями через помощники(google assistant, siri и т.д.)
Можно вспомнить того же Цукерберга (согласитесь, далеко не последний человек и компания в IT):
Цукерберг признал ошибочность использования HTML5 в мобильных клиентах Facebook
В ходе общения с Майклом Аррингтоном (Michael Arrington) на конференции TechCrunch Disrupt глава Facebook Марк Цукерберг (Mark Zuckerberg) признал, что его компания совершила немало ошибок. Одной из самых серьезных в последнее время оказалось решение использовать HTML5 на мобильных платформах, сообщает The Verge.
В рамках интервью с основателем самой популярной в мире социальной сети речь шла о применении HTML5 вместо родного кода для мобильных платформ. Результатом этого была очень нестабильная и неэффективная работа клиентов Facebook для iOS и Android. Фактически, по словам Цукерберга, компания потеряла впустую два года, пытаясь довести до ума HTML5-версии своих мобильных программ.
Позиция ровно такая же — нативный нужны ровно тогда когда они нужны. Нагрузки такие как FB или мессенджеры, это естественный выбор. Апы для банков, ну как бы нууууу, как бы ну ладно, разве что ради безопасности. Но например, сфера ЖКХ, автосалоны, медицина, обучающие центры, да и апы для собственных сотрудников компаний наконец? Логичней, быстрее и дешевле сделать progressive web? Разе нет? И даже вопросы "работает оффлайн" решаются! Как я сказал ранее — сегментация работает всегда. Рынок "мобильных взаимодействий между бизнесом и потребителем" фактически значительно больше чем то, что имеет экономический смысл окучивать именно нативом.
Когда речь идет о PWA приложениях, то есть обеспечивается повторяемость входа (это один из принципов progressive), то я считаю что не нужны.
Не понимаю фразы. Бизнесу не нужна повторяемость входа? Или нужна, но он больше доверяет SEO, а не списку приложений на девайсе пользователя?
В контексте имелось ввиду обратное — НУЖНА — ОЧЕНЬ НУЖНА — и имелось ввиду, что PWA уже обеспечивает повторяемость входа, поэтому нативно не факт что нужно. SEO остается как раз как минимально надежный, но не исключаемый вариант. Плюсом еще "боты это новые закладки" еще и расширяет георгафию мест где бизнес может быть в телефоне у клиента. Но не сам бот конечно, это ИМХО порно полное, слишком должно занимает решение вопроса ( вот тут об этом очень просто и от человека который точно знает — http://dangrover.com/blog/2016/04/20/bots-wont-replace-apps.html ). Но как канал присутствия и входа в апп боты хорошо воспринимаются бизнесом, по крайней мере в Штатах и в Африке, где у нас пока самые большие внедрения Mobsted сделаны.
Кажется непонимание раньше возникло. В контексте этого поста я не делаю различия между PWA и нативными приложениями, и то, и другое, приложения, которые пользователь устанавливает себе на телефон, а не сайт/приложение, которые он открывает в браузере. Что под капотом у PWA тот же браузер, а то и тот же сайт, что пользователь может нагуглить, это уже к вопросу «какое приложение мы делаем для наших пользователей» после положительного ответа на вопрос «делаем ли мы нашим пользователям мобильное приложение или им достаточно будет нашего сайта?»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Будущее мобайла — не приложения, а браузеры