Коли у бізнесу виникає потреба у своєму мобільному додатку, не завжди зрозуміло, з якого боку підступитися до цього завдання. Вона може здатися заплутаною та складною, особливо якщо ви вперше стикаєтеся з реалізацією цифрового продукту. Наша стаття допоможе розібратися, як створити програму і що відбувається на кожному етапі процесу розробки. Мобільні програми розробляють за допомогою нативних технологій або кросплатформових інструментів. Вибір підходу впливає функціональні можливості майбутнього продукту, терміни реалізації проекту та порядок виконання робіт. Нативна технологія передбачає, що цифровий продукт буде випущений на одній конкретній платформі. Тому його пишуть рідною для операційної системи (ОС) мовою програмування. Наприклад, якщо сервіс створюється для користувачів iOS, можна використовувати Swift, а якщо для користувачів Android - Kotlin. Нативні програми забезпечують швидке завантаження, плавне відтворення анімації та моментальний відгук на дії користувача. Вони мають високу продуктивність, оскільки вони враховують специфіку кожної ОС. Інтерфейс таких сервісів виходить звичним для користувачів, оскільки відповідає стандартам обраної платформи для релізу. Якщо бізнес віддає перевагу нативному підходу і хоче охопити аудиторію кількох платформ, створюють два окремі продукти. Для цього потрібні дві команди програмістів, дизайнерів та тестувальників. Щоб зарелізувати програму одночасно на обох ОС, роботу над двома версіями ведуть паралельно.Якщо ресурси обмежені, вибирають послідовну розробку. Спочатку випускають програму для однієї платформи, а потім, коли з'являються додаткові кошти, — для іншої. Кросплатформний підхід передбачає створення однієї програми, яка працює на кількох ОС. Для цього використовуються такі фреймворки, як React Native, Xamarin, Flutter або Kotlin Multiplatform Mobile. Технологія дозволяє не писати з нуля програми для кожної платформи, а використовувати загальну кодову базу – це скорочує тривалість розробки та економить кошти. Однак підхід має свої нюанси. Наприклад, кросплатформні послуги можуть програвати нативним в тривалості завантаження, плавності роботи та швидкості відгуку на події користувачів. Особливо це помітно, якщо функціональність продукту тісно пов'язана з апаратними можливостями пристрою: дзвінками, повідомленнями, камерою, геолокацією, Wi-Fi та іншими. Щоб програма вийшла зручною для користувачів, іноді доводиться оптимізувати код для кожної ОС. Різниця між нативною та кросплатформовою технологіями Незалежно від вибраної технології розробки, у процесі створення програми можна виділити сім ключових кроків. Розбираємось, що відбувається на кожному етапі. Створення програми починається з опрацювання ідеї. Щоб випустити корисний та затребуваний продукт, проводять серію досліджень. На початкових етапах важливо зрозуміти, кому призначений продукт. Для цього аналізують цільову аудиторію — потреби, звички користувача і переваги щодо дизайну та функцій додатку.Зібрана інформація допомагає зрозуміти, які проблеми повинен вирішувати мобільний сервіс і як він зможе покращити повсякденне життя користувачів. Щоб сервіс вийшов сучасним, досліджують актуальні тренди та популярні технології, які можна інтегрувати у додаток. Наприклад, зараз спостерігається тренд на персоналізацію інтерфейсу та контенту за допомогою штучного інтелекту. Взяти до уваги вдалі рішення, уникнути типових помилок і придумати кілер-фічу, щоб виділитися на тлі аналогічних пропозицій, допомагає аналіз схожих сервісів. Один із способів визначити їх сильні і слабкі сторони - вивчити коментарі користувачів у сторах. Відгуки дозволяють розібратися, що подобається людям у доступних програмах, а що викликає невдоволення. Дослідження, які необхідні для опрацювання ідеї Добута в ході досліджень інформація допомагає сформулювати цілі та завдання програми, встановити вимоги до продукту, визначитися з набором фічів та розставити пріоритети: які функції потрібно реалізувати насамперед, а які відкласти на потім. Після затвердження функціональності приступають до проектування і складають карту екранів, яка візуалізує структуру програми та основні сценарії користувача. Схема відбиває, з яких розділів складається обслуговування, як вони взаємозалежні як і користувачі будуть перемикатися з-поміж них. Вона допомагає організувати контент та розробити зручну навігацію. Також карту екранів використовують, щоб оцінити зразковий обсяг завдань, написати технічне завдання, сформувати беклог, підібрати відповідні способи реалізації проекту, скласти графік робіт та кошторис. Далі команда починає створення дизайну мобільного додатка.Процес передбачає опрацювання двох аспектів: Відповідає за логіку роботи сервісу. Щоб зробити товар зрозумілим для користувачів, дизайнери продумують навігацію та меню, розташування кнопок та діалогових вікон. Визначає зовнішній вигляд програми. Щоб інтерфейс виглядав естетично, а користувачам було зручно взаємодіяти з ним, дизайнери підбирають кольори та шрифти, оформляють кнопки, іконки та текстові блоки, додають анімацію. Перед тим, як розпочати створення макетів екранів, важливо переконатися, що обрана концепція візуального стилю буде привабливою для користувачів. Для цього розробляють інтерактивний прототип – чорнову версію програми, яка демонструє приблизний дизайн та імітує базову функціональність. Прототип тестують на потенційних користувачах, щоб оцінити юзабіліті інтерфейсу та виявити слабкі місця. Якщо учасники фокус-групи висловлюють зауваження, концепцію допрацьовують з урахуванням отриманого зворотного зв'язку. Після узгодження концепції малюють фінальні макети всіх екранів. Їх розробляють з урахуванням гайдлайнів платформ: Human Interface Guidelines для iOS та Material Design для Android. У цих документах закріплені рекомендації, які допомагають зробити програму звичною для користувачів обох платформ. Також дизайнери розробляють UI Kit - набір компонентів та шаблонів інтерфейсу, які стандартизують оформлення базових елементів, забезпечують однаковість дизайну та дозволяють масштабувати програму в майбутньому. Різниця між UX та UI На етапі розробки дизайнерські макети передають програмістам, які перетворюють їх на працюючий продукт. Відповідають за реалізацію інтерфейсу користувача.За допомогою коду вони відтворюють оформлення інтерфейсу та роблять так, щоб кнопки, форми та інші елементи UI працювали коректно. Роботу прискорюють готові бібліотеки компонентів: розробники вибирають із них потрібні шаблони та адаптують під концепцію продукту. Займаються серверною частиною. Вони створюють інфраструктуру, яка обробляє дані, керує логікою продукту та забезпечує зв'язок із зовнішніми сервісами. Щоб забезпечити високу якість продукту, на протязі всієї розробки QA-інженери проводять тести. Починають із перевірки окремих функцій та взаємодії кількох блоків коду та закінчують оцінкою роботи системи цілком. Розглянемо найпоширеніші види тестування: Дозволяє переконатися, що всі функції програми працюють коректно. Уявімо, що користувач мобільного банку намагається переказати гроші. Якщо після натискання кнопки "Надіслати" на екрані з'являється повідомлення "Недостатньо коштів", хоча на балансі є потрібна сума, помилку потрібно виправити. Тестувальники симулюють ситуацію, коли безліч користувачів одночасно виконують будь-які дії у додатку. Наприклад, роблять покупки. Це дозволяє оцінити, як програма працює при високому навантаженні та виявити вузькі місця, які можуть призвести до збоїв. Оцінює інтуїтивність навігації, легкість пошуку необхідних опцій та швидкість виконання різних завдань. Для юзабіліті-тестів залучають представників цільової аудиторії. Зауваження та пропозиції реальних користувачів допомагають покращити програму. QA-інженери перевіряють, як додаток обробляє та захищає дані від витоку. Для цього вони тестують алгоритми шифрування, механізми автентифікації та захисту від кібератак. Наприклад, імітують дії хакерів.Тестування безпеки допомагає виявити вразливі місця у коді, якими можуть скористатися зловмисники. Коли тестувальники виявляють баги, вони фіксують їх у системі відстеження помилок із докладним описом проблеми та її можливих наслідків. Звіт передають розробникам, щоб вони виправили недоліки. Після внесення змін до коду проводять повторне тестування. Це дозволяє виправити більшість багів до релізу, щоб із ними не зіткнулися реальні користувачі. Основні види тестування Коли сервіс пройшов усі етапи тестування, його можна публікувати у магазинах додатків. Але перед цим важливо переконатися, що продукт відповідає вимогам платформ. Вони мають свої стандарти, які стосуються безпеки та продуктивності. Контент у додатку не повинен порушувати етичних норм та авторських прав. Якщо якихось правил не дотримано, власникам сервісу можуть відмовити у розміщенні продукту або видалити його зі стору після публікації. Для того, щоб привернути увагу користувачів, важливо правильно оформити сторінку програми в магазині. Опис має бути інформативним і чітко пояснювати, які переваги надає сервіс та чим він корисний для аудиторії. Скріншоти допоможуть показати, як виглядає інтерфейс та як з ним взаємодіяти. При цьому зображення повинні бути якісними та відповідати рекомендаціям платформи за розмірами та стилем. Додатково можна записати короткий відео, який наочно продемонструє ключові функції продукту. Завдання, які потрібно вирішити на етапі релізу та просування програми Після релізу робота над програмою триває.Важливо розвивати продукт, щоб він залишався конкурентоспроможним та відповідав потребам аудиторії. Для цього регулярно збирають фідбек, моніторять коментарі користувачів у сторах та аналізують ключові метрики сервісу. Наприклад, кількість активних користувачів, середню тривалість взаємодії з інтерфейсом, рівень конверсій та інші. Статистика та зворотний зв'язок допомагають зрозуміти, з якими проблемами стикаються клієнти та як покращити продукт. Згодом потреби аудиторії, цілі бізнесу та тренди ринку можуть змінюватися. Програма повинна адаптуватися до цих змін, щоб залишатися привабливою для користувачів. Завдання команди - постійно доопрацьовувати сервіс, у тому числі впроваджувати нові фічі та покращувати існуючі. Регулярні оновлення допомагають підтримувати інтерес до програми та забезпечують довговічність сервісу на ринку. Вартість розробки програми розраховується індивідуально, оскільки залежить від кількох факторів. Перерахуємо основні: Чим більше функцій заплановано у додатку, тим вища вартість реалізації проекту. Прості сервіси з мінімальним набором можливостей коштують дешевше, ніж складні продукти з унікальними фічами. Рішення про те, на яких майданчиках випускати програму - Android, iOS або обох відразу - також впливає на ціну. Наприклад, створення двох нативних сервісів для різних ОС обійдеться дорожче за кросплатформну розробку. Дизайн з унікальною анімацією, кастомними іконками та ілюстраціями збільшує вартість розробки. Створення мінімалістичного інтерфейсу з використанням стандартних компонентів платформи коштує дешевше. Якщо програма інтегрується із зовнішніми системами, наприклад, CRM, платіжними шлюзами або інструментами аналітики, це збільшує обсяг робіт і, відповідно, вартість проекту. Якщо проект потрібно реалізувати у стислий термін, до роботи залучають додаткових фахівців, що впливає на підсумкову ціну. Щоб визначити бюджет проекту, студії розробки часто використовують модель розрахунку годинник × ставка. Бізнес-аналітики разом з технічними фахівцями та дизайнерами підраховує приблизний час, який піде на виконання різних завдань, та множать його на робочу ставку. Наприклад, якщо створення програми займе 2 тис. годин, а команда працює за тарифом 5 тис. рублів на годину, вартість становитиме 10 млн. рублів. Чинники, від яких залежить вартість проекту Щоб мобільний додаток вийшов якісним та затребуваним у аудиторії, важливо підійти до процесу розробки системно, приділяючи увагу кожній деталі. Усі етапи – від досліджень та проектування до написання коду та тестування – можна довірити підряднику, який виконає проект «під ключ». Якщо замовник вже провів частину робіт, наприклад, підготував дизайн, компанія може взяти на себе інші етапи розробки. Співпраця з професійною студією дозволяє зосередитись на стратегічних завданнях бізнесу. Злагоджена робота команд розробників та замовника допомагає створити програму, яка задовольняє потреби користувачів та відповідає цілям компанії. Сьогодні ми заглибимося в питання розробки програм для різних мобільних операційних систем і знову спробуємо зрозуміти різницю між iOS та Android? Уявіть, що у вас у дворі лежить купа заліза, ви вимовляєте заклинання і раптом це залізо оживає і перетворюється на робота. Раніше такі речі називалися магією, тепер це називається програмуванням. Розробники за допомогою коду, по суті просто тексту, змушує дуже безглузду свідомість — комп'ютер або смартфон робити неймовірні речі. Вгадувати наші музичні уподобання, відстежувати пульс, управляти розумним будинком і так далі. Тому сьогодні ми дізнаємося, що стоїть за цією магією. Розберемося, що таке середовище розробки? Дізнаємося, чим відрізняються програми під iOS та Android? Що краще, нативні чи крос-платформні програми? Отже, розробити програму - це приблизно як зробити табуретку. Для цього вам знадобиться необхідний набір інструментів і приміщення, де ви пилятимете свою табуретину. На програмістському таке приміщення з інструментами називається середовище розробки чи по-науковому IDE. IDE - Integrated development environment - інтегроване (або єдине) середовище розробки Для Android таким середовищем розробки є Android Studio, а для iOS – Xcode. Середовище розробки – це просто програма, де є все, що вам потрібно для створення програми. Тут є: Окей, рухаємось далі. Програми під різні платформи пишуть різними мовами програмування. Більшість коду під iOS пишуть на Objective-C і Swift, а під Android на Java і Kotlin. Swift та Kotlin – це більш сучасні та доброзичливі мови програмування. Ці мови дуже схожі, аж до того, деякі ділянки коду можуть збігатися на 70% і навіть більше. Ось приклад функції, яка на основі поточного дня та виду погоди створює повідомлення про прогноз. Цікаво, що Swift створено лише для розробки під iOS. А ось на Kotlin можна писати під різні платформи і під Windows, і під Linux, і навіть під iOS. Думаю, це одна з причин радості розробників коли Kotlin додали в Android Studio. Це було на Google I/O у 2017 році. З мовами та середовищем розробки розібралися. Але з чого складаються програми і як вони працюють зсередини? Розберемо з прикладу Android. Тут усі додатки складаються з чотирьох основних компонентів, це: Щоб вас не вантажити, докладніше зупинимося на двох з них: Активностях і сервісах. Почнемо з активності. По суті це основний інтерфейс програми. Це порожнє вікно, в яке ми запихаємо текст, зображення, кнопки та інші елементи інтерфейсу. Як правило, активність займає повний екран, і по суті вона схожа на веб-сторінку. Активність може бути одна, або може бути кілька. І також як ми можемо перемикатися між веб-сторінками за допомогою гіперпосилань, ми можемо перемикатися між активностями за допомогою спеціального класу Intent (тобто намір), попутно передаючи інформацію про дії користувача, тобто його наміри. Кожна активність має свій життєвий цикл. Виглядає він так складно: Але якщо спростити, активність може бути в одному з чотирьох станів: А зараз важливий момент.Активність, вибачте за тавтологію, активна тільки коли інтерфейс користувача знаходиться на передньому плані. Як тільки інтерфейс іншої Активності закриває поточну, перша активність ставиться на паузу, або зовсім знищується. Іншими словами, активність не може працювати у фоні. Для цього в Андроїді існує інший компонент - сервіс (service) Сервіси дуже зручна штука. За допомогою сервісів в Android дуже легко можна реалізувати будь-які фонові завдання: відтворення музики, завантаження файлів, навігацію та інше. Складність тільки одна, можна дуже захопитися фоновими процесами і зжерти весь заряд акумулятора. А ось у iOS проблеми зовсім іншого роду. Як аналог Сервісів тут є жарт, який називається Background Task, тобто буквально фонове завдання. Ось тільки всі фонові процеси в iOS суворо регламентуються. Дозволено лише певні типи фонової обробки: типу відтворення аудіо, якщо ваша програма це аудіоплеєр, ну або навігація, якщо ви навігатор або якийсь фітнес-трекер. І те, вам ще доведеться надати вагому причину, що вам цей функціонал необхідний, інакше додаток просто не пройде сувору перевірку Apple. З плюсів: навряд чи якась програма зжере на тлі батарейку на вашому iPhone. З мінусів - вам доведеться постійно тикати в екран, поки вантажиться видосик в Telegram. Тим не менш, частково такі обмеження можна обійти та реалізувати практично те саме, що можна зробити на Android. Іншими словами, розробка для iOS та Android дуже схожа. Звідси виникає питання, а чи можемо ми написати одну програму, яка буде працювати і на iOS та Android? Насправді можемо, але із застереженнями. Коли перед розробником стоїть завдання погнатися за двома зайцями, тобто розробити додаток відразу під дві ОС. У нього є три шляхи: Отже, нативна технологія — це прямолінійний, зрозумілий, і при цьому, напевно, найвитратніший шлях. Від англ. native - рідний, природний У цьому випадку під кожну операційну систему пишеться окремий додаток із використанням рідних для цієї системи мов та інструментів, тобто для iOS нативні додатки пишуться в середовищі розробки Xcode мовами Objective-C та Swift. А для Android використовують Android Studio та мови Java та Kotlin. Нативні програми вважаються найшвидшими, надійнішими і взагалі почуваються в рідній ОС як удома. Кожен такий додаток, як костюм пошитий на замовлення. З переваг такий костюм ідеально сидить, з недоліків для кожної ОС доводиться шити свій окремий костюм. Тому існує дуже приваблива ідея крос-платформної розробки. Уявляєте, ви пишете один код, який працює на різних платформах. Звучить як справжня мрія замовника. Потрібно вдвічі менше розробників, удвічі менше часу і, суто теоретично, удвічі менший за бюджет. Більше того, є безліч інструментів, тобто фреймворків, які дозволяють це зробити: React Native, Flutter, Xamarin, Cordova, Ionic, Titanium Appcelerator, Vue Native. Найпопулярніші — React Native та Flutter. Природно, кожен з таких фреймворків обіцяє, що їхній крос-платформний додаток буде нічим не гіршим за нативний, але на практиці все не так. У більшості випадків, крос-платформна програма буде працювати повільніше нативного, при цьому буде більше багів і більше проблем із сумісністю, коли виходить нова версія ОС. Тому в довгостроковій перспективі, крос-платформна технологія може вийти навіть дорожче за нативну. Ну а гібридний підхід поєднує обидві ці ідеї, коли якісь шматки додатка пишуться як крос-платформні, а якісь як нативні. Але який із цих підходів крутіший?
Нативні програми — програми, створені за допомогою інструментів, які надають власники операційної системи. Зазвичай вони виглядають найбільш органічно серед «рідних» програм ОС. Але для кожної системи потрібно робити свою версію програми, так як у всіх різні інструменти для створення таких програм. Крос-платформні програми створюються за допомогою спеціальних інструментів, які дозволяють запускати один і той же код на різних платформах. Замислювалося, що це дозволить скоротити вартість розробки за рахунок компромісного підходу до зовнішнього вигляду програми та її продуктивності. Гібридні додатки поєднують у собі нативні та крос-платформні частини. Можна сміливо сказати, що є проявом тривалого, а то й нескінченного, пошуку балансу між вартістю розробки програми та її здатністю приносити користь бізнесу. Будь-яка програма розробляється для досягнення якоїсь мети. При виборі технологій важливо враховувати кілька факторів, які можуть бути не завжди очевидними: Як приклад можна розглянути гіпотетичну програму для невеликого навчального порталу. Припустимо, є хлопці, які займаються створенням навчальних відеокурсів і вони хочуть зробити додаток для того, щоб користувачі могли дивитися ролики в дорозі та без інтернету. Крос-платформний підхід, наприклад React-Native, тут може добре спрацювати. Чому? А тому що завдання не складне. По суті, треба реалізувати ряд досить простих фіч типу: авторизація, перегляд списку доступних курсів, перегляд самих курсів та їх покупка. Тому шансів, що щось піде не так на різних платформах, дуже мало. А заощадити кошти вийде пристойно. Тому крос-платформа для таких випадків є дуже логічним підходом. Який підхід використовувався під час розробки програми «МойОфіс Документи»? Наш додаток можна розглянути як показовий приклад нативної програми. Розкажемо докладніше, із чого воно складається. Додаток “Мій Офіс Документи” можна розділити на дві частини: ФМ — приклад класичного набору щодо стандартних функцій: авторизація, робота з мережею, показ списку об'єктів за допомогою стандартних UI елементів. Редактори – зовсім інша історія. Їхнім «серцем» є загальне ядро, написане на C++. За рахунок цього ми отримуємо повну уніфікацію того, як виглядають і поводяться редактори на всіх платформах, на яких ми вміємо працювати. Ціна цієї уніфікації конкретно нашого додатка — необхідність роботи з C++, якою мовою складно назвати стандартною для мобільної розробки. Що цікаво, через ядро ми можемо назвати наш додаток гібридним, т.к. у ньому є крос-платформна частина. Різниця лише в тому, що в такій крос-платформі код ядра працює навіть швидше, ніж якби він був написаний на наших «нативних» Java та Kotlin. Крім ядра, у нас є нестандартні елементи інтерфейсу, які так само критичні до продуктивності. Я люблю наводити як приклад логіку рендерингу документів. Цей компонент складається з двох частин: логіка ядра, яка малює вміст документа в буфері та логіка малювання цього буфера вже на екрані. Чому так працює – окрема історія, але зараз важливо, що це дозволяє нам знаходити баланс між швидкістю малювання вмісту та ефективним споживанням пам'яті та CPU. (Тут потрібно вставити відео в якому включений developer mode в рендерингу, додасть наочності) Загалом наш додаток складно назвати «тривіальним» з точки зору розробки. Ми маємо як стандартні речі, так і дуже вимогливі до продуктивності компоненти, проблеми в яких наші користувачі помічають дуже швидко. Тому ми спочатку робимо наш додаток максимально нативним.Це дозволяє сконцентруватися на бізнес-завданнях замість боротьби з крос-платформними фреймворками для того, щоб вичавити з них максимум продуктивності. Під яку платформу складніше програмувати iOS чи Android? Після спільних обговорень ми дійшли висновку, що складність саме у роботі приблизно однакова. Обидві системи сьогодні стрімко рухаються у загальному напрямі як у фічах, і за підходами до розробки (kotlin ~ swift, ComposeUI ~ SwiftUI). Відмінності, звичайно, залишаються, але вони не такі значні, щоб про них говорити в контексті "складніше-простіше". Інше питання, що поріг входу в iOS, як і раніше, вище, ніж в Android: вам потрібен мак і айфон для того, щоб почати. А чи можна написати програму взагалі без коду? На сьогоднішній день дійсно існують технології, які дозволяють створювати певний вид додатків буквально не написавши жодного рядка коду. Щоб зрозуміти, як це працює, можна повернутися до попередньої теми. На розробку зручніше дивитися не бінарно (нативне або крос-платформне), а як безперервний процес пошуку найбільш оптимального способу вирішувати бізнес-завдання. Рухаючись від нативної до повністю крос-платформної розробки, ми також рухаємося шляхом абстрагування від конкретних платформ і ОС до технологій, які дозволяють сфокусуватися тільки на бізнес-завданнях. Зерокодинг — приклад крайнього становища на спектрі розробки. Тут на вас чекає безліч обмежень: зовнішній вигляд, потенційно реалізовані фічі, продуктивність, повна залежність від конкретної компанії. З іншого боку, ви маєте можливість запустити першу версію програми буквально за вихідні. А в деяких випадках це може бути дуже важливим. Підписуйтесь на Мой Офіс ВКонтакте, будьте в курсі новин розробки додатків.
Встановити безкоштовні редактори для вирішення повсякденних завдань домашнього комп'ютера або мобільного пристрою: ПК, Google Play Store, AppStore.
Як створити програму: від опрацювання ідеї до публікації в сторах
Як створити програму: від опрацювання ідеї до публікації в сторах
Способи створення програм
Нативна розробка
Кросплатформова розробка
Як створити мобільний додаток - етапи розробки
Дослідження та опрацювання ідеї
Проектування та планування
Дизайн
Розробка програми
Тестування програми
Реліз
Підтримка та оновлення
Як формується ціна на розробку мобільного додатку
Висновок
Як створюють мобільні програми? Розбір
І поставимо головні питання розробнику!Де розробляються програми?
Якими мовами пишуться програми?
З чого складаються програми?
iOS та фонові завдання
Нативні, крос-платформні та гібридні розробки