Разработка мобильных приложений *

Аннотации в Kotlin — это не только @Deprecated и @Suppress. Разбираемся, где живут SOURCE, BINARY и RUNTIME, чем KSP отличается от kapt, как compiler plugins меняют код и какие практические задачи можно закрыть генерацией: debug menu, удаление экспериментов и каталог performance-метрик.

Занимаюсь разработкой своей игры на Flutter. Дошёл до этапа, когда её пора было показать другу-тестировщику, а у него iPhone. Первая мысль — покупать Mac Mini или подписку Apple Developer за $99 в год. Обе цены платить не хотелось, пока проект не подтвердил, что вообще будет.

На Samsung всё это делается за 15 минут: dev mode, USB, установка. На iPhone пришлось искать схему, которую нигде не находил собранной в одном месте — четыре инструмента, час на реализацию и заметно дольше на то, чтобы вообще понять, что она существует.

Внутри: рабочий пайплайн Tenorshare iCareFone → GitHub Actions → Sideloadly → доверие на устройстве. Полный yml для сборки unsigned .ipa на хостовом macOS-раннере (со всеми нюансами Flutter-версии, precache, packaging и --dart-define для API). Разбор тонких моментов, которые не вылезают в туториалах: bundle ID под бесплатным Apple ID, Firebase-конфиги, миграция macos-latest на macOS 26 в июне 2026.

Отдельно — честная экономика iOS-релиза из России в июле 2026: как теперь оплачивать Apple Developer, когда с 1 апреля отключили мобильную оплату; во сколько по факту обходится 99 долларов через Gift Card, посредников и иностранные карты; и сравнение с Google Play ($25 единоразово), RuStore и AppGallery.

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

Это вторая, практическая, часть из двух. Здесь про то, как организованы слои, какие контракты уходят в Swift, как готовить SKIE, как устроены обработка ошибок и DI, что с модульностью, скоростью сборки и тестами.

Привет, Хабр. На связи Илья Новиков, технический директор команды разработчиков «Исходный код».

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

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

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

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

Всем привет! Хочу поделиться своим первым опытом в разработке мобильной игры для iOS — в жанре roguelite. Это pet‑проект, который неожиданно для меня самого дорос до релиза в App Store, так что расскажу и про идею, и про технические идеи. Надеюсь, будет интересно почитать:)

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

В какой-то момент я перестал мечтать и сел писать своё. Наивно думая, что это несложно Ну что там, показывай точку из базы да пикай при подъезде. (Спойлер) Я ошибался почти в каждом своём предположении. Эта статья про то, как «тут же нечего делать» превратилось в фьюжн сенсоров, счисление пути в тоннелях, геодезию проездов и краудбазу с криптозащитой. И про то, чему меня научила каждая набитая шишка.

Flutter активно движется в сторону Swift Package Manager (SPM) и, как и весь Swift‑мир, постепенно отказывается от CocoaPods. Сам Flutter описывает миграцию в два шага: включить флаг flutter config --enable-swift-package-manager и запустить сборку. Если после этого приложение собирается и в консоли появляется предложение deintegrate CocoaPods — вы счастливчик. Если нет, добро пожаловать под кат. 

Привет! Меня зовут Даниил Гиренко, я Flutter‑разработчик в Яндекс Про. Проект по переводу нашего супераппа с CocoaPods на Swift Package Manager оказался одним из самых сложных и долгих в моей карьере программиста. Весь мой пережитый ужас опыт я решил выразить в этой статье, чтобы решившиеся на миграцию разработчики (или агенты) понимали, какие подводные камни их ждут. Буду рад, если ваш проект займёт недели, а не месяцы, как у меня.

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

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

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

В новом выпуске UISlider изнутри и топ-10 вопросов по Kotlin в 2026 году, Swift 6.2 против вашего оптимизатора и переписывание Flutter на C#, всего несколько недель на вайб-кодинг, новый формат электронных книг для изучающих язык, многомерные векторы в конкурентном анализе мобильных приложений, обучение LLM 0.5B с нуля на статьях Хабра и многое другое. Подключайтесь!

Привет, Хабр. Я уже не тот беззаботный парнишка, что собирал 486-й компьютер. Время бежит, я скуф успел поработать с C++, C#, Java и Kotlin, последние 10 лет занимаюсь мобильной разработкой. Программирование я до сих пор люблю потому что больше ничего не умею. Но чем дольше работаешь, тем чаще ловишь себя на мысли, что от некоторых вещей начинает подгорать. Сегодня я расскажу, как я попытался избавиться хотя бы от части таких вещей.

Спойлер: оба находятся в опасности, но по-разному. Эта разница имеет значение.

Я не собирался сравнивать веб и мобилку как две враждующие платформы.

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

На вебе можно спрятать админку за условием в JavaScript и решить, что доступ закрыт. В мобилке можно положить токен в SharedPreferences и надеяться, что до него никто не доберется. Можно оставить открытый бакет, отключить нормальные правила Firebase, забыть про rate limit на логине или принять userId из тела запроса.

Все это выглядит как мелочи, пока приложение работает.

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

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

Когда проект растёт, дольше всего начинают тянуться самые «тяжёлые» проверки – UI-тесты. Один-два модуля поменял, а CI всё равно гоняет сотни тестов на эмуляторах и ждёт их десятки, а то и сотни минут. Знакомо?

Это третья, финальная статья цикла о том, как мы в Циане перешли от полного прогона всех проверок к выборочному с помощью Impact-анализа. В первой части я показывал, как мы ускорили статические анализаторы, во второй — как в два раза сократили unit-тесты, научившись обходить граф Gradle-модулей. В заключительной части я расскажу, как у нас на проде реализован выборочный запуск UI-тестов.

В архитектуре KMP+CMP-приложений главный вопрос не в том, сколько кода можно пошарить. Он в том, где нужно остановиться.

Я покажу два рабочих подхода. Первый — архитектура для большого мобильного продукта: общий Kotlin-слой для бизнес-логики и нативный UI на каждой платформе. Второй — стартаповый путь, где Compose Multiplatform помогает быстро запустить мобильные продукты, web- и desktop-приложения. И даже backend на общих моделях данных.

Поговорим о том, когда нужно и не нужно применять «лучшую» архитектуру.

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

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

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

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

Серия вторая: Продуктовое мясо и хроники интеграционного ада. Детальный разбор самого цифрового космолета, погружение под капот легаси-экосистемы, курьезные истории из жизни нашего «прода» в жанре «пиу-пиу». И в завершение 10 наших железных правил выживания с госами.

Добро пожаловать на борт. Физика процесса изменена, но внешне мы стоим на ногах.

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

Недавно мне в руки попал флагман 2011 года — Nokia E7-00. По современным меркам это устройство практически бесполезное: операционная система не поддерживает современные протоколы шифрования, сервисы Ovi давно отключены, форум allnokia недоступен, а сам бренд телефонов Nokia за это время дважды воскрешали разные компании, впрочем, без особого успеха.

В этой статье я расскажу о том, как работают смартфоны на Symbian^3 в современном мире, как разрабатывать приложения для них, и ради эксперимента попробую запустить подобие локальной языковой модели, которая дает полезные советы.

Я скучал по C#, когда писал на Flutter, и по Flutter — когда писал на C#. Поэтому взял и совместил: Plumix — фреймворк с флаттеровской архитектурой виджетов поверх .NET и Avalonia, который во многом строят ИИ-агенты. Рассказываю про мотивацию, конвейер портирования, текущие фичи и планы.

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

Подмена ожидания, Гипербола, Сравнение, Ирония, Сарказм, Двусмысленность, Каламбур, Абсурд, Антишутка, Шутка с вопросом-ответом, Повтор с нарастанием, Ложная логика, Доведение до абсурда, Обратный смысл, Нелепица, Пародия, Цитата вне контекста, Чёрный юмор, Самоирония, Эскалация

И я решил написать программу тренажер для тех кто хочет научиться остроумно шутить.

Про ARC, weak/unowned и retain cycle на русском написано столько, что добавить нечего. Про borrowing/consuming и ~Copyable (это, к слову, Swift 5.9, а не 6 - частая путаница) на английском тоже десятки разборов. И почти все они устроены одинаково: объясняют, что фича делает, на игрушечном примере с файловым дескриптором, и заканчивают выводом «так безопаснее и быстрее».

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

Статью я старался написать так, чтобы её читал не только стафф. Поэтому по ходу я коротко объясняю базовые вещи - стек и кучу, ARC, copy-on-write. Если вы это и так знаете, просто пролистывайте врезки «на полях».

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

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