Мобильная разработка

Казалось бы, тема заезженная до состояния покрышки камаза: «сделай бота, который качает ролики». На Хабре уже лежит десяток туториалов, на GitHub — сотни форков. Но если вы хоть раз открывали такой бот в проде — вы знаете, что 90% из них падают на втором пользователе, а оставшиеся 10% честно умирают на видео длиннее 15 минут.

Я полез в органическую выдачу Google, чтобы понять, почему люди вообще ищут Telegram-ботов, а не пользуются веб-сервисами. И выдача, честно говоря, удручает.

Представьте ситуацию: вы работаете в огромном проекте, где количество модулей давно перевалило за тысячу. Вы решаете обновиться до свежего Xcode 26.2, ожидая прироста производительности, но вместо заветного «Build Succeeded» получаете молчаливое падение: SWBBuildService quit unexpectedly.

Всем привет, меня зовут Алексей Севко, я ведущий разработчик программного обеспечения из команды Delivery & Performance Яндекс Go. В этой статье я расскажу почти детективную историю о том, как:

— Искать иголку в стоге сена: когда падает закрытый бинарник Xcode.

— Стать контрибьютором swift-build: почему иногда проще переписать системный поиск макросов в swift-build, чем ждать фикса от Apple.

— Использовать свою версию билд-системы: как мы внедрили инфраструктуру прозрачной подмены компонентов Xcode через XCBBUILDSERVICE_PATH, чтобы не ждать релиза Xcode со Swift 6.3 и работать стабильно уже сегодня.

Если ваш проект тоже перерос стандартные инструменты Apple или вам просто интересно, как превратить рекурсию в итерацию и не сойти с ума от 45-минутных дебаг-сессий, — добро пожаловать под кат!

В этом выпуске сравнение быстродействия SwiftUI и UIKit, план изучения Android-разработки и Kotlin DSL для Android-шейдеров, прагматичный взгляд на архитектуру Flutter и пара детективов с поиском багов, как не надо делать скриншоты в App Store, диспетчеризация дома, поддержка Swift в разных IDE, тестирование взаимодействия нескольких устройств и многое другое. Заходите!

Пока все обсуждают очередные сливы баз и особенности модерации в популярных «безопасных» мессенджерах, решил попробовать пойти другим путем. В этой статье рассказываю, как я скрестил Flutter и Go через CGO, прикрутил libp2p для создания P2P-сети и реализовал честное E2EE шифрование (Double Ratchet для личек и MLS для групп). Никакой централизации, никаких единых точек отказа. Делюсь результатами эксперимента.

У меня был один телефон, на котором я создавал проект, редактируя файлы в nano.

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

В 2024 году Google тихо убил Timeline в Google Maps. Историю местоположений перевели в «локальный режим», который на практике работает через раз - данные теряются, синхронизации нет, а у многих просто исчезли годы накопленной истории.

Для меня это было важно: я много езжу на машине и хотел знать простую вещь - сколько конкретная поездка стоит в бензине. Ничего подходящего не нашёл и решил написать сам. Я бэкенд-разработчик, до этого проекта не написал ни строчки на Swift - дальше про то, как за месяц вечерами собрал GPS-трекер с фильтром Калмана, fog of war на geohash и Live Activity.

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

Есть Bloc, есть Dio, есть go_router, есть get_it. Где-то рядом лежат репозитории, модели, пара экранов и слайд со стрелками. На демо это звучит убедительно: “вот UI-слой, вот data-слой, вот state management”. Кажется, что если взять правильный набор пакетов, дальше система почти сама соберётся.

У меня так не вышло.

Я делаю Flutter-приложение для изучения языков. Это не pet-проект на три экрана, а полноценный клиент: авторизация через несколько провайдеров, анонимный вход, перевод, распознавание, генерация контента, учебные капсулы, локальные настройки, офлайн-поведение, WebSocket-события, длинные фоновые операции. И основные проблемы там начинаются не на уровне Flutter, а в тот момент, когда продуктовая логика перестаёт помещаться в учебные примеры.

Почти все полезные инженерные решения в проекте появились не из любви к “красивой архитектуре”, а после вполне приземлённых сбоев в реальных сценариях:

пользователь зашёл анонимно, потом решил зарегистрироваться и не должен потерять данные;

сеть на телефоне формально есть, но realtime-слой умер;

тяжёлая серверная операция крутится десятки секунд, а UI не должен выглядеть подвисшим;

приложение надо уметь не просто логинить, а аккуратно переживать смену identity;

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

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

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

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

Naïve-клиент для iOS и macOS и сервер, устанавливающийся одной командой

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

Скилл для Claude Code, который знает Material Design 3 лучше, чем вы: 30+ компонентов с Compose-маппингами, генерация тем из seed-цвета, адаптивная навигация и аудит готового приложения по 10 категориям — от цветовых токенов до accessibility. Compose-first, Flutter вторичный, веб в maintenance mode. 454 звезды за 4 дня.

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

Начиная писать Flutter-приложение, для стейт-менеджмента часто хватает простого setState или простого решения, по типу BLoC/Cubit без излишеств. Но с течением жизни проекта ваши блоки могут начать превращаться в god objects. Внутри хендлеров могут находиться и запросы в сервисы, и валидация, и эмиттеры состояния, а для крупной страницы точно одним ивентом не обойдешься. В таких условиях разработка сильно затрудняется, становится сложно поддерживать и масштабировать проект, снижается тестируемость.

Это не субъективный опыт — строгая разделенная архитектура повышает гибкость, переиспользуемость и тестируемость кода. BLoC сам по себе — паттерн с отличной дисциплиной потока данных и строгим отделением бизнес‑логики от UI, но стоит немного расслабиться, и он разрастается до god объекта.

Цель этой статьи — продемонстрировать, как вынесение бизнес логики в use-cases может помочь вернуть контроль над ViewModel слоем. Это не попытка навязать единственный вариант реализации, а материал про технический компромисс, подтвержденный цифрами и опытом.

Если набрать в поиске «книга по SwiftUI на русском», результаты будут неожиданно скромными. Такие издания есть, но они либо выпущены уже довольно давно (как, например, наша книга Александра Казанцева, либо представлены на английском, либо доступны в формате он-лайн курсов разной степени полноты. Печатная книга по актуальной разработке под iOS - явление нынче редкое.

Месяц назад мы выпустили перевод книги «iOS 18 App Development Essentials» Нила Смита — автора, которого англоязычное сообщество знает по многолетней серии учебников по разработке приложений под платформы Apple и Android. Книга вышла под названием «Основы разработки приложений для iOS», насчитывает 736 страниц и охватывает всё от синтаксиса Swift до публикации приложения в App Store. Книга вышла довольно толстой (а перевод всегда немного больше оригинала), но этот объем заполнен довольно полезной и актуальной информацией.

Как создать мобильное приложение c фото- и видео-камерой на C# с использованием элемента SkiaCamera: SKSL шейдеры, AI-субтитры и наложение графики во время записи.

Для захвата камеры в .NET MAUI есть хорошие варианты: CommunityToolkit.Maui.Camera, MediaPicker и платформенное API.

Для особого класса задач, где необходимо обрабатывать превью и кадры, идущие в запись, есть пакет DrawnUi.Maui.Camera.

Лучше всего заходит для :

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

Когда я впервые всерьёз сел писать AGSL под Android, ощущение было очень странное. С одной стороны - современный графический конвейер, RuntimeShader, RenderEffect, красивые эффекты и весь этот техно-киберпанк. С другой - шейдерный код живёт внутри строковых литералов, uniform-ы приходится объявлять и привязывать вручную, а отладка периодически начинается с философского вопроса: «в какой именно строке я сейчас всё сломал?»

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

Собственно, так и появился RedByteFX. Я сделал его не только ради собственного удобства. Мне хотелось решить ещё одну задачу: сделать AGSL более массовой и понятной технологией для Android-разработчиков. Потому что в нативном виде AGSL мощный, но психологически для многих выглядит как «не трогай, это на Новый год». А мне хотелось, чтобы к шейдерам можно было подойти без дрожи в коленях и без ощущения, что сейчас придётся разговаривать с господином ПЖ на древнем пацакском наречии.

В новом дайджесте пружинная анимация и Kotlin без «воды, будущее Android-приложений с AppFunctions и путь к сингулярности, лампа с цифровым джинном, как Gemma 4 меняет правила игры, ошейники для коров, замена List, Remote Compose и многое другое. Заходите!

Несколько лет назад сеть McDonald проводила промо-акцию, в которой через простую мини-игру можно было выиграть iPhone. Называлась эта игра «FriesHit» и была доступна в мобильном приложении McDonald’s (бельгийская версия). Это просто примитивная тапалка, целью которой являлось занять первую строчку таблицы лидеров, чтобы заполучить заветный iPhone (или Samsung S10, если вы окажетесь на втором месте; но кому он нужен).

Каждый день таблица лидеров аннулировалась, то есть компания ежедневно отдавала iPhone X занявшему первое место (как я понял, это происходило целый месяц). Естественно, в игре есть свой подвох — чтобы набрать победные очки, нужно соревноваться с другими игроками. Хитрость в том, что для покупки жизней в игре вы тратите «баллы лояльности». Кто не знает, эти баллы вам начисляют за покупку товаров в сети (типа потратьте €1 в ресторане McDonald's и получите 10 баллов).

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

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

Каждое Android-приложение, которое хранит данные на устройстве, рано или поздно сталкивается с базой данных. Встроенная SQLite — надёжное решение, но работа с ней через SQLiteOpenHelper требует написания SQL-запросов вручную, преобразования курсоров в объекты и постоянного контроля за закрытием соединений. Это отнимает время и довольно часто вызывает ошибки.

Google предложил библиотеку Room, которая является оберткой над SQLite и реализует паттерн ORM (Object-Relational Mapping). В этой статье мы на конкретном примере сравним, как выглядят операции добавления и чтения данных на чистом SQLite и на Room. Вы увидите, почему Room избавляет от «шаблонного кода» и делает работу с БД простой и безопасной.

Знакомо, правда? Мечтаешь создать невозможное: уникальное, новое, то, чего ещё нет на рынке. И при этом чтобы это было твоё «детище», твой продукт, которым ты будешь гордиться и который станет по-настоящему стоящим и полезным для мира.

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

В этой статье я расскажу о проектировании мобильного приложения "Balance" по методу колеса жизненного баланса — от выбора идеи до кликабельных прототипов и тестирования.

Изучая UI/UX-дизайн, маркетинг и рынок в целом, я пришла к главному выводу: уникальность заключается не в том, чтобы придумать то, чего никто никогда не делал, а в том, чтобы сделать так, как никто другой не делает: удобно, красиво, с душой. И для этого не нужна команда дизайнеров. Только вы, ваше желание и правильные шаги.

Некоторые языки программирования начинают по-настоящему ценить тогда, когда разработчик замечает: значительная часть усилий уходит на решение задачи, а не на борьбу с инструментом. Экосистема Java — хороший пример такого накопленного трения. Она несет в себе наследие решений, принятых десятилетия назад, притом они не обязательно плохие — просто раньше не учитывались те сценарии, которые сегодня стали повседневностью: интенсивная работа с асинхронностью, быстрые итерации, требования к читаемости и поддерживаемости кода. Kotlin возник как попытка аккуратно убрать часть этого трения, не разрушая существующую инфраструктуру. Речь здесь идет о другом уровне комфорта при решении привычных задач — от базовых конструкций до построения полноценных сервисов. Именно этому посвящена только что вышедшая в издательстве «БХВ» книга Елены Ван Энгелен – Масловой «Kotlin. Краткий курс».