Привет!
Меня зовут Антон, и я занимаюсь автоматизацией тестирования Web и Mobile приложений.
Если вы начинаете автоматизировать UI-тесты под iOS, то наверняка заметили, что информации по фреймворку XCUITest в сети не так много, особенно на русском языке.
Эта статья — краткое руководство по основам автоматизации на XCUITest. Здесь я постарался собрать ключевые моменты, которые помогут вам сделать первые шаги в UI тестировании iOS-приложений.
В рамках исполнения законодательства ЕС о цифровых рынках (DMA) Apple с марта 2024 года обязана предоставлять «альтернативные каналы» дистрибуции и оплаты для «читательских» приложений и ряда других категорий. Для этого разработчики в Европе заключают отдельное дополнение к договору (Alternative Terms Addendum) и получают специальные права на использование внешних платежей
Появление unit- и UI-тестов неизбежно в крупных мобильных приложениях: появляется новая функциональность, старая расширяется, изменяются существующие элементы. Для стабильной работы команда вынуждена внедрять автотесты, что требует инфраструктуры, инструментов, а также времени и внимания для их реализации.
Размышляя над этим, пришла идея использовать LLM для автоматической генерации тестов. Это могло бы снизить нагрузку на разработчиков и минимизировать влияние автотестов на time to market новых фич. Меня зовут Марк, я iOS-разработчик Lamoda Tech. Ранее я рассказывал о своем опыте поиска решений с использованием GPT и Copilot в UI-тестах.
Привет, Хабр! Меня зовут Алексей Григорьев, я техлид iOS-разработки продукта Membrana в МТС. Это тариф с приложением для управления приватностью в сети и окружением.
Swift Concurrency принесла множество инструментов для управления многопоточностью. Среди них глобальные акторы, которые помогают обеспечивать безопасность данных и контролировать потоки выполнения.
Один из самых распространенных и полезных глобальных акторов — это @MainActor, который гарантирует выполнение операций в главном потоке приложения. В этом посте я на его примере покажу все варианты, как можно реализовать изоляцию и что в итоге выведет код: на каком потоке будут выполнены update, internal update и set в property.
Привет! Меня зовут Андрей Максимкин, я iOS-разработчик в hh. Мы в команде активно используем async/await подход при написании нового кода, а также активно применяем при переписывании старого. В процессе работы сталкивались с некоторыми интересными и не самыми очевидными моментами — их и рассмотрим в статье.
Работа с различными потоками — очень важная часть разработки мобильных приложений под iOS. Грамотное распределение нагрузки положительно влияет на скорость работы приложения, а значит, и на пользовательский опыт. До Swift 5.5 для работы с многопоточностью в основном использовали фреймворки GCD и NSOperation. Начиная с версии Swift 5.5 стал доступен функционал async/await. В статье мы кратко расскажем о базовых принципах данного подхода и сделаем акцент на проблемах и особенностях, которые необходимо знать при написании кода. Информация будет полезна тем, кто уже знаком с функционалом async/await, а некоторые примеры могут быть интересны и более продвинутым разработчикам.
Apple по доброте душевной поделилась с разработчиками инструментом отладки SwiftUI. Удобный он или не очень — разберёмся вместе с Surf iOS Team.
В мобильную разработку приходят различными путями. Некоторые рождаются с девайсом в руках, других ведет извилистая дорога вдоль серверов, майнфреймов, дестопных приложений. Но каждый кто в нее попадает ощущает свою незащищенность с тыла, если нет надежного партнера в лице бэкенд ‑разработчика. И, буквально, каждый мобильщик ожидает, что необходимый API будет готов хотя бы за один спринт, до того, как в нем возникнет необходимость. Конечно же, мир IT разработки редко допускает такую роскошь — за нее требуется бороться с ПМ и бизнес‑аналитиком. К тому же не редки ситуации, когда то, что должно быть сделано «на вчера», будет готово «на послезавтра». Те кто имеют достаточно опыта как в наземном, так и подземном мире — берут инициативу с свои руки, и сами предлагают клиент‑серверный интерфейс.
Для мобильного мира C# и Java — падения из рая в ад — это довольно естественный процесс, поскольку присущие им платформы изначально целились на поддержку темных сил бэкенда. То ли дело Swift — познавшему небо — не легко дается жизнь на льдине, вместе с ластоногими.
Получить лучшее из обоих миров, и не потерять темп позволяют некоторые экзотические решения, наподобие Perfect и Vapor. Однако, они в большей степени отвечают на вопрос «Как?» вместо того, чтоб предложить какое‑нибудь удовлетворительное минимальное решение. С другой стороны, как правило, исходные требования мобильной команды довольно умерены и стереотипны от одного приложения к другому. Обычно требуется поддержка и управления такими сущностями как аккаунт пользователя, профиль, продукт и изображения.
Навигация при помощи текстовой строки внутри приложения может и не быть самым удобным способом для разработчика, но когда строковое значение приходит из вне приложения — это едва ли не самый надежный вариант переместить пользователя внутрь вложенной системы иерархии экранов. Вместе с тем, довольно часты ситуации, когда вместе с путем навигации передаются еще и параметры, с которыми экран должен быть отображен. Если схема координатора задана через перечисление, то возникает неоднозначность — либо координатор не может быть развернут исходя из названий элементов перечисления, либо, конкретные координаторы будут унаследованы от типа String, но параметры не могут быть переданы как ассоциированные значения.
Использование концепции MVVM порождает еще один философский вопрос: может ли один и тот же экран с одной и той же viewmodel иметь различные типы входных параметров. Конечно, для идеологии чистого кода — ответ однозначен. Но ведь если нет нужды в создании нового вида или новой view model, то подавляющее количество разработчиков предпочтет переиспользовать один и тот же экран и для отображения десериализированного объекта, и для сериализированных параметров, передаваемых строкой в пути навигации.
Вторая статья из цикла об идеях воспроизведения и редаĸтирования медиа с
использованием AVFoundation. В ней разберём тему сложных ассетов.
В этой статье мы сосредоточимся на создании фитнес-приложения с использованием HealthKit. Это отличная возможность интегрировать данные о здоровье пользователей прямо в ваш продукт. Мы настроим фреймворк для отслеживания тренировок на Apple Watch; узнаем, как получить доступ к данным о физической активности и управлять ими, сохраняя при этом конфиденциальность пользователей.
Gemini 2.5 Experimental воспроизводит в SwiftUI с поразительной точностью стили текста и функциональные возможности прототипов, подготовленных дизайнерами в Figma. Особенно это касается разработки русскоязычных UI.
Выдаёт полноценный изобретательный SwiftUI код, демонстрируя высокий потенциал Gemini 2.5 в преобразовании Figma-макетов в рабочий iOS-код.
Первая статья из циĸла об идеях воспроизведения и редаĸтирования медиа с
использованием AVFoundation. В ней рассмотрим главный объеĸт работы с медиа –
простой ассет.
Вот я и добралась до Copilot (знаю, поздно, всё руки не доходили установить). Было жутко интересно, чем конкретно он мне может помочь в написании кода. Так что, ХаброКотаны, кому интересно, приглашаю вас почитать дальше.
P.S. Обложку, кстати, сделал гпт в стиле гибли из моей фоточки.
Для атомарного перемещения внутрь иерархии вложенных вью весьма удобно, и, главное, просто использовать путь в виде строки. К примеру, строка вида «/auth/a//b/c/profile/a/c» открывает экран «c» в иерархии экранов «profile», что позволяет откатываться назад по «back» аж до самого корня, проходя через каждый экран. А легкое изменение строки на «/profile/c» откроет только нужный экран без остальных степеней вложенности.
История развития асинхронного программирования в языке Swift. Можно относиться к этому как к расследованию нераскрытого дела.
Использование координатора совместно с NavigationStack является общепризнанной практикой на протяжении последних трех лет -- быстро, удобно, надежно. Однако, в том случае если выбор конечных точек пути описывается перечислением, то по мере роста размеров проекта, начинает разрастаться и класс координатора. Пока количество конечных экранов приложения находится в пределах пяти десятком – это не является проблемой, поскольку Pascal/Camel/Snake нотация легко секционирует группы экранов. Но на долгих проектах количество экранов переваливает за 2-3 сотни, и, в этом случае, перечисления на несколько сот строк становятся проблемой. Особенно, тогда, когда над проектом работает команда разработчиков.
Когда-то презентации новых iPhone и флагманов на Android приковывали внимание. Теперь же люди шутят, что там под бесконечное «amazing» показывают то же, что и годом ранее. Сногсшибательных инноваций уже не происходит, о чём тогда гордо говорить на камеру?
С мобильными конференциями иначе. Там ожидают услышать не новую сенсацию, а полезный контент, помогающий мобильным разработчикам лучше выполнять свою работу. И вот такой контент с годами не закончился: тут всегда есть, куда копать. А по его темам можно отследить, как с годами разработка менялась.
Мы впервые провели Mobius в 2014-м, ещё до появления iPhone X и Google Pixel. В апреле проведём его в очередной раз (в Москве с возможностью онлайн-участия). Каким именно контент будет на этот раз?
Программа уже готова, и представляем Хабру краткие описания докладов. Даже если вы сами не собираетесь участвовать в конференции, пробежаться взглядом всё равно может быть любопытно: это позволит понять, чем вообще живёт российская мобильная разработка в 2025-м.
Toolbox был переписан с использованием лучших инструментов в экосистеме и новейших функций Swift, и теперь он стал еще более мощным, чем когда-либо!
Старый Toolbox
Vapor Toolbox - это инструмент командной строки, который используется для решения распространённых задач при работе с Vapor, таких как создание, компоновка, запуск и развёртывание проектов.
В настоящее время большинство подкоманд Toolbox устарели, поскольку Swift и экосистема эволюционировали, предоставляя более совершенные инструменты для решения этих задач. Единственная функция, которая по-прежнему очень полезна, - это команда new, которая используется для создания новых проектов Vapor на основе шаблонов.
Шаблоны Toolbox - это репозитории Git, содержащие проект Vapor, и они используют Mustache для замены заполнителей(placeholders) пользовательским вводом. Для создания шаблонов Mustache в Toolbox использовалась библиотека, поддерживаемая сообществом Vapor, которая представляет собой Swift-оболочку для синтаксического парсера mustach, написанную на C.
Toolbox был создан с использованием ConsoleKit, библиотеки, созданной командой Vapor, которая предоставляет API для создания интерактивных инструментов CLI, разработанных до появления Swift Argument Parser. Возможности ConsoleKit по обработке аргументов в настоящее время считаются устаревшими, и вместо них рекомендуется использовать Swift Argument Parser.
Переписывание Toolbox
Все устаревшие подкоманды были удалены, и единственная оставшаяся функция - это команда new.
Мы заменили оболочку mustach на swift-mustache от Hummingbird, которая представляет собой библиотеку рендеринга Mustache, полностью написанную на Swift.
На недавно завершившейся конференции Let's Vision 2025 я получил множество вопросов о SwiftData: «Достаточно ли SwiftData развита, чтобы использовать ее в реальных проектах?» и „Как начинающему разработчику эффективно использовать SwiftData?“. Эти вопросы не только отражают живой интерес разработчиков к новейшему фреймворку Apple для хранения данных, но и свидетельствуют о нерешительности при выборе технологии.
Эта статья призвана стать руководством для разработчиков, заинтересованных в SwiftData, и помочь вам понять ее сильные стороны и ограничения, чтобы вы могли принимать обоснованные решения, исходя из потребностей вашего проекта. Независимо от того, рассматриваете ли вы возможность использования SwiftData в новом проекте или планируете переход с другого устоявшегося решения, приведённый ниже материал может помочь в процессе выбора.
Привет, Хабр! Меня зовут Дмитрий Сурков, я iOS-разработчик приложения для среднего и малого бизнеса ПСБ. Наше приложение состоит из различных модулей и внутренних библиотек, которые связаны между собой, поэтому важно сохранять гибкость и обратную совместимость во время разработки. В этой статье мы разберемся, как вносимые изменения нарушают эти правила, а также как это исправить.
