Что такое «Нативное приложение»?
JavaScript?! Как Phonegap? Не, я лучше сделаю нативное приложение.
Приложения на Titanium – это не сайты, которые чудесным образом обернуты в приложения.
Что ты имеешь в виду под «Нативной» разработкой?
А что делает приложение нативным?
Что такое хороший User Experience?
Выглядит и ведет себя ожидаемо
iOS, Android и Windows имеют различные требования к дизайну (iOS, Android,Windows) и если вы опираетесь на них, ваше приложение более предсказуемо и следовательно, проще в использовании.
Отличный пример – TabGroups. На Андроиде они, как правило, встроены в Action Bar и будут прокручиваться если их много. На iOS Tab Bar расположен внизу и если у вас больше пяти табов, то пятый будет вести на экран выбора нужного таба. На Windows Pivot Tabs работают почти как на Андроиде, но выглядят немного по-другому, они не являются частью Command Bar, который расположен внизу экрана. 
Так что технология, которая используется для разработки нативного приложения, не должна иметь собственные UI контролы, вместо этого она должна использовать те, которые предоставлены платформой.
В Titanium есть кросс-платформенные API почти для всего, и он всегда переводит их в платформенные UI-компоненты. Например, Ti.UI.TabGroup даст вам результат как на картинке выше, но напишете вы при этом один код (Alloy):
Для тех API, которые представлены не во всех платформах, мы используем пространства имен, например, Ti.UI.Android.CardView.
Единство API там, где это возможно, платформо-зависимые API – там, где нет. Всегда с уважением к целевой платформе.
Будущее мобайла — не приложения, а браузеры
В дискуссиях о будущем мобайла постоянно звучит тезис о том, что «в конце концов останутся только мобильные приложения под iOS или Android». Старший менеджер по продукту в Intercom Хью Даркин решил с этим поспорить. Он считает: у многих, кто говорит об этом, есть личная заинтересованность в выживании нативных мобильных приложений.
Заявления о том, что будущее принадлежит нативным мобильным приложениям, игнорируют тот факт, что браузеры и веб быстро становятся мобильной операционной системой будущего, а нативные приложения медленно вымирают.
Нативные приложения хороши, но не для всего
Безусловно, нативные приложения прекрасно подходят для определенных вещей. Например, для частых интенсивных задач вроде общения с друзьями, семьей и коллегами — того, что мы делаем каждый день множество раз. Таким приложениям, как Snapchat, WhatsApp, Facebook Messenger, нужен доступ к камерам, микрофонам и непосредственно к операционной системе. В этом случае создание нативных приложений под iOS и Android имеет смысл.
Но нужна ли на самом деле нативная установка любым другим типам приложений? Мобильный веб и сегодняшние браузеры могут легко справиться почти со всем, что нам может понадобиться. Давайте не забывать о том, что нативные мобильные приложения были временным решением для краткосрочных проблем с подключением. В мире с 4G и повсеместным Wi-Fi этих проблем больше нет.
Благодаря развитию возможностей и стандартов мобильного веба такие компании, как Patagonia, уже попрощались со своими нативными мобильными приложениями.
— Adam Kmiec (@adamkmiec) June 1, 2016
What was that about websites being irrelevant and this being an app only future?
Время прощаться.
–––––
Спасибо за поддержку приложения Patagonia для iPhone. Теперь наш сайт красив и удобен в любом мобильном браузере, а это приложение мы больше не поддерживаем — можете удалить его со своего устройства.
*
Адам Кмеч @adamkmiec
Кто там говорил, что сайты неуместны и будущее исключительно за приложениями?
Мы проводим в мобильных браузерах больше времени, чем кажется
От нативных приложений отказываются не только компании: сегодняшний средний американец скачивает ноль приложений в месяц. Это мало связано с тем, сколько времени мы проводим со своими смартфонами — сопоставьте эту усталость от приложений с количеством времени, которое мы проводим в браузерах.
Всем знакомы Firefox, Chrome, Safari и Internet Explorer — «традиционные» браузеры с адресной строкой, поисковой функциональностью и кнопками перехода вперед и назад. Но это не единственные браузеры, которыми мы пользуемся каждый день.
Мы проводим все больше времени в мессенджерах и социальных сетях, которые сами являются оболочками для мобильного веба. На самом деле они — браузеры. И эти браузеры дают нам тот социальный контекст и те связи, к которым мы стремимся, но которых не дают традиционные браузеры.
Например, Facebook — наш браузер для социального веба. Он упрощает просмотр и поиск друзей, компаний и потенциально интересного для нас контента. Не мы «вытягиваем» контент традиционными браузерами, а Facebook «доставляет» нам контент, исходя из наших интересов и интересов наших друзей. Обратите также внимание на ряд эстетических перемен: например, несколько новых особенностей приложения Facebook для iOS, которые приближают его к настоящему браузеру.
У встроенного в приложение Facebook браузера есть кнопки перехода вперед и назад, он также позволяет делать закладки и вводить свой URL.
Тогда как Slack — это наш браузер для работы. Он упрощает поиск документов, обсуждений и данных. В прошлом нам приходилось запрашивать необходимые сведения у своих коллег, при этом мы просто упускали ту информацию, которая могла бы пригодиться, но мы ничего не знали о ней. Сегодня наши коллеги «доставляют» нам документы и обновления с помощью браузеров вроде Slack, что делает наши рабочие будни проще и согласованнее.
WhatsApp — наш браузер для близких друзей. Будь то общение один на один или в маленьких группах, мы просматриваем и потребляем персонализированный контент от ближайших друзей, которые «доставляют» его нам. Мы доверяем их рекомендациям — это самый персонализированный способ просматривать веб.
Перечисленные мессенджеры — все нативные приложения, конечно. Но критично то, что они включают новые функции, заменяющие действия, которые раньше выполнялись в других нативных приложениях или где-то еще. Они предлагают головокружительный набор возможностей на основе миллионов умных интеграций с продуктами сторонних разработчиков программного обеспечения, и всякая необходимость покидать этот новый тип браузеров практически исчезает.
На самом деле эти социальные браузеры настолько успешны, что нам достаточно всего трех, чтобы находить и потреблять весь нужный нам контент. Неудивительно, что Facebook, Google и многие другие ставят на это. Если вы владеете браузером, вы владеете аудиторией.
Время, проведенное в приложениях, которыми пользуется средний американец
Номер в рейтинге / Время в приложении относительно общего времени со смартфоном
Согласно comScore, 50% времени пользователи проводят в одном самом используемом приложении и почти 80% времени — в трех самых используемых
Боты — новый способ просмотра
Самое увлекательное в этих новых браузерах то, как много всего в них до сих пор меняется.
Закладки были в основе операционных систем с 1990-х — в виде иконок на рабочем столе и стартовых меню. По мере того, как мы стали проводить больше времени в традиционных браузерах, мы стали полагаться на новый тип закладок. Мы сохраняли адреса веб-страниц и доменные имена. Мы устанавливали панели инструментов для доступа к сервисам вроде MSN News, поиска Google, почты Yahoo! Mail. Мы собственноручно отбирали контент для себя.
Что касается мобильных технологий, мы наблюдаем становление ботов как нового типа динамических закладок для мобильных браузеров. Вместо того, чтобы каждый раз набирать в адресной строке URL и ждать загрузки контента, мы используем ботов, способных доставлять контент тогда, когда он нам нужен. Они могут подстроиться под наше взаимодействие с контентом и со временем подавать все более подходящий для нас. Они отбирают контент для нас.
Например, опция music в мессенджере Telegram: бот использует встроенную панель управления, которая позволяет вам находить и слушать музыку, даже не отправляя никаких сообщений. А также обновляет свои собственные сообщения на лету по мере вашего продвижения по результатам поиска.
Так что вам не понадобится а) устанавливать отдельное нативное мобильное приложение (типа Spotify) или б) искать музыку в браузере вроде Chrome: вместо этого боты смогут обеспечить любые нужды пользователя, — зарезервировать столик в ресторане или купить что-нибудь, — в пределах социального приложения или мессенджера.

Со временем боты станут для нас способом сохранять свои интересы и варианты поведения. Доставляемый нам контент подразумевает действия. Мы можем бронировать и покупать что-то. Мы можем что-то читать. Отбор всего этого будут определять сети наших близких друзей и искусственный интеллект.
Что это значит для завтрашних стартапов
Самой популярной операционной системой в мире всегда будет веб — не iOS или Android. Важно, чтобы следующее поколение производителей программного обеспечения не ограничивалось созданием только нативных версий веб-приложений под iOS и Android.
Просто обеспечьте, чтобы веб-приложения хорошо выглядели и работали в новом типе мобильных браузеров — мессенджерах. Не создавайте под iOS или Android только ради мнимых возможностей распространения. Распространять надо там, где люди проводят большую часть своего времени: в социальных приложениях и мессенджерах — новых мобильных браузерах оснащенного ботами мира.
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией приложений, игр и сайтов на 60 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
Нативные приложения обречены (часть 1)
Отныне я не буду больше создавать нативные приложения. Все мои приложения в дальнейшем будут прогрессивными веб-приложениями (PWA, Progressive Web Apps). Это такие приложения, которые предназначены для еще более органичной работы на мобильных устройствах, чем нативные приложения.
Что я имею ввиду под «более органичной работой»? Большая часть веб-траффика исходит от мобильных устройств и пользователи устанавливают в среднем от 0 до 3 новых приложений в месяц. Это означает, что люди не тратят много времени на поиск новых приложений в App store, но они проводят много времени в сети, где могут найти и использовать ваше приложение.
Прогрессивные веб-приложения начинают свою работу как любое другое веб-приложение, но когда пользователь возвращается в приложение и показывает (фактом использования), что он заинтересован в более регулярном обращении к приложению, браузеры предложат пользователю установить приложение на свой домашний экран. PWA также могут использовать push-уведомления как и нативные приложения.
Компании EDISON разрабатывает и нативные мобильные приложения, но мы делаем это прогрессивно 😉
Вот здесь можно поглядеть наше портфолио мобильных приложений под iOS.
Разумеется, для тех же проектов реализуем и мобильные приложения на Android.
И тут-то начинается интересная часть. Как и любое нативное приложение, прогрессивное веб-приложение будет обладать собственной иконкой для домашнего экрана и когда вы нажимаете на нее приложение запускается без оболочки браузера Chrome. Это означает отсутствие адресной строки и кнопок навигации. Только обычная строка состояния телефона и ваше приложение во всем своем почти полноэкранном великолепии.
К этому уже давно шло. Ни одна из технологий не является особо новой, за примечательным исключением развивающегося кросс-платформенного стандарта.
Немного истории
На заре iPhone не существовало app store. Стив Джобс хотел, чтобы разработчики создавали приложения для iPhone, используя стандартные веб-технологии.
Иногда мечтатели правы, но они на 10 лет опережают свое время. Оглядываясь назад на 2 года, рекомендация Стива Джобса о создании веб-приложений для iPhone была названа журналом Forbes его “крупнейшей ошибкой”, поскольку нативные приложения приобрели сокрушительный успех.
Сегодня, оглядываясь назад, кажется очевидным, что он действительно что-то нащупал, но только далеко впереди возможностей существующий веб-стандартов того времени.
Сейчас десятилетие спустя, мобильные веб-стандарты поддерживают многие функции, которые были нужны разработчикам нативных приложений и первоначальное видение мобильных веб-приложений Стива Джобса теперь воспринимается серьезно всем миром. Практически с самого начала Apple поддерживал “apple-mobile-web-capable” веб-приложения, которые вы можете добавить себе на домашний экран, используя мета тэги, которые помогают устройствам iOS находить такие вещи как подходящие иконки.
Другие производители последовали примеру, каждый создавал свою собственную коллекцию мета тэгов для объявления возможностей мобильных веб-приложений. Но недавно была введена кросс-платформеная спецификация и теперь кросс-платформенные мобильные веб-приложения наконец-то становятся реальностью.
Приложения, выполняющие стандарт называются прогрессивными веб-приложениями, не путать с такими сбивающими с толку, похожими терминами как прогрессивное усовершенствование или отзывчивые приложения.
Что такое прогрессивные веб-приложения
Прогрессивные веб-приложения являются веб-приложениями, разработанными и адаптированными под мобильные устройства. Если браузер отмечает, что пользователь хочет продолжить использование приложения, то он может предложить ему установить приложение на свой домашний экран. Но для того чтобы он это сделал, приложения должны удовлетворять специфическим критериям:
Что забывают многие создатели приложений так это то, что если вы делаете прогрессивное веб-приложение, то вы должны иметь возможность управлять приложением без браузерной оболочки и навигационных жестов. Мобильные устройства полагают, что вы встроили собственную навигацию в приложение.
Например, если у вас есть страница, то эта страница должна иметь обратную ссылку на пользовательский интерфейс приложения, или пользователям придется закрывать и повторно открывать приложение, чтобы вернуться обратно к главному экрану.
Прогрессивные приложения — инструкция
В сети существует множество информации о создании прогрессивных веб-приложений, но по большей части она устаревшая, а многие источники содержат только фрагменты того, что вам нужно чтобы создать приложение. Давайте исправим это.
Включить HTTPS
Чтобы включить HTTPS вам понадобится:
Манифест
Файл манифеста называется manifest.json и он достаточно простой. Он состоит из имени ( short_name для иконки домашнего экрана и опционального name для более полного названия), начального url, большого списка иконок чтобы вы могли поддерживать широкий спектр если для разных платформ нужны разные размеры иконки. Для Android и iOS вам понадобится:
Где 180*180 может быть заменено на любое нужное разрешение. Использование известных имен не обязательно, но если вы забудете включить тэги, iOS все-равно сможет найти иконки, ища их в корневой директории вашего веб-приложения, если вы будете использовать известные имена.
Иконки iOS не поддерживают прозрачность.
Простой manifest.json:
Существуют некоторые функции, о которых вам следует знать. theme_color устанавливает цвет статусной строки, а заголовок окна используется при переключении между приложениями на Android.
Манифест есть не везде
Когда с создал первое прогрессивное веб-приложение, я был потрясен тем, что оно работало как и предполагалось в Chrome на Android, но не в Safari /iOS. Причина в том, что мобильный Safari, несмотря на десятилетнюю поддержку этих функций, используя свои специфичные тэги не поддерживает до сих пор спецификацию веб-манифеста.
Поэтому в дополнение к файлу манифеста для поддерживаемых браузеров вам также понадобятся специальные мета тэги для iOS, начиная с этого, который будет запускать приложение без оболочки браузера:
От браузера к ОС: что такое Native Client и чем он может быть полезен?
Отметив в начале августа 20-летний юбилей, браузеры почти сразу перешагнули и ещё одну важную ступеньку: на прошлой неделе в бета-версии Google Chrome 14 был включён экспериментальный компонент Native Client (NaCl). Мне повезло рассказывать об этом уникальном проекте с самых первых его дней (см. Компьютерра #763) — и тем приятней констатировать сейчас, что цель, которую ставили перед собой авторы, в общем достигнута.
Чего не хватает веб-браузерам, не считая утопической стопроцентной совместимости? Увы, скоростей. Даже с учётом всех мыслимых инноваций и модификаций последних лет — революционных Javascript-движков, использования GPU, предварительного рендеринга страниц, новых протоколов (слышали про SPDY?) и прочего подобного — скорость исполнения веб-приложений на порядки медленней той, что обеспечивает любая нативная программа, выполняемая непосредственно микропроцессором. Вот здесь-то и вступает в игру NaCl.
Проект, ведомый уже три года по инициативе и под крылом Google, позволяет веб-программистам писать такие приложения, которые будут исполняться внутри браузера со скоростью, лишь слегка уступающей скорости программ в машинных кодах, но сохранят переносимость, присущую веб-приложениям.
Фокус объясняется просто: Native Client — это «песочница», внутри которой работают программы, написанные на C/C++ и других классических языках, компилируемых непосредственно в машинный код. Но замкнутые в своём участке памяти, NaCl-приложения общаются с внешним миром только через программный интерфейс, связывающий их с Javascript-движком браузера. Поэтому не имеет значения, в какой операционной системе идёт работа, важно лишь для какого процессора они скомпилированы (сейчас NaCl-программы могут быть в инструкциях x86 и ARM).
Поскольку речь идёт об исполнении непроверенного машинного кода, полученного извне, вопрос обеспечения безопасности выходит на первый план. Можно ли гарантировать, что NaCl-программа не навредит системе, где она исполняется (почистив жёсткий диск, украв ценную информацию и пр.)? Авторы уверены, что это возможно.
Native Client формирует три степени защиты. Во-первых, перед исполнением код подвергается анализу на предмет выявления потенциально опасных последовательностей. Во-вторых, программа изолирована от других приложений аппаратно, средствами микропроцессора. В-третьих, связь с окружающим пространством организована с помощью Javascript, а значит и воспользоваться NaCl сможет только теми ресурсами, которые доступны Javascript-программам. Наконец, исходные тексты опубликованы под свободной лицензией, что само по себе добавляет уверенности.
Native Client ценен не только собственными уникальными свойствами, но и наличием открытого, оформившегося API (Pepper), посредством которого он увязывается с элементами HTML5. Возможность гибко, стандартным образом вписать NaCl-программы в существующую веб-архитектуру, предположительно, даст толчок лавинообразному росту числа таких приложений. А простота переноса существующих наработок в среду Native Client (особенно легко портируются линуксовые программы, а системные библиотеки даже не требуют изменений в коде) позволит не изобретать велосипед.
Важность текущего момента в том, что эксперименты завершены и начата практическая стадия. Native Client незримо присутствует в Chrome уже на протяжении нескольких версий — в виде тестовой опции, активировать которую необходимо вручную. Начиная с версии 14, стабильный релиз которой ожидается в сентябре, NaCl-среда будет активирована по умолчанию, что сразу же расширит список её пользователей с узкого круга разработчиков до минимум нескольких миллионов рядовых сетян (Chrome сейчас третий по популярности браузер в мире).
Какими будут NaCl-программы? Теоретически, на их плечи лучше всего взвалить обязанности, для которых требуется обработка больших объёмов данных в кратчайшее время. Вот почему ожидается, что основными областями применения будут мультимедийные функции браузеров и игры (к примеру, Google реализовала так встроенный в Chrome PDF-вьюер).
Однако по факту самым востребованным свойством Native Client стала его независимость от операционных систем. NaCl-программа без модификаций и настройки работает в MS Windows, Mac OS X, Linux и Chrome OS. Правда, список приложений пока невелик (см. официальный сайт), но уже есть интересные сторонние разработки (например, NaClBox, позволяющий запускать DOS-игры в браузере).
Ближайшее будущее Native Client связывается с двумя тенденциями. Первую должны сформировать разработчики прикладного софта, которые с помощью NaCl могут сравнительно легко переносить имеющиеся наработки в Сеть и таким образом наделять их кроссплатформенностью. Подать пример собирается лично Google, где надеются со временем превратить сам браузер Chrome в приложение NaCl (а значит и уменьшить хлопоты по адаптации к разным ОС, и усилить защиту, поскольку браузер будет работать в закрытой «песочнице»).
Другую тенденцию сформируют пользователи, требуя поддержки NaCl-приложений в браузерах, конкурирующих с Chrome. Поскольку исходники открыты, ничто кроме идеологических соображений не должно помешать проникновению Native Client в Firefox, Safari, Opera и Internet Explorer. Ожидается, что это произойдёт с участием создателей браузеров или без них (при помощи плагинов).
Наконец, в отдалённой перспективе Native Client может сыграть важную роль в становлении облачной Chrome OS — где отныне возможен запуск приложений, едва ли хоть в чём-то уступающих программам для классических операционных систем. И здесь скрыт самый жирный плюс этой оригинальной разработки. Да, сторонники Native Client, безусловно, большие оптимисты. И верить им или нет, решать вам. Но в любом случае новинку стоит оценить лично. Ведь если ожидания оправдаются, резко и необратимо изменятся не только браузеры, но и весь мир вычислительной техники: браузеры станут полным эквивалентом операционных систем и фундаментом для обновлённой софтверной индустрии.
Натив или кроссплатформа? Детальный разбор простым языком
Немного знаний терминологии не повредит, чтобы иметь больше совместного контекста. Постараюсь не быть занудой.
SDK — software development kit — инструментарий разработчика. Говорят например, — AppStore SDK — набор инструментов для реализации платежей и подписок в приложении. Или Android SDK — совокупность более мелких SDK для разработки под всю платформу.
API — это программный интерфейс, (тяжело объяснять простыми словами оказывается). Руль — физический интерфейс к колёсам, коробка передач — к двигателю, мы дергаем за них, чтобы машинерия внутри сделала для нас более сложную работу через простой для восприятия интерфейс. Программные интерфейсы — наборы функций, объектов, используя которые программисты выполняют сложную работу более простыми действиями.
Поскольку сухой разбор преимуществ и недостатков той или иной технологии — пустая трата времени, будем честны, из любой технологии можно сделать какашку и конфетку, вопрос лишь какой ценой, поэтому для развития осознанного понимания, зайдем чуть издалека.
Так или иначе, клиент любого бизнеса, пожелавшего открыть для себя вожделенную айтишечку, доступен через 3 окошка:
Также мы не рассматриваем устройства носимой электроники, интернета вещей, экранов холодильников, различных embedded систем — уж очень они специфичны.
На заре широкого коммерческого успеха мобильных гаджетов, некто по фамилии Джобс, отстаивал идею о том, что персональный смартфон — это всего лишь окошко к всемирной паутине, которое всегда с собой. Круто же звучит! Вот что он говорил:
Полноценный движок Safari уже присутствует внутри iPhone. То есть, вы можете создавать изумительные Web 2.0 и Ajax приложения, которые выглядят и ведут себя так же, как родные программы iPhone. И они способны прекрасно взаимодействовать с его сервисами: звонить, отправлять электронные письма, разыскивать местоположение в Google Maps. И знаете, что? Для этого не нужен SDK! У вас уже все есть для написания невероятных приложений для iPhone, если вы знаете, как создавать программы, используя современные веб-стандарты.
Есть предположение, что изменить взгляд Джобсу помог Джонни Айв, убедив его в том, что устройства эппл без нативных сторонних приложений не будут доступны для создателей контента, плюс от этого платформа потеряет эксклюзивность. В тоже время, в кулуарах Гугл зрел андроид и у менеджмента не было особого мнения на этот счет.
Собственно, к чему эта лирика. Исторически, мы имеем два основных способа доставки приложения пользователю:
-Нативное приложение — созданное с использованием инструментов разработки вендоров: Apple/Google и распространяемое через магазины приложений. Для разработки под Apple актуальны технологии: UIKit, SwiftUI + богатый iOS SDK, язык программирования Swift (и для особых случаев старичок Objective-C)Для Андроид соответственно — Android SDK, Jetpack Compose, языки: Java 8, Kotlin
Веб-приложение, использующее браузер в качестве среды выполнения и ограниченного доступа к ресурсам девайса (я специально не называю веб-приложение сайтом, так мы в терминах отделяем статические странички от динамичных, наполненных различной бизнес-логикой, приложений). К ним же относятся так называемые WebView — приложения, обернутые тонким слоем нативного кода, использующего SDK браузера для открытия веб-приложения, также распространяются через сторы.На ладан дышащие представители этого вымирающиего семейства — Apache Cordova и Ionic. Они не скрывают свое основное назначение — быстрое прототипирование приложений. Для них актуальны классические веб технологии — HTML, CSS, Javascript. Сюда же попадают поделки из no-code конструкторов типа GlideApps и его аналогов.
Оба подхода стоят диаметрально противоположно друг другу по ряду критериев:
Промеж первых двух, с недавних пор, расположись гибридные технологии, которые в настоящий момент чаще всего подразумеваются как кроссплатформенные:
Гибридные, компилируемые в нативный код — приложения написанные с использованием сторонних инструментов разработки, языков программирования, которые имеют свой набор библиотек, связывающих программные интерфейсы платформенных SDK с собственными интерфейсами или полностью заменяющие их.
Типичные представители этого семейства: React Native, Native Script, Electron.
Пока мы не убежали далеко, хочу немного шокировать нетехническую публику — самая кроссплатформенная технология, он же язык программирования, внимание, — C++! Та-да-а-ам! И как ни странно, он очень широко используется для создания полностью нативных кроссплатформенных модулей. Никаких компромиссов! Только хардкор! Ведь наши приложения, это не только кнопочки и списки. Обработка сотен точек на картах, базы данных с особыми возможностями синхронизации совместного доступа к данным, криптография, доставка и обработка видео в реальном времени, ежесекундные данные котировок, которые мы хотим доставлять молниеносно для десятков биржевых тикеров одновременно и многое другое. Никто не пишет эту логику дважды или трижды под каждую платформу.
Главный вопрос при выборе технологии (безотносительно иных бизнес целей) — опыт какого качества мы хотим подарить пользователю. И вот несколько критериев, влияющих на пользовательский опыт:
Говоря образно, по степени абстрактности к конечной мобильной платформе, технологии можно разделить так:
Кроссплатформенные технологии, в первую очередь, хотят завлечь нас преимуществами единой кодовой базы. С этим трудно спорить:
Сравните 2 кусочка кода, описывающих карточку с картинкой:
Команды нативных разработчиков часто разбавляют C/C++ программистами. Они пишут кроссплатформенные модули для разных задач в основном не связанных непосредственно с бизнес логикой.
На старте с нуля ему нет равных в качестве продукта к скорости разработки. 2-3 разработчика способны наковырять безумное количество фич в кратчайшие сроки и выпустить продукт. При этом look-and-feel, производительность будут более чем приемлемыми. Большое количество библиотек решат множество задач типовой функциональности. Я бы назвал flutter серебряной пулей, но. надо кое-что иметь в виду.
Технология предназначена для создания UI! Как и язык программирования Dart.
Выдержка из википедии в доказательство о том, что есть флаттер на самом деле:
Flutter is an open-source UI software development kit created by Google.
Разработка с этим SDK мне всегда напоминала письмо из Простоквашино:
На личном опыте проверено, что в процессе развития продукта скорость нативной разработки со временем возрастает, а кроссплатформенной убывает. Это обусловлено тем, что в начале требуется больше усилий для сборки архитектуры и наработке кода для 2х проектов, нежели для одного. Пока умудренные в особенностях своих платформ, кодеры скрупулезно собирают базовые джентельменские наборы для любого нативного приложения, их коллеги по кроссплатформенному цеху возможно уже готовятся выпускать MVP. Всё меняется на зрелой стадии продукта.
Вот список бед на кроссплатформе, которые на поздней стадии сожрут больше денег, чем на старте:
Дайте знать, если хотите продолжение про KMM и Xamarin, жду вас и ваши мнения в комментариях!
Канала в телеге нет, но если что, пишите в личку
