
Apple по доброте душевной поделилась с разработчиками инструментом отладки SwiftUI. Удобный он или не очень — разберёмся вместе с Surf iOS Team.
Открытый объектно-ориентированный язык
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-разработчик приложения для среднего и малого бизнеса ПСБ. Наше приложение состоит из различных модулей и внутренних библиотек, которые связаны между собой, поэтому важно сохранять гибкость и обратную совместимость во время разработки. В этой статье мы разберемся, как вносимые изменения нарушают эти правила, а также как это исправить.
Меня зовут Дима, я iOS инженер-менеджер в крупнейшем телеком-операторе Казахстана. У нас 19 разработчиков — и билд-тайм для нас важная составляющая разработки. В этой статье я пройдусь по следующему пути:
• рассмотрю стратегии, которые вы сможете сразу применить;
• покажу реальные цифры из наших проектов;
• сделаю выводы и поделюсь инсайтами.
В данной статье не будет подробного разбора кода, я добавил краткие примеры, чтобы у тебя (если ты новичок), было представление о том, как выглядит в коде та или иная технология. Следуя этому плану, обращаясь к указанным ресурсам, можно уверенно дойди до уровня Junior и начать поиск свой первой работы.
Почему стоит выбрать iOS-разработку?
iOS-разработка остается одним из самых востребованных направлений в IT. Спрос на специалистов растет, зарплаты остаются высокими, а сам процесс разработки комфортный благодаря экосистеме Apple. Не стоит бояться разговоров о том, что рынок перегрет, главное знать зачем вы это делаете и просто дойди до конца.
💰 Сколько зарабатывают iOS-разработчики в России в 2025 году?
• Junior – 120 000–180 000 ₽
• Middle – 250 000–350 000 ₽
• Senior – от 400 000 ₽ и выше
Но чтобы получить первый оффер, нужно освоить Swift, UIKit, сетевое взаимодействие, архитектуры (у вас должно быть понимание, для чего та или иная архитектура, основные сущности, не обязательно глубоко разбираться) и основы хранения данных. Давай разберемся, с чего начать.
1. Изучение Swift и основ программирования
Swift – это современный язык программирования от Apple. На нем пишут приложения для iOS, macOS, watchOS и tvOS.
📌 Что нужно изучить в первую очередь?
✅ Основы (переменные, типы данных, операторы)
✅ Управляющие конструкции (if, switch, for, while)
✅ Коллекции (Array, Set, Dictionary)
✅ Опционалы (Optional, nil, guard let, if let)
✅ Основы ООП (классы, структуры, наследование, протоколы)
✅ Управление памятью (ARC, weak, strong, unowned)
Аутентификация в мобильных приложениях с помощью Telegram Login Widget обделена информацией как официальной документации, так и в интернете. В этой статье поделюсь примером реализации входа в iOS приложение c помощью Telegram. В статье приведены сниппеты кода на Typescript + React, Go и Swift.
В этой статье мы рассмотрим различные подходы для работы с небезопасными операциями в языке программирования Swift. Swift предоставляет несколько способов для работы с указателями и низкоуровневой памятью.
Всем привет, меня зовут Ибрагим, я iOS разработчик одной из команд мобильного банкинга и это моя первая статья для Хабра, поэтому прошу строго не судить.
Сегодня хочу рассказать Вам, как мы пилили дробили монолит на SPM пакеты и создавали дизайн систему.