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

Existential Container — одна из тех тем, которые регулярно всплывают на собеседованиях на middle и senior iOS-разработчика. Если понимать layout контейнера, проще объяснить несколько связанных тем: any vs some, Protocol with Associated Types, type erasure и стоимость protocol dispatch.

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

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

Для своей коллекции я написал плеер. Для себя. Через полгода это превратилось в нишевое приложение для iOS на 11 языках: с собственным DSP, распознаванием музыки, онлайн радио и CarPlay.

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

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

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

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

Друзья, всем привет. Это моя проба пера на Хабре. Меня зовут Максим Талалаев, я достаточно давно управляю людьми. Вот теперь занимаюсь этим в сфере IT. Делаю с командой проект по созданию и развитию платформы временной (гибкой) занятости.

Пишем на PHP. Используем Laravel и Lifewire с Filament. Базы на PostgreSQL. Приложения писали на Flutter, хотя в первое время нас здорово выручал самописный mini‑App в телеграм. В общем все, как у всех.

И вот недавно встал вопрос в загрузке приложений на известные всем площадки: GooglePlay, RuStore. На «десерт» мы оставили AppStore, так как мифов о нем ходило гораздо больше, чем о двух вышеупомянутых источниках. Я не буду подробно останавливаться на самой процедуре, по которой написано немыслимое количество статей и материалов,а сразу перейду к моментам, на которые лично у меня ушло больше всего душевных и временных терзаний, а также управленчески неэффективно потраченного времени (ну, это уже по завершении всех этапов так можно сказать. Конечно, когда я был в процессе, мне так не казалось.). Естественно, я прошел все стадии, начиная от «Создать аккаунт разработчика на организацию в России сейчас невозможно» до «А ты попробуй найти специализированное бюро, которое тебе для Apple корректно сделает перевод на иностранный язык».

Несколько месяцев пилю embedded P2P-мессенджер на Matrix-протоколе как личный pet-проект в свободное от основной работы время. Стек: форк Dendrite (Matrix homeserver на Go), Pinecone overlay routing от matrix.org research, gomobile bind для упаковки в .aar и .xcframework, modernc.org/sqlite вместо CGO-варианта (иначе gomobile капризничает). Не туториал и не “hello world на gomobile”, а серьёзная архитектурная амбиция в свободное время. Делюсь reasoning’ами почему такие архитектурные выборы и где они начинают течь.

Без обещаний неубиваемости. Проект в активной разработке, на этапе интеграции в клиентское приложение поверх Rust SDK matrix.org. Цифры приведу с явной маркировкой “где замерено на моём стенде, где плановая оценка, что ещё не проверено”. Production-NAT-кейсы (CGNAT, реальные мобильные сети) - впереди в следующем рывке. Если что-то принципиально новое всплывёт - напишу продолжение.

Если экран с картинками начинает тормозить, проблема редко сводится к одному AsyncImage. Разбираю, что действительно стоит измерять, как использовать preview и prefetch, зачем делить устройства на tier и почему одинаковое поведение на всех девайсах почти всегда ошибка.

Привет, Хабр! Меня зовут Константин Шкурко, я ведущий разработчик мобильных приложений в РСХБ. Сегодня хочу рассказать историю о том, как всем известные обстоятельства заставили нас в сжатые сроки искать альтернат­ивные пути доставки нашего инвестиционного приложения «Свои инвестиции» пользователям iOS - и как это изменило наш технологический стек.

Когда Apple заблокировала российские банковские приложения в App Store, перед нами встала непростая задача. У нас были десятки тысяч активных пользователей на iOS, которые пользовались брокерским приложением для управления своими инвестициями. Торговля акциями, облигациями, аналитика портфеля, выставление заявок - всё это внезапно стало недоступно для значительной части клиентской базы.

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

Всем привет! Меня зовут Иван, я Android разработчик и сегодня я хочу поговорить с вами об такой вещи как Coroutines в языке Kotlin

Не знаю как у вас, а я всегда интересовался как устроены те или иные вещи на низком уровне, поэтому когда я начал активно заниматься Android разработкой и познакомился с Kotlin одним из главных вопросов который не уходил у меня из головы, как устроены Coroutines на низком уровне?

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

Рассказываем, как заменили Context.dev API на Jina Reader и Vercel AI SDK, чтобы генерировать DESIGN.md для AI-агентов без платной подписки.

Если вы когда-нибудь пытались скормить сырой HTML с глубокой вложенностью React-компонентов в LLM-контекст, вы знаете эту боль: 20 000 токенов уходит на бесполезный <div>-суп и закрывающие теги. Именно для решения этой проблемы одни хорошие люди и создали designmd.supply — инструмент, который парсит сайт и собирает из него структурированный DESIGN.md для AI-ассистентов. Проблема в том, что его ядро опиралось на платный Context.dev API, который недавно закрыл бесплатный доступ.

Открытый форк open-designmd решил эту задачу иначе: все проприетарные эндпоинты заменены на бесплатные альтернативы — Jina Reader для парсинга HTML в Markdown, Microlink для скриншотов, и любой LLM-провайдер через OpenRouter или Ollama. Весь пайплайн работает локально, без подписки и кредитных карт.

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

В крупных приложениях для iOS взаимодействие между компонентами зачастую оказывается сложнее, чем сам компонент. Сервис завершает операцию, координатор должен отреагировать, возможно, потребуется обновить несколько экранов, и передача каждой зависимости по всему дереву навигации быстро начинает казаться излишней «рутинной» работой. Внедрение зависимостей и управление состоянием по-прежнему имеют своё место. Шина (данных) событий предоставляет нам ещё один инструмент для слабосвязанных уведомлений, где прямое управление добавило бы ненужную сложность. Цель этого компонента проста: позволить одной части приложения публиковать событие, а другим частям приложения — подписываться на события определенного типа. Реализация сосредоточена на типовой безопасности, потокобезопасном хранении, автоматической очистке при деаллокации владельца, явной отмене отдельных подписок, доставке MainActor для кода пользовательского интерфейса и поддержке AsyncStream для потребителей async/await.

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

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

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

Разбираем очень неприятный баг в React Native + iOS: почему push-уведомления сохраняются на Android, но теряются на iOS в background/killed state. В статье обсудим как на самом деле устроены APNS, Notification Service Extension, App Groups и почему проблема вообще не в React Native. Будет интересно…

В этом выпуске продолжаем исследовать новинки I/O 2026 и переводить пользователей, прекращаем использовать .onAppear и лезем Gradle под капот, делаем приватность частью архитектуры, создаем систему привлечения пользователей, поднимаем Llama 3 в облаке и многое другое. Заходите!

Всем привет!

Недавно я публиковал статью о том, что HalChat вышел в Google Play, и это вызвало небольшой ажиотаж вокруг проекта. Буквально за пару дней мы пробили отметку в 100+ скачиваний, а за один день было зарегистрировано 60 новых пользователей. Оценив такой отклик, я решил, что нужно идти дальше и сделать клиент HalChat для Android открытым.

Далее: зачем Open Source для HalChat, обновление и планы на будущее.

Это третий пост о нашем проекте на Хабре. В первом мы рассказывали гипотезу, во втором — что из неё выжило после первых пользователей. Сейчас короткий и довольно прямой пост: мы ищем разработчика. Без модной формулировки про «rockstar ninja» — реально студенческий проект, в котором сейчас не хватает рук, чтобы двигаться дальше.

Я сделал приложение NeonDrift — живые обои для macOS на основе Metal-шейдеров. Для базовой работы не нужны сторонние библиотеки, Screen Recording или Accessibility-доступ. Только AppKit, MetalKit и SwiftUI.

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

Главная идея статьи не в том, чтобы сделать ещё один wallpaper app, а в том, чтобы показать как на macOS можно аккуратно совместить AppKit window management, Metal render loop и SwiftUI-настройки без приватных API — и где именно этот подход начинает трещать по швам.

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

В этой статье разберём две вещи, которые из этого выросли: острова (свой сервер) и мультиличность (несколько независимых зашифрованных аккаунтов на одном телефоне). И отдельно, без прикрас, расскажем, где у этого подхода границы.

1. Фундамент: сервер, который мало что знает

Сначала коротко про основание, иначе дальше будет непонятно.

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

- Sealed sender: отправитель запечатан внутри зашифрованного конверта, а не лежит в заголовке. На транспортном уровне сервер видит "кому доставить", но не "от кого". Кто это понимает, тот сразу видит, что граф общения на сервере не собирается.

- Контент шифруется end-to-end: эфемерный X25519 на сообщение, HKDF, ChaCha20-Poly1305. Сервер пересылает шифротекст, ключей у него нет.

Идея простая: сервер это в основном тупая труба для шифротекста. Нет телефонов, нет графа, нет содержимого. Это важно для всего дальнейшего.

2. Острова: свой сервер вместо нашего

Раз сервер это тупая труба, его можно вынести куда угодно. Любая организация (редакция, юрфирма, команда, НКО) поднимает свой экземпляр RCQ, свой остров, и общается внутри него: свой сервер, свои UIN, своя история, свои группы, отдельно от публичной сети.

Звучит как мем про стартап, который пытается быть всем сразу. Я сам так думал примерно до середины разработки. Но в итоге мы это собрали, выкатили в App Store и Google Play, и теперь команды реально ведут в этом проекты. Расскажу, как оно устроено внутри, что было тупо, что неожиданно сработало, и где я до сих пор не уверен, что мы поступили правильно.

Сразу оговорюсь: это не «убийца Jira» и не «убийца Slack». Это попытка убрать одну конкретную боль, на которую я смотрел несколько лет.

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

У продуктов Клеверенса (например, «Магазин 15», «Склад 15») есть возможность обмениваться данными между учетной системой (например, «1С: Предприятие») и удаленными ТСД через сеть. Это так называемый обмен через Интернет, который решает вопрос работы с удаленными устройствами без сложных и длительных настроек ПО и оборудования (например, проброс портов на роутере).