Чому мобільна розробка технологічніша за веб? Чи може програміст запустити застосунок без команди? Чи правда, що головний етап роботи над продуктом починається після релізу, та чому всі сперечаються про конструктори інтерфейсів і force unwrap? Артур Майорський, iOS Engineer в Universe з екосистеми Genesis, спростував найпоширеніші міфи в цій сфері на прикладі розробки найпростішого застосунку — мобільного калькулятора.
МІФ №1
Мобільна розробка — це примітивне програмування.
Цей міф виник через велику кількість інструментів, що полегшують роботу iOS- та Android-інженерів. А також тому, що в цю сферу досить низький поріг входу. Навіть щойно почавши вивчати розробку, можна написати просту логіку базового калькулятора, додати готовий інтерфейс, — і ваш перший «продукт» готовий.
Але водночас у мобільній розробці чимало цікавих завдань і складних технологій. На відміну від вебу тут є доступ до найрізноманітнішого функціонала. Наприклад, доступ до всіх функцій камери та LiDAR на телефоні дає можливість реалізувати функціональність, можливу лише в мобільній розробці. В нашому застосунку ScanGuru це використовується для підказок користувачу при скануванні документа. Це допомагає зробити якісніший знімок, регулюючи відстань, ступінь освітлення тощо.
Такі рішення неможливо реалізувати, просто під’єднавши стандартну бібліотеку роботи з камерою. Треба аналізувати потік кадрів, створювати алгоритми, які шукатимуть на кожному кадрі документи та перероблятимуть їх у вигляд, максимально схожий на цифровий. Тому мобільну розробку аж ніяк не можна назвати примітивною.
МІФ №2
Застосунок можна створити без коду.
В iOS, як і в Android, існують готові рішення, наприклад, конструктори інтерфейсів. Деякі розробники використовують їх, адже це швидше й наочніше. Інші створюють інтерфейси з допомогою коду, тобто прорахуванням кожного елементу на екрані, адже це дає більше гнучкості. Часто це стає предметом суперечок та навіть хейту. Але насправді можна знайти плюси й мінуси в будь-яких рішеннях та архітектурах.
В Universe не користуються конструкторами інтерфейсів в iOS. В Android-застосунку доля готових інтегрованих рішень складає максимум 5%. У будь-якому разі це лише візуальна частина. Розробнику все одно доведеться багато працювати з кодом, щоби її налаштувати. Навіть вже згаданий калькулятор неможливо створити готовими рішеннями без коду.
МІФ №3
Після релізу фаза розробки завершується.
Навпаки, усе тільки починається. Більшість розробників спочатку випускають MVP-версію продукту, щоби перевірити гіпотезу та нішу. На цьому етапі швидкість — найважливіша, тому командам немає сенсу заморочуватися над архітектурою та дизайном. Це може зайняти багато часу та інвестицій, а продукт не злетить.
Повернімось до калькулятора. Наприклад, є гіпотеза, що такий застосунок може приносити мільйони. Можна створити його за день, а можна залучити команду продакт-аналітиків, два місяці думати над дизайном, проводити UX-дослідження та за пів року нарешті запустити бездоганний калькулятор. Але виявиться, що в цю нішу дуже дорого приводити людей. Дізнатися про це можна було б, витративши лише один день розробки.
Тому після релізу, якщо гіпотеза не підтвердилася, і застосунок нікому не потрібен, фаза розробки справді завершується. Якщо ж продукт злетів, ця фаза починає розганятися: переписується MVP, створюється нова архітектура, набирається команда, планується додатковий функціонал, проводяться тести тощо. Надалі продукт треба буде постійно покращувати — протягом всього його існування.
МІФ №4
Ринок Mobile App — перенасичений, а створення застосунків — затратне.
В App Store та Google Play — мільйони застосунків. Їхнє число постійно змінюється, адже щодня на платформи завантажуються нові продукти та видаляються старі й неякісні. Водночас загальний обсяг ринку мобільних застосунків щороку зростає. 2021 року користувачі обох платформ витратили $132 млрд, а за прогнозом Sensor Tower, у 2026 році глобальні витрати сягнуть $233 млрд.
Тому перенасичений не весь ринок загалом, а окремі його ніші. Натомість є ніші, що поступово зростають без зупинки, або ті, що стрімко зростають, а потім зупиняються.
Для багатьох застосунків достатньо одного розробника. Якщо він обрав правильну нішу та зробив конкурентний продукт, у нього є всі шанси на успіх. Не для всіх продуктів потрібна велика команда iOS-розробників, адже 100 людей не зробить кращий калькулятор, ніж одна людина. Створити застосунок насправді можна безкоштовно, інвестувавши лише власний час та 100$ за акаунт розробника в App Store (25$ — в Google Play).
Якщо розробник планує запускати продукт самостійно, він має базово розумітися в бізнесі, продакт-менеджменті та маркетингу, інакше не зможе конкурувати та залучати аудиторію.
МІФ №5
Використання force unwrap в iOS-розробці — так чи ні?
Force unwrap — це дія, яка за певних умов може «крашнути» застосунок. Та тема для запеклих дискусій.
Одні розробники вважають, що їх не можна використовувати в коді. Але, з іншого боку, вони космічно заощаджують час розробника в застосунках, складніших за калькулятор. І якщо все робити правильно, шанс, що все впаде, — частіше мінімальний. Тому є думка, що за певних обставин force unwrap можна використовувати.
Наприклад, якщо не використовувати force unwrap, а шукати шляхи безпечно приховувати від користувача помилки, як це доволі часто роблять, QA може пропустити баг. Краш пропустити неможливо, тому force unwrap може економити багато часу розробнику та зменшувати кількість багів.
МІФ №6
Час програмістів дорожчий, ніж час компʼютерів.
Є думка, що всі застосунки працюють занадто повільно, й розробники не докладають достатньо зусиль, щоби зробити їх швидшими. Для мобільної розробки справді немає сенсу робити дуже швидкі програми. Адже в чому сенс супершвидкої операції, якщо здатність екрана «намалювати» її все одно обмежена? Зазвичай розробники у швидкості обробки інформації орієнтуються саме на можливості екрана — 1/120 секунди. Так користувач не помітить, як вона обробляється.
Навіть якщо такої швидкості досягнути не вдається, і певна операція обробляється довше, усе одно краще не «вигадувати велосипед» та не писати суперскладний код два тижні, щоби воно працювало швидше. Краще просто намалювати гарний loader, адже два зайвих тижні розробки означають, що на два тижні пізніше вийде реліз. За цей час він міг би приносити +20% виручки щодня. Це потенційно сотні тисяч втрачених доларів просто тому, що в користувача трошки швидше завантажиться екран, і це не принесе глобальної користі ані йому, ані бізнесу.
Сучасні смартфони — досить потужні, здатні нормально працювати навіть у застосунках із дуже поганим кодом. Якщо програма працює занадто повільно й зависає, то це відбувається через очевидні баги, а не через те, що розробник не використав якісь складні рішення. Краще просто та швидко написати якісний код, ніж довго працювати над тим, щоби застосунок працював на 1 мілісекунду швидше. У простій зрозумілій структурі коду значно легше шукати баги та фіксити їх. Інший бік складного коду — довгий онбординг нових співробітників. Десь економиться трошки часу, але гальмується вся подальша розробка.
Скоро в Genesis планується запуск нового профільного комʼюніті для мобільних розробників, дізнайтеся про інші 12 спільнот.
