Технологию нужно выбирать после того, как стало понятно, зачем вообще нужен мобильный продукт.
В продолжение предыдущего поста. Допустим, с первым вопросом разобрались: мобильное приложение бизнесу действительно нужно. Пользователи будут регулярно им пользоваться, есть понятные сценарии, которые удобнее реализовать на смартфоне, и экономика проекта в целом сходится.
Дальше возникает вопрос: какое приложение делать?
Вариантов, если сильно упростить, три.
PWA — веб-приложение, адаптированное под мобильное использование.
Кроссплатформа, например Flutter, позволяет делать решение сразу для iOS и Android с общей кодовой базой.
Нативная разработка — Swift для iOS и Kotlin для Android.
Разница между этими подходами примерно x2 по цене и деньгам. При этом для большинства обычных бизнес-задач кроссплатформа вполне способна заменить нативную разработку. Последняя становится особенно актуальной, когда проекту нужны специфические возможности устройства или сложная работа с аппаратной частью.
С PWA и кроссплатформой нужно смотреть на планы развития продукта. Пуши, отдельный мобильный интерфейс и многие стандартные сценарии можно реализовать в обоих вариантах. Но если дальше появятся NFC, Bluetooth, сложная офлайн-работа или другие специфические функции, решение может быть другим.
Если по-простому:
1. нужен быстрый и относительно простой мобильный продукт — склоняемся к PWA
2. нужны полноценные приложения для iOS и Android с разумным бюджетом — смотрим кроссплатформу
3. есть сложные технические требования и глубокая работа с устройством — рассматриваем native
Дальше появляются новые функции, обновления операционных систем, исправления ошибок, изменения API, новые устройства и требования магазинов приложений. Поэтому нужно считать стоимость владения продуктом хотя бы на несколько лет.
Если у вас два нативных приложения, часть работы придётся выполнять отдельно для каждой платформы. При общей кодовой базе в кроссплатформенном решении объём такого дублирования может быть меньше.
С другой стороны, попытка реализовать на неподходящей технологии сложный продукт тоже может дорого обойтись.
Поэтому отдельно стоит оценить экономику. Сколько будет стоить разработка, поддержка и развитие продукта на горизонте нескольких лет.
В продолжение предыдущего поста. Допустим, с первым вопросом разобрались: мобильное приложение бизнесу действительно нужно. Пользователи будут регулярно им пользоваться, есть понятные сценарии, которые удобнее реализовать на смартфоне, и экономика проекта в целом сходится.
Дальше возникает вопрос: какое приложение делать?
Вариантов, если сильно упростить, три.
PWA — веб-приложение, адаптированное под мобильное использование.
Кроссплатформа, например Flutter, позволяет делать решение сразу для iOS и Android с общей кодовой базой.
Нативная разработка — Swift для iOS и Kotlin для Android.
Разница между этими подходами примерно x2 по цене и деньгам. При этом для большинства обычных бизнес-задач кроссплатформа вполне способна заменить нативную разработку. Последняя становится особенно актуальной, когда проекту нужны специфические возможности устройства или сложная работа с аппаратной частью.
С PWA и кроссплатформой нужно смотреть на планы развития продукта. Пуши, отдельный мобильный интерфейс и многие стандартные сценарии можно реализовать в обоих вариантах. Но если дальше появятся NFC, Bluetooth, сложная офлайн-работа или другие специфические функции, решение может быть другим.
Если по-простому:
1. нужен быстрый и относительно простой мобильный продукт — склоняемся к PWA
2. нужны полноценные приложения для iOS и Android с разумным бюджетом — смотрим кроссплатформу
3. есть сложные технические требования и глубокая работа с устройством — рассматриваем native
Дальше появляются новые функции, обновления операционных систем, исправления ошибок, изменения API, новые устройства и требования магазинов приложений. Поэтому нужно считать стоимость владения продуктом хотя бы на несколько лет.
Если у вас два нативных приложения, часть работы придётся выполнять отдельно для каждой платформы. При общей кодовой базе в кроссплатформенном решении объём такого дублирования может быть меньше.
С другой стороны, попытка реализовать на неподходящей технологии сложный продукт тоже может дорого обойтись.
Поэтому отдельно стоит оценить экономику. Сколько будет стоить разработка, поддержка и развитие продукта на горизонте нескольких лет.