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

В архитектуре 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. Если вы это и так знаете, просто пролистывайте врезки «на полях».

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

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

Привет! Я Катя Образцова, AI-продакт-лид и заместитель руководителя развития продукта в Битрикс24.

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

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

В новом дайджесте UISlider изнутри и навигация в Jetpack Compose без магии, миграция приложения на Navigation 3 и сборщик мусора в Dart, мобильное тестирование в 2026, как меняется разработка в эпоху ИИ, новые модели Anthropic и Google и многое другое. Заходите!

В iOS 26 у UISlider появился liquid-glass-вид и физика доводки (settle) после того, как пользователь отпускает палец. Если честно, я не проверял, как это выглядело в старых версиях и как оно работало, так как до iOS 26 ни в своих проектах, ни в тех, что я писал на работе, я не использовал стандартный компонент, так как его внешний вид никого не устраивал. У такой доводки есть побочный эффект: если в этот момент дернуть setValue(_:animated:) извне, наш слайдер на один кадр едет в новую точку, а потом откатывается туда, куда его тянет settle. removeAllAnimations() не помогает: анимация идёт не через CABasicAnimation, а через property-driver на display link. Дальше про то, как я нашёл рабочий путь это исправить.

Добавлял в свою читалку офлайн-словари и упёрся в MDX, формат словарей MDict. Проприетарный, официальной спеки от создателей нет. Готовые Java-парсеры под GPL, а у меня закрытое приложение, тащить нельзя. Значит, пишу свой, с нуля и без зависимостей. Рассказываю, как формат устроен внутри, где я споткнулся, и почему пришлось руками писать RIPEMD-128, чтобы прочитать даже оглавление словаря.

Какова ситуация в мобильном тестировании в 2026-м году?

На связи Ильнур – ведущий тестировщик: начал свой путь в ИТ 10 лет назад как специалист технической поддержки. Со временем понял, что хочу не просто «чинить», а понимать, как всё устроено. Так я пришёл в тестирование и уже через год стал тимлидом команды.

На протяжении следующих 5 лет участвовал в запуске более 10 приложений – от MVP до многомиллионных. Я учился на ошибках, пропускал через себя сотни релизов, «съел собаку» в ручном тестировании, понял, как работают платформы, сети, железо. Хочу поделиться своими мыслями о мобильном тестировании как человек, который знает сферу изнутри.

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

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

Эта статья – моя попытка объяснить вам доходчивым языком, что же такое Garbage Collector в Dart, объяснить почему эти некоторые знания нам нужны на практике и что из всей этой тяжелой, технической внутрянки вам необходимо знать.

Всем привет! Я Никита, тимлид команды Android в Банки.ру. 

Недавно, внедряя в приложение фичу авторизации без SMS-кода (seamless), мы столкнулись с тем, что она в упор отказывалась работать – но только на Android. Мы дебажили ее полторы недели, перепробовали все возможные варианты и закошмарили всех доступных операторов связи, прежде чем узнали, что все дело было… в энергосбережении.

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

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

Я давно, со студенчества, интересовался проблемами старения организма. Поработав с десятками тысяч пациентов, я уже не удивлялся, что паспортный (хронологический) возраст и реальное состояние организма — это две разные вещи. Один пациент в 60 бегает марафоны, другой в 45 еле ходит по дому. Но причины этого медицине, честно говоря, до ситх пор непонятны. Мне хотелось как‑то объективизировать, оцифровать, что ли, эту разницу без сложных анализов и дорогостоящих исследований. И чтобы каждый человек мог легко и просто оценить свой биологический возраст — не просто для того, чтобы его узнать — а сделать определенные выводы и, возможно, изменить свои привычки и даже обратиться к специалистам. Теперь для этого есть общедоступные инструменты — смартфоны с фотокамерой, искусственный интеллект и модели, способные анализировать, состояние кожи и другие показатели по фотографии. Надо попробовать, решил я. Но для этого нужно создать мобильное приложение. Раньше я бы на такое не замахнулся, ну а сейчас — время есть, инструменты есть, желание есть — why not?

Вы когда-нибудь задумывались, зачем нужны библиотеки для навигации в Jetpack Compose? Почему мы не можем просто взять mutableStateOf со списком экранов и переключаться между ними? Оказывается, если мы попробуем реализовать такой наивный подход, то столкнёмся с рядом проблем: rememberSaveable не работает, ViewModel не очищаются после ухода с экрана, Lifecycle не работает корректно и многое другое.

В статье разберём, как работают библиотеки навигации в Jetpack Compose и какие задачи они решают на примере библиотеки навигации Modo.

Ну что же…, на дворе 2026 год, первый DogPlanner живёт своей жизнью, доступен на многих площадках мобильных приложений, мы о нём много писали в соцсетях и различных блогах. С тех пор как мы сделали его, а опубликовали мы его аж в июне 2020 года, вы прислали нам много различных идей по его доработке, написали множество отзывов, а также мы узнали о приличном количестве проблемных мест по его функциональности и содержанию, и всё это было абсолютно заслуженно! Хотим сказать вам огромное спасибо за всю обратную связь, которую мы получили, и получаем до сих пор от вас! Но давайте снова вернёмся к критике…

Когда говорят про нейросети в разработке игр, разговор почти всегда уходит в одну из двух крайностей.

Первая: «это всё ерунда, игрушка для ленивых».
Вторая: «теперь один человек может нажать пару кнопок и сделать новый Fallout».

Обе версии удобные. И обе, по моему опыту, довольно далеки от реальности.

Я уже довольно давно (третий год) в одиночку делаю Sunarius — большую постапокалиптическую RPG (представьте игру как Fallout 2, вот это оно). Это проект с глобальной картой, тактическими пошаговыми боями, диалогами, квестами, фракциями, торговлей, караванами, лутом, инвентарём, развитием отряда, сохранениями и кучей систем, которые должны не просто существовать рядом, а работать вместе.

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

И вот здесь нейросети действительно всё поменяли.

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