Плохая практика: не использовать фантомные типы (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 во второй аргумент. На примере все становится понятно 🙂