Що таке кросплатформенний мобільний застосунок і чим він відрізняється від нативного застосунку? Коли варто обирати кроссплатформенний підхід, та які його переваги та недоліки. Що має знати дизайнер для того, щоб ефективно взаємодіяти з розробниками та як правильно підійти до процесу дизайну — розповідає Макс Штомпіль,  продуктовий дизайнер у компанії Welltech, і куратор курсу Mobile Apps Design у Projector Online Institute.

Нативний застосунок розробляється з використанням нативних мов програмування, таких як Swift для iOS і Kotlin для Android. Він працюватиме лише на тій платформі, для якої він був розроблений. Кросплатформенний застосунок буде працювати на двох платформах одночасно.

Переваги кросплатформенного підходу:

• Одна команда розробників може писати код, який буде працювати на обох платформах. Для цього вже є готові фреймворки, наприклад Flutter від Google чи React Native від Meta.
• Краще підходить для стартапів та MVP-продуктів. Такі застосунки швидші та дешевші у розробці. Можна скоріше випустити застосунок, щоб перевірити гіпотезу, та якщо потрібно, швидко змінити курс свого продукту.

Недоліки кросплатформенного підходу:

• Гірший UX.
• Повільніша робота. Хоча зараз з розвитком технологій цей недолік стає менш помітним.

Для прикладу можна звернути увагу на такі відомі кросплатформенні застосунки, як Pinterest, Skype чи eBay. Навіть Instagram, колись починався, як кроссплатформенний застосунок і зараз містить частину функціонала, написану на React Native. А от Coinbase півтора року тому навпаки перейшов від нативної розробки до React Native.

Нижче наведена схема, яка пояснює, як це працює з точки зору розробки

Bridge виконує функцію трансформування кросплатформенного коду в нативний код

Дизайн кросплатформенних застосунків: два підходи

Існують два підходи до дизайну кросплатформенних застосунків:

#1 Створення однакового візуального дизайну для обох платформ

Прикладами таких застосунків є Pinterest та Coinbase.

Коли варто використовувати цей підхід?

• Якщо ви цілитесь на одну платформу, де є більшість користувачів, та готові пожертвувати нативним досвідом для іншої платформи.
• Якщо ви хочете розробити кастомний дизайн і забезпечити його ідентичність на обох платформах.
• Якщо у вас обмежений час на розробку та випуск продукту.

Для прикладу розглянемо застосунок Coinbase, на якому головний екран має однаковий дизайн для обох платформ, включаючи таби, кнопки, список та іконки.

#2 Створення нативного дизайну для кожної платформи (ще можна зустріти, як вираз platform specific).

Розробник, в цьому випадку, в коді вказує, що залежно від платформи ми показуємо різні компоненти.

Коли варто використовувати цей підхід?

• Якщо ви не маєте домінуючої платформи, а ваші користувачі розподіляються між платформами приблизно порівну.
• Якщо ви хочете надати нативний досвід для кожної платформи.

Ми можемо побачити це на прикладі компонентів на екрані “About” у застосунку Google Pay: на iOS використовується NavigationBar, а на Android – TopAppBar.

Дизайн кросплатформенних застосунків: з чого почати

Перше, що я порадив би зробити, — це поспілкуватися з розробниками та зрозуміти, який фреймворк та бібліотеку ви будете використовувати. Кожна бібліотека містить свій набір компонентів, який допоможе вам швидше створити дизайн для застосунку. Це така ж сама бібліотека компонентів, яку ми маємо як на iOS, так і на Android.

Вона може бути універсальною (один компонент для двох платформ). Наприклад, Slider в NativeBase

Або мати декілька компонентів, які відповідають підходу platform specific.

Ось, наприклад, модальні вікна в Ionic.

А ось Toggle/Switch:

Якщо ваша бібліотека не міститиме декілька компонентів, ви зможете попросити команду розробки їх створити.

Далі потрібно визначитися з підходом до дизайну. Якщо планується створення повністю кастомного застосунку, то все зрозуміло — ми просто робимо однаковий дизайн. Але якщо ви хочете, щоб ваш застосунок був ближчий до нативних застосунків, то я рекомендую зробити нативними ті компоненти, до яких ваші користувачі звикли в цих застосунках.

Наприклад, тайм пікери, тогли/світчі, модальні вікна та слайдери. Все інше можна робити однаковим. Важливо пам’ятати, що ми навіть у своїх нативних застосунках не завжди дотримуємося нативного дизайну для всього.

Також варто зазначити, що деякі бібліотеки мають можливість викликати нативні компоненти, тому їх використання буде дешевше, ніж створення власних компонентів, які мають однаковий вигляд на всіх платформах. Наприклад, компонент Time picker має кардинально різний вигляд на різних платформах, тому нативне використання цього компонента буде найкращим варіантом.

Готувати два окремих макети чи один універсальний для всіх платформ?

Я б рекомендував обмежитись одним макетом, особливо, якщо ви використовуєте constraints та auto layout. Це дозволить розробникам перевірити поведінку застосунку на різних розмірах екранів. Важливо при цьому розробляти дизайн для найменшого розміру. Для компонентів, що змінюються залежно від платформи, використовуйте помітки в Figma. Однак, якщо відмінності між екранами різних платформ значні, варто розглянути створення окремих макетів.

Важливо зазначити, що це мій особистий досвід, і перед прийняттям рішення щодо створення макетів, варто обговорити це з командою.

Процес створення дизайну може виглядати наступним чином:

1. Обираємо підхід до дизайну, враховуючи цілі та аудиторію проєкту
2. Обираємо фреймворк та бібліотеку для створення застосунку
3. Обговорюємо з командою кращий спосіб організації дизайн-процесу з урахуванням того, що ми проєктуємо для двох платформ
4. Створюємо крутий застосунок

Загалом кросплатформенна розробка є корисним підходом для створення мобільних застосунків. Все ж вибір підхожих інструментів та технологій залежить від конкретної задачі та потреб користувачів. В деяких випадках кросплатформенна розробка буде найкращим рішенням