🎉 Выпущено в релиз обновление iOS IQ - с новым режимом и поддержкой iOS 26

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

Что из мажорных изменений?

- Полноценный новый боевой режим «Исправь и собери код». Попробовал проверить, насколько вообще реально решать головоломки с кодом, пришёл к выводу, что собрать рабочий варик из хаоса даже 15 строк может быть утомительно - поэтому примерно этим размером и ограничил (рекомендую затестить дзен-рандом и не используйте подсказки, это не наш путь).
- Новый блок вопросов по многопоточке.
- Обновил несколько существующих веток с темами, добавил практически в каждую по несколько новых задач.

Был удивлён, что в даже в RC-версии Xcode завезли проблему с компилированием кода, если в проекте Metal (а у нас он есть), потратил наверное час, чтобы корректно зааттачить нужный тулчейн - если у кого-то есть такая же проблема, вот ветка.

🏠 Скачайте приложение в AppStore - и поставьте оценку, пожалуйста.

* кстати, бот также обновлен, удалил пару дублей в опциях и добавил несколько новых вопросов.

Пишите в личные сообщения канала (кнопка в телеге слева снизу), если вы хотели бы увидеть новые режимы или что-то ещё, я всегда всем отвечаю.

😃 iOS Dev

Кажется, пора внести ясность

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

Все мы хотим проводить рефакторинг! А какой разработчик не хочет?

Ведь тут как с автомобилем - вроде и едет, и тормоза в порядке, ну и что, если там где-то тарахтит или стучит, стоит ли всегда чекать шрус?

Напомню, что есть полезное правило трёх.

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

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

В такой момент важно не пропустить вспышку, когда дальнейшее наслаивание логики может поломать слишком многое внутри.

И в такой момент жизненно важно для проекта остановиться.

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

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

Так бывает не всегда.

Зато вы после проведённого рефакторинга сможете спать спокойно.

А вот стоит ли оно таких усилий - решать вам и вашей команде. Ведь многие проекты существуют и прекрасно себя чувствуют на стадии и так сойдёт.

Пишу про моменты, которые вам не расскажут ни на одной конференции здесь.

😃 iOS Dev

Почему проекты на Swift сталкиваются с трудностями (и как их преодолеть)

📖 У Tuist вышел разбор, в котором объясняется не только то, почему в крупных Swift-приложениях начинаются типичные проблемы, среди которых и медленные билды, и нестабильные тесты, но, например и то, как справиться со всем этим не прибегая к кардинальным изменениям вроде перехода на React Native или помощи Bazel.

Про React Native это отсылочка к недавнему разбору о том, как Shopify взял и перевёл все мобильные приложения на React Native. Хотя у всего есть своя цена.

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

Но вообще в статье есть важные поинты, на которые стоит обратить внимание и посмотреть, можно ли это изменить у вас на проекте:

- Безусловно, одним из факторов для возможного преодоления сложностей они считают модуляризацию.
- Время сборок. Тут не обошлось и без их паблик-дашборда.
- Работа с тестами и разбор флагов.
- Анализ сборок и выводы. Нельзя не вспомнить и про xcbeautify.
- Derived Data. Рассматривают и те проблемы, что есть сейчас, и заглядывают в будущее. На самом деле, Apple уже работает над подходом, называемым хранилищем с адресацией по содержимому и явными модулями, к которому они постепенно подталкивают пользователей.

😃 iOS Dev

Реализация алгоритма для навигации по метро Токио на Swift

В необычном докладе Крис рассказывает не только о способах получения следующих доступных станций в метро, но и о связывании инфы с Dynamic Island.

Сам проект использует два типа данных: статику от жд-системы и GPS в реальном времени от юзера.

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

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

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

😃 iOS Dev

Вышла первая версия Swift Configuration - новый инструмент чтения конфигов от Apple

В первую очередь либа преднозначена для экосистемы Swift-серверов, где конфиг часто считывается из нескольких источников. Но не только. Среди основных преимуществ:

➡️ Появился единый API для чтения конфигураций в приложениях и библиотеках.
➡️ Быстрый старт с поддержкой environment variables, аргументов, JSON/YAML и in-memory данных.
➡️ Есть опция создавать свои провайдеры конфигураций с открытым протоколом ConfigProvider.

Новая либа пригодится и в инструментах командной строки, и в тех приложениях и библиотеках, где нужно гибкое управление конфигурацией.

📖 Вводный пост здесь, примеры на GitHub, а вся документация (и кейсы использования) лежат вот тут.

😃 iOS Dev

Основы работы с памятью в Swift: size, stride, alignment

Одной из основных задач на моей текущей работе является работа с бинарным протоколом (когда-то давно выбрали его не только потому что он более компактен по сравнению с традиционными вариантами вроде JSON или XML), но и не в меньшей степени из-за скорости и эффективности обработки (а ещё безопасности).

При работе с памятью для новичков важно понимать всего лишь 3 основных свойства: это size, stride и alignment.

И хотя с size всё кажется очевидным, но даже в доках есть важная сноска:

Размер типа не включает в себя динамически выделенную память. В частности, MemoryLayout<T>.size, когда T является типом класса, остается неизменным независимо от количества сохраненных свойств T.

Для stride как и следует из названия:

это количество байт от начала одного экземпляра T до начала следующего при хранении в непрерывной памяти или в `Array<T>`.

А вот что такое alignment? И вообще что такое смещение значения и как оно влияет?

📖 Делюсь простой и понятной статьёй, в которой буквально на пальцах объясняют все эти свойства, а ещё какие сложности могут возникнуть.

И напомню про этот пост c разбором MemoryLayout.

✅ А если вы хотите разобраться с темой на более детальном уровне, то вам сюда.

😃 iOS Dev

Теорема о бесконечных обезьянах

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

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

А на дистанции длиной плюс-минус в бесконечность есть шанс, что она даже напечатает Шекспира.

Массовая истерия с ИИ мне напоминает примерно это же.

Я уже вижу, как готовят списки промптов, и, чёрт возьми, даже продают их: «что, серьёзно?» (тут нужен мем), а на сотнях сайтов вводят курсы как гуглить работать с ИИ или хакать подписку.

Самим не смешно?

Все создатели ИИ пишут эти советы, чтобы ты, pal, покупал их. Чтобы ты больше верил в то, что чудо-машина за тебя всё сделает.

Даже в Xcode внедрили ChatGPT - сколько там, 5 запросов, 10, 15? А дальше нужно опять думать.

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

Ребята посерьёзнее знают, что шум вокруг ИИ подобен парадоксу Солоу.

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

Чтобы создать что-то новое, нужно уметь выходить за рамки.

Нужно изобретать.

И что-то новое совсем необязательно очередной велосипед.

Не верьте звону вокруг, помните - ради чего вы вообще в профессии, особенно если кроме денежной мотивации есть что-то ещё.

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

😃 iOS Dev

Как наш подписчик прокачал Swift, улучшив производительность для JSONDecoder+JSONEncoder

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

Но что делать, если вы нашили проблему в самом Swift? Как быть и куда идти с алгоритмом решения?

👩‍🎓 Наш читатель знает ответ на этот вопрос, ведь при поиске он буквально прошёл путь от первых гипотез до качественных инженерных решений (обязательно посмотрите его доклад, чтобы понять что не так с Codable, какие оптимизации можно сделать и какие бенчмарки можно чекнуть).

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

На конкретном примере:

T.self is _JSONStringDictionaryDecodableMarker.Type, value as? _JSONStringDictionaryEncodableMarker и value as? _JSONDirectArrayEncodable очень медленные. И чем больше двоичный файл, тем медленнее эта проверка работает в первый раз для каждой пары class/struct/enum и protocol. И Кристиан решил, что стоит изучить, нужны ли вообще эти проверки когда используются дефолтные keyDecoding/EncodingStrategy.

А буквально на днях его правки утвердили в Apple, что означает потенциальное ускорение JSONDecoder/JSONEncoder буквально в два раза.

📖 Описание проблемы и решения тут, а больше деталей здесь.

😃 iOS Dev

Какими рабочими инструментами я пользуюсь ежедневно и сколько это всё стоит

Apple Developer Account (personal) - $ 99 в год. У меня аккаунт уже более 10 лет, не жалел ни разу. Есть ещё несколько учёток с доступом для работы, за них естественно платит компания.

Tower для работы с Git (оплачивает компания) - по факту $ 99 в год.

CyberDuck - бесплатный браузер для серверов и облаков с поддержкой FTP, SFTP, Amazon S3, OpenStack Swift, Microsoft Azure & OneDrive, Google Drive и многим другим. При закрытии есть алерт про донат (заплатил один раз $ 10, очень доволен).

Дев-фигма (точно не знаю цену, мне кажется около $ 25 в месяц) - оплачивает компания.

Для пет-проектов:

Лицензия Sketch - 110 евро в год. Всегда считал, что понимание принципов работы с интерфейсом (а не только гайдлайнов в коде) упрощает коммуникацию с командой дизайнеров.

Два акка Notion для бусти - каждый по 200 евро в год (я использую систему прямых инвайтов и отслеживаю доступ с помощью кастомной системы). Возможно, скоро понадобится ещё один, всё зависит от вас ❤️.

DB Browser для SQLite - бесплатно, с поддержкой на Patreon.

Оплата Cloud functions + Firestore для бота, портала и моей системы для трека ревенью от приложений (с вебхуками) - сейчас около 15 евро в месяц.

GitHub и GitHub Actions - пока бесплатно. Раньше юзал BitBucket, но недавно они перешли на лимит в 1ГБ для размера реп, к сожалению, вложиться не получилось, но может оно и к лучшему.

DaisyDisk - утилита для управления и удаления (ради чего и покупал) свободным местом. Стоило приложение $10, но периодически бывают всякие удобные акции и можно даже купить за $5.

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

ReviewBuddy - для отслеживания позиций в сторах с переключением без выхода из учётки, годовой премиум - $ 10, для меня - смотрите пункт выше.

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

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

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

Что не связано с работой напрямую: очень люблю слушать музыку, и сейчас у меня две подписки - Apple Music и Яндекс Музыка. Яндекс для меня в тысячу раз удобнее из-за бесконечных прослушиваний вроде моей волны с настройками, но к сожалению практически 70% того, что слушаю - там сейчас недоступно, приходится выкручиваться.

Поделитесь, а без какого инструмента вы не видите современную разработку? Согласны ли с тем, что сейчас подписка на LLM нужна также как интернет или можно обойтись? Может вы пишете инструменты сами?

😃 iOS Dev