🐱 TipKit-Examples
Мы уже разбирали статьи и доклады про TipKit но пока его не стали все использовать, сложно понять как он выглядит и ощущается. Анимации и поведение нужны для спецификации задач и демонстации нативного элемента дизайнеру. Простой Example, который можно поставить на свой телефон уже сегодня

⚡️На Reddit обсуждают Sideloading в новой бете iOS
В актуальной iOS 17.2 beta нашли возможность устанавливать ipa напрямую, например через airdrop. Успешно завершается установка если эту ipa вы сами ранее скачали из App Store под своей учетной записью Apple ID, другими словами-подписали. При попытке установить файл, связанный с чужой записью Apple ID, вываливается ошибка с невозможностью проверки его целостности

🖥 Готов ли Swift OpenAPI Generator для продуктивного кода? (10 мин 🇷🇺)
Детальный разбор про нативный Swift OpenAPI (Swagger) генератор исходников. Вообще я фанат подхода с кодогенерацией сетевого слоя, это не только сокращение бойлерплейта но и исключение человеческого фактора на уровне клиент-серверного взаимодействия. Если вам предоставляют Swagger с методами бека, вы можете генерировать нативный код: модели, запросы, парсеры, ошибки согласно спецификации. Сам давно использую java генератор для шаринга Spec-first подхода и для клиента и для сервера, но его интеграция гораздо сложнее для мобильной команды чем новый Swift генератор ❤️‍🔥

Плохая практика: не использовать фантомные типы (2 мин 🇺🇸)
Интересная идея - использовать фантомные типы с Generic для типобезопасности кода. В статье детально разбирается пример в котором такой подход помогает избегать ошибок, но я с такими ошибками не сталкивался... Как думаете, полезная идея 👍 или усложнение ради усложнения 👎 и достаточно делать typealias на swift типы?

Сегодня в 10:50 стартует Community (бесплатный) день конференции Mobius! Регистрация

💸 Удивительный мир внутри .ipa
🌐 Как сделать, чтобы не тормозило, пожалуйста
⬇️ Как собеседовать мобильных инженеров? Системный дизайн спешит на помощь!
📱 Пишем нативно под Аврора ОС как под iOS: Clean-архитектура, Coordinator и UDF

🐚 Skip - плагин Xcode для транспиляции SwiftUI приложения на Android

Пятница - самое время рассмотреть очередной кросплатформенный движок. По-началу, когда я о нем услышал, мысленно закопал. Но потом понял что идея вполне жизнеспособна:
🔥 Полный натив для iOS, в отличии от большинства движков (Flutter, Compose Multiplatform). Look&Feel из коробки. SwiftUI на iOS и Compose на Andoid
🔥 Нет отдельного языка или новых концепций как с React Native или Xamarin
🔥 Нет проблем с ARC - код изначально пишется на Swift+SwiftUI
🔥 Исходники Kotlin, которые генерятся движком, могут быть не только просмотрены но и отредактированы

Не все так просто, даже если опустить вендорлок:
💩Поддержка языка ограничена, нужно думать какие конструкции можно использовать
💩Нативные компоненты прийдется писать свои или адаптировать сильно транспилированный код
💩В качестве БД прийдется использовать прямые обращения к sqlite

Почему я думаю, что это может взлететь?
💸Стартапы часто начинают с iOS-only приложения, которые пишут на самых актуальных инструментах, а это способ быстрее получить аналог на Android и проверить интерес
💸Проще найти разработчика который умеет писать нативный код для iOS и адаптирует его под Android

Можно поступить мудро, и посмотреть взлетит ли этот подход через пару лет, ведь если долго сидеть на берегу реки, то можно увидеть, как мимо проплывёт труп твоего врага 😀

Subscript строк по индексу и ренжу
Мое самое большое непонимание в эволюции 🖥Swift - удаление substring при переходе с Swift 2.3 на Swift 3.0. Из-за некоторых граничных кейсов, которые сложно покрыть обычными индексами, мы потеряли удобство для всех кейсов. В результате чего, почти в каждом проекте есть расширение, позволяющее работать со строками через subscript. И пару раз я находил там баги или неожиданное поведение. На сколько я понимаю, все приседания с ради предсказуемой работы с emoji:

"\u{1F44D}" // 👍
"\u{1F44D}\u{1F3FD}" // 👍🏽

Если вы тоже работаете с обычными строками, забирайте мой gist

⚠️ Изменения в конструкторе URL из строки в iOS 17
Если зайти в документацию URL конструктора с аргументом в виде строки, там появилась секция:

⚠️Важно! Начиная с iOS 17 поведение метода будет соответствовать RFC 3986.

Понятно что важно, но что это значит на практике? На самом деле, все проще чем кажется! Новое значение по умолчанию заключается в том, что URL(string:) пытается закодировать недопустимые символы. Если мы хотим продолжать использовать поведение, существовавшее до iOS 17, нам нужно будет заменить URL(string:) на новый URL(string:encodingInvalidCharacters:) и передать false во второй аргумент. На примере все становится понятно 🙂