Мобильная разработка
Photo
[Перевод] Как мы использовали Codex, чтобы запустить приложение Sora под Android за 28 дней четырьмя инженерами
Это статья из официального блога OpenAI, но подход меня так зацепил, что решил перевести для всех. Я тоже часто переношу веб-приложения на мобилки примерно таким же способом и было очень здорово увидеть такой же подход (архитектура+рабочее_приложение-как-пример) у по сути создателей сильного AI. Пишу про разные похожие интересные вещи тут
В ноябре мы представили миру приложение Sora для Android, предоставив любому пользователю с Android-устройством возможность превращать короткие текстовые промпты в живые видео. В день запуска приложение заняло 1-е место в Play Store. За первые 24 часа пользователи Android сгенерировали более миллиона видеороликов.
За этим запуском стоит история: первая версия продакшн-приложения Sora для Android была создана всего за 28 дней благодаря тому же агенту, который доступен любой команде или разработчику – Codex.
С 8 октября по 5 ноября 2025 года небольшая команда инженеров, работая бок о бок с Codex и израсходовав примерно 5 миллиардов токенов (вау), провела Sora для Android от прототипа до глобального запуска. Несмотря на скорость разработки и масштаб, приложение демонстрирует показатель стабильности (crash-free) 99,9% и архитектуру, которой мы гордимся. Если вам интересно, использовали ли мы какую-то секретную модель – нет, мы использовали раннюю версию модели GPT-5.1-Codex, ту самую, которую любой разработчик или компания могут использовать уже сегодня через CLI, расширение для IDE или веб-приложение.
Читать далее
Читать: https://habr.com/ru/articles/976330/
@mobi_dev | Другие наши каналы
Это статья из официального блога OpenAI, но подход меня так зацепил, что решил перевести для всех. Я тоже часто переношу веб-приложения на мобилки примерно таким же способом и было очень здорово увидеть такой же подход (архитектура+рабочее_приложение-как-пример) у по сути создателей сильного AI. Пишу про разные похожие интересные вещи тут
В ноябре мы представили миру приложение Sora для Android, предоставив любому пользователю с Android-устройством возможность превращать короткие текстовые промпты в живые видео. В день запуска приложение заняло 1-е место в Play Store. За первые 24 часа пользователи Android сгенерировали более миллиона видеороликов.
За этим запуском стоит история: первая версия продакшн-приложения Sora для Android была создана всего за 28 дней благодаря тому же агенту, который доступен любой команде или разработчику – Codex.
С 8 октября по 5 ноября 2025 года небольшая команда инженеров, работая бок о бок с Codex и израсходовав примерно 5 миллиардов токенов (вау), провела Sora для Android от прототипа до глобального запуска. Несмотря на скорость разработки и масштаб, приложение демонстрирует показатель стабильности (crash-free) 99,9% и архитектуру, которой мы гордимся. Если вам интересно, использовали ли мы какую-то секретную модель – нет, мы использовали раннюю версию модели GPT-5.1-Codex, ту самую, которую любой разработчик или компания могут использовать уже сегодня через CLI, расширение для IDE или веб-приложение.
Читать далее
Читать: https://habr.com/ru/articles/976330/
@mobi_dev | Другие наши каналы
Мобильная разработка за неделю #612 (8 — 14 декабря)
В этом выпуске особенности Struct в Swift и RemoteCompose в Android, знакомство с Frida и новые умные очки Google, сломанное ценообразование приложений с подпиской, навигация на SwiftUI, создание анимированных полос и многое другое. Заходите!
Читать далее
Читать: https://habr.com/ru/articles/976470/
@mobi_dev | Другие наши каналы
В этом выпуске особенности Struct в Swift и RemoteCompose в Android, знакомство с Frida и новые умные очки Google, сломанное ценообразование приложений с подпиской, навигация на SwiftUI, создание анимированных полос и многое другое. Заходите!
Читать далее
Читать: https://habr.com/ru/articles/976470/
@mobi_dev | Другие наши каналы
Мобильная разработка
Photo
Ученые научили крыс бегать и стрелять внутри DOOM
Ученые обновили эксперимент с DOOM II: теперь крысы не только бегают по уровню, но и стреляют, управляя персонажем без имплантов и нейроинтерфейсов
— Читать дальше «Ученые научили крыс бегать и стрелять внутри DOOM»
Ученые обновили эксперимент с DOOM II: теперь крысы не только бегают по уровню, но и стреляют, управляя персонажем без имплантов и нейроинтерфейсов
— Читать дальше «Ученые научили крыс бегать и стрелять внутри DOOM»
❤1
Мобильная разработка
Photo
Р-ФОН: пишем, запускаем и отлаживаем для него программы на Raspberry Pi с установленной ОС «РОСА Фреш»
Это самый простой способ создания программ для Р-ФОН.
Традиционно программы для мобильных телефонов собираются в специализированных средах разработки, включающих эмуляторы.
Уникальность телефона Р-ФОН заключается в том, что на нём можно сразу запускать программы, работающие на компьютерах с процессорами ARM и операционными системами «РОСА Фреш» и «РОСА Хром». Это существенно облегчает разработку. И написание, и запуск, и отладку, и работу в программе можно сначала обкатать на компьютере, и лишь на последнем этапе скопировать программу на телефон и протестировать уже на нём.
Естественно, для работы со специфическими для телефона компонентами, такими как GPS-приёмник и GSM-модем, требуется отдельный подход. Но для создания пользовательского интерфейса и, например, кода для работы по сети - компьютер более чем удобен.
Какой же компьютер с процессором ARM подойдёт? Неплох компьютер на процессоре Байкал-М, но он дороговат, и его ещё нужно поискать. А вот компьютер на основе Raspberry Pi можно назвать народным. Подойдёт 64-разрядный, то есть, начиная с версии Raspberry Pi 4. Мне достался Pi 400, и всё описанное ниже было опробовано именно на нём.
Ниже описан мой опыт написания простых тестовых программ для Р-ФОН, использующих различные графические инструментарии (Qt, PyQt, GTK3, GTK4, SDL2).
Читать далее
Читать: https://habr.com/ru/articles/976428/
@mobi_dev | Другие наши каналы
Это самый простой способ создания программ для Р-ФОН.
Традиционно программы для мобильных телефонов собираются в специализированных средах разработки, включающих эмуляторы.
Уникальность телефона Р-ФОН заключается в том, что на нём можно сразу запускать программы, работающие на компьютерах с процессорами ARM и операционными системами «РОСА Фреш» и «РОСА Хром». Это существенно облегчает разработку. И написание, и запуск, и отладку, и работу в программе можно сначала обкатать на компьютере, и лишь на последнем этапе скопировать программу на телефон и протестировать уже на нём.
Естественно, для работы со специфическими для телефона компонентами, такими как GPS-приёмник и GSM-модем, требуется отдельный подход. Но для создания пользовательского интерфейса и, например, кода для работы по сети - компьютер более чем удобен.
Какой же компьютер с процессором ARM подойдёт? Неплох компьютер на процессоре Байкал-М, но он дороговат, и его ещё нужно поискать. А вот компьютер на основе Raspberry Pi можно назвать народным. Подойдёт 64-разрядный, то есть, начиная с версии Raspberry Pi 4. Мне достался Pi 400, и всё описанное ниже было опробовано именно на нём.
Ниже описан мой опыт написания простых тестовых программ для Р-ФОН, использующих различные графические инструментарии (Qt, PyQt, GTK3, GTK4, SDL2).
Читать далее
Читать: https://habr.com/ru/articles/976428/
@mobi_dev | Другие наши каналы
🙉4🤷2🌚1
Танцы с бубном, душевные терзания и комплекс супергероя: как мы новый редактор в «Заметках» разрабатывали
Привет, Хабр! Меня зовут Антон Макарычев, я ведущий инженер-программист в команде мобильной разработки kvadraOS. Сейчас мы с коллегами работаем над приложением «Заметки»: уже реализовали Drag-and-Drop между разными экранами в Compose, рисование на холсте, экспорт заметок в PDF или TXT и другие полезные функции. И сегодня я хочу рассказать, как рождалась наша ключевая функциональность — редактор.
Спойлер: в этой истории будет много боли, падений, преодолений и взлетов (без последнего у меня не осталось бы сил на статью). А еще расскажу про главную ошибку в выборе архитектурных решений, которую мы допустили и которая завела нас в тупик. Так что сможете научиться на нашем опыте!
Читать далее
Читать: https://habr.com/ru/companies/yadro/articles/974944/
@mobi_dev | Другие наши каналы
Привет, Хабр! Меня зовут Антон Макарычев, я ведущий инженер-программист в команде мобильной разработки kvadraOS. Сейчас мы с коллегами работаем над приложением «Заметки»: уже реализовали Drag-and-Drop между разными экранами в Compose, рисование на холсте, экспорт заметок в PDF или TXT и другие полезные функции. И сегодня я хочу рассказать, как рождалась наша ключевая функциональность — редактор.
Спойлер: в этой истории будет много боли, падений, преодолений и взлетов (без последнего у меня не осталось бы сил на статью). А еще расскажу про главную ошибку в выборе архитектурных решений, которую мы допустили и которая завела нас в тупик. Так что сможете научиться на нашем опыте!
Читать далее
Читать: https://habr.com/ru/companies/yadro/articles/974944/
@mobi_dev | Другие наши каналы
Скандалы, интриги, продуктовые метрики: что нам дало ускорение загрузки экрана в приложении hh
Привет! Меня зовут Саша Тотилас и я руковожу командой разработки в hh.ru. Хочу поделиться с Хабром результатами A/B-эксперимента: при оптимизации одного из экранов нашего приложения мы ускорили загрузку контента и выяснили, как это влияет на продуктовые метрики, а также собрали интересные инсайты.
Я не буду глубоко погружаться в технические детали, а сосредоточусь на подготовке эксперимента и интерпретации результатов. Статья будет полезна не только для мобильных разработчиков, но и для аналитиков и продактов.
Читать далее
Читать: https://habr.com/ru/companies/hh/articles/977376/
@mobi_dev | Другие наши каналы
Привет! Меня зовут Саша Тотилас и я руковожу командой разработки в hh.ru. Хочу поделиться с Хабром результатами A/B-эксперимента: при оптимизации одного из экранов нашего приложения мы ускорили загрузку контента и выяснили, как это влияет на продуктовые метрики, а также собрали интересные инсайты.
Я не буду глубоко погружаться в технические детали, а сосредоточусь на подготовке эксперимента и интерпретации результатов. Статья будет полезна не только для мобильных разработчиков, но и для аналитиков и продактов.
Читать далее
Читать: https://habr.com/ru/companies/hh/articles/977376/
@mobi_dev | Другие наши каналы
Мобильная разработка
Photo
Опенсорс-библиотека Implicits от Яндекс Браузера: новый шаг в передаче зависимостей Swift
Когда iOS‑приложение вырастает до сотен тысяч строк, появляется проблема: добавление зависимости в глубокий компонент требует изменений во всех промежуточных функциях. Эти функции зависимость не используют — они просто передают её дальше. Сигнатуры разбухают, рефакторинг превращается в массовую правку файлов, и значительная часть кода становится техническим шумом.
Проблема известна. Scala использует implicit parameters на уровне языка, Kotlin экспериментирует с context receivers, Android полагается на Dagger. А Swift не предлагает встроенного решения. Поэтому мы в команде Яндекс Браузера создали библиотеку Implicits — механизм неявной передачи зависимостей с compile‑time‑проверками. Она успешно работает в продакшне Браузера на полутора миллионах строк Swift‑кода, а ещё доступна в опенсорсе.
В этой статье я расскажу о поиске собственного подхода для передачи зависимостей в коде на Swift, о том, как внедрение Implicits позволяет существенно сократить boilerplate, ускорить рефакторинг и улучшить читаемость кода благодаря локальному объявлению только реально используемых зависимостей, а также покажу реальные примеры из продакшн‑кода мобильной версии Яндекс Браузера.
Читать далее
Читать: https://habr.com/ru/companies/yandex/articles/976898/
@mobi_dev | Другие наши каналы
Когда iOS‑приложение вырастает до сотен тысяч строк, появляется проблема: добавление зависимости в глубокий компонент требует изменений во всех промежуточных функциях. Эти функции зависимость не используют — они просто передают её дальше. Сигнатуры разбухают, рефакторинг превращается в массовую правку файлов, и значительная часть кода становится техническим шумом.
Проблема известна. Scala использует implicit parameters на уровне языка, Kotlin экспериментирует с context receivers, Android полагается на Dagger. А Swift не предлагает встроенного решения. Поэтому мы в команде Яндекс Браузера создали библиотеку Implicits — механизм неявной передачи зависимостей с compile‑time‑проверками. Она успешно работает в продакшне Браузера на полутора миллионах строк Swift‑кода, а ещё доступна в опенсорсе.
В этой статье я расскажу о поиске собственного подхода для передачи зависимостей в коде на Swift, о том, как внедрение Implicits позволяет существенно сократить boilerplate, ускорить рефакторинг и улучшить читаемость кода благодаря локальному объявлению только реально используемых зависимостей, а также покажу реальные примеры из продакшн‑кода мобильной версии Яндекс Браузера.
Читать далее
Читать: https://habr.com/ru/companies/yandex/articles/976898/
@mobi_dev | Другие наши каналы
Все не так с Codable
Привет, Хабр! На связи Кристиан Бенуа, iOS-разработчиĸ в Т-Банĸе. Быстродействие мобильных приложений — один из критериев, влияющих на успех не только приложения, но и всего бизнеса.
Особое внимание должно уделяться производительности кода в стандартной библиотеке языка, так как этот код используется почти во всех приложениях, которые написаны на этом языке.
Расскажу, как мы сделали pull request в swift-foundation и внесли несколько оптимизаций в
Читать далее
Читать: https://habr.com/ru/companies/tbank/articles/977694/
@mobi_dev | Другие наши каналы
Привет, Хабр! На связи Кристиан Бенуа, iOS-разработчиĸ в Т-Банĸе. Быстродействие мобильных приложений — один из критериев, влияющих на успех не только приложения, но и всего бизнеса.
Особое внимание должно уделяться производительности кода в стандартной библиотеке языка, так как этот код используется почти во всех приложениях, которые написаны на этом языке.
Расскажу, как мы сделали pull request в swift-foundation и внесли несколько оптимизаций в
JSONDecoder/JSONEncoder, ускорив сериализацию и десериализацию в два раза. В конце обсудим, как получить эту оптимизацию без ограничений по версии iOS и насколько можно ускорить работу с JSON в приложении.Читать далее
Читать: https://habr.com/ru/companies/tbank/articles/977694/
@mobi_dev | Другие наши каналы
EcoQuest: А кто это тут нагадил?
Шалом, любители кинуть бумажку мимо урны. Я честно пытался скормить написание этой статьи нескольким разным ИИ потому, что очень хочу спать. Но...
Пойти в лес за мусором...
Читать: https://habr.com/ru/articles/977916/
@mobi_dev | Другие наши каналы
Шалом, любители кинуть бумажку мимо урны. Я честно пытался скормить написание этой статьи нескольким разным ИИ потому, что очень хочу спать. Но...
Пойти в лес за мусором...
Читать: https://habr.com/ru/articles/977916/
@mobi_dev | Другие наши каналы
Мобильная разработка
Photo
OpenAI анонсировала функции ChatGPT, которые сделают поиск в Google бесполезным
ChatGPT получит визуальный поиск, интерактивные ответы и встроенные приложения, из-за которых привычный поиск Google может стать ненужным
— Читать дальше «OpenAI анонсировала функции ChatGPT, которые сделают поиск в Google бесполезным»
ChatGPT получит визуальный поиск, интерактивные ответы и встроенные приложения, из-за которых привычный поиск Google может стать ненужным
— Читать дальше «OpenAI анонсировала функции ChatGPT, которые сделают поиск в Google бесполезным»
🤔1
Мобильная разработка
Photo
Как мы перевернули подход к мобильным интерфейсам с Backend Driven UI
После того как наш парк вырос до более 245 тысяч самокатов и велосипедов, а команда сервисных центров начала исчисляться сотнями человек, стало ясно: управлять статусами устройств, задач и процессов в нашем внутреннем сервисном приложении по старинке уже не получится. Представьте себе: нужно изменить статус самоката или работы, а механик, специалист по контролю качества и бригадир — роли с разными функциями — видят одни и те же кнопки, одни и те же статусы, в которые можно перевести самокат. Иногда нажимают не туда — и ремонт идет не по желаемому процессу, что-то может потеряться, сроки увеличиваются… Добавим в уравнение еще разные версии мобильного приложения с различным набором кнопок — в какой-то версии кнопку убрали, в какой-то добавили. В итоге вся надежда только на бэкенд, перед которым встала задача контролировать и валидировать действие каждого пользователя в приложении.
В WCMA (Whoosh Control Maintenance App, писали о нем в предыдущей статье), нашем внутреннем приложении для управления флотом, мы столкнулись с этой проблемой в полной мере. Напомню, в этом приложении работает наша сервисная команда, через него мы обслуживаем самокаты и велосипеды в городе, следим за их зарядом, переставляем на спросовые парковки, а также восстанавливаем и чиним.
Одна из первых версий WCMA была больше похожа на пульт-отмычку для самоката, приложение не было интуитивным: все переводы доступны, а значит люди нажимали куда попало, часто новички путались в процессах и кнопках, в целом было мало контроля над действиями пользователей. Это могло вызывать ошибки “в полях” или при ремонте флота. Чтобы это исправить, мы завели большее количество ролей в системе, и каждая роль получила свой особенный раздел в WCMA. А для надежности добавили много проверок на бэкенде, валидирующих действия команды.
Такой подход работал, статусная модель была простой: несколько базовых состояний и переходы между ними. Но с ростом бизнеса логика усложнилась. Появились региональные особенности работы в разных городах, ролевые ограничения, условные переходы, зависящие от контекста.
Меня зовут Игорь Волынский, я backend-разработчик в команде WCMA Whoosh. И сегодня я расскажу, как мы решили эту проблему: построили централизованную и гибкую систему управления статусами, добавили условные переводы с хендлерами для проверки бизнес-правил и реализовали динамические сценарии для гибкого формирования UI. Спойлер: теперь наши механики и менеджеры видят только те действия, которые им реально доступны, а бэкенд гарантирует целостность данных на уровне системы.
Читать про формирование UI через бэкенд
Читать: https://habr.com/ru/companies/whoosh/articles/977814/
@mobi_dev | Другие наши каналы
После того как наш парк вырос до более 245 тысяч самокатов и велосипедов, а команда сервисных центров начала исчисляться сотнями человек, стало ясно: управлять статусами устройств, задач и процессов в нашем внутреннем сервисном приложении по старинке уже не получится. Представьте себе: нужно изменить статус самоката или работы, а механик, специалист по контролю качества и бригадир — роли с разными функциями — видят одни и те же кнопки, одни и те же статусы, в которые можно перевести самокат. Иногда нажимают не туда — и ремонт идет не по желаемому процессу, что-то может потеряться, сроки увеличиваются… Добавим в уравнение еще разные версии мобильного приложения с различным набором кнопок — в какой-то версии кнопку убрали, в какой-то добавили. В итоге вся надежда только на бэкенд, перед которым встала задача контролировать и валидировать действие каждого пользователя в приложении.
В WCMA (Whoosh Control Maintenance App, писали о нем в предыдущей статье), нашем внутреннем приложении для управления флотом, мы столкнулись с этой проблемой в полной мере. Напомню, в этом приложении работает наша сервисная команда, через него мы обслуживаем самокаты и велосипеды в городе, следим за их зарядом, переставляем на спросовые парковки, а также восстанавливаем и чиним.
Одна из первых версий WCMA была больше похожа на пульт-отмычку для самоката, приложение не было интуитивным: все переводы доступны, а значит люди нажимали куда попало, часто новички путались в процессах и кнопках, в целом было мало контроля над действиями пользователей. Это могло вызывать ошибки “в полях” или при ремонте флота. Чтобы это исправить, мы завели большее количество ролей в системе, и каждая роль получила свой особенный раздел в WCMA. А для надежности добавили много проверок на бэкенде, валидирующих действия команды.
Такой подход работал, статусная модель была простой: несколько базовых состояний и переходы между ними. Но с ростом бизнеса логика усложнилась. Появились региональные особенности работы в разных городах, ролевые ограничения, условные переходы, зависящие от контекста.
Меня зовут Игорь Волынский, я backend-разработчик в команде WCMA Whoosh. И сегодня я расскажу, как мы решили эту проблему: построили централизованную и гибкую систему управления статусами, добавили условные переводы с хендлерами для проверки бизнес-правил и реализовали динамические сценарии для гибкого формирования UI. Спойлер: теперь наши механики и менеджеры видят только те действия, которые им реально доступны, а бэкенд гарантирует целостность данных на уровне системы.
Читать про формирование UI через бэкенд
Читать: https://habr.com/ru/companies/whoosh/articles/977814/
@mobi_dev | Другие наши каналы
🔥21❤7💯4🦄2⚡1👍1
Мобильная разработка
Photo
GTA: Vice City запустили прямо в браузере — без установки. Поиграть можно даже со смартфона
GTA Vice City запустили прямо в браузере без установки: игра работает на ПК и смартфонах, быстро загружается и требует лицензионные файлы
— Читать дальше «GTA: Vice City запустили прямо в браузере — без установки. Поиграть можно даже со смартфона»
GTA Vice City запустили прямо в браузере без установки: игра работает на ПК и смартфонах, быстро загружается и требует лицензионные файлы
— Читать дальше «GTA: Vice City запустили прямо в браузере — без установки. Поиграть можно даже со смартфона»
🔥5
Мобильная разработка
Photo
В Rust-коде ядра Linux нашли опасный баг, приводивший к kernel panic
В Rust-коде ядра Linux обнаружили опасный баг в Binder, приводивший к повреждению памяти и kernel panic. Исправление уже включено в стабильные обновления
— Читать дальше «В Rust-коде ядра Linux нашли опасный баг, приводивший к kernel panic»
В Rust-коде ядра Linux обнаружили опасный баг в Binder, приводивший к повреждению памяти и kernel panic. Исправление уже включено в стабильные обновления
— Читать дальше «В Rust-коде ядра Linux нашли опасный баг, приводивший к kernel panic»
❤4
От ощущений к цифрам: как мы внедрили метрики перформанса в андроид приложение
Всем привет! Меня зовут Тимур, я платформенный Android-разработчик с опытом 5+ лет в ритейле и e-com.
В этой статье разберём, почему перформанс на мобильных устройствах это не ощущения, а фактор, который влияет на конверсию и GMV. Покажу, какие метрики имеет смысл собирать на клиенте, как их мониторить, и приведу примеры кода для Android.
Присаживайтесь, наливайте чай/кофе — поехали.
Читать далее
Читать: https://habr.com/ru/articles/978170/
@mobi_dev | Другие наши каналы
Всем привет! Меня зовут Тимур, я платформенный Android-разработчик с опытом 5+ лет в ритейле и e-com.
В этой статье разберём, почему перформанс на мобильных устройствах это не ощущения, а фактор, который влияет на конверсию и GMV. Покажу, какие метрики имеет смысл собирать на клиенте, как их мониторить, и приведу примеры кода для Android.
Присаживайтесь, наливайте чай/кофе — поехали.
Читать далее
Читать: https://habr.com/ru/articles/978170/
@mobi_dev | Другие наши каналы