iOS *

Вот и время для заключительной статьи этого цикла. В предыдущих статьях мы рассмотрели нашу мотивацию, всю техническую информацию и поделились инсайтами при создании масштабируемого бизнес-решения в виде кроссплатформенного SDK. В этой небольшой статье хотелось уделить внимание иным аспектам, таким как адаптация процессов команды KMP и смежных команд, которые являются заказчиками, немного поговорить про подходы к тестированию и контролю качества, CI/CD и т.д.

Кратко напомним про контекст и продукт: Instories — мобильный видеоредактор для маркетологов, SMM-специалистов и блогеров. Контекст проекта: желание получить ряд SDK (мы называем их Kit-ами, по сути это разные сборки SDK для разных продуктов, со своими ресурсами, фичами и дизайн системой) для наших уже существующих приложений, которые содержали бы в себе коробочные фичи (и бизнес-логику, и UI), готовые к подключению, а также были бы легко расширяемыми и переиспользуемыми для разных приложений компании.

В предыдущих статьях мы рассматривали технические и архитектурные аспекты при создании Kotlin Multiplatform SDK, но немаловажной частью остается работа с UI и ресурсами в таком SDK, особенно если он поставляется сразу в несколько продуктов.

Да, в Compose Multiplatform есть базовая работа с ресурсами: можно работать со строками, картинками и файлами по аналогии с Android проектами, однако что делать, когда для каждого продукта под одним и тем же ключом локализации должна срываться своя строка? В этой статье мы поделимся своим подходом и инсайтами.

Кратко напомним про контекст и продукт: Instories — мобильный видеоредактор для маркетологов, SMM-специалистов и блогеров. Контекст проекта: желание получить ряд SDK (мы называем их Kit-ами, по сути это разные сборки SDK для разных продуктов, со своими ресурсами, фичами и дизайн системой) для наших уже существующих приложений, которые содержали бы в себе коробочные фичи (и бизнес-логику, и UI), готовые к подключению, а также были бы легко расширяемыми и переиспользуемыми для разных приложений компании.

В предыдущих статьях (раз и два) мы рассмотрели, почему выбрали Kotlin Multiplatform для нашего SDK, а также подробно разобрали базовую архитектуру проекта, включая core-модули и организацию Kit-ов. Теперь настало время погрузиться в самое интересное — архитектуру отдельной фичи и то, как мы организовали взаимодействие между модулями.

Эта статья будет особенно полезна тем, кто хочет понять, как на практике реализовать feature-first подход в KMP проекте, как правильно организовать DI, навигацию и работу с ресурсами в многомодульной архитектуре.

Кратко напомним контекст и продукты: Instories — мобильный видеоредактор для маркетологов, SMM-специалистов и блогеров. Контектс проекта: желание получить ряд SDK (мы называем их Kit-ами, по сути это разные сборки SDK для разных продуктов, со своими ресурсами, фичами и дизайн системой) для наших уже существующих приложений, которые содержали бы в себе коробочные фичи (и бизнес-логику, и UI), готовые к подключению, а также были бы легко расширяемыми и переиспользуемыми для разных приложений компании.

В прошлой статье было много текста о том, почему мы стали смотреть в сторону кроссплатформенной разработки и почему мы в Instories выбрали именно Kotlin Multiplatform (далее — KMP) для своего решения.

Кратко напомним контекст и продукты: Instories — мобильный видеоредактор для маркетологов, SMM‑специалистов и блогеров. Контектс проекта: желание получить ряд SDK (мы называем их Kit‑ами, по сути это разные сборки SDK для разных продуктов, со своими ресурсами, фичами и дизайн системой) для наших уже существующих приложений, которые содержали бы в себе коробочные фичи (и бизнес‑логику, и UI), готовые к подключению, а также были бы легко расширяемыми и переиспользуемыми для разных приложений компании.

Мы выбрали использовать многомодульную архитектуру, чтобы каждая фича была инкапсулирована в своем модуле и не влияла на другие фичи, а также разделили проект на несколько крупных пакетов: kits, core и feature. В данной статье мы рассмотрим первые два пакета с технической точки зрения, а также поделимся причинами и инсайтами для выбранных решений.

В современном мире мобильной разработки скорость вывода новых функций на рынок становится критическим фактором успеха. Особенно это актуально в контексте быстро развивающихся технологий, таких как AI, где промедление может стоить конкурентного преимущества. Рассказывать будем на примере нашего продукта Instories — мобильного видеоредактора для маркетологов, SMM-специалистов и блогеров.

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

Именно с такими вызовами столкнулась наша команда, когда мы начали искать способы оптимизации процесса разработки для iOS и Android платформ.

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

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

Мы решили сделать навигацию нагляднее — с помощью AR прямо через камеру смартфона. Сейчас технология доступна в столичных торговых центрах «Авиапарк», «Афимолл», «Европейский» и в «Галерее» в Петербурге.

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

Привет, Хаброжители! Хотите писать код один раз и запускать его на Android и iOS, сохранив нативное качество и производительность?

В этой книге вы освоите все шаги разработки полнофункциональных кросс-платформенных приложений с помощью Kotlin Multiplatform SDK — от создания проекта с нуля до миграции существующих нативных решений. Подробные инструкции, архитектурные подходы и реальные примеры помогут уверенно работать с общими модулями, многопоточностью, сетевым слоем, хранением данных и Compose Multiplatform для iOS.

Особое внимание уделено использованию нативного и общего кода в кросс-платформенном приложении, применению expect/actual, тестированию с Kotest, оптимизации разработки с помощью KSP, плагинов компилятора и ИИ-ассистентов. Вы узнаете, как создавать и публиковать собственные KMP-библиотеки, а также получите краткий справочник по Kotlin и Swift, чтобы уверенно ориентироваться в обеих экосистемах.

Привет, Хабр! В прошлой статье мы поговорили о строках в Swift - об их особенностях, внутреннем устройстве и подводных камнях. И я подумал: ведь строки это по сути - коллекции. А какая главная и самая популярная коллекция в Swift? Конечно же, массивы. Их используют повсюду. Но вы когда-нибудь задумывались, как они устроены внутри? Давайте погрузимся внутрь массивов и посмотрим, что они из себя представляют.

Это история о том, как я превратил свой старый iPhone 8 в OCR-сервер на солнечных батареях, используя фреймворк Apple и зарядную станцию EcoFlow River 2 Pro. Он месяцами напролёт работает в режиме 24/7, обрабатывая тысячи изображений на полностью автономном питании.

За год с лишним мой сервер обработал 83 418 запросов на распознавание текста (OCR) и 48 ГБ изображений, используя только фреймворк Apple Vision и возобновляемую энергию. Большинство людей после апгрейда закидывают свои старые iPhone в ящик. Но не я. Я превратил свой телефон в сервер, который экономит мои деньги, работая полностью автономно.

Мог ли я просто запустить этот сервер на своём маке, как нормальный человек? Конечно же. Но разве это весело?

В этом выпуске рассуждения о месте Rust в iOS и MAX в Android, погружение в JNI и опыт Shopify с React Native, архитектурный сдвиг оффлайна, быстрый старт в CI, мобильный рынок Турции, продукты для бумеров и многое другое. Заходите!

Спойлер: сократили размер приложений на 44% и ускорили их запуск в среднем на 51%.

Привет, Хабр! Меня зовут Владислав Сединкин, я занимаюсь iOS 10 лет и последние 2 года работаю в мобильной Core-команде Туту. В этом году мы решили сменить менеджер зависимостей и мигрировать с CocoaPods на SPM. Результаты оправдали ожидания, хотя и сложности на этом пути, конечно, были. В статье расскажу про проблемы, с которыми мы столкнулись в процессе, и предупрежу, на что стоит обратить внимание, чтобы не повторить наши ошибки.

Привет! Меня зовут Даниил, я работаю в команде SDK в VK. Одно из направлений, которым занимается наша команда, — разработка SDK для авторизации через сервисы экосистемы VK. Он состоит из нескольких компонентов: авторизации, логина в один клик, шторки для входа с более удобным интерфейсом и поддержкой Mail и OK как провайдеров авторизации. 

Мы давно задумывались о поддержке Flutter, поскольку это быстроразвивающаяся платформа, которой уже пользуется много клиентов. Было видно, что поддержка Flutter нужна клиентам, даже на фрилансовых биржах публиковали заказы на поддержку VK ID. Логичным поступком стало сделать официальное решение от VK, чтобы клиентам не приходилось делать одинаковую работу. В этой статье поделюсь опытом поддержки Flutter в нашем SDK. Статья будет полезна любому разработчику, который хочет добавить поддержку Flutter в свою библиотеку. Материал рассчитан на разработчиков, которые ничего не знают о Flutter и будут разбираться с ним с нуля. Приведены примеры кода только под Android, поскольку под iOS всё делается аналогично.

Existential container — это структура данных в рантайме, которая хранит значение типа скрытого за протоколом. Он появляется там, где мы используем название протокола в качестве типа переменной или аргумента функции. С помощью existential container реализован динамический вызов методов протокола, а также управление жизненным циклом внутренного значения типа.

Тестирование на Swift долгие годы держалось на трех китах: XCTest, сторонние библиотеки и собственная смекалка. Но на WWDC 24 Apple представила новый, современный фреймворк — Swift Testing, который предлагает концептуально новый подход к тестированию.

Меня зовут Кирилл Гусев. Я мобильный разработчик в ОК. В этой статье я расскажу о том, какие возможности предоставляет Swift Testing и как мы планируем их применять в ОК.

Команда JavaScript for Devs подготовила перевод кейса Shopify о миграции их крупнейших приложений на новую архитектуру React Native. Результат впечатляет: еженедельные релизы не остановились, стабильность сохранилась, а производительность выросла.

В новом дайджесте Swift Runtime и производительность iOS-приложений, вопрос на 16К и полный айсберг Android, проектирование интерфейсов по азиатски, 17 платящих клиентов за час из Tinder, реклама на холодильниках и многое другое. Заходите!

Привет, Хабр! Сегодня поговорим о теме, которая вроде бы знакома каждому разработчику, но при этом часто остаётся в тени. Речь пойдёт о строках в Swift.

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

Привет, Хабр! Я Кристиан Бенуа, iOS-разработчиĸ в Т-Банĸе. В современном мире производительность приложения — ĸритичесĸи важный фаĸтор, определяющий его успех. Пользователи ожидают мгновенного отĸлиĸа и плавной работы, даже небольшие задержĸи могут негативно сĸазаться на восприятии приложения.  

Для больших iOS-приложений, написанных на Swift, понимание работы Swift Runtime и его влияния на производительность — важный навыĸ разработчиĸов. Swift Runtime при исполнении ĸода отвечает за фундаментальные вещи языĸа Swift: управление памятью и систему типов в рантайме.

В статье сосредоточимся на механизмах приведения типов и создания generic-типов внутри Swift Runtime и рассмотрим один ĸонĸретный метод, ĸоторый является узĸим местом в производительности приложения. Разберем примеры ĸода, демонстрирующие, ĸогда и почему этот метод вызывается, ĸаĸово его влияние на отзывчивость приложения и ĸаĸие стратегии использовать для смягчения негативного воздействия. 

В этом выпуске построение современного BLE-сервиса и повышение производительности за счет лучшего сокращения ресурсов, Swift на Android и эволюция презентационных паттернов, MAX без оболочки, эмоциональное решение проблем, трудные уроки инди-хакинга и многое другое. Заходите!

Привет, Хабр! В прошлых статьях мы говорили про ARC и управление памятью в Swift, но обошли стороной ещё одну сильную сторону языка. Речь идёт о generic'ах и протоколах - именно они делают Swift таким чистым и мощным. В этой статье мы разберёмся, как они работают и почему без них невозможно представить современный Swift.