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

_{^{(*одно из значений слова flutter — порхать)}}

Разбираемся, есть ли жизнь сохранение состояния во Flutter-приложении. Что будет, если ОС решит его перезапустить. Куда денется пользовательский ввод и навигация, и как с этим справляться.

Дисклеймеры:

• для понимания нужно иметь стартовые знания о Flutter;
• рассуждаю с точки зрения Android, про iOS — это не ко мне;
• не являюсь специалистом по Flutter/Dart, подхожу с позиции новичка;
• в некоторых местах опускаю второстепенные моменты (например, реализации вспомогательных функций), найти недостающее можно в полном коде проекта.

Apple Review Guidelines достаточно подробны, но приложения проверяют живые люди и часто трактуют правила по разному.

Предлагаю в комментариях рассказать о ваших реджектах приложений и как вы их решили.
Под катом несколько примеров.

Тестирование – очень важный этап разработки мобильных приложений.

Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore несколько недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную негативную реакцию, пользователи оставляют низкие оценки и истерические отзывы. Новые пользователи, видя это, не устанавливают приложение.

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

Поэтому в отделе тестирования у нас работает 8 человек (0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.

Под катом я расскажу как мы тестируем мобильные приложения.

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

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

Вид тестовой документации также зависит от ситуации на проекте и ожиданий заказчика.

Не так давно для андроид-разработчиков Google представил новую библиотеку — Android Architecture Components. Она помогает реализовать в приложении архитектуру на основе паттернов MVx (MVP, MVVM etc.). Кроме того, уже давно выпущена другая библиотека от Google — Data Binding Library. Она позволяет прямо в разметке связывать отображение UI-контролов со значениями, содержащимися в объектах. Это важная особенность паттерна MVVM — связывать слой View со слоем ViewModel.

Обе библиотеки направлены на построение архитектуры Android-приложений в MVVM стиле.
Я расскажу, как можно использовать их вместе для создания проекта с архитектурой на основе MVVM.

Когда в CRM 57000 контактов, людям совсем не хочется записывать их в айфон вручную. Надо найти решение поизящней, которое позволит не просто искать контакты в отдельном приложении, но и отображать имя человека при входящем звонке. Мы долго гуглили, а потом вспомнили про анонс фреймворка CallKit с WWDC. Информации по этой теме оказалось не так много: немногословная документация, статья на Хабре и ни одного пошагового руководства. Хочу восполнить этот пробел. На примере создания простого приложения покажу, как научить CallKit определять тысячи номеров.

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

• Pthreads, или потоки POSIX. Библиотека для низкоуровневой работы с многопоточностью. Определена как набор типов и функций на языке C. Подробнее можно ознакомиться тут.
• Background selectors. Это отправка сообщения объекту, которое будет исполнено на указанном потоке. В коде это селектор с названием performSelector и различными параметрами (например, performSelectorOnMainThread:withObject:waitUntilDone:). Документация
• NSThread. Представлены как базовые средства для работы с потоками. Ознакомьтесь с концептуальным документом по работе с потоками и документацией.
• Grand Central Dispatch. Библиотека, основанная на блоках — анонимных участках кода, иначе замыканиях. Рабочее название — libdispatch.
• NSOperation. Построен на основе GCD. Стоит заметить, что сама операция является абстрактной сущностью и на практике стоит использовать NSInvocationOperation и NSBlockOperation.

В этой статье поговорим о вопросах GCD.

Два года назад я начал негласно исполнять роль iOS-lead в компании Touch Instinct и формированием стабильной работы iOS-отдела. Спустя полгода это трансформировалось в официальную должность. Из-за отсутствия опыта у меня возникало огромное количество проблем, которые вызывали жжение в области верхней части кресла. Это происходило из-за ряда факторов:

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

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

Тема статических анализаторов кода изъезжена. Последние полгода практически нет конференции без выступления, посвященного этому вопросу. Но все они рассказывают об анализаторах изнутри, показывают механизмы их работы. При этом забывают грамотно объяснить, для чего они изначально предназначены. Чаще всего рассматривается теоретическая часть работы статических анализаторов, без практической реализации. Поэтому расскажу про цели, которые преследуются статическими анализаторами в реальных командах на коммерческих проектах. А также рассмотрю пример организации работы с различного рода анализаторами в нашей компании.

На WWDC 2017 Apple анонсировала ARKit — SDK для работы с дополненной реальностью. Благодаря ему порог вхождения в эту технологию стал значительно ниже. Можно ожидать появления большого количества качественных игр и приложений.

На одном из проектов столкнулась с утечками памяти. Воспользовалась первым правилом разработчиков — загуглила. К моему глубокому разочарованию нашла много статей для программистов и совсем чуточку для тестировщиков. Большинство публикаций датированы 2011-2014 годом.

Ниже информация об утечках памяти, которая пригодится в 2017 году. Расскажу, чем их наличие грозит приложению, и перечислю несколько подходов к локализации.

В этом году с нетерпением ждал WWDC. Хоть Apple и сидит на самой большой горе кэша в истории, конкуренты подпирают со всех сторон. Гугл с телефонами, Амазон с Алексой, Майкрософт с AR — в какой-то момент даже показалось, что Apple начинает догонять, а не лидировать. Но сегодняшний keynote вернул все на свои места.

Доброго времени суток! Меня зовут Иван Смолин, я разработчик мобильных приложений на платформе iOS. Сегодня предлагаю вам окунуться в мир функционального программирования. Статья носит по большей части теоретический характер, нежели практический. В ней я постараюсь дать определения основным понятиям функционального программирования и покажу примеры реализации на C, Objective-C, Swift, Haskell.

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

Существует 6 основных концепций:

• концепция первого класса и функций высшего порядка
• концепция чистых функций
• концепция неизменяемого состояния
• концепция опциональности и сопоставления с образом
• концепция ленивости и бесконечных структур данных
• концепция лямбда-исчислений

Привет! Меня зовут Гавриил, я Android-лид Touch Instinct.

В марте Google выкатил релизное обновление ConstraintLayout. Презентовали его еще на прошлом Google I/O. С того момента прошел почти год, ConstraintLayout стал лучше, быстрее и оброс новыми возможностями. Например, приятно, что появилась возможность объединения элементов в цепи — это позволяет использовать ConstraintLayout вместо LinearLayout.

О всех новых и старых возможностях ConstraintLayout я и постараюсь рассказать в этой статье. Предупрежу сразу — статья будет длинная и других семи частей не будет. Про визуальный редактор ConstraintLayout в статье не будет ни слова — только XML-разметка (по старинке) и немного кода.

Доброго времени суток! Меня зовут Иван Смолин. Я iOS разработчик в Touch Instinct.

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

Привет, я Андрей, управляющий партнер в Touch Instinct. Расскажу вам, как съездил на Google I/O. Ниже экскурсия по площадке в Маунтин-Вью, обзор конференции и много фоток.

Меня зовут Лена, я руководитель отдела тестирования Touch Instinct.

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

Расскажу, какие аналитические задачи встают перед тестированием в Touch Instinct и как мы их решаем.

Привет! Я Алиса, маркетолог в Touch Instinct. Мы делаем мобильные приложения для неравнодушных брендов. Сегодня небольшая экскурсия по штаб-квартире в Петербурге, присоединяйтесь.

Всем доброго времени суток! Меня зовут Николай, я iOS-Lead в компании Touch Instinct. В процессе разработки часто приходится иметь дело с проектами, которые должны работать на нескольких языках. Расскажу, к какому подходу мы пришли при работе с локализацией.

Минусы базовых подходов

Есть несколько основных подходов для локализации iOS-приложения. Сперва стоит определиться, разрабатывается приложение с использованием storyboards или нет.

С использованием storyboards

Можно локализовывать строки напрямую в storyboard. Однако, при таком подходе есть ряд минусов:

• в случае наличия большого количества storyboards, локализованные строки разбросаны по проекту;
• невозможность использования атрибутных строк, а также строк, которые состоят из нескольких составных частей;
• вам всё равно придется часть строк локализовывать в коде. Это ведет к еще большему разбросу в приложении;
• фактически отсутствует возможность что-то проверить другому разработчику при проведении code review.

Без storyboards

В этом случае локализуем всё в коде. Однако и тут есть ряд минусов. Дело в том, что файлы со строками локализации localizable.strings — магические. При изменении таких файлов очень велика вероятность возникновения ошибки из-за человеческого фактора. Изменения нельзя отследить, пока ошибка не будет найдена в процессе тестирования.

Таким образом, хотя для локализации уже есть готовые механизмы в iOS SDK, они имеют существенные минусы. Более подробно смотрите здесь.