Нативная или кроссплатформенная кроссплатформен-ная разработка: что подойдёт вашему бизнесу

• Когда бóльшая часть аудитории — люди 15–35 лет;
• Если «Яндекс.Метрика» и Google Analytic показывает, что большинство посетителей заходят на сайт с мобильных устройств. Это говорит о том, что вашим клиентам УЖЕ удобнее получать аналогичные продукт/услугу через приложение;
• У прямых конкурентов оно уже есть.

Из неочевидного: когда бизнесу нужно оптимизировать работу, наладить эффективность. Пример — корпоративное приложение для дальнобойщиков, продукт для внутреннего пользования, который помог оптимизировать бизнес Сервико-Авто в целом

• Слишком узкая ниша (например, у вас ПП-шашлычная для веганов);
• Неспособность приложения решать задачи (если бизнес сезонный, например, по аренде яхт, то приложением оставшиеся 3 сезона никто пользоваться не будет. А заказчик, кстати, изначально приходил именно за ним);
• Слабый поток клиентов или их неготовность к чему-то новому (запчасти для сельхоз техники вряд-ли кто-то будет заказывать через приложение)

Лучше вложить деньги в маркетинг — завести страничку в ВК и TГ, нанять SMMщика, SEOшника, заказать лендинг и запустить таргет. Или сделать адаптивную версию сайта.

Допустим, вы склоняетесь к первому варианту — приложение нужно. Но выбор на этом не закончился.

Главный вопрос теперь в том, какой подход применить — нативный или кросплатформенный?

Один и тот же метод может подойти одному, но не подойти другому, и у каждого есть плюсы и минусы.

Михаил планирует запустить стартап. Чтобы начать собирать заказы, он решается на разработку мобильного приложения. Мужчина хочет охватить больше клиентов: и владельцев IOS, и владельцев Android, но боится, что разработка 2-х приложений ударит по карману.

Он знает, что можно разработать одно приложение, которое будет работать на 2-х платформах сразу. Речь о кроссплатформе. Суть таких приложений в том, что они работают одновременно и на Android, и на iOS, стоят дешевле и разрабатываются быстрее.

Нативное же приложение будет работать только на одной, «своей» платформе — Android или iOS.Представьте: вы хотите поговорить с корейцем. И для этого учите корейский. Если вам нужно поговорить с немцем — учите немецкий. Так работает нативная мобильная разработка: с каждой платформой вы говорите на ее родном (native) языке. У Android это Java и Kotlin, у iOS — Objective-C и Swift.

Кроссплатформа работает по-другому. Допустим, вы хотите поговорить с корейцем, но не хотите учить его язык. Он тоже не владеет русским, но вы оба знаете английский, поэтому можете общаться на нем. То есть вместо нативных языков, вы используете один код, которые могут понять все ОС.

Кроссплатформенные приложения чаще всего разрабатываются на 2-х фреймворках — React-Native или Flutter. Михаил знает, что правильного и неправильного подхода нет, но ему надо выбрать что-то одно. Поможем ему разобраться.

Главный плюс кроссплатформы — один код для разных платформ. Из этого вытекает все остальное:

• Скорость. Так как для Android и iOS пишется один код, срок запуска продукта сокращается. Идеально для бизнеса, который собирается заявить о себе уже через 3-4 месяца;
• Экономия. Нативная разработка дороже — для каждой версии нужно нанять 2 команды разработчиков. Сэкономить можно, только если выбрать одну платформу;
• Большая аудитория. Ваш проект охватит большинство пользователей, но денег вы потратите меньше;
• Нет разношерстности в интерфейсе. Кроссплатформенная разработка позволяет просто скопировать все элементы UI, в отличие от нативной (там из-за различий в версиях могут возникнуть проблемы).

• Производительность ниже. Это из-за малой взаимосвязи между инструментами и платформой. Нативные приложения надежнее и работают быстрее;
• Все равно нужен нативный код. Кроссплатформенные фреймворки поддерживают не все функции. Например, в React Native не воспроизводится медиа. Нужно либо дописывать код на нативных языках, либо подключать дополнительные модули. Но все равно — закодить небольшие дополнения в самих фреймворках на нативных языках проще и быстрее, чем изначально делать всю работу на нативе;
• Нужно проверять приложение после обновления каждой операционной системы. Потому что некоторые функции могут перестать работать так, как они задумывались.

• Высокая производительность. Нативное МП реже зависает и полноценно работает оффлайн. Flutter, конечно, тоже неплохо справляется с анимацией, но максимальную отдачу можно получить только в нативной среде, не используя промежуточные библиотеки;
• Можно подключить элементы AR/VR. На кроссплатформе это тоже можно сделать, но нативная разработка справится с задачей лучше. Ее поддержка в RN и Flutter реализована только на базовом уровне, а всех эффектов можно добиться только на родных языках;
• Возможности для инноваций. Их можно реализовать и на React Native, но это сложнее и дольше. Все уникальные элементы придется писать на нативных языках;
• Малый размер. Если нужно сделать приложение максимально компактным, нативная разработка поможет его уменьшить.

• На нее уходит много времени. Обычно от 4 месяцев, потому что продукт создается под каждую платформу отдельно;
• Цена. По сути, компания создает сразу 2 продукта для разных систем. На разработку 2-х кодовых баз понадобятся 2 команды;
• Сложности с поддержкой. Тестировать коды для 2-х несвязанных между собой версий тоже долго. Придется нанимать 2 команды тестировщиков (снова упирается в бюджет);
• Ограничение одной платформой. Если захочется сэкономить и разработать нативное приложение только под одну платформу, то можно упустить прибыль, потому что продукт не будет работать на других платформах.

Нативная разработка подходит для:

— Воплощения высокоуровневых анимаций и уникальных спецэффектов: звуковых, тактильных, визуальных (такие вещи важны в приложениях для медитаций или творчества);

— Когда нужно по-максимуму задействовать мощности смартфона для сложных вычислений;

— Если большинство клиентов пользуются определенной ОС. Тогда есть смысл разработать приложение именно под нее.

Кроссплатформенная разработка идеально подходит для:

— Создания MVP, если компания хочет охватить больше пользователей как можно скорее;

— Когда в приложении не планируется делать тактильные отклики на действия пользователей.

При этом на кроссплатформе все еще можно воплотить сложные высоконагруженные решения. Например, сервис для онлайн-тренировок и приложение для управления вендинговыми аппаратами, которые разрабатывались у нас в Пиробайте.