Как мы снизили стоимость разработки приложения в два раза
Рассказываю о новом подходе к разработке MVP для стартапов — как не тратить кучу денег на создании и внедрении дизайна, а быстро собрать интерфейс на Bootstrap. Подход полезен тем, кому нужен простой понятный интерфейс и запуск проекта с космической скоростью.
Почему у вас стоимость работы зависит от количества экранов? Что если будет сложная логика работы приложения? Например, логика работы страницы приложения стоит в 3 раза больше верстки? Выходит что вы написали про MVP каких-то типовых проектов?
Как себя поведет webview если нужно загрузить и проскролить список из 10 000+ элементов? Что будет с плавностью и отзывчивостью?
Почему вы считаете что html верстка быстрее нативной и/или других кроссплатформенных технологий? Может быть html верстальщики просто дешевле или в команде не было нативщиков?
В одном из комментариев вы написали: "Кордову, ионик и подобные компилируемые фреймворки забрили из-за двух факторов: 1. При обновлении приложения его нужно переопубликовывать".
Работает ли такой подход на iOS? Если да, то что вы будете делать, когда apple прикроет такую возможность?
Вячеслав, попробую ответить на всю массу Ваших вопросов:
1. Стоимость привязана к количеству экранов по принципу среднего арифметического. Практически в любом проекте примерно 20% сложных экранов, 40% средних и 40% простых. Конечно, есть риск просчитаться, но он сопоставим с ошибкой в сроках при почасовой оценке, а для сейлзов так проще и для клиентов понятнее.
2. Нет, мы не делали типовых MVP. Это как-то даже звучит абсурдно, т.к. MVP - это как раз ключевая бизнес-функция, которой проект будет отличаться от конкурентов.
3. Если есть огромная куча элементов, которую нужно проскроллить, то используется либо lazy load, либо, в крайнем случае, пагинация. Если уж совсем беда из-за плохой скорости передачи данных, то можно воспользоваться
4. По поводу скорости html-вёрстки. Возможно, в статье не совсем корректно выразился. Речь не о скорости загрузки, а о скорости разработки. То есть сделав 1 webview-экран мы его по факту реализовали и в iOS, и в Android и в веб-версии. По скорости загрузки передавать сгенерированный экран, либо данные, например, в JSON, при текущих реалиях 3-4G разницы нет. Можете скачать из сторов нашу демку для запуска маркетплейсов "Сервис поиска исполнителей", посмотрите как всё грузится.
5. Да, подход работает и в iOS. Для сторов, формально, это передача контента (свайп-меню, верхняя плашка, GPS и т.д. у нас нативные). То есть, если выражаться Вашими словами, то Apple должен прикрыть передачу данных между приложением и сервером в принципе, а этого никогда не будет. В год мы публикуем 40-50 приложений в сторы, при модерации подобных вопросов с саппортом не возникает, хотя, саппорт Apple на порядок суровее, чем Гугловский.