App Extensions появились в iOS 8 и сделали систему более гибкой, мощной и доступной для пользователей. Приложения могут отображаться в виде виджета в Центре Уведомлений, предлагать свои фильтры для фотографий в Photos, отображать новую системную клавиатуру и многое другое. При этом сохранилась безопасность пользовательских данных и системы. Об особенностях работы App Extensions и пойдёт речь ниже.

Согласно BetaNews, из 30 лучших приложений с более чем 500 000 установок 94% содержат по меньшей мере три уязвимости среднего риска, а 77% содержат хотя бы две уязвимости с высоким уровнем риска. Из 30 приложений 17% были уязвимы для атак MITM, подвергая все данные перехвату злоумышленниками.

Кроме того, 44% приложений содержат конфиденциальные данные с жесткими требованиями к шифрованию, включая пароли или ключи API, а 66% используют функциональные возможности, которые могут поставить под угрозу конфиденциальность пользователей.

Именно поэтому мобильные устройства являются предметом многих дискуссий по вопросам безопасности. Принимая все это во внимание, мы в ByteCodeрешили рассмотреть методологию OWASP Mobile TOP10 с целью продемонстрировать процесс проведения анализа мобильных приложений на уязвимости.

OWASP Mobile TOP 10 — одна из основных методологий тестирования приложений на уязвимости. В таблице 1 описаны 10 уязвимостей, которые применяются для характеристики уровня безопасности приложения. [2,7,11]

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

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

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

Под катом представлена обобщенная эвристика к алгоритму A*, полезная именно в свете практической пригодности на больших графах при ограниченных ресурсах, например, на мобилке.

Однажды менеджеры Лайв Тайпинг подумали: «Как хорошо было бы иметь инструкцию-чеклист, чтобы ничего не забыть перед публикацией приложения в стор. С ней можно перестать носить всё в голове и не объяснять вновь пришедшим менеджерам, что к чему, а просто скинуть гуглдок». Подумали и написали — для себя. Но потом поняли, что нехорошо скрывать полезную информацию от общественности. Поэтому мы надеемся, что инструкция поможет менеджерам всех остальных студий так же, как помогает нам.

Тема этой заметки — публикация приложения в App Store. Чуть позже мы опишем порядок действий для публикации в Google Play.

Что же нужно сделать PM`y в ходе публикации:

1. создать аккаунт в App Store для заказчика, если у заказчика его нет, или предложить
2. опубликовать приложение с нашего аккаунта;
3. подготовить маркетинговые материалы (иконка, скриншоты, текст, видео для предпросмотра приложения);
4. приложить к сборке сертификат цифровой подписи;
5. настроить оплату за пользование приложения;
6. Отправить сборку в App Store.

Идём под кат и разбираем по порядку.

1 марта в офисе Avito состоялась очередная встреча сообщества iOS разработчиков CocoaHeads. Под катом вас ждут небольшой рассказ о том, как прошёл митап, и, самое главное, видеозаписи докладов. Приятного просмотра!

Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

• Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
• Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

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

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

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

В июне мы ездили на WWDC 2016, и на одной из сессий ребята из Apple обмолвились, что наконец-то можно делать «gorgeous astonishment» — определитель номеров под iOS 10. Радости нашей не было предела, но до поры до времени: как Apple любит, фичу она предоставила с рядом ограничений.

Уведомления в iOS 10

Говорят, что на этом WWDC не было ничего интересного, кроме интерактивных уведомлений. Действительно, новые уведомления одна из самых интересных новых фич. Не только для разработчиков, но и для простых пользователей. В iOS 10 попытались унифицировать работу с локальными и пуш-уведомлениями и добавили для этого новый фреймворк UserNotifications.framework. Старое API теперь запрещено (deprecated), но его можно использовать до тех пор, пока вы поддерживаете iOS 9.

Новые уведомления умеют:

• показывать вложения (картинки и видео)
• отображать кастомный UI
• показывать стандартный UI в активном приложении (why so long!11)
• удалять себя из центра уведомлений (!!1)

В этой статье разберемся как это работает. Будет интересно не только разработчикам, но и UX проектировщикам.

Случалось ли с вами, что вы открыли Storyboard и от увиденного вас начинают переполнять положительные эмоции?

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

Привет! Последние несколько лет я занимался фрилансом на Upwork (бывший oDesk) и вот наконец решился поделиться своим опытом и наблюдениями с Хабрасообществом в небольшом цикле статей. Начать хотелось бы издалека: кому на мой взгляд стоит рассмотреть фриланс как основной вид своей деятельности + хотелось бы разобрать основные «отпугивающие» факторы, которые мешают многим решиться. Кому небезразлична тема фриланса и Upwork в частности — добро пожаловать под кат.

Всем доброго времени суток. Сегодня хочется поговорить про проблему валидации строк в IOS проектах. Думаю Вы как и я часто с этим сталкиваетесь, когда надо проверить, например, поле пароля на соответствие нескольким критериям.

Например:

— Длина пароля больше 6 символов
— Минимум одна цифра
— Буквы верхнего и нижнего регистра

Зачастую такое требование реализовываются примерно так:

    func isPasswordCorrect(_ value:String) -> Bool {
        // code for check length, number exist, uppercase and lowercase chars
    }

Просто. Функция работает, пароль проверяется. Все довольны.

Дальше если нам надо проверить поле email на корректность, мы также пишем функцию, например:

    func isEmailCorrect(_ value:String) -> Bool {
        // code for check length, number exist, uppercase and lowercase chars
    }

И так далее.

По росту проекта функций с такими проверками становится все больше и больше. При создании нового проекта нам надо или начинать все сначала или копировать эти функции с прошлого проекта. Не очень удобно. Один из вариантов решения под катом.

Тормоз для броненосца USS Indiana BB-1, 1910 год. Эта штуковина должна тормозить корабль водоизмещением 10453 тонны.

Оригинал: iOS App Performance: Instruments & beyond
Автор: Igor M

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

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

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

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

‘Login’ или ‘log in’? Одно слово или два? Это достаточно распространенный вопрос среди тех, кто пишет на английском языке. Давайте разберемся, как же правильно.

От переводчика:
Уже опубликовано много материалов по MVC и его производным паттернам, но каждый понимает их по-своему. На этой почве возникают разногласия и холивары. Даже опытные разработчики спорят о том, в чем отличие между MVP, MVVM и Presentation Model и что должен делать тот или иной компонент в каждом паттерне. Ситуация усугубляется еще и тем, что многие не знают истинную роль контроллера в классическом варианте MVC. Предлагаю вашему вниманию перевод хорошей обзорной статьи, которая многое проясняет и расставляет всё по своим местам.

Elasticsearch — поисковый движок с json rest api, использующий Lucene и написанный на Java. Описание всех преимуществ этого движка доступно на официальном сайте. Далее по тексту будем называть Elasticsearch как ES.

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

В этой статье я расскажу про основы ES на примере индексации постов блога. Покажу как фильтровать, сортировать и искать документы.

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

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

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

В этой статье речь пойдет о новой возможности в iOS 10 — Notification Content Extension. Это разновидность расширения, которая позволяет отображать пользователю собственный интерфейс при взаимодействии с уведомлением (remote или local). И отдельно коснемся того, что можно, а что нельзя делать в этом новом расширении — в том числе насколько оно гибко настраивается и конфигурируется.