Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Июльский отчет Data Reportal показал, что число пользователей мобильных телефонов за 2023 год увеличилось аж на 168 (!) миллионов. Значит ли, что из-за такого прироста нужно выделять бюджет на разработку МП? Да, но не всем. Рассказываем, в каких случаях можно обойтись без приложения, а в каких без него никуда. Подскажем, когда лучше выбирать кроссплатформенную разработку МП, а когда — нативную.
Мобильное приложение нужно запускать бизнесам, у которых:
— большинство клиентов — люди в возрасте от 15 до 35 лет;
— большинство посетителей заходят на сайт с мобильных устройств. Это говорит о том, что вашим клиентам уже удобнее получать аналогичные продукт или услугу через приложение. Соотношение можно отследить в «Яндекс.Метрике» и Google Analytics;
— есть конкуренты со своим приложением.
Из неочевидного: когда бизнесу нужно оптимизировать процесс, построить эффективную работу внутри. Самый подходящий пример из нашего арсенала — корпоративное приложение для дальнобойщиков, которое помогло в итоге оптимизировать бизнес в целом.
Когда точно не делать:
— слишком узкая ниша (например, ПП-шашлычная, где все из кабачка, брокколи и индейки);
— неспособность приложения решать бизнес-задачи;
— слабый поток клиентов или их неготовность к чему-то новому.
Тогда лучше вложить деньги в маркетинг — завести страничку в ВК и TG, нанять SMM-щика, заказать лендинг и запустить таргет. Если очень хочется приложение, то лучше сделать адаптивную версию сайта.
Итак, допустим, вы поняли, что МП вам все-таки необходимо. Но проблема метаний на этом не закончилась. Главный вопрос теперь в том, что выбрать — нативную или кроссплатформенную разработку? Это 2 разных метода, у каждого свои плюсы и недостатки. Ниже разберем, какой вариант подойдет вашему бизнесу.
Михаил планирует запустить стартап. Чтобы начать собирать заказы, он решается на разработку мобильного приложения. Мужчина планирует охватить больше клиентов: и владельцев IOS, и владельцев Android, но боится, что разработка 2-х приложений ударит по карману. Михаил где-то слышал, что можно разработать одно приложение, которое будет работать на 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, если компания хочет охватить больше пользователей как можно скорее. Или когда в приложении не планируется делать тактильные отклики на действия пользователей. При этом на кроссплатформе все еще можно воплотить сложные высоконагруженные решения. Яркие тому примеры — сервис для онлайн-тренировок и приложение для управления вендинговыми аппаратами, которые разрабатывались у нас в Pyrobyte.
Теперь Михаилу понятно, чем отличаются кроссплатформенные приложения от нативных. Он определился с выбором и решил, что выберет первое (что логично):
— он хочет запустить MVP, чтобы начать быстрее получать заказы;
— его ЦА пользуется 2-мя платформами;
— будущее приложение не предполагает сверхнагруженных эффектов, поэтому его производительность не пострадает;
— в случае чего он сможет без проблем масштабироваться.
Если у вас остались вопросы, будем рады пообщаться в комментах!
***
Чтобы не пропустить интересное, следите за нами:
В телеграм-канале
Во ВКонтакте
На нашем сайте
Итак: когда пора делать мобильное приложение, а когда нет
Мобильное приложение нужно запускать бизнесам, у которых:
— большинство клиентов — люди в возрасте от 15 до 35 лет;
— большинство посетителей заходят на сайт с мобильных устройств. Это говорит о том, что вашим клиентам уже удобнее получать аналогичные продукт или услугу через приложение. Соотношение можно отследить в «Яндекс.Метрике» и Google Analytics;
— есть конкуренты со своим приложением.
Из неочевидного: когда бизнесу нужно оптимизировать процесс, построить эффективную работу внутри. Самый подходящий пример из нашего арсенала — корпоративное приложение для дальнобойщиков, которое помогло в итоге оптимизировать бизнес в целом.
Когда точно не делать:
— слишком узкая ниша (например, ПП-шашлычная, где все из кабачка, брокколи и индейки);
— неспособность приложения решать бизнес-задачи;
— слабый поток клиентов или их неготовность к чему-то новому.
Тогда лучше вложить деньги в маркетинг — завести страничку в ВК и TG, нанять SMM-щика, заказать лендинг и запустить таргет. Если очень хочется приложение, то лучше сделать адаптивную версию сайта.
Делаем мобильное приложение: определяемся с подходом
Итак, допустим, вы поняли, что МП вам все-таки необходимо. Но проблема метаний на этом не закончилась. Главный вопрос теперь в том, что выбрать — нативную или кроссплатформенную разработку? Это 2 разных метода, у каждого свои плюсы и недостатки. Ниже разберем, какой вариант подойдет вашему бизнесу.
Что такое кроссплатформенная и нативная разработка — на примере Михаила
Михаил планирует запустить стартап. Чтобы начать собирать заказы, он решается на разработку мобильного приложения. Мужчина планирует охватить больше клиентов: и владельцев IOS, и владельцев Android, но боится, что разработка 2-х приложений ударит по карману. Михаил где-то слышал, что можно разработать одно приложение, которое будет работать на 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, если компания хочет охватить больше пользователей как можно скорее. Или когда в приложении не планируется делать тактильные отклики на действия пользователей. При этом на кроссплатформе все еще можно воплотить сложные высоконагруженные решения. Яркие тому примеры — сервис для онлайн-тренировок и приложение для управления вендинговыми аппаратами, которые разрабатывались у нас в Pyrobyte.
Теперь Михаилу понятно, чем отличаются кроссплатформенные приложения от нативных. Он определился с выбором и решил, что выберет первое (что логично):
— он хочет запустить MVP, чтобы начать быстрее получать заказы;
— его ЦА пользуется 2-мя платформами;
— будущее приложение не предполагает сверхнагруженных эффектов, поэтому его производительность не пострадает;
— в случае чего он сможет без проблем масштабироваться.
Если у вас остались вопросы, будем рады пообщаться в комментах!
***
Чтобы не пропустить интересное, следите за нами:
В телеграм-канале
Во ВКонтакте
На нашем сайте
