// Mobile apps
#1. Нативні додатки (рідні)
#2. Плюси розробки нативних додатків
#3. Мінуси розробки нативних додатків
#4. Кросплатформні додатки (не рідні)
#5. Плюси кросплатформенної розробки додатків
#6. Мінуси кросплатформенної розробки застосунків
#7. Особливості нативного та кросплатформенного підходу
#8. Таблиця основних відмінностей між нативним і кросплатформним підходом
#9. Резюме (який підхід обрати)
#10. Невеликий бонус
Опис: Дамо визначення кросплатформенному та нативному підходу до розроблення застосунків, опишемо переваги та недоліки кожного та підкажемо, який обрати.
Коли смартфони тільки з'явилися, розробники були обмежені лише платформно-орієнтованим, або нативним, підходом до створення застосунків. Тобто вони могли створити застосунок лише для певної платформи (iOS та Android). Якщо ж потрібна була підтримка відразу обох платформ, то доводилося створювати два окремі додатки для кожної мобільної платформи.
Зараз вибір трохи більший, оскільки, крім нативного, ви також можете створити кросплатформний застосунок, який працюватиме як на Android, так і на iOS, використовуючи тільки одну базу коду. Далі ми розповімо, що стоїть за термінами нативної та кросплатформної розробки застосунків, а також детально опишемо переваги та недоліки кожного підходу і іх нюанси.
Нативними називають програми, які працюють лише на одній мобільній платформі або операційній системі, тобто тільки на iOS, Android, Windows mobile, Blackberry тощо. Це майже всі встановлені за замовчуванням додатки: телефонна книжка, акселератор, файловий менеджер, календар, калькулятор, імейл-клієнт та інші стандартні сервіси, а також майже всі мобільні відеоігри та інші програми, що використовують графічні чіпи.
Користувачі люблять "натівки" за адаптивний UX, високу швидкість роботи, звичний дизайн і чуйність. Що досягається завдяки використанню "рідних" для кожної платформи мовних середовищ: Swift і Objective-C для iOS, а також Java і Kotlin для Android. Крім того, за допомогою нативного підходу програмісти можуть отримати повніший доступ до апаратної та сервісної частини пристрою: фото- і відеокамери, аудіомудуль, телефонна книга, GPS-модуль тощо - загалом, вони легко інтегруються і "почуваються як вдома" на рідній платформі.
Розплачуватися за адаптований UX, чуйність, функціональність і продуктивність доводиться часом і, отже, вартістю розроблення, оскільки на написання програмного коду для двох платформ витрачається в півтора-два рази більше часу, а отже, і бюджет розроблення має бути значно більшим (докладніше про це нижче за текстом).
Висока швидкість і продуктивність.
Оскільки при створенні нативних програм використовуються інструменти та технології, безпосередньо пов'язані з платформою, це дає змогу забезпечити пряму та водночас більш просту взаємодію застосунку з платформою, що значно підвищує загальну швидкість і продуктивність програми, особливо під час використання графічного чіпа пристрою (тому майже всі мобільні ігри - це нативні застосунки). З тих самих причин "натівки" мають нижчий час відгуку, нижчу ймовірність збоїв та зависань.
Більше можливостей для інтеграції з платформою.
Більш повноцінний доступ до функцій і сервісів платформи дає змогу створювати застосунки з повноціннішим використанням можливостей цієї платформи. Наприклад, нативні додатки для фото- і відеозйомки зазвичай дають змогу отримувати якісніші фото та відео. Те саме стосується і Bluetooth, NFC, GPS, аудіомодуля та інших функцій.
Звичний інтерфейс користувача (більш адаптований).
Оскільки нативні додатки тісніше інтегруються з платформою, це дає змогу використовувати максимум доступних можливостей апаратної частини пристрою і повноцінніше відповідати гайдлайнам (про них буде сказано нижче). Завдяки цьому можна реалізувати більш звичний для аудиторії платформи інтерфейс і досвід користувача.
Краще позиціонування в онлайн-маркетплейсах.
Ще завдяки тіснішій інтеграції з платформою і пристроєм, а також якіснішому досвіду користувача, нативні застосунки зазвичай вище позиціонуються в таких маркетплейсах, як App Store, Google Play. Крім того, є припущення, що механізми ранжування на цих майданчиках апріорі дружелюбніше ставляться до "рідних" застосунків.
Значний час і вартість створення застосунку.
Розробка програми під кожну з кількох платформ може дуже сильно збільшити час розробки, оскільки інженерам потрібно написати дві бази коду, отже, і вартість розробки застосунку буде вищою. Адаптація UI/UX-дизайну під кожну платформу також може зайняти досить багато часу, що ще більше "роздує" бюджет розробки.
Залежність від однієї мобільної операційної системи.
Для нативних рішень інженери-програмісти використовують мовне середовище, спеціально розроблене для операційної платформи, що робить такий застосунок несумісним з іншими платформами. Іноді це не є проблемою (наприклад, якщо ви орієнтовані на Індію, де понад 90% смартфонів працюють на Android), але частіше за все через такий підхід ви обмежите охоплення і доступність свого сервісу, товару або послуги.
Втрачені фінансові можливості (прибутки).
Завідоме скорочення свого ринку однією мобільною платформою - це очевидне скорочення потенційної фінансової вигоди. Особливо якщо під час проектування і розробки ніхто не думає про можливий вихід на інші мобільні платформи в разі успішного запуску проекту.
Кросплатформні додатки - це програми, створені за концепцією "скомпілюй один раз, запусти скрізь", оскільки вони передбачають розробку однієї кодової бази для роботи на різних платформах / операційних системах. Це досягається завдяки застосуванню таких інструментів розробки, як React Native і Xamarin, що дають змогу написати код програми та розгорнути його на різних платформах із близьким до рідного для обраної платформи UI/UX-дизайном.
Завдяки кросплатформенному підходу до створення програм можна істотно скоротити час і вартість розробки. Однак при цьому не варто розраховувати на видатну продуктивність та/або максимальну інтеграцію з функціями і сервісами платформи та пристрою. Налаштування також може стати проблемою, оскільки воно буде обмежене використаною структурою.
Єдина база коду для всіх платформ.
Можливо, головним плюсом кросплатформної розробки є використання однієї бази коду для різних мобільних платформ. Завдяки цьому команда розробників може використовувати лише один технологічний стек (і при цьому його набагато простіше підібрати), а не відразу кілька технологічних стеків для кожної мобільної платформи / операційної системи.
Більш просте та швидке розгортання.
Оскільки для створення кросплатформних рішень не потрібно вивчати кілька технологічних стеків, розробники можуть сконцентруватися на одному технологічному стеку, що дає змогу вивчити й потім реалізувати всі його переваги. Крім того, одна кодова база також дає змогу сильно прискорити початкове розгортання застосунку одразу на кількох платформах, а також скоротити час і складність апдейтів.
Скорочення часу і вартості розробки.
Це ще одна важлива перевага кросплатформної розробки, яка досягається за рахунок скорочення часу на написання коду для двох і більше баз коду. Скільки саме можна заощадити часу і грошей, залежить від завдання проекту і фреймворку. Наприклад, завдяки React Native ви можете створювати додатки на 50% швидше, ніж при нативній розробці. Крім того, React Native дає змогу використовувати готові компоненти, які вже були створені кимось іншим, та легко інтегрувати їх у свій власний проект. Саме тому ми в Merehead створюємо кросплатформні додатки, використовуючи React Native.
Покриття ширшої аудиторії користувачів.
Оскільки кросплатформні рішення розробляються для двох і більше платформ / операційних систем, то й охоплення цільової аудиторії у них більше. Це дає змогу представити застосунок на більшій кількості мобільних пристроїв для більшої кількості користувачів, що робить кросплатформу вигіднішою для бізнесу, ніж присутність лише на одній платформі.
Допустимість однакового інтерфейсу та UX.
Одна команда розробників і загальна кодова база дає можливість створити однаковий користувацький інтерфейс для всіх платформ, що дуже важливо для брендів. Крім того, це дає змогу реалізувати "безшовний" перехід з однієї платформи на іншу, наприклад, зі смартфона на планшет, ноутбук, комп'ютер або телевізор (ігрову приставку або смарт-тв).
Менша гнучкість, ніж у нативних додатків.
Уніфікований стек технологій не дає такої ж високої гнучкості, як стек, заточений під конкретну платформу. Через що кросплатформні рішення в переважній більшості не можуть мати такий самий ступінь інтеграції з платформою і пристроєм, як нативні рішення.
Більш низька продуктивність і надійність.
Втрата гнучкості в розробці також означатиме втрату в можливостях щодо поліпшення та оптимізації продуктивності. Інакше кажучи, за інших рівних умов кросплатформні рішення ніколи не працюватимуть так само швидко, надійно, безпечно і плавно, як нативні застосунки.
Можлива невідповідність у дизайні на двох платформах.
Ще одна проблема, яка може у вас виникнути, - наявність деяких відмінностей між призначеними для користувача інтерфейсами та користувацьким досвідом на різних платформах / операційних системах (наприклад, на Windows є кнопка "Пуск", а на macOS у неї немає аналога). Це може бути зумовлено як різними вимогами до дизайну користувацьких інтерфейсів на різних платформах, так і специфічними обмеженнями цих платформ.
Можливі складнощі з маркетплейсами додатків.
Механізм і вимоги до кросплатформних застосунків у маркетплейсах Apple App Store і в Google Play Store відрізняються. Проходження всіх бюрократичних процедур, перевірок і тестів може зайняти багато часу і викликати деякі труднощі.
Дизайн інтерфейсу. Вище ми писали про те, що при створенні мобільних застосунків використовують гайдлайни - це цінні інструкції / вказівки власників платформи, орієнтовані на те, щоб підігнати функціонал і зовнішній вигляд застосунку під стандарти платформи. Гайдлайни відображають бачення створювачів платформ про те, як зробити досвід користувача на платформі максимально комфортним. Інакше кажучи, з їхньою допомогою можна зрозуміти, який вигляд повинен мати дизайн, щоб він був звичним для користувачів цільової платформи.
При нативній розробці використовуються мови, які володіють максимально повним інструментарієм для реалізації всіх вимог гайдлайнів, тобто для створення звичного аудиторії платформи дизайну. Тоді як кросплатформна розробка передбачає використання універсальних інструментів, які хоч і дають змогу наблизити дизайн до "нативного", але для цього вам доведеться витратити значно більше зусиль. При цьому швидкість анімації, чуйність, ефекти та дизайн все одно будуть хоч трохи, але іншими (щоправда, це не завжди погано).
Користувацький досвід. Більш низька чутливість (швидкість реакції додатка на дії користувача), більш різка (смикана) анімація, пінг та підвисання здатні дуже сильно зіпсувати досвід користувача. Часто ці проблеми призводять до того, що користувачі видаляють застосунок після першого запуску, незважаючи на його унікальність, приємний дизайн і низьку вартість.
Кросплатформні рішення через застосування неспецифічних для платформ мов у цьому плані поступаються нативним - вони гальмують і виснуть, і це їхня головна проблема. І хоча підвисання можуть бути на долі секунди, але й цього достатньо, щоб користувач віддав перевагу нативному застосунку. Наприклад, багато хто віддає перевагу Android-пристроям, оскільки на цьому ринку можна знайти пристрої з частотою оновлення екрана 90-140 Гц, тоді як на тому ж iPhone 12 Pro Max вона становить лише 60 Гц, що сильно псує досвід користувача.
Крім того, розробники кросплатформених застосунків зазвичай створюють однаковий дизайн (так простіше, швидше і дешевше), що може бути не завжди добре, оскільки на кожній платформі зазвичай є свої специфічні правила (гайдлайни). І коли ці правила ігноруються, користувачам однієї з платформ може бути незвично (некомфортно) використовувати застосунок.
Яскравий приклад - звична для Android-пристроїв функція Back, яка не має аналогів на iOS. Якщо у кросплатформного застосунку буде однаковий дизайн, то користувачі однієї платформи будуть змушені пристосовуватися, що може погіршити їхній користувацький досвід. Розв'язати цю проблему можна, тільки створивши два різні дизайни з урахуванням особливостей кожної платформи. Але це, по суті, будуть два різні додатки, але на одній кросплатформенній мові, що багато в чому нівелює переваги цього підходу до розробки програм.
Обмеження мобільної платформи. При нативній розробці ви будете обмежені можливостями платформи і пристрою, що використовується. Проектуючи кросплатформенний застосунок, розробник має враховувати не тільки ці обмеження, а й можливості використовуваної мови, моста і фреймворка.
Обслуговування та підтримка. Для комплексного обслуговування кросплатформенного рішення (оновлення, апдейти безпеки, пошук і виправлення помилок) зазвичай потрібно вдвічі менше ресурсів, оскільки з цим може впоратися один фахівець (команда), тоді як для обслуговування нативних рішень для двох платформ потрібно щонайменше два фахівці (Android, iOS).
Час і вартість розробки. Створення кросплатформних рішень, як правило, обходиться значно дешевше за нативну розробку, що зумовлено меншими обсягами робіт. Виграш зазвичай становить від 30 до 50%. Ось таблиця з порівнянням часу і вартості кросплатформної vs нативної розробки, виходячи з даних міжнародної фріланс-платформи upwork.com.
Тепер, коли ми розуміємо, що мають на увазі під кросплатформеною і нативною розробкою, а також знаємо переваги та недоліки кожного варіанта, давайте коротко розглянемо основні відмінності між ними.
Рішення про вибір оптимального для підходу до розроблення застосунків залежить від бізнес-завдань, складності проекту та індивідуальних обставин, тому тут не можна дати єдино правильної відповіді. Можна надати лише загальні рекомендації.
На нативному підході розробки застосунку варто зупинитися, якщо:
Кросплатформний підхід (React Native) краще використовувати для тестування ідеї та виходу на ринок у найкоротші терміни. Також такий підхід кращий, якщо вам потрібен простий додаток для вирішення конкретного завдання, наприклад, стрічка новин або форма для голосування.
Якщо ви все ще не вирішили, який варіант підходить для вас краще - кросплатформна або нативна розробка, скористайтеся цією схемою:
Відгуки наших клієнтів
Розробка гнучної екосистеми на основі технології блокчейн
