Советы по отладке при работе над проектами Swift

Вот несколько моих любимых трюков и советов по отладке, которые я использую при работе над проектами Swift.

Мобильная ОС компании Apple

Вот несколько моих любимых трюков и советов по отладке, которые я использую при работе над проектами Swift.
Сегодня мы выпускаем самое большое обновление для нашей библиотеки SwiftUINavigation с момента её первого выпуска год назад. В нём обеспечена поддержка новых API-интерфейсов iOS 16, исправлены ошибки некоторых навигационных инструментов Apple, улучшена поддержка оповещений и диалоговых окон подтверждения, а также улучшена документация.
Присоединяйтесь к нам для быстрого обзора новых функций и обязательно обновитесь до версии 0.4.0, чтобы получить доступ ко всему этому и многому другому:

Узнайте, как использовать HomeKit Accessory Simulator (HAS) (Симулятор аксессуаров для HomeKit) от Apple, для имитации смарт-аксессуаров для дома при разработке приложений с поддержкой HomeKit.

SwiftUI имеет совершенно новые API-интерфейсы навигации в iOS 16 и macOS 13. Они позволяют нам определять навигацию на основе стека и навигацию по нескольким столбцам.

Начиная с Xcode 14, симуляторы для watchOS и tvOS доступны в виде отдельных загрузок (iOS и macOS по-прежнему «встроены»). Данное решение позволяет значительно уменьшать размер загрузки приложения, однако теперь вам придется самостоятельно управлять этими большими (3-4 ГБ) компонентами.
При первом запуске Xcode 14 вам будет предложено загрузить дополнительные платформы. Также подсказка появится, когда вы попытаетесь запустить код без среды выполнения.
Но что это за загрузки и где они хранятся? Первый совет — откройте дисковую утилиту (Disk Utility). Вы увидите кучу новых томов «Симулятор», смонтированных в разделе «Образы дисков» (Disk Images):

Настроим Push уведомления при использования EAS. 
Факт отсутствия в русскоязычном сегменте интрнета и какого либо примера по настройке пуш уведомлений с использованием лишь инструментов которые предоставляет Expo Go очень расстраивает, поэтому вы сейчас видите сие творение.

Привет всем мобильным разработчикам! Мы одинаково любим Android и iOS. Но у каждого свои предпочтения. Предлагаем определить фаворита в дружеском поединке. Для этого перенесёмся в Гималаи и покорим Эверест. Выберите команду и постарайтесь дать как можно больше правильных ответов, чтобы добраться до вершины первыми. На весь тест 10 минут.

Это вторая статья из цикла про bottom sheet, в которой мы воссоздаём поведение платёжного фрагмента в Кошельке по образу и подобию Apple Pay и сталкиваемся с тем, что это не так то просто.
Из материала вы узнаете, как повторить полноценную навигацию в рамках bottom sheet отображения, основанного на autolayout, а не на неудобном ручном расчёте высоты. А ещё мы вместе повторим анимации навигационных переходов и добавим navigation bar как нативный способ управления навигацией.

В настоящее время SwiftUI предоставляет протокол Layout, позволяющий нам создавать суперпользовательские (сверхиндивидуальные мне кажется здесь больше подходит) макеты, копаясь в системе компоновки без использования GeometryReader. Протокол Layout дает нам невероятную силу создания и повторного использования любого макета, который вы можете себе представить. На этой неделе мы узнаем, как использовать новый протокол Layout для создания макета потока в SwiftUI.
Любой макет, который вы хотите создать, должен соответствовать новому Layout протоколу. Для реализации у него есть две необходимые функции.


В проекте Swift происходит много захватывающей работы, и за всем этим трудно следить, потому что это происходит во многих различных репозиториях, пул-реквестах и форумах. Чтобы дать сообществу лучшее представление об общей картине, Основная Команда провела исследование среди рабочих групп и разработчиков по всему проекту и собрала информацию о том, на чем они сосредоточены в течение следующего года.
Пожалуйста, имейте в виду, что здесь ничто не является заключением для какого-либо конкретного релиза проекта - планы и приоритеты со временем могут меняться. Это также не полный список всего, что происходит в проекте. Тем не менее, мы надеемся, что вы найдете его интересным и информативным, и если у вас есть вопросы по любой из этих областей, пожалуйста, не стесняйтесь обращаться и спрашивать более подробную информацию.
Core Data в SwiftUI на примере шаблонного приложения, предложенное Apple. Это было тривиальное приложение, в котором всего лишь один объект Core Data с одним единственным атрибутом, и тем не менее было показано, что давая объектам Core Data дополнительную функциональность с помощью „синтаксического сахара“ в расширении extension их классов class, автоматически генерируемых Xcode, можно добиться комфортной работы с Core Data в SwiftUI. Эти классы являются миниатюрными ViewModels для наших SwiftUI Views, так как они реализуют протоколы ObservableObject и Identifiable. И Apple научила их прекрасно «играть» на поле реактивности SwiftUI. Xcode классов class для объектов Core Data существенно возрастает при работе с реальными взаимосвязанными объектами — рейсами Flights, аэропортами Airports и авиакомпаниями AirLines, которые мы получаем в интернете на сайте компании  FlightAware  и размещаем в локальной базе данных Core Data. CoreDataSwiftUIFlights является сильно упрощенной модификацией реального приложения Enroute из стэнфордских курсов CS193P 2020, которое оперативно подкачивает данные с сервера  FlightAware  и требует от вас платной подписки на сервис  FlightAware . Flights, аэропортах Airports и авиакомпаниях Airlines в JSON формате. Эти данные размещаются в Core Data с учетом взаимосвязей этих объектов, и вы можете не просто видеть всю информацию о рейсах, но и делать различные запросы к ней с помощью фильтров и сортировать ее нужным вам способом.
 Core Data, разработанный Apple для постоянного хранения данных на своих платформах, эффективно работающий даже с очень большими объемами данных, используется очень давно, с версии iOS 3 и macOs 10.4, так что прошло где-то порядка 10 лет с того момента, когда Apple впервые представила фреймворк Core Data. Когда это произошло, языка программирования Swift вообще не было в проекте, так что Core Data была спроектирована с ориентацией на Objective-C и, конечно, это отразилось на её API.
SwiftUI, который предложил нам новую парадигму конструирования UI, он был предложен для iOS 13 и полностью опирался на Swift, его корни — это Swift, хотя он использует UIKit “под капотом” и полностью зависит от UIKit на iOS, по крайней мере на данный момент, и от AppKit на macOS. Конечно, он это скрывает, как только может, он сконструирован и реализован с прицелом на Swift. Более того, Swift сам был существенно доработан с целью поддержки SwiftUI и стал ещё более мощным и интересным.Core Data принципиально связана с объектно-ориентированным программированием ( классы, наследование, делегирование и все такое), a суперсовременный SwiftUI основан на декларативном функциональном программировании (структуры, протокольно-ориентированное программирование) и имеет реактивную природу, которая воплощается в использовании архитектуры MVVM. Универсальные функции и типы в Swift в настоящее время требуют фиксированного количества параметров типа. Невозможно написать функцию или тип, который принимает произвольное количество аргументов с различными типами, не прибегая к одному из следующих обходных путей:

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

Разберу как Apple использовали UIKit для приложения Календаря: события, сетку дней, экран с превью года, навигейшн и другие элементы. 
Из интересного - события сделали картинками, а переход для навигации - простое перемещение вьюх за экран. Подробнее под катом.

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

В то время как Android-устройства в целом ушли в направлении простых вырезов в экране под фронтальную камеру или даже подэкранных фронталок, Apple создала совершенно новый пользовательский опыт благодаря своему новому пространству для размещения камеры — «челке» (the notch). Сегодня мы с вами обсудим, как реализовать нечто подобное в iOS.
Виджеты, которые Apple представила в iOS 14, позволяют нам просматривать информацию прямо на наших главных экранах.
Но что, если мы пойдем еще дальше и представим контекстно-зависимую информацию, которая всплывает при необходимости и не задерживается на экране слишком долго? А что, если бы это было реализовано таким образом, чтобы все это гармонично работало с самым большим обновлением для фронтальной панели, которое наши iPhone видели с момента появления челки? Больше никаких «а что, если» — встречайте Dynamic Island.