iOS дайджест #36: MVVM на Combine, Swift 6, конференции на 2020

В выпуске: 10 заповедей iOS-разработки, книга по SwiftUI, план на Swift 6, памятка по работе с форматтерами, много библиотек и немного про функциональщину.

Статьи

Mac Pro Xcode compiling times
Mac Pro стоит намного дороже топового Macbook или Mac Mini, но насколько же он быстрее компилит? Спойлер: не намного быстрее.

Thinking in SwiftUI
Вот и obj-c.io подоспели с книгой по SwiftUI. Обещают 5+ часов видео, примеры кода, но это все за $79.

Downloading and Caching Images in SwiftUI
Классическая задача — скачать, закешировать и отобразить картинку. Только теперь на SwiftUI.

Exploring Swift 5.2’s new functional features
Не могу сказать, что мне нравятся изменения в Swift 5.2, но в любом случае классно, что язык развивается.

On the road to Swift 6
Продолжая тему — уже есть план на Swift 6.

2020 iOS Conference Calendar
Год только начался, а куча конференций уже начали подготовку.

The iOS internationalization basics I keep forgetting
Мощная памятка по работе с форматтерами, локалями, тайм-зонами.

Practical Functional Programming in Swift: The Fundamentals
Лайтовое чтиво про функциональное программирование. Чистые функции — ван лав.

The Ten Commandments of iOS Development
10 заповедей iOS-разработки. Все по делу и нужно периодически к ним возвращаться.

Can You Answer This Simple Swift Question Correctly?
Так люблю подобные викторины. Может и самому что-то такое сделать?

Tips & tricks for iOS app debugging.
Брейкпоинты, логи — это, конечно, хорошо. Чтобы использовали chisel, я еще не видел, но выглядит как маст хэв.

Optionals in Swift Objective-C Interoperability
С Optional и Objective-C не все так просто, и иногда было уж больно странное поведение.

Swift fatalError is a fatal error
fatalError сливает вашу структуру проекта!

Building ViewModels with Combine framework
RxSwift не нужен или пишем mvvm с помощью Combine.

Библиотеки

UBKAccessibilityKit
Библиотека, которая облегчают работу и валидацию accessibility. Репозиторий оформлен так себе, но идея неплохая.

Puma
В последнее время все больше кайфую от CLI на Swift. Типа Fastlane на Swift.

Swift Embedded
Swift для железок. Почему бы и нет.

Barber
Берем один экран приложения, делаем из него отдельное приложение и запускаем.

Storyboard to SwiftUI
Сториборды мертвы. Да здравствует SwiftUI?

SwiftPowerAssert
Максимально детальное описание ассертов в тестах, которые упали.

Sitrep
Анализатор кода на Swift. Показывает количество файлов, протоколов, количество строк кода, импорты. Не так много всего, но все равно неплохо.

Finger Massage
Самое странное, что я видел за последнее время. Массаж для пальцев с помощью тачпада с поддержкой Force Touch.

Poes
В Xcode 11.4 завезли тестирование push-уведомлений в симуляторе, и вот уже удобная CLI утилита для этого. По сути, simctl + запись файла во временную директорию.

Видео

BA: Swiftable

SwiftConf ’19

dotSwift 2020


← Предыдущий выпуск: iOS дайджест #35

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




23 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Почему apple сделала SwiftUI и Combine только для iOS 13+ ? Уверен, что там по фичам хватит и iOS 9, можно было и не делать эти фреймворки как часть ОС.

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

От этого страдают не только пользователи, но и сами разработчики:
пока другие коллеги изучают новые достижения в ML/Computer Vision/др. областях, где сейчас происходит реальный прогресс, среднестатистический apple-разработчик вынужден изучать yet another method как формошлепить.

Так в iOS библиотек для Machine Learning тоже завезли.
Тем более ios 13 поддерживается многими устройствами.

Так в iOS библиотек для Machine Learning тоже завезли.

Да, стало намного удобнее в этом плане. Но большинство ios-разработчиков все равно будет учить SwiftUI, чтобы все также лепить формы, но уже на другом фреймворке, вместо того чтобы попробовать что-то реально новое для себя. Да, большинство алгоритмов ML придумали еще в 80-90е годы, но и сейчас далеко не каждый разработчик знаком с ними.

ios 13 поддерживается многими устройствами.

У моей знакомой iPhone 6, он с каждым обновлением все больше и больше глючит. Среди обычных пользователей не так много людей, часто меняющих телефон.

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

Наши(где люди сами покупают телефоны) рынки не особо интересные еплу, разве что продать cpo телефоны. Епл в первую очередь думает про операторские рынки, где каждые 2 года люди получают новый, слив свой старый. + айфон по подписке.
Зачем делать телефон, который работает долго и хорошо? Тогда никто не купит новый. Достаточно делать реальную поддержку 2-3 года (чтобы было выгодно перепродать на развивающихся рынках, наш, Индия и тд), а дальше уже можно и забить на оптимизацию и тд. Звонить может, 2-3 апы запустить и хватит

Зачем делать телефон, который работает долго и хорошо? Тогда никто не купит новый.

Да, я в курсе как работает экономика и при каких условиях могут быть кризисы перепроизводства.

Но у меня как у разработчика — цель создать продукт удобный для пользователей (не глючит, и не падает не только на новых, но и на старых устройствах и ОС).
У Apple — создать качественный продукт, чтобы его покупали больше чем у конкурентов, но не настолько качественный, чтобы пользователи не могли пользоваться этим продуктом по 10 лет, не покупая новый.

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

Но у меня как у разработчика — цель создать продукт удобный для пользователей (не глючит, и не падает не только на новых, но и на старых устройствах и ОС).

Скорее всего я должен вас растроить, но бизнес так не считает. Я не знаю, над каким продуктом вы сейчас работаете и какова его монетизация (если она есть), но довольно часто юзеры со старыми девайсами приносят больше вреда, чем пользы. А если вы и под андроид пишите, то я думаю, что вы сталкивались с устройствами из поднебесной и костылями для них.
А если делать апу для души, то да, можно пострадать с поддержкой старого железа/софта

бизнес так не считает.

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

вы сталкивались с устройствами из поднебесной и костылями для них

Да, одна из причин, почему американские и европейские стартапы не очень популярны на таком большом рынке как Китай. Зачем качать приложение амер. или европ. стартапа, если оно не будет работать на твоем телефоне.

А вы можете привести пример такого стартапа? Мне в голову приходит только телеграмм, но это скорее исключение из правил, ибо он был написан нердами, в хорошем смысле этого слова, да и бюджет там позволял такое.

Line, WeChat.
А у WhatsApp раньше даже было приложение для кнопочных телефонов (iphone тогда уже существовал).

а есть примеры, не из мессенджеров? С ними то как раз всё ясно, вы товар и слить рекламные предпочтения

А если делать апу для души, то да, можно пострадать с поддержкой старого железа/софта

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

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

Это оффтоп. Рассуждение в данную сторону приведет вообще куда-то далеко от темы.

Кстати, а не в OpenSource ли тоже популярно не закончивши одну подсистему, упразднять текущую стабильную и начинать новую ломая все.

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

Быть благотворительной организацией или не быть каждый решаем сам.

Если вы хотите поддерживать то это ваше право, это довольно похвально. Но это выбор каждого.

Вам же не запрещает никто хоть iOS 8 поддерживать в своих приложениях.

Справедливости ради, я бы не отказался от возможности заливать обновления для старых версий «последней совместимой версии». Бывает такое, что дропаешь поддержку старой версии ios, а через месяц находишь багу, но уже не обновить, без костылей.

У моей знакомой iPhone 6, он с каждым обновлением все больше и больше глючит. Среди обычных пользователей не так много людей, часто меняющих телефон.

iPhone 6, а особенно iPhone 6+, это самая неудачная модель и позор от Apple.

Но есть момент, iPhone 6 начал продаваться в 2014-м году, такой срок не все ноутбуки тянут. Большинство Андроидов в том числе дорогого сегмента уже хлам.
Я как iOS разработчик вообще рад что это устройство убрали с поддержки.

Но большинство ios-разработчиков все равно будет учить SwiftUI, чтобы все также лепить формы, но уже на другом фреймворке, вместо того чтобы попробовать что-то реально новое для себя

Ну это вообще про людей вообщем, простите за тавтологию. А скорее всего еще не будут учить пока не заставят)

Тот же ML на iOS пока применять очень неудобно. Python программисты шарахаются от того какими усилиями все заводится на iOS.

Почему apple сделала SwiftUI и Combine только для iOS 13+ ? Уверен, что там по фичам хватит и iOS 9, можно было и не делать эти фреймворки как часть ОС.

Потому что для того, чтобы DLS SwiftUI’я работал ему нужны opaque типы. А для opaque типов нужен рантайм Swift 5.1. А поскольку все ABI-стабильные версии свифта теперь поставляются с iOS, а не с приложениями, то нужен iOS 13+ с рантаймом Swift 5.1+.
Ограничения по версии ОС всегда были в системных библиотеках, а теперь будут и в свифте. Собственно, этот факт был широко известен уже несколько лет, поэтому не вижу здесь каких-то шокирующих поворотов. Да и никто не запрещает сидеть на Swift 4.2 или Obj-C и кайфовать. Вон, корпорация F так и делает.

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

Та камон. В корпорациях добра типа Apple правая рука не знает, что делает левая. Увязывать стратегию одной кучки гиков по замедлению устройств на уровне кернела с вознёй другой кучки гиков с их свифтом и третьей кучки гиков с их фреймворками — это уже попахивает теориями заговора. У них столько митинг румов нет.

чтобы DLS SwiftUI’я работал ему нужны opaque типы
opaque типов нужен рантайм Swift 5.1

Теперь вопрос почему для рантайма Swift 5.1 нужна iOS 13+. К примеру, если бы авторы C++ 14/17 вводили такие же ограничения по версии ОС — поднялась бы буря негодования среди разработчиков.

этот факт был широко известен уже несколько лет, поэтому не вижу здесь каких-то шокирующих поворотов

Вот и негодую с тех пор.

Да и никто не запрещает сидеть на Swift 4.2 или Obj-C и кайфовать

Еще один недостаток Apple — Obj-C до сих пор нужен для бриджевания с C++ кодом в ООП-стиле. Именно поэтому этот язык до сих пор используется в большинстве C++ проектов (тот же WebRTC к примеру). Почему до сих пор нет нормального бриджевания C++ кода со свифтом? Вот и приходится создавать враперы на Obj-C.

Увязывать стратегию одной кучки гиков

Ну тут либо криворукость разработчиков и архитекторов, либо намеренная стратегия.

Теперь вопрос почему для рантайма Swift 5.1 нужна iOS 13+.

Я бы задавал вопрос иначе. Зачем рантайм Swift 5.1 на iOS 12, если там нет системных библиотек, которые его используют и если там есть ABI-стабильный Swift 5? А также непонятно, как этот рантайм туда ретроактивно поставлять? Опять паковать вместе с приложениями? Мне, и как пользователю и как разработчику, эти 7.5 мб сэкономленного места с каждого приложения греют душу больше, чем возможность использования opaque типов в iOS <13. А даже если и поставлять 5.1 вместе с приложением, это означает, что и SwiftUI и Combine нужно с ним поставлять, так как их нет в старых SDK. Это недальновидная стратегия, так как к 2030 году ты будешь поставлять Swift 10 и все «системные библиотеки», которые создавались с поддержкой новых рантаймов. Будем скачивать калькуляторы весом в гигабайт.

К примеру, если бы авторы C++ 14/17 вводили такие же ограничения по версии ОС

Так это совершенно другой кейс. iOS для Apple — это 1st party платформа и вполне логично, что они поставляют рантайм своего нативного языка вместе с этой ОС. Для 3rd party платформ, какой-нибудь Linux-кофеварки — пожалуйста, скачивай исходники, собирай и поставляй версию рантайма Swift на своё усмотрение.

Мне, и как пользователю и как разработчику, эти 7.5 мб сэкономленного места с каждого приложения греют душу больше,

Соломоново решение — добавить это все (Swift 5.1 runtime и тд) в iOS 13+ под видом системных фреймворков, но и дать возможность разработчикам включать это под видом библиотек в приложения для iOS < 13.

К примеру, если бы авторы C++ 14/17 вводили такие же ограничения по версии ОС
Так это совершенно другой кейс. iOS для Apple — это 1st party платформа и вполне логично, что они поставляют рантайм своего нативного языка вместе с этой ОС.

... что собственно сделала так же самая Apple и создатели др. юниксовых операционок с С++ — включила рантайм в ОС (под видом libc++.dylib и др.), но и дала возможность разработчикам самим выбирать, включать это в приложение или нет (параметр при компиляции -static-libstdc++).

В этом плане C++ намного более гибкий, чем Swift. Почему Apple дает так мало свободы разработчикам, которые пишут под ее ОС-мы — это хмм.. политика компании.

Может быть потому что даже довольно старые устройства (iPhone 6S, который представили в 2015 году, 5 лет назад) поддерживают самую свежую iOS 13. Это ж вам не андроид, в котором об обновлениях можно забыть уже через год. :)

+100500.

Но справедливости ради, у Android намного лучше поддержка старых версий на уровне библиотек.
К примеру я могу использовать самый новый Jet Pack или другое новое API на 5м Андроиде.

Хотя это возня с UI. Те же Neural Networks API доступен только с Android 8.1.

Підписатись на коментарі