Куда должен вести пуш

Диплинк ведёт на определённый экран приложения — целевую посадочную страницу. Когда такая ссылка приходит в пуше, текст уведомления подсказывает пользователю, что откроется после нажатия.

Допустим, приложение отправляет уведомление о статусе перевода, из которого должен открываться экран подтверждения этой операции. При нажатии на пуш пользователь рассчитывает сразу увидеть нужный перевод. Если переход заканчивается на главной, человеку приходится самостоятельно восстанавливать путь к операции.

Поэтому, перед тестированием сопоставьте текст уведомления с целевым экраном и зафиксируйте ожидаемый результат. Во время проверки нужно тестировать, что открылась именно та операция, о которой говорится в сообщении.

Как проверить переход при разном состоянии приложения

Один и тот же пуш нужно открыть в разных условиях. Например, на момент нажатия приложение полностью закрыто, телефон заблокирован и пользователю ещё предстоит пройти вход. Чтобы разобраться, на каком этапе теряется переход, сначала рассмотрим запуск и возвращение в приложение.

• Приложение закрыто. При холодном старте оно запускается и загружается, после чего должно продолжить переход к экрану из уведомления. Во время проверки проследите, куда пользователь попадает по завершении запуска.
• Приложение работает в фоне. Здесь проверяют возвращение из свёрнутого приложения и открытие целевого экрана. При действующей сессии пользователь должен продолжить работу в приложении; дополнительную перезагрузку при открытии пуша стоит разобрать с командой.
• Телефон заблокирован. Откройте уведомление с экрана блокировки и разблокируйте устройство с помощью Face ID или PIN-кода. После этого маршрут к нужному экрану должен сохраниться.
• Пользователь уже работает в приложении. Полученное уведомление открывают во время активной работы. Проверьте, как переход вписывается в текущую навигацию и вызывает ли он перезагрузку приложения.

Разблокировка телефона и вход в приложение могут оказаться отдельными этапами одного перехода. Если приложение запрашивает пароль, проверку продолжают до экрана, на который вело уведомление. При потере маршрута зафиксируйте, после какого действия открылся неожиданный экран.

Что происходит после повторного входа

В инвестиционном приложении сессия может завершаться после некоторого времени бездействия. Тогда пользователь открывает пуш и сначала попадает на экран входа. У команды должны быть согласованные требования к тому, как приложение поведёт себя после ввода пароля.

Вернёмся к примеру с акцией. Человек получает уведомление о резком росте её цены, открывает его спустя час и проходит повторный вход. Если в этот момент приложение возвращает его на главную, поиск нужной акции приходится начинать заново.

Чтобы продолжить переход после входа, приложение сохраняет его цель. Приложение и сервер передают сведения о том, какой экран хотел открыть пользователь, и после проверки пароля маршрут продолжается. Такой сценарий проверяют с завершившейся сессией: открывают уведомление, проходят вход и смотрят, какой экран появился.

Повторный запрос PIN-кода или возврат на главную нужно разбирать с учётом требований безопасности конкретного продукта. Если такое поведение предусмотрено, команда должна понимать, как оно влияет на переход по уведомлению. QA фиксирует результат проверки и обсуждает его с менеджером продукта.

Проверять нужно и параметры маршрута, передаваемые между приложением и сервером. С помощью отладочного прокси можно попробовать перехватить и изменить эти параметры, затем проверить, как приложение обработало переход. Отдельно нужно определить в требованиях, какие данные маршрута должны очищаться при выходе из аккаунта или удалении приложения, и проверить выполнение этих требований.

Что показать, если нужный экран недоступен

К моменту открытия уведомления целевой раздел может оказаться недоступен. Например, актив уже исключён из торгов или чат поддержки временно перестал работать. Для каждого случая приложению нужен понятный способ завершить переход.

На экране актива можно сообщить, что он больше не торгуется. В случае с поддержкой сообщение должно объяснить временную недоступность раздела и предложить вернуться позднее. Команде также нужно определить, куда перенаправить человека, чтобы он мог продолжить работу в приложении с сохранением контекста.

При тестировании воспроизведите недоступность целевого раздела и откройте ведущую к нему ссылку. Посмотрите, соответствует ли сообщение причине сбоя и куда человек может перейти с этого экрана.

Плохое интернет-соединение тоже нужно включить в условия проверки: оно может помешать загрузить содержимое после нажатия. Здесь нужно проследить, что происходит с переходом при проблемах с сетью и какое состояние приложения видит пользователь.

Как проверить одну ссылку в разных каналах

Один диплинк может использоваться в пушах, рекламных баннерах, письмах и СМС. Ссылку также размещают в QR-кодах, социальных сетях и мессенджерах. Команда должна проверить переход из каждого канала, где эта ссылка используется.

Ошибка может проявляться при открытии баннера: ссылка приводит на другой экран. Проверка этой же ссылки из пуша в таком случае проходит успешно. Чтобы найти проблему, нужно пройти оба пути и сопоставить результат с ожидаемым экраном.

При проверке сохраняйте связь между источником перехода и его результатом. Если ошибка воспроизводится из баннера, эту деталь нужно зафиксировать вместе с самой ссылкой. Тогда команда сможет повторить тот путь, на котором возникла проблема.

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

Как организовать работу с диплинками

Когда ссылки используют разные команды, их удобно собрать в общем реестре. Он помогает найти нужный диплинк и увидеть, для чего тот создан, кто за него отвечает и когда его проверяли. Для ведения реестра подойдёт таблица в Excel или встроенный инструмент сервиса, в котором создаются ссылки.

В запись о каждом диплинке можно включить следующие поля:

• название или ID диплинка;
• цель перехода;
• тип диплинка;
• параметры;
• статус;
• ответственный;
• дата создания;
• дата последней проверки;

Когда диплинк перестаёт работать, в реестре можно найти его ответственного и договориться о замене. После изменения логики перехода ссылку проверяют повторно и обновляют дату проверки.

Подготовленные требования к переходам и реестр ссылок помогут сформулировать задачу для внешней команды QA. Centicore Group проводит функциональное тестирование приложений на соответствие требованиям и разрабатывает тестовые сценарии под задачи проекта.

Итого

Проверку перехода завершают на экране, ради которого пользователь открыл уведомление, с учётом всех промежуточных шагов. Для недоступного раздела заранее согласуют содержание сообщения и дальнейший переход. Эти результаты нужно зафиксировать для каждого условия проверки, включая повторный вход и открытие ссылки из разных каналов.

Для приложения с серверной выдачей контента это означает, что пользователь заплатил и несколько часов не получает подписку или покупку. Google зафиксировала инцидент Play Billing 1 сентября с 08:54 до 11:43 UTC и объявила о решении в 13:59 UTC, но по данным отчёта задержки продолжались и после закрытия инцидента. Официального комментария Google к отчёту на момент публикации нет.

• Две задержанные транзакции: от покупки до RTDN 3 ч 55 мин 40 с и 2 ч 11 мин 55 с; доставка уже созданного события на сервер заняла 0,6 и 1,4 с.
• Девять нормальных транзакций того же периода: 0,086–0,148 с до eventTimeMillis, доставка 0,3–2,3 с.
• Pub/Sub со стороны разработчика работал: максимум одно неподтверждённое сообщение возрастом до 3 с, push-запросы завершались ack_200, максимальная задержка push 4,5 с.
• Затронуты и одноразовые покупки, и подписки, в нескольких странах и валютах; Россия в отчёте не названа.
• Официальный инцидент Play Billing: 1 сентября, 08:54–11:43 UTC; отчёт утверждает, что задержки были и позже.

Где именно терялось время

Автор отчёта разложил путь уведомления на два отрезка. Первый: от завершения покупки до момента, когда Google создала событие (это и есть eventTimeMillis, время события в миллисекундах Unix). Второй: от создания события до получения его сервером через Pub/Sub. Второй отрезок оставался быстрым, 0,6 и 1,4 секунды в проблемных случаях. Всё время ушло на первый: уведомление не доходило часами, при том что метрики Pub/Sub со стороны разработчика чистые: очередь пустая, подтверждения приходят, задержка доставки в пределах секунд. На каком именно внутреннем этапе у Google застревало событие, по этим данным установить нельзя.

Есть оговорка, которую автор делает сам: он не сохраняет внешнее поле publishTime из конверта Pub/Sub, поэтому не может доказать, где именно внутри инфраструктуры Google лежала задержка, до публикации в Pub/Sub или после. Вывод о том, что событие создавалось поздно, сделан по eventTimeMillis.

Почему RTDN нельзя считать единственным источником правды

Документация Google требует после получения RTDN вызывать Developer API: уведомление не содержит полного состояния покупки. Этот случай добавляет к этому редакционный вывод: уведомление может прийти поздно или, в худшем сценарии, не прийти вовремя вообще. Если сервер выдаёт доступ только по RTDN, при задержке пользователь остаётся без оплаченного. Если клиент после покупки сам сообщает серверу токен покупки, а сервер проверяет его через Developer API, задержка RTDN ни на что не влияет.

Что проверить в своём приложении

1. Убедиться, что клиент после успешной покупки отправляет purchase token на сервер, а сервер подтверждает его через Google Play Developer API, не дожидаясь RTDN.
2. Логировать eventTimeMillis и publishTime из конверта Pub/Sub вместе с временем получения, чтобы при следующем инциденте было видно, на каком отрезке задержка.
3. Проверить логи за 1–2 сентября на покупки, у которых разница между временем оплаты в клиенте и RTDN больше нескольких минут.
4. Не завязывать acknowledge покупки только на RTDN: неподтверждённая в течение трёх дней покупка возвращается пользователю автоматически.

Отчёт говорит о нескольких странах и валютах, но Россию не называет; учитывая, что оплата в Google Play российскими картами не работает с 2022 года, задержки касаются в первую очередь приложений с зарубежной аудиторией. Что ещё менялось в правилах Play в последние дни: требование к AnkiDroid убрать ссылку на пожертвования и стабильный релиз Android Studio Quail 4. Появится ли по этому отчёту официальный ответ Google или новая запись в статусе Play Billing, мы проверим.

Источники: Отчёт разработчика в сообществе Google Play, Google Play Status Dashboard: инцидент Play Billing, Справочник RTDN

История касается не только AnkiDroid. Правило, на которое ссылается Google, запрещает вести пользователей к оплате мимо Google Play Billing; пожертвования допускаются лишь для организаций с подтверждённым налоговым статусом благотворительной и на определённых условиях. У большинства open source-проектов таких документов нет.

• Google Play счёл ссылку AnkiDroid на Open Collective нарушением Payments Policy; первое уведомление пришло 20 июля, документы проекта Google 7 августа не принял.
• Требование: убрать ссылки на платежи вне Google Play Billing или подтвердить статус tax-exempt организации; сам Play Billing для пожертвований таких организаций запрещён.
• Дата удаления при отсутствии исправления: сначала 3 августа, затем 11 сентября 2026 года, оба раза с оговоркой «везде, кроме Индии и России»; причина исключения не объяснена.
• AnkiDroid связан с организацией статуса 501(c)(6), в приложении ничего не продаётся, Open Collective — единственный источник денег; мейнтейнеры убирают ссылки из Play-сборки ветки 2.24.x.
• Разработчикам с кнопкой «поддержать» в бесплатном приложении: ссылка на внешнюю площадку без статуса благотворительной организации — ровно случай AnkiDroid.

Что именно нарушил AnkiDroid

По тикету Google номер 9-2777000041594, нарушение относится к Payments Policy: внутри приложения была ссылка на Open Collective, платформу, через которую проект собирает пожертвования, а проблема помечена для сборки с version code 122400300. Google предложил два выхода: убрать все ссылки, «направляющие пользователей на оплату через системы, отличные от биллинга Google Play», либо доказать, что AnkiDroid — организация со статусом tax-exempt, освобождённая от налогов по американским правилам.

Remove any links directing users to make payments using systems other than Google Play's billing system.

Загвоздка в том, что политика Google одновременно запрещает использовать сам Google Play Billing для пожертвований освобождённым от налогов организациям, а AnkiDroid связан с организацией статуса 501(c)(6), профессиональной ассоциацией, а не благотворительным фондом. То есть донаты через Play невозможны, а ссылка наружу запрещена. Команда отдельно подчёркивает, что в приложении ничего не продаётся, Open Collective — единственный источник финансирования, а сам AnkiDroid не связан с Anki, AnkiWeb, AnkiMobile и AnkiHub.

Хронология

• 20 июля 2026 года: первое автоматическое уведомление Google с датой удаления 3 августа «везде, кроме Индии и России».
• 7 августа: Google сообщил, что присланные документы нарушение не устранили.
• Позднее уведомление: новая дата удаления 11 сентября 2026 года с той же региональной оговоркой.
• 29 августа: мейнтейнеры открыли issue #21656 с просьбой о помощи сообщества и решением убрать ссылки «под протестом».
• 1 сентября: обсуждение на Hacker News; изменений в позиции Google в issue нет.

Почему Индия и Россия отдельно

В уведомлениях Google оба раза называл дату удаления приложения из Play «везде, кроме Индии и России». Причина исключения в переписке не объясняется; в issue нет и подтверждения, что удаление где-либо уже произошло. Для пользователей из России это означает лишь то, что из Play приложение не пропадёт. Для разработчиков, которые распространяют приложение и через RuStore или прямой установкой, напрашивается редакционный вариант: держать ссылки на пожертвования только вне Play-сборки; AnkiDroid подтвердил лишь удаление ссылок из сборки для Play.

Что проверить в своём приложении

• Найдите в приложении все ссылки на внешние платежи: Boosty, Patreon, Open Collective, «Купить кофе», номера кошельков, QR-коды. Ссылка на площадку пожертвований без подтверждённого статуса благотворительной организации — ровно случай AnkiDroid.
• Разделите сборки: в версию для Google Play ссылки не включайте, в сборку для F-Droid, RuStore или прямой загрузки APK оставьте.
• Не рассчитывайте на «объяснить в апелляции»: AnkiDroid отправлял документы, Google 7 августа ответил, что нарушение не устранено.
• Если приложение платное или с подпиской, донаты как отдельный товар возможны только через Google Play Billing с его комиссией, и только если вы не благотворительная организация.
• Держите под рукой историю уведомлений: первое письмо AnkiDroid получил 20 июля, а дедлайн подошёл через шесть недель.

Что дальше

Ближайшая веха — сборка ветки 2.24.x без ссылок на донаты. Дата 11 сентября покажет, выполнит ли Google угрозу удаления в остальных странах. Реакцию Google на публичность ждать имеет смысл, но на момент публикации в issue никаких изменений позиции магазина нет, а сам Google на запросы в треде не отвечал.

Источники: Issue #21656 в репозитории AnkiDroid, Обсуждение на Hacker News

Изображение на обложке: AnkiDroid

Quail 4 — финальный стабильный выпуск линейки Quail, и автор анонса, менеджер продукта Android Studio Амман Фасил Асфав, называет её «готовой к использованию в продакшене». Помимо локальной модели в IDE вошли 23 готовых «навыка» агента под типовые задачи Android, кликабельные ссылки на классы и методы в ответах, индикаторы состояния в списке чатов и сворачиваемый показ рассуждений модели.

• Android Studio 2026.1.4 (Quail 4) стабильна; это последний выпуск линейки Quail.
• Gemma 4 работает локально через встроенный движок инференса; код не покидает машину, лимитов на токены нет.
• Минимум 12 ГБ оперативной памяти для самых маленьких моделей; по словам Google, «машины с 32 ГБ и больше будут работать лучше всего».
• 23 встроенных навыка агента (AGP 9 Upgrade, Android Profiler, Navigation 3, Adaptive и другие) выбираются автоматически по запросу и отключаются одним переключателем.
• Локальный режим включается в Agent model selector или в Settings, Tools, AI, Model Providers, Gemma; веса IDE скачивает, проверяет и обновляет сама.

Как устроена локальная модель

Android Studio сама скачивает веса Gemma 4, проверяет их и обновляет. Внутри IDE работает лёгкий движок инференса, поэтому отдельный сервер вроде Ollama поднимать не нужно. Модель выбирается в переключателе Agent model selector или в настройках: Settings, Tools, AI, Model Providers, Gemma. После этого агент работает локально: анонс подтверждает многофайловые рефакторинги полностью офлайн; остальные сценарии облачного агента Google для локального режима отдельно не перечисляет. Google подчёркивает два свойства: исходный код не покидает локальную машину, и квоты на токены не действуют.

Your source code never leaves your local machine and you never hit token quota limits.

Требования к железу компания называет прямо: самые маленькие варианты Gemma 4 стартуют на 12 ГБ оперативной памяти, а лучше всего работают машины с 32 ГБ и больше. На ноутбуке с 16 ГБ, где рядом крутятся эмулятор и Gradle, стоит ожидать, что локальная модель окажется медленнее и заметно проще облачной. Это цена за приватность и отсутствие квот, и оценивать её нужно под свой проект: по нашему опыту, многофайловый рефакторинг на маленькой модели требует больше ручных проверок, чем на облачной.

Что такое навыки агента

«Навык» здесь — заранее написанная инструкция с контекстом под конкретную задачу Android: как обновить проект на Android Gradle Plugin 9, как читать данные профилировщика, как переехать на Navigation 3 или сделать адаптивную вёрстку под планшеты и складные устройства. В Quail 4 таких навыков 23, и IDE подбирает их по метаданным запроса сама. Если подбор мешает, навыки отключаются общим переключателем в настройках IDE.

Что ещё изменилось в интерфейсе агента

• Ссылки на классы, функции, методы и пути файлов в ответах агента стали кликабельными.
• В списке Recent Chats появились индикаторы: загрузка, ожидание ввода, завершение фоновой задачи.
• Вкладки Task и Walkthrough объединены во вкладку Summary of Changes; по ней стоит проверять правки перед применением.
• Рассуждения моделей с режимом reasoning показываются сворачиваемым блоком.

Что менять в проекте и процессе

• Обновите Android Studio до 2026.1.4 через Check for Updates; проект менять не нужно.
• Если в компании запрещено отправлять код во внешние сервисы, включите Gemma в Model Providers и убедитесь, что облачный провайдер в настройках не выбран.
• Проверьте память: 12 ГБ — заявленный минимум для самых маленьких моделей, 32 ГБ и больше — рекомендация Google; на 16 ГБ закройте эмулятор перед работой агента или пользуйтесь физическим устройством.
• Для миграции на AGP 9 попробуйте одноимённый навык: это задача с сотней мелких правок, где агент экономит время.
• Региональных оговорок в анонсе нет, но доступность загрузки весов из России Google не подтверждает; проверяйте на своей машине. Локальный режим не требует подписки на облачные модели.

Контекст

Линейка Quail шла к этому весь цикл: в Quail 2 появились параллельные чаты с агентом, затем навыки, интеграция с Firebase и первая поддержка локальных моделей в Canary-сборках. Quail 4 закрывает линейку и делает локальный режим штатным в стабильной версии. Следующая линейка Android Studio получит новое кодовое имя; сохранится ли в ней локальная Gemma как основной сценарий, Google не говорит, и это предположение редакции по тону анонса.

Источники: Leverage Android skills and Gemma 4 in Android Studio Quail 4 (Android Developers Blog), Android Studio release notes

Изображение на обложке: Google, Android Developers Blog

Попытка №1. Путь в лоб: Классы и интерфейсы

Самый очевидный способ - создать родительский класс с переменными, а языки сделать его наследниками. Но это просто… фиаско. Даже если не писать from/toJson, процесс выглядит так:

1. Объявил переменную в родителе.
2. Прописал её в конструкторе.
3. Повторил то же самое для всех дочерних классов (всех языков).

Если бы я работал на аутсорсе в Индии и мне платили за количество строк кода - это был бы идеальный вариант. Но я хотел, чтобы одной строки при объявлении было достаточно.

Попытка №2. Стандарт (ARB/JSON)

Я поплевался, но решил попробовать - «стандарт» всё-таки. Мало ли, может чего поменялось за годы. Вроде всё завелось, но сам процесс… это боль. Бегать по разным файлам, чтобы добавить одну строчку - так себе удовольствие.

Почему я от него окончательно отказался? Когда данных становится реально много (десятки языков, тысячи строк), ты попадаешь в ловушку: тебе нужно эту махину либо целиком держать в памяти, либо постоянно подгружать и парсить. Ради смены одного слова на кнопке заставлять девайс ворочать тяжелые JSON-ы в рантайме - так себе затея для производительности.

Попытка №3. Таблицы и костыли

Подумал: «Окей, почему бы не подтянуть старый добрый CSV или вообще закинуть всё в табличку?». И тут официальный пакет локализации сказал: «Извини, мужик, тут наши полномочия всё».

Ну, я тоже не пальцем деланный. Решил припахать нейросеть, чтобы она написала мне собственный генератор. Флоу получился такой:

1. Добавляю строку в таблицу.
2. Запускаю генератор.
3. Он лепит «родительский» файл.
4. После Freezed генерит toJson, fromJson…

Короче, весело не было. Мало того, я понимал: если языков станет много, мне придется добавлять их все разом и единовременно, иначе в рантайме всё начнет плеваться ошибками. Плюс та же проблема с памятью: таблица - это структура, которую надо парсить и хранить.

Красный флаг для программиста

Но главная проблема даже не в этом. Необходимость запускать генератор после добавления каждой переменной - это для любого программиста красный флаг.

Что происходит на практике? Когда ты пишешь код и тебе нужно добавить одну несчастную строку, тебе лень (читать: нехочется выходить из потока творения) запускать весь этот цикл с генерацией. Ты просто её хардкодишь в надежде «потом скопом всё добавлю одним махом». А «потом» наступает тогда, когда уже весь проект завален хардкодом, и вычищать его - то еще удовольствие. Даже нейросетки с такими запросами помогают не с первого раза, и с сомнительной эффективностью.

Нутром чуял - флоу неправильный. В итоге я пришел к тому, что называю идеальной локализацией.

Эволюция лени: почему Enum победил интерфейсы

Я начал мучить нейросеть разными вариантами реализации. Для меня в первую очередь был важен флоу работы: мне было тупо лень писать больше одной строки кода, чтобы добавить переменную.

Моя философия проста: строку захардкодить - моментально. Добавление даже одной строки в другом файле требует доп. действий. НО, если действий минимум, то кодер поймет, что выигрыш во времени сейчас мизерный против больших потерь в будущем, и исправно добавит строку в правильное место. Этого не произойдет, если для добавления строки нужно «отчитаться» в десяти местах.

Попытка №4. Рекорды (Records)

Присматривался к рекордам. С ними удобно: не нужно писать конструкторы. Но есть подвох: как только ты добавил переменную в один язык, компилятор тут же сходит с ума и требует добавить её во все остальные прямо сейчас. Никакой гибкости и возможности оставить «на потом».

Идеальный костыль: Enum

В итоге я пришел к самому, казалось бы, «неправильному» способу, который оказался идеальным. Enum. Само название намекает на перечисления и цифры, но оказалось, что хранить в нем буквы и целые фразы - это лучший путь для локализации.

Знаете, мне моё решение так понравилось, что я пошел к нейросетям и проверил его со всех сторон. Все модели остались в полном восторге. Под это дело я даже подготовил монументальную «нейро-статью» на полтора часа внимательного чтения, со всеми графиками, бенчмарками и анализом производительности.

Но потом я заглянул в правила Хабра, прислушался к голосу разума и понял: никто не хочет читать полтора часа сухой статистики. Лучше я просто расскажу вам свою историю «от первого лица», как я докатился до такой жизни. Ну, а если вы совсем уж фанаты цифр - просто скормите этот текст любой нейронке, она вам перескажет всё в лучших академических тонах с графиками на любой вкус.

А здесь мы будем говорить по делу.

Ниже я выкатываю сам код. Код тут не для зубрежки, а лишь чтобы указать направление / идею. Самая большая прелесть этой системы в том, что она оставляет гигантское пространство для любого типа реализации. Это архитектурный каркас, который чертовски сложно сломать. Главное — уловить принцип.

Реализация

Принцип разделения:

• enum Strings → типизированный контракт (что существует).
• translator → источник данных (откуда берётся текст).

Структура файлов - минимальная. Никаких внешних зависимостей:

Ядро - strings.dart

Весь контракт локализации в одном enum. Два режима - хардкод switch и серверный кеш - за одним и тем же

. Даже сообщения об ошибках локализации — сами локализованы:

Список языков - languages_enum.dart

Каждый язык - самодостаточная единица: знает свой код, название, направление текста и как себя загрузить:

Хотите грузить с сервера? Одна строка + loader. И

- тоже одна строка, потому что

уже является registry:

Переводчик - i18n/russian.dart

Как это выглядит в жизни (и почему я перестал хардкодить) Я намеренно не привожу здесь код оберток виджетов или конкретных стейт-менеджеров. Всё это - чистая «вкусовщина». Для работы системы нужен лишь элементарный вещатель событий (Notifier), повешенный на метод смены языка.

Но главное - это мой ежедневный флоу. Сейчас, чтобы добавить строку в UI, я просто вызываю нужный мне ключ: Strings.someKey(). Без контекста, везде.

А если ключа еще нет? Я тупо иду в Strings и добавляю одну строчку в Enum. Всё.

Благодаря дефолтному конструктору, приложению абсолютно плевать, что у меня там еще 100 языков не переведены. Оно компилируется и работает здесь и сейчас. А дальше в дело вступают гит-хуки: при комите нейросетка сама подхватывает изменения и заполняет недостающие поля в переводчиках.

Знаете, какое самое странное чувство? Мне сейчас реально проще и быстрее завести переменную в локализации, чем хардкодить строку в коде. Кажется, это и есть признак здоровой архитектуры - когда делать «правильно» становится физически удобнее, чем делать «быстро» и криво.

Собственно если в кратце это все о чем я хотел рассказать. Если тема зайдет или кто-то сам не сможет допереть, как прикрутить это к своей архитектуре - пишите в комментариях, разберемся.

Надеюсь, мой опыт сэкономит вам пару литров нервных клеток. Всех благ и чистого кода без «магических строк»!

Почему эта схема вообще появилась? Из-за дефицита кадров в ИТ, который давно превратился в постоянный фон для компаний, занимающихся цифровыми продуктами. Найти миддла или синьора занимает два-три месяца, а в узких технологических стеках — и того дольше. Пока идёт поиск, проекты стоят или перегружают команду. И тогда возникает спрос на альтернативные способы работы с ИТ-персоналом.

Разберём, как устроен аутстаффинг, чем он отличается от аутсорсинга ИТ-специалистов и при каких задачах находить кадры через провайдера – хорошее решение.

ИТ-аутстаффинг и штат: в чем разница

Штатный найм — это прямые трудовые отношения. Работодатель оформляет сотрудника к себе и ответственен за налоги, взносы, отпуска, больничные и кадровое сопровождение. Специалист становится частью корпоративной структуры и, как правило, видит своё дальнейшее развитие внутри этой компании. Это привычная схема для обеих сторон.

При ИТ-аутстаффинге компания-провайдер трудоустраивает специалиста у себя и передаёт его заказчику — на срок или под проект. Схема иначе выстраивается юридически, но с точки зрения ежедневной работы разницы нет. Заказчик ставит задачи и требует результатов. Провайдер отвечает за зарплату, кадровый учёт и трудовые гарантии.

Отличия двух моделей — в таблице:

Ещё один вопрос, который нередко возникает: чем аутстаффинг отличается от аутсорсинга. При аутсорсинге заказчик отдаёт задачу внешней команде и принимает результат — без погружения в то, как команда работает изнутри. При аутстаффинге он получает конкретного человека и управляет им сам. Это разные форматы с разной логикой применения: первый — про готовый результат, второй — про ресурсы.

А как вообще контролировать человека, которого не нанимал? Да ровно так же — через задачи, метрики, совместные инструменты. Трудовой договор тут ни при чём. Меняется только то, кто его подписывает и кто несёт кадровые обязательства.

Преимущества аутстаффинга разработчиков

Классический рекрутинг никуда не уходит, но иногда аутстаффинг гораздо эффективнее. Итак, каковы же преимущества этой формы найма?

Аутстаффинг в ИТ: быстрое масштабирование без кадровой нагрузки

Найти сильного специалиста в команду в среднем занимает два-три месяца — и это при активном поиске. Часто бывает так, что людей в команде не хватает, потому что проект стремительно растет. Запуск нескольких параллельных процессов поиска кадров рискует затянуться. И тогда бизнес обращается к провайдеру, чтобы добрать нужное количество специалистов. Провайдер предлагает кандидатов, имеющих релевантный опыт в конкретном технологическом стеке, уже через одну-две недели, иногда – быстрее. Разница ощутима, особенно когда дата запуска проекта уже стоит в календаре.

Особенно это важно, когда приходится одновременно масштабировать несколько направлений. Привлечь четверых-пятерых специалистов через провайдера — это один договор и один процесс согласования, а не пять отдельных рекрутинговых потоков с непредсказуемыми сроками.

Экономит бюджет и снижает операционные затраты

Содержание штатного сотрудника — это не только зарплата. К ней добавляются расходы на рекрутинг (в среднем одна-три месячные выплаты), обустройство рабочего места, обучение, страховые взносы, налоги и кадровое администрирование. При аутстаффинге эти статьи уходят к провайдеру — заказчик платит прозрачную ставку по договору.

По завершении проекта не нужно думать о выходных пособиях или процедурах сокращения. Вопрос закрывается условиями договора с провайдером. При сравнимой квалификации специалиста совокупные расходы на аутстаффинге нередко оказываются ниже, чем на штатного сотрудника — если считать в полном объёме.

Дает доступ к широкому пулу технических компетенций

Провайдеры, предоставляющие аутстаф разработки, держат в базе специалистов самых разных профилей — серверные разработчики, системные

архитекторы, тестировщики, технические аналитики. Для заказчика это означает возможность подобрать человека с нужным стеком без ограничений локального рынка.

Именно поэтому аутстафф программистов особенно востребован у компаний, работающих с редкими или нестандартными технологиями. Найти такого специалиста «в штат» часто сложнее и дороже, чем привлечь через провайдера с обновляемой базой кандидатов — особенно если речь о нишевых стеках с ограниченным предложением на рынке труда.

Специалисты с разнообразными опытом

Разработчики на аутстаффинге, как правило, обладают более широким техническим кругозором, чем их штатные коллеги: они успели поработать в разных командах, с разными стеками и типами задач. Это даёт им гибкость мышления и насмотренность, которую сложно получить, годами работая в одном продукте.

Кроме того, проектный формат держит таких специалистов в тонусе: нет возможности погрязнуть в рутине.

Снижение административной нагрузки

Прежде чем новый штатный разработчик напишет первую задачу в трекере, кадровый отдел потратит время на оформление, бухгалтер — на налоговый учёт, юрист — проверит трудовой договор. Это нормально для штатного найма — но это реальные часы и ресурсы. При аутстаффинге вся эта работа остаётся за провайдером.

Для компаний, которые одновременно закрывают несколько направлений, это особенно ощутимо. Пятеро специалистов через провайдера — это пять ставок в одном договоре. Пятеро штатных — это пять кадровых дел, пять налоговых расчётов, пять пакетов документов. Разница в операционной нагрузке очевидна.

Когда аутстаффинг выгоднее штатного найма

Модель аутстаффинга в ИТ работает лучше всего в нескольких конкретных ситуациях — давайте суммируем, когда лучше всего задуматься именно об этом варианте найма.

• Проектная работа с ограниченным горизонтом. Нанимать разработчика в штат на полгода-год — нецелесообразно: по завершении проекта появляются расходы на сокращение или переобучение. Аутстаффинг закрывает задачу без лишних обязательств на выходе.
• Срочный рост команды. Продукт запускается через три месяца, а нужны ещё три специалиста прямо сейчас. Классический рекрутинг не успеет. Провайдер может дать команду параллельно, без разрыва в темпе разработки.

Нишевые технологии и редкие стеки. Когда нужен человек с узкой экспертизой, которых на локальном рынке единицы — провайдер с

• широкой базой найдёт быстрее и, скорее всего, дешевле, чем собственный подбор.
• Тест гипотезы без обязательств. Компания запускает новое направление, но не уверена в его горизонте. Аутстаффинг позволяет собрать команду, быстро оценить гипотезу и выйти без кадровых последствий, если направление не пошло.

У модели есть и ограничения, которые важно учитывать. Главный риск — зависимость от провайдера: если партнёрство прерывается досрочно, специалист уходит вместе с накопленным знанием о проекте. Для критически важных функций это серьёзно. Поэтому разумный подход — смешанный: ключевые роли закрывать штатом, а аутстаффинг подключать для расширения команды под конкретные задачи с понятным сроком.

Штатный найм: когда он по-прежнему эффективен

Задач, с которыми штатный найм справляется лучше, немало. Особенно это заметно, когда продукт живёт годами и ключевые решения принимаются людьми, которые понимают его историю. Посмотрим на преимущества найма.

• Погружение в продукт. Человек, который работает с одним продуктом год или два, знает его глубже, чем тот, кого привлекли на полгода. Этот контекст нельзя передать через документацию или онбординг — он накапливается постепенно, через участие во всех стадиях и решениях.
• Лояльность. Штатный сотрудник думает о своей карьере внутри компании, заинтересован в её развитии. Это сложно воспроизвести в модели временного сотрудничества — здесь у специалиста другие приоритеты.
• Корпоративная память. Внутренние специалисты накапливают базу знаний, обучают новых коллег, передают экспертизу. При аутстаффинге существует риск, что с окончанием контракта вместе со специалистом уйдут и знания о проекте — если не выстроить процесс передачи.
• Стабильность команды. Долгие проекты требуют предсказуемого состава: меньше перестановок, меньше потерь контекста. Штатный найм даёт более высокую вероятность сохранить команду на горизонте нескольких лет.

Штатная модель незаменима там, где важны стратегическая непрерывность и инженерная культура: развитие ключевого продукта, техническая архитектура, формирование внутренней экспертизы. Всё это требует людей, которые связывают своё развитие с компанией, — аутстаффинг эту связь не создаёт. При выборе формата стоит честно оценить горизонт задач и то, насколько важна долгосрочная вовлечённость специалиста.

Не вместо, а вместе: гибкие форматы и штатный найм техкадров

Аутстаффинг не вытеснит штатный найм, так как решает иные задачи. Когда нужны скорость, гибкость, доступ к экспертизе без долгосрочных обязательств — он работает. Когда важны глубина погружения, лояльность и накопление знаний внутри команды — штат не заменить.

Компании, прошедшие через опыт масштабирования технической команды, как правило, не задаются вопросом «аутстаффинг или штат» — они комбинируют. Устойчивое ядро в штате, расширение под конкретные задачи — через провайдера.

Подробнее о том, как организована работа с внешними техническими кадрами, — в профильных материалах компаний, например, в разделе ИТ-аутсорсинг на сайте Selecty, где описаны конкретные форматы взаимодействия заказчика с провайдером.

Гибкие форматы работы с техническими кадрами сегодня — уже не просто тренд, а устойчивая норма рынка. Компании, которые умеют подбирать инструмент под задачу, получают ощутимое операционное преимущество. ИТ-аутстаффинг при правильном применении — один из таких инструментов.

Реклама. ООО Селекти, ИНН 7736313541, erid: 2W5zFJYUtvD

Программа обязывает всех разработчиков Android-приложений пройти верификацию личности — независимо от того, распространяют ли они приложения через Google Play, сторонние магазины или напрямую через APK. 62 организации из 19 стран, включая EFF, F-Droid и Tor Project, подписали открытое письмо против программы, назвав её угрозой открытости Android.

— Google требует верификацию личности для всех Android-разработчиков — не только в Play Store

— С 30 сентября 2026 незарегистрированные приложения блокируются в 4 странах, в 2027 — глобально

— F-Droid заявляет, что программа фактически уничтожает проект

— 62 организации (EFF, Tor Project, Proton, KDE) подписали открытое письмо против

— Для хобби-разработчиков предусмотрен бесплатный аккаунт с лимитом в 20 устройств

Android Developer Verification — программа верификации разработчиков, анонсированная Google во второй половине 2025 года. До сих пор верификация требовалась только для публикации в Google Play. Новая программа распространяет это требование на все каналы дистрибуции: сторонние магазины (F-Droid, Galaxy Store, Amazon Appstore), прямую загрузку APK и любой другой способ установки на сертифицированные Android-устройства (то есть практически все телефоны с Google Play Services — более 95% активных Android-устройств за пределами Китая).

Что требуется для верификации

Google предлагает два типа аккаунтов (регистрация — на developer.android.com/developer-verification):

• Full Distribution ($25) — полная верификация: юридическое имя, адрес, email, телефон, загрузка государственного удостоверения личности. Для организаций — дополнительно D-U-N-S-номер (бесплатный бизнес-идентификатор Dun & Bradstreet, но получение занимает до 28 рабочих дней)
• Limited Distribution (бесплатно) — упрощённая верификация без госдокументов, только email. Ограничение: не более 20 устройств. Запуск в июне 2026

Для разработчиков, уже верифицированных в Google Play Console, ничего не меняется — Google автоматически зарегистрирует подавляющее большинство существующих приложений.

Что происходит с незарегистрированными приложениями

С 30 сентября 2026 года в Бразилии, Индонезии, Сингапуре и Таиланде незарегистрированные приложения будут заблокированы для установки и обновления на сертифицированных Android-устройствах. В 2027 году требование распространится глобально.

В апреле 2026 на все сертифицированные устройства (Android 7+) через Google Play Services будет установлен системный сервис «Android Developer Verifier» — он и будет проверять регистрацию разработчика при каждой установке.

Для установки незарегистрированных приложений пользователю нужно пройти «расширенный режим» (advanced flow):

1. Включить режим разработчика в настройках
2. Подтвердить, что установка добровольная (защита от социальной инженерии)
3. Перезагрузить телефон (обрывает потенциальный удалённый доступ)
4. Подождать 24 часа (обязательный «период охлаждения»)
5. Пройти биометрическую аутентификацию
6. Установить приложение — с постоянной меткой «от неверифицированного разработчика»

Установка через ADB (для разработки и тестирования) по-прежнему работает без ограничений.

Почему Google это делает

Google ссылается на собственное исследование: вредоносное ПО из сайдлоуд-источников встречается в 90 раз чаще, чем из Google Play. Главная проблема — анонимность: разработчик, пойманный на распространении малвари, может удалить аккаунт и мгновенно зарегистрировать новый. Верификация привязывает дистрибуцию к реальной личности. 24-часовой «период охлаждения» в advanced flow направлен против сценариев социальной инженерии — когда жертву дистанционно вынуждают установить вредоносное приложение под давлением:

В течение этих 24 часов атакующему становится значительно сложнее удержать жертву. За это время вы, вероятно, выясните, что ваш близкий на самом деле не в тюрьме и что ваш банковский счёт не под угрозой.

Почему 62 организации против

В феврале 2026 года коалиция из 62 организаций опубликовала открытое письмо на имя Сундара Пичаи, Ларри Пейджа и Сергея Брина. Среди подписантов:

• EFF (Electronic Frontier Foundation)
• F-Droid — крупнейший альтернативный магазин свободного ПО
• Tor Project
• Proton (ProtonMail, ProtonVPN)
• KDE, GNOME Foundation
• LineageOS, Nextcloud, Vivaldi
• FSF, FSFE, Software Freedom Conservancy
• Chaos Computer Club, La Quadrature du Net, Privacy Guides

Главная претензия: F-Droid под угрозой закрытия

F-Droid — альтернативный магазин приложений, который компилирует программы из открытого исходного кода и подписывает их собственным ключом. По новым правилам F-Droid не может зарегистрировать чужие приложения от своего имени (это означало бы ложное заявление на владение), и не может обязать тысячи волонтёров-разработчиков лично регистрироваться в Google.

F-Droid заявил напрямую: если Google реализует программу в текущем виде, это фактически уничтожает проект. Аналогичная проблема у IzzyOnDroid и других репозиториев свободного ПО.

Шесть претензий открытого письма

1. Гейткипинг за пределами Play — Google становится единственным арбитром, кто может распространять ПО для Android
2. Барьеры входа — D-U-N-S-номер, госдокументы, $25 — непропорциональная нагрузка на инди-разработчиков
3. Приватность — централизация данных обо всех разработчиках у Google
4. Произвольное применение — Google может отозвать верификацию по своему усмотрению
5. Антиконкурентная разведка — Google получает данные обо всех приложениях конкурирующих экосистем
6. Регуляторные риски — возможный конфликт с DMA (Digital Markets Act) в ЕС

Хронология

• 2025 — программа анонсирована
• 30 марта 2026 — регистрация открыта для всех разработчиков
• Апрель 2026 — «Android Developer Verifier» устанавливается на все сертифицированные устройства через Play Services
• Июнь 2026 — запуск бесплатных Limited Distribution аккаунтов
• Август 2026 — глобальный запуск advanced flow для пользователей
• 30 сентября 2026 — начало блокировок в Бразилии, Индонезии, Сингапуре и Таиланде
• 2027 — глобальное распространение

Что не затронуто

• Установка через ADB — без ограничений
• Корпоративные managed-устройства (Enterprise MDM) — освобождены
• Альтернативные AOSP-прошивки (GrapheneOS, LineageOS, /e/OS) — не затронуты (нет Play Services)
• Разработка и тестирование — не требует регистрации

Выводы

Android Developer Verification — самое значительное ограничение открытости Android за всю историю платформы. Google аргументирует его борьбой с малварью (90x чаще из сайдлоуда), но критики указывают: программа превращает Android в подобие iOS, где единственный арбитр дистрибуции — владелец платформы.

Для разработчиков, публикующихся через Google Play, ничего не меняется. Для тех, кто распространяет приложения за его пределами — F-Droid, прямые APK, корпоративные решения — начинается обратный отсчёт до 30 сентября 2026.

Приложение White House (gov.whitehouse.app, версия 47.0.1) — официальный Android-клиент Белого дома, доступный в Google Play. Под капотом — React Native на Expo SDK 54 с движком Hermes. Бэкенд — WordPress, который отдаёт контент через REST API на whitehouse.gov.

— Приложение содержит JavaScript-инжектор, который скрывает cookie-баннеры, GDPR-диалоги, пейволлы и логин-стены на любых сайтах, открытых через встроенный браузер

— В коде заложена инфраструктура GPS-трекинга через OneSignal: опрос координат каждые 4,5 минуты при активном использовании и каждые 9,5 минут в фоне

— YouTube-плеер загружает HTML-страницу с GitHub Pages мейнтейнера сторонней библиотеки — компрометация аккаунта позволит выполнить произвольный код

— В продакшен-сборке остались артефакты разработки: URL localhost, IP разработчика и экспортированная Activity

Что из себя представляет приложение

Приложение Белого дома — по сути, обёртка над WordPress. Весь контент загружается через REST API с эндпоинтами вида /wp-json/whitehouse/v1/*. Вот основные разделы:

• /home — главный экран
• /news/articles — новости
• /wire — лента «The Wire»
• /live — прямые трансляции
• /galleries — фотогалереи
• /issues и /priorities — политические приоритеты
• /achievements — «достижения»
• /media-bias — раздел «предвзятость СМИ»
• /social/x — прокси ленты X/Twitter

Среди контента — разделы «THE TRUMP EFFECT», «Greatest President Ever!», «Text President Trump» (с номером 45470) и ссылки на TrumpRx.gov, TrumpAccounts.gov, а также форма доноса ICE. Конфиг Expo указывает владельца forty-five-press — судя по всему, это медиа-команда, а не государственное агентство.

Инжектор обхода cookie-баннеров и пейволлов

Самая неожиданная находка — JavaScript-код, который инжектируется в каждый сайт, открытый через встроенный WebView приложения. Пейволл (paywall) — это платная стена, блокирующая доступ к контенту для неподписчиков. Скрипт использует механизм injectedJavaScript в React Native WebView.

Что именно скрывает инжектор:

• Cookie-баннеры (по CSS-селекторам *cookie*, *Cookie*)
• GDPR-диалоги согласия (*consent*, *gdpr*, *GDPR*)
• Баннеры OneTrust (*onetrust*)
• Баннеры приватности (*privacy-banner*)
• Логин-стены (*login-wall*, *loginWall*)
• Стены регистрации (*signup-wall*, *signupWall*)
• Апсейл-блоки (*upsell*, *Upsell*)
• CMP-боксы (.cmpboxBtnYes, .cmpbox)
• Любые элементы с aria-label, содержащим «cookie» или «consent»

Скрипт работает в два этапа. Сначала создаёт CSS-правило display: none !important для всех элементов, соответствующих селекторам. Затем устанавливает MutationObserver, который отслеживает любые изменения DOM и скрывает новые элементы с соответствующими классами. Дополнительно принудительно снимает блокировку прокрутки: body { overflow: auto !important }.

По сути, приложение Белого дома обходит GDPR-требования и пейволлы на сторонних сайтах. Для государственного приложения это, мягко говоря, неожиданно.

Инфраструктура GPS-трекинга

В конфиге Expo есть плагин withNoLocation, который, казалось бы, отключает геолокацию. Однако в скомпилированном коде присутствует полноценная инфраструктура трекинга через OneSignal SDK.

Константы опроса координат

В классе LocationConstants жёстко заданы интервалы опроса:

• FOREGROUND_UPDATE_TIME_MS = 270000 — 4,5 минуты при активном использовании
• BACKGROUND_UPDATE_TIME_MS = 570000 — 9,5 минут в фоне
• TIME_FOREGROUND_SEC = 300 — 5-минутный порог для переднего плана
• TIME_BACKGROUND_SEC = 600 — 10-минутный порог для фона

Как работает трекинг

Класс GmsLocationController использует Google Fused Location API. При каждом опросе запрашивает координаты с приоритетом PRIORITY_BALANCED_POWER_ACCURACY (код 102) и устанавливает maxWaitTime в полтора раза больше интервала.

Перехваченные координаты обрабатывает LocationCapturer: широта, долгота, точность, временная метка, флаг фоновой работы и тип (грубый/точный). Всё сохраняется в PropertiesModel и отправляется на серверы OneSignal (api.onesignal.com).

Есть и фоновый сервис LocationBackgroundService, который продолжает собирать координаты даже когда приложение свёрнуто.

Защита — есть, но условная

Формально GPS-трекинг защищён гейтом: флаг _isShared по умолчанию false. Трекинг активируется только после вызова setLocationShared(true). Плагин withNoLocation по идее не должен его включать. Но вся инфраструктура скомпилирована в приложение. Поскольку трекинг реализован в нативном коде (Java), простое OTA-обновление JavaScript-бандла его не активирует. Однако если в приложении есть bridge-вызов к setLocationShared из JS — достаточно серверного конфига для включения без обновления через Google Play.

Риски цепочки поставок

JavaScript с чужого GitHub Pages

Для YouTube-плеера используется библиотека react-native-youtube-iframe, которая загружает HTML-страницу с GitHub Pages пользователя lonelycpp — мейнтейнера этой библиотеки:

Если аккаунт lonelycpp на GitHub будет скомпрометирован, злоумышленник сможет подменить эту страницу и выполнить произвольный JavaScript в WebView приложения Белого дома. Это классическая supply-chain атака (атака через цепочку поставок — компрометация стороннего компонента для проникновения в целевую систему). Хостинг ресурсов на GitHub Pages вместо CDN с Subresource Integrity — плохая практика для любого приложения, тем более государственного.

Виджеты Elfsight

Приложение загружает JavaScript-платформу Elfsight с CDN:

Elfsight — это виджет-платформа для социальных сетей. Никакой песочницы — скрипт исполняется в том же контексте, что и основное приложение.

Сторонние сервисы вместо госинфраструктуры

Ни один из сторонних сервисов не является государственной инфраструктурой:

• Mailchimp (whitehouse.us10.list-manage.com) — обработка email-подписок. Адреса пользователей уходят на серверы Mailchimp
• Uploadcare (ucarecdn.com) — хостинг контентных изображений через 6 захардкоженных UUID
• Truth Social — захардкоженный embed с профилем Трампа, аватаркой со static-assets-1.truthsocial.com и кнопкой «Follow»
• Facebook — плагин страницы через iframe facebook.com/plugins/page.php

Профилирование пользователей через OneSignal

OneSignal SDK в приложении — это не просто пуш-уведомления. Платформа предоставляет широкие возможности для профилирования пользователей:

• addTag — тегирование пользователей для сегментации
• addSms — привязка номеров телефонов к профилям
• addAliases — кросс-девайсная идентификация пользователей
• addOutcomeWithValue / addUniqueOutcome — отслеживание действий и конверсий
• Полный цикл in-app сообщений: WillDisplay, DidDisplay, WillDismiss, DidDismiss, inAppMessageClicked
• Отслеживание изменений состояния: подписки, разрешения, пользовательский профиль

Локальная SQLite-база хранит таблицы notification (с полями notification_id, opened, dismissed, title, message, full_data) и in_app_message (с отслеживанием показов и кликов).

Артефакты разработки в продакшен-сборке

В релизной версии приложения остались следы, которых там быть не должно:

• URL http://localhost:8081/wp-json/whitehouse/v1/galleries?page= — захардкоженный адрес локального дев-сервера
• IP-адрес разработчика 10.4.4.109 — прописан в strings.xml как react_native_dev_server_ip
• Пакеты expo-dev-client, expo-devlauncher, expo-devmenu — средства разработки Expo
• Иконка дев-меню dev_menu_fab_icon.png
• Экспортированная PreviewActivity из Compose UI Tooling — доступна другим приложениям через android:exported="true"

Экспортированная Activity — это потенциальный вектор атаки. Любое приложение на устройстве может запустить PreviewActivity через Intent.

Отсутствие certificate pinning

Certificate pinning (закрепление сертификата) — это метод защиты от атак «человек посередине» (MITM), при котором приложение принимает только заранее известные сертификаты сервера. Приложение Белого дома использует стандартный Android Trust Manager без закрепления сертификатов. Это означает, что при использовании скомпрометированного Wi-Fi или корпоративного прокси трафик между приложением и серверами whitehouse.gov может быть перехвачен и прочитан.

Разрешения и файловый доступ

Манифест запрашивает следующие разрешения:

• INTERNET — доступ к сети
• VIBRATE — вибрация
• ACCESS_NETWORK_STATE — состояние сети
• POST_NOTIFICATIONS — отправка уведомлений
• WAKE_LOCK — предотвращение засыпания
• RECEIVE_BOOT_COMPLETED — автозапуск при загрузке
• C2DM.RECEIVE — облачные пуш-уведомления
• CHECK_LICENSE — проверка лицензии Google Play

Конфигурация FileProvider описывает путь external-path name="shared" path="." — приложение может предоставлять любые файлы из внешнего хранилища другим приложениям через FileProvider. Это не означает чтение чужих данных, но расширяет поверхность атаки при взаимодействии между приложениями.

Полный стек зависимостей

Список SDK внутри приложения впечатляет:

• Фреймворк: React Native, Expo SDK 54, Hermes JS engine
• Пуш/вовлечение: OneSignal, Firebase Cloud Messaging, Firebase Installations
• Аналитика: Firebase Analytics, Google Data Transport, OpenTelemetry
• Сеть: OkHttp 3, Apollo GraphQL, Okio
• Изображения: Fresco, Glide, Coil 3, Uploadcare CDN
• Видео: ExoPlayer (Media3), Expo Video
• ML: Google ML Kit Vision (сканирование штрих-кодов), модель Barhopper
• Криптография: Bouncy Castle
• Хранилище: Expo Secure Store, React Native Async Storage
• WebView: React Native WebView (с инжектором)
• DI: Koin
• Сериализация: GSON, Wire (Protocol Buffers)
• Лицензия: PairIP license check (Google Play Verification)

Что делать пользователям

1. Не открывать ссылки через встроенный браузер приложения — копировать URL и открывать в Chrome/Firefox, где cookie-баннеры отображаются корректно
2. Проверить разрешения приложения в настройках Android: Настройки → Приложения → White House → Разрешения — убедиться, что геолокация отключена
3. Учитывать, что RECEIVE_BOOT_COMPLETED запускает сервисы приложения при каждой загрузке устройства — даже если вы не открывали приложение
4. Для параноиков: использовать отдельный рабочий профиль Android (Настройки → Система → Несколько пользователей) для изоляции

Чеклист для разработчиков: что не должно попадать в прод

Этот случай — хороший повод проверить собственные приложения. Вот что стоит убрать перед релизом:

1. URL localhost и IP-адреса разработчиков — искать в strings.xml, конфигах и коде
2. Дев-пакеты (expo-dev-client, devmenu) — исключать из релизных сборок через build flavors
3. Экспортированные Activity для отладки — убирать android:exported="true" у дев-компонентов
4. Внешние JS-зависимости без SRI — хостить критичные ресурсы на собственном CDN
5. Избыточные SDK-модули — если не используете геолокацию, исключить модуль из сборки, а не просто «отключить» флагом
6. Широкие пути в FileProvider — ограничивать до конкретных директорий вместо path="."
7. Certificate pinning — добавить для всех критичных эндпоинтов через network_security_config.xml

Выводы

Приложение Белого дома — это React Native обёртка над WordPress с инжектором обхода cookie и пейволлов, инфраструктурой GPS-трекинга через OneSignal и JavaScript-зависимостями с GitHub Pages стороннего разработчика. Без certificate pinning.

Этот разбор показывает, что даже государственные приложения могут содержать сомнительные практики: от обхода GDPR-баннеров до supply-chain зависимостей от случайных разработчиков. Полная инфраструктура GPS-трекинга, встроенная в код, но формально «отключённая» — это бомба замедленного действия, которая может быть активирована без обновления приложения.

Оригинальный анализ доступен в блоге thereallo.dev.

А вы проверяли, какие разрешения у государственных приложений на вашем телефоне?

В чем секрет привлекательности миниаппов

Миниаппы (мини-приложения) – это встроенные в мессенджер веб-приложения, которые позволят воспользоваться тем или иным сервисом без установки отдельных программ. Миниаппы дают возможность пользователям взаимодействовать с цифровыми продуктами, совершать покупки или играть в игры, не покидая интерфейса мессенджера. Такие приложения интегрируются с экосистемой мессенджера, используя его API для авторизации, платежей и уведомлений.

Популярность миниаппов нетрудно объяснить. Во-первых, это просто удобно: пользователь мгновенно преодолевает путь до услуги или инструмента. Во-вторых, мини-приложения крайне просты в интеграции и подходят для внедрения сервисов, маркетплейсов и других востребованных платформ. В-третьих, разработка миниаппов значительно проще и дешевле, чем создание и дистрибуция классических нативных приложений. Наконец, многие мессенджеры уже имеют встроенные механизмы платежей или поддерживают их через сторонние системы. В результате от использования миниаппов выигрывает и бизнес, и разработчик, и эндюзер.

Что будущее за интернетом, мы поняли еще несколько лет назад – и сразу адаптировали наши системы для веб-среды. Сделать это нам удалось благодаря технологии WebAssembly (Wasm), с помощью которой можно создавать прогрессивные веб-приложения (PWA). Уже в 2021 году мы смогли добиться видимых результатов: распознавание паспорта РФ, распознавание документов и QR-кодов, а также сверка лиц стали доступны непосредственно в браузере. Притом все вычисления происходят непосредственно на пользовательском устройстве, а для распознавания не требуется GPU.

Эти возможности сразу оценили в банках – когда после удаления их приложений из сторов возникла необходимость перенести привычный пользовательский функционал в интернет.

Как использовать технологии распознавания в вебе

Сегодня наши решения на базе WebAssembly применяются во многих ключевых пользовательских сценариях. Для иллюстрации назовем некоторые из них.

• Цифровой онбординг. Распознавание паспорта сегодня позволяет осуществлять онбординг и проверки KYC прямо через браузер. Чтобы открыть счет, оформить продукт или подключить услугу, клиенту нужно просто просканировать документ, или загрузить его изображение из галереи. Благодаря этому отпала необходимость личного посещения офисов или отделений и стало возможно получить доступ к сервисам в любое удобное время. Наша система работает и с паспортами СНГ, мы рассказывали об этом тут.
• Платежи и переводы. Благодаря автоматическому распознаванию стало возможно реализовать ежедневные платежи в онлайн-банках. Пользователь наводит камеру мобильника на QR, номер телефона или квитанцию и может моментально совершить оплату или перевод. Система уверенно работает даже в “экстремальных” случаях: когда треть QR-кода перекрыта или он находится на расстоянии или под углом. Здесь мы рассказывали, как в вебе реализовать распознавание банковской карты.

• Сервисы бухгалтерии. Сегодня большой популярностью пользуются сервисы аутсорсинга бухгалтерии для обслуживания юридических лиц. В особенности эта возможность полезна для малого бизнеса и индивидуальных предпринимателей – там, где для работы с документами просто нет штатного сотрудника. Распознавание документов (акты, УПД, счета-фактуры, формы ТОРГ-12, накладные и другие) позволяет решать задачи ввода и структуризации данных прямо в браузере. Быстро и удобно.

Благодаря возможностям Wasm эту функциональность можно легко перенести и в мессенджер. Некоторые наши клиенты так и поступили. Например, ВТБ уже запустил оплату по QR в мессенджере MAX. Говорят, что работает даже на парковке (наша распознавалка уж точно – интернет для этого не требуется).

Как это реализовать

Перейдем от теории к практике. Как мы писали выше, добавить распознавание в мини-приложения мессенджеров нам удалось благодаря технологии WebAssembly.

Наш основной продукт – библиотека компьютерного зрения. Поскольку она написана на С++, для переноса кодовой базы в браузер мы используем инструмент emscripten, поддерживаемый google. На выходе мы получаем wasm файл и js файл для работы с ним. Добавляем бизнес логику и распознавание, например, банковской карты реализуется вот так:

В браузере для захвата изображений с камеры необходимо сначала отрисовать видеопоток на canvas, аналогичным образом клиент может отрисовывать на canvas PDF и HEIC, если вам необходимо распознавания фотографии или документа из галереи, например.

Код выше показывает работу распознавания одного изображения, но если вы в цикле будете передавать изображения с камеры и дальше в spawnedSession.Process(image), то воспользуетесь преимуществами распознавания документов в видеопотоке. Кстати, мы недавно получили на это патент США.

Для распознавания в браузере паспорта РФ, реализация очень похожа.

Указываем режим распознавания и маску документа. Можно указать маску звездочкой “*”, а режим “anydoc”, тогда поиск будет осуществляться по всем доступным документам.

Следующая настройка позволяет вернуть в результате изображение документа, исправленное по перспективе (утюг) и обрезанным по пропорциям физического документа.

Результат распознавания представляет из себя объект с именованными полями документа и его изображения (лицо, подпись, шаблон документа). Мы не ограничиваем в структуре ответа, поэтому вы можете сформировать для себя ответ в json в любом удобном виде: с картинками или без, с метаданными, с коэффициентами уверенности и т.п.

Напоследок

Как можно убедиться, интеграция систем Smart Engines в миниаппы осуществляется быстро и абсолютно безболезненно. Гибкость наших технологий позволяет решать любые задачи распознавания хоть в Telegram, хоть в MAX, хоть в любом другом мессенджере с возможностью создания мини-приложений.

Скорость и качество работы технологий распознавания паспорта и других документов, а также кодифицированных объектов в веб-среде сопоставима с нативными библиотеками. Охват широкой аудитории мессенджеров и положительный пользовательский опыт обеспечены. Smart Engines – распознаем даже на парковке!

Современные приложения для камеры должны сочетать мощные функции: пользователи хотят снимать видео в HDR, с частотой 60 кадров в секунду и стабилизацией изображения — и всё это одновременно. Но как разработчику гарантировать, что устройство поддерживает такую комбинацию?

Ранее совмещение нескольких функций было рискованным: проверка поддержки каждой функции по отдельности не гарантировала их совместной работы. Это могло привести к нестабильной работе камеры или её полному сбою. Чтобы избежать проблем, разработчики ограничивали функциональность, лишая пользователей с мощными устройствами, такими как Pixel 10 Pro, полноценного опыта.

CameraX 1.5 решает эту проблему с помощью нового API Feature Group. Теперь вы можете заранее проверить поддержку комбинации функций или задать приоритеты, а библиотека сама подберёт оптимальную конфигурацию для устройства.

Что такое CameraX?

CameraX — это библиотека Jetpack, которая упрощает разработку приложений для камеры на Android. Она предлагает удобный и единообразный API, совместимый с большинством устройств, начиная с Android 6.0 (API level 23). Для новичков рекомендуем изучить официальную документацию и пройти практический codelab.

Возможности API Feature Group

Новый API позволяет создавать продвинутые приложения для камеры, избегая проблем с совместимостью. Вы сможете:

• Создавать адаптивные интерфейсы: Динамически включать или отключать настройки в зависимости от возможностей устройства. Например, если пользователь включает HDR, опция 60 FPS автоматически станет недоступной, если комбинация не поддерживается.
• Реализовать режим “Максимальное качество”: Укажите желаемые функции с приоритетами, и CameraX выберет лучшую комбинацию, поддерживаемую устройством, без сложной логики.
• Избежать сбоев: Проверка поддержки комбинаций заранее предотвращает ошибки при настройке камеры, обеспечивая стабильную работу.

Как это работает: основные компоненты

API построен на обновленных классах SessionConfig и CameraInfo.

• GroupableFeature: Включает набор функций, таких как HDR_HLG10, FPS_60, PREVIEW_STABILIZATION и IMAGE_ULTRA_HDR. Список пока ограничен из-за вычислительных требований, но будет расширен в следующих версиях.
• Новые параметры SessionConfig:requiredFeatureGroup: Для обязательных функций. Если комбинация не поддерживается, вызов bindToLifecycle завершится ошибкой IllegalArgumentException.preferredFeatureGroup :Для необязательных функций. Укажите список с приоритетами, и CameraX выберет лучшую комбинацию.
• requiredFeatureGroup: Для обязательных функций. Если комбинация не поддерживается, вызов bindToLifecycle завершится ошибкой IllegalArgumentException.
• preferredFeatureGroup: Для необязательных функций. Укажите список с приоритетами, и CameraX выберет лучшую комбинацию.
• CameraInfo#isFeatureGroupSupported(): Метод для проверки поддержки комбинации функций. Передайте SessionConfig, чтобы узнать, поддерживается ли набор функций, и настройте интерфейс соответственно.

Практическое применение

Рассмотрим два сценария использования API.

Сценарий 1: Режим "Максимальное качество"

Чтобы автоматически включить лучшие функции, задайте список приоритетов в preferredFeatureGroup. Например, приоритет: HDR, затем 60 FPS, затем стабилизация. CameraX сам выберет оптимальную комбинацию.

CameraX проверит комбинации в порядке приоритета, выбрав первую поддерживаемую:

1. HDR + 60 FPS + Стабилизация
2. HDR + 60 FPS
3. HDR + Стабилизация
4. HDR
5. 60 FPS + Стабилизация
6. 60 FPS
7. Стабилизация
8. Ничего

Сценарий 2: Адаптивный интерфейс

Для интерфейса, реагирующего на выбор пользователя, проверяйте неподдерживаемые комбинации:

Интегрируйте логику в интерфейс для отключения неподдерживаемых опций и привязки стабильной конфигурации:

Ознакомьтесь с тестовым приложением CameraX для примера реализации (не для продакшена).

API Feature Group устраняет неопределенность при работе с продвинутыми функциями камеры, позволяя создавать надежные приложения. Он доступен как экспериментальный в CameraX 1.5 и станет стабильным в версии 1.6 с дополнительными улучшениями.

Что исправили

Две ключевые правки касаются дисплея. Первая устраняет мерцание экрана и внезапные выключения устройства в определённых сценариях. Вторая — проблему с «замершим» или размытым изображением.

Системные баги тоже не обошли стороной. Google устранила редкую ошибку, вызывавшую нестабильность системы, а также артефакт полупрозрачного фона, который мог «зависать» после открытия камеры.

Отдельно компания починила отображение статуса фонарика в виджете At a Glance и баг, из-за которого могла происходить аварийная перезагрузка при старте или остановке трансляции через Media Output Switcher.

Почему стоит установить обновление

Многие из этих багов проявлялись не у всех пользователей и не на постоянной основе. Но именно такие мелкие глюки чаще всего раздражают в повседневном использовании — и их устранение улучшает общее впечатление от системы. Поэтому обновление стоит установить даже тем, кто не сталкивался с проблемами напрямую.

Напомним, что в 2023 году жюри признало, что практики Google вокруг Play нарушают антимонопольное законодательство. В октябре 2024 г. судья Донато утвердил трёхлетний запрет, обязав Google открыть Play для конкуренции. Девятый округ летом 2025 г. подтвердил решение.

Сейчас судьи отклонили ходатайство Google о временной заморозке части судебного запрета. Верховный суд не стал замораживать ключевые части запрета судьи Джеймса Донато, которые были подтверждены Апелляционным судом Девятого округа летом.

Google планирует подать полноценную жалобу в Верховный суд до 27 октября, но это будет уже после даты исполнения. На данный момент запрет действует, и Google обязан начать исполнение.

Что Google должен сделать уже в октябре

Согласно приказу суда и его трактовке в материалах дела и СМИ, Google обязан:

• Прекратить требовать от разработчиков обязательного использования Google Play Billing.
• Разрешить разработчикам информировать пользователей (включая ссылки из приложений) о внешних способах оплаты без дополнительных комиссий и отпугивающих экранов.
• Открыть путь к распространению приложений вне Play Store (включая указание способов загрузки).
• Разрешить разработчикам устанавливать собственные цены.
• Прекратить выплаты/бонусы производителям устройств, операторам и разработчикам за эксклюзивы в Play или предустановку.
• Сотрудничать с Epic в рамках совместного технического комитета по безопасному доступу конкурирующих магазинов к каталогу Play.

Google публично сообщил, что выполнит юридические обязательства, параллельно продолжая попытки обжаловать запрет в Верховном суде. Компания предупреждает о рисках для безопасности пользователей при ослаблении контроля в платежах и дистрибуции.

По данным Bloomberg и источников в цепочке поставок, новые версии iPad Pro и MacBook Pro будут представлены в конце октября, а вместе с ними ожидается и обновлённый Apple Vision Pro.

Дефицит в онлайн-магазине Apple намекает на скорое обновление

Как отметил Марк Гурман, сроки доставки некоторых конфигураций iPad Pro M4 на сайте Apple уже достигают двух–трёх недель — особенно в версиях с большим объёмом памяти и дисплеем OLED.

Аналогичная ситуация и с MacBook Pro на M4: большинство конфигураций доступны, но базовая модель M4 временно исчезла из каталога и, по данным источников, вернётся в продаже ближе к концу месяца.

Такое поведение запасов обычно предшествует официальному анонсу, поскольку Apple сокращает поставки старых моделей перед запуском новых.

Apple Vision Pro и другие обновления

Ожидается, что Apple Vision Pro получит незначительное обновление характеристик — улучшение автономности, оптики и, возможно, новый вариант с увеличенным объёмом памяти.

Однако поставки гарнитуры остаются стабильными, что указывает на то, что компания не планирует кардинальных изменений в линейке до 2026 года.

Также до конца года Apple намерена представить:

• AirTag 2 с улучшенным чипом Ultra Wideband;
• Apple TV 4K (A17 Pro) с поддержкой повышенной частоты кадров;
• HomePod mini 2 с новым звуковым процессором.

Когда ждать анонса

Apple традиционно проводит осенние презентации в середине или конце октября. В последние годы компания чередует полноправные мероприятия с видеотрансляцией и тихие релизы через пресс-релизы.

Пока неизвестно, выберет ли Тим Кук сцену в Apple Park или ограничится публикацией новинок на сайте, но одно ясно — период ожидания подходит к концу.

«Изменения в запасах почти всегда означают обновление оборудования. Похоже, до следующего раунда объявлений от Apple осталось всего несколько дней», — отмечает Гурман.

Что думают пользователи

Многие поклонники бренда в соцсетях признаются, что отложили покупку iPad Pro и MacBook Pro, ожидая выхода новых версий.

Если слухи подтвердятся, в продаже появятся устройства с чипом M4 Ultra, дисплеями OLED нового поколения и улучшенным время автономной работы.

• Google Play Store v48.3 (06.10.2025): обновленные иконки в некоторых уведомлениях Google Play Protect на телефонах, ПК, ТВ, Auto.

Важно: функция в релиз-нотах не гарантирует её мгновенную доступность на всех устройствах. Google часто вводит функции постепенно, «поэтапно разворачивая» (staged rollout).

Google Play services v25.39

Через APKMirror задокументирован выпуск версии 25.39.30 (beta).

Разработчики из Google усилили возможности управления аккаунтами — теперь система работает гибче с профилями под присмотром, упрощая родительский контроль и настройку устройств для детей. Темы, используемые в интерфейсах поднадзорных аккаунтов, получили визуальное обновление и стали единообразнее, чтобы пользователи лучше ориентировались в настройках.

Отдельного внимания заслуживает и визуальная часть — привычные аватарки теперь оформлены в новом, более современном и чистом стиле. Для разработчиков Google добавила свежие инструменты и API, которые позволяют глубже интегрировать функции управления аккаунтами и безопасности в сторонние приложения, обеспечивая плавную работу и более высокий уровень конфиденциальности.

Особое улучшение касается защиты и безопасности: функция Sensitive Content Warnings в Google Messages научилась распознавать нежелательный контент не только на фотографиях, но и в видеороликах — шаг, который повышает безопасность общения в мессенджере. Параллельно был переработан и режим Driving Do Not Disturb — он стал работать стабильнее, меньше отвлекать водителя и лучше подстраиваться под дорожные ситуации.

В более ранних версиях (v25.37) Google уже вводил исправления стабильности при управлении аккаунтами, улучшения соединений устройств и дополнения к API. Droid Life. Версия 25.39, скорее, эволюция этих функций, сглаживающая баги и добавляющая новые интерфейсы.

Google Play Store v48.3

В релиз-нотах отмечено, что в уведомлениях Google Play Protect обновлены иконки на всех поддерживаемых платформах: Auto, ПК, телефон, ТВ.

Безопасность: Android Security Bulletin (сентябрь 2025)

Параллельно с системными обновлениями Google продолжает выпускать ежемесячные безопасностные бюллетени Android (Android Security Bulletin).

В бюллетене за сентябрь 2025 описано множество уязвимостей — например:

• CVE-2025-48543 — уязвимость в Android Runtime, позволяющая эскалацию привилегий, без необходимости дополнительного запуска кода.
• Несколько уязвимостей в Framework и ядре классифицируются как высокие (High) — могут дать локальное повышение привилегий.
• Устройства с Android 10 и выше могут получить обновления безопасности через Google Play system updates.

Что проверять и как обновиться?

С учётом подтверждённых данных, рекомендуем:

• Проверять на вашем устройстве версии:
  Google Play services — должна быть 25.39.x (или выше, если уже вышли патчи).
  Google Play Store — версия v48.3 или выше.
  Google Play system update (в Настройках телефона) — наличие новых системных патчей безопасности.
• Google Play services — должна быть 25.39.x (или выше, если уже вышли патчи).
• Google Play Store — версия v48.3 или выше.
• Google Play system update (в Настройках телефона) — наличие новых системных патчей безопасности.
• Если устройство не получает обновления автоматически — попробуйте вручную запустить обновление Google Play services через доступные источники (Play Store, Google Play System Update).
• Следите за бюллетенями безопасности Android: версия безопасности (security patch level) должна быть актуальной.
• У устройств с более старыми версиями Android (менее Android 10) возможности получать обновления безопасности через Google System могут быть ограничены.

Смотреть подкаст на YouTube, в VK.

Анна Жаркова пишет нативные приложения под iOS и Android и кросс-платформенные приложения на Xamarin, Xamarin.Forms и Kotlin Multiplatform. Написала книгу о Kotlin Multiplatform, которая выходит в сентябре. Пишет статьи, выступает на конференциях и митапах. Член программного комитета Mobius, CodeFest, «Стачка». Увлекается живописью и участвует в выставках.

Поговорили о безумных проджект-менеджерах, войне Android и iOS, о том, почему ИИ не заменит программистов, и что делать, если вам позарез нужно установить ВСЕ приложения из магазина. Добро пожаловать в абсурдный и увлекательный мир мобильных разработчиков!

О смысле мобильных приложений

Какие нам вопросы задали наши прекрасные подписчики. Первый вопрос: «А зачем вообще нужны мобильные приложения? У меня вот компьютер, а у друга ноутбук».

Ну, да, вопросы бывают разные, мы к этому привыкли. Начнём с того, что это, конечно, здорово, что есть компы и ноутбуки, но с собой человек, скорее всего, носит именно смартфон, а не компьютер или ноутбук.

Если попробовать ответить на этот вопрос серьёзно: мобильное устройство — это не просто «звонилка», это ещё и полезные клиентские приложения, которые позволяют получить быстрый доступ к информации или услугам. Конечно, это всё можно сделать и с компьютера, но главное назначение мобильного устройства — дать вам максимум возможностей при минимуме затрат: ресурсов, времени и с минимальным размером самого устройства.

Ну да, взять то же банковское приложение, оплату с телефона… Ребята, с компьютером не походишь, чтобы это всё делать. Давай поедем к следующему. Можно делать так, чтобы приложение ставилось не из App Store?

Конечно. Если это приложение под Android, оно будет ставиться через Google Play, а также есть специальные магазины, например, AppGallery для Huawei или RuStore. Также у некоторых вендоров есть свои маркеты, например, у Samsung.

Если же говорить про iOS, то тут всё строго с App Store. Но кто знает, возможно, в будущем появятся и кастомные магазины для iOS. Хотелось бы, чтобы поскорее.

А скажи, пожалуйста, насколько широкий ассортимент приложений в этих альтернативных магазинах? У меня всё на яблоках, я не особо разбираюсь, что там происходит, особенно с Huawei, с RuStore. Можешь рассказать, насколько там всё хорошо или плохо?

Я думаю, если говорить про приложения, которые имеют ограничения в загрузке в App Store, они, в принципе, есть и в Google Play, но свободно грузятся в остальные магазины. Особых ограничений нет. Конечно, бывают ситуации, когда приложение пропадает из магазина по чьей-то жалобе. Но выбор приложений довольно большой. Например, в компании, где я работаю, мы свободно загружаем наши приложения в разные магазины, и всё в порядке.

Супер. А насколько вообще отличается разработка для, скажем, Huawei от классической Android? Там есть какая-то своя специфика, или всё тоже самое? Может, свой стэк?

Плюс-минус как Android, но есть определённые различия. У них своя среда разработки, свои сервисы, дополнительные технологии. Тема довольно обширная, но в принципе, всё это плюс-минус то же самое, и Android-разработчику освоить это несложно. Главное — поставить нужную IDE (Интегрированную среду разработки) и взять устройство для отладки.

А какие там специфические IDE?

Да, там есть, по-моему, собственная IDE, но я скажу честно, я с ней особо не работала. Я сейчас копаю немножко в другом направлении.

О фантастическом девайсе

«Пользователю позарез нужно установить вообще все мобильные приложения, которые существуют на маркете. Всё использует, всё жизненно важно. Вопрос: что представлял бы из себя девайс, который смог бы это выдержать?» Я с трудом представляю, интересно твоё мнение.

Что ж, ну, возникает вопрос: наверное, у этого пользователя очень много денег, он может позволить себе все платные приложения. Порадуемся за него!

Но если говорить про аппарат, то это должен быть какой-то супермощный с параметрами из серии «Чёрная дыра». Современное приложение, тот же самый «суперап», который объединяет кучу сервисов, может занимать сотни мегабайт. Обычное банковское приложение — тоже несколько сотен мегабайт.

Поэтому если у пользователя есть какой-то супермощный компьютер, возможно, он причастен к каким-то научным, суперсекретным, может быть, даже военным разработкам, и у него память на каком-то кристалле из чёрной дыры… то, возможно, это и сработает.

В реальности, конечно, это похоже на шутку «я сейчас все игры установлю». Но ни одного нормального девайса даже с супервозможностями не хватит. Сейчас максимум — это 512 ГБ внутреннего хранилища, часто без возможности расширения. Но даже с картой памяти вам точно не хватит.

Да, вот у меня даже на айфоне он сгружает в облако всё, что не нужно. И у меня стоит довольно много приложений, в том числе детские, с ИИ, чтобы звёзды смотреть, цветы диагностировать… Куча странных приложений, которые я использую очень ситуативно. Я не представляю, сколько надо времени, чтобы скачать себе даже десятую часть всех существующих приложений в Store. Ну, это невозможно.

Ну, может, человек решил стать суперблогером по приложениям, решил сделать краш-тест всего маркета и всех возможных аппаратов. Удачи ему и успехов.

О разработке на мобильном телефоне

«Раз для компов проги пишут на компах, разве не уместнее для мобилок писать на мобилках?»

Кстати, очень хороший вопрос. На заре энтузиазма, когда только появлялись смартфоны, все считали: «Сейчас они будут настолько мощные, что не понадобится настоящий комп, чтобы писать программы».

Но это столкновение с реальностью. Девайс довольно слабенький, и ресурсов не хватит. Это сложный процесс: чтобы скомпилировать приложение, необходимо несколько гигабайт свободной памяти и много вычислительных ресурсов.

Конечно, на мобильном устройстве можно скомпилировать какие-то простые, легковесные приложения, например, на скриптовых языках. Есть такие технологии. И в том числе можно использовать мобильные устройства как инструмент для разработки. У того же GitHub такое было.

Но честно говоря, если есть желание что-то писать на мобильном аппарате, то лучше работать с облачными средами разработки. Потому что даже на компе та же Android Studio может кушать очень много памяти и сохранять много кэша. Облачная среда, конечно, в какой-то степени небезопасна, потому что вы что-то загружаете на сторонние сервера. Но если это ваше собственное, настроенное место, то вполне можно по удалёнке получать доступ. Другой вопрос, что вам тогда необходим хороший интернет.

Ну, ты знаешь, у меня вот был странный опыт. Когда я училась на Python-разработчика, у меня был старый макбук. Он у меня сдох через полгода, просто потому что не вывез: ты ставишь все эти библиотеки, прописываешь команды, подгружаешь версии… В общем, у меня просто сдох жесткий диск. Поэтому да, хороший вопрос. Не всякий даже ноут это выдержит, как выяснилось.

Более того, даже для сборки мощных мобильных приложений на Mac сейчас часто требуется 32, а то и 64 ГБ памяти. Были бы, конечно, такие крутые мобильные устройства, полноценные мини-компьютеры… Но это уже из области фантазии наших зрителей.

О Keycloak и мобильной безопасности

Так, следующий вопрос. «Подскажите, кто-нибудь пользуется Keycloak для SSO (стандарт единого входа)?»

Интересный, конечно, вопрос про Keycloak. Я слышала такое слово от бэкендеров — это механизм, который используют для безопасности на бэкенд-части. Но что примечательно, с вопросом про Keycloak часто приходят именно к нам, мобильным разработчикам.

Тебе говорят слово «Keycloak», и ты думаешь: «Хорошо, а я тут причём?» Так что да, это довольно часто задаваемый не по адресу вопрос. Ответ — спросите у аналитика или у бэкенд-разработчика.

А как ты думаешь, почему к мобильным разработчикам приходят с этим вопросом?

Я думаю, потому что говорят, что это какой-то механизм, необходимый для безопасной разработки. И часто люди путают, с чьей стороны должно быть внедрение того или иного решения.

Keycloak — это система идентификации и управления доступом с единой точкой входа. Мобильное приложение — это фронтенд-клиент, который обращается к API вашего сервера. Поэтому вся система должна быть реализована на бэкенде. Мобильщик будет лишь использовать готовое API. Если вам говорят, что вы должны это сделать сами на мобилке, ну тогда вы, получается, не мобильщик, а фуллстэк. Я вас поздравляю!

О выборе технологии: натив vs Flutter

Так, переходим к следующему вопросу. «Стоит ли погружаться в нативную разработку или сразу учить Flutter?»

Очень хороший вопрос. Flutter — это отдельная технология со своим языком Dart. Но тут есть маленький нюанс. Да, Flutter — технология отличная, но вы разрабатываете под Android и iOS, и поэтому вам необходимы знания нативной разработки, хотя бы в минимальном объёме. Есть проекты, где пишут код Flutter-разработчики, но от них требуют хороших, крепких знаний по нативу хотя бы одной платформы.

Когда у вас есть такой базис, вы понимаете, что вам необходимо сделать: как работать с жизненным циклом, с памятью, с сенсорами, с моделью разрешений. Всё это — знания натива, и без этого не обойтись. Это необходимо.

То есть, сначала учим какую-то одну платформу как базу, а потом уже идём во всякие Flutter’ы с ними.

Безусловно. Вы исходите из того, что пишете под Android (или iOS). И уже смотрите: как я могу это делать? Я могу писать на нативе, а могу на Flutter’е. Но Flutter всё равно будет опираться на натив, поэтому получается такая ступень по изучению технологий.

О роли ИИ в мобильной разработке

Что сейчас можно сделать с помощью ИИ в мобильной разработке?

Довольно много. Но тут возникает уточняющий вопрос: использовать ИИ как инструмент или внедрять ИИ в приложение? Есть возможности по внедрению ИИ, чтобы оно что-то генерировало в вашем приложении: умные ассистенты, генерация изображений и т.д.

Есть также возможности с помощью ИИ генерировать код. Но это явно не для начинающих. Почему? Потому что ошибок в таком коде довольно много. Чтобы этот код работал, нужен человек, который понимает, как такой код писать самому. То есть ИИ может помочь сократить время, выступить инструментом генерации, но не более.

К тому же сейчас есть технологии, которые позволяют разместить у себя модель нейросети, обучить её под свои нужды и использовать. Да, это дорого и ресурсоёмко, но возможность есть. В целом, возможности широкие, но они не заменят нормального разработчика. Все помнят мем про кружку, которую ИИ не догадался перевернуть? Это показательно.

Вопрос от этого же задавателя вопросов. «Используют ли Kotlin Multiplatform React Native (технологии для кроссплатформенной разработки) и так далее? Если да, бывают ли задачи с адаптацией под мобильный веб?»

Хм, хороший вопрос. Если говорить про работу с искусственным интеллектом в контексте этих технологий… Вы можете попробовать сгенерировать код под любую платформу. Для этого нужно писать много промтов и иметь много ресурсов для обучения модели.

Но если говорить о продакшене, то тут имеет смысл использовать только то, что безопасно. Есть компании, которые разрабатывают свои инструменты на основе LLM-моделей, как, например, Яндекс. Есть те, кто берут открытые модели, разворачивают их и используют.

А вот публичные сервисы вроде ChatGPT я не рекомендую использовать для продакшена. Они могут залогировать ваш код и потом выдать его кому-то. Это крайне небезопасно. В прошлом или позапрошлом году был скандал, когда ChatGPT выдавал куски кода одной компании, вплоть до креденшиалов. Так что в продакшене — только собственные решения.

О сегментации рынков Android и iOS

Насколько реально сегментированы рынки Android и iOS?

Если говорить про iOS, то тут всё просто: один вендор — Apple. Вся экосистема: iOS, iPadOS, watchOS, специальная OS для авто. Минимальная сегментация. А вот с Android вендоров много. Это и гиганты типа Samsung, большой кусок рынка у Xiaomi и её суббрендов вроде Poco или Redmi.

Но стоит не забывать, что есть страны Латинской Америки, Африки, Юго-Восточной Азии, где ситуация с разработкой и устройствами совершенно другая, чем в Штатах, Европе или СНГ. Там до сих пор используют такие технологии, как Cordova, PhoneGap, потому что это дёшево, а iPhone там очень непопулярны — банально не по карману.

О самых сложных задачах

Какие задачи в мобильной разработке самые сложные?

Всё зависит от того, что считать задачами. Есть интересные фичевые задачи, которые дают возможность разрабатывать что-то новое. Есть рутинные, неинтересные, но простые задачи, которые просто отнимают много времени.

А есть задачи-челленджи, когда ты создаёшь что-то на основе сложной библиотеки или, наоборот, из простых исходников делаешь суперсложное решение — например, для работы со звуком, видео, сканеры и т.д.

Но многие скажут, что самая сложная задача — это работа с заказчиком, с ТЗ, работа между командами. То есть, есть элемент технического челленджа, а есть — психологического. Разработчику надо уметь преодолевать и те, и другие, потому что это позволяет потом работать проще и интереснее.

Об ассемблере в 2025 году

«Какое место в Android и, видимо, iOS-разработке занимает ассемблер в 2025 году?» Вообще ассемблер и мобильная разработка, мне кажется, две немножко разные сущности.

Честно говоря, я не пользовалась ассемблером для мобильной разработки. Если у того, кто это задал, есть наработки, пусть пришлёт, посмотрим. Или придёт на Mobius и расскажет про это — у нас ещё открыт CFP. Если это будет супер-хардовый доклад, это будет здорово!

Например, пару лет назад у нас был человек, который встроил Doom (а он написан на ассемблере) в SwiftUI. То есть низкоуровневое что-то встраивается через C, C++ (например, через NDK для Android). Всё это можно сделать.

Но возникает вопрос: зачем? Потому что есть решение «потому что могу» — и это круто. А есть принцип разумной достаточности: не надо усложнять решение там, где это не нужно. Мы экономим и делаем оптимальной не только архитектуру приложения, но и время разработчика. Так что, отвечая на вопрос: есть Doom UI. Можете посмотреть: где только Doom не запускали.

О дизайне под Android и iOS

«Почему менеджеры и дизайнеры всегда хотят, чтобы на Android всё выглядело точно так же, как на iOS?»

Я думаю, потому что это красиво. У iOS долгое время очень много вкладывалось в визуал, в неповторимые жесты и систему. Это было просто супер. Затем Google решил догнать. Сначала появился Material Design, потом более продвинутый. И теперь, если посмотреть на доклады Google и Apple, можно заметить, что в какой-то момент предложения инженеров Google превращают Android в iOS, а у iOS есть тенденция становиться визуально похожим на Android.

Основная причина, почему хочется использовать iOS-подобный дизайн на Android, — «потому что красиво». Но Android не повезло: красивые вещи довольно затратны. Изначально Android затачивался под аппараты для всех, включая страны с дешёвыми устройствами малой мощности. Тащить туда всю красоту — вредить пользователям. Там действует принцип «максимум возможностей при минимальных затратах».

Ну да, Apple всегда стремились делать очень красиво. Так, скоро же выйдут новые модели Apple, они там всё выкатят в сентябре. Там какие-то изменения по разработке будут под iOS?

Я думаю, не без этого. Изменения идут каждый год, иногда несколько раз в год. Но что хорошо у Apple и Google — нет таких радикальных изменений, чтобы все бросали работу и шли переписывать приложение под новую парадигму.

Были у них такие периоды, но это было связано скорее с языками (Swift у Apple, Jetpack Compose у Google), которые сильно менялись. Но кардинальной смены инструментов или парадигмы в ближайшее время не планируется.

Крик души мобильного разработчика

Так, ещё у нас остался один большой вопрос, прямо крик души. Цитирую: «Почему на симуляторе всё работает, а на телефоне нет? Телефон тупее? Если отключу фоновые процессы, батарейка начнёт заряжаться в обратную сторону? А можно сделать так, чтобы приложение работало одинаково на всех 19 тысячах моделей телефонов? Почему я должна платить 99 долларов в год, чтобы тестировать на своем же телефоне? Почему пуши приходят только тогда, когда я уже сама все проверила вручную? Почему SwiftUI делает все проще, но я все равно страдаю?»

Я так понимаю, это крик души. Мы пойдём по частям. Судя по желанию, «чтобы оно работало везде одинаково», — это PM или Product Owner detected. «Нехорошо, неправильно не делайте, делайте правильно». Вот такой тезис.

Давай пройдёмся по частям.

Про симулятор и телефон. Эмулятор имеет ограниченные ресурсы и параметры ОС. Он запускается на вашем компьютере, где ресурсов больше, и вы можете настроить сеть, например, прокси. А телефон — это реальное железо с ограниченными ресурсами, которых может не хватить. Кроме того, на эмуляторе некоторые вещи могут игнорироваться или, наоборот, не воспроизводиться. Тестировать на эмуляторе безопаснее для вашего телефона, его ресурсы просто сожрутся. Хотя тестировщик, конечно, должен проверять на реальных устройствах.

Про 99 долларов. Вы платите не мне, а компании Apple. А компания Apple считает, что вы должны платить, «потому что они красивые». Вот. Такова жизнь.

Про пуши и SwiftUI. Можно сказать, что страданиями душа совершенствуется, а также навыки разработчика. У каждой технологии есть подводные камни, главное — правильно её использовать. Но даже если вы знаете, как правильно, вы не застрахованы от багов и питфолов.

С пушами отдельная история. Доставка пуш-уведомлений — вещь негарантированная. Многое зависит от сервиса, который вы используете (Firebase часто капризничает, try RuStore, они стабильнее), от территориальных особенностей, от того, как настроена рассылка. На Android и iOS разные политики работы с пушами. Иногда, если понизить приоритет пушам, они дойдут гарантированнее, чем с высоким приоритетом. Всё индивидуально.

А по SwiftUI... Я очень сочувствую вашему опыту. Если вы посмотрите WWDC последних двух лет, особенно этот год, они даже не прикладывают исходники тех примеров, которые показывают. То есть покажут сниппет, а целиком приложение не дают. Так что, возможно, это всё на их совести. Пусть они спят плохо.

О собеседованиях и офферах

«Почему для получения оффера недостаточно, что в своём телефоне я разработчик?»

Хороший вопрос. Когда вы приходите на собеседование и у вас проверяют знания, это не потому что мы редиски и хотим попить вашу кровушку. Мы выбираем человека, с которым будем работать.

Это как на стройке: есть прораб и рабочие. Каждый делает свою операцию. Человек, которого мы ждём в коллектив, будет брать часть нашей работы. А вы меняете ваше время, усилия и навыки на денежки. Вот так работает экономика.

Чтобы вы получили оффер, мы должны понимать, что вы придёте и сможете делать задачи. 90% вопросов на собеседовании — это либо общая теория, либо обсуждение кейсов. Тестовые задания сейчас практически не дают, особенно на миддлов и сеньоров. Мы надеемся, что человек с опытом может мысленно разложить задачу и рассказать, как бы он это сделал. Чтобы показать, что он сможет с этим работать.

Скажи, а вот такие тест-кейсы на собеседованиях помогают вычислить и не допустить тех, кто опыт накручивает?

Ох, на самом деле да. Бывает, людей вводят в заблуждение разные кураторы, и они считают, что если суперуверенно рассказать что-то HR, то он уже прошёл. Вот эти кейсы, где предлагается подумать и рассказать, как бы ты это делал, — довольно показательны.

Тем более, человек может запнуться на теории, войти в ступор. У меня самой такое было лет шесть назад. А когда просишь рассказать, как бы ты это делал, это показывает, как человек думает, как решает задачи на практике, с какими технологиями он умеет работать.

Если человек говорит: «Это всё гуглится», — возникает вопрос: «Зачем ты тогда тут?» Кейсы экономят время, не у всех может открыться среда для лайвкодинга, и они помогают понять, как человек мыслит и насколько он адекватен.

Об автомобильной разработке

Так, и вот последний странненький, на мой взгляд, вопрос. «Зачем нужны специалисты по мобильной разработке, если есть уже автомобильная?»

Хороший вопрос. Можно обыграть, что автомобильная — это разработка на vibe-кодинге, just for fun. Если говорить серьёзно, то автомобильную разработку тоже делают мобильные разработчики! Так что можно быть автомобильным разработчиком, но не сужайте себе поле, попробуйте другие девайсы, вам тоже понравится.

Например, брать с собой в карман автомобиль — это, конечно, шикарно, но не везде реализуемо. Он тяжёлый.

Зачем разработчику Swift изучать ассемблер

Ассемблер — это не просто низкоуровневое программирование, а способ понять, как код на Swift или Objective-C преобразуется в инструкции процессора. Он помогает разобраться в движении данных, оптимизировать производительность и отлаживать сложные ошибки. Изучение ассемблера не требует писать целые приложения на нем, но дает уверенность и глубокое понимание работы системы. К тому же, умение работать на уровне процессора добавляет разработчику уникальности и открывает новые карьерные перспективы.

Регистры: основа работы процессора

Регистры — это быстрые ячейки памяти процессора, своего рода «рабочий стол» для данных. На архитектуре Apple Silicon (ARM64) они выполняют следующие роли:

• x0–x7: передача аргументов и возвращаемых значений.
• x8: регистр косвенных результатов (используется редко).
• x9–x15: временные регистры для промежуточных вычислений.
• x16–x17: для системных вызовов (например, указание номера вызова).
• x18: регистр платформы, сохраняемый между вызовами.
• x19–x28: регистры, которые нужно сохранять при вызове функций.
• sp (x31): указатель стека, хранящий локальные данные.
• pc: счетчик программы, указывающий на следующую инструкцию.

При выполнении системного вызова (например, для вывода текста в консоль) аргументы загружаются в регистры x0, x1 и далее, номер вызова — в x16, а команда svc 0 передает управление ядру системы.

Настройка Xcode для работы с ассемблером

Чтобы начать писать код на ассемблере, нужно настроить проект в Xcode:

1. Откройте Xcode и создайте новый проект: File → New → Project….
2. Выберите Command Line Tool в разделе macOS, затем нажмите Next.
3. Назовите проект, например, HelloAsm, выберите язык C (его позже заменим) и нажмите Create.
4. В Project Navigator удалите файл main.c.
5. Добавьте новый пустой файл: File → New → File… → Other → Empty, назовите его main.s и нажмите Create.
6. В настройках проекта откройте Build Phases и убедитесь, что main.s добавлен в Compile Sources.

Теперь Xcode будет компилировать файл main.s как точку входа для программы на ассемблере.

Первая программа: «Hello, Assembly!»

Рассмотрим минимальную программу, которая выводит «Hello, Assembly!» в терминал. Вот ее структура с пояснениями:

• .section __TEXT,__text & .global _main: указывает, что это исполняемый код, а _main — точка входа.
• mov x0, 1: задает 1 (stdout) как первый аргумент системного вызова.
• adrp/add: загружает адрес строки msg в регистр x1 (с учетом разбиения на страницы).
• mov x2, #0x11: задает длину сообщения (включая символ новой строки и нулевой терминатор).
• mov x16, #0x4: указывает номер системного вызова для записи в macOS.
• svc 0: выполняет системный вызов, передавая управление ядру.
• Повторение для вызова выхода.

Примечание: в коде используются шестнадцатеричные числа. Знание преобразования между десятичными, двоичными и шестнадцатеричными числами пригодится.

Сборка и запуск

Соберите и запустите проект в Xcode. При успешной компиляции в терминале появится:

Hello, Assembly!

Если вывод не появился, проверьте:

• Файл main.s добавлен в Compile Sources.
• Нет лишних C-файлов, которые могут переопределить main.
• Архитектура проекта соответствует вашему оборудованию (Intel или Apple Silicon).

Что дальше

Написав первую программу на ассемблере, вы сделали шаг к пониманию работы процессора. Продолжайте изучать регистры — это упростит отладку и поможет лучше понимать, где находятся данные в вашем коде.

Мы собрали лучшие инструменты для мобильного программирования: от простых редакторов до IDE с компиляторами и отладчиками. Вы узнаете про приложения для фронтенда и бэкенда. Мы затронем тему вайб-кодинга и даже расскажем, как установить Linux-терминал поверх Android или iOS.

Ссылки на приложения опубликовали в комментариях.

CodePen

• Приложение для браузера: ✅
• Приложение для Android: ✅
• Приложение для iOS: ❌

Обзор начнём с онлайн-платформы для фронтендеров CodePen. Песочница работает с HTML, CSS, JS. С её помощью разработчики обмениваются идеями, создают прототипы и обучаются вёрстке. CodePen ценят за простоту – открыл песочницу, написал код, увидел результат.

Проекты называются «пэнами», ими можно делиться с другими пользователями. Ещё есть лента, где публикуют интересные работы с открытым кодом. Проекты можно копировать себе, оценивать и комментировать.

CodePen поддерживает 7 фреймворков, 5 библиотек и 24 набора UI-компонентов. Возможности ограничены только мощностью устройства: превью тяжёлых пэнов на телефоне будет лагать.

На бесплатном тарифе можно создавать неограниченное количество пэнов, коллекций и шаблонов. Единственное неудобство – добавлять картинки нужно через альтернативный хостинг. За $8 в месяц можно грузить картинки напрямую, работать в команде с коллегами, создавать личные пэны, которые закрыты от других пользователей.

Code Editor

• Веб-приложение: ❌
• Приложение на Android: ✅
• Приложение на iOS: ✅

Универсальный редактор Code Editor подсвечивает синтаксис 110+ языков. В приложении есть поиск и замена символов, отображение и скрытие строк, выделение совпадающих скобок, автоматические отступы.

Фронтендеры скачивают Code Editor ради предпросмотра HTML и плагина Emmet. Также через встроенную консоль удобно тестировать и отлаживать JS-скрипты.

Приложение распознает комбинации клавиш, поэтому к телефону можно подключить физическую клавиатуру и кодить как за маленьким монитором.

Code Editor поддерживает FTP, FTPS, SFTP и WebDAV для работы с удалёнными серверами. Ещё в приложение добавили Google Диск, Dropbox и GitHub, чтобы синхронизировать файлы между устройствами.

Acode

• Веб-приложение: ❌
• Приложение на Android: ✅
• Приложение на iOS: ❌

Редактор Acode охватывает 100+ языков программирования. Приложение оптимизировано для работы с файлами до 50000 строк. Acode выбирают для мобильной разработки, быстрых правок и обучения программированию.

Встроенный просмотр HTML и Emmet ускоряет вёрстку. В JS-консоли можно тестировать код фрагментами без создания отдельных файлов. Веб-сайты запускаются прямо в браузере приложения. Ещё редактор поддерживает GitHub, FTP/SFTP для работы с удалёнными серверами.

Плагины расширяют функционал Acode. Например, можно установить эмулятор терминала или добавить ИИ-агента от популярных провайдеров.

Pydroid, Cxxdroid, Jvdroid

• Веб-приложение: ❌
• Приложение на Android: ✅
• Приложение на iOS: ❌

Приложения от одного разработчика не случайно объединили в один раздел – это лучшие мобильные IDE для Python, C/C++ и Java. Каждое заточено под конкретный ЯП, но все построены на одной архитектуре и предлагают схожий функционал.

IDE работают автономно – интернет нужен только для скачивания дополнений. В каждом приложении есть терминал, примеры кода для обучения, система управления пакетами и библиотеками.

Редакторы поддерживают:

• подсветку синтаксиса,
• работу с вкладками,
• расширенную клавиатуру,
• быструю публикацию кода на Pastebin.

Pydroid 3 – самое функциональное приложение из тройки. Это интерпретатор Python 3 с менеджером пакетов pip и готовыми библиотеками для data science:

• numpy,
• scipy,
• matplotlib,
• scikit-learn,
• jupyter.

В премиум-версии доступны OpenCV, TensorFlow и PyTorch.

Есть поддержка GUI-приложений через Tkinter, Kivy с SDL2-бэкендом и PySide 6. Также встроен компилятор C/C++/Fortran для сборки нативных библиотек и Cython.

Отладчик PDB работает с точками останова. Приложение определяет используемые библиотеки и переключается на соответствующий режим выполнения. Ещё редактор автоматически ставит отступы и предлагает навигацию по методам.

Cxxdroid – это компилятор C/C++ на базе Clang с поддержкой ассемблера. В менеджере пакетов есть популярные библиотеки:

• Boost,
• SQLite,
• ncurses,
• libcurl.

Графические библиотеки SDL2, SFML и Allegro доступны в премиум-версии.

Разработчики заморочились над системой кэширования, которая ускоряет сборку в среднем в 3 раза, а при использовании Boost – до 33 раз. Также есть режим интерпретатора (REPL) на основе CERN Cling для интерактивной работы с кодом.

Архитектура приложения исключает падения IDE из-за ошибок в пользовательском коде – анализ и компиляция выполняются одним компилятором.

Jvdroid работает на OpenJDK 11 – редактор поддерживает стандарты Java и jar-библиотек. Интегрирован с Maven для управления проектами и зависимостями. Компилятор оптимизирован с помощью Nailgun.

Приложение включает JShell для интерактивной работы с Java. Есть компиляция программ на Kotlin, Scala и Clojure через Maven. Ещё редактор показывает Javadoc для методов и классов.

Replit

• Веб-приложение: ✅
• Приложение на Android: ✅
• Приложение на iOS: ✅

Replit – облачная IDE с ИИ-агентом. Вы получаете помощника, который создаёт проекты по промпту: описываете идею приложения, агент предлагает функции, генерирует код и деплоит в облако.

Ассистент автоматически разбивает большие файлы на части, оптимизирует работу с API, добавляет нужные библиотеки. Есть поддержка основных языков:

• Python,
• JavaScript,
• TypeScript,
• C++,
• HTML/CSS,
• Java,
• Ruby и десятки других.

До 100 человек могут одновременно редактировать код. Готовые проекты деплоятся одним кликом. Доступна выделенная VM, автоскейлинг, деплой по запросу.

Встроенные инструменты:

• Автодополнение кода через Ghostwriter.
• Поиск и исправление ошибок в реальном времени.
• Модульное тестирование без настройки.
• Интеграция с GitHub (автосинхронизация).
• Аутентификация пользователей через Repl Auth.

ИИ-агент поддерживает ограниченный набор технологий – Flask и Node.js. С React и другими фронтенд-фреймворками могут быть проблемы. Интеграции доступны только с OpenAI, Google, PostgreSQL и S3.

Официальные приложения для iOS и Android позволяют кодить прямо с телефона. Интерфейс адаптирован под сенсорные экраны, поддерживается голосовой ввод для общения с ассистентом.

Replit подходит для быстрого прототипирования, обучения и создания простых веб-приложений. ИИ-агент понравится тем, кто хочет воплотить идею в код без знаний разработки. Для сложных проектов не подойдет, но для MVP и экспериментов – хороший выбор.

Termux (iSH Shell)

• Веб-приложение: ❌
• Приложение на Android: ✅
• Приложение на iOS: ✅

Termux – это полноценный Linux-терминал для Android. В отличие от редакторов кода, вы получаете ОС со всеми инструментами программиста. Можно работать с любыми языками программирования, компилировать код, устанавливать библиотеки, подключать базы данных, настраивать веб-серверы.

После установки в приложении вы увидите только чёрный экран – это Linux-терминал. Графического интерфейса нет, всё управляется командами.

Перед работой обновите систему:

Первая команда проверяет доступные обновления, вторая их устанавливает. На все вопросы отвечайте «Y».

Termux используют системные администраторы, разработчики, студенты IT-специальностей и все, кому нужна мобильная среда разработки. Единственный нюанс – нужно время на изучение bash, но это справедливая цена за мощный и гибкий инструмент.

Подведём итоги

Выбор мобильного редактора зависит от ваших задач:

• Для фронтенда подойдут CodePen (веб-разработка и прототипирование), Code Editor и Acode (универсальные редакторы с поддержкой HTML/CSS/JS).
• Для бэкенда есть отдельные IDE: Pydroid для Python, Cxxdroid для C/C++, Jvdroid для Java. Они работают автономно и включают все необходимые инструменты.
• Для экспериментов с ИИ попробуйте Replit – облачную IDE с умным ассистентом, который создаёт приложения по описанию.
• Для профессиональной разработки установите Termux (Android) или iSH Shell (iOS) – это полноценные Linux-терминалы с неограниченными возможностями.

Знаете классное приложение, которое не попало в подборку? Расскажите в комментариях о его плюсах и минусах! Ваши советы помогут коллегам в поисках идеального инструмента для работы с кодом на смартфоне.

Кроме визуального апгрейда, iOS 26 готовит платформу к будущим устройствам и меняет логику взаимодействия с интерфейсом. Разбираемся, зачем Apple полностью переосмысляет дизайн и как это повлияет на пользователей, разработчиков и рынок.

Когда ждать релиз iOS 26 и кто её получит

Первая бета-версия для разработчиков стала доступна 9 июня, сразу после WWDC. Публичная бета ожидается с 14 по 21 июля 2025 года. Финальный стабильный релиз запланирован на сентябрь, одновременно с выходом линейки iPhone 17.

iOS 26 получат устройства, начиная с iPhone 11 и новее. Владельцы iPhone XR, XS и XS Max останутся на iOS 18.

Что такое Liquid Glass

Это новый визуальный стиль интерфейса, который Apple представила в iOS 26. Он основан на полупрозрачности, размытии фона и эффекте глубины. Панели, кнопки и другие элементы теперь выглядят как стеклянные поверхности с лёгким свечением и размытым фоном.

Такой подход уже знаком пользователям: похожие эффекты применялись в Windows Vista (Aero Glass) и Android с Material You. В iOS 26 они выполнены в более адаптивной форме. Анимации теперь стали контекстно-зависимыми, а сама система — динамичнее. Интерфейс реагирует на поведение пользователя вместо выполнения команд.

Резюмируем, какими будут визуальные особенности:

• Полупрозрачные и размытые элементы UI
• Плавные переходы и анимации с физическим моделированием
• Динамическая реакция интерфейса на фокус, жесты и состояние экрана

С технической точки зрения Liquid Glass требует больше ресурсов, и поэтому iOS 26 недоступна на устройствах до iPhone 11.

Как обновление влияет на дизайн и разработку

Редизайн iOS заставит пересмотреть подход к проектированию интерфейсов и логике разработки мобильных продуктов.

Для разработчиков

Система получила обновленные UIKit и SwiftUI, в которых появились новые параметры для настройки анимаций и поведения элементов интерфейса. Теперь вместо ручной отрисовки переходов разработчик может задать жесткость, скорость, инерцию. Система сама просчитает анимацию с помощью физического движка.

Разработчикам теперь достаточно задать числовые параметры, и система автоматически создаст натуральные переходы и микровзаимодействия.

Также появляются механизмы для адаптации UI под разные форм-факторы — это важно на фоне слухов о складных устройствах. Девелоперам придется проявить гибкость мышления в работе с переменными размерами экранов.

Для дизайнеров

Дизайнерам предстоит адаптироваться к концепции живого, полупрозрачного интерфейса. В iOS перекочевал подход для AR-сред. Теперь важно подстраивать поведение UI в разных состояниях и сценариях.

В то же время появляются ограничения. Пока ни Figma, ни Sketch, ни другие инструменты не поддерживают эффект Liquid Glass или физику взаимодействий. Прототипировать и тестировать дизайны станет сложнее.

Пользователи начнут ждать таких же гибких интерфейсов от всех приложений. Это особенно сложно для кроссплатформенных решений.

Apple Intelligence: ИИ без ассистента

Компания представила искусственный интеллект как набор функций, встроенных в повседневную рутину. ИИ анализирует ваши действия, чтобы предложить помощь в нужный момент. Большая часть операций выполняется на устройстве, что важно для конфиденциальности. С разрешения пользователя система может обращаться к ChatGPT для сложных запросов. По умолчанию она работает локально.

Apple подчеркивает, что не сохраняет и не читает ваши данные. Все процессы происходят на устройстве или через Private Cloud Compute. Это промежуточный вариант, где запрос обрабатывается в облаке, но без сохранения истории.

iPhone сам предлагает решение, когда нужно, оставаясь при этом практически невидимым. Apple превращает саму систему в умного ассистента.

Где работает ИИ-ассистент:

• Сообщения и письма — обобщает длинные переписки, предлагает автоматические ответы, сортирует уведомления по приоритетности
• Звонки — транскрибирует разговоры и выдает краткое содержание
• Снимки экрана — распознаёт контент и предлагает действия: добавить встречу в календарь, найти товар по изображению и т.д.
• Переходы между приложениями — связывает действия: например, превратить голосовую заметку в текст и сразу отправить её в мессенджер.
• Персонализированные действия Siri — на основе контекста и привычек пользователя.

Такой подход позволяет системе действовать проактивно, не отвлекая пользователя голосовыми интерфейсами. Это делает UX более органичным.

Пользователю важен не чат с ИИ, а то, что интерфейс сам понимает контекст. Apple внедряет ИИ как часть UX — это зрелый подход.

ИИ-ассистент работает не на всех устройствах — только iPhone 15 Pro и новее, iPad и Mac на M-чипах. Некоторые функции появятся не сразу, а будут добавляться в течение 2025–2026 года.

Новые и обновлённые приложения

В iOS 26 обновились практически все ключевые приложения. Карты стали визуально легче и получили мягкие переходы между уровнями. В Wallet добавили новые сценарии отображения карт и улучшили доступ к билетам и кодам. Apple Music изменилась визуально: обложки больше, плеер — плавнее, появились первые элементы персонализации на основе ИИ.

Сообщения и Телефон теперь адаптируются под сценарии использования — от отображения звонков до плавных анимаций при переходе между чатами. Интерфейс стал чуть менее предсказуемым, но более живым.

Появилось и совершенно новое приложение — Apple Games. Это не просто каталог, а игровой хаб: там собраны достижения, рекомендации и челленджи с друзьями. Похоже, Apple решила снова попробовать зайти в гейминг, но уже с упором на персонализацию.

CarPlay тоже не остался в стороне: теперь в нём работают виджеты и живые данные. Входящие звонки и уведомления стали компактнее, а интерфейс — адаптивнее и ближе к мобильной iOS. В некоторых машинах CarPlay теперь может управлять климатом и другими системами авто.

Универсальность экранов и складной iPhone

В последние пару лет Apple оформила множество патентов на устройства со складными конструкциями. Среди них:

• раскладушка,
• гибкие шарниры,
• дисплей с защитой от падения,
• экраны с гибкой текстурой,
• система компенсации цвета и яркости на складном экране.

Американские СМИ отмечают, что в свежих патентах компания пытается сочетать технологичность и приятный глазу дизайн. Потенциально новые складные дисплеи для планшетов, телефонов и ноутбуков могут иметь диагональ до 18 дюймов.

По мнению экспертов, многие нововведения в iOS 26 говорят о подготовке к устройствам следующего поколения — AR-гарнитурам и складным телефонам.

Когда интерфейсы на всех устройствах будут базироваться на одних принципах, переход в очки AR станет бесшовным и интуитивным. Liquid Glass — связующее звено.

Возможные проблемы и ограничения

Как и любое масштабное обновление, iOS 26 не обошлась без шероховатостей. Однако некоторые блогеры на YouTube отмечают, что бета-версия содержит уж слишком много багов по сравнению с бетами ранних iOS.

Пользователи массово жалуются на подтормаживания, вылеты стандартных приложений, зависания интерфейса и артефакты при переключении между экранами. Особенно это касается моделей iPhone 11–12 — устройства тянут Liquid Glass, но не без усилий.

Эффект жидкого стекла как визуальная фича тоже вызывает очень много споров и баталий. На Reddit считают, что Apple превратила классную идею просто в запотевший экран. Чтобы получить действительно красивый эффект, нужны минималистичные обои и центр управления. Тем, кто привык к многоцветным картинкам и множеству иконок, сложно воспринимать заблюренные значки.

В профессиональном сообществе уже обсуждаются два слабых места Liquid Glass. Это снижение читаемости на пёстрых фонах и сбои в работе VoiceOver — экранной озвучки для слабовидящих пользователей. В бета-версии iOS 26 фокус может «прыгать», а чтение — прерываться на полуслове.

Сравнение основных функций старой и новой iOS

Собрали в таблицу, что изменилось в интерфейсе Apple.

Выводы

• iOS 26 — переход к новой логике интерфейса: гибкой, адаптивной, контекстной
• ИИ работает в фоновом режиме — незаметно встраивается в рутину
• Обновления системы затронули все составляющие: от базовых приложений до архитектуры UI
• Новые подходы повлияют на разработку и дизайн: возрастут требования к адаптивности, контексту и микровзаимодействиям
• Обновления получат модели iPhone 11 и выше
• Apple создает задел на будущее: интерфейс постепенно подстраивается под человека, под аксессуары AR и под возможные «раскладушки»

Стоит ли ждать осени? Если любите стабильность, лучше подождать. Если нравится тестировать сырой продукт и отлавливать баги — вперёд в публичную бету в июле.

ИИ теперь — такое же базовое свойство платформы, как графический движок. Мы свидетели начала новой эры эволюции iOS.

Теперь система как бы живёт вместе с пользователем. Это уже не просто оболочка, а сопроцесс.

Инструменты и окружение

Современные DevOps-инженеры без инструментов — как админ без терминала. Вот что стоит добавить в стек:

Топ-10 инструментов DevOps, которые упростят вашу жизнь и избавят от ночных релизов — Список лучших инструментов для DevOps-инженеров, которые упрощают релизы, мониторинг и CI/CD-процессы. От логгирования до автоматизации тестов.

Podman: Альтернатива Docker без daemon — Знакомим с Podman, инструментом, который не требует daemon, но дает весь функционал Docker.

Docker Hub в России — всё? Гайд, как обойти блокировку —Объясняем, как работать с Docker Hub после блокировки: альтернативы, зеркала и решения.

CI/CD, Kubernetes и деплой

Когда каждое изменение должно доходить до продакшена быстро и без боли — нужна хорошая сборка:

Разворачиваем инструменты CI/CD: практики от DevOps-инженеров — Практическое руководство по внедрению и настройке CI/CD: инструменты, примеры, лайфхаки.

Собираем и деплоим в Kubernetes приложение на Node.js с помощью werf — Пошагово показываем, как собрать и развернуть приложение на Node.js в Kubernetes с помощью инструмента werf.

Как автоматизировать деплой с использованием Kubernetes — Рассказываем, как автоматизировать процесс деплоя приложений в Kubernetes: подходы, инструменты и советы.

Выбираем оптимальную архитектуру мониторинга: от легковесного сервиса до высоконагруженных кластеров —Рассматриваем варианты мониторинга от минимальных решений до сложных систем, подходящих под высокие нагрузки.

Практики и подходы

Не только инструменты, но и культура разработки — основа DevOps:

Как стать DevOps в 2024 году — Что нужно знать, какие навыки прокачивать, с чего начать.

Как автоматизировать безопасность с помощью DevSecOps и искусственного интеллекта — Объясняем, как применить DevSecOps-подход и AI для защиты приложений на всех этапах разработки.

Как serverless-технологии помогают снизить нагрузку на разработчиков — Разбираемся, как serverless помогает ускорить разработку, упростить масштабирование и снизить поддержку инфраструктуры.

Не забывайте читать предыдущие гайды. Python, React, мобильная разработка, С++, инструменты, фронтенд.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

1. Топовые инструменты для фронтенд-разработки в 2025 году — собрали самые полезные инструменты, которые помогут фронтендерам работать быстрее и лучше в 2025 году.
2. ReactJS на изи: что реально нужно знать фронтенд-разработчику в 2025 году — кратко и по делу: что должен знать разработчик, работающий с React в 2025 году. Хуки, компоненты, архитектура.
3. Что должен знать уважаемый фронтендер в 2024 году — обновленный список знаний для фронтенд-разработчиков. Современные фреймворки, DevTools и подходы.
4. Фронтенд-разработка: чем занимаются и сколько зарабатывают специалисты — Объясняем, чем занимается фронтенд-разработчик, какие бывают задачи и сколько можно зарабатывать.
5. Как работать с JSON в веб-разработке — простое объяснение JSON: как он устроен, как его использовать и почему без него не обойтись на фронтенде.
6. Как выбрать IDE, если вы начинающий веб-разработчик — обзор самых удобных и популярных сред разработки для начинающих веб-разработчиков, их плюсы и минусы.
7. Эффективные инструменты для оптимизации кода во фронтенд разработке — собрали инструменты, которые помогут ускорить загрузку, уменьшить размер и повысить читаемость кода.
8. 30 самых полезных библиотек Python для веб-разработки в 2024 году — лучшая подборка Python-библиотек для веба: от фреймворков до утилит. Что взять в 2025 году.
9. На каком языке писать сайт в 2024 году — помогаем выбрать язык программирования под сайт в 2025 году. Сравнение по скорости, удобству и экосистеме.

Предыдущие подборки лежат здесь: Python, React, мобильная разработка, С++, инструменты.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

База и теория

1. Event loop для чайников: простыми словами о сложном механизме браузера — В статье разбираем, что такое Event Loop, очередь задач и стек вызовов. Простыми словами о том, как браузер выполняет JavaScript-код и обрабатывает события.
2. Чек-лист по Node.js для новичков: обработка ошибок — Показываем основные подходы к обработке ошибок для Node.js. Рассматриваем пошаговую инструкцию и практические примеры.
3. Что нужно учить JavaSript-разработчикам в 2024 году — Разбираем, какие технологии и навыки нужно знать JS-разработчику, в том числе и в 2025. От фреймворков до подходов к архитектуре.
4. Декларативные языки на примерах с JavaScript — Рассказываем, что значит декларативный стиль программирования. Сравниваем с императивным на примерах JavaScript.
5. JavaScript localStorage: Полное руководство — Разбираем, как работает localStorage. Учим сохранять данные на клиенте с помощью JavaScript.
6. Как работает режим strict в JavaScript — Объясняем, что делает режим strict и почему он помогает писать более безопасный код на JavaScript.
7. Как бесплатно выучить JavaScript и не идти в онлайн-школы — Рассказываем, как самостоятельно освоить JavaScript. Бесплатные ресурсы, полезные советы и личный план обучения.
8. Какие JS-библиотеки использовать для анимаций на сайте в 2024 году — Актуальные JavaScript-библиотеки для веб-анимации. Рассматриваем лучшие инструменты для красивых и быстрых интерфейсов.

Практикуемся

1. 10 реальных вопросов с собеседования JavaScript-разработчика с ответами — Подборка реальных вопросов с собеседований для JavaScript-разработчиков. Даем ответы и объясняем, как правильно мыслить на интервью.
2. Приложение прогноза погоды с использованием Vue JS — Пошаговое руководство по созданию погодного приложения на Vue.js. Обучаем взаимодействию с API и построению интерфейса.
3. Математика в программировании: реализуем уравнения на JavaScript — Объясняем, как реализовать математические уравнения на JavaScript. Практика для программистов, которые не боятся формул.
4. Регулярные выражения в JavaScript: разбираемся в создании — Учим создавать и использовать RegExp в JavaScript. Поясняем синтаксис, паттерны и типовые ошибки.
5. Решаем популярные задачи с асинхронным кодом на JavaScript: часть первая — Практика асинхронного программирования на JavaScript. Решаем задачи с API, задержками и промисами.
6. Асинхронный JavaScript: изучаем Async/Await, Callbacks и Promises — Учим писать асинхронный код в JavaScript: от колбэков до современного async/await. Понятно, на примерах и без лишнего.
7. Задачи по асинхронному программированию на JS — Упражнения на асинхронный JavaScript. От простых примеров до сложных сценариев.

Предыдущие подборки лежат здесь: React, мобильная разработка, С++, инструменты.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

Определяем цель

Успех приложения начинается с четкого понимания, зачем оно нужно — так становится проще определить целевую аудиторию. Это влияет не только на функционал, но и на дизайн, способы продвижения и даже тон общения с пользователями.

Некоторые программы помогают развивать существующий бизнес — как это делают банковские сервисы, которые упрощают работу с клиентами. Другие становятся самостоятельными продуктами, например, для обучения, занятий спортом или развлечений.

Кроме того, приложение должно решать реальные проблемы пользователей. Допустим, вы задумали создать программу для фрилансеров. Решили провести исследование, и оно показало, что фрилансеры часто страдают от прокрастинации и ненавидят заниматься выставлением счетов клиентам. Ваша идея и главная фишка — приложение, которое автоматизирует процесс оплаты, контролирует сроки выполнения проектов и помогает планировать рабочее время.

Чтобы убедиться, что идея действительно рабочая, проведите опросы в Telegram-каналах фрилансеров или создайте анкету. Вы можете спросить, какие функции для них наиболее актуальны: автоматический расчет налогов, интеграция с платежными системами или отслеживание времени работы. Это поможет сфокусироваться на действительно важных фичах и отсеять второстепенные.

Выбираем платформу и инструменты

Сегодня на российском рынке доминируют две мобильные операционные системы: Android (около 70% пользователей) и iOS (около 30%). Оптимальным решением будет разработка приложения для обеих платформ, особенно если вы ориентируетесь на крупные города, где доля пользователей iOS существенно выше.

Приложения под Android большинство разработчиков пишет на Kotlin, хотя Java до сих пор остается одним из вариантов из-за обширной базы готовых решений и библиотек. Основной средой выступает Android Studio — в ней есть весь необходимый инструментарий для создания, отладки и тестирования приложений. Современные разработчики активно используют Jetpack Compose для построения пользовательского интерфейса, Room для работы с базами данных, Retrofit для сетевых запросов и Dagger или Hilt для внедрения зависимостей.

В мире iOS основным языком программирования стал Swift — современный и безопасный инструмент для нативных приложений. Разработка ведется в среде Xcode, официальной IDE от Apple. Для построения интерфейсов все чаще используется SwiftUI, для управления данными — Core Data, а для сетевого взаимодействия — фреймворк Alamofire. Работа с асинхронными событиями упрощается с помощью фреймворка Combine.

При ограниченных ресурсах можно рассмотреть кросс-платформенную разработку. Так, Flutter использует язык программирования Dart и позволяет создавать производительные приложения с нативным внешним видом. React Native дает возможность применять веб-технологии для мобильной разработки, а Xamarin ориентирован на разработчиков, привыкших к экосистеме Microsoft и языку C#.

Выбор платформы и инструментов должен основываться на характеристиках вашей ЦА, требованиях к функционалу и имеющихся ресурсах. Учитывайте также, что для разных магазинов приложений (RuStore, App Store, Google Play) могут потребоваться специфические оптимизации и настройки.

Продумываем функционал

При разработке функционала важно следовать концепции MVP (Minimum Viable Product) — минимально жизнеспособного продукта. Это позволит быстрее выйти на рынок, получить обратную связь и итеративно улучшить приложение.

Возьмем для примера приложение доставки еды. В этом случае MVP должен включать:

• авторизацию пользователя через телефон, email или социальные сети;
• каталог ресторанов с фильтрацией по кухне, рейтингу и времени доставки; меню каждого заведения с фотографиями и описанием блюд;
• корзину с возможностью изменения состава заказа;
• оформление заказа с выбором адреса доставки и способа оплаты;
• отслеживание статуса заказа в реальном времени;
• профиль пользователя с историей заказов.

Важно уделить внимание и техническим аспектам функционала:

• Локальное кэширование данных. Поддерживает работу приложения при слабом интернет-соединении или его отсутствии. Сохраняет каталоги, популярные позиции и историю действий пользователя.
• Офлайн-режим. Определяет набор функций, доступных без подключения к сети. Критически важен для удержания пользователей в зонах с плохим интернетом.
• Система пуш-уведомлений. Информирует пользователей о важных событиях, статусах заказов и специальных предложениях. Повышает вовлеченность и возвращаемость в приложение.
• Многопоточная обработка. Выполняет ресурсоемкие операции в фоновом режиме. Гарантирует отзывчивость интерфейса даже при выполнении сложных задач.
• Оптимизация изображений. Внедряет алгоритмы сжатия для быстрой загрузки визуального контента. Обеспечивает комфортное использование даже при ограниченной скорости соединения.

При этом разработчики часто допускают ошибки, и одна из самых распространенных — функциональная перегруженность. Не стоит добавлять AR-анимации, игровые механики и другие «модные» функции, если они не решают реальных проблем клиентов.

Также многие игнорируют обратную связь пользователей, хотя механизмы ее сбора стоит включать уже в MVP. Недостаточное внимание к безопасности может стать критичным для приложений с личными данными и платежами. А отсутствие встроенных инструментов аналитики затрудняет понимание того, как пользователи взаимодействуют с программой.

Выбор правильной архитектуры — это фундамент, который определяет надежность, масштабируемость и удобство поддержки. Вот основные паттерны для мобильных приложений:

• MVVM — рекомендуемый Google подход с разделением UI и бизнес-логики
• MVI — однонаправленный поток данных, хорошо сочетается с реактивным программированием
• MVP — классическая архитектура. Популярна благодаря простоте реализации
• Clean Architecture — многослойный подход с упором на тестируемость и гибкость
• VIPER (iOS) — расширенный MVC со строгим разделением ответственности

Важное значение имеет также выбор технологий для хранения и передачи данных. Для локальной работы подойдут SQLite + Room, Realm или DataStore; для сетевого взаимодействия на Android чаще всего используют Retrofit + OkHttp, а в реактивных сценариях — Ktor Client.

Правильный выбор архитектуры напрямую зависит от масштаба проекта и размера команды. Небольшие приложения могут обойтись простыми решениями, тогда как сложные продукты требуют комплексного подхода с продуманным разделением ответственности.

Создаем удобный интерфейс

Интерфейс — это лицо приложения. Даже если у вас отличный функционал, но пользоваться им неудобно, людям будет проще удалить программу и найти что-то другое.

Эффективный UI/UX строится на пяти ключевых принципах:

1. Очевидность (интуитивное понимание интерфейса);
2. Экономия внимания (минимум шагов для достижения цели);
3. Консистентность (единообразие элементов с одинаковой функциональностью);
4. Обратная связь (видимый результат каждого действия);
5. Прощение ошибок (возможность отмены операций).

Современные инструменты значительно ускоряют создание качественных интерфейсов. Дизайнеры используют Figma, Adobe XD и Sketch для прототипирования. Android-разработчики предпочитают Jetpack Compose и Material Design Components. Для iOS актуальны SwiftUI, UIKit и Human Interface Guidelines от Apple.

Наглядный пример различий между хорошим и плохим интерфейсом — приложения для доставки еды. В удачном решении ключевые элементы находятся в зоне комфортного доступа, процесс заказа разбит на логические шаги с индикацией прогресса, а дизайн адаптируется к условиям использования. В неудачном — мелкие тесно расположенные кнопки, длинные формы без разбивки на шаги и непонятная навигация.

Проводим тестирование

Юзабилити-тесты с фокус-группами, A/B-тестирование элементов и аналитика пользовательского поведения дают объективную картину взаимодействия клиентов с приложением.

Комплексное тестирование включает два основных направления:

1. Автоматизированное тестирование: unit-тесты (JUnit, XCTest) для проверки отдельных компонентов; интеграционные тесты для проверки взаимодействия между модулями; UI-тесты (Espresso, XCUITest) для проверки интерфейса; end-to-end тесты для имитации полного пользовательского сценария.
2. Ручное тестирование: функциональное (соответствие требованиям), тестирование производительности (работа под нагрузкой), юзабилити (оценка удобства), кросс-платформенное тестирование (проверка на разных устройствах) и тестирование подключений (поведение при различном качестве интернет-соединения).

Для этого используют специализированные инструменты: Firebase Test Lab для запуска тестов на множестве устройств, Crashlytics для мониторинга сбоев, Android Profiler и Xcode Instruments для анализа производительности. А Accessibility Scanner помогает адаптировать интерфейс для людей с ограниченными возможностями, расширяя потенциальную аудиторию.

Публикуем приложение

После тестирования и исправления проблем наступает ответственный момент публикации. Каждый магазин приложений имеет свои особенности процесса:

• Google Play: создание аккаунта разработчика ($25 единоразово); подготовка материалов (иконка, скриншоты, видео, описание); загрузка APK/App Bundle; заполнение формы оценки контента; настройка дистрибуции и ценообразования; ожидание проверки (до 2 дней).
• App Store: регистрация в Apple Developer Program ($99/год); создание записи в App Store Connect; подготовка маркетинговых материалов; загрузка сборки из Xcode; заполнение информации о возрастных ограничениях; ожидание рассмотрения (1-7 дней).
• RuStore: бесплатное создание аккаунта; подготовка материалов; загрузка APK; заполнение метаданных; быстрая модерация (до часа).

Перед публикацией важно убедиться в соответствии приложения правилам магазина, подготовить политику конфиденциальности и настроить аналитику для мониторинга производительности с первого дня.

Поддерживаем и обновляем

После выпуска начинается непрерывный процесс поддержки и совершенствования продукта. Разработчики регулярно исправляют найденные ошибки, добавляют новые функции и улучшают работу уже существующих.

Для эффективного мониторинга используют комплексные аналитические инструменты: Firebase Crashlytics для отслеживания сбоев, Firebase Analytics/Google Analytics для анализа пользовательского поведения, RuStore Remote Config — бесплатный аналог Firebase, Mixpanel для углубленного анализа пользовательских путей, AppMetrica от Яндекса как комплексное решение для российского рынка.

Автоматизация процессов разработки критически важна для регулярных релизов. CI/CD-системы (GitHub Actions, GitLab CI, Bitrise, Fastlane) позволяют автоматизировать сборку, тестирование и публикацию обновлений, значительно сокращая время выхода новых версий.

Оптимальная стратегия обновлений включает регулярный график релизов (каждые 2-4 недели) с четким приоритетом задач: критические исправления, новые функции, оптимизация производительности. В тренде современной разработки: персонализация на основе ИИ, многофункциональные суперапп-решения, адаптация под новые форм-факторы устройств и повышенное внимание к приватности данных.

Продвигаем приложение

На рынке огромная конкуренция, и без активного продвижения ваш продукт просто затеряется среди тысяч других программ. Важную роль здесь играет ASO (App Store Optimization) — оптимизация для магазина приложений. В некоторых случаях был зафиксирован рост установок до 70% благодаря сильным ASO-стратегиям.

Для Android-приложений это означает настройку страницы так, чтобы пользователи легко находили ваш продукт. Здесь важно правильно подобрать ключевые слова для описания, создать привлекательную иконку и подготовить качественные скриншоты. Чтобы понять, какое оформление работает лучше, разработчики всё чаще используют A/B-тесты — такая возможность есть, например, в RuStore. Она позволяет сравнить разные версии карточки приложения и выбрать ту, которая эффективнее привлекает пользователей.

Также разработчики могут использовать как бесплатные, так и платные форматы продвижения. Один из бесплатных форматов — фичеринг, когда редакция размещает приложение в подборках, разделах или на главной странице магазина. Платное же продвижение позволяет настраивать таргетинг по демографии, географии, интересам, ключевым фразам и устройствам, а также запускать кампании прямо в поисковой выдаче магазина.

Еще один инструмент для продвижения приложений — социальные сети. Здесь можно показывать функционал программы, общаться с пользователями, отвечать на их вопросы и рассказывать о новых опциях. Это помогает создать активное сообщество вокруг продукта. Так, к примеру, В 2023 году компания Geozilla, разработчик приложения для отслеживания местоположения близких, провела кампанию по продвижению с инфлюенсерами в социальных сетях. В рамках сотрудничества удалось собрать более 1 миллиона просмотров, а коэффициент конверсии из кликов в установки приложения составил 24%.

Партнерские программы и рекламные кампании тоже сильно влияют на привлечение новых пользователей. Нельзя забывать и о работе с отзывами — нужно активно отвечать на комментарии и решать проблемы, о которых пишут люди.

Собственный сайт или блог разработчика тоже может привлечь внимание к приложению, особенно если у вас уже есть известный бренд.

Подводим итоги

Создание успешного приложения начинается с четкого определения цели и понимания потребностей пользователей. Затем нужно выбрать подходящие технологии, продумать необходимые функции, спланировать архитектуру и разработать понятный интерфейс. Обязательно проведите тщательное тестирование перед запуском. После публикации важно регулярно обновлять приложение на основе отзывов пользователей и данных аналитики, а также активно продвигать его в магазинах приложений и социальных сетях.

Не гонитесь за модными технологиями ради технологий — сосредоточьтесь на том, что действительно нужно вашим пользователям. Если вы создадите действительно полезный и удобный продукт, он найдет свою аудиторию и станет успешным.

iOS или Android? React Native или Flutter? Собираем все новости и гайды по мобильной разработке тут.

Это лишь один из многих довольно общих примеров. Но есть уникальные кейсы, как разработчики с крайне простой идеей выпустили приложение и проснулись миллионерами — рассказываем о них в статье.

Flappy Bird (олдскулы свело)

Кто-то еще помнит эту безумную птичку? В 2013 году она появилась на iOS, а в 2014 — на Android. А разработал ее вьетнамский кодер Донг Нгуен всего за несколько дней. Сам программист заявлял, что всего его игры проходимы, и главное их отличие от сложных западных игрушек — простота, хард-левел и истинное веселье. В общем, те самые ретро-игры.

Суть, кажется, объяснять не стоит — все и так помнят, что есть пиксельная птичка, которой нельзя упасть или удариться об трубу. Самое же интересное — как в 2013 году к этой в какой-то степени дурацкой игре пришла такая популярность. На самом деле, до сих пор загадка: одни связывают это с роликом PewDiePie (на тот момент у него было уже более 20 млн подписчиков на YouTube, другие — с вирусным эффектом в соцсетях.

В январе 2014 птичка возглавила топ бесплатных приложений в американском и китайском App Store, а потом — в британском. Игрушку скачали более 50 млн раз, а разработчики зарабатывали с рекламы $50 000 долларов в сутки!

10 февраля 2014 года Нгуен неожиданно удалил Flappy Bird из App Store и Google Play. В интервью Forbes он объяснил это чувством вины: игра, задуманная как легкое развлечение на пару минут, стала для многих «наркотиком». Нгуен говорил, что не мог спать из-за давления популярности и хотел вернуть себе спокойствие. После удаления начался ажиотаж: телефоны с установленной игрой продавались на eBay за тысячи долларов, а рынок заполонили десятки клонов.

Однако в этом году должно было произойти чудо: в сентябре 2024 компания Gametech Holdings объявила, что готовит перезапуск игры в 2025 — она банально украла права у Нгуена, когда те истекли. Правда, твиттерские было выяснили, что это скам: Gametech связана с другой компанией — 1208 Productions, которая делает игры для Web 3 с NFT. А еще Gametech подписаны на кучу инфоцыганских аккаунтов в Твиттере. Вишня на торте — на официальном сайте перезапуска птички лежала демка, один из юзеров ее скачал, и в конце его попросили завести криптокошелек. В общем, птичку не тапаем, на NFT-развод не попадаем.

Но в Flappy Bird все еще можно поиграть: здесь лежит браузерная версия. Честно, феномен птички все еще для нас загадка, но зато это хороший пример, что можно создать абсолютно обычную игру и сделать так, чтобы она сильно завирусилась в сети.

BeReal

Та самая антисоциальная сеть, которая завирусилась в ТикТоке в 2022 году. Суть и реализация очень простая: приложение раз в день отправляет уведомление, и вы должны быстро сделать селфи — всего за две минуты. Неважно, где вы и что делаете — гуляете с собакой или поете в душе, главное — запостить фотографию в приложение. Никаких фильтров, масок и всего остального. Кстати, просто последить за друзьями нельзя: приложение не даст вам доступ к ленте, пока вы не выложите пост.

Сейчас у приложения нет монетизации, поэтому все цифры основываются на оценках и капитализации. Последняя сделка по BeReal прошла в июне 2024 года — привлекли более $580 млн.

Как мы помним, красота и гениальность — в простых вещах. А простые вещи — те, которые происходят с нами каждый день. Считайте, что разработчики сделали миллионное состояние просто на том, что нас окружает.

Wordle

Это простая браузерная игра, в которой нужно угадать слово из пяти букв за шесть попыток. После каждой попытки игра подсказывает, какие буквы угаданы правильно: зеленым подсвечиваются те, которые стоят на своём месте, желтым — те, которые есть в слове, но стоят не там, и серым — те, которых в слове вообще нет.

Эту игру придумал программист Джош Уордл в 2021 году как подарок для своей девушки, которая любила словесные головоломки. Он выложил её в интернет просто «для друзей», но очень быстро Wordle стала вирусной. В январе 2022 года игрушку купила The New York Times за небольшую семизначную сумму, то есть где-то за $1-3 млн.

Технология тоже очень простая: обычная веб-страница, написанная на HTML, CSS и JavaScript. Загружается список слов, одно из них выбирается как «слово дня», и дальше работает простейшая логика — сравнение букв и подсветка.

Популярность тоже вполне объяснима. Во-первых, игра ужасно простая. Там нет рекламы, регистрации, внутриигровых покупок — просто заходишь и играешь. Во-вторых, можно сыграть только один раз в день, и это ограничение превратилось в фишку — у многих игроков это стало ритуалом. Кстати, в 2022 году wordle был самым частым запросом в Google среди американцев.

Автор этой статьи тоже обожает Вордл! Это еще и отличный шанс подтянуть свой английский. Если еще не пробовали — оцениваем здесь.

Locket Widget

Еще одна до жути простая идея: делаете фото в приложении, и оно появится у ваших друзей на главном экране в виде виджета.

Мэтт Мосс запустил Locket Widget в 2022 году — он разработал приложение всего за несколько недель для своей девушки, с которой у них были отношения на расстоянии (опять романтическая история). Сейчас им пользуются десятки миллионов людей по всему миру, а в 2022 году в него загрузили более 2 млрд фотографий.

На пике популярности Мосс с командой привлекли $12,5 млрд инвестиций. Кстати, завирусилось приложение опять благодаря ТикТоку — видео в аккаунте Мосса набирали миллионы просмотров.

На самом деле подобные приложения, которые выводятся на экран в виде виджетов — настоящая золотая жила. Особенно популярными становятся различные карточки с мотивационными фразами, в общем, забирайте идею (в них можно сделать подписку за шрифты, тематики и визуал).

Calm

Calm — одно из самых известных приложений для медитации и сна. Его разработали два предпринимателя — Алекс Тью и Майкл Эктон Смит — в 2012 году. Идея была очень простой: помочь людям справляться со стрессом и тревогой с помощью коротких медитаций, приятной музыки. Интерфейс — тоже максимально минималистичный.

Когда Calm только появилось, никто особо не верил, что такое «спокойное» приложение может выстрелить. Но всё оказалось наоборот: люди устали от шума, соцсетей и перегрузки. Приложение стало настоящим островком тишины — его включали перед сном, в перерывах на работе или просто чтобы немного расслабиться.

В 2016 году Calm начал активно развиваться и добавлять новые функции, которые сделали его намного популярнее и полезнее для пользователей. Тогда появилась одна из главных фишек — Sleep Stories. Считайте, что это сказки на ночь, только для взрослых работящих людей. А сейчас самая популярная функция в приложении — 10-минутная медитация, которая доступна пользователям всего лишь 24 часа.

Конечно, сейчас приложение разрослось и стало сложнее, но на старте это был очень простой интерфейс с небольшим количеством функций (хотя, наверное, в приложении для медитации именно так и должно быть).

Уже в 2019 году Calm стал первым «единорогом» в сфере ментального здоровья — его оценили в $1 млрд, а позже — и в $2 млрд. Плюс компания зарабатывает на ежемесячных и пожизненных подписках.

Как говорится, think different, а все гениальное — просто. Приложение на миллион долларов можно сделать даже за несколько дней, главное — немного удачи, крутая идея и промо.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

Вместе с экспертами Kursfinder я изучила более 20 предложений и выбрала 17 лучших онлайн-курсов по геймдизайну. В статье они представлены в виде подборок для удобства поиска. В начале я собрала 10 программ, которые, на мой взгляд, наиболее качественные. Если ни один из этих курсов не подходит вам, ознакомьтесь с дополнительным списком из трех программ. В конце статьи вы найдете подборку бесплатных материалов. Полный список курсов по теме можно найти в каталоге Kursfinder.

ТОП-10 лучших курсов по геймдизайну в 2026 году

1. Геймдизайн. Концепт игры от Skillbox — лучший курс по основам разработки концептов для игр, включая создание механик и истории.
2. Профессия Геймдизайнер от GeekBrains — программа по подготовке специалистов в области геймдизайна с фокусом на проектирование игр и их развитие.
3. Профессия Геймдизайнер с нуля до PRO от Skillbox — интенсивное обучение, которое охватывает все этапы создания игр, от концепта до реализации.
4. Геймдизайнер от XYZ School — онлайн-курс по основам геймдизайна и разработки игр, включая создание увлекательных механик и баланса.
5. Профессия геймдизайнер от Contented — вариант для тех, кто хочет стать геймдизайнером и научиться создавать успешные игровые проекты.
6. Онлайн-курс по геймдизайну мобильных игр от Onskills — курс ориентирован на создание мобильных игр и разработку игровых механик для мобильных платформ.
7. Геймдизайн и разработка игр от Международной академии бизнеса IAB — программа сочетает теорию геймдизайна и практическую разработку игр.
8. Курсы геймдизайна от Onskills — обучение геймдизайну с нуля — от базовых концепций до сложных игровых систем.
9. Геймдизайн для детей от BKC — курс для детей, который вводит их в основы геймдизайна и помогает развить творческое мышление.
10. Геймдизайн. Базовый курс от Realtime — начальный курс по основам геймдизайна, включая создание игровых механик и концептуальную разработку.

Обучение геймдизайну подходят широкому кругу людей, которые хотят профессионально заниматься созданием игр. В первую очередь, они будут полезны новичкам без опыта, но с искренним интересом к игровой индустрии и желанием освоить эту профессию с нуля. Также курсы принесут пользу представителям смежных профессий — программистам, художникам и сценаристам, которые хотят расширить свои компетенции и глубже понять принципы игрового дизайна. Особенно ценными такие программы окажутся для аналитически мыслящих творческих людей, которые любят разбирать игры на составляющие, изучать их механику и придумывать собственные игровые системы.

Онлайн-курсы по геймдизайну

1. Геймдизайн. Концепт игры | Skillbox

Вы научитесь создавать оригинальные игровые концепции, которые найдут отклик у аудитории. Освоите навыки составления концепт-документа и ведения игровой документации. Изучите методы создания увлекательных и захватывающих игр. Поймете, из каких этапов состоит процесс создания игры, и определите свою роль как геймдизайнера на каждом этапе.

• Стоимость: 104 628 рублей
• Длительность: 3 месяца
• Формат обучения: видеоуроки, тестирования, проекты, домашняя работа
• Сертификат: сертификат установленного образца

Кому подойдет:

• новичкам;
• специалистам из смежных профессий.

Преимущества:

• доступ навсегда;
• скидка 40%;
• курс в подарок;
• бесплатная консультация;
• персональная обратная связь;
• проекты в портфолио;
• стажировка в игровой студии.

Недостатки:

• ограниченное время на скидку.

Программа обучения:

• Создаем свою игру
• Определяем целевую аудиторию
• Создаем увлекательный сюжет
• Определяем способы монетизации игры
• Анализируем игру
• Разрабатываем стратегию развития игры
• Подводим итоги

Ознакомиться с полной программой >>>

2. Профессия Геймдизайнер | GeekBrains

Вы освоите основы геймдизайна и разработаете концепцию собственной игры. Научитесь придумывать увлекательные игровые механики и создавать целые игровые миры. Станете частью сообщества студентов, изучающих игры. В команде вы будете работать над созданием игры в течение месяца. Такой опыт станет ценным дополнением к вашему резюме и повысит ваши шансы на успешное трудоустройство.

• Стоимость: 192 312 рублей
• Длительность: 8 месяцев
• Формат обучения: вебинары, видеоуроки, домашние задания, тестирования
• Сертификат: сертификат установленного образца

Кому подойдет:

• новичкам;
• тем, кто уже начал работать в данной сфере.

Преимущества:

• скидка до 45%;
• два курса на выбор в подарок;
• повышенная скидка от менеджера;
• помощь с трудоустройством;
• бесплатная консультация.

Недостатки:

• ограниченное количество мест на потоке.

Программа обучения:

• Разработка игры
• Стажировка в компании GameBox
• Level Design
• Геймдизайн. Баланс игры
• Основы разработки игр
• Заработок в играх
• Создание документации

Ознакомиться с полной программой >>>

3. Профессия Геймдизайнер с нуля до PRO | Skillbox

Освойте искусство создания оригинальных игровых концепций в различных жанрах и разработки увлекательного игрового процесса. Вы будете работать с Unity и UE5, научитесь гармонично сочетать игровые механики и систему прокачки. Научитесь удерживать внимание игроков и создавать увлекательные игровые сценарии. После завершения основных программ и формирования портфолио сможете претендовать на позицию младшего разработчика. Школа поможет вам найти работу и подготовиться к собеседованию.

• Стоимость: 156 922 рубля
• Длительность: 8 месяцев
• Формат обучения: видеоуроки, тестирования, проекты, домашняя работа
• Сертификат: сертификат установленного образца

Кому подойдет:

• новичкам с нуля.

Преимущества:

• доступ навсегда;
• скидка 40%;
• курс в подарок;
• бесплатная консультация;
• персональная обратная связь;
• проекты в портфолио.

Недостатки:

• ограниченная скидка на рассрочку.

Программа обучения:

• Разработка игры
• Стажировка в компании GameBox
• Level Design
• Геймдизайн. Баланс игры
• Основы разработки игр
• Заработок в играх
• Создание документации

Ознакомиться с полной программой >>>

4. Геймдизайнер | XYZ School

Освойте искусство разработки игровых механик, научитесь работать с документацией, создавать продуманные уровни и погружаться в атмосферу, максимально приближенную к реальным условиям работы геймдизайнера. После завершения обучения вы будете готовы начать карьеру в игровой индустрии. Программа разработана опытными профессионалами, которые работали над созданием таких игр, как Assassin’s Creed: Valhalla и Atomic Heart.

• Стоимость: от 149 500 рублей
• Длительность: 13 месяцев
• Формат обучения: вебинары, видеоуроки, тестирования, практика, домашние задания
• Сертификат: диплом или сертификат об обучении

Кому подойдет:

• новичкам с нуля.

Преимущества:

• скидка 50%;
• выгодная рассрочка;
• дополнительная скидка за оплату целиком;
• несколько тарифов на выбор.

Недостатки:

• некоторым обучение покажется долгим.

Программа обучения:

• Разработка игрового дизайна
• Создание повествовательного дизайна
• Проектирование уровней с помощью OUTBLOCK

Ознакомиться с полной программой >>>

5. Профессия геймдизайнер | Contented

Освойте навыки анализа рынка, оформления документов, работы с игровыми движками, настройки баланса игры, продвижения и поддержки проекта. Приобретите больше опыта, создавая прототипы игр на заданную тему в сжатые сроки. Это позволит вам расширить портфолио новыми проектами. Также будете много играть и разовьете насмотренность.

• Стоимость: 149 832 рубля
• Длительность: 9 месяцев
• Формат обучения: вебинары, воркшопы, видеоуроки, тестирования
• Сертификат: сертификат

Кому подойдет:

• тем, кто хочет создавать инди-игры;
• тем, кто желает совмещать хобби с работой;
• тем, кто хочет систематизировать знания.

Преимущества:

• портфолио из более 40 работ;
• грант 20 000 рублей на курс;
• бесплатная консультация;
• помощь с трудоустройством.

Недостатки:

• не во всех тарифах есть блоки работы с Blender.

Программа обучения:

• Вхождение в профессию
• Как разработать интересную игру
• Команда и стадии создания игры
• Позиционирование и уникальность
• Анализ и улучшение механик
• Тестирование и проверка предположений

Ознакомиться с полной программой >>>

6. Онлайн-курс по геймдизайну мобильных игр | Onskills

Онлайн-курс для тех, кто хочет стать геймдизайнером. Узнайте, как создать приложение с увлекательным геймплеем для мобильных устройств и как на этом можно заработать. Сертификат вы получите в электронном виде, а если вам нужен бумажный вариант, школа отправит его по почте России.

• Стоимость: от 1 900 рублей
• Длительность: 11 уроков
• Формат обучения: видеоуроки, практика
• Сертификат: сертификат

Кому подойдет:

• новичкам;
• создателям игр на ПК;
• геймерам;
• художникам;
• разработчикам.

Преимущества:

• выгодная рассрочка;
• бесплатный урок;
• неограниченный доступ к теории;
• отличная техническая помощь.

Недостатки:

• нет вебинаров.

Программа обучения:

• Знакомство с профессией
• Представление идей
• Написание истории
• Создание прототипов
• Разработка механик
• Достижение баланса
• Анализ данных

Ознакомиться с полной программой >>>

7. Геймдизайн и разработка игр | Международная академия бизнеса IAB

Вы освоите основы геймдизайна, включая принципы создания увлекательных и сбалансированных игр. Научитесь разрабатывать игровые механики и системы, работать с инструментами и технологиями для создания игр, создавать прототипы, тестировать и отлаживать игры. Поймете структуру и элементы игрового процесса, разовьете навыки командной работы и сможете применить теоретические знания на практике для создания собственных игр или улучшения существующих проектов.

• Стоимость: 11 400 рублей
• Длительность: 250 ак.часов
• Формат обучения: видеоуроки, практика
• Сертификат: диплом с международным приложением

Кому подойдет:

• новичкам.

Преимущества:

• обучение можно начать бесплатно;
• гибкий график;
• помощь в поиске работы.

Недостатки:

• мало технической поддержки.

Программа обучения:

• Основы геймдизайна
• История развития игр
• Жанры и их особенности
• Основные термины
• Создание игровых ассетов
• Разработка уровней и сцен
• Баланс и сложность

Ознакомиться с полной программой >>>

8. Курсы геймдизайна | Onskills

Обучение геймдизайнеров с нуля и получение сертификата. Узнайте, как создавать игры, которые будут увлекательными и популярными. Станьте частью сообщества GameDev с помощью Onskills. Смотрите лекции в удобное время. Доступ к курсу и всем его обновлениям останется у вас навсегда.

• Стоимость: от 1 900 рублей
• Длительность: 11 уроков
• Формат обучения: видеоуроки, практика
• Сертификат: сертификат

Кому подойдет:

• новичкам;
• создателям игр на ПК;
• геймерам;
• художникам;
• разработчикам.

Преимущества:

• выгодная рассрочка;
• бесплатный урок;
• неограниченный доступ к теории;
• отличная техническая помощь.

Недостатки:

• иногда возникают технические сбои.

Программа обучения:

• Знакомство с профессией
• Представление идей
• Написание истории
• Создание прототипов
• Разработка механик
• Достижение баланса
• Анализ данных

Ознакомиться с полной программой >>>

9. Геймдизайн для детей | BKC

Увлечение играми может привести к тому, что вы станете востребованным специалистом в этой области. Через игровую разработку можно достичь высокого уровня в программировании и создавать свои собственные миры, используя лишь свою фантазию. На программе детям расскажут, как использовать свои навыки и с чего начать, чтобы развить свой творческий потенциал и достичь успеха в этой области.

• Стоимость: 5 760 рублей
• Длительность: по запросу
• Формат обучения: вебинары, практика
• Сертификат: сертификат

Кому подойдет:

• детям 10–12 лет.

Преимущества:

• подарки первым 30 ученикам;
• скидка 10%;
• оплата мат.капиталом.

Недостатки:

• не указано время обучения.

Программа обучения:

• Разработка платформера
• Улучшение возможностей игры
• Дизайн уровней и растительность
• Интеграция программного кода
• Неожиданные события и трудности

Ознакомиться с полной программой >>>

10. Геймдизайн. Базовый курс | Realtime

В кратчайшие сроки и с максимальной интенсивностью вы получите как теоретические, так и практические знания в сфере. Эти знания позволят вам определиться с дальнейшими шагами и выстроить четкий план развития в выбранной вами области. Кроме того, программа познакомит вас с бесплатными программами и приложениями, которые помогут вам повысить эффективность работы в любой сфере.

• Стоимость: 14 000 рублей
• Длительность: 20 часов
• Формат обучения: вебинары, практика
• Сертификат: не указан

Кому подойдет:

• специалистам различных профессий;
• тем, кто хочет попасть в сферу разработки игр.

Преимущества:

• помощь с трудоустройством;
• выгодная стоимость;
• сжатые сроки.

Недостатки:

• не предусмотрена выдача сертификата.

Программа обучения:

• Современное состояние игровой индустрии
• Направления геймдизайна
• Виды игр и их особенности
• Жанры игр и их характеристики
• Способы распространения игр

Ознакомиться с полной программой >>>

Еще 3 курса по геймдизайну

Дополнительное обучение на геймдизайнера — это возможность углубить специализацию или освоить новые направления в разработке игр. Они подойдут как начинающим, так и опытным разработчикам, которые хотят расширить свои навыки: от баланса игровой экономики до нарративного дизайна или работы с современными ИИ-инструментами.

• Геймдизайн от Алгоритмики. В процессе игры ребенок самостоятельно разрабатывает сюжет и создает образы персонажей. На каждом уроке дети знакомятся с новыми английскими словами, понятиями из игровой индустрии и основами тайм-менеджмента.
• Гейм-дизайн и разработка компьютерных игр от Центра обучающих технологий. В ходе обучения студенты освоят не только создание игр с помощью Unity, но и приобретут знания в области оптимизации приложений для различных платформ, геймдизайна, монетизации и продажи игр.
• Геймдизайн: как делать игры, которые нравятся и приносят деньги от AppTractor. Вы познакомитесь с множеством примеров реальных компаний и игр. Более того, у вас будет возможность пообщаться с лекторами напрямую после каждой лекции и задать им вопросы по теме, а также получить консультацию или рекомендацию.

Бесплатные курсы по геймдизайну

Для тех, кто хочет освоить сферу без финансовых вложений, существуют бесплатные курсы по геймдизайну. Такие программы позволяют получить базовые знания о создании игр, принципах проектирования механик и работе с игровыми движками. Они подходят для начинающих, которые хотят попробовать себя в профессии, или для опытных разработчиков, желающих расширить свои навыки.

1. Введение в игровую индустрию — Skillbox

Вы узнаете, какие профессии существуют в игровой индустрии. Поймете, какие перспективы у начинающего специалиста, и определитесь с направлением своей деятельности. Вы ознакомитесь с полным процессом разработки игр: от создания идеи до выпуска и продвижения продукта.

Главное о курсе:

• один месяц обучения;
• 17 видео в программе.

2. Антипедагогика: Боги и герои — Stepik

Программа обучения игровому дизайну для тех, кто хочет сделать процесс обучения увлекательным и интересным. Как создавать и проводить игры на уроках и занятиях с детьми.

Главное о курсе:

• 54 урока;
• пять часов четыре минуты видео;
• 104 теста.

3. Технологии и компьютерные игры — Stepik

Программа обучения предназначена для того, чтобы познакомить участников НТО Junior с тематикой, связанной с технологиями и компьютерными играми, а также углубить их теоретические знания, освоить необходимые технологии и развить навыки.

Главное о курсе:

• 24 урока;
• три часа 11 минут видео;
• 53 теста;
• шесть интерактивных задач.

4. Геймдизайн и его приемы — XYZ School

Все о создании игр: от отдельных элементов и методов до идей и концепций известных создателей.

Главное о курсе:

• философия геймдизайна;
• контрольные точки;
• как стимулируют игроков;
• баланс в играх.

Интересная информация о профессии

Геймдизайнер — это специалист, который создает игровые концепции, разрабатывает правила и механику игр, чтобы обеспечить увлекательный игровой процесс. Вот несколько интересных фактов о профессии геймдизайнера:

• Многогранность профессии. Специалист может заниматься не только разработкой игр, но и тестированием игровых механик, анализом данных, созданием нарратива (повествования) в игре, взаимодействием с командой разработчиков для реализации идей.

• Творческий подход. Профессия требует креативности и способности мыслить нестандартно. Работники часто вдохновляются различными источниками, такими как литература, искусство, кино и другие игры.

• Командная работа. Специалисты обычно работают в команде, которая может включать в себя художников, программистов, звукорежиссеров и других специалистов. Важно уметь эффективно взаимодействовать с коллегами и координировать свои усилия.

• Влияние на индустрию. Геймдизайнеры могут оказывать значительное влияние на игровую индустрию, создавая популярные игры, которые становятся культовыми среди игроков. Их работа может определять тренды и направления развития игр.

• Постоянное обучение. Игровая индустрия постоянно развивается, поэтому работникам необходимо постоянно учиться и следить за новыми тенденциями, технологиями и инструментами.

• Разнообразие проектов. Геймдизайнеры могут работать над различными типами игр, включая мобильные, консольные, компьютерные и онлайн-игры. Это позволяет им приобретать разнообразные навыки и опыт.

• Возможность влиять на эмоции игроков. Одна из самых важных задач — создание игрового опыта, который вызывает у игроков эмоции и оставляет впечатление. Это требует глубокого понимания психологии игроков и умения создавать захватывающие истории.

• Баланс и оптимизация. Работники должны уделять внимание балансу игровых механик, чтобы обеспечить справедливую и увлекательную игру для всех игроков. Они также оптимизируют игровой процесс для достижения наилучшего пользовательского опыта.

• Необходимость проработки деталей. Даже мелкие детали в игре могут существенно повлиять на впечатление от нее. Поэтому специалисты часто тратят много времени на проработку мелочей.

• Постоянное взаимодействие с сообществом. Специалисты могут получать обратную связь от игроков через форумы, социальные сети и другие платформы. Это помогает им улучшать игры и учитывать интересы сообщества.

Чем занимается

Основные задачи геймдизайнера:

Разработка механик

• Придумывает, как игрок будет взаимодействовать с миром (движение, бой, диалоги, экономика и т. д.).

• Балансирует сложность, чтобы игра была и интересной, и справедливой.

Создание игрового мира и контента

• Продумывает уровни, квесты, сюжетные повороты (часто вместе с нарративным дизайнером).

• Определяет, какие предметы, враги и способности появятся в игре.

Проектирование игровой экономики

• Рассчитывает, как игрок будет получать ресурсы, тратить их и прогрессировать.

• В мобильных играх — разрабатывает системы монетизации (донаты, боевые пропуска и т. д.).

Работа с документацией

• Составляет GDD (Game Design Document) — «библию» игры, где прописаны все механики и правила.

• Объясняет команде (художникам, программистам), как все должно работать.

Тестирование и итерации

• Играет в ранние версии, ищет баги и «неудобные» моменты.

• Меняет параметры (например, урон оружия или скорость передвижения), чтобы игра стала увлекательнее.

С какими специалистами работает геймдизайнер?

• Художники — чтобы визуал соответствовал геймплею.
• Программисты — чтобы механики правильно работали в коде.
• Продюсеры — чтобы уложиться в сроки и бюджет.
• Тестировщики — чтобы находить и исправлять ошибки.

Примеры решений геймдизайнера:

• В RPG он решает, сколько опыта давать за убийство монстра, чтобы прокачка не была слишком быстрой или медленной.
• В шутере — определяет, как быстро восстанавливается здоровье, чтобы игра оставалась динамичной, но не слишком легкой.
• В мобильной игре — придумывает, как мотивировать игрока заходить каждый день (например, ежедневные награды).

Чем геймдизайнер НЕ занимается?

• Не рисует концепты (это работа концепт-художников).
• Не анимирует персонажей (это делают аниматоры).
• Не программирует (но может писать простые скрипты для прототипов).

Если коротко: геймдизайнер — это архитектор игры. Он отвечает за ее «удобство», баланс и удовольствие от процесса.

Навыки, необходимые для работы

Чтобы успешно работать в геймдизайне, нужен уникальный микс из креатива, аналитики и soft skills. Вот главные умения, которые требуются в индустрии:

Hard Skills (Технические навыки)

Проектирование игровых механик:

• Умение придумывать и описывать правила, системы и взаимодействия (например, боевую систему, экономику, прокачку).

• Понимание баланса (например, как сделать игру сложной, но не несправедливой).

Работа с инструментами:

• Документирование: написание GDD (Game Design Document), таблиц баланса, схем взаимодействий.

• Прототипирование: базовое владение Unity, Unreal Engine, Godot или даже Tabletop Simulator (для настолок).

• Анализ данных: чтение метрик (в мобильных играх — retention, monetization).

Знание игровых жанров и трендов:

• Понимание, чем отличаются геймдизайновские решения в RPG, шутерах, стратегиях и казуальных играх.

• Умение анализировать успешные/провальные игры и выявлять причины их качества.

Основы смежных дисциплин:

• Базовое понимание программирования (логика, простые скрипты на C#, Python или визуальные скрипты).

• Основы психологии игрока (мотивация, теория вознаграждения, поведенческие паттерны).

Soft Skills (Гибкие навыки)

Креативность и логика:

• Способность генерировать идеи, но также отбрасывать лишнее — дизайн это про ограничения.

• Умение видеть систему целиком: как механики влияют друг на друга.

Коммуникация и работа в команде

• Четкое объяснение своих идей художникам, программистам, продюсерам.

• Умение принимать критику и дорабатывать дизайн под требования проекта.

Аналитическое мышление:

• Способность разбирать игры на «составляющие» и понимать, почему они работают (или нет).

• Любовь к тестированию и итерациям — геймдизайн это постоянные правки.

Тайм-менеджмент и адаптивность:

• Работа в условиях жестких сроков (особенно перед релизом).

• Готовность переделывать систему с нуля, если она не работает.

Дополнительные плюсы

• Опыт в моддинге или создании небольших игр (хоть на GameMaker или Roblox).

• Участие в Game Jams (например, Ludum Dare) — ценится в резюме.

• Знание игровых движков (даже на базовом уровне).

• Навыки гейм-аналитики (A/B-тесты, метрики F2P-игр).

Какие бывают специализации в геймдизайне (системный, левел, нарративный и т. д.)?

Геймдизайн — широкая область, и в крупных студиях роли часто разделяют. Основные специализации:

Системный геймдизайнер

Чем занимается: проектирует сложные игровые системы — боевую механику, экономику, прокачку, инвентарь.

Пример: расчет урона, стоимости предметов, скорости прогресса.

Важно: аналитическое мышление, понимание математики и логики.

Левел-дизайнер

Чем занимается: создает уровни, локации, расставляет врагов и объекты.

Пример: проектирование карты в шутере или лабиринта в RPG.

Важно: чувство темпа, понимание «потока» игры (flow).

Нарративный дизайнер

Чем занимается: работает с сюжетом, диалогами, лором, квестами.

Пример: написание ветвящихся диалогов в Mass Effect.

Важно: навыки сторителлинга, иногда — сценарное мастерство.

Экономический дизайнер

Чем занимается: балансирует внутриигровую валюту, цены, донат в F2P-играх.

Пример: система «гемов» в Clash of Clans.

Важно: знание Excel, теория игр.

UX/UI-дизайнер в играх

Чем занимается: проектирует интерфейсы, подсказки, меню.

Пример: удобное колесо быстрого доступа в Skyrim.

Важно: понимание юзабилити, работа в Figma/Adobe XD.

Технический геймдизайнер

Чем занимается: связующее звено между дизайнерами и программистами, пишет скрипты.

Пример: настройка ИИ врагов через Blueprint в Unreal Engine.

Важно: базовые навыки программирования.

Другие ниши:

Контент-дизайнер — создает предметы, способности, персонажей.

Мета-дизайнер — проектирует долгосрочную мотивацию (например, сезоны в Fortnite).

Как выглядит типичный рабочий день геймдизайнера?

Расписание сильно зависит от стадии проекта (препродакшн, активная разработка, полиш перед релизом) и типа студии (AAA, инди, мобильная разработка). Но общий шаблон выглядит так:

Утро (2–3 часа)

Синк-митинг с командой

• Обсуждаются текущие задачи, проблемы, планы на день.

• Вопросы от программистов (Как должна работать эта механика?).

• Правки от продюсера (Нужно ускорить прогрессию).

Проверка новых билдов

• Тестирование вчерашних изменений: не сломала ли новая механика старые системы?

• Заведение багов в трекер (Jira, Trello).

День (4–5 часов)

Проектирование и документация

• Доработка GDD (Game Design Document) — описание новых механик.

• Создание таблиц баланса в Excel (урон, цены, скорость прокачки).

• Прототипирование в Unity/Unreal (если техдизайнер — настройка скриптов).

Совещания

• С художниками — согласование визуала под геймплей.

• С нарративным дизайнером — интеграция квестов в систему.

• С продюсером — отчет по срокам.

Итерации по фидбеку

• Правка механики после тестов: например, уменьшение сложности босса.

• Переписывание диалогов по замечаниям сценаристов.

Вечер (2–3 часа)

Тестирование и фиксы

• Играет в текущую сборку, ищет дизайнерские косяки:

• Подготовка задач на завтра.

Креатив в тишине (если есть силы)

• Придумывание новых идей для игры.

• Анализ конкурентов (Как в Elden Ring сделали прогрессию оружия?).

Нюансы для разных ситуаций

• В начале проекта — больше митингов, мозговых штурмов, создание прототипов.

• Перед релизом — аврал, правки по 100 раз, стресс (Кранч).

• В инди-командах — геймдизайнер часто сам лезет в движок, рисует схемы на салфетках.

• В мобильных играх — копание в аналитике (почему игроки уходят на 3-м уровне?).

Какие самые распространенные мифы о профессии?

«Геймдизайнер только играет в игры»

На деле: 10% игры, 90% — документы, таблицы, встречи и правки.

«Нужно уметь рисовать/программировать»

Реальность: это плюс, но не обязательно. Главное — понимать принципы дизайна.

«Геймдизайнер — главный по идеям»

Правда: идеи — 1% работы. 99% — их реализация, тестирование и доработка.

«Достаточно любить игры»

Факт: нужно анализировать их, понимать, почему они работают (или нет).

«В индустрии берут только с опытом»

На самом деле: начать можно с моддинга, Game Jams или QA.

Какие инструменты и движки используют геймдизайнеры?

Движки

• Unity — для мобильных и инди-игр (C#-скриптинг).

• Unreal Engine — для AAA (визуальные скрипты Blueprint).

• Godot — легкий аналог Unity для 2D.

Документирование

• Google Docs/Notion — для GDD.

• Excel/Google Sheets — для баланса (формулы, графики).

• Miro/Figma — схемы механик, интерфейсов.

Тестирование

• Jira/Trello — трекинг задач.

• DevTools движков — дебаг механик.

Аналитика (в F2P):

Firebase/GameAnalytics — метрики игроков.

Как нейросети и AI изменят геймдизайн?

Геймдизайн уже начал трансформироваться под влиянием ИИ, и в ближайшие 5–10 лет изменения станут еще более радикальными. Вот ключевые направления:

Автоматизация рутины

Генерация контента

• Уровни и локации: ИИ (как Procedural Generation 2.0) сможет создавать уникальные, но сбалансированные уровни по запросу (сгенерируй подземелье в стиле Dark Souls).

• Персонажи и диалоги: нейросети (например, ChatGPT) будут писать ветвящиеся диалоги, адаптируя их под стиль игры.

• Текстуры и 3D-модели: инструменты вроде MidJourney/Stable Diffusion ускорят создание концептов.

Баланс и тестирование

• AI-тестеры будут находить базы и дисбаланс быстрее людей.

• Динамическая балансировка: ИИ подстроит сложность под навыки игрока в реальном времени.

Новые возможности для дизайнеров

Прототипирование за минуты

• Генерация готовых механик по описанию (сделай систему крафта как в Skyrim, но с элементами алхимии).

• ИИ-помощники (типа Copilot для геймдизайна) будут предлагать решения:

• Как сделать босса сложным, но не нечестным?
• Какая экономика подойдет для мобильной RPG?

Персонализированный геймплей

• Адаптивные сюжеты, где ИИ меняет историю под действия игрока.

• Уникальные враги, созданные на основе стиля игры пользователя.

Будущее профессии

• Геймдизайнер 2.0 — это куратор ИИ, а не рабочая лошадка.

• Появятся новые специализации:

• AI-дизайнер — настройка нейросетей под нужды игры.
• Промт-инженер — мастер формулировок для генеративного ИИ.

• Инди-разработка выиграет: маленькие команды смогут делать контент уровня AAA.

Где и как учиться

Профессия геймдизайнера требует практики, аналитического мышления и понимания игровой индустрии. Формальное образование — не обязательное условие, но оно может ускорить вход в профессию. Вот основные пути обучения:

Высшее и специальное образование

Университеты и колледжи

Игровые вузы и факультеты

Некоторые учебные заведения предлагают программы по геймдизайну, разработке игр или интерактивному дизайну. Обучение обычно включает:

• Основы геймдизайна (механики, баланс, нарратив).

• Работу с игровыми движками (Unity, Unreal Engine).

• Программирование для дизайнеров (логика, скриптинг).

• Командные проекты (создание игр в группах).

Смежные специальности

Если нет узкопрофильных программ, подойдут:

• Компьютерные науки / Программирование (полезно для технического дизайна).

• Психология / Маркетинг (понимание поведения игроков).

• Литература / Сценарное мастерство (для нарративного дизайна).

Онлайн-университеты и курсы

Многие платформы предлагают структурированные программы от основ до продвинутых тем:

• Курсы по геймдизайну (механики, баланс, документация).

• Специализации по игровым движкам (Unity, Unreal, Godot).

• Интенсивные программы с менторской поддержкой.

Самообразование

Книги и теория

Базовые знания можно получить из книг, например:

• Основы геймдизайна (механики, циклы вовлеченности).

• Психология игроков (мотивация, reward-системы).

• Анализ игр (разбор успешных и провальных проектов).

Практика и создание игр

• Game Jams (соревнования по созданию игр за 48–72 часа).

• Моддинг (изменение существующих игр, например, карты для Warcraft 3, моды для Skyrim).

• Инди-разработка (небольшие проекты на Unity, Ren'Py, RPG Maker).

Игровые движки и инструменты

• Unity, Unreal Engine, Godot — для прототипирования.

• Figma, Miro — для схем и документирования механик.

• Trello, Notion — для организации работы.

Сообщество и нетворкинг

• Форумы и Discord-серверы (обсуждение дизайна, поиск команды).

• Конференции и митапы (GDC, DevGAMM, локальные ивенты).

• Портфолио и блоги (публикация разборов игр, своих проектов).

Опыт работы и старт карьеры

Стажировки и Junior-позиции

• Тестирование игр (QA) → понимание багов и игровых систем.

• Ассистент геймдизайнера → помощь в балансе и документации.

• Левел-дизайн / Нарративный дизайн → узкие роли с ростом в геймдизайн.

Инди-студии и пет-проекты

Многие начинают с некоммерческих проектов, чтобы набрать опыт.

Как выбрать путь?

• Если хотите структуру → курсы, университеты.

• Если готовы к самообучению → книги + практика (Game Jams, моддинг).

• Если нужен быстрый вход в индустрию → стажировки в QA или инди-команды.

Заработная плата

Размер оплаты труда специалиста по разработке игр определяется его опытом и местом работы. В столице, например, недавно пришедшие в профессию могут рассчитывать на доход до 70 000 рублей в месяц, работники со средним уровнем квалификации — от 70 000 рублей, а профессионалы — от 205 000 рублей. Чтобы получить актуальную информацию о зарплатах и вакансиях, стоит обратиться к специализированным ресурсам по поиску работы, таким как hh.ru. На этих сайтах вы сможете найти предложения от прямых работодателей, которые указывают требования и условия оплаты труда.

Заключение

Игровая индустрия меняется быстро, и успех в ней требует гибкости и готовности учиться. Но если вы действительно увлечены играми и готовы вкладывать силы в их создание, курсы по геймдизайну станут отличным трамплином для карьеры. Главное — не останавливаться на теории и сразу применять знания на практике. Ведь лучший способ научиться делать игры — это просто начать их делать.

Подборки по схожим темам:

1. Лучшие курсы по разработке игр
2. Лучшие курсы по Веб-дизайну

В случае выявления ошибок, неточностей или устаревшей информации, пожалуйста, сообщите об этом в комментариях. Также вы можете указать, если хотите, чтобы я добавила проверенное вами обучение в подборку.

22 апреля тебя ждут крутые спикеры, секретный гость и два мощных трека.

Hard

Наш хардовый трек — для тех, кто в проде с закрытыми глазами. API First, компонентные и контрактные тесты, мониторинг и SRE. Обсудим реальные кейсы нашего банка и как мы создаём системы, которые работают стабильно и эффективно.

Как внедрить API First в сложную финтех-инфраструктуру с учетом legacy-систем? Разберем, почему стандарт AsyncAPI не всегда подходит для крупных систем, как мы адаптировали его под наши реалии и разработали собственные инструменты.

Покажем сравнительный анализ решений, демонстрацию работы нашего генератора и подход к безболезненному переходу на API First. Подробности в докладе старшего технического руководителя Максима Морозова.

Head of profession QA Кристина Клигер поделится, как через развитие команды тестирования можно быстро доставлять фичи до клиентов и радовать бизнес.

Глава центра развития ИТ-мониторинга Валентин Лебедев раскроет секреты превращения мониторинга в сервис. Живет ли OpenSource в крупных предприятиях?

Soft

В ламповой уютной атмосфере на пуфике с бутером в руке обсудим, что такое настоящий софт. Как растить инженеров, внедрять изменения и работать с сопротивлением команд и представителей бизнеса.

СТО Виктор Цветков и Head of profession SA Юлия Григорьева расскажут, какие способы внедрения изменений существуют по степени мягкости. Почему важно учитывать корпоративную культуру при работе с изменениями. Далее поговорим про неотъемлемую часть — обучение команды и работе с их сопротивлением новым практикам. Поделимся нашими лайфхаками и секретами.

Head of Profession Вадим Ваганов объяснит, зачем коммитить в main несколько раз на дню. Спойлер: чем чаще релизишься, тем меньше ошибок.

Техлид Роман Олеск поделится лайфхаками для успешного роста ваших инженеров. Расскажем о матрице инженерных ролей и компетенций, а также о персональных треках развития сотрудников.

Экспозона

50 экспертов Газпромбанк.Тех ждут тебя, чтобы погрузить в специфику нашей работы.

16 стендов объединят вместе ИТ-направления в нашем банке:

Data Science, RPA, Искусственный интеллект, Инновации, Database, Backend, QA, DevOps, Frontend, Мобильная разработка iOS и Android, Product Design, Кибербезопасность, Business Analysis, System Analysis, IT Recruitment и Agile.

Не упусти возможность лично пообщаться с экспертами. Узнай из первых уст, как банк запускает инновационные стартапы, почему с помощью Data Science можно решать творческие задачи и что нужно для запуска собственного робота. Мы расскажем, какие современные технологии и подходы используют команды.

Нетворкинг

После официальной части мероприятия приглашаем остаться и продолжить общение в неформальной обстановке. С нас космические угощения и напитки!

Как закоммититься

Вход по мультипаспорту:)

Торопись, количество мест ограничено!

До встречи на GPB CONF!

А тут можно узнать больше о наших проектах.

Принципы удобства использования (Usability) в мобильных приложениях

Удобство использования или юзабилити — ключевой элемент успешного проектирования мобильных приложений. Этот принцип нацелен на понятное, простое и приятное взаимодействие пользователей с интерфейсом приложения.

Что такое удобство использования и почему это важно?

Удобство использования — это показатель того, насколько легко и эффективно пользователь может выполнять задачи в приложении. Оно играет решающую роль в удержании аудитории: даже функциональное приложение может быть отвергнуто, если его интерфейс неудобен. Как понять, что все правильно?

• Требуется больше времени на взаимодействие с приложением;
• Снижается количество ошибок пользователей;
• Повышается лояльность благодаря положительному опыту.

Интуитивно понятная навигация и структура приложения

Интуитивность — когда пользователю не нужно учиться работать с приложением. Ключевые элементы:

• Простая структура. Главное меню должно быть минималистичным, с четким выделением основных функций;
• Ожидаемое поведение интерфейса. Элементы вроде кнопок или ссылок должны выглядеть так, как предполагает пользователь;
• Видимость пути. Всегда важно показывать, где находится пользователь и как он может вернуться к началу.

Пример хорошей навигации — использование нижней панели с доступом к ключевым разделам приложения. Плохая навигация — вложенные меню, где нужно нажать на кучу кнопок, чтобы, например, вернуться к началу.

Упрощение взаимодействия с учётом ограниченного экрана

Маленькие экраны мобильных устройств требуют продуманного подхода. Что учитываем:

• Минимум информации на одном экране. Разделение задач на этапы делает взаимодействие удобным;
• Используем жесты (например, свайпы) для экономии пространства.
• Делаем контрастный и четкий дизайн, адаптированный для восприятия на малых экранах.

Примеры хорошей и плохой навигации в мобильных интерфейсах

Примеры хорошей навигации:

• Приложения для путешествий (например, карты), в которых все ключевые функции видны сразу.
• Маркетплейсы, где есть кнопки быстрого доступа к категориям.

Примеры плохой навигации:

• Приложения, где ключевые элементы «спрятаны» в дополнительных меню (например, цена на продукт или вкладка для скачивания)
• Непонятные иконки без подписей, из-за которых пользователь теряется (так было, например, в ранних версиях Snapchat).

Принципы юзабилити при проектировании мобильных приложений — это не только создание привлекательного дизайна, но и забота о функциональности и комфорте взаимодействия. Продуманная структура, простота и адаптация к ограничениям экранов формируют положительный пользовательский опыт, который выделит приложение на фоне других.

Адаптивность и отзывчивость интерфейса

Адаптивность и отзывчивость интерфейса — неотъемлемые принципы проектирования мобильных приложений. Рассмотрим основные элементы.

Поддержка различных размеров экранов и ориентаций устройств

Мобильные устройства отличаются разнообразием экранов: от компактных смартфонов до больших планшетов. Чтобы обеспечить универсальность пользовательского интерфейса, важно учитывать:

• Автоматическую адаптацию к ориентации устройства. Горизонтальная и вертикальная ориентации должны одинаково обеспечивать удобный доступ к функциям;
• Динамическое масштабирование. Интерфейс приложения должен корректно отображаться как на компактных, так и на больших экранах.

Использование адаптивных элементов интерфейса и сетки

Адаптивные элементы и сетки делают интерфейс мобильных приложений гибким и удобным. Основные рекомендации:

• Сетки. Использование 12-колоночной системы сеток помогает выровнять элементы и адаптировать их к разным разрешениям экрана;
• Элементы с пропорциональными размерами. Кнопки, текстовые поля и изображения должны плавно масштабироваться.

Использование гибкой сетки улучшает юзабилити, так как интерфейс выглядит логично и привлекательно.

Советы по созданию отзывчивого дизайна с помощью автолейаутов и flexbox

Такие инструменты, как автолейаут и flexbox, упрощают процесс создания адаптивного дизайна.

• Flexbox. С его помощью элементы автоматически перестраиваются, занимая оптимальное место на экране;
• Автолейауты. Ускоряют размещение элементов интерфейса, особенно в условиях ограниченного пространства.

Эти подходы помогают сделать приложения удобными для всех типов устройств, улучшая их визуальное восприятие и функциональность.

Как обеспечить хорошую читаемость текста и удобное размещение элементов

Для читаемости и удобства взаимодействия важны:

• Размеры шрифта. Минимальный размер текста — 14 пикселей;
• Контрастность. Текст и фон должны быть легко различимыми;
• Расстояние между элементами. Клавиши и другие интерактивные зоны не должны располагаться слишком близко друг к другу (на языке мемов — «коллеги, нужно хочется побольше воздуха»).

Принципы визуальной иерархии

Эффективный пользовательский интерфейс должен не только выглядеть привлекательно, но и помогать юзеру быстро находить нужную информацию. Принципы визуальной иерархии играют ключевую роль в проектировании мобильных интерфейсов, направляя внимание пользователя в нужное русло и упрощая взаимодействие.

Использование размеров, цветов и контрастов для выделения важной информации

Размеры, цвета и контрастность позволяют расставить акценты в интерфейсе мобильных приложений:

• Размеры. Более крупные элементы привлекают внимание;
• Цвета. Использование ярких оттенков для ключевых элементов (например, кнопок действий) помогает пользователю легко их идентифицировать;
• Контраст. Четкий контраст между текстом и фоном улучшает читаемость и повышает удобство использования.

Создание иерархии элементов для привлечения внимания пользователя

Размещение элементов на экране должно учитывать логику взгляда пользователя. Основные принципы:

• F-образный паттерн. Пользователи читают экраны по горизонтали сверху вниз, что следует учитывать при размещении информации;
• Визуальные маркеры. Иконки, стрелки и выделения направляют внимание на важные действия.

Эффективная иерархия помогает избежать перегрузки информацией, делая интерфейс более удобным.

Баланс между текстом и визуальными элементами

Сбалансированное использование текста и графики делает мобильные приложения понятными и эстетичными:

• Минимализм. Четкие заголовки и лаконичные описания помогают удерживать внимание;
• Графика. Иллюстрации или иконки должны дополнять, а не заменять текстовую информацию;
• Соотношение. Не менее 40% пространства должно быть отведено под «воздух», чтобы элементы не выглядели сжатыми.

Примеры эффективного использования визуальной иерархии в мобильных приложениях

Хороший пример: в приложении для заказа еды крупные фотографии блюд сопровождаются яркими кнопками «Добавить в корзину». Контраст помогает пользователю быстро сориентироваться.

Плохой пример: сложные таблицы без визуального разделения информации. Это снижает читабельность и затрудняет восприятие.

Визуальная иерархия — один из основных принципов проектирования мобильных интерфейсов. Грамотное использование размеров, цветов и баланса между текстом и визуальными элементами улучшает опыт взаимодействия пользователя с приложением.

Обратная связь и взаимодействие

Важный аспект проектирования мобильных интерфейсов — организация качественной обратной связи между пользователем и приложением. Это усиливает восприятие, улучшает опыт взаимодействия и повышает уровень юзабилити. Рассмотрим основные принципы.

Предоставление визуальной и тактильной обратной связи при взаимодействии

Пользователи ожидают мгновенной реакции приложения на любое действие, будь то нажатие кнопки или свайп. Важные элементы:

• Визуальная обратная связь. Изменение цвета кнопок, всплывающие уведомления или выделение активных элементов сигнализируют об успешном действии;
• Тактильная обратная связь. Легкие вибрации при взаимодействии создают эффект физического присутствия и делают процесс интуитивно понятным. Самый банальный пример — 3D Touch на устройствах Apple, когда, например, ссылка в Safari открывается с вибрацией в новом окне, то же самое с фотографиями в пленке.

Использование анимаций и переходов для улучшения пользовательского опыта

Анимации могут не только украшать интерфейс мобильных приложений, но и облегчать его восприятие:

• Плавные переходы. Анимации помогают визуально объяснить, что происходит: например, как открывается меню или перемещается элемент;
• Интерактивные элементы. Кнопки с эффектом нажатия или иконки, которые анимируются при взаимодействии, делают приложение более живым.

Важно соблюдать баланс: чрезмерное количество анимаций перегружает интерфейс и снижает производительность.

Как сделать интерфейс отзывчивым и живым, не перегружая его анимацией

Основной принцип — минимализм:

• Используйте анимацию для подсказок и подтверждений. Так, плавное появление сообщения об ошибке делает интерфейс более дружелюбным;
• Адаптируйте анимации для разных устройств, чтобы сохранять производительность.

Совет: избегайте сложных 3D-эффектов и длительных анимаций, которые могут отвлекать от основного действия.

Примеры хорошей обратной связи в популярных приложениях

Положительный пример: в приложении для заметок Google Keep кнопка «Добавить» анимируется, сигнализируя о том, что запись сохранена. Это интуитивно понятно и просто.

Отрицательный пример: в приложениях с перегруженными анимациями и задержкой реакции (например, медленно открывающиеся меню) пользователь теряет концентрацию.

Обратная связь — одна из основных характеристик качественного пользовательского интерфейса. Сбалансированное использование визуальных эффектов, тактильной реакции и анимаций делает мобильные приложения более удобными и отзывчивыми, улучшая общее восприятие и опыт пользователя.

Минимализм и фокус на контенте

Минимализм — ключевой принцип при проектировании мобильных интерфейсов, который способствует улучшению юзабилити и снижению когнитивной нагрузки на пользователя. Рассмотрим основные аспекты минималистичного подхода.

Принцип «чем меньше, тем лучше»: избегайте избыточного функционала и информации

В мире мобильных приложений избыточность отвлекает пользователя от главной цели. Оптимизация предполагает:

• Отказ от избыточных функций. Приложение должно предлагать только те функции, которые необходимы для выполнения основных задач;
• Упрощение визуального контента. Минимум текста и графики помогает пользователю быстрее ориентироваться.

Пример: приложение для концентрации внимания Forest, в котором основное внимание уделяется одной функции — вырастить дерево, не прикасаясь к телефону на протяжении определенного количества минут. Простая навигация и отсутствие лишних элементов позволяют сосредоточиться на главной цели.

Минимизация элементов интерфейса для сохранения фокуса на контенте

Интерфейс мобильных приложений должен подчеркивать контент, а не доминировать над ним. Это достигается за счет:

• Простой структуры экранов с акцентом на содержимое;
• Использования цветовых акцентов для выделения ключевых действий;
• Минимизации отвлекающих элементов: сложных иконок, избыточных меню, всплывающих окон.

Совет: оставьте только те элементы, которые действительно необходимы для взаимодействия. Например, в Instagram* вся структура построена вокруг контента: фотографии и видео остаются в центре внимания, а, например, мессенджер выведен в отдельную вкладку и не отображается в главном меню снизу.

*Корпорация Meta признана экстремистской в РФ

Уменьшение когнитивной нагрузки на пользователя

Пользовательский опыт становится приятнее, если приложение избавляет от необходимости запоминать сложные маршруты или действия. Для этого:

• Убирайте ненужные этапы взаимодействия;
• Делайте навигацию интуитивно понятной;
• Используйте лаконичные инструкции и понятные иконки.

Примеры минималистичного подхода в мобильных приложениях

Хороший пример: Тот же Google Keep, где интерфейс полностью сосредоточен на создании и хранении заметок. Никаких лишних настроек или сложных функций.

Плохой пример: приложения с избыточной анимацией или всплывающими окнами, которые отвлекают от контента.

Минималистичный подход к проектированию мобильных интерфейсов помогает пользователю сосредоточиться на выполнении основных задач и улучшает общее восприятие. Принципы минимализма — это отказ от лишнего, простота и удобство, что делает приложения более понятными и функциональными.

Доступность (Accessibility)

Доступность интерфейсов в мобильных приложениях — это не только забота о пользователях, но и важный фактор, повышающий юзабилити. Разработка доступных приложений расширяет аудиторию и делает взаимодействие удобным для всех, включая людей с ограниченными возможностями.

Обеспечение доступности интерфейса для пользователей с ограниченными возможностями

Чтобы интерфейс мобильных приложений был доступным, необходимо учитывать потребности людей с различными нарушениями, в том числе:

• Зрение (частичная или полная потеря, дальтонизм);
• Слух;
• Опорно-двигательный аппарат (ограниченные возможности взаимодействия с экраном);
• Когнитивные особенности (дислексия, проблемы с вниманием).

Использование контрастных цветов, доступных шрифтов и альтернативных текстов

Контрастные цветовые схемы и крупные, легко читаемые шрифты облегчают взаимодействие. Основные советы:

• Используйте шрифты без засечек (sans-serif), по типу Arial или Roboto;
• Выбирайте контрастные сочетания текста и фона, которые соответствуют стандартам WCAG (например, чёрный текст на белом фоне);
• Добавляйте альтернативные тексты к изображениям для работы с экранными дикторами. Это особенно важно для визуальных приложений.

Пример: в Uber значки и шрифты адаптированы для режима высокой контрастности, что делает их удобными для пользователей с нарушениями зрения.

Важность поддержки экранных дикторов и жестов

Современные интерфейсы мобильных приложений должны быть оптимизированы для работы с технологиями вспомогательного ввода, такими как:

• Экранные дикторы (например, VoiceOver на iOS или TalkBack на Android);
• Управление жестами, позволяющее заменить физические кнопки.

Для этого важно структурировать интерфейс так, чтобы дикторы правильно озвучивали элементы: кнопки, заголовки, поля ввода.

Как улучшить доступность с минимальными усилиями

Достичь высокой доступности можно даже с небольшими изменениями:

1. Используйте встроенные библиотеки платформ для включения функций доступности;
2. Проверяйте интерфейс с помощью симуляторов (например, Google Accessibility Scanner);
3. Стремитесь к простоте и интуитивности, чтобы сократить время на адаптацию.

Основной принцип доступности — обеспечение равных возможностей для всех пользователей. Удобный и доступный пользовательский интерфейс не только улучшает опыт, но и делает мобильные интерфейсы соответствующими современным стандартам.

С его помощью разрабатывают приложения для мобильных устройств и продукты для десктопных платформ. Кроме того, этим языком пользуются геймдев-разработчики, создающие игры для Apple, а также бэкенд-разработчики, использующие библиотеки Swift.

В июне 2024 года вышла новая версия языка — узнаем, какие функции появились в этом релизе, в чем преимущества Swift 6, каковы отличия этого продукта от С++.

Обзор Swift: путь к версии 6

Согласно официальным данным, Swift создан разработчиками компании Apple в 2014 году. Однако алгоритмы, которые лежат в основе этого языка, использовались еще в 90-х годах прошлого века при создании платформы NeXT — основы для будущих систем iOS и macOS.

Сотрудники Apple занимались разработкой языка несколько лет, при этом у Свифт нет конкретного прародителя, поскольку при создании использовались наработки сразу нескольких продуктов — Objective-C, Haskell, Python, C++ и других.

В 2014 году на официальной презентации был представлен пакет документов по языку Swift на 500 страницах. Уже в следующем году вышла обновленная, более производительная версия Swift 2.0.

В 2015 вышла модификация 3.0, которая отменила прошлые версии. Следующее масштабное обновление вышло в 2017 году — версия Swift 4.0 несколько раз модифицировалась. В 2019 вышла пятая версия, в которой содержалось множество нововведений. 11 июня 2024 — дата релиза Swift 6, последней на текущий момент версии языка.

Особенности и преимущества Swift 6

Поскольку Swift был создан относительно недавно, в нем учтены многие недостатки, свойственные более ранним языкам программирования. Разработчики изначально делали ставку на простоту изучения и применения, а также использование языка для быстрого старта и последующего развития проектов.

В отличие от Objective-C — языка, который корпорация Эппл использовала ранее, синтаксис у Swift более понятный и лаконичный. Программистам требуется меньше времени на написание кода.

Еще одна ключевая особенность Свифта — его повышенная производительность. Несмотря на простоту и быстрое освоение, эффективность языка довольно высока. Эксперты утверждают, что Swift втрое быстрее Objective-C и в 8 раз опережает по скорости Python. В новой версии разработчики попытались превзойти по этому параметру C++.

Другие преимущества:

• Наличие современных библиотек и фреймворков, которые существенно упрощают написание кода для программистов. В распоряжении разработчиков — множество готовых функциональных блоков.
• У Swift открытый исходный код, что делает язык доступным для всех пользователей. Это может показаться странным для Apple, но в данном случае такой ход корпорации полностью оправдан. Профессиональное коммьюнити занимается исправлением багов и предлагает полезные нововведения.
• К сильным сторонам языка относится его безопасность. По этому показателю Свифт превосходит Objective-C. Благодаря улучшениям при работе с памятью разработчики минимизировали риск стороннего доступа к данным.
• Более эффективная работа со сценариями снижает вероятность критических ошибок при разработке программ.
• Возможность визуализации результата программирования. С помощью специальной песочницы можно наглядно оценить результаты работы конкретной программы. Такой метод позволяет быстро обнаружить ошибки в коде и тем самым сократить время на разработку.
• Динамические библиотеки. Благодаря такому формату пользователи быстрее вносят изменения и обновления в готовые коды, не дожидаясь релиза новых версий iOS.

Swift нельзя назвать универсальным языком, поскольку он создан в качестве специализированного инструмента для работы с платформами iOS и macOS. Однако у разработчиков, знакомых с этим языком, широкая сфера деятельности — они могут создать любое приложение или игру для устройств на iOS, занимаются серверными и системными программами. Одно время планировалось, что Свифт будет адаптирован для Android, но вряд ли этот проект будет реализован.

Возможности для разработки программ на Свифт практически не ограничены. В этом легко убедиться, открыв магазин AppStore. Это могут быть простейшие виджеты и игры, а также сложнейшие программы профессионального уровня.

В числе недостатков языка эксперты указывают сложности при работе с приложениями, написанными на Objective-C. Для этого используют своего рода мост, который часто затрудняет процесс сборки софта. Этот минус отчасти нивелирован в новой версии.

Что касается перспектив Swift, то они вполне определены. Разработчики, владеющие этим языком, постоянно востребованы. Количество пользователей, приложений и возможностей систем macOS и iOS постоянно растет, а значит, растут и запросы на разработку нового софта.

Apple вряд ли откажется от Свифта в ближайшие 10 лет — в этот инструмент вложены слишком большие ресурсы. Язык продолжит развиваться, а с учетом открытого кода этот процесс будет происходить все более интенсивно.

С другой стороны, поскольку Swift — это не кроссплатформенный язык, его применение ограничено устройствами Apple. А значит, все разработки могут быть связаны только с продуктами этой корпорации.

Что нового в Swift 6

Свифт 6 — это крупнейшее обновление языка за последние пять лет. Сразу после выхода обновления эксперты обратили внимание на повышение производительности и улучшенную кодируемость. В новой версии повышена безопасность данных и появилось подмножество Embedded Swift, предназначенное для работы в системах с существенными ограничениями. Появились и другие обновления, которые мы рассмотрим более подробно.

Обратите внимание, что рассматриваемые нами изменения актуальны на момент официального релиза Swift 6, то есть в будущем наверняка появятся дополнительные обновления.

Полный параллелизм

В Свифт 6 параллелизму (то есть выполнению одновременно сразу нескольких задач) уделено много внимания. Наиболее значительное изменение — полная проверка параллельности, активированная по умолчанию. Это нововведение может потребовать ряда корректировок в коде, поскольку в более ранних версиях функция проверки была опциональной.

В Свифт 6 проверка параллелизма улучшена — устранены ложные сообщения о гонках данных, распространенные в версии 5.10. Многие целевые изменения сделали параллелизм более простым для освоения.

Примером значимого нововведения можно назвать SE-0414 — эта опция позволяет компилятору привести доказательства, что разные части кода могут выполняться одновременно. Изменение основано на концепции sendability (отправляемости) — то есть базируется типах данных, которые возможно в безопасном режиме отправлять в параллельной среде.

Некопируемые типы данных

В Свифт все типы значений, как и ссылочные типы, копируемые. В новой версии есть некопируемые типы, полезные в ряде сценариев, где они применяются в качестве уникальных ресурсов. Такая опция предотвращает утечку ресурсов и повышает удобство кодирования.

Интеграция с С++

В новой версии Swift может напрямую взаимодействовать с языком С++, обеспечивая тем самым бесшовную интеграцию опыта разработчиков. Тратить время и ресурсы на переход не придется. Теперь виртуальные методы C++, аргументы и другие элементы стандартных библиотек могут быть напрямую перенесены в Свифт. Взаимодействие платформ предполагает взаимную адаптацию аналогичных языковых концепций и при необходимости — коррекцию семантики.

Эксперты считают, что использование языка Swift в проектах на С++ повышает безопасность, поскольку уязвимость данных в новой версии продукта Эппл. минимизирования.

Поиск ошибок

В новой версии реализована одна из лучших в профессиональной среде опций по обработке ошибок. С ее помощью баги автоматически отлавливаются и устраняются на начальном этапе работы с программой.

Замена функций

Некоторые изменения присутствовали еще в ранних версиях Свифт, но были скрыты. В новой модификации такие функции стали полноценными. В основном это специализированные возможности, касающиеся переменных и других данных в параллельных средах.

Итерация пакета

В новой версии есть итерация по пакетам, что делает возможным обход параметров, введенных в предыдущей модификации. Такая возможность позволяет сравнивать кортежи (упорядоченные наборы данных) в нескольких строках кода.

Анализ нововведений: как Swift 6 меняет разработку

Экспертное сообщество расценивает нововведения Swift 6 как однозначно положительные. Максимум внимания создатели новой версии уделили доменам параллелизма, что делает модификацию более доступной для рядовых разработчиков.

Такие опции, как автоматическая проверка параллелизма, улучшение концепции sendability и другие делают написание кода более быстрым и эффективным. Значительная часть нововведений направлена на повышение производительности разработки при создании сложных приложений.

Еще один пункт, на который стоит обратить внимание — это безопасность гонок данных. В процессе разработки параллельных программ возникает множество ошибок. Такое происходит, когда сразу несколько потоков совместно пользуются данными, при этом один из них начинает эти данные менять. Гонки чреваты сбоями в программе и проблемами, которые непросто устранить.

В Swift 6 задействованы механизмы изоляции данных, опции для защиты изменений кода и безопасного обмена информацией. Безопасность data-race здесь достигается по умолчанию.

Обновления делают Свифт 6 мощным, безопасным и эффективным инструментом, который подходит для разработки широкого ассортимента приложений — это может быть прикладной мобильный софт, настольные приложения, серверные и системные программы.

Сравнение Swift 6 и C++

На презентации Swift 6 представители Apple заявили, что в новой версии язык стал еще более скоростным и безопасным, а по эффективности, возможно, превзошел С++. В свое время Свифт создавался именно в качестве потенциальной замены языка С++, у которого есть есть определенные уязвимости.

Рассмотрим основные параметры Swift 6 и сравним их с показателями С++:

• Скорость. С английского слово Swift переводится как «стремительный». Разработчики изначально намеревались сделать высокоскоростной язык. По скорости он однозначно превосходит последнюю версию Python, а по некоторым алгоритмам опережает и С++.
• Производительность. Скорость исполнения кода неизбежно повышает производительность приложений, которые работают на Свифт. При этом софт, в отличие от аналогичных программ, написанных на С++ и других языках, не перегружает до критических значений вычислительные мощности устройств.
• Код. Свифт изначально создавался как язык с максимально простым, неперегруженным синтаксисом. Это делает работу с инструментом понятной и доступной. В новой версии громоздких конструкций и лишних элементов стало еще меньше. Swift все больше становится похожим на естественный язык, оставаясь ясным и чистым даже при создании сложного года. Неочевидных ошибок здесь встречается на порядок меньше, чем в С++.
• Память. Инновационная система автоматического управления памятью ARC следит за расходованием и очисткой нужного количества ресурсов. Программисту можно не отслеживать этот параметр.
• Безопасность. Еще один аспект, в котором эксперты отдают предпочтение Swift 6. В новой версии несанкционированный доступ к важным данным минимизирован. При этом язык точнее отслеживает баги разработчика, снижая риск малозаметных, но критичных ошибок. При этом Свифт более предсказуем, что важно для процессов тестирования и отладки.

Благодаря открытому исходному коду языком Swift могут пользоваться практически все желающие — от профессиональных разработчиков до самоучек. Это решение компания Apple, известная закрытыми разработками, приняла сознательно — с целью сделать язык более мощным, простым и эффективным. Комьюнити действительно способствует совершенствованию языка, при этом Свифт можно переносить на сторонние системы, создавать новые библиотеки, расширяющие возможности инструмента программирования.

Apple уделяет время и ресурсы на продвижение и развитие языка. Компания следит не только за обновлением версий, но и постоянно предоставляет пользователям актуальные обучающие материалы. В macOS есть встроенная среда разработки, которая поддерживает Свифт, что называется «из коробки». В Apple Swift Playgrounds можно создавать пробные версии приложений и тут же тестировать их. Официальный подробный учебник по языку доступен в открытом хранилище Apple Books.

Есть ли позиции, по которым C++ опережает Swift? Да, такие моменты присутствуют, поскольку ничего совершенного в природе, даже если это цифровая среда, не существует.

Один из главных недостатков Swift 6, как и предыдущих версий, это узкая специализация. Свифт применяется только для разработки программ на устройства Apple, никакого другого назначения у него нет. Приложения в теории могут работать на Windows и Linux, но это будет неудобное решение.

Еще один минус — относительно небольшое по численности русскоязычное сообщество. Сравнивать уровни поддержки специализированного языка и универсального несколько некорректно, но именно сообщество способствует развитию и распространению языка.

Относительным недостатком можно считать неразрывную связь Swift 6 и старых версий с Objective-C. Свифт без проблем встраивается в продукты, написанные на Objective-C, что обеспечивает разработке гибкость. Однако новичкам, желающим освоить программирование для Apple, придется освоить оба языка, иначе работать с приложениями будет сложно.

Итоги

Очевидно, что при разработке продуктов для Apple язык Swift 6 будет предпочтительным выбором. Однако по причине узкой специализации Свифт не получится использовать для написания программ на других ОС. В этом отношении C++ более функционален и практичен, поскольку относится к универсальным языкам программирования.

Впервые упоминание о Cangjie появилось в октябре 2021 года. Huawei собиралась выпустить этот язык программирования в 2022 году, но по каким-то причинам запуск отложился на целых два года.

Основная аудитория Cangjie — разработчики, работающие с экосистемой Huawei, включая мобильные устройства, облачные сервисы и IoT (Интернет вещей). Если вы уже знакомы с языками вроде Java или C++, освоить Cangjie будет проще, потому что у них есть некоторые общие черты. Huawei нацелена на то, чтобы привлечь разработчиков из разных сфер, предлагая им мощный и гибкий язык для создания приложений.

Стратегические цели Huawei: только ли ответ на санкции?

Компания разработала Cangjie с несколькими стратегическими целями. В первую очередь это ответ на санкции: появилась необходимость постепенно объединять Harmony OS и OpenEuler. Harmony OS — мобильная ОС, представленная в августе 2019 года как альтернатива iOS и Android. OpenEuler — продукт для облачных сервисов. Это дистрибутив Linux, запущенный в январе 2020 года, основанный на EulerOS, который является форком CentOS. Так компания будет меньше зависеть от других уже существующих технологий.

Кроме того, Huawei видит в этом проекте долгосрочную инвестицию в будущее. Упрощенный синтаксис и возможности доменно-ориентированной разработки позволят новичкам быстрее осваивать программирование. Huawei заинтересована в создании активного сообщества, которое будет поддерживать и развивать язык, что в перспективе принесет компании выгоду за счет увеличения базы разработчиков.

А еще введение нового языка укрепляет имидж Huawei как инноватора в области технологий. В условиях жесткой конкуренции с другими технологическими гигантами, такими как Google или Apple, создание уникальных решений и дает возможность выделяться.

Преимущества Cangjie: безопасность, производительность и гибкость

Что интересного есть у Cangjie:

• Интеграция с аппаратным и программным обеспечением Huawei. Теперь разработка приложений под устройства Huawei станет более эффективной.
• Интеграция с Agile DSL. Можно объединять обычное программирование с конструкциями, близкими к естественному языку. Это упрощает взаимодействие между техническими и нетехническими участниками проекта, улучшая коммуникацию и совместную работу.
• Встроенные инструменты для статической проверки кода, которые помогают выявлять уязвимости и ошибки на этапе написания кода. Это улучшает качество создаваемого программного обеспечения и позволяет разработчикам исправлять проблемы до того, как они попадут в конечный продукт. А еще повышает безопасность кода.
• Улучшенное управление памятью и сборка мусора. Обеспечивает более эффективное выполнение кода и минимизирует вероятность утечек памяти. Разработчики могут сосредоточиться на бизнес-логике, не беспокоясь о низкоуровневых задачах, связанных с управлением ресурсами.
• Высокое быстродействие. Можно создавать приложения с высокой нагрузкой, например, для работы с большими данными или машинного обучения.
• Гибкость синтаксиса. Можно писать код с минимальным количеством строк. Это актуально для новичков, которые только начинают путь в программировании.

Какие перспективы у российских разработчиков

Huawei пока еще не объявляла дату релиза, но в рамках бета-тестирования предоставлены все необходимые инструменты: разработка, тестирование, отладка и статическая проверка качества программного обеспечения.

Для российских разработчиков использование Cangjie может стать актуальным, если работа с экосистемой Huawei войдет в их приоритеты. В условиях международной обстановки адаптация программных решений под китайские технологии уже активно развивается. Если Huawei продолжит расширять свои позиции в мире, включая Россию, то интерес к Cangjie среди местных разработчиков будет расти.

Веб-разработка

5 новых функций CSS, которые вы обязаны знать в 2024 году

Веб-разработчику важно всегда быть в курсе новых технологий, которые применяются при разработке сайтов. В этой статье вы узнаете о 5 новых функциях CSS: о cелекторе :has(), запросах к контейнерам, вложенности CSS, text-wrap:balance и :focus-visible.

Как стать фулл-стек веб-разработчиком

Хочется и во фронтенд, и в бекэнд? Тогда фулл-стек — это лучшее решение для вас. В этой статье IT-блогер Conner Ardman рассказал, что нужно учить, чтобы стать фулл-стек веб-разработчиком в 2024 году (ещё не поздно).

Роадмап веб-разработчика: что учить в 2024 году

Ну а если пока не понятно, что и в какой последовательности учить — вам поможет этот материал. Stefan Mischook составил дорожную карту для веб-разработчиков, охватывающий все технологии, которые нужно знать в 2024 году.

Шпаргалка по всем свойствам CSS Flexbox

Кратко, удобно, понятно — такая вот шпаргалка по свойствам флекса. Если вы постоянно забываете, чем align-items отличается от justify-conent, то обязательно добавляйте гайд в избранное — он вам точно поможет.

Другие материалы ищите по тегам: HTML, Фронтенд, React, Веб-разработка, Angular, Node.js, Vue

Мобильная разработка

Тренды в мобильной разработке в 2024 году

Пользователь нашего сайта рассказала, что в мобильной разработке будет популярно в 2024 году и на какие технологии стоит делать ставку. Кстати, вы тоже можете писать статьи — для этого зарегистрируйтесь на сайте и воспользуйтесь кнопкой «Написать пост».

Дорожная карта по Android-разработке с нуля

Ещё одна полезная статья от читателя Tproger. Из материала вы узнаете как стать Android-разработчиком с нуля, следуя дорожной карте, и что изучать и в какой последовательности. Подходит новичкам ;)

Битва титанов: Java vs Kotlin

Не знаете, какой язык для мобильной разработки лучше учить? Прочитайте этот материал и, возможно, сможете определиться.

Советы начинающим мобильным разработчикам от опытных коллег

Джуны, загляните. Здесь очень важные советы, которые могут помочь вам быстрее набираться опыта и повышать свою квалификацию в мобильной разработке.

Другие материалы ищите по тегам: Мобильная разработка, Java, Kotlin, Swift.

Машинное обучение

Как и на чём обучить модель машинного обучения

В статье показали базу, полезную для крепких джунов и более опытных специалистов: объяснили, как подобрать фреймворк и железо и раскатать ML-модель.

Книги о машинном обучении для новичков

Четыре книги, которые подойдут тем, кто только начинает свой путь в машинном обучении. Кстати, подборку сделала специалист.

Как работает обучение без учителя

Что такое обучение без учителя и почему оно так называется? Какие задачи можно решить с помощью этих методов? А какими алгоритмами? Есть ли у него недостатки? Разбираемся как на банковских примерах, так и на более приземленных вещах — столах, стульях и шкафах.

Другие материалы ищите по тегам: Машинное обучение, Искусственный интеллект, Нейронные сети

Делитесь в комментариях лучшими статьями, книгами, видео, курсами, подкастами, которые помогают в обучении любым IT-профессиям.

После закрытия Zenly мы вместе с коллегами Димой Трачуком и Марией Мышь (ранее работала в Zenly), собрались и начали обдумывать создание своего приложения. К нам постепенно присоединились и другие специалисты, и мы продолжили формировать команду.

Конечно, вдохновлялись Zenly, ведь сами являлись активными пользователями ранее популярного и полезного сервиса. После его закрытия у нас появилась потребность в аналогичном решении для отслеживания местоположения друзей. Поэтому мы решили создать Blink. Позаимствовали положительный опыт использования Zenly, но дополнили продукт новыми функциями и улучшениями, делающими его уникальным и отвечающим потребностям пользователей.

Стоит отметить, что импортозамещение обычно подразумевает создание аналога продукта, который больше не доступен в России. В случае Zenly, это приложение не просто ушло из России — оно полностью прекратило свою деятельность. Поэтому мы не выступаем импортозаместителями в прямом смысле этого слова. Наше приложение — самостоятельное решение, разработанное с нуля.

Какие основные функции и возможности предлагает Blink пользователям? Можем ли мы «бампнуться» по-старинке или отправить смайлик другу на весь экран?

Blink — это приложение, которое вобрало в себя все ключевые функции некогда популярного Zenly, но с рядом значительных улучшений и новшеств.

Одна из новых возможностей Blink — функция отслеживания шагов. Теперь пользователи могут соревноваться друг с другом, сравнивая свою ежедневную активность. Эта опция стала возможной благодаря высокой точности геолокации.

Кроме того, в Blink реализована усовершенствованная система чекинов. При отметке пользователя в определенной локации, его друзьям тут же приходит push-уведомление. В Zenly данная функция работала менее эффективно, поэтому мы приняли решение о ее полной переработке.

Еще одна интересная особенность Blink — функция «трях», аналогичная «бампу» из Zenly. Теперь, чтобы сообщить друзьям о встрече, достаточно просто потрясти телефонами. Вообще, термин «бамп» в английском языке имеет сексуальный подтекст, поэтому для англоговорящей аудитории звучит так же странно, как «трях» для русскоязычной.

Какие программные платформы и языки программирования использовались для разработки Blink? Почему был выбран именно такой технологический стек?

Выбор стека связан с наличием специалистов на рынке, задачами и с высокими хайлоадом. В качестве основного языка веб-разработки мы выбрали компилируемый Golang, это современный стандарт для стартапов.

Помимо Golang, в стек входит ряд других ключевых инструментов. Для обработки потоков данных в режиме реального времени используется Apache Kafka, надежный и производительный брокер, с которым уже была знакома команда разработчиков и DevOps/SRE. Выбор Kafka обусловлен необходимостью надежной маршрутизации гигабайтов геопакетов в секунду.

В качестве основной базы данных выбран PostgreSQL, известный своей надежностью, производительностью и возможностью масштабироваться. Для кэширования данных используется Redis, а ClickHouse – для аналитики и обработки больших объемов данных, в том числе для пост-процессинга геокоординат. На данный момент объем данных в кластере приближается к 30 ТБ, и ClickHouse справляется с этой нагрузкой.

Для мобильных платформ мы используем Swift для iOS и Kotlin для Android.

Основной принцип, которым руководствуемся при выборе технологий – широкое распространение и длительная история использования, гарантирующие надежность. Было решено не экспериментировать с новыми технологиями, а использовать проверенные инструменты, с которыми уже работали ключевые специалисты.

Перейдем к конкретным фичам. Какие алгоритмы и методы используются для определения местоположения пользователей в Blink? Как вы обеспечиваете высокую точность геолокации?

В основе нашей работы лежит сбор данных с устройств пользователей и применение технологий геофенсинга. Хотя мы не изобретаем революционных решений, поскольку действуем в рамках закрытых операционных систем (iOS и Android), тщательно обрабатываем полученные данные, чтобы обеспечить их точность и надежность. Как происходит процесс?

Все начинается с получения координат от пользователя. Эти данные проходят несколько этапов проверки. Мы анализируем, не произошел ли резкий скачок местоположения, например, перемещение из России в Австралию за короткий промежуток времени. Фильтр Калмана помогает сглаживать координаты, удаляя аномальные значения и улучшая точность.

Если координаты проходят наши фильтры, они отправляются на дальнейшую обработку. Но если выявляем проблемы по типу воздействия GPS-глушилок, применяем дополнительные этапы проверки.

Мы также проверяем, находится ли пользователь в знакомом окружении, например, в домашней сети Wi-Fi. Если данные указывают на аномальное перемещение, корректируем местоположение.

Стоит отметить, что в последнее время мы все чаще сталкиваемся с проблемами навигационных систем и GPS-глушилок. Поэтому разработали целый ряд фильтров и механизмов для обеспечения высокой точности геолокации. Кроме того, работаем над улучшением клиентской части, оптимизируя работу приложения для минимального потребления заряда аккумулятора. Blink в среднем потребляет всего 1% заряда в сутки, что является отличным показателем. Мы потратили много времени на это улучшение, и теперь приложение практически не тратит заряд, хотя работает в фоновом режиме.

Как реализована система хранения и обработки больших объемов геоданных в приложении? Какие технологии и подходы задействованы?

Мы внедрили два ключевых решения: Apache Kafka и ClickHouse.

Apache Kafka выступает в качестве надежного механизма передачи данных между различными сервисами. Он обеспечивает бесперебойную доставку координат пользователей, которые постоянно обрабатываются и анализируются приложением.

В свою очередь, ClickHouse — это высокопроизводительная аналитическая база данных, где мы храним всю историю передвижений наших пользователей. Это позволяет создавать уникальные решения, раскрывающие интересные закономерности и паттерны поведения людей. Например, мы можем показывать пользователям, где они чаще всего ночевали, с кем больше всего общались, какие места посещали и какие районы исследовали. Эти «цифровые следы» помогают людям лучше понимать свои привычки.

Стоит отметить, что объем накопленных нами данных уже превышает 30 терабайт. Это огромный массив информации, который требует применения современных Big Data решений, таких как Kafka и ClickHouse. Благодаря этому мы можем эффективно управлять и анализировать все эти данные, извлекая ценные инсайты и предоставляя полезный сервис нашим пользователям.

А что насчет самих пользователей? Как вы подходите к вопросам безопасности и конфиденциальности данных в Blink? Какие меры предприняты для защиты личной информации?

Мы применяем комплексный подход, сочетающий в себе передовые технологии шифрования и строгие меры контроля доступа.

Во-первых, все данные тщательно зашифрованы. Даже в случае несанкционированного доступа к бэкапам, злоумышленник не сможет расшифровать эту информацию без наличия соответствующих ключей. Объем хранимых данных также делает невозможным их незаметное похищение.

Во-вторых, в компании регулярно проводится аудит безопасности. Мы тщательно контролируем, кто и к каким данным имеет доступ. Более того, любое обращение к конфиденциальным ресурсам, будь то подключение к базе данных из нестандартного местоположения, вызывает срабатывание системы оповещения. Таким образом, все действия с чувствительной информацией пользователей фиксируются в журнале регистрации и расцениваются как инциденты безопасности.

Какие методы и инструменты применяются для анализа поведения пользователей, их передвижений и активности в приложении? Как вы используете эти данные для улучшения сервиса?

У нас есть два основных направления аналитики: клиентская и серверная.

Для клиентской аналитики мы используем как бесплатные, так и платные трекеры для отслеживания активности пользователей. Одним из ключевых инструментов является Amplitude, позволяющий собирать и анализировать данные о взаимодействии пользователей с приложением.

В части серверной аналитики:

• Все события, связанные с действиями пользователей, собираются и отправляются на наш сервер, где хранятся в базе данных ClickHouse. Это касается как клиентских, так и серверных событий.

• Собранные данные затем передаются в BI-системы, такие как Redash и Superset, для визуализации и построения дашбордов.

• Наши аналитики проверяют гипотезы и анализируют поведение пользователей. При этом данные обезличены, чтобы не нарушать конфиденциальность.

Один из последних кейсов:

В дашборде, посвященном онбордингу пользователей, мы заметили значительное снижение конверсии на этапе заполнения никнейма. Анализ показал, что многие никнеймы уже были заняты, и новым пользователям сложно было выбрать уникальные. В результате мы внедрили функцию автоматической генерации никнеймов, с возможностью их изменения. Это решение повысило конверсию на этапе онбординга на 3 процентных пункта.

В целом, при разработке новой функциональности мы всегда опираемся на данные. Мы анализируем, как пользователи взаимодействуют с приложением, какие у них возникают проблемы, что пользуется наибольшей популярностью, а что — меньшей. Такой аналитический подход позволяет нам принимать обоснованные решения и улучшать продукт на основе реальности, а не интуитивных предположений.

С какими основными трудностями и вызовами вы сталкивались в процессе разработки и масштабирования Blink? Как вы их преодолевали?

Несмотря на стремительный рост, мы столкнулись с несколькими серьезными техническими вызовами:

1. Изначально, с нагрузкой в 10 тысяч онлайн-пользователей, наши го и легковесные горутины, а также оптимизированные веб-фреймворки справлялись с нагрузкой. Однако с ростом аудитории до 100 тысяч возникли проблемы на сетевом уровне, которые нашим инженерам удалось решить за счет переконфигурирования балансеров (nginx + sysctl).
2. Для хранения географических данных мы выбрали PostgreSQL, но со временем объем этих данных превысил 1 ТБ, что привело к существенному падению производительности. Попытки горизонтально масштабировать PostgreSQL оказались малоэффективными, и в итоге мы перешли на Clickhouse, который гораздо лучше справился с этой задачей. Перевод на Clickhouse занял около недели, но куда больше времени потребовалось на миграцию данных из PostgreSQL.
3. Недостаток мониторинга приводил к тому, что о проблемах мы узнавали уже тогда, когда они становились критическими и вызывали простои сервиса. Несколько бессонных ночей наглядно продемонстрировали важность использования инструментов вроде Grafana.

Несмотря на эти трудности, нам удалось преодолеть их и продолжить успешное развитие Blink. Опыт, полученный в ходе решения этих задач, стал для нас бесценным.

Каковы ваши планы на дальнейшее развитие приложения? Над какими новыми функциями и возможностями сейчас работаете?

В первую очередь, мы активно работаем над улучшением качества геолокации. Поскольку основная особенность нашего продукта заключается в точном определении местоположения пользователей, важно, чтобы оно всегда отображалось корректно. Мы тщательно анализируем возникающие у пользователей проблемы (случайные вылеты и неверные координаты) и внедряем разные фильтры для их минимизации. В случаях, когда проблему невозможно решить из-за внешних факторов, мы честно информируем пользователей о временных неудобствах.

Из больших сервисов, над которыми работаем сейчас — чекины. Это инструмент, который позволяет пользователям в реальном времени делиться своим местоположением, фотографиями и видео, рассказывая друзьям о том, где они находятся прямо сейчас. В ближайшем будущем планируем добавить элементы геймификации, например, возможность соревноваться за звание «мэра» в различных локациях, основываясь на частоте посещений.

Кроме того, мы разрабатываем собственную карту Blink Maps, которая будет интегрирована в приложение уже через несколько месяцев для некоторых устройств на Android. Это наша собственная 3D-карта, позволяющая решить технические ограничения, с которыми мы сталкиваемся при использовании платформенных карт, по типу Google Maps. Например, сможем более эффективно отображать больше пинов без задержек и сбоев. Карта будет регулярно обновляться, что позволит избегать проблем с устаревшей информацией. У нас свой движок, построенный на видеопроцессоре GPU, который на основе данных OpenStreetMap делает магию. Основу мы берем из OSM и поверх накручиваем все свои изменения.

Как вы считаете, какие тенденции и инновации будут определять развитие мобильных приложений для отслеживания местоположения в ближайшем будущем?

Развитие мобильных приложений для отслеживания местоположения будет в значительной степени определяться несколькими ключевыми тенденциями. Во-первых, одним из главных трендов станет создание и использование собственных карт. Компании будут стремиться к разработке индивидуальных картографических решений, чтобы обеспечить более точное и актуальное отображение данных. Это позволит делать карты под себя, а не универсальную балалайку для всех. Сегодня оффлайн — это дополнение к онлайну, а карта лучше всего интегрирует реальный мир в виртуальный.

Во-вторых, предиктивный анализ и прогнозирование местоположения станут важными направлениями развития. Использование алгоритмов машинного обучения и искусственного интеллекта позволит не только фиксировать текущее местоположение, но и предсказывать перемещения пользователей на основе их привычек и исторических данных. Это значительно улучшит пользовательский опыт и откроет новые возможности для персонализации сервисов.

Однако, в свете этих тенденций, стоит учитывать, что Apple и Google, например, продолжают усложнять работу с геолокацией для сторонних разработчиков. Несмотря на наличие встроенных решений, таких как Find My Friends у Apple, ограничения и новые требования для работы с геоданными становятся все более жесткими. Это создает дополнительные вызовы для разработчиков, которые должны адаптироваться к меняющимся условиям и искать альтернативные пути стабильной работы своих приложений.

В этой статье на основе опыта работы с Firebase расскажу о плюсах, минусах и альтернативах использования этой платформы. Текст будет полезен тем, кто разрабатывает или планирует разрабатывать мобильные приложения.

В основе статьи — онлайн BoF-сессия на IT-конференции Mobius 2024, во время которой я обсуждал Firebase с коллегой Сергеем Мясниковым из ВКонтакте, Кириллом Поповым из ОК, Артёмом Ковардиным из RuStore и Алексеем Гладковым — мобильным разработчиком, автором проекта Mobile Developer.

Что такое Firebase?

Платформа Firebase популярна как набор решений для упрощения разработки мобильных приложений. С помощью её инструментов можно развернуть бэкенд со своей серверной логикой, подключить push-сообщения и аналитику, получать отчёты об ошибках, проводить A/B-тестирование. Платформа облачная: все ресурсы приложений, в том числе базы данных и клиентская аналитика, хранятся на серверах Google.

Самые востребованные инструменты Firebase:

• Firebase Cloud Messaging (FCM) — позволяет отправлять push-сообщения на устройства пользователей;
• облачная служба Firebase Remote Config — позволяет вносить изменения в конфигурацию приложения в режиме реального времени;
• сервис Firebase Crashlytics — помогает находить в приложениях причины зависаний, сбоев и медленной работы, собирать ошибки с продакшена, систематизировать их и фильтровать;
• сервис Firebase Performance Monitoring — инструмент для аналитики, позволяет отслеживать ключевые метрики: использование памяти, CPU, сетевого трафика;
• сервис Google Analytics — инструмент для продуктовой аналитики, позволяет получать информацию об использовании приложений и вовлечённости пользователей.
  

Именно с этих инструментов независимые разработчики и стартаперы обычно начинают знакомство с Firebase.

Альтернативы Firebase: почему они важны?

У Firebase действительно много полезных инструментов для мобильной разработки. Однако некоторые из них несовершенны и могут замедлить развитие проекта. Именно поэтому важны альтернативы, с которыми можно более точечно работать над продуктом.

Firebase — хороший выбор для старта приложения, в нём есть всё необходимое для запуска. Можно без лишних затрат опробовать технологии, поиграться с ними. Но сейчас мы находимся на этапе, когда Firebase постепенно теряет свою монополию. Альтернативные механики начинают давать не просто аналоги инструментам платформы, они открывают много новых опций. Поэтому вы даже выиграете, если будете использовать в том числе и альтернативные решения

Есть ещё одна причина, почему важны альтернативы Firebase: разработчикам необходимо поддерживать свои продукты на версиях Android без сервисов Google, например на ОС, собранных на базе AOSP. Но вне зависимости от операционной системы и её версии лучше держать в голове (а желательно в инструментарии) запасные варианты на случай, если что-то пойдёт не так.

Чем можно заменить FCM?

Push-сообщения — один из самых востребованных инструментов Firebase. Часто именно из-за него разработчики начинают использовать эту платформу в своих проектах; у них просто нет вариантов — push-сообщения используют Google-сервисы, которые, в свою очередь, имеют «системные привилегии».

Однако если вы собираетесь делать приложение для рынка России, то крайне желательно рассмотреть и другие инструменты и подумать над запасными решениями. Часть рынка РФ занимают, например, смартфоны Huawei, в которых нет сервисов из Google Play.

• RuStore Push — фактически альтернативный вариант для доставки push-сообщений, причём со своим транспортом. Чтобы упростить интеграцию, есть и омниканальное решение — Universal Push. Благодаря ему в рамках одного SDK можно обеспечить отправку в HMS, FCM и RuStore. Использование универсального API позволит подготовить некоторый fallback-механизм и поможет несколько повысить доставляемость уведомлений.
• Отдельные вендоры смартфонов разрабатывают свои решения для своих устройств. Например есть облачная служба Push Kit для рассылки уведомлений. С помощью неё можно отправлять push-сообщения на устройства Android и iOS, а также в веб-приложения.
• Если вы работаете в сфере B2B, то на рынке есть много MDM-решений — некоторые из них базируются на AOSP со своим транспортом для push-сообщений и со своим сервисом, который интегрируется в инфраструктуру заказчика. Этот вариант обычно используют компании, чтобы управлять устройствами сотрудников.

Когда проект только стартует, в нём обычно используется лишь Firebase. В дальнейшем желательно сразу заложить в проект несколько вариантов: например, RuStore Push, HMS Core, Firebase и один из омниканальных сервисов, — это позволит обезопасить себя и повысить доставляемость

Remote Config: какие есть аналоги?

Второй по популярности инструмент Firebase — Remote Config. Из названия понятно, что сервис позволяет добавлять в приложение параметры, которые можно изменять удалённо с бэкенда. Он достаточно легко интегрируется в мобильные приложения — как на Android, так и на iOS.

Одно из главных достоинств Remote Config — аналитика. Благодаря этому инструменту можно проводить A/B-тесты и изучать аудиторию приложения на основе таких критериев, как возраст или увлечения.

В качестве альтернативы FRC можно назвать RuStore Remote Config, который также позволяет конфигурировать приложения и проводить A/B-тесты. Это решение доступно для приложений на устройствах c Android и iOS и позволяет заменить Firebase.

Возможность конфигурировать свои приложения и проводить А/В-тесты — важная часть любого проекта, которая помогает делать его лучше для пользователей. Я советую диверсифицировать риски и использовать разные инструменты, чтобы не зависеть от одного сервиса

Анализ ошибок: Firebase vs Tracer

Анализ ошибок — один из важнейших параметров, на которые опираются при создании и развитии приложений. Если баги не устранять, они могут потянуть за собой ухудшение UX, потерю лояльности и отток аудитории, а также смещение фокуса с написания продуктового кода на исправление ошибок.

Сервис Firebase Crashlytics предоставляет подобную функциональность поиска ошибок. Он пользуется популярностью среди разработчиков, однако возможности сервиса сравнительно ограничены: в нём неудобный поиск, неточная группировка событий (ошибок, ANR) по типу, нет инструментов для работы с non-fatal ошибками, из-за чего они могут создавать свалку. И это только небольшой список проблем — на деле их гораздо больше.

В вопросе анализа ошибок у Firebase есть крепкая альтернатива — сервис Tracer от ОК. Если сравнивать эти два инструмента, то Tracer не только предлагает похожую функциональность по анализу, но и расширяет инструментарий разработчика. В нём есть:

• полнотекстовый поиск по стектрейсу;
• полноценный поиск по User ID — не только крешей, но и любых событий;
• возможность самому на клиенте решать, как группировать ошибки. Например, отдельно отслеживать все баги, связанные с авторизацией;
• поиск и фильтрация по любым полям и атрибутам;
• поддержка A/B-тестов;
• возможность профилирования и анализа утечек памяти в продакшене с загрузкой дампов памяти.

Мы начали создавать Tracer, когда разработчики Crashlytics, по ощущениям, совсем его забросили. Главная страница долго грузилась, сервис не умел сортировать ошибки по количеству задетых пользователей, не было полноценного поиска. В какой-то момент мы с коллегами решили делать свой продукт, в котором не было бы этих проблем

Ещё одна альтернатива Crashlytics — сервис Sentry. Это open-source проект, главная особенность которого — возможность развёртки внутри собственной инфраструктуры. Это позволяет минимизировать риски, связанные с утечкой чувствительных данных: например, словарей обфускации или логов с пользовательскими данными. Однако в России легально приобрести и развернуть self-hosted решение от Sentry не выйдет. К тому же на больших объёмах данных оно работает не идеально. И при всём этом требует затрат на поддержку и инфраструктуру.

Аналитика от Firebase: альтернативы есть

Аналитика, прежде всего, помогает разработчикам зарабатывать на их продуктах. Без неё не получится закупить трафик и будет непонятно, как много времени пользователь проводит в приложении и сколько удалось заработать с каждого источника.

Сервис для аналитики от Firebase — Google Analytics — позволяет увидеть общую картину того, что происходит в приложении. Однако для глубокого погружения он не очень подходит — для этого лучше использовать более локальные решения. Кстати, их довольно много: Google Analytics можно назвать самым легко заменяемым продуктом от Firebase.

Например, сервис MyTracker от VK. Он ориентирован на российский рынок, менее загружен, чем Performance Monitoring. Соответственно, позволяет более точно анализировать ключевые показатели мобильных приложений, эффективность источников трафика и монетизации. С помощью него можно сегментировать аудиторию и строить прогнозы LTV, оттока. Сервис интегрирован с RuStore и другими альтернативными сторами. На данных и сегментах MyTracker работают Remote Config и могут работать push-уведомления RuStore.

Ещё один вариант — написать свой движок для аналитики.

Аналитика от Google позволяет только примерно представить, что происходит с приложением. Если вам необходимо детальное понимание, то лучше всегда держать „второе мнение“. Обычно мы используем внешние системы аналитики и самописные вещи. В этом есть значительный плюс: не надо отдавать важные и персонализированные данные о пользователях сторонней компании

Архитектурная гибкость

Запуститься совсем без Firebase невозможно, однако у инструментов этой платформы есть альтернативы. Те решения, о которых я рассказал, дополнят необходимую функциональность. Я не призываю навсегда отказаться от Firebase — просто рекомендую проектировать архитектуру так, чтобы была возможность переключиться на другой инструмент. Благодаря этому вы сможете закрыть свои потребности, работать быстрее либо с бо́льшим удобством.

Конечно, её сравнивают и будут сравнивать с гигантами вроде Android и iOS. Поэтому она должна быть качественной и вполне конкурентоспособной, и одновременно самобытной и по-своему прорывной.

Нам хотелось бы привлечь больше разработчиков, создать больше приложений, сформировать свою экосистему сервисов и ширить базу преданных пользователей. И мы создали Aurora Foundation. Проект уже начал объединять разработчиков ОС, приложений и сервисов, производителей устройств. В статье расскажем, что уже готово и что планируем делать в будущем.

Взять хорошую универсальную основу

Сейчас многие популярные инструменты стали официально недоступны. Любимые многими продукты JetBrains не купить в России, какие-то ресурсы порой доступны только через VPN. Мы делаем IDE для Flutter, так что, очевидно, доступна ещё Android Studio. Но это всё же нишевый инструмент, который нет смысла брать за основу универсального продукта.

Есть и альтернативные пути. При желании можно и Neovim заточить под Flutter (хотя вряд ли найдётся много охотников таким образом работать) или посмотреть в сторону развивающихся опенсорсных проектов вроде подающего надежды Zed от создателей Atom. Но на длинной дистанции это не кажется удобными или надёжными.

По большому счёту, из мощных универсальных инструментов в свободном доступе остался лишь VS Code — по статистике им пользуется примерно треть разработчиков. Но не все его плагины полноценно работают в России, особенно сопряжённые с зарубежными облачными сервисами.

Так что мы взяли его опенсорсную версию Code OSS в качестве основы и начали писать свою IDE для российского комьюнити разработчиков под основные платформы (Linux, Windows, macOS на x86 и ARM). Лицензия MIT, убедительная история разных форков и способность работать как серверное веб-приложение без локальной установки стали дополнительными аргументами.

Project IDX — анонсированная новая среда разработки от Google тоже основана на Code OSS.

Максимально упростить работу

У Авроры давным-давно есть свои SDK, но процесс установки непростой. Нужно либо уже знать, как система устроена, либо лезть в документацию и идти по инструкции. А давайте честно, мало кто любит инструкции, и большинство сперва подходит интуитивно, обращаясь к документации, уже когда интуитивно не получилось.

Мы хотим убрать этот барьер и сделать процесс проще, чтобы даже новичок, который только-только окончил курс «Введение в программирование», смог установить и настроить IDE под себя, И затем быстро собрал работающее приложение с помощью шаблонов и преднастроенных тулчейнов сборки.

Поэтому делаем так, чтобы всё окружение и инструменты сами устанавливались и настраивались «по клику», а всё остальное автоматически доезжало по мере необходимости. Ну и конечно же используем контейнеры, чтобы создание сред отладки и сборки было наименее «инвазивным» для компьютера разработчика, и в перспективе появилась возможность запускать среды и на серверной стороне в облаке.

Продуманный Developer Experience — ключ к успеху любой платформы, будь то операционная система или просто фреймворк для прикладной разработки. И мы стараемся позаботиться в том числе о начинающих разработчиках и сделать опыт работы с Авророй для них приятным открытием

Добавить эмулятор и совместимость с другими операционками

Чтобы протестировать приложение на Авроре, нужен телефон или планшет на Авроре. А их сейчас не всегда легко достать на рынке — особенно если вы группа разработчиков и хотите парк устройств. К тому же не всегда удобно физически подключать телефон к ПК или ноутбуку, чтобы отлаживать и тестировать разрабатываемое приложение.

Поэтому нужен эмулятор устройства с Авророй. В классическом Aurora SDK уже есть такой, на базе виртуалок. А в Aurora Studio мы реализуем контейнеры с разными таргетами сборки ОС и эмулятором на базе QEMU. По задумке, его можно будет виртуально запускать и отлаживать приложения на основных архитектурах и форматах устройств локально или в облаке.

Взяв на вооружение Flutter, можно собирать приложения сразу для Авроры, Android и iOS. И почему бы не задаться целью сделать подход Aurora first — когда вместо портирования на Аврору приложений, изначально разработанных под другие платформы, мы сразу пишем софт под Аврору и параллельно собираем для других платформ. Думаю, такой подход поможет Авроре стать у российских разработчиков куда более популярной мобильной ОС.

Добавить облака

Облака — это тренд рынка по нескольким причинам.

• Отладка с тестированием становятся настолько ресурсоёмкими и комплексными процессами, что разумно выносить эти операции с компьютера разработчика на внешние мощности, в том числе облачные.
• Да и благодаря многообразию операционных систем, устройств и архитектур (x86 и ARM, RISC-V и MIPS, скорее всего, перестанут быть экзотикой Эльбрусы и LoongArch и так далее), приходится учиться жонглировать всё более сложными средами разработки и заниматься созданием и поддержкой собственных стендов в железе.
• Стандартом индустрии становятся IDE, усиленные облачными средствами сборки, запуска, отладки, тестирования и всевозможного анализа кода, а также публикации релизов на площадках дистрибуции. У Apple эти задачи решает Xcode Cloud, у Google — недавно стартовавший Project IDX. Подобная история есть, разумеется, и у Microsoft, причём сразу в нескольких местах – на vscode.dev, на github.dev и в Azure.
• В IDE прорастает направление ИИ-ассистентов для программирования, базирующихся на соответствующих облачных сервисах.
• Растёт актуальность нового класса облачных услуг — Environment-as-a-Service (EaaS, «среда как сервис»).
  

Это, кстати, ещё один аргумент в пользу Code OSS и его способности работать и десктопно, и в браузере. С таким фундаментом переход к нашей собственной EaaS-платформе станет абсолютно бесшовным.

Гарантировать безопасность

Мы уделяем особое внимание их безопасности, и разработчикам приложений также стоит о ней думать — в частности при взаимодействии с внешними службами.

Но безопасное кодирование — непростая дисциплина, особенно для новичков, потому что надо:

• овладеть принципами и подходами «безопасного кода»;
• освоить инструменты для своевременного выявления потенциальных уязвимостей;
• разобраться во множестве неочевидных технических нюансов, определяющих безопасную работу ПО;
• изучить требования закона к системам, которые затрагивают персональные данные и идентификацию пользователей, их платёжные средства или физиологические показатели;
• понимать требования закона к системам, которые обслуживают критическую инфраструктуру.

Крупные компании, онлайн-школы и технологические вузы даже запускают курсы по этой теме, поскольку эти компетенции становятся гигиеной в современном мире.

Это же просто нескончаемая эпопея с тем, как гиганты вроде Microsoft и их пользователи страдают от дыр в системах: взломы, сливы данных, скандалы. Конечно, сделать софт на 100% безопасным крайне сложно, но тем не менее инструментально обеспечить приличную долю неуязвимости можно.

Мы же мечтаем сделать безопасную разработку доступнее на уровне IDE. В идеале — чтобы разработчикам любого уровня и понимания темы было сложнее совершать ошибки. Для нас самих это станет дополнительной гарантией того, что в софте будет минимум уязвимостей. Что можно реализовать:

• указывать, что в написанном коде есть небезопасные конструкции, и подсвечивать их (для этого уже есть инструменты, которые нужно интегрировать в IDE);
• автоматически находить дыры и вредоносный код в опенсорсных пакетах, которые использует разработчик (и в их транзитивных зависимостях), прямо на это указывать и советовать использовать другую версию такого пакета или какие-то другие аналоги (у нашего «РТК-Феникс» уже выстроен очень хороший пайплайн, советую зайти и почитать);
• предлагать готовые шаблоны безопасной реализации типовых прикладных конструкций.

Реализовать это всё в упомянутой ранее концепции EaaS — самая разумная стратегия.

У меня есть сверхзадача — достичь такого уровня зрелости инструментов нашей IDE, который бы позволил буквально гарантировать разработчику: он создаст код, соответствующий всем необходимым требованиям безопасности и лицензионной чистоты. Звучит фантастически, но мы работаем в этом ключе.

Всесторонне развивать экосистему

Недостаточно просто сделать IDE и ждать, когда к нам придут разработчики — нужно развивать всю экосистему платформы, включая глобальные службы, необходимые приложениям.

Сейчас на Аврору постепенно добавляются новые приложения и растёт сообщество (там уже собрались классные и очень открытые специалисты — заходите). И что важно, мы развиваем экосистему базовых общедоступных сервисов. Среди которых долгожданная глобальная служба пушей, доверенные сервисы точного времени и DNS, проверка интернет-соединения и другие фичи, важные для любой мобильной платформы.

Из особо интересного: мы решили сделать службу синхронизации пользовательских данных между устройствами и развиваем довольно необычную концепцию сервисной агрегации. Она позволит добавить клиентские сервисы в Аврору не в виде приложений, а через интеграцию данных в одно из специальных типовых приложений платформы. В планах сделать такие приложения для нескольких областей — общение через различные текстовые и голосовые средства коммуникации, личная продуктивность, финансы, файловые хранилища, навигация и прочее.

Представим, что у вас пять банковских приложений, и вы перешли на Аврору. Чтобы не скачивать всё заново и потенциально не мучиться с иконками веб-версий, можно просто использовать предустановленный сервис, назовем его «Финансы», где будут данные из всех банков. Примером подобной концепции является многим хорошо знакомый Apple Wallet.

Разумеется, шаблоны работы со всеми сервисами этой экосистемы сразу интегрируем в Aurora Studio. И обеспечим автоматическую публикацию их релизов в RuStore и приватных корпоративных Аврора Маркетах.

Развитие Авроры сейчас находится на таком этапе, когда двигаться дальше без экосистемы средств разработки и общедоступных базовых сервисов будет всё сложнее. При этом создание и развитие экосистем задача непростая, и по плечу она, пожалуй, только сообществу крупных игроков, заинтересованных в win-win. Поэтому если не мы, то кто может быть драйвером этого развития?

Что осталось сказать

У нас огромные планы — осталось всё это сделать. Сейчас у нас уже есть первые сборки среды разработки Aurora Studio, которые можно скачать и пощупать. Пока там нет всех фич, про которые рассказали в статье, но мы в процессе их реализации. И приглашаем вас протестировать альфа-версию нашей IDE.

Впрочем, это только начало, и мы не хотели бы интегрировать поддержку других фреймворков и инструментов, сформировать среду для fullstack-разработки — с поправкой на условия, в которых работают российские разработчики, и наши представления об идеальной IDE, сопутствующих сервисах и судьбе сообщества в целом.

Пишите в комментариях, на что вы обращаете внимание в среде разработки и что хотели бы видеть в IDE.

И бонусом несколько полезных ссылок

• Живое сообщество в Telegram
• Официальная документация для разработчиков от Открытой мобильной платформы
• Официальная библиотека на GitLab
• YouTube-канал Открытой мобильной платформы, где выходят новости и обзоры
• Портал разработчиков
• Учебный курс на GitLab по работе в Qt
• Бесплатный курс на Stepik
• Платный курс на Otus
• Очный курс в Академии Информационных систем
  

Встречайте помощника с искусственным интеллектом Gemini Pro прямо внутри Android Studio!

Gemini Pro – это что такое?

Это умный чат-бот от Google, понимающий ваши вопросы об Android-разработке. То есть с помощью этого умного генератора кода вы сможете быстрее писать код. К тому же он, будучи знатоком Android, будет советовать правильные решения по ходу написания проекта.

Что он умеет?

• Отвечать подробно на вопросы вроде «Как добавить камеру в мое приложение?» или «Помоги создать экран логина в Compose».
• Генерировать целые куски кода по вашим описаниям.
  
• Писать комментарии и документацию к вашему коду!

Это безопасно?

По словам Google, Gemini Pro заботится о конфиденциальности – он использует данные только с вашего разрешения. Вы сами решаете, какие части проекта можно показывать ИИ.

Где новинку можно попробовать?

Gemini Pro сейчас на стадии тестирования, но уже доступен в свежих версиях Android Studio. Ищите его в разделе Gemini in Android Studio.

И еще немножечко на сладкое…

Новенький шаблон Gemini API Starter поможет создать собственные приложения при помощи ИИ. Его можно использовать, например, чтобы добавить в проекты разные фишки вроде:

• Умного чата
• Генерации подписей к изображениям
  
• Перевода
  
• И многого другого!
  

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики.

Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

На сегодняшний день, в целом, можно позитивно оценить Flutter. Его основной плюс в том, что это кроссплатформенная среда, позволяющая быстро типировать и экономить время. Гипотетически, один разработчик может обслуживать полностью экосистему iOS и Android, а также создавать кроссплатформенные приложения. С помощью Flutter можно смоделировать нативное приложение под Windows, Linux и iOS, и оно будет запускаться сразу в контейнере на Flutter, адаптированном под операционную систему, на которой оно запускается. Это существенно сокращает затраченное время и количество разработчиков для поддержания разных платформ.

Дополнительным преимуществом Flutter является то, что он разрабатывается силами Google, обладающего значительными ресурсами. Для Google это проект имиджевый, они вкладывают в него финансовые средства и нанимают квалифицированных специалистов. Платформа регулярно обновляется, придается большое значение оптимизации. Flutter представляет собой серьезное решение, которое составляет значительную конкуренцию нативным приложениям.

Единственным минусом Flutter является то, что для разработки крайне специфических задач, не поддерживаемых экосистемой Flutter, придется прибегнуть к нативной разработке и коду. Однако 99% задач покрываются уже существующими плагинами и библиотеками.

Кроме того, стать серьезным разработчиком на Flutter проще, чем стать экспертом в области Data Science или фронтэнд-разработчиком. Это объясняется наличием обширного комьюнити, поддерживающего этот язык программирования.

На связи Иван Ярославцев, руководитель агентства разработки цифровых продуктов Alto. Мы готовим к запуску новое мобильное приложение, а перед публикацией кейса, хотим рассказать про технологию мобильной разработки Flutter.

А именно, почему Flutter пользуется такой популярностью у программистов и как он помогает экономить бизнесу миллионы рублей на разработке.

Компании используют мобильные сервисы для разных задач: улучшить качество клиентского обслуживания, привлечь больше заказов, автоматизировать производство или избавить сотрудников от рутинной работы.

Но главная цель — оптимизировать ресурсы.

По нашему опыту, Flutter — лучшее решение для этой задачи. Главная его фишка — возможность создавать приложения для iOS и Android, используя один язык программирования и общий код.

Почему заказов на кроссплатформенные решения становится все больше?

1. Цена на разработку. Экономия в среднем составляет 30-50% от нативных решений на Swift и Kotlin. Технология подходит для проектов с бюджетом до 6 млн рублей.
2. Сроки разработки. Использование общей кодовой базы для всех платформ сокращает время разработки на всех этапах. Например, первую версию приложения «Шампурико» мы разработали за 4 месяца.
3. Функциональность. Проработанность и гибкость фреймворка закрывает потребности большинства сфер бизнеса. Flutter-приложения создаются для e-commerce, фудтеха, B2B-продуктов и других направлений.
   
4. Поддержка. Развивать и поддерживать один продукт с общим кодом дешевле и проще, чем несколько параллельных приложений для разных платформ.
   

Почему программисты выбирают Flutter основным стеком?

1. Open-source библиотеки. Flutter сегодня — первый по популярности кроссплатформенный фреймворк. Под него написаны тысячи открытых библиотек, что позволяет быстро добавлять новые функции и возможности в проект.
2. Востребованность на рынке и обучение. Распространенность этого фреймворка открывает большие возможности для трудоустройства. Также для изучения Flutter разработаны сотни образовательных программ.

Мы опросили специалистов уровня middle и senior, которые дали свои комментарии. Вот, что они ответили.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики.

Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Язык

Очевидно, но всё же: начинать нужно со Swift. Это основной язык разработки для платформ Apple — iOS и macOS. За 10 лет с момента выхода он полностью заменил Objective-С. В целом iOS-разработчику полезно знать Objective-C, поскольку его всё ещё можно встретить в легаси проектов с историей, но основной инструмент всё же Swift.

Архитектурные фреймворки

Apple в своей документации по-прежнему рекомендует архитектурные шаблоны MVC, Model-View-Controller. Это первый шаблон, с которым столкнётся начинающий iOS-разработчик. Шаблон — это способ организации кода, призванный сделать его поддерживаемым, расширяемым и читаемым.

Интересно, что эппловский MVC несколько отличается от канонического, общепринятого. И кстати, многие крупные компании отказываются от MVC, поскольку он приводит к разрастанию кодовой базы, и код, напротив, становится сложным для чтения.

С этой проблемой можно работать с помощью других архитектурных шаблонов проектирования, например MVP, Model-View-Presenter и MVVM, Model-View-ViewModel.

Библиотеки

UIKit и Swift UI

UIKit — фреймворк для создания интерфейсов в iOS. Он существует почти столько же, сколько сам айфон, и включает все компоненты пользовательского интерфейса — кнопки, текстовые поля, таблицы…

SwiftUI — более новый фреймворк, который позволяет верстать пользовательские интерфейсы в соответствии с актуальным декларативным подходом. В чём отличие декларативного от более старого императивного подхода?

Императивный подход предполагает, что мы пишем код приложения как инструкцию: за шагом 1 следует шаг 2 — и никак иначе.

При декларативном подходе мы описываем желаемый результат, без явного указания последовательности действий.

Как правило, декларативный подход делает код более читаемым и поддерживаемым. Это очень важно, потому что разработчик около 80 % времени не пишет, а читает код, разбирается в нём.

Пока UIKit и SwiftUI существуют параллельно — в том числе потому, что SwiftUI работает с версиями iOS от 13 и младше. Со временем UIKit уйдёт, как и язык Objective-C.

Core Data и SwiftData

Это инструменты работы с базами данных. Более новый фреймворк SwiftData создан на основе Core Data и предлагает более удобный и простой синтаксис. Кстати, SwiftData и Core Data могут использоваться одновременно.

GCD и async/await

GCD, Grand Central Dispatch — это механизм от Apple работы с многопоточным асинхронным кодом.

Если упростить, взаимодействие фронтенда и бэкенда устроено так: мы отправляем запрос и получаем ответ. Пока этот запрос идёт к серверу, а тот собирает эти данные и пытается нам их вернуть, может пройти 2-3 секунды. Если мы будем ждать выполнения метода — нам придётся на это время «заблокировать» приложение, остановить его работу для пользователя. Это плохо, так нельзя.

Потому и нужна асинхронность. GCD отвечает как раз за асинхронность, управляет очередями запросов, в нужные моменты создаёт и останавливает их.

При этом многопоточный асинхронный код тяжело поддаётся отладке. Баг, связанный с многопоточностью и асинхронностью, тяжело выявить и исправить.

Среда разработки

XCode — это «родная» среда разработки для создания приложений для iPhone, iPad, Apple Watch, MacBook и других устройств экосистемы Apple.

XCode включает в себя редактор кода, интерфейсные конструкторы, отладчики — словом, все инструменты, которые нужны для разработки и тестирования.

Любые существующие альтернативы — неофициальные, Apple их не поддерживает.

Система контроля версий

Конечно, нет разработки без какой-либо GIT, системы контроля версий. Когда разработку ведёт команда — а это любое количество разработчиков больше одного — необходимо хранить историю изменений. Например, чтобы в любой момент можно было откатить изменения и вернуть предыдущую версию приложения. Умение работать с GIT необходимо любому разработчику, независимо от платформы, для которой он пишет.

Чтобы ответить на вопрос, что надо изучать молодым разработчиками под iOS или тем кто хотят ими стать в 2024, надо для начала в кранце описать те изменения которые происходят сейчас в индустрии.

С приходом в массовое использование LLMs которые становятся все более полезными при разработке, на первый план будет выходить базовые знания и общее понимание того, что делать программист.

Все больше и больше будут цениться не те люди которые знают какие-то фреймворки или работал с определенными библиотеками, а те, кто хорошо понимает как построить хорошую архитектуру приложения, лучшие практики в разработке, знает алгоритмы и структуры данных, понимает как работает управление памятью на iOS и т.д.

На эту теоретическую базу уже необходимо накладывать практике по написанию приложений, во время которой и появится опыт работы с фреймворками, библиотеками и всеми остальными прикладными навыками, без которых приложение не написать.

Следующий важнейший момент - это максимально быстро постараться получить опыт работы в команде, ознакомиться с современными методологиями построения рабочего процесса, понимать что такое Agile, Scram, Code Review, парное программирование и т.д.

Еще я бы советовал на самом раннем этапе разобраться в том что такое Unit тесты, для чего они нужны и как их писать и стараться через боль и слезы писать их как можно больше в своих тестовых проектах. Этот навык автоматом заставит писать качественный код, а понимание покрытия приложения тестами даст огромный плюс для начинающего разработчика.

Ниже краткий гайд того как бы я рекомендовал выстраивать изучение iOS в 2024:

1. Потратить время на базовые знания в области алгоритмов и структур данных и изучение языка программирования Swift, понимать что такое массивы, множества, классы, структуры, перечисления и т.д. Этот пункт может быть очень тяжелым для начинающего и поэтому я бы рекомендовал не тратить на него много времени с самого начала, чтобы не потерять мотивацию, а возвращаться к нему и подтягивать знания во время остальных пунктов.
2. Начать изучать SwiftUI и жизненного цикла приложения в iOS, начать писать первые очень простые приложения, которые позволят продолжать тренировать и прокачивать пункт No1.
   
3. Почитать про архитектуру приложений, паттерны проектирования (базовые из них). Изучать и самое главное постараться максимально понять на примерах, что такое SOLID. На этом этапе можно взять свое тестовое приложение с предыдущего этапа и переписать его используя лучшие практике.
   
4. Освоить системы контроля версий хотя бы на базовом уровне. Изучать что такое Git и как с ним работать, выработать привычку делать изменения своего кода в отдельных ветках и т.д.
   
5. Начать изучать сетевое взаимодействие, понимать что такое HTTP, как происходит взаимодействие с сервером, какие запросы бывают и т.д. На этом этапе я бы советовал взять любой открытый API и написать простейший клиент к нему использую URLSeession. Не надо искать библиотеке, которые помогут вам это сделать, попробуйте разобраться в тех фреймворках которые предоставляет Apple.
   
6. Немного покопать в сторону многопоточности используя пример с запросами к серверу, почитать про GCD и нативный Cuncurrency в Swift (Actors, async/await, etc.)
   
7. Если предыдущие этапы пройдены, и появилось базовое понимание того как работает разработка под iOS, можно смело переходить к сторонним библиотекам. Во-первых, надо изучить механизм подключения этих библиотек - Swift Package Manager (SPM). На данном этапе можно взять свое предыдущее приложение по работе с API и переписать сетевую часть на вариант с использованием сторонней библиотеки Alamofire.
   
8. Начать изучать Unit тестирование и постараться покрыть свое приложение тестами. В процессе покрытия тестами вы скорее всего обнаружите, что большую часть кода покрыть тестами не получается, и это отличный знак того, что надо вернуться к первым пунктам и более детально изучить улучшение архитектуры приложения.
   
9. Почитать про методологии разработки, работу в команде, Agile, Scrum и т.д.
   
10. Опционально: необязательно, но безусловно будет плюсом покопать также в сторону баз данных и работы с данными в iOS: SwiftData, Core Data.
    
11. Искать первую работу в этой области. Если вы действительно сможете пройти предыдущие 9 пунктов, напишете пару тестовых проектов, которые вы довели до конца, могу вас уверить, что вы сможете устроиться на начальную позицию в хорошую компанию.

Если есть желание попробовать себя в разработке приложений под iOS, то по большому счету на сегодняшний день существует несколько больших фреймворков для создания приложений. Например: от Apple – UIKit, SwiftUI. От Google – Flutter, от Meta – React Native. Остальные фреймворки или мало популярны или устарели (Например Cordova и PhoneGap, Ionic).

Существуют 2 вида разработки мобильных приложений: нативная и кроссплатформенная. Стоит отметить – для новичков предпочтительнее нативная разработка. В то время как кроссплатформенные подойдут для более опытных разработчиков. Нативная разработка избавит от изучения различий между платформами, позволит сосредоточиться на нюансах разработки мобильных приложений именно для iOS, а не распыляться на все платформы.

Итак, чтобы приступить к разработке своего первого мобильного приложения для iOS, необходимо сделать следующее:

1. Определиться с идеей и предполагаемым интерфейсом приложения.
2. Выбрать язык программирования, на котором вы будете писать код. Это может быть Swift или Objective-C. Но Swift предпочтительней, так как он имеет легкий синтаксис и Apple регулярно добавляет новые улучшения.
   
3. Выбрать фреймворк, который вы будете использовать. Более современный и легкий для обучения будет SwiftUI, это декларативный (описательный) фреймворк от Apple, или надежный и основополагающий UIKit, это более старый фреймворк, но использующийся в большинстве iOS приложений.
   
4. Установить среду разработки Xcode. Это необходимый в разработке инструмент, даже для кроссплатформенной.
   
5. Начать претворять в жизнь вашу идею!
   

По началу знаний и навыков будет не хватать. Поэтому полезно будет воспользоваться открытыми библиотеками и инструментами для iOS (вы легко можете их найти на github).

Из самых популярных библиотек стоит выделить:

1. Alamofire – для HTTP-запросов и только.
2. Lottie – какое iOS приложение без красивых анимаций?
   
3. RxSwift/Combine – для реактивного программирования.
   
4. SwiftDate – Для упрощения работы с датами. Работа на прямую с датами может вызвать множество вопросов особенно для новичков.
   
5. - Kingfisher/SDWebImage – для загрузки изображений.

Инструменты:

1. Git – инструмент для управления версиями вашего приложения. Для упрощения работы можно использовать графические оболочки – Fork, SourceTree и другие.
2. CocoaPods и Swift Package Manager – менеджеры для установки библиотек.
   
3. Firebase – сервис от Google, который поможет вести статистику и работать с БД.
   
4. Fastline – для автоматизации загрузки ваших кодов на AppStore.
   
5. TestFlight – чтобы устанавливать ваше приложение на телефон и хвастаться перед друзьями.
   

В мире постоянно меняющихся технологий важно быть в курсе текущих трендов и инструментов. В DigitMind Technologies мы акцентируем внимание на выборе современных и эффективных решений для разработки на iOS. Вот наши рекомендации по ключевым технологиям и инструментам, которые должен знать каждый начинающий разработчик в 2024 году.

Устаревшие технологии

В разработке на iOS есть инструменты и фреймворки, которые, несмотря на свою предыдущую популярность, становятся устаревшими. Например, RxSwift и SnapKit были незаменимыми инструментами для реактивного программирования и упрощения работы с AutoLayout соответственно. Однако с появлением SwiftUI и Combine, эти технологии уходят на второй план, поскольку новые инструменты предлагают более интегрированные и эффективные способы достижения тех же целей.

Библиотеки и фреймворки, которые нужно знать в 2024 году

1. SwiftUI полностью изменяет подход к разработке интерфейсов на всех устройствах Apple, предлагая более простой и мощный декларативный синтаксис. Это первое, что должен освоить начинающий разработчик, стремящийся к созданию современных и адаптивных приложений.
2. Combine играет ключевую роль в управлении асинхронным кодом и событиями в приложениях iOS, используя концепции реактивного программирования. Освоение этой библиотеки позволяет создавать более чистый и понятный код для работы с данными и событиями.
   
3. Swift Composable Architecture (TCA) предлагает структурированный подход к построению приложений, сосредоточиваясь на управлении состоянием и эффектами в декларативном стиле. TCA облегчает тестирование, поддержку и масштабирование приложений, делая его ценным инструментом для современного iOS-разработчика.
   

Важные инструменты разработки

1. Xcode остаётся неотъемлемой частью экосистемы разработчика на iOS, предоставляя все необходимые инструменты для разработки, отладки и распространения приложений.
2. Swift Package Manager значительно упрощает управление зависимостями, позволяя легко интегрировать и обновлять библиотеки и фреймворки в проектах.
   

В iOS разработке на сегодня есть два основных фреймворка для создания интерфейсов: старый добрый UIKit и более свежий и модный SwuftUI. И перед новичками часто стоит задача - какой же из них лучше изучать, чтобы быстрее найти работу?

Короткий ответ на вопрос - лучше знать оба. :)

Ответ подлиннее: как бы нам ни хотелось уже перейти на более современные технологии, проектов на чистом SwiftUI пока еще очень мало, и знание UIKit вам, скорее всего, понадобится. Поэтому я рекомендовала бы начать изучение именно с него. Однако знание SwiftUI точно добавит очков начинающему специалисту и поможет выделиться серди конкурентов. Даже не все опытные разработчики знают этот фреймворк, и если у компании есть планы постепенно его внедрять - знания SwiftUI, даже для начала не очень глубокие, точно очень помогут в карьере.

Еще, по моему опыту, много проектов сегодня используют фреймворки для реактивного программирования (в основном, Combine и RXSwift). Далеко не все джуны их знают, поэтому изучить их основы точно будет плюсом. Начать советую с Combine - это нативный фреймворк Apple, который, как мне кажется, постепенно вытесняет RXSwift.

Что касается базовых инструментов для разработки и командной работы - в 2024 году вряд ли что-то кардинально изменится. Уверенное пользование Xcode, git, основы работы с Figma - все это точно пригодится в любой команде.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики.

Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Вот, о чём идёт речь в ролике.

1. Спикер по имени Маюко ведет канал, где обсуждаются темы, связанные с технологиями, карьерой и жизнью.
2. Маюко анонсировала новую линейку товаров (мерч), доступную для покупки.
   
3. Она имеет шестилетний опыт работы iOS-разработчиком в Кремниевой долине и ранее активно рассказывала о преимуществах этой профессии.
   
4. Маюко решила поделиться и недостатками карьеры iOS-разработчика, подчеркивая, что нет идеальных технологий или профессий.
   
5. Она упомянула, что не все компании нуждаются в приложениях, что ограничивает возможности для трудоустройства iOS-разработчиков.
   
6. Не каждая компания, имеющая iOS-приложение, готова инвестировать в мобильную разработку, что также сужает спектр возможностей для разработчиков.
   
7. Разработка под iOS требует дорогостоящего оборудования (MacBook), что является финансовым барьером для многих начинающих разработчиков.
   
8. Интегрированная среда разработки Xcode, несмотря на свою интеграцию с продуктами Apple, может быть сложной в использовании и иногда дает непонятные ошибки.
   
9. iOS-разработка является нишевой технологией, что затрудняет переход к другим технологиям и языкам программирования.
   
10. Процесс публикации приложений в App Store требует прохождения проверки, что замедляет выпуск обновлений и требует строгого планирования релизов.
    
11. В сообществе iOS-разработчиков существует своего рода 'культ Apple', что может создавать неприятную атмосферу и ощущение эксклюзивности.
    
12. Маюко признает, что, несмотря на недостатки, она все еще любит iOS-разработку и продолжит заниматься ею, стремясь дать полное представление о профессии.
    

Ниже — транскрибированный перевод ролика на русский язык.

Как многие из вас знают, я работала в Силиконовой долине iOS-разработчиком в течение шести лет. И за последние два-три года на моем канале я много говорила о том, почему мне нравится разработка под iOS. И хотя я не жалею о выбранном мной пути карьеры, потому что он предоставил мне множество отличных возможностей, и я очень благодарна за них, и мне нравится создавать iOS-приложения, я также считаю важным говорить о недостатках, потому что после двух-трех лет гиперболизации разработки под iOS я чувствую, что пришло время рассказать о том, почему мне это не нравится, потому что ничто не идеально, вы знаете, нет идеальной технологии или идеальной карьеры, поэтому я просто хотела пролить свет на эту сторону. Если вы смотрите это видео, то, возможно, вы рассматриваете карьеру в разработке под iOS, или просто изучаете рынок труда и хотите узнать о плюсах и минусах всего этого.

К сожалению, лично я не могу дать много плюсов и минусов для всех остальных областей, потому что разработка под iOS - это все, что я знаю, но я надеюсь, что это поможет в любом случае.

Не всем нужно приложение

Итак, первый пункт заключается в том, что не каждой компании нужно приложение. Если подумать о всех платформах, сервисах и веб-сайтах, многим из них нужен веб-сайт, но не каждому нужно приложение для iOS и Android. И поэтому выбор карьеры в разработке под iOS означал, что мои возможности были ограничены в выборе места работы. Конечно, в 2020 году и в 2010-х годах большинство людей все равно хотели создать приложение для своего продукта. И поэтому это не было таким ограничением, но если сравнить количество вакансий в веб-разработке, например, с разработкой под iOS, то размеры совершенно разные. В то же время некоторые продукты лучше подходят для приложений под iOS, чем для веб-сайтов.

Так что здесь есть обе стороны медали, но я считаю, что для компаний более универсальным является желание создать веб-сайты перед созданием приложения.

Не всем нужны iOS-разработчики

Следующий пункт заключается в том, что не каждой компании нужно много iOS-разработчиков. Связано с предыдущим пунктом, даже если у компании есть приложение для iOS, это не обязательно означает, что им всегда хочется много вкладывать в мобильную разработку.

И это потому, что сценарий использования не всегда имеет смысл, или они не нашли такой, который имеет. Я начала заниматься разработкой под iOS в 2014 году, и на протяжении всего шести лет мне также приходилось бороться, чтобы убедить компании инвестировать в разработку под iOS. Всегда идет дебаты о том, что важнее, мобильное приложение или веб-сайт, что стоит приоритезировать. И часто мобильное приложение проигрывает. Честно говоря, я потратила немало времени на убеждение руководителей, продуктовых лидеров, что мобильная разработка стоит вложений, хотя я и инженер. Но как еще я буду иметь задачи, если не убежу людей важности этой работы?

Однако со временем ситуация становится лучше.

Все больше и больше компаний говорят: "Да, конечно, нам нужно приложение для этого". Или, знаете, они сразу делают ставку на мобильные устройства. Но, думаю, это стоит иметь в виду.

Быть iOS-разработчиком — это дорого

Следующая причина, почему мне не нравится разработка под iOS, и, вероятно, это мой главный минус, заключается в том, что быть разработчиком под iOS действительно дорого. Для тех, кто не знает, разрабатывать приложения под iOS и Mac приложения можно только на Mac, нельзя делать это на Linux или Windows, что означает, что для создания приложений под iOS вам нужен MacBook.

На рынке представлено множество продуктов от Apple с различными ценовыми категориями, но я считаю, что вам нужен как минимум MacBook Pro. Вы можете запустить Xcode на любом Mac, но если вы запустите его на, например, MacBook Air, он будет работать очень медленно.

Я считаю, что 13-дюймовый MacBook Pro имеет минимальные характеристики процессорной мощности для запуска всего. Кроме того, Xcode занимает почти 20 гигабайт места на вашем компьютере, поэтому это исключает многих людей, если Mac такие дорогие, и это то, что вам нужно для входа в эту область.

Так что финансовая нагрузка реальна. Это буквально исключает многих людей из числа потенциальных разработчиков под iOS, потому что не каждый может себе позволить Mac.

Вот почему вещи вроде веб-разработки набирают обороты намного быстрее, потому что любой человек с любым компьютером, независимо от своего финансового положения, может начать программировать. И Apple сознательно выбирает такие ценовые категории, и пока они не представят линейку Mac за двести-триста или даже пятьсот долларов, это будет крайне эксклюзивно. Так что это то, что мне действительно не нравится в разработке под iOS.

Xcode слишком сложный

Следующее, что мне не нравится, это то, что работать с Xcode довольно сложно. Xcode, для тех, кто не знает, является официальной средой разработки для iOS, созданной Apple. И это здорово, потому что она интегрирована на всех уровнях, Apple создает язык программирования, компьютеры, телефоны, среду разработки, фреймворки и все остальное.

Но иногда она просто не работает для меня. В сообществе разработчиков под iOS даже есть много шуток о том, как уговорить Xcode сделать то, что вы хотите. И по сравнению с некоторыми сторонними инструментами, она все еще лучшая, но это не делает ее более простой для работы иногда. Поскольку разработка под iOS требует процесса компиляции, времена компиляции могут быть очень долгими в зависимости от вашего компьютера. И иногда она выдает криптичные, труднопонимаемые сообщения об ошибках.

Иногда вам приходится очищать кэш. И вам приходится перезапускать компьютер и так далее, так что это просто часть разработки под iOS, и я бы хотела, чтобы это работало немного проще, но ни один инструмент разработки не идеален, так что, думаю, это то, что у нас есть. Тем не менее, это все равно попало в мой список причин, почему мне не нравится разработка под iOS.

Разработка под iOS слишком нишевая

Разработка под iOS - это своего рода узкая технология, поэтому, я считаю, что ее довольно сложно перевести на другие технологии, которые существуют. Мое впечатление о веб-разработчиках и других разработчиках заключается в том, что им довольно легко или относительно легко освоить другие виды технологий и языков программирования. Но потому что разработка под iOS - это закрытая экосистема, и вещи меняются, но не слишком радикально, это просто сложнее сменить карьеру и перейти, например, в разработку фронт-энда. Так что если вы выбрали путь разработчика под iOS, вы не можете просто так переключиться на другие вещи. Но, я имею в виду, iOS все равно узкая область. И я говорю это потому, что используемые в iOS и Swift шаблоны исторически очень, но, да, становится все сложнее и сложнее, я чувствую, освоить другие вещи.

Но, да, это все равно, я имею в виду, это все равно узкая область.

Деплой — это боль

Следующее в списке, что, я знаю, это действительно большая проблема, с которой сталкиваются все разработчики под iOS, - это то, что вы не можете развертывать вещи в любое время.

В отличие от веб-разработки, где вы можете развертывать тысячи вещей в день и развертывать в любое время суток, это не так для разработки под iOS. И это потому, что у нас есть процесс проверки в App Store. Apple ввела это, чтобы обеспечить уровень качества и безопасности для всех приложений, которые у них есть в App Store для своих пользователей, что замечательно.

Я считаю, что это хорошо. Это означает, что вы не можете загрузить вирус, если загрузите приложение из App Store.

Но для разработчиков это означает, что вам придется проходить процесс проверки с Apple каждый раз, когда вы захотите обновить свое приложение. Краткий обзор заключается в том, что вы отправляете бинарный файл в Apple, они проверяют его примерно за день или два, а затем могут принять или отклонить. И если он принят, то вы можете опубликовать его. Но если он отклонен, вам придется много раз общаться и пытаться исправить проблему. И вам придется следовать всем рекомендациям по проверке магазина приложений.

Так что да, то, что вам приходится ждать день, чтобы Apple занялась вашим приложением, делает весь этот процесс намного длиннее. Итак, вам придется как-то планировать свои релизы. И это также означает, что если вы выпустите производственную ошибку, то, черт возьми, она будет там, знаете, по крайней мере полдня.

Так что да, вам просто нужно быть более осторожными.

iOS-разработчики странные

И наконец, на последнем месте, и я не очень знаю, как это передать, но я подумала, что должна это сказать, это то, что разработка под iOS как бы немного камповая, что, возможно, все разработки как-то таковы, но мне кажется, что особенно iOS-разработка.

И я имею в виду, я думаю, что дело в том, что это Apple, знаете, многие почитают Apple. И иногда в сообществе разработчиков под iOS кажется, что они так почитают Apple, что это похоже на религию или культ, и это просто как-то странно, это как будто Apple - это бог, который меняется и выпускает обновления, и вы всегда просто, как, о, боже, Apple, это так удивительно, это так здорово, или вы всегда критикуете его за то, что он не сделал, и это просто, как, успокойтесь, это просто компания, и некоторые продукты, есть такие вещи, как соперничество с Android, и я просто, как, парень, кому это важно?

Люди будут использовать тот телефон, который им хочется. И да, возможно, это имеет значение в бизнес-мире, но разработчикам под iOS нет смысла возмущаться из-за того, кто лучше и кто хуже. Все существует по какой-то причине, и нет лучшего или худшего. Так что просто оставьте это.

Это не так уж и важно, понятно? Так что да, из-за этого своеобразного культурного аспекта разработки под iOS и финансового барьера, который вам придется преодолеть, чтобы стать одним из них, это не всегда самое гостеприимное место. Я имею в виду, есть множество отличных ресурсов, разработчиков под iOS, учебных пособий и учителей и веб-сайтов и ресурсов, которые очень гостеприимны.

Я могу назвать несколько и оставлю их в описании ниже. Но да, некоторые аспекты этого просто какие-то странные, и я просто, почему? Почему вы должны быть такими? Но да, это, вероятно, можно сказать и о всех других разработках и технологиях. Это просто, я имею в виду, это также присуще сообществу Apple. Так что да, вот так.

Надеюсь, вам понравилось это видео, и вы услышали немного моего личного мнения, если вы используете мое, почему я не люблю разработку под iOS. Люблю ли я ее все еще? Да.

Буду ли я продолжать это делать? Конечно. Но да, как я уже сказала, я хочу, чтобы вы все получили полное представление о том, что это не такая идеальная технология. И, возможно, вы это уже знали, но я просто хотела поговорить из своего опыта, как я делаю на остальном этом канале.

Подробнее, что же будет популярно в 2024 году, на какие технологии стоит делать ставку, расскажет Анна Жаркова, руководитель группы разработки компании Usetech, мобильный разработчик с опытом более 10 лет, эксперт Mobile Broadcast и Skillbox, а также член программных комитетов Mobius, Codefest и DevFest (Омск).

Искусственный интеллект

Начнем мы с самого популярного и многообещающего направления, а именно с использования систем Искусственного Интеллекта. McKinsey Global Institute пишут о возможном увеличении прибыли компаний на $4,4 триллиона в год благодаря ИИ. Кроме того, бизнес чаще начинает внедрять генеративный ИИ в повседневные приложения.

Технологии ML давно используются в мобильной разработке. Это и различные библиотеки для распознавания и поиска изображений, сканирования и распознавания текста, работы с видео, звуком. И встроенные возможности софта для разработки приложений, которые помогают делать код лучше, бороться с утечками памяти и т.п. Та же самая технология FaceId использует в своей основе инструментарий ML.

С конца 2022 года отмечается настоящий всплеск по разработке систем ИИ. На данный момент нейросеть ChatGPT занимает первую строчку в рейтинге технологий генеративного ИИ. В российском сегменте нельзя не отметить мощный аналог от компании Яндекс Yandex GPT. Компании планируют активно встраивать решения на основе нейросетей в свои приложения. Это может быть не только сбор и обработка информации для улучшения пользовательского опыта. Например, сбор и анализ информации позволит строить модели поведения пользователей, сценарии, на основе которых улучшать подбор рекомендуемого контента и т.п. Также это решение различных генеративных задач. Например, автоматический перевод текста, умное взаимодействие с пользователем.

В плане самой разработки ИИ может быть использован для генерации и оптимизации кода. Много споров вызывают такие вопросы, как: насколько качественные решения будут создавать системы ИИ, а также насколько безопасно использовать их для анализа кода приложений. Но перспектива использования таких решений, тенденция к их развитию, определенно, есть.

Кроссплатформа, Kotlin Multiplatform, Flutter

Технологии кроссплатформенной мобильной разработки под несколько платформ одновременно популярны уже довольно давно. На текущий момент самыми используемыми являются SDK Kotlin Multiplatform (KMP) от JetBrains и Flutter от Google. Оба решения активно развиваются, и без сомнения, в 2024 году порадуют новыми решениями. Кстати, JetBrains проводит ежегодный опрос по использованию Kotlin, который доступен по ссылке.

Осенью 2023 года произошло то, чего ждали многие разработчики и почитатели технологии KMP. Технология перешла в статус Stable и стала полностью готова к полноценному использованию. Это означает, что многие, актуальные для Alfa и Beta версий SDK проблемы, были решены. Например, улучшили поддержку Kotlin/Native, работу с многопоточностью, памятью и т.п. Одной из целей роадмапа на 2024 год сформулировали реализацию прямого взаимодействия между языками Kotlin и Swift. Несмотря на то, что разработчики Google являются авторами конкурирующего продукта Flutter, компания официально делает большую ставку на KMP. Поддержка кросс-платформы включается во многие решения. Так что советуем присмотреться к данному продукту.

Еще одним трендом связанным с кроссплатформенной разработкой является использование Compose Multiplatform для реализации кросс-платформенного UI. Данный декларативный фреймворк объединяет такие технологии как Compose for Desktop, Compose iOS, Compose for Web, а также Jetpack Compose для Android, и позволяет быстро и относительно просто создавать общий UI для разных платформ. В 2023 году вышла альфа-версия Compose для iOS. В 2024 году ожидается выход Бета-версии, в которую войдут улучшения по работе с нативным UI iOS, а также поддержка кросс-платформенного решения для навигации.

В общемировых тенденциях мобильной разработки сохраняется популярность таких решений, как React Native, гибридной разработки на Cordova и ionic, а также Xamarin. Также сохраняется тренд на PWA разработку,

Российская разработка, импортозамещение

Еще в 2022 году возникла потребность в собственных решениях для импортозамещения, а также развития отечественных технологий. Одним из самых актуальных направлений мобильной разработки становится разработка под Aurora OS. Если сначала попробовать устройства под ее управлением могли в основном участники специальной бета-программы и энтузиасты, помогающие компании OMP в разработке и улучшении продукта, то уже осенью 2023 года смартфоны и планшеты на Aurora OS становятся доступны для приобретения для всех желающих. Готовится к выходу 5 версия OS с поддержкой встроенного магазин приложений на RuStore. Многие российские компании уже работают над своими собственными решениями с поддержкой Aurora OS.

Компания OMP также обновили и улучшили инструменты для разработчиков. Предлагается использовать не только QT/QML/C++, но и специальную версию Flutter для разработки под Aurora. Так что здесь стоит отметить сочетание двух трендов мобильной разработки.

Определенно, стоит уделить внимание платформе Rosa Mobile. Данная ОС была заявлена как замена Android, и освоить разработку приложений под нее, было бы весьма нелишним.

Также актуальным трендом остается переход на отечественные сервисы. Например, решения от Yandex для сбора метрик, карты, погода и другие SDK. Замена сервисов Firebase сервисами RuStore (те же пуш-уведомления).

Нативная разработка

Технологии и фреймворки меняются, нативная разработка остается. Это основа основ, база, которую должен знать каждый разработчик. Использование родных языков и инструментов, как и подхода Native First, будет актуально всегда. К тому же для реализации проектов со сложной логикой, сложным UI, стоит выбирать именно нативную разработку.

Ежегодно разработчики платформ iOS/Android, а также языков Swift и Kotlin, выпускают много новых и интересных решений, про которые рассказывают на тематических конференциях WWDC и Google I/O.

Особое внимание стоит уделить усиливающемуся тренду на декларативную разработку в мобильных приложениях. Фреймворки SwiftUI и Jetpack Compose активно развиваются, стабильно улучшаются, становятся более удобными и надежными в работе. Их все чаще используют в разработке приложений различной сложности. Много библиотек и готовых решений, заточенных под SwiftUI и Jetpack Compose. Можно сказать, что это новый стандарт мобильной разработки под Android и iOS.

Также стоит обратить внимание на дополнение мобильных приложений интерактивными виджетами, которые помогут привлечь внимание к приложениям и предоставить мгновенный доступ к ряду функций.

Виртуальная реальность

В 2023 году на конференции WWDC компания Apple представила одну из самых громких новинок — очки виртуальной реальности Vision Pro, работающие на платформе VisionOS. Разумеется, это далеко не самый первый такой девайс в мире, и подобные аппараты уже давно используются в игровой индустрии. Ставка делается на уникальные технологии иммерсивности, улучшенное качество звука и изображения. В рамках создания девайса были проведены масштабные разработки в области пространственных вычислений. Поддержка VisionOS была включена в такие инструменты, как: ARKit, RealityKit, Unity, RealityComposer и т.п. И инструментарий, и документация на данный момент доступны для всех заинтересованных разработчиков. Старт продаж самого устройства намечен на 2024-2025 год.

Недавно создатели Vision Pro сообщили о скором запуске магазина приложений для очков виртуальной реальности. А это значит, что в 2024 году нас ждет бум различных приложений для AR/VR устройств: игры, виртуальные примерочные, приложения для подбора интерьера, иммерсивный просмотр фильмов, прослушивание музыки и т.п. Кроме того, согласно Statista, к 2028 году число пользователей рынка AR и VR в мире достигнет 3674,0 млн пользователей.

Также и Google, и Apple уделяют большое внимание улучшению иммерсивного опыта пользователей и на стандартных смартфонах, часах и планшетах.

Не только смартфоны. IoT

Каждый год выпускаются новые различные устройства под управлением ОС Android, iOS. Это не только смартфоны и планшеты, но и часы, смарт-телевизоры, игровые приставки, фитнес-трекеры, компьютеры автомобилей, а также устройства системы “умный дом”. Компании-разработчики ОС заинтересованы не только в поддержке новых возможностей устройств и гаджетов, но и улучшении инструментария для сторонних разработчиков.

Использование NFC, Bluetooth в приложениях по-прежнему остается актуальным. Yahoo Finance прогнозирует рост в области NFC с 2023 по 2030 годы на 33,1 миллиарда долларов США.

Безопасность, улучшенная работа с сетью

Сохранение конфиденциальных сведений было и остается одной из главных задач разработчиков. Об этом свидетельствует прогноз Gartner. Внедрение усиленных мер безопасности (аутентификация по биометрии, использование блокчейн и т.п) весьма актуальны и в 2024 году. Также особое внимание следует уделять стабильной и безопасной работе с сетью, в том числе и работе с облачными сервисами, с NFC, при подключении к другим устройствам. Современные мобильные ОС предлагают широкий спектр нативных средств для реализации и поддержки безопасной работы приложений.

Подведем итог

В 2024 мобильные платформы, языки и инструменты разработки продолжат свое развитие. Основными направлениями, на которые мы рекомендуем обратить внимание, будут являться:

• нативная разработка;
• кроссплатформа;
• разработка под различные мобильные устройства, IoT;
• поддержка и использование российских технологий;
• безопасность, работы с сетью;
• AR/VR.

Successful app localisation demands a well-crafted strategy and technological support, thus we have prepared a guide describing the key steps and concepts of the process.

What is localisation

Before we go further into the discussion of the localisation process, let’s clarify the distinctions among translation, localisation, and internationalisation—terms often used interchangeably. While they may sound synonymous, each carries its distinct meaning.

Translation, executed by either human translators or machines, involves replacing words from one language with their equivalents in another, aiming to maintain the same meaning (what is being said).

Localisation, on the other hand, goes deeper, incorporating cultural nuances and norms to capture not just what is being said but also how it’s expressed.

Serving as the technical backbone for translation and localisation, internationalisation is a task handled by developers.

In this article we mainly will dwell on the process of localisation.

Reasons to localise your app

Though English is often regarded as a universal tool bridging diverse native languages, recent research challenges this assumption by revealing a strong user preference for content in their own language.

The “Can’t Read, Won’t Buy” report shows that 65% of respondents prefer content in their language even if it’s poor quality. This report draws insights from a survey conducted by CSA Research, involving 8,709 consumers across 29 locales. As you can see, localisation is essential if you plan to scale the business. Below are the advantages it offers.

Expanding Market Reach

App localisation serves as the cornerstone for venturing into new markets. It can help your business evolve from a startup to an enterprise level. Thus, for example, the Arab audience due to the significant number of Arabic script users, makes it the third most written language globally. With around 660 million people across 22 countries using Arabic, language and UI directionality (right-to-left) localisation can become a game-changer for a business.

Enhancing App Engagement

Users value app content tailored to their preferences and requirements, significantly impacting their overall experience. Tailored content not only boosts engagement but also fosters loyalty among users.

Driving Sales Growth

A strategic investment in localisation leads to a substantial market share increase in each new country entered, consequently elevating revenue streams.

Amplifying App Downloads and Visibility

Researches prove that app store descriptions written in the local language can enhance app downloads by up to 38%, underscoring the importance of localised content in increasing visibility and user adoption.

Localisation Types

There are several strategies of app localisation that can be used depending on the specific objectives and resources. The two primary approaches are Minimum Viable Localisation (MVL) and Full App Localisation.

Minimum Viable Localisation

MVL focuses on localising key features, app store descriptions, and metadata, making it suitable for early-stage swift market entry. The launch of Evernote in China serves as a great example of MVL, where the note-taking app successfully adapted crucial elements to the local market, achieving success with a simplified product and Chinese branding.

Full App Localisation

Full App Localisation is a comprehensive approach that suits more global companies committed to maximising reach and revenue.

Here are a few examples of companies that have effectively implemented app localisation and benefited from it.

WhatsApp — the popular messaging app that supports multiple languages, regional dialects, and cultural nuances to cater to its diverse user base across the globe.

Netflix — a streaming giant, not only offers a variety of subtitles but also produces original content in different languages.

Duolingo — a language learning app itself, Duolingo employs effective localisation strategies. It tailors language courses, interfaces, and content to suit the preferences and cultural contexts of users in various regions.

Apple Maps is another example of an app that enhances user experience through localization. It not only provides directions and maps in local languages but also displays familiar logos of subway systems to users and even adjusts its language to respect local conventions, such as using “boarding lines” in London and “boarding trains” in New York.

Uber — the ride-sharing platform Uber has successfully localised its app to accommodate different languages, payment methods, and cultural norms in various countries. This has contributed to its widespread adoption across diverse markets.

Each of these examples showcases how companies, regardless of their industry, can benefit from thoughtful app localisation to connect with users on a global scale.

Building a strategy

Creating a successful app localisation strategy is crucial for reaching a broader audience. Considerations for this may include:

1. Identifying target markets

• Research potential markets based on demographics, user behaviour, and market demand
• Evaluate competition and identify regions where your app could gain traction

2. Understanding cultural nuances

• Adapt content to cultural preferences, language variations, and local customs
• Be mindful of cultural sensitivities to avoid unintentional misunderstandings

3. Deciding on a launch approach (regional or global)

• Choose between a phased regional launch or a simultaneous global release based on your app’s scalability and target audience

4. Setting a budget

• Estimate costs associated with translation, cultural adaptation, and technical adjustments
• Consider potential return on investment (ROI) and allocate resources accordingly

5. Prioritising localised elements

• Identify crucial app elements for localisation, such as user interfaces, content, and marketing materials
• Prioritise elements that significantly impact user experience and engagement

6. Gathering resources

• Collect all necessary assets, including text, images, videos, and other content requiring translation or adaptation

7. Assigning responsibilities

• Clearly define roles and responsibilities for team members involved in the localisation process
• Ensure accountability and effective communication among team members

8. Involving stakeholders

• Engage stakeholders, including marketing, customer support, and development teams, to align goals and expectations
• Seek input from local teams or partners for market-specific insights

9. Establishing a timeline

• Develop a realistic timeline that accommodates the complexities of translation, adaptation, and quality assurance
• Set milestones and deadlines for each phase of the localisation process

10. Selecting language service providers

• Choose reliable language service providers (LSPs) with expertise in your target markets
• Evaluate their track record, linguistic capabilities, and industry-specific experience

11. Fostering collaboration among teams

• Encourage seamless collaboration between development, design, marketing, and localisation teams
• Implement tools and communication channels to streamline cooperation

12. Monitoring the process

• Implement monitoring mechanisms to track progress, identify bottlenecks, and address issues promptly
• Regularly review key performance indicators (KPIs) to ensure alignment with goals

13. Choosing an app localisation platform

• Evaluate localisation platforms that suit your app’s requirements and scale
• Consider features such as integration capabilities, ease of use, and support for collaborative workflows

14. Defining metrics and KPIs

• Establish key metrics and performance indicators to measure the success of your localisation efforts
• Monitor user engagement, downloads, and revenue generation across different markets

These considerations collectively contribute to creating the app localisation strategy that can provide a successful and culturally sensitive expansion into diverse markets.

Tips and Tricks to Ensure Smooth Localization

As we have already discussed, localising your mobile app involves more than just translation—it’s about creating a seamless experience tailored to different cultures and languages. Here are some tips and tricks to guide you through the process:

1. Anticipate Text Expansion or Contraction

• Different languages may alter text length. For instance, translating from English to German can result in a 20-35% text expansion, while English to Swedish may lead to a 20-35% contraction
• Plan for flexibility in your design to accommodate varying translations. Tools like Figma and Lokalise can assist in this process

2. Support Right-to-Left Languages

• Languages like Hebrew and Arabic are written from right to left. Neglecting this can distort your design and lead to bugs
• Choose tools, such as Lokalise with Sketch integration, that support right-to-left languages to maintain design integrity

3. Provide Context to Linguists

• Replace traditional spreadsheets with special tools, enabling linguists to translate with contextual screenshots

4. Maintain Consistency with a Glossary

• Develop a glossary and style guide to ensure consistent translations
• Use Transifex, Lokalise, or POEditor to set up project-specific glossaries, defining terms and specifying translatability and case sensitivity

5. Test Cultural Imagery for Better Customer Experience

• Enhance customer experience by ensuring cultural familiarity and avoiding confusion or offence
• Test content and UI/UX culturally before a full release, incorporating feedback from select customers, champions, and native speakers during Beta testing

6. Use Locale Alongside Language

• Consider regional differences by using locale settings alongside language codes (e.g., fr_be for Belgian French)

Remember, the success of app localisation goes beyond translation. It’s about crafting an experience that resonates with users globally. By integrating the practices mentioned in the article into your app’s life cycle, you can deliver an inclusive and engaging user experience, transcending language barriers and reaching new heights in the global app market.

Добрый день, меня зовут Инна, я андроид-разработчик, хочу написать о своем приложении Nocta Pro. Создание его началось осенью прошлого года, а опубликовано в Google Play оно в конце августа. Возможно, статья получится интересной для тех, кто пишет свой проект или задумывается о нем. Она о том, как проходила разработка.

Идея

У меня большой опыт в разработке. Больше всего нравилось писать под Android. Но жизнь сложилась так, что в последние полтора года на работе вначале попросили писать под iOS, потом освоился React Native. Но мне захотелось вернуться обратно в Android мир. Вначале отдохнуть от работы, т.к. она в то время была достаточно тяжелой, а потом подкачать свои устаревшие знания. И это лучше всего делать на реальном проекте.

Мой опыт показывает, что самое главное в приложении — это UI и UX. Будь оно сто раз полезно, но если будет выглядеть коряво, то обречено на провал (потом я подкорректировала это мнение, но об этом позже). И мне очень повезло с тем, что нашелся человек, его зовут Ярослав, он начинающий продуктовый дизайнер, у которого была идея и который уже набросал свою задумку в Figma. Мне оставалось только спросить — не хотел бы он, чтобы его проект был реализован? По ходу рассказа привожу комментарии Ярослава ниже курсивом.

Приложение

Nocta представляет собой трекер подписок. Сейчас почти у каждого есть какие-то регулярно оплачиваемые подписки. Некоторыми мы пользуемся всего один раз в пробный период (их необходимо вовремя отключить), а некоторые используем постоянно. Также у поставщиков подписок бывают разные тарифные планы (еженедельные, ежемесячные, годовые, да хоть каждые два дня) — их можно прикинуть и сравнить, какой выгоднее использовать и посмотреть сколько ты в результате экономишь, сколько будет заплачено денег всего и по каждой подписке, и можно легко переключаться на другие планы.

Ярослав: Идея такого приложения мне пришла в голову еще в далеком 2020 году, однако реализовать его не представлялось возможным из-за нехватки опыта, знаний и ресурсов. Что тогда, что сейчас, все представленные продукты на рынке содержат хотя бы один критический недостаток, который сводит на нет вообще весь смысл пользования таким трекером. Я горжусь Nocta потому, что в этом продукте решены сразу все известные недостатки и проблемы, и, более того, представлен ряд классных и полезных функций, которых вообще нигде нет.

Некоторые подписки могут быть в другой валюте. Есть Pay Upfront (Предоплата), что означает оплату подписки вперед на несколько циклов.

Ярослав: Pay Upfront – это классная и уникальная фича, которой нет ни в каком другом трекере. Она нужна, чтобы посчитать сколько денег нужно для того, чтобы оплатить подписку вперед на какой-то период. Особенно, когда бывают странные циклы списания – раз в две недели или раз в 30 дней. Ты оплачиваешь эту подписку и последующие уведомления приходят тогда, когда подходит следующая дата списания. Это удобная фича, которой лично я часто пользуюсь.

Как быстро попробовать приложение в действии

Нет ничего проще. Устанавливаете Nocta Pro и добавляете тестовые подписки. Проверить подходит оно или нет — можно за минуту, ничего не нужно делать сложного или разбираться как добавить подписку.

Ярослав: Когда я просматривал приложения, которые уже были, то каждый раз после установки я видел пустой экран, и для того, чтобы понять как им пользоваться, мне нужно было создавать подписки со множеством полей (это у нас в Nocte можно заполнить всего два поля – название подписки и ее стоимость). Поэтому пришла в голову идея для тех, кто только что установил приложение и хочет понять, подойдет оно ему или нет. Одним кликом добавляешь тестовые подписки и все – можешь рассматривать приложение со всех сторон. Таким образом, мы сэкономили много времени тем, кому приложение не подойдет.

Подобных интересных вещей в приложении еще много. Все максимально продумано.

Реализация

Я решила затянуть в приложение все новое, что было на тот момент — конечно же kotlin (до этого все мои больше 20 проектов были на java), современную архитектуру (MVVM), Jetpack Compose, Hilt, Compose Navigation, WorkManager, Glance Widget, Room, SqLite и т.д.

Начинать было тяжело. Экранов и логики нарисовано еще до начала реализации очень много. И чтобы преодолеть этот барьер — я просто решила попробовать сделать самый первый экран со списком. Это было ошибкой, нужно было рассмотреть все, что есть, и принять обдуманные решения. Потом, когда процесс уже встал на рельсы, я поменяла структуру базы данных, кое-что переделала, доработали requirements — автор идеи написал больше 30 страниц описывающих user flow и всяких расчетов, таблиц и правил, а также несколько таблиц в Excel, которые рассчитывали несколько сценариев с подписками, это очень помогло.

Ярослав: Мне пришлось написать документ, который я назвал – дизайн спецификации. Это сложная штука, в нем мне пришлось вводить такой язык – собственные термины и использовать их на протяжении всего документа, в формулах и т.д. Например, ППСГ – потенциально потраченная стоимость за год, которая для каждой подписки считается по своему. И оперируя этим словариком терминов я создавал этот документ, который получился объемным, мне понравилось над ним работать, хотя наверное его можно было бы сделать сильно лучше.

Ярослав: Еще пригодился Excel – файл. В нем были примеры подписок и все расчеты. Я его создал еще до реализации для того, чтобы использовать в эскизах экранов, чтобы они выглядели как можно правдоподобнее и были связаны друг с другом общей логикой. Позднее мы проверяли все данные с помощью этих расчетов.

Разработка достаточно сложная вещь, каждый день мы сталкиваемся с какими-то проблемами, которые нужно решать, недостатком знаний, которые нужно восполнять и т. д. У меня специфика работы была такая, что заказчик долго ждать не будет, поэтому если например задача не решается за 2 часа — я переключаюсь на что-то другое (а потом приходит решение) или принимаю решение делать не совсем оптимально, чтобы посмотреть на результат, а уже далее действовать в зависимости от общего мнения. Поэтому в некотором смысле — все приложение получилось таким компромиссом между попытками сделать хорошо и правильно, и продвижением вперед. Когда работаешь один — сложно сделать правильно с первого раза, что-то не получается, или просто пока не знаешь как сделать. Затем, уже спустя время, где-то находишь эти знания и рефакторишь код, исправляешь ошибки — когда это уже очевидно. Если буксовать и все время сомневаться — то весь проект рискует остаться недоделанным. У нас же была цель — Google Play Market — финальная точка, после которой можно выдохнуть.

Во время реализации дизайн в Figma был переработан, дополнен, уточнен и перепроверен.

Столкновение с реальностью

Ярослав: Как изменилась идея в начале разработки? Я столкнулся с тем, что разработчик пришел и сказал “нельзя”. В первую очередь это было связано с курсом валют. Первоначальная идея была такая, что курс валют приходит автоматически с накидыванием сверху полутора процентов банковских комиссий, потому что актуальный курс списания выше чем курс обменников. И тогда я подумал, что все, приложение не имеет смысла, но мы потом придумали, что можно заносить эти курсы вручную и даже напоминать обновить эти курсы.. и при этом убили двух зайцев – у пользователя всегда будут актуальные курсы валют и мы отказались от сервера. И даже я считаю это наверное плюс нашего приложения, т.к. если подумать , то автоматический курс валют не отвечал бы потребностям пользователя.

Ярослав: Еще один момент, который пришлось учесть, это использовать “темные паттерны”, к примеру уведомления, чтобы пользователь их не смахивал, а открывал и использовал приложение, чтоб Google не отозвал разрешение у приложения, нужно туда помещать интригу. Вначале было задумано уведомление “Через 3 дня спишется 100 рублей за подписку ХХХ”, а теперь “Скоро платеж” и чтобы узнать какой платеж пользователь должен нажать на уведомление и перейти в приложение, и таким образом поддерживается активность, в результате которой у нас с меньшей вероятностью отзовут разрешения.

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

Проект сейчас имеет 24 модуля. Для одного разработчика пет-проекта — это даже много, а когда хочешь попробовать, как оно получится — то вполне нормально для такого размера приложения.

UI

Приложение в классическом материальном дизайне. Я использовала библиотеку androidx.compose.material3. Для рисования интерфейса – Jetpack Compose. Сам дизайн продуман до мелочей, аккуратные отступы между элементами, паддинги тоже разные для оптической компенсации элементов в списке с точностью до пункта. Нами продумана вся дизайн система, она одинаковая — в Figma и перенесена в один из модулей приложения, легко найти и поправить, легко добавлять и использовать в любом месте. Есть система шрифтов, цветовая схема. Темная и светлая темы. Аккуратные картинки к каждой подписке пользователя. Иконки приложения для Monet в Android.

Ярослав: В самом начале Nocta планировалась как кейс для iOS и там было основных 20 экранов. Потом пришлось переделывать все экраны с учетом не только дизайна, но и с учетом логики того, как взаимодействуют окна, структура. iOS версия раньше смотрелась как-то прикольно, но теперь она устарела и Android версия выглядит значительно лучше. Кроме того, у меня прибавилось опыта, если я раньше мог пропускать экраны, которые содержат определенный стейт, то сейчас я сразу вижу, что экран должен содержать, какой стейт и как с ним взаимодействовать.

Я разработал UI kit, в нем содержатся – цветовая схема (светлая и темная), шрифты, и элементы дизайна, это как будто кирпичи, из которых формируются экраны.

Картинки к подпискам я пытался сделать лаконичными, чтобы не приходилось в них копаться, пытаясь выбрать то, что нужно. Я внимательно пролистал список иконок к андроиду в плагине Figma и выбрал те, который наиболее подходят для подписок.

Функционал

Это одна из самых сложных основ приложения. Оно содержит много расчетов с датами, много разных строк, которые обозначают эти даты, периоды. Для того, чтобы правильно их сделать – нам пригодился документ, где была бы описана вся логика, а также тестовые примеры

База данных

Самая легкая часть. Обожаю базы данных, делать их структуру и особенно — писать запросы. Поэтому у меня очень много что сделано запросами, а не простым вытаскиванием данных из таблицы и последующей обработкой с полным перебором. Sqlite классная быстрая база данных, возможности которой нужно использовать.

Уведомления

Ни для кого не секрет — Google с каждым выходом новой версии операционной системы ужесточает правила для приложений в плане потребления энергии или безопасности. И получается, что приложения, которыми пользуется владелец устройства — те имеют зеленый свет, а у остальных понемногу отбирают разные полученные ранее права. Наше приложение задумывалось так, чтобы пользователь вложил свое время вначале — заполнил данные по своим подпискам, установил нужные уведомления и в общем-то больше не обращался к приложению, просто получал уведомления о будущих платежах, чтобы оно его не беспокоило лишний раз, не надоедало, не раздражало. Но увы, такие приложения обречены на фактическое сокращение функциональности. Не будешь пользоваться — через месяц (а ведь есть подписки, которые оплачиваются раз в год!) не увидишь уведомления — ОС забирает разрешение и все. Открывать настройки, искать нужный пункт меню и приложение, включать уведомления — только одно перечисление этого уже вызывает раздражение.

Пришлось изменить текст уведомления. Вначале мы думали выводить текст «Следующий платеж 100 рублей через 2 дня по такой-то подписке». Теперь просто выводится «Следующий платеж через 2 дня». И нужно кликнуть на уведомление и откроется окно с подпиской. Увы, это неизбежная реальность.

Есть еще второй вид уведомлений – это напоминания пользователю уже в самом приложении. Напоминание сделать бэкап, или напоминание о том, что нужно разрешить системные уведомления.

Виджет

Еще один вариант решения проблемы с уведомлениями — сделать виджет, который будет показывать список нескольких ближайших платежей на экране. Если пользователь его поставит, то приложение будет периодически работать, пользователю не нужно будет в него даже заходить. Сделать виджет, который одобрит дизайнер, достаточно сложно, а сделать Glance Widget, по которому очень мало информации даже в документации — еще сложнее. Сделать его приемлемого размера на экране — уже задачка со звездочкой, т. к. в определенных версиях действуют одни правила, в более новых — другие и т. д. У нас виджет двух типов. Вначале я сделала более простой вариант — там кнопки быстрого доступа для открытия приложения, создания новой подписки или открытия календаря. А затем виджет с самыми ближайшими подписками.

Для виджета пришлось делать свою дизайн систему, т. к. используемый там «jetpack compose», на деле им не является, и пока что там нельзя сделать полноценную дизайн систему, т. к. он находится в разработке. Также там есть ограничения по использованию шрифтов и размеров, управлять ими как в приложении не получится, да и выглядит он в итоге на разных устройствах по-разному.

Как-то прочла замечание одного разработчика (спасибо ему), что после добавления кнопки установки виджета в самом приложении, его использование значительно возросло. Мы добавили такую же кнопку. Это и напоминает о том, что у нас есть виджет, и значительно облегчает его установку, сравните сами – легко ли найти виджет в длинном списке всех виджетов устройства, а затем искать ему место, или просто нажать на кнопку?

Перевод на русский язык

Это тоже было достаточно сложной частью. В приложении очень много различных фраз, которые отображаются на экране, обозначающих, например, период времени или количество чего-то («в следующем месяце», «через 2 года», «скоро», «каждый год») и очень много нюансов когда и что отображается. В английском языке все достаточно просто, там нет падежей, фразы строятся однотипно. При переводе на русский я пересмотрела многое, чтобы все правильно отображалось, но уже с целью на будущее, чтобы можно было переводить на другие языки.

Бэкапы

Как вы уже поняли, сервера у нас нет, поэтому отвечать за сохранность своих знаний должны сами пользователи. Я добавила удобную функциональность по создании бэкапа с данными, и восстановление данных из файла, так же приложение напоминает (как можно более ненавязчиво) что неплохо сделать бэкап. Некоторые операционные системы сами делают бэкап и при установке приложение — данные уже там.

Справочная система

У нас реализована и продумана справочная система, то есть в местах, где пользователю нужна поддержка в плане “что это такое?” – реализованы небольшие диалоги с подсказками, но есть и экраны, где объясняются фичи и концепции, что и для чего это нужно, как это работает, например, о функции Предоплаты.

Публикация в Google Play

Это тоже достаточно нетривиальная задача для человека, который давно там ничего не публиковал, т. к. все постоянно меняется. Я вначале решила, что опубликую приложение в Open Testing части. Она по сути ничем не отличается от Production, кроме того, что отзывы приватные, видны только владельцу.

Очень волнительно было ждать вердикта Google (и сейчас тоже волнительно). Интересный факт в том, что во время проверки приложения, Google также тестирует приложение и публикует его результат. Если находит баг — то предоставляется видео тестирования, при котором произошло падение. И один из интересных багов был найден и исправлен. Также, он проводит глубокий анализ со скриншотами на разных устройствах и широкий анализ приложения на адаптивность к пользователям с особыми потребностями.

Реклама

Ну а теперь о том, как изменилось мое мнение что важно для приложения. Увы и ах, без вложений в рекламу ничего не получается. Nocta получилась большое и красивое приложение, законченное, которым приятно пользоваться, со мной связалось несколько разработчиков (удалось «прорекламировать» только в чатах по разработке) и мы даже стали друзьями и делимся чем-то полезным.

Но реальность такова, что денег на это больше нет.

Планы

Ярослав: Не знаю насчет планов.. внутри приложения всегда можно добавлять, докручивать какие-то интересные фичи, тот же самый max-концепт, разделение на профили, теги, wizards, даже что-то безумное, какие-то сториз “а вы знаете, чтобы сэкономить на подписках, можно применить вот эту тактику”, добавить notification hub, с ним поработать, т.к. они у нас в разных местах возникают, разделить приложение max, basic, pro. Это в сторону фич, в сторону платформы – хотелось бы видеть приложение на iOS.

Вообще в планах у нас были две или три версии приложения. Одна — самая простая, для тех, кому нужна базовая функциональность. Вторая — Pro, платная, которая и была реализована и была выложена бесплатно. Но уже есть планы на дальнейшее развитие, продуманные фичи для добавления. Однако пока не знаю, будет ли продолжение (добавление крупных фич) в связи с тем, что сейчас получать доход от приложения уже сложно.

Конечно, было бы неплохо иметь сервер, сделать регистрацию пользователей и синхронизацию их данных, или, к примеру, автоматические курсы валют. Но освоение мною этих вещей это too much.

Небольшие доработки и добавления, изменения, конечно же будут. Сейчас, когда исправлены основные баги, я занята поиском новой работы.

Надеюсь, наше приложение понравится тем, кто любит такое ? Пожалуйста, пользуйтесь, присылайте нам свои пожелания, оставляйте оценки в Google Play Store, передайте ссылку своим друзьям, если знаете, что оно им понравится, мы благодарны вам за это.

1. Ссылка на Google Play Store;
2. Связаться с нами можно в телеграм;
3. Мой профиль и резюме.

Меня зовут Виталий Монастырев и в статье расскажу о процессе разработки AI фоторедактора GradCit, который умеет дорисовывать фон, позволяет редактировать черты лица, может создавать стикеры, заменять небо на фото и многое другое.

Идея проекта

Я достаточно давно занимаюсь программированием и мне хотелось попробовать свои силы в разработке собственного продукта. Считаю это достаточно полезным занятием, так как в процессе приходится развивать не только навыки разработки, но и маркетинга для продвижения приложения, планирования при принятии решений о добавлении нового функционала, тестирования и так далее.

Мне всегда нравилось делать фотографии на смартфон и я задумался, что можно попробовать сделать свой фоторедактор. С одной стороны, фоторедакторов в магазинах приложений сейчас и так много, но с другой — идея создания простого фоторедактора не выглядит суперсложной и кажется вполне реализуемой. Кроме того, можно для начала добавить какие-нибудь базовые фильтры для MVP-версии и далее наращивать функционал.

Базовая архитектура

Итак, с тематикой приложения определились. Теперь самое время подумать, что мы хотим в него добавить и какие компоненты нам нужны. Как я упомянул выше, для совсем базового функционала достаточно сделать обычные фильтры, которые можно накладывать на изображение. Однако, если мы хотим добавить приложению фишки, которые бы выделяли его на фоне конкурентов, то усилий потребуется чуть больше.

Сейчас очень активно развивается направление машинного обучения, с его помощью можно редактировать фотографии намного проще, чем раньше. Например, мы можем определять при помощи ML-алгоритмов различные элементы на фото автоматически и затем применять алгоритмы обработки. Но здесь стоит оговориться, что некоторые ML-алгоритмы достаточно ресурсозатратны и их не запустить на большинстве смартфонов. Для этих целей может потребоваться обработчик на стороне сервера, поэтому стоит предусмотреть этот момент в нашей архитектуре.

Следующий момент, который показался мне важным, это возможность делиться фотографиями. Безусловно, у нас есть различные мессенджеры и социальные сети, где мы можем публиковать свои фото, сторизы и прочее, но возможность публикации фотографий можно использовать в дальнейшем, чтобы проводить на основе приложения различные интерактивные конкурсы с аудиторией. Кроме того, мы получаем собственную независимую платформу, что в современном изменчивом мире является совсем не лишним.

Базовая архитектура в моем случае выглядит следующим образом:

Пройдемся по компонентам:

• Client — приложение, которое запускается на устройстве пользователя. В моем случае в качестве клиентов выступают приложения для iOS, iPadOS и macOS. Первая версия создавалась исключительно под iPhone и использовался язык Swift. Предвижу вопрос, почему не использовались языки для кросс-разработки, чтобы писать одно приложение под iOS и Android. Меня всегда смущала производительность таких приложений и возможность использования новейших инструментов. Также на выбор в пользу нативного языка повлияло и наличие различных инструкций и туториалов.
• Backend server — набор API, который отвечает за общение с клиентским приложением. Включает в себя методы аутентификации, работы с базами данных и ML server’ом. Backend server реализован на Spring.
• ML server — включает в себя ресурсоемкие ML-расчеты, которые невозможно провести на устройстве пользователя. Так как большинство ML-алгоритмов работают на Python, то сервер был реализован на Flask.
• Kafka — была использована, чтобы отгружать в нее информацию об уведомлениях, которые необходимо выслать на устройства пользователей. Это могут быть уведомления о том, что кто-то оценил фотографию, подписался на профиль, оценил фотографию и другое.
• Notification server — занимается отправкой уведомлений на устройства. Данные об уведомлениях забираются из топика Kafka. Реализован также на Spring.
• Redis — хранит кэшированную информацию о недавних запросах в оперативной памяти. Это позволяет быстрее возвращать ответ клиенту.
• MySQL — выступает в роли основной базы данных для хранения информации. Скорее всего в дальнейшем придется переезжать на что-то другое, но пока она справляется.

Интерфейс

Первая версия приложения разрабатывалась исключительно под iPhone, поэтому интерфейс был не заточен под перевороты и масштабирование экрана. В связи с этим на оптимизацию под iPad и Mac ушло несколько месяцев. Необходимо было предусмотреть повороты экрана, режим Split View, а также другие пропорции экрана.

Пользователю на главном экране доступны следующие вкладки:

• Камера. Позволяет сделать или выбрать фото из галереи и перейти к его редактированию.

• Карта. Выложенные фото при желании можно отметить на карте мира, которая является общей для всех пользователей приложения. Более того, для таких фотографий становится доступен режим AR. Если его выбрать, то на экране в режиме навигатора появляется расстояние и направление до места съемки.

• Лента. Доступны вкладки «Новое», «Топ» и «Подписки». Во вкладке «Новое» отображаются последние публикации, которые набрали минимальный рейтинг; в «Топе= отображаются недавние публикации с сортировкой по рейтингу; в «Подписках» соответственно подписки.

• Поиск. Позволяет находить пользователей, либо записи по хэштегу.

• Профиль. Здесь отображаются опубликованные фотографии, отметки на карте и опубликованные текстовые записи.

Добавлю небольшой комментарий относительно одной из основных проблем, с которыми я столкнулся при проектировании интерфейса. В моем случае пользователь может переходить бесконечное количество раз из одного ViewController в другой. Например: со вкладки ленты перейти на страницу записи, затем со страницы записи на страницу профиля, оттуда на страницу подписок, оттуда снова в профиль и так далее.

Каждый ViewController потребляет определенное количество оперативной памяти и если не заняться этим вопросом, то через N-количество итераций приложение вылетет с ошибкой по памяти. Для решения данной проблемы я реализовал инструмент кэширования страниц. При переходе со страницы на страницу сохраняется информация о последовательности переходов и о вкладках, закрытая вкладка удаляется из стека контроллеров. Отображаемая информация сохраняется в кэш. Размер кэша в оперативной памяти ограничен, поэтому информация также сохраняется в постоянную память устройства. Для того чтобы работали свайпы переходов (когда мы пальцем тянем от края экрана слева направо, чтобы открыть предыдущую страницу), при открытии новой страницы формируется предыдущая.

Реализованный механизм решает проблему утечки памяти, при бесконечном переходе по вкладкам. Возможно, есть способы, как это можно реализовать по другому и более просто, но я не нашел ничего похожего. Если кто-то сталкивался с подобными трудностями, то буду рад узнать как вы решали проблему в комментариях.

Возможности редактора

В редакторе доступно множество самых разных инструментов. При их интеграции стояла задача того, как совместить их работу между собой. Для этого используется своеобразная логика стека, где каждый эффект применяется последовательно к изначальному фото. Расскажу подробнее про функционал, который доступен в редакторе.

• ИИ маска. Позволяет отметить область на экране и задать prompt для замены фона. Дорисовка происходит на стороне сервера, так как требуется достаточно большое количество вычислительных ресурсов.

• Маска. Позволяет удалить лишний объект с фото. Для маски доступна возможность запуска модели прямо на смартфоне (при помощи Core ML), но при этом страдает качество изображения, поэтому пока модель работает также на сервере.

• Редактор лица. В данном режиме приложение распознает лица на фото и определяет отдельные элементы: глаза, губы, нос, рот и прочее. Далее происходит обработка с определенными элементами. Это может быть как добавление искажения поверх изображения, так и наложение фильтра.

• Замена неба. Инструмент определяет небо на фотографии и позволяет заменить его на выбранное изображение. Для большей реалистичности на фото накладывается дополнительный фильтр.

• Стикеры. В приложении доступны как стикеры по умолчанию, так поддерживается и добавление собственных стикеров. Добавить свой стикер можно через меню, либо нативно, перетащив его из фотогалереи.

• Замена фона. Модель машинного обучения автоматически определяет основной объект на фото и заменяет фон на выбранный.

• А также! Инструменты рисования, множество самых разных фильтров, HLS-настройка, рамки и многое другое.

Заключение

В статье я постарался описать общую архитектуру приложения, а также поделился самыми интересными возможностями редактора на живых примерах. На данный момент я продолжаю развитие приложение и постоянно добавляю новый функционал. Если у вас возникли какие-либо вопросы, либо пожелания, то я с радостью отвечу на них в комментариях.

Скачать приложение можно вот тут для iPhone и Mac:

А вот тут для iPad:

Содержание:

• О конкурсе
• Задание по направлению Android
• Моё решение
• Решение ChatGPT
• Звонок другу
• Комментарий победителя в номинации «Изящный код» и его решение

О конкурсе

Компьютерный код может написать любой разработчик. Красивый код пишут лишь единицы. Чистый, изящный, лаконичный, читаемый и понятный код, который работает без багов — это настоящее произведение искусства в сфере разработки.

Для участников стояла задача написать красивый код по одному из пяти направлений (Python, Java, Data Science, Front-end, Android).

Каждое направление предусматривало 3 номинации:

• Краса кода — решение, признанное максимально эффективным по мнению жюри;
• Изящный код — самое лаконичное решение, соответствующее поставленной задаче;
• Звезда кода — самое неординарное решение по общей оценке жюри.

Призы конкурса: iPhone 14, умная колонка и приглашение на вечеринку в честь Дня программиста.

Задание по направлению Android

Вводные данные:

Моё решение

Итак, нам нужно вывести список категорий и характеристик. При этом элементы в списке должны находиться разные типы элементов: категория, характеристика, концевик категории (её ID).

Первое, что пришло на ум — List. Это плохое решение, ведь так в этот список можно положить вообще всё, что угодно.

Я посмотрел, что объединяет входные дата-классы. Воспользовавшись nullable-свойствами, я создал общий дата-класс. В названии его я буквально написал, что он содержит.

Объекты этого класса будут наполнять результирующий список.

Дальше ничего не интересного: я просто воспользовался вложенными циклами.

С помощью именованных аргументов конструктора класса, в список сначала добавляется категория, потом все соответствующие характеристики, затем ID категории. Такое довольно простое решение.

Небольшая оптимизация:

В данном случае после добавления характеристики (feature) в итоговый список (categoriesWithFeatures), она удаляется из списка характеристик (mutableFeatures), поэтому следующая итерация цикла пройдёт быстрее, так как в списке будет меньше элементов.

Однако в данном случае необходимо создавать mutableFeatures (изменяемый дупликат списка features), что может быть неэффективно по памяти, если начальный список достаточно большой.

Эта оптимизация подходила бы, если входная функция возвращала изменяемый список:

После участия в конкурсе я нашёл конструкции языка и методы, которые позволяют улучшить код. Например, вместо моего дата-класса больше подошёл бы Sealed Class с тремя потомками: Категорией, Характеристикой и ID категории.

Решение ChatGPT

Я попросил ChatGPT решить поставленную задачу, и вот что он написал:

Моё решение лучше этого, потому что оно, как минимум, работает. Ура, моё решение лучше решения ChatGPT, плюс самооценка!

Что же делает наш умный товарищ:

• Пытается добавить элемент к неизменяемому списку (currentCategory?.features?.add(feature));
• Пишет комментарии в решении, которое должно читаться без комментариев.

Хорошо, давайте закроем на это глаза. Закрыли, но решение всё ещё плохое: оно не соответствует поставленной задаче:

• Основная функция в итоге возвращает список объектов CategoryWithFeatures. Этот класс содержит данные категории и список характеристик. Всё это он запихал в один класс. Теперь нет отдельных элементов категории, характеристики и ID категории, которые должны быть в результирующем списке по условию задачи.
• Его цикл работает только, если во входных данных характеристики идут строго по порядку: сначала характеристики одной категории, потом другой. В противном случае в цикле создаются дубликаты категорий.

Вот, что мы в итоге получаем:

Я также показал своё решение chatGPT и попросил его улучшить. Вот его версия моего решения:

Мой дата-класс он оставил без изменений и поменял саму функцию. Теперь сначала с помощью функции groupBy создаётся Map>, где ключи — ID категории, значения — списки характеристик. Потом всё те же вложенные циклы, только теперь нужные характеристики не нужно искать, а просто брать из созданного Map.

В итоге:

• Результат работы такой же;
• Вложенные циклы остались;
• Перед вложенными циклами появились: ещё один цикл от функции groupBy и дополнительная переменная;
• Код стал короче, но, как по мне, его читаемость не изменилась.

Звонок другу

Не получив фидбека от организаторов конкурса, я попросил его у друга. Вместе с фидбеком я получил ещё один вариант решения:

Я попытался переписать код, но в итоге сложность по времени получилась такая же. Пока что не придумал другого варианта.

Действительно, во втором цикле из-за функции addAll (которая циклически добавляет все элементы списка featuresFromMap) у нас снова получаются вложенные циклы. При этом читаемость кода снизилась.

К слову, весь первый цикл делает почти то же самое, что и функция groupBy. Разница в том, что groupBy вернёт Map>, а цикл — MutableMap>.

Мне не нравится моя мапа на самом деле. Я добавил список не фичей, а этого класса только из-за того, что не хотел дополнительно забивать память потом. Хотя мб я, кстати, неправильно посчитал, и такой вариант ничем не отличается. Короче, в промышленном коде так делать не стоит.

Комментарий победителя конкурса и его решение

Давид Жубрёв, победитель в номинации «Изящный код», разрешил опубликовать его решение:

Рассмотрим, что здесь происходит. Метод flatMap в соответствии с лямбда-функцией преобразует каждый элемент списка категорий в List, где первый элемент — объект категории. Список характеристик фильтруется по ID категории и преобразовывается в массив. С помощью оператора * каждый элемент массива вкладывается в упомянутый List. Последний элемент List — ID категории.
После этого flatMap избавляется от вложенных списков и возвращает одномерный список всех элементов.

Хоть в результате и получается List, решение очень лаконичное и понятное, что идеально соответствует номинации. По временной сложности всё остаётся так же, но выглядит лучше. Если добавить сюда другую структуру данных, например, тот же Sealed Class, то будет, возможно, лучшее решение поставленной задачи.

Победитель прокомментировал конкурс и своё участие в нём:

Я не возлагал больших надежд на победу, для меня это был, скорее, небольшой фан. Я был очень удивлен, когда мне написали о победе, но было крайне приятно)

Спасибо за прочтение данной статьи! Буду рад узнать ваше мнение о конкурсе и представленных решениях ?

Для кого-то успех измеряется прибылью и количеством загрузок, а для кого-то разработка приложения — это служение делу и стремление помочь людям. Это может быть достойным занятием и ради самого себя.

Так было с Рахулом Кумаром, который начал заниматься кодированием в 7 лет. В 2020 году из-за ограничений, связанных с блокировкой школы Covid-19, ему стало скучно сидеть в своей комнате, и он решил разработать приложение для iPhone до окончания школы.

Имея доступ к отцовскому MacBook, Кумар создал EmSafe — приложение для экстренных поездок, призванное помочь беженцам, иммигрантам, перемещенным лицам и тем, кто не знает английского языка, получить доступ к службам экстренной помощи в более чем 230 регионах мира.

До того как Кумар начал кодировать на Swift, у него был опыт работы с Java и Python, но он самоучка и не получал помощи от родителей.

«Когда я начинал, мне было трудно писать на этих языках, и я часто просто оставлял проекты незавершенными на несколько недель, потому что не мог легко найти конкретный ресурс для решения своей проблемы».

Его проект столкнулся с трудностями, когда он отправил его на внутреннее рецензирование в Apple. Хотя инструменты разработки и поддержка сообщества бесплатны, для того чтобы отправить приложение на рассмотрение и распространять его через App Store, необходимо зарегистрироваться в программе Apple Developer Program (99 долл. в год). Apple предлагает подробный набор рекомендаций, которым необходимо следовать для публикации любого приложения или игры.

«Мне приходилось постоянно устранять проблемы, которые находили специалисты App Review, например, проблемы с текстом кнопки или с отображением оповещения», — рассказывает Кумар.

Но он упорно продолжал работать и в итоге был выбран компанией Apple в качестве победителя конкурса Worldwide Developers Conference Swift Student Challenge в 2021 и 2022 годах. Кумар выпустил первую версию EmSafe в июле.

Впервые Apple выпустила Swift Playgrounds в виде приложения для iPad в 2016 году, а в 2020 году появилась версия для MacOS. Это бесплатное приложение позволяет редактировать код в одном окне и видеть, как он будет выглядеть в готовом приложении, в другом (в реальном времени).

Имеются встроенные уроки и задачи, которые можно пройти, а также загрузить примеры игровых площадок, чтобы посмотреть, как они работают. Программа предназначена для обучения основам с помощью наглядных примеров, а также для выявления ошибок в коде по мере его ввода. Можно создать приложение для iPhone полностью в Swift Playgrounds, но можно также экспортировать проекты в Xcode (полноценную среду разработки Apple).

«Apple предоставила множество руководств по кодированию в Playgrounds для начинающих, но через некоторое время мне понадобилась более подробная и продвинутая информация», — говорит Кумар. Он чувствовал, что ему не хватает опыта кодирования, необходимого для понимания плотной документации для разработчиков. «Основным способом обучения разработке приложений для iOS было изучение таких сайтов, как Hacking With Swift, а также поиск фрагментов кода на GitHub».

Бен Робинсон, молодой разработчик игры Anxiety Relief: Find Your Calm, рассказывает похожую историю. Он начал разрабатывать свое первое приложение для iPhone в 13 лет, но уже несколько лет изучал программирование.

Документация Apple поначалу казалась ему довольно пугающей. Если я не знал точно, как работает API (интерфейс прикладного программирования), то мне было трудно найти нужный компонент. Необходимо совершить ментальный скачок от процедурного мышления к абстрагированию кода и использованию объектно/протокольно-ориентированных конструкций.

Поначалу он запутался в том, что слишком буквально воспринимал все, что кодировал, и пытался реализовать функции, выполняющие слишком много операций. Но, по его словам, сообщество разработчиков iOS поддержало его и предложило множество ресурсов, которые можно было использовать. Как и Кумар, Робинсон нашел полезными учебные пособия Пола Хадсона «Hacking With Swift», в которых он знакомится с различными API-интерфейсами и побуждает его создавать на их основе различные вещи.

У меня не было знакомых разработчиков приложений, и когда у меня возникали трудности, я обычно полагался на те ответы, которые мог найти на Stack Overflow. Все разработчики-самоучки сталкиваются с этой проблемой, но это также сделало меня более выносливым и независимым. Я стал более уверенно логически мыслить и эффективно решать возникающие проблемы.

В дальнейшем Робинсон создал iOS-версию игры «Мафия» для игры с друзьями и надеется сделать карьеру в технологическом секторе. «Если у вас есть идея, действуйте! Никогда не знаешь, какая идея окажется той самой, которая взлетит», — советует он начинающим разработчикам. «Если ваша идея достаточно интересна, вы всегда сможете приобрести необходимые навыки, чтобы воплотить ее в жизнь».

Кумар поддержал эти слова, добавив, что лучше всего начинать с нескольких небольших проектов, ориентированных на то, что вам действительно интересно. Так вы быстро научитесь и будете иметь больше мотивации довести дело до конца. Он также советует потратить приличное количество времени на мозговой штурм и визуализацию приложения, прежде чем приступать к кодированию.

1. Java или Kotlin?
2. Начало работы
3. Система контроля версий
4. Android Architecture
5. Создание приложений
6. Продвинутая разработка
7. Заключение

Java или Kotlin?

Мы уже проводили сравнение Java и Kotlin, в ходе которого пришли к выводу, что оба языка важны. Так, без знания Java будет сложно разобраться в Kotlin, который всё ещё использует JVM. С другой стороны, Kotlin сделал большой шаг вперёд и ориентируется именно на Android-разработку, тогда как Java используется также для бэкенда, десктоп-приложений и Big Data.

Начало работы

Скачайте Android Studio и разберитесь с данной IDE.

Теперь настало время поближе познакомиться с выбранным языком. Если вы решили со старта взяться за Kotlin, имейте в виду, что документация предполагает хотя бы базовое знание Java.

Что Kotlin, что Java являются полноценными ООП языками, поэтому освойте принципы объектно-ориентированного программирования.

Изучите структуры данных и алгоритмы, подкрепите теорию практикой.

Скачайте систему автоматической сборки Gradle, потому как ручная сборка проектов с указанием нужных библиотек и фреймворков — процесс трудоёмкий.

Система контроля версий

Если вы ещё не работали с VCS, самое время начать. Изучите возможности и основные команды Git, выберите для себя один из веб-сервисов для хостинга проектов и попрактикуйтесь на первых репозиториях.

Android Architecture

Различные паттерны разработки позволяют повысить качество кода, сделать его более понятным и масштабируемым. К основных паттернам относятся:

• MVVM (Model–View–ViewModel);
• MVI (Model-View-Intent);
• MVP (Model-View-Presenter).

Подробнее о них можно узнать из статьи.

Создание приложений

А здесь самое интересное.

Activity в Android — это по сути окно приложения. Простые приложения состоят из одного окна, сложные — из двух и более. Жизненный цикл Activity включает в себя шесть коллбэков:

• onCreate() — создание активити;
• onStart() — подготовку к отображению на экране;
• onResume() — отображение на экране;
• onPause() — приостановку процессов;
• onStop() — состояние невидимости;
• onDestroy() — завершение работы.

Далее изучите создание гибких интерфейсов с использованием фрагментов и начните выполнять отладку с помощью Android Studio Debugger.

Для работы с компонентами используйте такие инструменты, как Room, Navigation, WorkManager, LiveData, Data Binding. Из сторонних библиотек будут полезны Glide, Retrofit, GSON и Firebase.

Разберитесь с Intent для взаимодействия между объектами Activity и объектом Context, который предоставляет доступ к ресурсам и другим объектам, в том числе к Activity.

Ну и как стать Android-разработчиком с нуля без практики? Следуйте инструкциям из данного видеоурока и подключитесь к NASA через API, чтобы получить доступ к фотографиям из космоса:

Продвинутая разработка

Продолжайте развиваться, осваивая безопасную разработку. Для тестирования подойдут фреймворки JUnit и Espresso, для управления зависимости — библиотеки Dagger и Koin. Дополнительно почитайте о параллелизме и многопоточности, узнайте, что это и как используется в создании Android-приложений.

Заключение

Так как же стать Android-разработчиком с нуля? Определитесь с языком программирования, научитесь работать с Android Studio, Gradle и веб-сервисом для хостинга проектов. Вам предстоит разобраться в основных паттернах и их отличиях, изучить создание гибких интерфейсов, а также подключаться к другим сервисам через API. Продвинутая разработка предполагает тестирование, управление зависимостями, работу с параллелизмом и многопоточностью.

Как и в случае с веб-приложением ChatGPT, воспользоваться языковой моделью на Android можно будет бесплатно. Стоимость подписки на ChatGPT Plus стоит $20.

Преимущество модельной версии ChatGPT заключается в том, что оно использует сервис Whisper от OpenAI для преобразования речи в текст.

Пока Android-приложение доступно только для пользователей из США, Индии, Бангладеш и Бразилии. С 31 июля OpenAI обещает сделать его доступным для других стран.

То же самое происходило, когда OpenAI выпустила приложение для iOS: сперва им могли воспользоваться только в США, и только потом ChatGPT стала доступна для остальных стран.

При этом PWA-приложение будет выглядеть как обычное приложение из AppStore или Play Market. Чтобы воспользоваться услугами, не нужно заходить в браузер на сайт банка или бояться, что магазин приложений удалит старую версию с вашего смартфона.

PWA-приложение (Progressive Web App) – это веб-приложение, которое похоже на нативное мобильное приложение, но разрабатывается и работает на базе веб-технологий, таких как HTML, CSS и JavaScript.

Основная идея PWA заключается в том, чтобы объединить преимущества веб и мобильных приложений. К примеру, PWA может кэшировать объекты и работать, даже если на устройстве нет интернета.

При этом PWA-приложение доступно для всех пользователей, вне зависимости от браузера и устройства. С точки зрения разработки, PWA позволяет не тратиться на создание приложений под разные браузеры, ОС и экраны.

iOS-разработка

Документация

Несколько лет назад от iOS-разработчиков требовали знать Objective-C, но сейчас обязателен только Swift. Язык активно развивается, а значит, перечитывать документацию придётся примерно раз в год.

Также важно изучить документацию двух фреймворков, на которых, как правило, ведётся разработка:

• Привычный UIKit, актуальный уже более 10 лет. Вопросы по этому фреймворку по прежнему входят в программу любого собеседования.
• Новый SwiftUI, который приходит на смену UIKit и активно дорабатывается и продвигается компанией Apple. Его знание пока не обязательно для прохождения собеседования, но привлечёт внимание работодателя.

Курсы и не только

• CS193p от Стэнфордского университета — Полноценный обучающий курс от ведущего мирового университета. Покрывает темы от основ до глубин. Раньше фокусировался на UIKit, теперь — на SwiftUI.
• Algorithms and data structures от Стэнфордского университета — Для тех кто в IT всерьёз и надолго. Подготовит к решению алгоритмических задач, которые задают на собеседованиях.
• iOS study DataSource by Slava Slutsker — Своего рода роадмап для iOS-разработчика. Много ссылок на книги, блоги, лекции, курсы, разбитые по уровням, скиллам и темам.
• Hacking with Swift — Более тысячи бесплатных советов, методик и обучающих материалов по Swift. Автор написал несколько книг про разработку для iOS, macOS, watchOS. Ведёт канал на YouTube.
• Artem Novichkov — портал, на котором Артём собирает собственные эксперименты со Swift. Например, как реализовать текст-спойлер как у Telegram на SwiftUI.
• Код Воробья — Портал с туториалами и разбором системных компонентов/приложений. В подвале сайта есть ссылки на их Telegram-канал и чат. В канале часто разбирают, как устроены те или иные системные приложения в iOS. А в чате можно задавать вопросы — там всегда помогут и объяснят.
• Материалы «Додо Пиццы» —  например, этот и этот.

Подкасты

• Podlodka — Уже прошло более 11 сезонов, в которых лучшие российские разработчики рассказали о применяемых подходах, лайфхаках и best practices. Еще здесь можно найти ответы на вопросы с собеседований (а зачастую и сами вопросы).

• Mobius — Лучшая русскоязычная конференция. В основном материалы для разработчиков уровня middle/senior. Много лекций по iOS с прошлых конференций доступны на канале.

Telegram-каналы для продвинутых разработчиков

• iOS Good Reads

• iOS.Devs

Каналы обзорные, авторские, полезны тем, что не постят много и делают выжимку за неделю/период. Существуют продолжительное время и имеют русскоязычных подписчиков, вместе с которыми вы сможете узнавать новое.

Когда я начинал учиться, старался изучать самые популярные ресурсы. Статьи на Хабр и Medium, записи конференций для разработчиков на платформах Apple Worldwide Developers Conference, официальную документацию Apple по SWIFT и её перевод от SwiftBook.

На Swiftbook вообще достаточно курсов для новичков (не бесплатных, но хороших). Правда, материалы по Swift постепенно устаревают, так что лучше не забывать про документацию. Хороший раздел Туториалы, где лежит много небольших статей о функционале.

Android-разработка

Освой Android играючи

Для тех, кто не понимает, что такое Android, как в него вкатиться и что делать. Здесь все представлено в лёгкой игровой форме, буквально с котиками. К тому же это «островок дружелюбия» в агрессивной среде программирования.

На платформе 34 бесплатных урока: как поставить саму Android Studio, как сделать первую программу и так далее — всё со скриншотами и на русском языке.

Stack Overflow

Тут можно найти разбор почти любого проблемного кейса. Так что сайт помогает, когда времени искать что-то в документации нет. Есть даже такая шутка в узких кругах: если он перестанет работать, разработчики перестанут выполнять свои задачи.

Полезные статьи и не только

• ​​Собеседование по Android — 250+ распространённых вопросов для джунов, мидлов и сеньоров (хотя, конечно, здесь собрано не всё). Понравилось разделение по градациям уровней. Я бы ориентировался на эту статью как минимум для первого собеседования, чтобы чувствовать себя более уверенным и подкованным.

После собеседований рекомендую записывать вопросы, на которые вы не смогли ответить — и после разбирать их. Так, вы сможете лучше подготовиться для других собеседований. Или даже вернуться через какое-то время в ту же компанию и сказать: я закрыл свои пробелы, хочу ещё раз пособеседоваться с вами — это нормальная практика.

• Вопросы и ответы для собеседования по Kotlin — Статья про Kotlin в целом, не только о платформе. Тоже будет полезна для прохождения собеседований.
• Java собеседование. Коллекции — На собеседованиях кандидатов любят погонять по коллекциям, поэтому советую статью на эту тему. Мне в своё время она помогла закрыть «пробелы» в теоретических знаниях.
• Для вдохновения рекомендую послушать ролики на YouTube и подкасты от представителей профессии: с чего они начинали, с какими сложностями сталкивались. Могу посоветовать интервью, где рассказываю о собственном пути в Android-разработке.

Важный совет — уметь гуглить на английском языке. На русском информации по теме не так много.

И немного про базы данных

Если вы уже освоили базу, можно попробовать усложнить свои проекты, и добавить в них, например, БД. И для этого понадобится знание новой темы —  SQL.

Для практики я советую начинающим специалистам SQL-EX. Он простой и достаточно популярный, подойдет и для разработчиков, и для аналитиков — всех, кому нужно попрактиковать SQL. В своё время я использовал этот сайт-задачник для оттачивания навыков по работе с SQL.

Когда человек проходит какой-то курс, ему часто не хватает именно практики, чтобы уверенно и бегло писать запросы. А после — показать навык на собеседовании, получить оффер и спокойно работать. И этот сайт как раз решает проблему.

Ещё посоветовал бы телеграм-каналы, которые ведут сами действующие специалисты. В них часто встречаются разборы кейсов из реальной практики, разборы тестовых заданий и ошибок, советы по прохождению собеседований.

Как лучше организовать обучение

• RTFM. Читайте документацию в первоисточнике.
• Обязательно пишите код, много кода. Для этого заведите себе в GitHub пет-проект. Например, простое приложение для показа новостной ленты/погоды/галереи изображений.
• Перенимайте опыт у экспертов.

Вне зависимости от выбранного пути собственно разработка — это лишь один из этапов создания приложения. Я разделил этот процесс на 6 основных шагов, в которых расскажу, что делать на старте, как оценить затраты, какие способы разработки оптимальны для вашего бизнеса и какие нюансы нужно учитывать, чтобы создать эффективное приложение.

Шаг 1. Определите бизнес-задачу

Первое, что необходимо понимать перед созданием мобильного приложения — то, что это не игрушка или дань моде, а рабочий инструмент, направленный на решение конкретных целей бизнеса. Причем инструмент достаточно дорогостоящий. Поэтому создавать приложение имеет смысл в том случае, когда оно будет способствовать решению вашей бизнес-задачи.

Приведу несколько примеров, когда разработка приложения оправдана: вы хотите увеличить охват целевой аудитории за счет активных пользователей мобильных устройств, упростить процессы покупки или оформления заявки, продвигать скидки и акции и т.д.

В конечном счете все это должно привести к росту прибыли, охвата или других важных для вас бизнес-показателей. Если мобильное приложение не ориентировано на это, высокие затраты на разработку могут не окупить себя.

Шаг 2. Проанализируйте целевую аудиторию и конкурентов

На этом этапе важно понять, пользуется ли ваша целевая аудитория мобильными устройствами и какие у нее потребности.

Приложение является довольно действенным инструментом для компаний, ориентированных на молодежь и активных пользователей гаджетов. Если ваш бизнес локальный или направлен на пожилую аудиторию — скорее всего, эффективнее и дешевле будет привлекать покупателей с помощью других каналов.

Успешное мобильное приложение не только решает задачи бизнеса, но и удовлетворяет потребности ваших клиентов или сотрудников:

• На вашем сайте высока доля мобильного трафика — возможно, пора переходить в мобайл.

• Покупатели в магазине часто забывают карту лояльности — было бы удобно иметь ее в электронном виде прямо в мобильном.

• Клиенты не всегда знают о текущих акциях — проинформируйте их об этом в приложении.

• Боятся, что товар закончится, пока они едут в магазин — предоставьте возможность зарезервировать его в 2 клика прямо с мобильного.

• Ваши сотрудники тратят много времени на определенные процессы – оптимизируйте их. Создайте базу знаний, CRM, внутрикорпоративные мессенджеры, портативные кассы, передающие заказы покупателей на склад и др.

Эти и многие другие потребности можно закрывать с помощью мобильных приложений. Очень полезно также заглянуть к конкурентам и посмотреть, какие возможности они предоставляют в приложении и какие фишки используют.

Шаг 3. Оцените вашу инфраструктуру данных

Любое бизнес-приложение построено на работе с данными клиентов и самого бизнеса (бухгалтерии, склада и пр). Поэтому важно понимать, есть ли у вас необходимая инфраструктура или потребуются дополнительные затраты на ее построение.

Если компания активно работает в онлайне, скорее всего, данные собираются и хранятся в электронном виде. В этом случае существующая архитектура данных подходит для наполнения мобильного приложения. Потребуется лишь ее доработать и построить канал взаимодействия с приложением.

Если вы не собираете данные или ведете учет в бумажном виде, мобильное приложение обойдется существенно дороже. На построение только архитектуры данных придется выделить от 40% бюджета. Самый недорогой вариант — простой интернет-магазин.

Если речь идет о нейронных сетях и анализе данных, то серверные работы займут существенную часть бюджета.

Шаг 4. Выберите способ и инструмент разработки

Как разрабатывать приложение: самостоятельно или на заказ — зависит от вашего бюджета и желаемого результата. Давайте разберем оба варианта.

Мобильное приложение своими руками

Разработать приложение самостоятельно можно, когда бюджет небольшой или вовсе отсутствует. Обычно к этому варианту прибегают представители малого и среднего бизнеса, которым достаточно стандартных решений по готовым шаблонам.

Существует три варианта самостоятельной разработки приложения:

Написание кода своими силами

Если вы обладаете навыками программирования или готовы получить их, то вполне можете написать приложение самостоятельно. Технологии можно использовать разные: от натива (Swift или ObjectiveC для iOS, Java или Kotlin для Android) до всевозможных фреймоворков — например, Xamarin (C#), ReactNative (Javascript) или Flutter(Dart).

В этом случае затраты на разработку будут минимальны, но сам процесс, скорее всего, займет много времени. Итоговое качество продукта будет зависеть только от вас самих.

Онлайн-сервисы для создания приложений на основе готового контента

Это наиболее простой способ создания приложений — чтобы им воспользоваться, вам понадобится только сайт, адаптированный под мобильные устройства. Такие сервисы конвертируют браузерную версию в приложение без существенных изменений. Весь процесс может занять несколько минут. Способ подходит для небольших сайтов с качественным адаптивным дизайном или мобильной версией. Быстро, дешево и сердито.

Если вас интересует такой вариант, рекомендую также в качестве альтернативы рассмотреть возможность доработки своего сайта и создания PWA – progressive web app. Эта технология позволяет получить своеобразный гибрид сайта и приложения: в десктопе он будет отображаться как обычный сайт, а в мобильной версии — имитировать приложение. Возможно, вам окажется достаточно этого функционала и не придется делать отдельное приложение.

Конструкторы мобильных приложений

С их помощью уже можно создать полноценное приложение с нуля. Никакими навыками программирования обладать не нужно — вся работа ведется в визуальном редакторе. Функционал конструкторов включает как готовые шаблоны, так и отдельные элементы: формы, кнопки, иконки и т.д.

По итогам вы получите простое мобильное приложение с шаблонным дизайном. Его функционал будет ограничен только возможностями использованного вами конструктора.

Затраты на самостоятельную разработку

Во многих сервисах доступны бесплатный базовый функционал и Pro-версии. Стоимость платных тарифов сильно разнится в зависимости от опций, периода оплаты и пр. В среднем для создания стандартного приложения понадобится около 50-150$ в месяц.

Не забудьте, что на разработке дело не заканчивается и даже готовые решения требуют поддержки и обновлений. Многие конструкторы предлагают публикацию приложения в магазинах и дальнейшее сопровождение за дополнительную плату.

Профессиональная разработка мобильного приложения

С ростом бизнеса шаблонные мобильные приложения, конечно же, его задач уже не решат. Крупная компания должна предоставлять клиентам качественный сервис, удобный интерфейс и функционал, отвечающий потребностям пользователей. Кроме того, у нее должна быть возможность отстроиться от конкурентов. На этом этапе компании борются за лучший клиентский опыт, поэтому без разработчиков уже не обойтись.

Существует несколько подходов к разработке в зависимости от задач приложения, желаемых сроков реализации и используемых технологий. Как правило, команда разработчиков выбирает тот способ и инструмент, с которыми она привыкла работать. Для собственника бизнеса они не играют большого значения, но следует знать основные нюансы.

Разработка отдельного приложения под каждую платформу

Данный подход предполагает написание кода отдельно под Android и под iOS. Целесообразен он в тех случаях, когда требуется уникальный дизайн для каждой платформы с соблюдением всех гайдлайнов, максимальная производительность приложения и полный доступ к функциональности (дактилоскопический сканер, алгоритмы дополненной и виртуальной реальности, тонкие настройки беспроводного соединения, трансляция геолокации и т.д.).

Минусы очевидны: это наиболее затратный способ с точки зрения времени и ресурсов. Каждая операционная система предполагает свой язык программирования (Swift или Objective-C для iOS, Java или Kotlin для Android) и способ описания UI-дизайна. Это обязывает разработчиков реализовывать весь функционал для каждой из платформ по отдельности, практически без возможности переиспользования наработок одной платформы на другой. Если проект сложный или команда не имеет опыта работы с двумя операционными системами, есть вероятность, что потребуется задействовать по отдельной команде на каждую платформу.

Кроссплатформенная разработка

В этом случае мобильные приложения на Android и iOS разрабатываются с использованием общей бизнес-логики и с единым описанием дизайна, что снижает затраты. Наиболее популярные инструменты кроссплатформенной разработки: React Native, Xamarin (Xamarin.Forms) и Flutter. На выходе получается приложение, которое выглядит и работает одинаково на обеих платформах.

В числе недостатков такого подхода: сложность соблюдения гайдлайнов каждой платформы, ограничения используемых фреймворков (например, отсутствует доступ к каким-либо функциям устройства) и меньшее быстродействие, по сравнению с нативом. Если есть необходимость в более сложных решениях, не факт, что разработчик сможет их реализовать.

Комбинация нативного подхода и кроссплатформенного

Для более сложных приложений мы используем этот подход. Его особенность состоит в том, что мы имеем общую бизнес-логику, но дизайн создается отдельно под требования Android и iOS. В этом случае разработчик фактически работает с нативным кодом каждой платформы, но с помощью единого языка программирования C#. Это дает возможность переиспользовать код на обеих платформах.

В DD Planet мы используем фреймворк Xamarin, который позволяет сгладить все различия платформ и написать код на одном языке. Это оптимальный вариант для сложных приложений – он позволяет соответствовать гайдлайнам каждой платформы и решать бизнес-задачи любой сложности.

Затраты на заказную разработку

Стоимость профессиональной разработки мобильных приложений под ключ начинается от 500 тыс. руб. Она зависит от уровня инфраструктуры данных и сложности самого приложения.

Шаг 5. Протестируйте

Тестирование — важный этап, который должен сопровождать весь процесс разработки. Проще и дешевле устранить баги в самом начале, чем постоянно дорабатывать после релиза.

Что необходимо тестировать:

• Функционал. Оцениваем, соответствует ли приложение ТЗ и потребностям бизнеса, и проверяем работоспособность всех функций.

• Конфигурации. Тестируем на разных устройствах, конфигурациях и версиях операционных систем.

• Высокие нагрузки. Проверяем, как ведет себя приложение при увеличении числа активных пользователей, пиковых нагрузках, нестабильном подключении к сети, добавлении ресурсоемкого функционала и т.д.

• Юзабилити. Анализируем удобство взаимодействия пользователей с приложением при различных сценариях поведения.

• Безопасность. Выявляем уязвимости к сетевым атакам, вирусам и взломам, обеспечиваем безопасность пользовательских данных.

Шаг 6. Регулярно поддерживайте приложение

Как часто требуется техническая поддержка? Если разработка и тестирование прошли с ошибками, то приложение нужно будет постоянно дорабатывать. Конечно, это не лучшая ситуация. Тем не менее, даже качественный продукт нужно регулярно поддерживать.

В среднем устранение недочетов требуется примерно раз в месяц. Учесть все при тестировании нельзя: клиенты используют огромное множество устройств с разными характеристиками, поэтому на отдельных гаджетах в любом случае будут всплывать мелкие баги.

Помимо мелких доработок, изредка появляется необходимость в масштабных обновлениях. Обычно это происходит с выходом новых девайсов, на которых приложение работает не так, как ожидалось.

Из наиболее ярких примеров — новые требования Apple к приложениям после выхода iPhone X. На обновления владельцам дали два месяца. Если спустя это время приложения отображались на устройстве некорректно, их удаляли из магазина.

Как правило, гарантийная поддержка на первое время входит в стоимость разработки.

Краткое резюме по созданию эффективного приложения

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

Продуманный подход и следование всем этапам позволят вам создать мобильное приложение без необходимости серьезных доработок в будущем, сэкономить на непредвиденных расходах и увеличить прибыльность вашего бизнеса.

Что такое интерфейс

«Интерфейс» в переводе с английского состоит из слов interaction ― взаимодействие ― и face ― лицо.

Интерфейс для бизнес-приложения — это средство взаимодействия пользователя с информационной системой. Хороший интерфейс должен быть интуитивно понятным и удобным в использовании, чтобы пользователи могли быстро и эффективно выполнять свои задачи. Интерфейс является ключевым элементом любого приложения, который определяет эффективность работы пользователей.

Почему интерфейс важен в любом бизнес-процессе

Многие компании уделяют большое внимание производительности и эффективности своих бизнес-процессов, чтобы максимизировать прибыль и удовлетворять потребности своих клиентов. Однако, не менее важную роль играет интерфейс, т.е. то, как пользователи взаимодействуют с продуктом или услугой. Если процесс взаимодействия с клиентом затруднен или неудобен, это может привести к потере клиентов и уменьшению прибыли.

Одним из примеров может быть интернет-магазин. Если на сайте или в приложении магазина нельзя совершить покупку в несколько кликов, то клиенты могут разочароваться и перейти к другому поставщику. Другим примером может быть облачный сервис, который используется сотрудниками компании. Если интерфейс интуитивно непонятен, то процесс работы может замедлиться, а производительность команды снизиться.

Кроме того, удобный интерфейс может увеличить лояльность пользователей. Если пользователь хорошо знаком с продуктом и умеет легко им пользоваться, то вероятность того, что он вернется к этому продукту, увеличивается. Поэтому компании должны уделять достаточно внимания разработке удобного интерфейса, чтобы его использование было максимально комфортным и эффективным для всех пользователей.

Основные виды интерфейсов для бизнес-приложений

Чаще всего выделяют два базовых вида интерфейса для бизнес-приложений, каждый из которых имеет свои особенности и применение:

Мобильные интерфейсы

Это интерфейсы мобильных приложений, с которыми пользователи взаимодействуют с экрана смартфона или планшета. Отсюда и особенности:

• Крупные элементы интерфейса — блоки меню, кнопки или иконки — которые заполняют экран полностью: так, чтобы их было хорошо видно даже при маленьком разрешении.

• Расположение элементов обосновано анатомически: так, чтобы ими было удобно управлять с помощью одной руки, а пальцы не промахивались мимо кнопки.

Веб-интерфейсы

Это интерфейсы сайтов и онлайн-сервисов, которые работают в десктопных браузерах. От мобильных их отличает то, что масштаб и композиция элементов здесь могут быть любыми, а управляют ими с помощью мыши или тачпада. В таких графических интерфейсах чаще встречаются большие текстовые блоки, видео и анимация.

Инструменты для создания качественного интерфейса

Создание интерфейса для бизнес-приложения может происходить с помощью различных инструментов и технологий. Вот несколько из них:

• Sketch: это инструмент для дизайна интерфейсов, который используется для создания векторных иллюстраций и элементов интерфейса. Sketch позволяет создавать макеты и дизайны, а также работать с готовыми библиотеками символов и плагинами.

• Figma: это веб-приложение для дизайна интерфейсов, которое позволяет создавать прототипы и работать с другими участниками команды в режиме реального времени. Figma также позволяет работать с библиотеками символов и плагинами, что делает процесс дизайна более эффективным.

• Adobe XD: это инструмент для создания интерфейсов, который позволяет создавать прототипы, анимации и элементы интерфейса. Adobe XD также позволяет работать с другими продуктами Adobe, такими как Photoshop и Illustrator, что делает процесс дизайна более удобным.

• InVision: это платформа для создания интерактивных прототипов и дизайна интерфейсов. InVision позволяет создавать анимации и переходы между страницами, а также работать с другими участниками команды.

• HTML, CSS и JavaScript: это языки программирования, которые используются для создания веб-интерфейсов. Они позволяют создавать интерактивные элементы, анимации и прототипы, а также работать с различными библиотеками и фреймворками.

Конечный выбор инструментов и технологий для создания интерфейса зависит от потребностей и возможностей команды и проекта.

Этапы создания интерфейса

Создание интерфейса для бизнес-приложения — это процесс, состоящий из нескольких этапов. Рассмотрим каждый:

1. Исследование пользователей и целей приложения. На этом этапе необходимо изучить потребности и цели пользователей, а также определить, каким образом интерфейс приложения может помочь им достичь этих целей.

2. Проектирование информационной архитектуры. На этом этапе создаются структура и организация информации в приложении. Это включает в себя создание карт сайта и диаграмм потоков данных, которые помогут организовать информацию и логику приложения.

3. Создание макетов и прототипов. На этом этапе создаются визуальные макеты и прототипы, которые показывают, каким образом пользователи будут взаимодействовать с приложением. Макеты могут быть созданы как на бумаге, так и в специальных программных инструментах.

4. Тестирование прототипов. Прототипы необходимо тестировать, чтобы проверить, насколько эффективно пользователи могут взаимодействовать с приложением. На этом этапе выявляются недостатки интерфейса и предлагаются улучшения.

5. Создание графического дизайна. На этом этапе определяется стиль и цветовая гамма приложения, а также создаются визуальные элементы интерфейса, такие как кнопки, иконки и шрифты.

6. Разработка интерфейса. На этом этапе происходит создание кода, который реализует интерфейс приложения. В этом процессе используются языки программирования, такие как HTML, CSS и JavaScript.

7. Тестирование и улучшение. На этом этапе проводится тестирование уже разработанного интерфейса приложения. Выявленные недостатки устраняются, а интерфейс приложения улучшается и оптимизируется в соответствии с потребностями пользователей.

Каждый из этих этапов является важным для создания привлекательного и эффективного интерфейса приложения. Правильное планирование и реализация каждого из них помогут создать удобный и понятный интерфейс для пользователей.

Рекомендации для создания привлекательного интерфейса бизнес-приложения

• Сделайте интерфейс интуитивно понятным. Люди должны легко понимать, как использовать приложение и какие функции оно предоставляет.

• Держите дизайн чистым и простым.

• Используйте привлекательные и нейтральные цвета и шрифты.

• Создавайте качественные изображения и иконки.

• Размещайте элементы так, чтобы пользователи могли легко находить нужные функции.

• Старайтесь создавать дизайн, который соответствует брендингу вашей компании.

Совет от эксперта:

Создавайте такой интерфейс, чтобы с ним могла работать даже ваша бабушка, либо чтобы ей можно было по телефону рассказать, как совершать те или иные операции, потому что в бизнес-приложении далеко не всегда работают IT-специалисты, а оно должно быть доступным и понятным для всех пользователей.

OkHttp предоставляет простой, легкий в использовании API для выполнения HTTP-запросов, включая поддержку протоколов HTTP/1.1 и HTTP/2. Библиотека поддерживает все стандартные методы HTTP и может легко обрабатывать несколько одновременных запросов, а также предоставляет расширенные возможности: кэширование запросов/ответов, объединение подключений в пул (connection pooling), аутентификация и др.

О том, почему иногда стоит использовать OkHttp, а не вездесущий Retrofit, можно посмотреть в видео от Android Broadcast. Краткое пояснение дано в следующем пункте статьи.

В статье подробно рассмотрены основные объекты и методы библиотеки и представлены основы работы с ней в Android-разработке.

Содержание:

• Преимущества OkHttp
• Основные классы и методы
• Простой GET-запрос (синхронный/асинхронный)
• Сериализация/десериализация
• Простой POST-запрос
• Особенности работы с HTTPS
• Аутентификация на сервере
• Использование вместе с ViewModel

Преимущества OkHttp

OkHttp — это библиотека более низкого уровня, чем Retrofit. Это означает, что HTTP-запросы, автоматизированные в Retrofit с помощью аннотаций, придётся писать вручную. Однако в этом и главный плюс библиотеки: она предоставляет более обширный функционал и настройки соединения, что может повысить производительность и сократить использование памяти. К слову, Retrofit под капотом использует OkHttp.

Библиотека разработана как легкая и эффективная, с акцентом на снижение задержек и повышение работоспособности. Это достигается за счет применения различных методов оптимизации, таких как повторное использование соединений, сжатие и конвейеризация.

Преимущества OkHttp:

• Гибкость: Библиотека предоставляет больше контроля над процессом сетевого взаимодействием за счёт дополнительных функций, например, пользовательской обработки запросов и ответов.
• Лёгкость: OkHttp — более компактная библиотека, чем Retrofit, что позволяет минимизировать размер используемой приложением памяти.
• Кэширование: Библиотека имеет встроенную поддержку HTTP-кэширования, что может повысить производительность и снизить нагрузку на сеть.
• Аутентификация: OkHttp предоставляет гибкий и расширяемый API аутентификации, что упрощает реализацию различных её моделей.
• Перехватчики (Interceptors): Это механизм, позволяющий легко настраивать запросы и ответы, а также хороший выбор для приложений, требующих расширенной обработки запросов.
• WebSockets: OkHttp обеспечивает встроенную поддержку WebSockets, что позволяет легко реализовать коммуникацию с сервером в режиме реального времени.

Основные объекты и методы

Настройка клиента и запроса

Класс OkHttpClient — клиент для HTTP-вызовов, который можно использовать для отправки запросов и чтения ответов.

OkHttpClient.Builder — класс предоставляющий методы для настройки клиента, например кэш, аутентификация, перехватчики, тайм-ауты и др. По завершению настройки используется метод build(), который возвращает экземпляр класса OkHttpClient.

OkHttp работает лучше при создании одного экземпляра OkHttpClient и повторном его использовании для всех HTTP-вызовов. Так происходит потому, что каждый клиент содержит свой собственный пул соединений и пул потоков. Повторное использование соединений и потоков уменьшает задержку и экономит память. И наоборот, создание клиента для каждого запроса приводит к трате ресурсов на незадействованные пулы.

Класс Request представляет собой HTTP-запрос. Request.Builder позволяет установить параметры запроса, например url и заголовки.

В целом, HTTP-заголовки представляют собой что-то похожее на Map: каждое поле имеет одно значение или не имеет его вовсе. Однако некоторые заголовки могут иметь несколько значений. В связи с этим для добавления заголовка к запросу применяются два метода:

• header(name, value) — устанавливает только одно значение заголовка name. При этом все существующие значения заголовка будут удалены, и после этого будет установлено новое значение.
• addHeader(name, value) — добавляет заголовок без удаления уже имеющихся значений.

При чтении заголовка из ответа используйте header(name), чтобы вернуть последнее вхождение заголовка (зачастую это единственное вхождение). Если значение отсутствует, header(name) вернет null. Чтобы прочитать все значения заголовка в виде списка, используйте headers(name).

Для установки целевого URL-адреса запроса используется метод url(). По завершению настройки запроса используется метод build(), который возвращает объект Request.

Отправка запроса

newCall — метод класса OkHttpClient, который подготавливает запрос к выполнению в будущем. Принимает объект Request и возвращает объект Call.

Класс Call (вызов) — это запрос, который был подготовлен к выполнению. Вызов может быть отменен. Поскольку экземпляр класса представляет одну пару запрос/ответ, он не может быть выполнен дважды. Для выполнения запроса существуют два метода:

• execute() — при синхронном вызове. Метод незамедлительно выполняет запрос и блокирует поток до тех пор, пока ответ не будет доступен для обработки или пока не возникнет ошибка.
• enqueue() — при асинхронном вызове. Метод назначает запрос на выполнение в определенный момент в будущем. Диспетчер определяет, когда будет выполнен запрос: обычно сразу же, если в данный момент не выполняются несколько других запросов. Позже клиент получает объект responseCallback либо с HTTP-ответом, либо с исключением в случае возникновения ошибки.

Чтение ответа

Класс Response представляет HTTP-ответ. Тело ответа — свойство экземпляра класса, которое может быть использовано только один раз и затем закрыто. Все остальные свойства неизменяемы.

Прежде чем как-либо использовать тело ответа, необходимо проверить, был ли запрос к серверу успешен. Для этого существует метод isSuccessful() вышеупомянутого класса. Метод проверяет код состояния (status code) HTTP-ответа и возвращает значение true, если код находится в диапазоне 200-300. Если код находится за пределами этого диапазона, он возвращает значение false, указывающее, что запрос не был успешным.

Неуспешный запрос означает, что возникли проблемы на стороне клиента или сервера. Например, запрос был неправильно составлен, на сервере произошла ошибка или сервер некорректно обработал запрос. Если не проверять код состояния, то в конечном счёте можно работать с ответом, который не содержит ожидаемых данных.

Для получения тела ответа используется метод body() класса Response, который возвращает экземпляр класса ResponseBody.

ResponseBody — одноразовый поток от сервера к клиенту, содержащий тело ответа в виде необработанных байтов. Каждое тело ответа поддерживается активным подключением к веб-серверу.

Класс ResponseBody поддерживает потоковую передачу очень больших ответов. Например, его можно использовать для чтения ответа, размер которого превышает всю память, выделенную текущему процессу. Можно даже передавать в потоковом режиме ответ, объем которого превышает общий объем памяти на текущем устройстве, что является обычным требованием для стриминговых видео-приложений.

Класс не загружает весь ответ в память, поэтому тело ответа может быть считано только один раз. Для этого существует несколько методов:

• bytes() и string() — считывают весь текст ответа в память, а затем возвращают его в виде массива байтов или строки соответственно. Методы следует использовать только для небольших ответов. При считывании больших ответов будет вызвана ошибка OutOfMemoryError.
• source, byteStream, charStream — предназначены для потокового чтения ответа. Метод source возвращает объект BufferedSource, позволяющий читать тело ответа в виде потока байтов. byteStream работает аналогично, но возвращает объект InputStream. charStream — возвращает объект Reader, который позволяет читать тело ответа в виде потока символов.

Если использовать body() без упомянутых методов, то будет получен сам объект ResponseBody, с которым ничего особо не поделаешь.

Простой GET-запрос (синхронный/асинхронный)

Перед использованием библиотеки нужно добавить соответствующую зависимость в Gradle:

Номер последней версии можно посмотреть на Maven Central.

Синхронный запрос (Java):

Синхронный запрос (Kotlin):

В то время как в Java используются методы объектов, в Kotlin иногда используются их свойства. Например, свойство body объекта Response.

Каждое тело ответа поддерживается ограниченным ресурсом. Поэтому после использования оно должно быть закрыто. Закрытие ресурса освобождает все системные средства, которые были выделены ресурсу, и делает его доступным для сбора мусора (garbage collection). Если не закрыть тело ответа, произойдет утечка ресурсов, что в конечном итоге может привести к замедлению или крашу приложения.

Для закрытия ресурса можно использовать метод close(), но предпочтительнее использовать блок try-with-resources (Java) и метод use (Kotlin). Обе конструкции выполняют блок кода относительно заданного ресурса, а затем корректно закрывают его, независимо от того, вызвано исключение или нет.

Асинхронный запрос (Java):

Асинхронный запрос (Kotlin):

Асинхронный запрос выполняется в потоке Worker. Когда ответ доступен для чтения выполняется обратный вызов (сallback). Этот вызов выполнится после того, как будут готовы заголовки ответа. Чтение тела ответа все еще может блокировать поток. OkHttp в настоящее время не предлагает асинхронных API для получения тела ответа по частям.

Callback имеет два абстрактных метода:

• onResponse — вызывается, когда HTTP-ответ был успешно получен от удаленного сервера.
• onFailure — вызывается, когда запрос не может быть выполнен из-за проблем с подключением, тайм-аута или при его отмене. Поскольку в сети может произойти сбой во время соединения с сервером, возможен случай, когда удаленный сервер успевает принять запрос до сбоя.

Сериализация/десериализация

В данном пункте кратко рассмотрена сериализация и десериализация объектов (их преобразование в определённую последовательность байтов, которую можно передать по сети, и наоборот).

Для того, чтобы преобразовать объект в строку JSON или наоборот можно воспользоваться библиотеками Gson и/или Moshi.

Вкратце, если вам нужна проста использования и широкий набор функций, то выбираете Gson. Если нужна производительность и эффективное использование памяти, то лучшим выбором будет Moshi.

Рассмотрим пример сериализации с помощью Moshi (Java).

То же самое в Kotlin:

Для сериализации необходимо создать объект Moshi, адаптер и передать ему тип сериализуемого объекта. В данном случае это тип Class.

Если требуется сериализовать более сложный объект, например коллекцию, то тип можно передать двумя способами.

1) С помощью метода Types.newParameterizedType(), который создает новый параметризованный тип.

2) С помощью класса TypeToken библиотеки Gson. Класс используется для передачи информации о типах во время выполнения программы. Конструктор класса возвращает представленный класс из заданного типа.

Разница способов состоит в том, что TypeToken более типобезопасен (typesafe), а Types.newParameterizedType более эффективен.

Десериализация осуществляется аналогичным образом.

При сериализации/десериализации Moshi может вызывать разного рода исключения, к примеру если десериалируемая строка не является строкой JSON или если строка не соответствует объекту, в который её пытаются преобразовать.

Если серверная и клиентская часть настроены правильно, то такого не должно происходить. Но всё же рекомендуется оборачивать операции Moshi в блок try-catch.

Простой POST-запрос

Чтобы сделать POST-запрос, используется метод post() класса Request.Builder. Метод принимает RequestBody, который он добавляет к запросу.

POST-запрос в Java:

POST-запрос в Kotlin:

Объект MediaType необходим для описания типа содержимого тела запроса или ответа. Обычно он используется для установки заголовка “Content-Type” в HTTP-запросе.

Чтобы получить объект MediaType можно использовать один из статических методов одноименного класса:

• MediaType.parse(String) — создает новый экземпляр MediaType с указанным типом содержимого и кодировкой. Функция возвращает медиатип для строки, или null, если строка не является правильно сформированным медиатипом.
• MediaType.get(String) — работает аналогично MediaType.parse, но если строка сформирована неправильно, то вызывает исключение IllegalArgumentException.

В Kotlin используется метод toMediaType() объекта String. Метод является аналогом MediaType.get(String).

RequestBody — класс, представляющий собой тело запроса. Экземпляр класса создаётся с помощью метода create.

RequestBody.create(MediaType, String) создает тело запроса с указанным содержимым и его типом. Метод имеет несколько реализаций. Содержимое можно передать в виде массива байтов, файла, строки или объекта okio.ByteString. Тип содержимого всегда указывается с помощью объекта MediaType. Этот объект также устанавливает заголовку “Content-type” соответствующее значение, поэтому вручную устанавливать этот заголовок не нужно.

Аналогом RequestBody.create(MediaType, String) в Kotlin является метод toRequestBody(MediaType?) объекта String.

Особенности работы с HTTPS

OkHttp пытается балансировать между двумя задачами:

• Подключение к максимально возможному количеству хостов. Сюда входят как современные хосты, на которых используются последние версии boringssl, так и немного устаревшие хосты, на которых используются старые версии OpenSSL.
• Безопасность соединения. Сюда входит проверка удаленного веб-сервера с помощью сертификатов и конфиденциальность данных, передаваемых с помощью надежных шифров.

При согласовании соединения с HTTPS-сервером OkHttp должен знать, какие предлагать версии TLS и наборы шифров. Для клиента, который хочет максимизировать возможность соединения с различными серверами, это будут устаревшие версии TLS и слабые по конструкции наборы шифров. Для клиента, который хочет максимизировать безопасность, это будут только последняя версия TLS и самые сильные наборы шифров.

Конкретные решения по безопасности и соединению реализуются с помощью ConnectionSpec. OkHttp включает четыре встроенных типа соединений:

• RESTRICTED_TLS – безопасная конфигурация, предназначенная для удовлетворения более строгих требований по соответствию.
• MODERN_TLS – безопасная конфигурация, позволяющая подключаться к современным HTTPS-серверам.
• COMPATIBLE_TLS – безопасная конфигурация, которая подключается к безопасным, но менее современным серверам HTTPS.
• CLEARTEXT – небезопасная конфигурация, которая используется для URL-адресов http://.

По умолчанию OkHttp будет пытаться установить соединение MODERN_TLS. Если соединение MODERN_TLS не удастся, okhttp3 переключится на другой тип соединения. Точный механизм отката зависит от конкретной реализации okhttp3 и конфигурации, установленной разработчиками.

Настроить конфигурацию можно следующим образом:

В официальной документации можно найти дополнительные способы работы с HTTPS, такие как создание собственной спецификации подключения, закрепление сертификата и настройка доверенных сертификатов.

Аутентификация на сервере

Аутентификацию на сервере можно реализовать двумя способами.

1) Вручную добавить заголовок аутентификации. Полезно в случае, если нужна аутентификация только для одного запроса. Для того, чтобы добавлять заголовок ко всем запросам клиента, можно создать перехватчик. Способ полезен, если у вас статический ключ API или токен, который нужно отправлять с каждым запросом.

2) Использовать интерфейс Authenticator — полезно, когда необходимо динамически аутентифицироваться или нужна дополнительная настройка процесса аутентификации.

Интерфейс позволяет выполнить либо предварительную аутентификацию перед подключением к серверу, либо реактивную аутентификацию после получения ответа от веб-сервера или прокси-сервера.

Рассмотрим пример реактивной аутентификации. В таком случае, если код состояния ответа равен 401 (Unauthorized), OkHttp посылает повторный запрос, включающий заголовок “Authorization”.

При этом важно сделать проверку, была ли в первоначальном запросе попытка аутентификации. Если да, то, скорее всего, дальнейшие попытки будут бесполезны, и аутентификатор должен отказаться от них.

Здесь метод authenticator с помощью лямбда-функции устанавливает экземпляр интерфейса Authenticator, который предоставляет механизм для проверки ответа от сервера и возвращает запрос, включающий в себя учетные данные клиента. Метод Credentials.basic используется для кодирования имени пользователя и пароля при базовой аутентификации.

Использование вместе с ViewModel

Простой асинхронный запрос в ViewModel можно сделать следующим образом.

Метод postValue передаёт задачу по установке значения главному потоку. Если попытаться присвоить значение напрямую, то будет вызвано исключение java.lang.IllegalStateException: Cannot invoke setValue on a background thread.

Необходимо делать именно асинхронный запрос, чтобы не блокировать поток интерфейса и чтобы приложение оставалось отзывчивым. Либо можно самостоятельно настроить синхронный вызов в другом потоке.

Начиная с SDK 10 при попытке синхронного вызова в главном потоке будет вызвано исключение android.os.NetworkOnMainThreadException.

Чтобы сделать запрос в отдельном api-файле и передать ответ переменной из ViewModel можно воспользоваться механизмом callback.

В файле SomeApiService.kt находится интерфейс RequestCallback, класс SomeApiService с методом makeRequest, который делает запрос к серверу, и объект SomeApi, через который будет осуществляться доступ к экземпляру класса.

В MainViewModel.kt функция getResponseFromApi реализует интерфейс RequestCallback и передает его в качестве параметра методу makeRequest().

Представленный код можно обернуть во viewModelScope.launch {…}, чтобы запрос был отменён при очистке (разрушении) MainViewModel.

Заключение

OkHttp — гибкая библиотека, выступающая в роли HTTP-клиента.

В отличии Retrofit настраивать клиент, писать запросы и обрабатывать ответы необходимо вручную. Это одновременно и преимущество и недостаток OkHttp. Недостаток заключается в необходимости писать много шаблонного кода. Преимущество — возможность кастомизировать соединение.

Из-за слабой кастомизируемости в некоторых случаях Retrofit может не подойти, и без OkHttp не обойтись. Также благодаря кастомизации OkHttp можно повысить производительность и уменьшить использование памяти.

Полезные ресурсы: Подробнее про Authenticator; Различные примеры использования библиотеки; Перехватчики (Interceptors).