Swift *

Регулярные выражения в Swift

Регулярные выражения позволяют нам выполнять сложные операции поиска и замены в тысячах текстовых файлов всего за несколько секунд, поэтому неудивительно, что они популярны уже более 50 лет. Apple обеспечивает поддержку регулярных выражений на всех своих платформах – iOS, macOS, tvOS и даже watchOS – все они используют один и тот же класс, NSRegularExpression. Это чрезвычайно быстрый и эффективный способ поиска и замены сложного текста десятки тысяч раз, и все это доступно для использования разработчиками Swift.

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

Начнем с основ.

Давайте начнем с пары простых примеров для тех, кто раньше не использовал регулярные выражения. Регулярные выражения – сокращенно regexes – предназначены для того, чтобы мы могли выполнять нечеткий поиск внутри строк. Например, мы знаем, что "cat".contains("at") является истиной, но что, если мы захотим сопоставить любое трехбуквенное слово, оканчивающееся на "at"?

Это как раз то, для чего предназначены регулярные выражения.

Сначала определим строку, которую мы хотим проверить.

Несмотря на то, что UIKit постепенно уступает место более современному во всех отношениях SwiftUI, до сих пор остается огромное количество проектов, которые основаны на фреймворке UIKit. Далее будет представлена библиотека, которая позволяет выполнять конструирование внешнего вида намного быстрее и удобнее, чем стандартные средства.

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

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

Например, фреймворк может быть использован для:

Измерение производительности iOS-приложений как правило производится путем профилирования приложения для расчета затрачиваемого времени в каждой функции. Обычно это делается с помощью Time Profiler в Xcode Instruments, но он известен, как медленный и ненадежный.

Emerge предлагает инструмент профилирования как часть Тестирования Производительности в CI. Данное профилирование представлено как flame-граф, и доказало, что может быть простым способом получить понимание о критических элементах, влияющих на производительность приложения, и находить решения. Сегодня мы представляем новый способ использовать те же самые великолепные визуализации профилирования, полностью локальные и с открытым исходным кодом.

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

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

Написание нативных Swift модулей для React Native на примере Yandex Mapkit или коротко о том, куда потратить пару часов свободного времени, если ты React Native разработчик.

Привет, Хабр. Меня зовут Кирилл Смирнов. Я технический лидер iOS команды в СберЗдоровье. Последний год наша команда активно занимается улучшением инструментов разработки, в том числе модуляризацией, и уже успела получить опыт, который может быть полезен другим. В предыдущем материале я рассказывал, как компании подготовиться к модуляризации iOS приложений, а в этом остановлюсь на вопросах оптимизации сборки проекта и выборе вариантов линковки артефактов компиляции.

Привет! Меня зовут Сергей Балалаев, я руковожу отделом разработки мобильного приложения для ПВЗ в Ozon. Это то самое приложение, которым сотрудники пунктов выдачи сканируют штрихкод, чтобы выдать товар получателю. Оно внутреннее, для сотрудников. iOS-версией постоянно пользуются 12 тыс. человек, поэтому при постановке задачи нас не просили делать мультиязычную версию. Но мы с самого начала разработки решили поддерживать несколько языков — когда возникнет необходимость локализации, справимся в спокойном режиме и без проблем, свойственных проектам, в которых локализацию не закладывали.

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

Не так давно на проекте возникла необходимость настроить периодическое обновления информации со стороннего сервиса. В моем случае это был файл‑справочник в формате JSON, хранящийся в Bundle приложения, и ещё Info.plist в придачу. Отмечу, что такие файлы нельзя изменять в запущенном iOS приложении. Да и вообще, вызовы напрямую в сторонний сервис уже в рантайме меня не сильно радовали — в случае сбоя загрузки данных у приложения отваливался кусок функциональности.

Как бы вы поступили в этом случае? Вынесли бы кэширование таких файлов на ваш бэк? Таким образом мы бы решили проблему со сторонним нестабильным сервисом, но что делать с Info.plist?

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

В сети много материала по созданию Command Line Tool на Swift, но мы разберем абстрактный пример создания такой утилиты сразу в связке с iOS проектом.

К сожалению, как нам пояснил Дуг Грегор (Doug Gregor) из Swift Language Workgroup, Swift 6 все-таки не успеет увидеть свет в 2023 году. Но знали ли вы, что Apple уже зарелизила некоторые части Swift 6 в версии 5.8? Да, вы не ослышались. Эти части нового Swift поставляются с Xcode 14.3, но они по умолчанию отключены. Они заработают сразу после выхода Swift 6, что может занять еще один год или даже больше.

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

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

К счастью, в Swift 5.8 есть легкий универсальный способ активировать все эти опции: нам просто нужно передать в Swift флаг -enable-upcoming-feature, прописав его в OTHER_SWIFT_FLAGS настройках сборки нашего проекта в Xcode. А также нам нужно знать, какие именно фичи нам доступны, но я не смог найти хорошего комплексного обзором (по крайней мер пока). Предложение, в рамках которого был добавлен этот унифицированный способ активации, содержит такой список, но он не обновляется более новыми опциями, добавленными позже, как, например, в SE-0384. Так где же мы можем получить достоверный актуальный список всех поддерживаемых опций?

В предыдущей части мы разобрали преимущества работы с async/await по сравнению с GCD. В этой части мы более подробно рассмотрим ключевые слова async и await (и не только). Разберемся в том, как они работают, что означает "неблокирующее ожидание" и самое главное рассмотрим это все на примерах.

Power asserts (также известные как диаграммированные утверждения) дополняют ваши ошибки утверждений информацией о значениях, полученных во время оценки условия, и представляют ее в легко усваиваемой форме. Power asserts являются популярной функцией Spock (а позже и всего языка Groovy независимо от Spock), ScalaTest и Expecty.

Power asserts предоставляют описательные сообщения об утверждениях для ваших тестов, подобные следующим примерам:

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

Современные технологии – это истинное благо для любого бизнеса. Но точно так же они могут стать самым настоящим проклятьем. Только представьте. Вы захотели создать собственное мобильное приложение. Идея уже есть, спонсоры найдены, и, казалось бы, выпускай себе приложение и покоряй им мир стандартными «Efficiency, Resilience and Innovation • Trust • Human-Centered approach • Passion • Excellence». Но в действительности все оказывается куда сложнее. Вы приходите к специалистам и не понимаете, кого слушать. Одни наперебой убеждают вас, что приложение стоит сделать на технологии React Native, а другие упорно доказывают, что нет лучшего решения, чем разработка на Swift/Kotlin. Звучит знакомо? Тогда эта статья точно вам поможет.

Системный Segmented Control - это хорошо и удобно. Но когда доходит до его кастомизации, проще написать свой гибкий компонент с нуля. В этой статье история разработки своего segmented сontrol'а, переросшего в отдельную внешнюю зависимость, с ожидаемыми и не очень сложностями.

Привет, Хабр! На связи Сергей, iOS-разработчик в компании SimbirSoft.

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

Интеграция Combine в проект будет полезна для обеих сторон — бизнеса и команды разработки:

1. Процесс работы становится быстрее, а значит дешевле.

2. Фреймворк считается достаточно модным. Есть большое количество разработчиков, которым нравится использовать реактивный подход, и которые хотят поработать с новым инструментом — повышается интерес соискателей к вакансиям, в которых фигурирует эта технология.

3. Combine способствует легкой поддержке и удобном переходе на современные технологии в будущем (например, на SwiftUI).

Всем привет, с вами я, Анна Жаркова, ведущий разработчик компании Usetech. 

Apple уже опубликовала анонс WWDC 2023, который пройдет 5-9 июня. А это значит, что время загадывать и угадывать, что же нового нам представят из инструментария iOS SDK.

И начнем мы со Swift 5.8, который официально вышел (ссылка). В новой версии появились доработки, связанные как с самим sdk и Swift, так и SPM, инструментом документации и SwiftSyntax. Часть новинок уже разобрал у себя Пол Хадсон, и об этом можно почитать здесь, здесь и здесь.

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

Математически ряд Фибоначчи представляет собой последовательность чисел, которые следуют этому уравнению: F(n) = F(n-1) + F(n-2). Эта последовательность встречается в различных интересных контекстах, например, в природе, в раковинах, спиральных структурах и галактиках, а также в дизайне римских полов, и даже брокеры используют ряд Фибоначчи для прогнозирования акций.

DoccGPT - это эксперимент по полной автоматизации документирования кодовой базы на Swift. Он еще не закончен, но - будет (FAQ читайте ниже).