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

Например, фреймворк может быть использован для:

Измерение производительности iOS-приложений как правило производится путем профилирования приложения для расчета затрачиваемого времени в каждой функции. Обычно это делается с помощью Time Profiler в Xcode Instruments, но он известен, как медленный и ненадежный.

Emerge предлагает инструмент профилирования как часть Тестирования Производительности в CI. Данное профилирование представлено как flame-граф, и доказало, что может быть простым способом получить понимание о критических элементах, влияющих на производительность приложения, и находить решения. Сегодня мы представляем новый способ использовать те же самые великолепные визуализации профилирования, полностью локальные и с открытым исходным кодом.

Power asserts (также известные как диаграммированные утверждения) дополняют ваши ошибки утверждений информацией о значениях, полученных во время оценки условия, и представляют ее в легко усваиваемой форме. Power asserts являются популярной функцией Spock (а позже и всего языка Groovy независимо от Spock), ScalaTest и Expecty.

Power asserts предоставляют описательные сообщения об утверждениях для ваших тестов, подобные следующим примерам:

DoccGPT - это эксперимент по полной автоматизации документирования кодовой базы на Swift. Он еще не закончен, но - будет (FAQ читайте ниже).

Apple представила совершенно новый фреймворк CoreTransferable и ShareLink вью в SwiftUI, позволив нам совместно использовать контент и экспортировать его из наших приложений весьма декларативно. На этой неделе мы узнаем, как сделать данные передаваемыми (* переносимыми) и как использовать новое вью ShareLink в SwiftUI.

Начиная с Xcode 11, когда Apple представила Xcode Test Plans для более простого и более настраиваемого управления тестированием и его выполнения, — и новые, и уже существующие проекты приходилось вручную переводить на использование новой системы или создавать новые планы тестирования с нуля. Для тех, кто не знаком: планы тестирования позволяют одному файлу управлять одной или несколькими тестовыми конфигурациями для набора тестов; допускают использование нескольких языков, смоделированных локаций, настроек тестирования и многое другое в одном тестовом запуске. Они могут сэкономить массу времени главным образом для локализованных приложений, приложений с белой меткой или сценариев со сложными конфигурациями сборки.

Переход на планы тестирования не требует больших усилий, вам нужно открыть существующую схему и перейти в раздел Test, а затем нажать кнопку Convert to use Test Plans…

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

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

Последний, но не менее важный пост в серии — о доступности. Важно сделать ваше приложение доступным для пользователей VoiceOver. Как правило, гораздо сложнее сделать доступным ваш визуальный контент. К счастью, Apple предоставляет функции аудиографики, которая позволяет нам отображать любую диаграмму с помощью звука. На этой неделе мы узнаем, как улучшить доступность наших графиков с помощью фреймворка Swift Charts.

Прежде всего, я должен отметить, что фреймворк Swift Charts понимает ваши данные и автоматически бесплатно создает дерево (*древовидную схему) доступности для вашей диаграммы. Вам не потребуется выполнять никаких специальных действий, чтобы сделать вашу диаграмму доступной при использовании фреймворка Swift Charts.

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

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

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

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

RGB какой-то отстой.

Модель RGB, мало чем отличающаяся от ASCII, адресов памяти и наличия 86 400 секунд в сутках, является одной из тех инструментов, которые немного упрощают программирование, до поры до времени.

Команда The Browser Company активно использует фреймворк The Composable Architecture (TCA). Основываясь на опыте нашей команды и мнениях более широкого сообщества, я разработал новый набор best practices (лучших практик), которые могут принести пользу вашим проектам TCA.

Вот некоторые из ключевых практик, которые можно использовать в своих проектах.

В рамках предстоящей функции Widgetsmith я хотел рисовать линейные градиенты. Я делал это бесчисленное количество раз, используя замечательный стиль заливки LinearGradient. Это прекрасно работает и может легко встраиваться в множество различных форм и ситуаций в SwiftUI.

Однако всякий раз, когда я использовал их раньше, я использовал только встроенные значения direction (направления):.top,.topTrailing,.leading и т. д. И, если быть честным, это были единственные варианты, которыми я располагаю.

Пару недель назад я выступил с докладом о том, как обрести уверенность в процессе релиза, на Mobile Devops Summit, дистанционном мероприятии, организованном Bitrise. В конце концов, я подумал, что было бы неплохо написать статью с описанием специфики выступления и мотивов, стоящих за ним.

SwiftUI имеет отличный API для стилизации view независимо от их реализации. В этом посте мы рассмотрим, как мы можем стилизовать пользовательские view таким же образом.

В прошлом году в ходе нескольких эпизодов на Swift Talk мы продемонстрировали, как создать собственный степпер для увеличения и уменьшения значения. Он был похож на Stepper в SwiftUI, но с API, который делает его стильным.

Этот пост является кратким изложением того, что мы рассмотрели тогда, а также несколькими приёмами, которым мы научились с тех пор, чтобы наши пользовательские стили view (представление, вью, вьюшка) работали ещё лучше, как built‑in (встроенные) в SwiftUI. В последующем посте мы рассмотрим несколько более продвинутых вариантов использования.

Какое-то время у нас был только модификатор onHover(perform:) в SwiftUI, который вызывается, когда пользователь перемещает указатель над рамкой view (представление, вью, вьюшка) или от неё. Раньше не было официального способа непрерывного отслеживания местоположения указателя. Это изменилось с введением onContinuousHover(coordinateSpace:perform:) в macOS 13 и iPadOS 16.

Новый модификатор позволяет нам читать текущую HoverPhase и сообщает точное местоположение указателя, когда он находится в пределах границ view. Давайте посмотрим на это в действии.

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

Когда вы будете готовы решить некоторые из своих бизнес‑задач с помощью ML, вы должны подумать, где будут работать ваши модели ML. В некоторых случаях имеет смысл использовать серверную инфраструктуру. Преимущество серверной достоверности в том, что ваши модели ML показали конфиденциальность, поэтому конкурентам будет труднее вас догнать. Кроме того, серверы могут работать с более высоким спектром моделей. Например, модели GPT (прославившиеся благодаря ChatGPT) в настоящее время требуются современные графические процессоры, поэтому о потребительских устройствах не может быть и речи. С другой стороны, обслуживание вашей конфиденциальной информации обходится довольно дорого, и если потребительское устройство может работать с вашей моделью, зачем больше? Кроме того, могут возникнуть проблемы с конфиденциальностью, когда вы не можете отправить данные на удаленный сервер для обработки.

Однако давайте предположим, что имеет смысл использовать устройства iOS ваших клиентов для запуска моделей ML. Что может пойти не так?

Facebook для iOS (FBiOS) — старейшая мобильная кодовая база в Meta. С тех пор как приложение было переписано в 2012 году, над ним работали тысячи инженеров, оно было отправлено миллиардам пользователей, и оно может поддерживать работу сотен инженеров одновременно.

После многих лет итерации кодовая база Facebook не похожа на типичную кодовую базу iOS:

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

В DoorDash мы очень серьезно относимся к скорости запуска приложений. Мы одержимы оптимизацией опыта наших клиентов и постоянными улучшениями.

В этой статье мы рассмотрим три отдельные оптимизации, которые сократили время, необходимое для запуска нашего потребительского приложения для iOS, на 60 %. Мы определили эти возможности, используя проприетарные инструменты повышения производительности, но инструменты Xcode или DTrace также могут быть подходящими альтернативами.

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

Однако, когда дело доходит до ScrollView SwiftUI, в настоящее время (на момент написания) не существует встроенного способа выполнения таких наблюдений за прокруткой. Хотя встраивание ScrollViewReader во view (представление, вью, вьюшка) прокрутки позволяет нам изменять положение прокрутки в коде, оно, как ни странно (особенно учитывая его имя), не позволяет нам каким‑либо образом считывать текущее смещение содержимого.

Один из способов решить эту проблему — использовать богатые возможности UIKit UIScrollView, который благодаря протоколу делегата и методу scrollViewDidScroll обеспечивает простой способ получать уведомления всякий раз, когда происходит прокрутка. Однако, несмотря на то, что я обычно большой поклонник использования UIViewRepresentable и других механизмов взаимодействия SwiftUI/UIKit, в этом случае нам пришлось бы написать довольно много дополнительного кода, чтобы преодолеть разрыв между двумя фреймворками.