🚀 Swift 6.2 уже доступен
📖 Самые важные изменения здесь и в карточках.
Можно ещё раз взглянуть на InlineArray и Span, познакомиться с Subprocess, узнать, что поменялось в NotificationCenter и многое другое.
😃 iOS Dev
📖 Самые важные изменения здесь и в карточках.
Можно ещё раз взглянуть на InlineArray и Span, познакомиться с Subprocess, узнать, что поменялось в NotificationCenter и многое другое.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
5❤🔥35 11💯6👍3🍓2 2✍1🔥1🏆1
Как отключить Liquid Glass для iOS-приложения при использовании новых SDK в iOS 26
Всё просто: добавьте в plist проекта
Но это решение вероятно сработает ровно до 27 iOS, так как Apple уже обещает его задепрекейтить.
😃 iOS Dev
Всё просто: добавьте в plist проекта
UIDesignRequiresCompatibility
в YES.Но это решение вероятно сработает ровно до 27 iOS, так как Apple уже обещает его задепрекейтить.
Please open Telegram to view this post
VIEW IN TELEGRAM
6🔥16 11✍6🏆5 2👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Сфера Фибоначчи на Metal + SwiftUI
Наложение решётки Фибоначчи (она же золотая спираль или просто сфера Фибоначчи) на поверхность сферы может оказаться неплохим математическим челленджем, а ещё весьма быстрым и эффективным способом распределения точек.
Например, про филлотаксис и одну из загадок Да Винчи я писал уже в канале - обязательно загляните.
А сегодня делюсь анимацией, которую можно сделать с помощью доступных фич Metal уже сейчас (конечно, с поправкой на производительность).
📖 Кстати, на хабре можно посмотреть, как повысить эффективность распределения точек.
А в💰 бусти и ⭐️ в телеграме вас уже ждёт код реализации (этого и многих других необычных эффектов).
😃 iOS Dev
Наложение решётки Фибоначчи (она же золотая спираль или просто сфера Фибоначчи) на поверхность сферы может оказаться неплохим математическим челленджем, а ещё весьма быстрым и эффективным способом распределения точек.
Например, про филлотаксис и одну из загадок Да Винчи я писал уже в канале - обязательно загляните.
А сегодня делюсь анимацией, которую можно сделать с помощью доступных фич Metal уже сейчас (конечно, с поправкой на производительность).
📖 Кстати, на хабре можно посмотреть, как повысить эффективность распределения точек.
А в
Please open Telegram to view this post
VIEW IN TELEGRAM
7 21🔥16❤🔥6💯2 2✍1👍1
Вышла SQLiteData 1.0 от создателей PointFree: альтернатива SwiftData с CloudKit-синком и шерингом
🛠 Среди заявленных фич на GitHub:
- Создание моделей с помощью структур и перечислений Swift.
- Типобезопасные и схемобезопасные запросы для фетча данных.
- Высокопроизводительный декодер SQLite.
- Можно юзать property wrappers, аналогичные
- Прямой синк с CloudKit.
- Поддержка iCloud-шеринга для обмена инфой между юзерами.
- Основано на SQLite.
📖 Большой обзор с примерами - тут, а полная документация - здесь.
😃 iOS Dev
🛠 Среди заявленных фич на GitHub:
- Создание моделей с помощью структур и перечислений Swift.
- Типобезопасные и схемобезопасные запросы для фетча данных.
- Высокопроизводительный декодер SQLite.
- Можно юзать property wrappers, аналогичные
@Query
в SwiftData (работает не только в SwiftUI, но и в целом в @Observable
-моделях и UIKit-контроллерах).- Прямой синк с CloudKit.
- Поддержка iCloud-шеринга для обмена инфой между юзерами.
- Основано на SQLite.
📖 Большой обзор с примерами - тут, а полная документация - здесь.
Please open Telegram to view this post
VIEW IN TELEGRAM
9 29👍8🔥6🍓4🤯3 2✍1⚡1
Как использовать [weak self] в Swift Concurrency Task?
Donny Wals рассматривает кейсы, которые помогут предотвратить утечки памяти и пытается ответить на несколько вопросов.
➡️ Основы использования
➡️ Использование
➡️ Есть ли проблема при использовании
➡️ Предотвращение
➡️ Как использовать
📖 Статью целиком можно прочитать здесь.
А вот тут есть большой разбор проблем с утечками памяти (классических примеров и способов поиска).
😃 iOS Dev
Donny Wals рассматривает кейсы, которые помогут предотвратить утечки памяти и пытается ответить на несколько вопросов.
[weak self]
в completion handlers.[weak self]
и немедленное развертывание внутри таски.guard let self
при старте задачи.strong self
внутри задачи.[weak self]
в более длительных задачах. 📖 Статью целиком можно прочитать здесь.
А вот тут есть большой разбор проблем с утечками памяти (классических примеров и способов поиска).
Please open Telegram to view this post
VIEW IN TELEGRAM
4 16✍11👍7🔥5💯4 1
🎉 Выпущено в релиз обновление iOS IQ - с новым режимом и поддержкой iOS 26
Я специально дождался от эпла, пока они зарелизят новую ось, чтобы чекнуть стекло в продакшне. Несколько главных разделов уже обновлено, какие-то мелочи ещё в процессе.
Что из мажорных изменений?
- Полноценный новый боевой режим «Исправь и собери код». Попробовал проверить, насколько вообще реально решать головоломки с кодом, пришёл к выводу, что собрать рабочий варик из хаоса даже 15 строк может быть утомительно - поэтому примерно этим размером и ограничил (рекомендую затестить дзен-рандом и не используйте подсказки, это не наш путь).
- Новый блок вопросов по многопоточке.
- Обновил несколько существующих веток с темами, добавил практически в каждую по несколько новых задач.
Был удивлён, что в даже в RC-версии Xcode завезли проблему с компилированием кода, если в проекте Metal (а у нас он есть), потратил наверное час, чтобы корректно зааттачить нужный тулчейн - если у кого-то есть такая же проблема, вот ветка.
🏠 Скачайте приложение в AppStore - и поставьте оценку, пожалуйста.
* кстати, бот также обновлен, удалил пару дублей в опциях и добавил несколько новых вопросов.
Пишите в личные сообщения канала (кнопка в телеге слева снизу), если вы хотели бы увидеть новые режимы или что-то ещё, я всегда всем отвечаю.
😃 iOS Dev
Я специально дождался от эпла, пока они зарелизят новую ось, чтобы чекнуть стекло в продакшне. Несколько главных разделов уже обновлено, какие-то мелочи ещё в процессе.
Что из мажорных изменений?
- Полноценный новый боевой режим «Исправь и собери код». Попробовал проверить, насколько вообще реально решать головоломки с кодом, пришёл к выводу, что собрать рабочий варик из хаоса даже 15 строк может быть утомительно - поэтому примерно этим размером и ограничил (рекомендую затестить дзен-рандом и не используйте подсказки, это не наш путь).
- Новый блок вопросов по многопоточке.
- Обновил несколько существующих веток с темами, добавил практически в каждую по несколько новых задач.
Был удивлён, что в даже в RC-версии Xcode завезли проблему с компилированием кода, если в проекте Metal (а у нас он есть), потратил наверное час, чтобы корректно зааттачить нужный тулчейн - если у кого-то есть такая же проблема, вот ветка.
* кстати, бот также обновлен, удалил пару дублей в опциях и добавил несколько новых вопросов.
Пишите в личные сообщения канала (кнопка в телеге слева снизу), если вы хотели бы увидеть новые режимы или что-то ещё, я всегда всем отвечаю.
Please open Telegram to view this post
VIEW IN TELEGRAM
18❤🔥16🔥8 7💯2 2👍1🍓1
Кажется, пора внести ясность
Бизнесу не важно, что у вас под капотом: насколько ваш код красив и удобен в саппорте в будущем, как именно вы хэндлите все сценарии ошибок в непростых сценариях или насколько тяжелые задачи решаете, когда деливерите фичи.
Все мы хотим проводить рефакторинг! А какой разработчик не хочет?
Ведь тут как с автомобилем - вроде и едет, и тормоза в порядке, ну и что, если там где-то тарахтит или стучит, стоит ли всегда чекать шрус?
Напомню, что есть полезное правило трёх.
Важно помнить, что попытка слишком раннего рефакторинга при выборе неправильной абстракции может привести к ухудшению кода по мере появления новых требований и, в конечном итоге, потребует повторного рефакторинга.
Поэтому часто можно услышать от продактов или архитекторов (кому повезло и у них они есть на проекте) - что давайте сделаем фичу, а зарефакторим потом, в следующих спринтах когда-нибудь.
В такой момент важно не пропустить вспышку, когда дальнейшее наслаивание логики может поломать слишком многое внутри.
И в такой момент жизненно важно для проекта остановиться.
Для этого должен быть лид, способный взять ответственность за изменения в ядре проекта (или крупной фичи).
И будет здорово, если ваши стейкхолдеры или продакты смогут оценить такую ветку изменений по достоинству.
Так бывает не всегда.
Зато вы после проведённого рефакторинга сможете спать спокойно.
А вот стоит ли оно таких усилий - решать вам и вашей команде. Ведь многие проекты существуют и прекрасно себя чувствуют на стадии и так сойдёт.
Пишу про моменты, которые вам не расскажут ни на одной конференции здесь.
😃 iOS Dev
Бизнесу не важно, что у вас под капотом: насколько ваш код красив и удобен в саппорте в будущем, как именно вы хэндлите все сценарии ошибок в непростых сценариях или насколько тяжелые задачи решаете, когда деливерите фичи.
Все мы хотим проводить рефакторинг! А какой разработчик не хочет?
Ведь тут как с автомобилем - вроде и едет, и тормоза в порядке, ну и что, если там где-то тарахтит или стучит, стоит ли всегда чекать шрус?
Напомню, что есть полезное правило трёх.
Важно помнить, что попытка слишком раннего рефакторинга при выборе неправильной абстракции может привести к ухудшению кода по мере появления новых требований и, в конечном итоге, потребует повторного рефакторинга.
Поэтому часто можно услышать от продактов или архитекторов (кому повезло и у них они есть на проекте) - что давайте сделаем фичу, а зарефакторим потом, в следующих спринтах когда-нибудь.
В такой момент важно не пропустить вспышку, когда дальнейшее наслаивание логики может поломать слишком многое внутри.
И в такой момент жизненно важно для проекта остановиться.
Для этого должен быть лид, способный взять ответственность за изменения в ядре проекта (или крупной фичи).
И будет здорово, если ваши стейкхолдеры или продакты смогут оценить такую ветку изменений по достоинству.
Так бывает не всегда.
Зато вы после проведённого рефакторинга сможете спать спокойно.
А вот стоит ли оно таких усилий - решать вам и вашей команде. Ведь многие проекты существуют и прекрасно себя чувствуют на стадии и так сойдёт.
Пишу про моменты, которые вам не расскажут ни на одной конференции здесь.
Please open Telegram to view this post
VIEW IN TELEGRAM
11👍23 10❤🔥5✍2🔥2💯2🤝1
Почему проекты на Swift сталкиваются с трудностями (и как их преодолеть)
📖 У Tuist вышел разбор, в котором объясняется не только то, почему в крупных Swift-приложениях начинаются типичные проблемы, среди которых и медленные билды, и нестабильные тесты, но, например и то, как справиться со всем этим не прибегая к кардинальным изменениям вроде перехода на React Native или помощи Bazel.
Про React Native это отсылочка к недавнему разбору о том, как Shopify взял и перевёл все мобильные приложения на React Native. Хотя у всего есть своя цена.
Видимо, в tuist читали мой вчерашний пост и согласны, что бизнесу пофиг, почему у вас проект собирается так долго и это вам мешает - ведь конечная цель повысить профит от продукта, что справедливо.
Но вообще в статье есть важные поинты, на которые стоит обратить внимание и посмотреть, можно ли это изменить у вас на проекте:
- Безусловно, одним из факторов для возможного преодоления сложностей они считают модуляризацию.
- Время сборок. Тут не обошлось и без их паблик-дашборда.
- Работа с тестами и разбор флагов.
- Анализ сборок и выводы. Нельзя не вспомнить и про xcbeautify.
- Derived Data. Рассматривают и те проблемы, что есть сейчас, и заглядывают в будущее. На самом деле, Apple уже работает над подходом, называемым хранилищем с адресацией по содержимому и явными модулями, к которому они постепенно подталкивают пользователей.
😃 iOS Dev
📖 У Tuist вышел разбор, в котором объясняется не только то, почему в крупных Swift-приложениях начинаются типичные проблемы, среди которых и медленные билды, и нестабильные тесты, но, например и то, как справиться со всем этим не прибегая к кардинальным изменениям вроде перехода на React Native или помощи Bazel.
Про React Native это отсылочка к недавнему разбору о том, как Shopify взял и перевёл все мобильные приложения на React Native. Хотя у всего есть своя цена.
Видимо, в tuist читали мой вчерашний пост и согласны, что бизнесу пофиг, почему у вас проект собирается так долго и это вам мешает - ведь конечная цель повысить профит от продукта, что справедливо.
Но вообще в статье есть важные поинты, на которые стоит обратить внимание и посмотреть, можно ли это изменить у вас на проекте:
- Безусловно, одним из факторов для возможного преодоления сложностей они считают модуляризацию.
- Время сборок. Тут не обошлось и без их паблик-дашборда.
- Работа с тестами и разбор флагов.
- Анализ сборок и выводы. Нельзя не вспомнить и про xcbeautify.
- Derived Data. Рассматривают и те проблемы, что есть сейчас, и заглядывают в будущее. На самом деле, Apple уже работает над подходом, называемым хранилищем с адресацией по содержимому и явными модулями, к которому они постепенно подталкивают пользователей.
Please open Telegram to view this post
VIEW IN TELEGRAM
7🔥16 10✍7👍5🏆1
This media is not supported in your browser
VIEW IN TELEGRAM
Реализация алгоритма для навигации по метро Токио на Swift
В необычном докладе Крис рассказывает не только о способах получения следующих доступных станций в метро, но и о связывании инфы с Dynamic Island.
Сам проект использует два типа данных: статику от жд-системы и GPS в реальном времени от юзера.
А ещё затрагиваются вопросы хранения, отображения и то, как именно стейт-машина позволяет сделать резы более стабильными в каждом случае.
🛠 Хотя сам алгоритм алгоритм не опенсорснут по очевидным причинам, но в этой репе есть целых 5 приложений, которые использовались для сбора данных.
📖 Сама презентация на английском тут, видео здесь (на японском языке будет позже, если кто-то хочет дождаться).
😃 iOS Dev
В необычном докладе Крис рассказывает не только о способах получения следующих доступных станций в метро, но и о связывании инфы с Dynamic Island.
Сам проект использует два типа данных: статику от жд-системы и GPS в реальном времени от юзера.
А ещё затрагиваются вопросы хранения, отображения и то, как именно стейт-машина позволяет сделать резы более стабильными в каждом случае.
🛠 Хотя сам алгоритм алгоритм не опенсорснут по очевидным причинам, но в этой репе есть целых 5 приложений, которые использовались для сбора данных.
📖 Сама презентация на английском тут, видео здесь (на японском языке будет позже, если кто-то хочет дождаться).
Please open Telegram to view this post
VIEW IN TELEGRAM
9 17🔥10🏆4👍2🤯2🍓2👏1💯1
Вышла первая версия Swift Configuration - новый инструмент чтения конфигов от Apple
В первую очередь либа преднозначена для экосистемы Swift-серверов, где конфиг часто считывается из нескольких источников. Но не только. Среди основных преимуществ:
➡️ Появился единый API для чтения конфигураций в приложениях и библиотеках.
➡️ Быстрый старт с поддержкой environment variables, аргументов, JSON/YAML и in-memory данных.
➡️ Есть опция создавать свои провайдеры конфигураций с открытым протоколом
Новая либа пригодится и в инструментах командной строки, и в тех приложениях и библиотеках, где нужно гибкое управление конфигурацией.
📖 Вводный пост здесь, примеры на GitHub, а вся документация (и кейсы использования) лежат вот тут.
😃 iOS Dev
В первую очередь либа преднозначена для экосистемы Swift-серверов, где конфиг часто считывается из нескольких источников. Но не только. Среди основных преимуществ:
ConfigProvider
. Новая либа пригодится и в инструментах командной строки, и в тех приложениях и библиотеках, где нужно гибкое управление конфигурацией.
📖 Вводный пост здесь, примеры на GitHub, а вся документация (и кейсы использования) лежат вот тут.
Please open Telegram to view this post
VIEW IN TELEGRAM
5 15🔥9👍6❤🔥4🤯1💯1
Основы работы с памятью в Swift: size, stride, alignment
Одной из основных задач на моей текущей работе является работа с бинарным протоколом (когда-то давно выбрали его не только потому что он более компактен по сравнению с традиционными вариантами вроде JSON или XML), но и не в меньшей степени из-за скорости и эффективности обработки (а ещё безопасности).
При работе с памятью для новичков важно понимать всего лишь 3 основных свойства: это
И хотя с size всё кажется очевидным, но даже в доках есть важная сноска:
Для stride как и следует из названия:
А вот что такое
📖 Делюсь простой и понятной статьёй, в которой буквально на пальцах объясняют все эти свойства, а ещё какие сложности могут возникнуть.
И напомню про этот пост c разбором MemoryLayout.
✅ А если вы хотите разобраться с темой на более детальном уровне, то вам сюда.
😃 iOS Dev
Одной из основных задач на моей текущей работе является работа с бинарным протоколом (когда-то давно выбрали его не только потому что он более компактен по сравнению с традиционными вариантами вроде JSON или XML), но и не в меньшей степени из-за скорости и эффективности обработки (а ещё безопасности).
При работе с памятью для новичков важно понимать всего лишь 3 основных свойства: это
size
, stride
и alignment
.И хотя с size всё кажется очевидным, но даже в доках есть важная сноска:
Размер типа не включает в себя динамически выделенную память. В частности, MemoryLayout<T>.size, когдаT
является типом класса, остается неизменным независимо от количества сохраненных свойствT
.
Для stride как и следует из названия:
это количество байт от начала одного экземпляра T
до начала следующего при хранении в непрерывной памяти или в `Array<T>`.
А вот что такое
alignment
? И вообще что такое смещение значения и как оно влияет? 📖 Делюсь простой и понятной статьёй, в которой буквально на пальцах объясняют все эти свойства, а ещё какие сложности могут возникнуть.
И напомню про этот пост c разбором MemoryLayout.
Please open Telegram to view this post
VIEW IN TELEGRAM
6🔥17 9❤🔥5✍4👍1👏1💯1🏆1
Теорема о бесконечных обезьянах
Если в течение продолжительного времени случайным образом стучать по клавиатуре, то среди набираемого текста будут возникать осмысленные слова, словосочетания и даже предложения.
А на дистанции длиной плюс-минус в бесконечность есть шанс, что она даже напечатает Шекспира.
Массовая истерия с ИИ мне напоминает примерно это же.
Я уже вижу, как готовят списки промптов, и, чёрт возьми, даже продают их: «что, серьёзно?» (тут нужен мем), а на сотнях сайтов вводят курсыкак гуглить работать с ИИ или хакать подписку.
Самим не смешно?
Все создатели ИИ пишут эти советы, чтобы ты, pal, покупал их. Чтобы ты больше верил в то, что чудо-машина за тебя всё сделает.
Даже в Xcode внедрили ChatGPT - сколько там, 5 запросов, 10, 15? А дальше нужно опять думать.
Я уже вижу, как люди буквально начинают верить в то, что это и есть программирование. Отчасти они правы, ведь наша задача переводить естественный язык в понятный машине, но лишь отчасти.
Ребята посерьёзнее знают, что шум вокруг ИИ подобен парадоксу Солоу.
Я за взвешенный подход не только потому, что люди глупеют при использовании ИИ, но из-за того, что это порождает посредственность, убивает креативность и ставит специалиста в рамки его же промптов.
Чтобы создать что-то новое, нужно уметь выходить за рамки.
Нужно изобретать.
И что-то новое совсем необязательно очередной велосипед.
Не верьте звону вокруг, помните - ради чего вы вообще в профессии, особенно если кроме денежной мотивации есть что-то ещё.
Создавать всегда ценнее, чем просто копировать. Не каждый шорткат позволит вам быть впереди, иногда это путь в тупик.
😃 iOS Dev
Абстрактная обезьяна, ударяя случайным образом по клавишам пишущей машинки в течение неограниченно долгого времени, рано или поздно напечатает любой наперёд заданный текст.
Если в течение продолжительного времени случайным образом стучать по клавиатуре, то среди набираемого текста будут возникать осмысленные слова, словосочетания и даже предложения.
А на дистанции длиной плюс-минус в бесконечность есть шанс, что она даже напечатает Шекспира.
Массовая истерия с ИИ мне напоминает примерно это же.
Я уже вижу, как готовят списки промптов, и, чёрт возьми, даже продают их: «что, серьёзно?» (тут нужен мем), а на сотнях сайтов вводят курсы
Самим не смешно?
Все создатели ИИ пишут эти советы, чтобы ты, pal, покупал их. Чтобы ты больше верил в то, что чудо-машина за тебя всё сделает.
Даже в Xcode внедрили ChatGPT - сколько там, 5 запросов, 10, 15? А дальше нужно опять думать.
Я уже вижу, как люди буквально начинают верить в то, что это и есть программирование. Отчасти они правы, ведь наша задача переводить естественный язык в понятный машине, но лишь отчасти.
Ребята посерьёзнее знают, что шум вокруг ИИ подобен парадоксу Солоу.
Я за взвешенный подход не только потому, что люди глупеют при использовании ИИ, но из-за того, что это порождает посредственность, убивает креативность и ставит специалиста в рамки его же промптов.
Чтобы создать что-то новое, нужно уметь выходить за рамки.
Нужно изобретать.
И что-то новое совсем необязательно очередной велосипед.
Не верьте звону вокруг, помните - ради чего вы вообще в профессии, особенно если кроме денежной мотивации есть что-то ещё.
Создавать всегда ценнее, чем просто копировать. Не каждый шорткат позволит вам быть впереди, иногда это путь в тупик.
Please open Telegram to view this post
VIEW IN TELEGRAM
5❤🔥31🔥13🍓8 5👍4🤯3🫡1
Как наш подписчик прокачал Swift, улучшив производительность для JSONDecoder+JSONEncoder
Я постоянно говорю о том, как важны метрики скорости/отзывчивости/производительности. Для пользователя это может оказаться решающим фактором при выборе приложения при прочих равных.
Но что делать, если вы нашили проблему в самом Swift? Как быть и куда идти с алгоритмом решения?
👩🎓 Наш читатель знает ответ на этот вопрос, ведь при поиске он буквально прошёл путь от первых гипотез до качественных инженерных решений (обязательно посмотрите его доклад, чтобы понять что не так с Codable, какие оптимизации можно сделать и какие бенчмарки можно чекнуть).
Проблемы парсинга могут стоять особенно остро, и я уверен что буквально каждый iOS-разработчик решал и решает схожие задачи прямо сейчас у себя на проекте.
На конкретном примере:
А буквально на днях его правки утвердили в Apple, что означает потенциальное ускорение JSONDecoder/JSONEncoder буквально в два раза.
📖 Описание проблемы и решения тут, а больше деталей здесь.
😃 iOS Dev
Я постоянно говорю о том, как важны метрики скорости/отзывчивости/производительности. Для пользователя это может оказаться решающим фактором при выборе приложения при прочих равных.
Но что делать, если вы нашили проблему в самом Swift? Как быть и куда идти с алгоритмом решения?
Проблемы парсинга могут стоять особенно остро, и я уверен что буквально каждый iOS-разработчик решал и решает схожие задачи прямо сейчас у себя на проекте.
На конкретном примере:
T.self is _JSONStringDictionaryDecodableMarker.Type
,value as? _JSONStringDictionaryEncodableMarker
иvalue as? _JSONDirectArrayEncodable
очень медленные. И чем больше двоичный файл, тем медленнее эта проверка работает в первый раз для каждой пары class/struct/enum и protocol. И Кристиан решил, что стоит изучить, нужны ли вообще эти проверки когда используются дефолтные keyDecoding/EncodingStrategy.
А буквально на днях его правки утвердили в Apple, что означает потенциальное ускорение JSONDecoder/JSONEncoder буквально в два раза.
📖 Описание проблемы и решения тут, а больше деталей здесь.
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥38 13❤🔥6🎉3 2👍1