iOS Broadcast – Telegram
iOS Broadcast
3.46K subscribers
1.84K photos
86 videos
1.04K links
Подборка новостей и статей для iOS разработчиков.

Новости Kotlin и мультиплатформы @kotlin_broadcast
Новости Android @android_broadcast
Реклама и прочее @ab_manager
Download Telegram
Демонстрация:​ Как интегрировать новый язык дизайна в приложения
Вчера прошла "встреча с Apple" ключевой темой которой являлся новый дизайн и жидкое стекло. Мои хайлайты из 2-часового доклада:
🔵Жидкое стекло становится частью фундаментальной системы дизайна Apple.
🔵Интерактивность жидкого стекла представляет собой огромный скачок в программных и графических технологиях.
🔵Акцент на содержании приложений и улучшение иерархии пользовательского интерфейса.
🔵Пользовательский интерфейс должен быть легко доступен и элегантно отходить на второй план.
🔵Три урока, усвоенные при перестройке приложения с помощью SwiftUI: начните с малого, работайте умнее, а не усерднее, завоевывайте доверие.
🔵Требуется дизайн система, где дизайн и код работают в гармонии.
🔵Переписывание приложения на SwiftUI облегчает переход на Liquid glass
🔵Liquid Glass помогает интерфейсу отойти на второй план, позволяя контенту сиять.

Опыт команды дизайнеров Apple:
🟢Цель проекта — создать единый язык дизайна для всех продуктов Apple.
🟢Мотивация: улучшение эргономичности и удобства использования.
🟢Десятки эскизов и прототипов помогают находить лучшие решения.
🟢Преимущества имеют нативные компоненты для создания интерфейсов
🟢Liquid Glass уменьшает количество цветов в кнопках, позволяя контенту быть хорошо видимым
🟢Поиск перемещён с верхней части iPhone на нижнюю для большей доступности.
🟢Сворачивание панели вкладок позволяет сфокусироваться на контенте.
🟢Иконки приложений формируют первое впечатление о приложении.
🟢Жидкое стекло создаёт единый визуальный язык для иконок.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
11👍2
🐥 Усовершенствования Swift 6.3 для Embedded Swift
В версии Swift 6.3 идут значительные улучшения для Embedded Swift — версия Swift, оптимизированная под крайне ограниченные среды
Ключевые обновления:
🟢Метод denoscription/debugDenoscription для Float, Double теперь доступен в библиотеке Embedded Swift
🟢Появились диагностические предупреждения (EmbeddedRestrictions), которые помогают выявлять конструкции языка, неподходящие для Embedded-режима (например, untyped throws, применение generic-функций к existential)
🟢Улучшена взаимосвязь с C: поддержка атрибута @c, улучшена терпимость к несоответствиям между C-подписью и Swift-объявлением
🟢Отладка: улучшена работа с LLDB — появилась поддержка чтения памяти с указанием типа, улучшенная трассировка исключений на armv7m
🟢Линковка: устранена типовая проблема с дублированием символов при использовании Embedded Swift библиотек через слабые (weak) определения; введён атрибут @export

Даже если вы разрабатываете исключительно под iOS, полезно знать о развитии языка: улучшенная C-совместимость, диагностика, отладка — всё это может пригодиться. Swift 6.3 продолжает расширять возможности встроенного (embedded) варианта языка — теперь он становится не просто экспериментом, а более полноценной средой для разработки лёгких и эффективных решений.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
📱 MagnifyGesture в SwiftUI
Зумирование контента — привычное действие для пользователей. С помощью MagnifyGesture с iOS 17 в SwiftUI можно легко добавить такой жест к View:
🔴При использовании стандартных жестов зумирования возникают нюансы: нужно решить, будет ли увеличенное состояние "временным" (возврат к исходному после окончания жеста) или "сохраняемым" (пользователь может масштабировать и остаться на этом уровне)
🔴Без правильной настройки жеста и состояния пользовательский опыт будет непредсказуемым

Вариант 1: Временный зум
🟣Используйте @GestureState для хранения текущего коэффициента масштабирования:
🟣Примените .scaleEffect(magnification) к View и добавьте жест
🟣Итог: во время жеста View масштабируется, после окончания жеста возвращается к исходному состоянию.

  @GestureState private var magnification: CGFloat = 1

.gesture(
MagnifyGesture()
.updating($magnification) { value, state, _ in
state = value.magnification
}
)


Вариант 2: Сохраняемый зум
🟣Используйте два свойства:
🟣Применяйте .scaleEffect(totalMagnification * currentMagnification) и жест
🟣Итог: пользователь увеличивает View — и масштаб остаётся на этом уровне до следующего жеста.
  @State private var totalMagnification: CGFloat = 1.0
@State private var currentMagnification: CGFloat = 1.0

.gesture(
MagnifyGesture()
.onChanged { value in
currentMagnification = value.magnification
}
.onEnded { value in
totalMagnification *= value.magnification
currentMagnification = 1.0
}
)


Что важно:
Убедитесь, что целевые устройства поддерживают iOS 17+, чтобы использовать MagnifyGesture
Решите заранее: нужен ли вам зум постоянный или временный — архитектура жеста зависит от этого
При сохраняемом зуме обязательно работайте с двумя состояниями (текущим и накопленным), чтобы обеспечить плавный UX и корректные вычисления
Проверьте интерфейс: масштабирование влияет на расположение, обрезку, может потребоваться дополнительная логика для предотвращения слишком малого или слишком большого масштаба
Тестируйте на разных устройствах (iPhone, iPad), ориентациях и с разными контентами (изображения, списки, кастомные Views) — чтобы жест не конфликтовал с другими жестами (например, прокруткой)

Добавление зума через MagnifyGesture в SwiftUI — мощный инструмент для повышения интерактивности интерфейса. Главное — выбрать правильную стратегию и грамотно реализовать состояние.
Please open Telegram to view this post
VIEW IN TELEGRAM
1
📱 Когда GeometryReader не нужен
Использование GeometryReader для управления layout-разметкой может усложнить и сделать более тяжелой иерархию View. Часто, чтобы центрировать контент или задать максимальную ширину (например, для iPad), разработчики оборачивают всё в GeometryReader, вычисляют размеры — но это влияет на layout, вызывает лишние пересчёты, усложняет структуру. Правильным решением в этом кейсе является использование onGeometryChange + contentMargins (iOS 17+ с бекпортом до iOS 16)
🔵onGeometryChange даёт возможность реагировать на изменение геометрии контейнера — без необходимости оборачивать интерфейс в GeometryReader
🔵Вместе с contentMargins можно задавать отступы для scroll-контента, центрировать и ограничивать ширину — делая layout адаптивным и чистым

Практические плюсы для iOS разработчика:
🟢Более лёгкая и чистая иерархия View — без лишних вложений.
🟢Упрощённая адаптивная верстка: удобнее для iPad, разных размеров экранов, responsive-дизайна.
🟢Код легче поддерживать и читать — сокращается boilerplate, меньше хитростей.
🟢Можно контролировать layout декларативно, оставаясь в духе SwiftUI.

Что стоит проверить прямо сейчас:
Проверьте части UI, где сейчас используете GeometryReader просто ради вычисления ширины/центрирования. Возможно, его можно заменить на onGeometryChange + contentMargins
Для scrollable-экранов с ограниченной шириной (галереи, карточки, формы) — попробуйте contentMargins + ограничение max-width, чтобы красиво центрировать контент на широких экранах
Если нужна реакция на изменение размеров контейнера — onGeometryChange позволяет элегантно отлавливать это и обновлять layout без лишней обёртки
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
🔨 CS193P 2025
Вышел обновленный стендфорский курс CS193p. Это бесплатный курс посвященный разработке приложений для iOS, объясняет основы создания приложений для iPhone и iPad с помощью SwiftUI. Почему культовый? В 2012 году я сам по нему учился и всю свою карьеру встречаю множество талантлевых iOS разработчиков, которые так же начали карьеру с него. На сайте представлены материалы, которые были доступны студентам Стэнфорда - записи домашних заданий и демонстрационный код.
🟢Курс на английском. От себя советую включать субтитры и слушать в оригинале, привыкать к международной терминологии
🟢Сам курс очень базовый и его можно начать изучать без знаний в iOS разработке, но база по программированию и ООП обязательна
🟢Между лекций есть домашние задания, их выполнение обязательно для полного погружения, если у вас появятся сложности, пишите в комментарии к этому посту-постараюсь помочь
🟢Если вы уже знакомы с iOS разработкой но сам курс не проходили - крайне советую пройти для систематизации ваших знаний

Пока вышли первые 6 лекций, но скоро должны появиться еще 9-10 лекций. Появилась идея сделать обзор лекций в канале @ios_broadcast, если вам такой формат интересен, ставьте 🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥429
Привет, хочу поделиться классным каналом, который и сам читаю, про iOS разработку и мобильную разработку в целом.

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

👉 Подписывайтесь на @hardworkerIT
8👍4🤔21
🔨 CS193P Лекция 1
Обычная вводная лекция, о курсе, требования для прохождения курса и знакомство со всем необходимым набором возможностей Xcode. Самая интересная часть 1 лекции это домашнее задание, до 4 лекции от студентов Stanford требуется изучить основы Swift:

Цветовая кодировка разделов
🔘Серые темы не нужно читать сейчас
🟡Желтые темы необычны и требуют внимания
🔴Красные темы важны и требуют внимательного прочтения

Материалы к прочтению:
🟢Swift Tour
🟢Swift API Guidelines
🟢Swift Basics

Мои хайлдайты из плана для чтения:
🟢Словарь и массив являются мощными и часто используемыми структурами. Освойте их как можно раньше
Разобраться в разнице между let и var
🟢Функции являются типами первого рода в Swift (first-class citizens). Это означает, что их можно использовать как и любые другие типы данных
🟢Замыкания (Closure) более мощные, чем встроенные функции - являются ссылочными типами
🟢Перечисления важны в Swift
🟢Структуры являются value-type, классы - ссылочными типами
🟢Методы экземпляра, свойство self, изменение типов значений из методов экземпляра

Получил достаточно много 🔥в реакциях, так что введу разбор одной лекции в неделю. Тем кто хочет погрузиться в iOS разработку-предлагаю за эту неделю смотреть саму лекцию и задавать вопросы по домашнему заданию прямо в комментарии к посту.
#cs193p
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍71
🎄 Адвент календарь для программистов

Продолжаем предновогоднюю традицию - Advent of Code.
Это адвент-календарь небольших головоломок по программированию объединенных общей историей. Я создал приватную таблицу лидеров 1538681-2a00287b, если вы тоже не хотите соревноваться со всем миром - присоединяйтесь.
Первая задача появилась только что! В этом году всего 12 задач на 12 дней и отличный довод чтобы опробовать AI ассистентов и узнать, достаточно ли они уже хороши (ставлю что нет)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
🔱 Создавайте с головой для того чтобы получалось быстро.
Статья о том, как рост и успех компании могут быть подорваны из-за неправильного подхода к оптимизации. Команда Tuist рассказывают о паттерне "Перемещение нагрузки" в системах мышления, который приводит к симптоматическому решению проблем. В статье рассматривается метрика "Пропускная способность мержа", которая сигнализирует о состоянии инженерной организации.В статье подчеркивается важность оптимизации рабочих процессов, а не только оборудования, для повышения эффективности, естественно на примере Tuist:

Merge Throughput: Ключевой показатель
🟡Merge throughput — это количество успешных изменений кода, которые попадают в основную ветку каждый день.
🟡Этот показатель отражает скорость доставки функций, исправления ошибок и реакции на рыночные требования.
🟡С ростом команды merge throughput может снижаться, что указывает на проблемы в процессе разработки.

Фаза 1: Одинокий волк
🟡Основатель запускает стартап и работает один, используя AI-ассистенты.
🟡Скорость разработки высока, но нет контроля качества, что приводит к критическим ошибкам.

Фаза 2: Добавление безопасности
🟡Основатель добавляет CI и нанимает первого инженера.
🟡Процесс разработки становится медленнее, но стабильнее благодаря проверкам и ревью.

Фаза 3: Умножение команды
🟡Команда растет до пяти инженеров, но merge throughput не увеличивается пропорционально.
🟡Проблемы: задержки в ревью, частые конфликты, нестабильные тесты, нехватка CI-раннеров.

Фаза 4: Стена сложности
🟡Команда растет до 30 инженеров, но merge throughput остается низким.
🟡Проблемы: длительные CI, частые конфликты, нестабильные тесты, задержки в ревью.

Фаза 5: Ловушка грубой силы
🟡Команда предлагает три решения: более мощные машины, больше людей, переписывание кода.
🟡Все эти решения имеют недостатки и не решают основную проблему.

Фаза 6: Умная оптимизация
🟡Интеграция Tuist позволяет использовать бинарный кеш и выборочное тестирование.
🟡Только измененные модули перекомпилируются, только затронутые тесты выполняются.
🟡Это значительно сокращает время CI и улучшает эффективность.

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

Вы сталкивались с подобными проблемами? Самые интересные проблемы приходят при росте 100+ разработчиков, но на этом уровне уже нужен не Tuist
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2