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

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

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

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

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

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

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

Все создатели ИИ пишут эти советы, чтобы ты, 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

Импорт файлов в SwiftUI: рабочий пример

Периодически самым разным приложениям может пригодиться опция работы с файлами.

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

📖 На этом несложном примере можно посмотреть пример настройки и разобраться с каждым параметром по отдельности.

🛠 А тут доступен исходный код.

😃 iOS Dev

Реализация перетаскивания элементов в SwiftUI

Применений этого механизма множество: от организации фоток в альбомах до, например, реализации какого-нибудь таск-менеджера вроде трелло.

Подход с использованием стандартных модификаторов onDrag и onDrop имеет ряд преимущество по сравнению с этим вариантом.

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

📖 В этом материале можно посмотреть реализацию этого варианта на реальном примере.

😃 iOS Dev

😳 AppMigrationKit - новый фреймворк для переноса данных на Android

Экспансия Apple продолжается, буквально только что анонсировали новый фреймворк для экспорта данных приложения на другое устройство или для импорта с другой платформы.

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

Информации пока немного, но уже есть условия:

AppMigrationKit поддерживает только миграцию на и с платформ, отличных от Apple, таких как Android. Система не использует фреймворк для миграции между устройствами iOS или iPadOS. Фреймворк также не имеет функциональности в приложениях iOS, работающих в visionOS или macOS на Apple silicon. Фреймворк игнорирует вызовы из приложений Mac, созданных с помощью Mac Catalyst.

📖 Остальная информация - здесь.

😃 iOS Dev

Навигация в SwiftUI: типы, отличия, разбор неочевидных моментов

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

Посчитал, что полезно будет собрать в одном месте несколько подходов к реализации, посмотреть на разные опции и закрепить вопросами важные моменты.

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

Навигация ранее многих даже останавливала от использования SwiftUI, но с 16 оси мне кажется, всё стало намного проще.

А почему стало проще? Я собрал три важных раздела, добавил реальных примеров и попробовал задать несколько вопросов на рассуждение.

👩‍🎓 Уже сейчас можно чекнуть основные типы навигации в SwiftUI (в том числе затронул и пример реализации координатора, который из коробки не так просто завести).

А также вас ждёт список полезных ссылок и новая свежая вопросная секция (в том числе с задачками на рассуждение).

🧠 Что вы получите, подписавшись сегодня:

➡️Разбор нескольких сотен вопросов на сложные темы
➡️Вопросы на чтение кода
➡️Многопоточность
➡️DispatchQueue: практические вопросы
➡️Swift Concurrency
➡️Алгоритмы: терминология и примеры
➡️Память: ARC, side table, флаги, утечки
➡️Множество анимаций, шейдеров и не только

Подписаться можно на 💰 бусти и ⭐️ в телеграме.

😃 iOS Dev

Цена ошибки

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

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

В частности, есть можество примеров последствий, к которым могут приводить ненавязчивые «и так сойдёт, чекнем в следующем релизе».

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

В iOS было много примеров багов, которые правились пассивно (или не правились вовсе).

Например, в 7 оси можно было скипнуть локскрин с помощью комбинации использования контрол-центра и многократного нажатия на камеру/таймер.

Я намеренно не перечисляю кучу ошибок с календарём, режимом не беспокоить и так далее (кстати, проблему в эпл не устраняли, а попросили подождать неделю).

А сколько было проблем с сообщениями, которые окирпичивали ваши девайсы? Тысячи их.

Кто юзает эпл-технику давно, помнит, как даже пятисекундное видео могло заставить вас ребутать смартфон.

Проблемы с нагревом, случайными ребутами на морозе (классика почти для всех наших регионов в РФ), а из недавнего проблемы с Face ID.

К сожалению, это справедливо и для макоси, на тахо, например - куча историй с дропом/шумом и вообще локом аудио-модуля при использовании симулятора (чинится только через kill). Я уже писал и про способ фикса metal-тулчейна в Xcode.

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

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

Главное, чтобы первый вайб-кодинг баг не стал последним. Хорошо, что это всего лишь банковское приложение, правда? И этот список транзакций не нужно было давать при подаче на визу или проверять у tax-department.

Люди допускают ошибки. Но ИИ - не просто делает то же самое, он снижает вашу внимательность, увеличивает энтропию и усложняет поддержку в будущем.

Я рад, что есть истории упрощения рутины (это здорово), написание тестов - кайф, особенно если они не начинают флаковать, мок-данные - великолепно, очень удобно

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

Чтобы потом впопыхах не искать Vibe Code Cleanup Specialist (ведь этим специалистом чаще всего будете вы сами).

😃 iOS Dev

Создание кастомных контролов в SwiftUI

По сравнению с UIKit сейчас гораздо проще создать кастомный элемент управления на любой вкус.

Джордан Морган делится интересным подходом к реализации, когда каждый контрол должен соответствовать трём правилам:

1️⃣ Простота освоения: если что-то неочевидно, то люди в целом не будут этим пользоваться.

2️⃣ Контрол должен быть запоминающимся. Если нет очевидной причины использовать системное решение, то стоит дважды подумать, прежде чем делать своё.

3️⃣ Доступность. Если что-то не может быть использовано всеми, возможно этот контрол не нужно делать.


😃 iOS Dev

Лёгкая демонстрация эффекта липкости на SwiftUI

📖 Минсанг Чой поделился необычным подходом к реализации (без использования Metal 😉).

🛠 Исходный код доступен на GitHub.

😃 iOS Dev

Повторяем эффект Apple Intelligence - разбор+код

В новой оси можно было заметить анимированный эффект обводки, который динамически подсвечивает формы и компоненты.

📖 В этой статье автор пробует воссоздать этот эффект в SwiftUI с помощью модификаторов для фона и оверлэя и делится расширением.

🛠 Исходный код доступен здесь.

Если захотите подключить через SPM, то используйте этот адрес (в самой репе ошибка).

😃 iOS Dev

Классическая история

Написание кода - это лишь верхушка айсберга наших задач.

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

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

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

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

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

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

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

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

Здесь всё сложнее.

😃 iOS Dev

Кэширование изображений в SwiftUI

Ещё в 15 оси появилась полезнейшая AsyncImage (можно грузить изображения без лока интерфейса), но есть небольшая загвоздка: SwiftUI, например при скролле вверх-вниз картинка будет загружена заново.

И как раз в таких ситуациях не обойтись без кэширования.

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

📖 В этой статье рассматривается полезный для новичков способ работы с NSCache и его настройка.

Напомню и про эти материалы:

➡️ Загрузка UIImage с диска: разбор сценариев и импакт на память
➡️ Контроль и оптимизация процесса декодирования изображений в iOS

😃 iOS Dev