iOS *

Привет! Я Валерия Кудрявцева, iOS-разработчик в KTS. Пора поговорить о новинке.

9 сентября 2026 года Apple представила iPhone Duo, свой первый складной смартфон. Пока пользователи обсуждали новый форм-фактор, у нас, iOS-разработчиков, вопрос был другой: как поддерживать приложение на устройстве с двумя экранами и сгибом. Для нас Apple подготовила раздел HIG о проектировании под Duo, шесть Tech Talks и хаб Get Ready for iPhone Duo.

Статья основана на опубликованных Tech Talks Apple. Xcode 27.1 beta на момент подготовки ещё не вышел, поэтому возможности 27.1 описаны по презентациям. Проверить их на практике нужно после выхода SDK.

Сразу оговорюсь. По информации Apple, существующие приложения запустятся на Duo и без пересборки. Но адаптацию интерфейса это не отменяет: то, как приложение займёт внутренний дисплей и как поведут себя стандартные панели, зависит от SDK, с которым оно собрано. Различия разберу ниже.

Отдельный интерфейс под каждую pose Duo делать не нужно. А вот допущения в текущей вёрстке проверить придётся. Если код берёт доступное пространство из модели устройства или ориентации и считает отступы симметричными, на Duo такие расчёты дадут неверный результат. Основа остаётся одна: адаптивный UI, который смотрит на размер текущего окна и на size class.

Дальше разберу изменения iOS 27, что система сделает сама и что нужно править в коде, новые API 27.1 и типичные ошибки при аудите. В конце сравню подходы с Android foldable и расскажу, что из этого уже есть в Compose Multiplatform.

Привет, Хабр! На связи Владимир Бойко, ведущий iOS‑разработчик в Т‑Банке. В статье расскажу, как мы построили AI‑QA‑агента, который проходит тест‑кейсы так же, как это делает человек: запускает приложение на симуляторе, выполняет сценарий шаг за шагом, анализирует экраны с помощью VLM и автоматически сравнивает ожидаемый результат с фактическим.

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

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

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

Звучит как противоречие: iPad стал вполне рабочим инструментом разработчика, а собрать под него (и под iPhone) приложение всё равно нельзя без Mac. Xcode — единственная официальная среда сборки и подписи iOS-приложений — существует только под macOS, и Apple явно не планирует это менять. Значит ли это, что весь цикл разработки придётся выполнять, сидя за компьютером? Нет — если Mac всегда доступен по сети, а с iPad до него можно дотянуться удалённо.

Vivaldi предоставляет вам все необходимые инструменты для работы в сети. С нашим последним обновлением Vivaldi 8.2 мы даём вам больше — с полной поддержкой расширений на Android, так что вы можете настроить свой мобильный браузер именно так, как вам нужно.

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

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

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

В такой среде архитектура нужна не для красивой схемы. Она нужна, чтобы изменения были дешёвыми.

Идущий в составе iOS калькулятор показывает округлённый результат. Constructive Calculator всегда готов показать следующую значащую цифру, так же, как калькулятор Android.

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

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

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

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

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

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

Прошел месяц. Докладываю обстановку)

Скажу честно, я сама не до конца верила, что это произойдет, но мировые гиганты продолжают медленно но верно затягивать гайки. Наверное, только ленивый не видел новостей о том, что в Android появляется замечательная функция (Developer Verification), которая заставляет 24 часа ждать перед установкой стороннего приложения через APK. Не прошло и недели, как новостные ленты наводнили сообщения о запрете iMazing и других сервисов для устройств Apple — а именно они позволяли устанавливать запрещенные американцами программы, которыми пользуются у нас в стране. Меня эта новость зацепила, как говорится, "по живому", потом что я как раз решила переустановить приложение Сбера...и не смогла! Поэтому я, скрепя зубами, все-таки решила слезать с iOS и попыталась выяснить, какой смартфон можно купить, чтобы в ближайшем будущем он не превратились в тыкву. Под катом делюсь всей информацией, какую нашла.

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

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

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

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

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

В этом дайджесте надежное выполнение фоновых задач в 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.

Попросил Claude написать таймер одним HTML-файлом — а телефон его не будит: вкладка спит, будильник не звонит. Сделал Kapsula: приложение для Android и iOS, которое запускает такой файл как проект с настоящими будильниками ОС через мост из пяти методов. Внутри — iframe без same-origin, postMessage-RPC, три грабли Android-уведомлений, звук на iOS, правило состояния для ИИ-кода и промпт вместо SDK. Без сервера, без аккаунта, без аналитики.

Привет!

Представьте, что вы с удовольствием пишите один код на все платформы на Kotlin Multiplatform, и вдруг приходит задача «синкать данные раз в час, только по вайфаю и когда телефон на зарядке».

Под Android вы берёте WorkManager и за пятнадцать минут закрываете тикет. Потом яблочный смежник открывает документацию по BGTaskScheduler и обнаруживает, что модель там вообще другая и работает всё по-другому: нет очереди задач, есть окна, которые система выдаёт по своему усмотрению и т. д.

В итоге в проекте появляется expect fun scheduleSync() с разными реализациями, которые ведут себя по-разному, и никто в команде через год не сможет сказать, что именно произойдёт на iOS, если приложение свернули посреди загрузки.

Так как я андроидер с альтернативным мышлением, мне нравится API WorkManager'а. Я захотел его скопировать под KMP, породив так называемый Kotlin Multiplatform Work Manager или же Jabbit (job + rabbit, да, я знаю) — планировщик фоновых задач для KMP.

Таргеты: Android, iOS, js и wasmJs. Как будет время и желание, появится ещё и декстоп.

В новом выпуске 136 уровней вложенности XCUITest и Android Runtime под капотом, как Tinder сократил холодные старты на 47% и новые условия распространения приложений в Евросоюзе, от Event-Driven UI к State-Driven UI, что нового в Dart, как сделать MCP удобными и действительно полезными, уменьшение трения в приложениях и многое другое. Заходите!

React Native по-прежнему часто описывают формулой «один код для iOS и Android». В 2026 году она звучит слишком просто. Современное приложение на React Native — это общий продуктовый слой на TypeScript, нативный интерфейс, Hermes, Fabric, JSI, фоновые процессы, platform-specific код и довольно много решений о том, где именно должна выполняться каждая задача.

Мы столкнулись с этим в Synchra.24 — мобильном приложении для линейных и распределённых команд. В проекте больше тысячи TS/TSX-файлов и свыше ста экранов, но рядом с ними живут Kotlin и Swift: геопозиция, push-уведомления, биометрия, системные виджеты и работа с медиа. Это не история о функциях нашего продукта и не попытка его рекламировать. Это разбор того, чем на практике стала разработка на React Native к 2026 году — и какую часть этой работы действительно можно поручить нейросетям.

В октябре прошлого года на Хабре вышла статья «Как я писал свою звонилку для видеозвонков» — автор под ником CEOCTO за несколько вечеров написал P2P-видеозвонилку на WebRTC, потому что его достали обрывающиеся созвоны в мессенджерах. Я прочитал, улыбнулся, полез смотреть исходники на GitHub — и на этом всё. Как обычно бывает с чужими pet-проектами: оценил, закрыл вкладку, забыл