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

Нативное приложение на C в продакшен часов Xiaomi, вы когда нибудь мечтали о таком? Я покажу как - на примере последней модели Xiaomi SmartBand 10 Pro, оно того стоит, работает быстро, возможности практически не ограничены, интеграция не сильно сложная, и то что сломали разработчики поправимо, а главное это довольно интересно.

Всем привет! Сегодня я хочу поделиться историей, которая длится уже порядка 10 лет.

Это история не про успешный успех или очередное нытье о том, как сложно и несправедливо, это просто про меня и мой путь. Она началась много лет назад, в далеком 2016, когда Tilda только приобрела свою первую популярность и из всех кипятильников кричали: «Web-разработчикам конец», «Убийца веб-разработки».

В 2016 году мне было 22 года, и я толком не понимал, чем заниматься. У меня был закончен специалитет и бакалавриат по финансам и банковскому делу. Я застал кризис 2014 года, уйдя с хорошей должности в банке в армию на срочку. Вернувшись, я полгода обивал пороги во Владивостоке в то время, когда все банки массово сокращали персонал. В целом, если у тебя не было «волосатой руки», твой максимум составлял 50 тысяч рублей, и то с премией!

Работал я в тот момент в одном дочернем банке одного очень известного Зеленого Банка, на должности кредитного эксперта. Единственное, что занимало мою голову, был вопрос: «Что я вообще здесь делаю и какого будущего я хочу?»

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

Эта статья не про геймдизайн, не про монетизацию, не про продвижение и не про то, почему ваша игра никому не нужна.

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

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

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

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

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

Меня зовут Ваня, я руководитель команды Android-разработки SDK Алисы и техлид проекта дефолтного ассистента. Сегодня мы с вами разберёмся, где проходят эти границы, на примере Алисы AI.

Публикация приложения в App Store — процесс волнительный, однако потеря этой возможности — уже катастрофа. В этой статье мы разберем способы продления членства в программе Apple Developer осенью 2026 года и подводные камни с которыми можно столкнуться. Если вы тоже столкнулись с этой проблемой или знаете рабочие варианты — эта статья для вас.

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

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

В дату релиза проект деплоится в прод. Но почему-то там все также один пользователь — сам создатель.

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

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

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

Привет, это команда ОС Аврора.

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

Дальше разговор обычно упирается в одну и ту же фразу: у нас всё нативное. Kotlin, Swift, годы накопленного кода, и переписывать это долго и дорого. Кроссплатформа есть далеко не у всех.

Тем, у кого она есть, нам уже давно есть что ответить: Flutter под Аврору поддерживается официально, Compose Multiplatform — тоже, и такие команды переезжают без драмы. А вот всем остальным мы до недавнего времени могли предложить только сочувствие.

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

Возьмём типичный отчёт воронки интернет‑магазина: «Каталог → Товар → Корзина → Оформление заказа → Оплата». До последнего шага дошло 38% сессий, остальные 62% потерялись между «Оформлением» и «Оплатой». Для продуктовой аналитики эти 62% — повод для гипотезы «форма оформления слишком длинная» и задачи на редизайн. Для команды разработки те же 62% — конкретная JavaScript ошибка. Но пока данные о конверсии и данные об ошибках лежат в разных системах, выбор между ними происходит наугад. Как перестать «угадывать» почему отвалились пользователи и какую в этом роль играет Customer Journey Map разберу в статье.

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

Привет, Хабр! Меня зовут Денис Смирнов, я старший инженер по разработке ПО искусственного интеллекта KVADRA AI в YADRO. В этой статье расскажу, как мы искали нейросеть для автоматической цветокоррекции на планшете KVADRA_T, почему выбрали MSLTNet и как довели ее до работы на реальном устройстве.

С появлением Flutter GPU у Dart-разработчиков впервые появился прямой доступ к Metal и Vulkan без единой строчки нативного кода. Чтобы понять, готов ли новый API к настоящим 3D-играм, я написал над ним движок на чистом Dart: сцена, PBR-освещение, каскадные и кубические карты теней, HDR-конвейер и три взаимозаменяемых графических бэкенда (Flutter GPU, WebGL2 и программный растеризатор), плюс три законченные игры, играбельные прямо в браузере. В статье разбираем границы Flutter GPU, устройство движка и самые дорогие грабли, собранные по дороге.

Всем привет. Я Михаил Харитончик, лидер продукта GenUI в Цифровом Ассистенте ГигаЧат B2C. Моя команда занимается генеративными интерфейсами: тем, как превращать ответ модели в понятную визуализацию, интерактивные элементы и полноценный пользовательский сценарий. И сегодня я хочу поговорить о будущем приложений. Точнее, о будущем, в котором приложений в привычном виде может вообще не остаться.

Этот текст про горизонт от нескольких месяцев до пары лет. В ИИ-индустрии даже полгода — практически геологическая эпоха: изменения происходят не кварталами, а итерациями длиной в несколько часов. Недавно я увидел, как Сэм Альтман репостит сообщение: кто-то обнаружил, что Grok при работе с агентом отдаёт исходный код. Прошло менее суток — и Grok CLI уже ушёл в open source. За происходящим в индустрии физически сложно успевать.

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

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

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

В этой части я проведу вас через наш интеграционный лабиринт. Расскажу, как мы собирали команду, выстраивали процессы, договаривались со стороной интегратора и проектировали идеальное API. Какой путь мы успели пробежать за 8 месяцев хардкора. И как я впервые столкнулся с «обстоятельствами непреодолимой силы». В финале я дам вам 10 правил работы с госами, которые мы вынесли из этого опыта и могут оказаться полезными, если вы окажетесь в подобной ситуации.

Если вы не читали первую часть — рекомендую вернуться. Там о том, как мы выстраивали юридическую защиту и внедряли практически полноценный Agile под маской Waterfall. Это не просто «история», это набор инструментов, который помогал нам не сойти с ума. Но если вам ближе продуктовое мясо и детали реализации — добро пожаловать прямо сюда. Читать мою историю можно в любом порядке.

Приготовьтесь, отправляемся. Следующая станция — «прод».

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

Но спустя 5 минут поисков до вас доходит осознание:Gradle Flavor на KMP нет и не планируется, а вместо них нам достается expect/actual, разбивающий код по платформенным сорц сетам

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

Так я вернулся в геймдев и начал разрабатывать собственные игровые проекты. Мне был нужен инструмент для 2D‑игры с версиями для Android и браузера, который позволил бы сохранить общий код, не прятал бы происходящее за визуальным редактором и не заставлял бы отказываться от привычной Java‑экосистемы.

В итоге я выбрал libGDX.

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

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

Одна минута macOS-раннера в GitHub Actions стоит десять минут Linux. Я перенёс iOS-сборку Flutter-приложения в Xcode Cloud: с ~45 оплачиваемых минут на релиз до 6, без .p12 и профилей в секретах, с тремя shell-скриптами вместо 90 строк YAML. Внутри — схема тегов ios/v* и android/v*, настройки Xcode Cloud, которые молча сжигают compute-часы, и таблица семи падений первого живого прогона — ни одно из них не было ошибкой миграции. Плюс чек-лист и открытый скилл, который из этого вырос.

Привет! Я Максим Савченко, iOS-разработчик. Эта история началась с вопроса, как сделать живую форму в духе иконки Siri — и довольно быстро уехала в другую сторону: аттрактор Лоренца на сотнях тысяч, а потом и на миллионе частиц, где и расчёт, и отрисовка живут на GPU.

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

В статье разбираю это по шагам: математика и выбор интегратора, ping-pong-буферы, compute/render-пайплайн, point primitives и additive blending. А в конце — GPU Frame Capture и замеры на физическом iPhone. Спойлер, который я сам не ожидал: RK4 в этой конфигурации оказался далеко не самым дорогим местом. Основная цена ушла в отрисовку и overdraw.

Если коротко: это не гайд «как нарисовать красивую картинку», а разбор того, зачем вообще лезть в Metal и где кадр упирается на реальном устройстве.

Пользователи открывали мое приложение VibeLing и не понимали, что учить. Я добавил готовые коллекции и долго считал проблему решенной.

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

В этом дайджесте надежное выполнение фоновых задач в iOS и детекция лица в реалтайме для биометрии в Android, забавные анимации с меш-градиентами в Jetpack Compose и кастомизация пейволов с Apple Foundation Models, Kotlin Coroutines Channels и Actor‑модель, фоновые задачи в KMP с API как у WorkManager, разработка на Авроре под Аврору, двуногий робот в форме утёнка от Hugging Face и многое другое. Заходите!

Apple меняет домен новых Private Relay адресов для Sign in with Apple. Внешне это похоже на небольшую правку allowlist, но на практике быстро выявляет хрупкую архитектуру, где email участвует в поиске аккаунта.

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

Тут должна быть картинка

Привет, Хабр! Когда-то я пять лет проработал в отделе тестирования, а последние шесть занимаюсь разработкой под iOS и Android. На одном из первых проектов в мобилке я на Java под Android создал пирамиду тестирования: больше тысячи unit-тестов, больше ста интеграционных и с десяток UI и End‑to‑End. На текущей работе сделал то же самое с нуля, но уже под iOS на Swift.

Но не все сценарии можно покрыть автотестами. Многое все еще тестируется вручную. Например, на текущем проекте мне нужно проверять работу звонков. И для этого не подходят симуляторы/эмуляторы, так как часть функций звонков в них недоступна. Единственная возможность проверить - это взять два физических телефона и протыкать все руками. Обычно я так и делаю при разработке. А потом готовые фичи передают ручным тестировщикам, которые это проверяют на своих телефонах. 

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

Начал разбираться и узнал, что есть множество мировых ферм устройств: BrowserStack, Sauce Labs, LambdaTest, AWS Device Farm, Firebase Test Lab и другие. Но все они зарубежные. С текущими перебоями интернета в РФ — ненадежный вариант. Оказалось, что в России, кроме приватных ферм у корпораций, есть MWS SunQ. Можно развернуть STF и Appium самому — но это больше задача для DevOps. И ограничена теми устройствами, что есть у фирмы. У нас их штук десять — для полноценного тестирования мало. Поэтому я решил разобраться с MWS SunQ.