Xcode *

На Mastodon кто-то спросил, можно ли подключить Google Gemini к бете Xcode 26 в macOS 26. Можно! Но… с помощью небольших хитростей и прокси-скриптов.

После добавления зависимостей Firebase через CocoaPods в iOS-проект, при сборке я столкнуться с не приятной ошибкой:

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

Давайте разберемся, как опубликовать наше первое приложение в AppStore. 

В этой статье я расскажу о том, как создать нативный Sheet, который автоматически подсчитывает свою высоту в зависимости от котента (SwiftUI View). Задача была в том, чтобы решение было c минимумом костылей и сохраняло поддержку iOS 15. Готового похожего решения мне не удалось найти, поэтому решил создать свой вариант.

Итак, есть задача: переделать экран авторизации на новый дизайн. И заодно на SwiftUI. Одна загвоздка — проект пока ещё поддерживает ios15, из‑за этого многие фичи SwiftUI недоступны.

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

Всё началось как обычно, а что если ...

Как минимум одна из фич iOS реализована действительно хорошо — это системное резервное копирование, и всё, что связано с автоматическим переносом данных при переезде с одного iPhone на другой.

Однако в случае с некоторыми iOS-приложениями старания Apple внезапно разбиваются о небрежность их разработчиков. Именно с этим я недавно столкнулся, выполнив перенос данных со своего старого iPhone на новый, и много где результаты оказались довольно печальными. Полностью упоролось, например, приложение Тинькофф Банка.

И тут возникает закономерный вопрос — почему так получается, что с этим делать?

Постановка проблемы

На сегодняшний день наиболее известны такие архитектурные паттерны как MVC, MVVM, MVP, Viper, Clean Code.

Все они в той или иной мере работают с тремя основными сущностями - Модель, Вью, Контроллер, добавляя время от времени некоторые дополнительные, например, Presenter.

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

Но эти характеристики не отражают сущности приложения в целом. Это как если бы мы разделили воду на водород и кислород и пытались бы из их особенностей понять сущность воды.

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

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

Именно в такие моменты приходится переосмысливать общую архитектуру проекта и отвечать на вопросы “Зачем нужен тот или иной код, какую задачу он решает?”, “Где расположен код, реализующий ту или иную функциональность и как он работает?”. И т.д.

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

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

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

При этом, задача понимается как бизнес-процесс.

Мне хотелось посмотреть, как работает ИИ Редактор кода Cursor AI на примере создания iOS приложения с выборкой данных с ресурса, который не требует API key и платной подписки. И этим ресурсом оказались публичные фотографии с Flickr.com.

Необходимо создать UI iOS приложения со строкой поиска вверху и сеткой Grid под ней для отображения миниатюр фотографий.

Пользователь должен иметь возможность вводить текст в строку поиска и видеть набор фотографий, теги которых tags соответствуют строке поиска. Строка поиска может содержать одно слово (например, «rose») или разделенные пробелами слова(например, «forest bird» (лес птица)).

Проблемы с графикой на iOS? Скрытые дебаг-фишки Xcode спасут вас!

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

Я расскажу, как исправить поехавшие пиксели с мощными дебаг-инструментами, и приведу примеры багов отображения на iPhone 16 Pro. Мой гайд поможет вам оптимизировать графику и сохранить пользователей, которых бесят тормозящие приложения.

Больше всего мне нравится изучать процессы мобильной разработки, включая самые низкоуровневые вещи. Из чего состоит iOS-приложение? Какие этапы оно проходит перед тем, как оказаться на устройстве пользователя? Что такое Executable binary? Что происходит внутри препроцессора?

Если вам, как и мне, интересно разбираться в Computer Science для iOS, приглашаю под кат. Разберём первые, самые базовые понятия, которые касаются любого iOS-приложения. Статья поможет тем, кто хочет двигаться дальше, кому интересен IT мир, и кто по каким-то причинам ещё не приступил к изучению подобного материала.

Продолжаю эпопею с модальными экранами на SwiftUI. Но сегодня больше кода. Была задача, сделать ProgressView и SkeletonView. Вдруг кому-то пригодится, показываю.

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

Я уже 2 месяца прохожу обучение в онлайн‑школе и у нас на этой неделе был открытый урок, нужно было подготовить доклад на тему «Малоизвестные фичи или особенности языка Swift»

Так вот — я решила погуглить этот вопрос, подготовилась, написала код. Но когда дело дошло до самого выступления, оказалось, что говорить ртом — это не так‑то и просто. Да и в целом выступать, даже в Zoom.

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

Недавно я столкнулся с задачей, которая требовала написания большого объема шаблонного кода. Вспомнив, что в Swift 5.9 появились макросы, созданные специально для генерации шаблонного кода, я решил попробовать их в действии. Ранее я работал с макросами в Objective-C и C++, поэтому ожидал увидеть нечто похожее. Однако, поискав информацию, я понял, что макросы в Swift — это совсем другое, не похожее на то, что я встречал в других языках.

В отличие от макросов в C++ или Objective-C, в Swift нужно писать гораздо больше кода, соблюдая при этом строгие правила оформления. Иначе можно столкнуться с загадочными ошибками компиляции, решение которых не всегда очевидно. Дополнительные трудности возникают из-за того, что многие статьи и видео просто повторяют официальную документацию, не объясняя понятным языком, как именно использовать макросы. Часто вместо этого начинаются сложные рассуждения о структуре AST (Abstract Syntax Tree) или приводятся примеры кода, которые демонстрируют результат работы макроса, но не показывают, как его создать и отладить.

Именно из-за таких трудностей я решил написать эту статью. Её цель — максимально просто, без углубления в теорию, объяснить, как можно уже сегодня начать использовать макросы в Swift. Если вам захочется изучить эту тему подробнее, вы всегда сможете обратиться к официальной документации или материалам с WWDC, где этот вопрос разобран более детально. А если вам понравится моя подача, пишите в комментариях — я постараюсь объяснить сложные моменты в отдельных статьях.

В этой статье изначально планировала написать продолжение первой части статьи. А именно показать обещанные ProgressView и SkeletonView. Но тут на моём пути возникло неожиданное препятствие.

Обо всём по порядку.

Мы же понимаем, что просто так оставить View со всем функционалом внутри нельзя. Обычно я накидываю быстрый функционал и UI в одном классе, а затем уже разделяю. Использую MVVM архитектуру. И модальное окно не стало исключением. Проверив, что всё работает во View, я создала ViewModel, сделала её ObservableObject

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

Привет! Меня зовут Антон Долганов, я iOS-разработчик в компании Контур. Я работаю над инфраструктурными модулями и параллельно поддерживаю наше приложение Контур.Коннект, которое используется для подключения к внутреннему VPN и даёт доступ к корпоративным сервисам.

Недавно мы выпустили обновление Коннекта, добавив поддержку Быстрых команд (Shortcuts). Теперь можно включать и отключать VPN, даже не заходя в приложение. В этой статье я расскажу, как я это реализовал и почему это полезно.

Не так давно прогремела новость, что Cocoapods переходит в режим поддержки, больше не будет развития, а только поддержка. В связи с этим встал вопрос, что дальше. В начале мы склонялись к чисто Swift Package Manager, но потом пришло понимание, что неплохо было бы уйти от конфликтов в project файле и сделать задел на модульность. В этой статье постараюсь описать полный путь от Cocoapods к Tuist+SPM, затрону то, что было мне было не понятно в других статьях и передать опыт, чтобы облегчить другим переход.

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

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

Всем привет! Меня зовут Фарид, я занимаюсь iOS-разработкой в компании Банки.ру.

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

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

В этой статье мы: 

1) пройдёмся по основным подходам к поиску утечек; 
2) попробуем найти способ сделать его обнаружение утечек менее болезненным;
3) выясним, можно ли каким-то образом застраховаться от утечек в будущем развитии проекта.