Swift *

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

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

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

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

В этой статье мы узнаем, как профилировать сборку в Xcode и получать метрики. В следующей статье я расскажу о методах устранения узких мест и ускорения сборки проекта. Следует также упомянуть, что мы будем использовать проект Kickstarter iOS, который можно найти на Github. Так что давайте начнем!

Что мы измеряем?

Первое, что мы должны сделать, — определить, что мы пытаемся измерить и оптимизировать. Можно рассмотреть два варианта:

• Clean build — clean и сборки проекта. Часто clean сборка выполняется на CI для проверки нового pull request и выполнения юнит тестов.
• Incremental build — сборки проекта после значительных правок исходного кода. Эта сборка создается разработчиком во время работы над новой функциональностью.

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

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

В конце марта вышел релиз Swift 5.2 для Xcode 11.4. В нём улучшена диагностика ошибок, анализ зависимостей, расширен функционал SwiftPM. Обзор некоторых изменений уже был опубликован на Хабре, в этой же статье рассмотрена эволюция самого языка с возможными примерами использования.


 

Аннотация:

1. Пример реализации нового функционала в классе через добавление «флажка».
2. Последствия.
3. Альтернативный подход и сравнение результатов.
4. Как избежать ситуации: «Архитектурный оверкилл»?
5. Момент, когда приходит время всё менять.

Любому продукту, который в данный момент находится в сторе, грозят релизы. Наш проект не является исключением. Мы работаем по методологии scrum, разработка делится на спринты, обычно спринты не привязаны ко времени, а делятся на временные отрезки, зависящие от скоупа спринта. По итогам спринта обычно проводится релиз приложения в стор, который включает в себя новые фичи и некоторый багфикс.

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

• Итерационная разработка. Выпуск готовых и согласованных фич.
• Разное время приемки фич. Каждая фича имеет разный приоритет со стороны заказчика, что определенно влияет на сроки релиза даже уже готовых фич.
• Критические баги и SLA. При обнаружении реальных проблем на продовых сборках необходимо в кратчайшие сроки исправить баг и выкатить обновление.

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

Добрый день,

На практике iOS разработчик часто сталкивается с задачей показа большого количества информации в виде списка или в виде коллекции, как правило, для этого отлично подходят UITableView или UICollectionView. Также часто встречается задача реализации экрана, который представляет собой комбинацию списка и коллекции.

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

Привет, Хабр! Для пользователя сообщения об ошибке часто выглядят как «Что-то не так, АААА!». Конечно, ему бы хотелось вместо ошибок видеть волшебную ошибку «Починить все». Ну или другие варианты действий. Мы начали активно добавлять себе такие, и я хочу рассказать про то, как вы можете это сделать.



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

Давайте сразу сформулируем, что мы будем делать:

• Добавим типу Error функциональности
• Превратим ошибки в понятные для пользователя алерты
• Выведем в интерфейс возможные дальнейшие действия и обработаем их нажатия

И все это будет на Swift:)

Иногда нам нужно сформировать SwiftUI View, учитывая некоторые условия. Например, в приведенном коде мы определяем HomeView, который может содержать ProfileView, в случае если в LogInManager есть loggedInUser. Мы пытаемся это реализовать, используя стандартный оператор if:

В этой статье я бы хотел еще немного раскрыть возможности Core Data. Данная статья является продолжением. Я очень надеюсь что у меня получится донести мысль о том, что Core Data не одна из множества реляционных баз данных, а очень мощный инструмент который сможет стать неотъемлемым оружием в арсенале любого уважающего себя IOS-разработчика.

Кто не знаком с первой частью, настоятельно рекомендую прочитать первую часть

Ну что ж, начнем!

Apple предоставляет различные варианты обработки данных и событий в iOS приложениях. Обработка событий UIControl происходит через паттерн target-action. В документации к UIControl написано следующее:

The target-action mechanism simplifies the code that you write to use controls in your app

Посмотрим на пример обработки нажатия на кнопку:

Я редко занимаюсь чем-то «низкоуровневым». Мой примерный рабочий день состоит из разработки мобильных приложений для бизнеса и кучи разноплановых менеджерских штук. Само собой, иногда хочется отвлечься. Получается это редко, и, наверное, поэтому, доставляет особое удовольствие. В этот раз отвлечься было решено с помощью набора «Амперка. Тетра», который предназначен для детей и с помощью которого можно узнать основы схемотехники, названия всяких сенсоров, и попробовать попрограммировать что-то, работающее в реальном мире, а не на экране компьютера. В общем, когда ты взрослый бородатый мужик — вообще самое оно.

Что мы делаем? Сервис регистрации и авторизации пользователя для мобильного приложения

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

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

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

(ФЗ 152 «О персональных данных», ст. 12, Глава 2)

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

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

Здравствуй, Хабр. За недавние 7 месяцев обходил собеседований, где-то больше 20. Все они были на позицию Junior iOS developer. В итоге после многочисленных терзаний и подтягиваний различных нюансов мобильной разработки, мне дали офер в компанию, чему я был безумно рад.

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

Писать я тут буду только для Junior Swift iOS developer позиций. Другие собеседования на тех позицию не проходил.

Я перечислю списком вещи которые с вероятностью 99% вас будут спрашивать, потом я добавлю пару слов о каждом пункте.

Итак, начнем.

Тем с Core Data уже написано большое количество, но большинство этих статей на английском языке, а так же с использованием большого количества «умных» слов которые могут запутать новичков.

Продолжение серии статей [Часть 2]

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

Мы знаем, что ObservableObject классы с его @Published свойствами созданы в Combine специально для View Model в SwiftUI. Но в точности ту же самую View Model можно использовать и в UIKit для реализации архитектуры MVVM, хотя  в этом случае нам придется вручную «привязать» (bind) UI элементы к @Published свойствам View Model. Вы удивитесь, но с помощью Combine это делается парой строк кода. Кроме того, придерживаясь этой идеологии при проектировании UIKit приложений, вы в дальнейшем безболезненно перейдете на SwiftUI.

Цель этой статьи  состоит в том, чтобы на примитивно простом примере показать, как можно элегантно реализовать MVVM архитектуру в UIKit с помощью Combine. Для контраста покажем использование той же самой View Model в SwiftUI.

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



Код находится на Github.

Основной инструмент любого программиста — язык программирования. Когда начинался проект мы выбрали Swift. Решили идти в ногу со временем, старый, но так горячо любимый Objective-C остался не у дел. Однако у Swift есть небольшая проблема и особенно она становится заметной, когда проект начинает расти – это проблема времени сборки проекта. Для понимания проблемы и размеров проекта, попробуем сравнить среднее время сборки за неделю на всех проектах студии.

Cocoapods считается наиболее популярным менеджером зависимостей для iOS. Последние годы Apple работает над развитием своего нативного менеджера зависимостей Swift Package Manager (SPM).

Изначально его использование было возможно только для server-side Swift или приложений для терминала. На таких приложениях обкатывали и дорабатывали SPM, комьюнити знакомилось с его работой, а команда Apple получила бета тестеров.

С релизом Xcode 11 SPM начал приходить и в мир разработки под iOS. Сейчас это уже полноценный инструмент, который можно использовать, но пока с ограничениями.

Искусственный интеллект становится ближе с каждым годом, ещё вчера он был доступен только для ограниченного числа людей. Сегодня же мы можем сами создавать модели машинного обучения и использовать их в своих проектах. В этой статье мы познакомимся с инструментами Create ML и попробуем обучить модель для классификации изображений.

Но прежде чем начать, немного истории и пояснений. На ежегодной конференции для разработчиков WWDC2018 компания Apple представила инструменты для работы с машинным обучением Create ML. Обученная в Create ML модель является результатом применения алгоритма машинного обучения для набора обучающих данных. Модели не занимают много места (около 3Мб), поэтому их можно хранить в проекте. Изначально модели предлагалось обучать с помощью Playgrounds в XCode 10 и поддерживалась работа с изображениями, текстом и таблицами. При запуске playgrounds проекта необходимо было импортировать библиотеку CreateML и запустить MLImageClassifierBuilder (в случае если бы мы обучали модель для классификации изображений).

import CreateMLUI

let builder = MLImageClassifierBuilder()
builder.showInLineView()

В 2019 году Apple представила совершенно новый инструмент для работы с моделями машинного обучения, отделив его от Playgrounds. Стало возможным обучать модели без единой строчки кода. Список типов данных пополнился звуками и активностью. Всего представлено 5 типов данных и 9 шаблонов моделей. Давайте рассмотрим каждый тип данных и какие модели мы можем получить в результате.