О программировании на Swift

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

В чем разница?

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

// Пример для типа Значение (value type) struct S { var data: Int = -1 } var a = S() // Присваиваем переменной a значения структуры S var b = a //значение переменной a копируется в переменную b a.data = 42 //переопределяем значение переменной a, переменная b остается не изменной print("\(a.data), \(b.data)") // выводим в консоль значения "42, -1"

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

// Пример ссылочного типа (Reference type) class C { var data: Int = -1 } var x = C() // создаем экземпляр класса C var y = x //присвоим переменной y значение переменной x x.data = 42 // изменим значение переменной x (y так же изменится) print("\(x.data), \(y.data)") // "42, 42" действительно оба значения изменились

  Роль мутаций в безопасности

Одной из причин по которой выбирается  Value type вместо Reference type можно считать более легкое использование кода. Если вы всегда получаете уникальную копию экземпляра, то знаете, что никакая другая часть вашего приложения не изменит этого значения без вашего участия. Это особенно полезно в многопоточных средах, где разные связи могут изменять свои данные в ходе работы. Используя Value type можно избежать много неприятных ошибок, которые крайне сложно отладить. Разница определяется в терминах того, что происходит, когда вы собираетесь изменить данные, есть один случай, когда значения и ссылочные типы пересекаются: когда экземпляры не имеют записываемых данных. В отсутствие мутации, значения и ссылки действуют одинаково. Полезно, знать что класс может быть полностью неизменным. В этом случае легче использовать объекты NSObject, сохраняя преимущества семантики значений. Сегодня вы можете написать неизменный класс в Swift с помощью только неизменяемых сохраненных свойств и избежать использования каких-либо API. В самом деле, многие классы общей библиотеки Cacoa, такие как NSURL, разработаны как неизменяемые классы. Тем не менее, Swift в настоящее время не обеспечивает никакого механизма для обеспечения неизменности класса (например, подклассы) в том виде в котором эта неизменность применяется для структур и перечислениий.

Так что и как выбрать?

Итак, если вы хотите спроектировать новый тип, как решить какой тип он должен иметь? Когда вы работаете с Cocoa многие API потребуют использование классов для NSObject. Для остальных случаев можно использовать небольшой гайдлайн: Используйте value type в случаях:  

Сравнимых экземпляров данных

Создания независимый копий

Использования многопоточных данных

Используйте reference type (классы) в случаях:

Сравнения идентичности экземпляров

Создания общих, изменяющихся данных

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

В чем разница?

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

// Пример для типа Значение (value type) struct S { var data: Int = -1 } var a = S() // Присваиваем переменной a значения структуры S var b = a //значение переменной a копируется в переменную b a.data = 42 //переопределяем значение переменной a, переменная b остается не изменной print("\(a.data), \(b.data)") // выводим в консоль значения "42, -1"

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

// Пример ссылочного типа (Reference type) class C { var data: Int = -1 } var x = C() // создаем экземпляр класса C var y = x //присвоим переменной y значение переменной x x.data = 42 // изменим значение переменной x (y так же изменится) print("\(x.data), \(y.data)") // "42, 42" действительно оба значения изменились

  Роль мутаций в безопасности

Одной из причин по которой выбирается  Value type вместо Reference type можно считать более легкое использование кода. Если вы всегда получаете уникальную копию экземпляра, то знаете, что никакая другая часть вашего приложения не изменит этого значения без вашего участия. Это особенно полезно в многопоточных средах, где разные связи могут изменять свои данные в ходе работы. Используя Value type можно избежать много неприятных ошибок, которые крайне сложно отладить. Разница определяется в терминах того, что происходит, когда вы собираетесь изменить данные, есть один случай, когда значения и ссылочные типы пересекаются: когда экземпляры не имеют записываемых данных. В отсутствие мутации, значения и ссылки действуют одинаково. Полезно, знать что класс может быть полностью неизменным. В этом случае легче использовать объекты NSObject, сохраняя преимущества семантики значений. Сегодня вы можете написать неизменный класс в Swift с помощью только неизменяемых сохраненных свойств и избежать использования каких-либо API. В самом деле, многие классы общей библиотеки Cacoa, такие как NSURL, разработаны как неизменяемые классы. Тем не менее, Swift в настоящее время не обеспечивает никакого механизма для обеспечения неизменности класса (например, подклассы) в том виде в котором эта неизменность применяется для структур и перечислениий.

Так что и как выбрать?

Итак, если вы хотите спроектировать новый тип, как решить какой тип он должен иметь? Когда вы работаете с Cocoa многие API потребуют использование классов для NSObject. Для остальных случаев можно использовать небольшой гайдлайн: Используйте value type в случаях:  

Сравнимых экземпляров данных

Создания независимый копий

Использования многопоточных данных

Используйте reference type (классы) в случаях:

Сравнения идентичности экземпляров

Создания общих, изменяющихся данных

Уже многие успели обновиться до Xcode 7.1 и идущим вместе с ним Swift 2.1. Помимо новинок как это часто бывает, подстерегают и неприятные сюрпризы. И если вдруг перестал работать Realm на версии Xcode7.1 Swift2.1? Есть решение!

Переустановка Realm под  Xcode 7.1

Клонируйте репозиторий или скачайте Zip файл по ссылке: https://github.com/realm/realm-cocoa

Откройте новое окно терминала.

Перейдите в директорию репозитория cd ~/Path/To/The/Repo .

Выполните команду: REALM_SWIFT_VERSION=2.1 sh build.sh build which will cause the project to be updated to Swift 2.1

Затем снова добавьте файлы фреймворков в свой проект. Проследите, что галочка  Copy items if needed проставлена. Жмите Finish.

Уже многие успели обновиться до Xcode 7.1 и идущим вместе с ним Swift 2.1. Помимо новинок как это часто бывает, подстерегают и неприятные сюрпризы. И если вдруг перестал работать Realm на версии Xcode7.1 Swift2.1? Есть решение!

Переустановка Realm под  Xcode 7.1

Клонируйте репозиторий или скачайте Zip файл по ссылке: https://github.com/realm/realm-cocoa

Откройте новое окно терминала.

Перейдите в директорию репозитория cd ~/Path/To/The/Repo .

Выполните команду: REALM_SWIFT_VERSION=2.1 sh build.sh build which will cause the project to be updated to Swift 2.1

Затем снова добавьте файлы фреймворков в свой проект. Проследите, что галочка  Copy items if needed проставлена. Жмите Finish.

Эта статья является переводом статьи 5 Myths About App Store Optimization из блога Kissmetrics. Рынок приложений это большой бизнес. Очень большой. Продажи приложений оцениваются в 25 млрд долларов по сообщению от WSJ. Но эта цифра не включает доходы от других смежных отраслей, которые являются частью экономики приложений. По оценкам VisionMobile, глобальная экономика приложений достигнет $ 143 млрд в 2016, с темпами роста на уровне 30%. Приложения все еще являются одной из горячей областей экономики прямо сейчас. И да, экономика приложений все еще растет. Создание и продажа приложений находится на подъеме.

Graph from Moz.

  Уже сейчас приобретаются и устанавливаются приложения на 1 миллиард смартфонов во всем мире. Вот почему app store optimization (ASO) сейчас важная тема для маркетологов и специалистов по оптимизации поиска. К сожалению в такой новой области не обойтись без мифов. Имея дело со столь серьезным предметом,  мы не можем позволить себе недооценивать возможности ASO. В этой статье я собираюсь развенчать часть мифов и дать достоверную информацию, которая поможет вам доминировать в игре ASO.

Насколько важна App Store Optimization?

Для начала, давайте договоримся о стартовой точке: ASO действительно очень, очень важна! Почему? Не только  потому, что это большой бизнес, большей частью потому, каким образом пользователи находят эти приложения. Издание Apptentive сообщает, что 63% (данные по платформе iOS) приложений находятся клиентами по поиску и просмотру App Store. По Android эта цифра равна 58%.

Существует несколько различных путей поиска покупателем новых приложений — медиа, сайты, друзья и т.д. Но приложения все еще продолжают искать через поиск. Исследования Nielsen коррелируют с данными Apptentive:

Graph from Parisoma.

По словам руководителя поиска Google Play,  Джейн Ангина , 12% от числа всех ежедневно-активных пользователей ищут приложения каждый день. И целых 50% этих DAU (daily active users) ищут приложения хотя бы раз в неделю. В течение месяца Google Play обрабатывает шесть миллиардов уникальных поисковых фраз. Мы должны лучше понимать ASO и лучше всего этому поможет избавление от следующих мифов: Приступим.

 5 мифов об ASO (App Store Optimization )

МИФ #1: Изменяйте свое название, адаптируя к высокочастотным запросам.

Реальность: Выберите название и придерживайтесь его

Нет никакого подтверждающего аргумента, что Заголовок-это наиболее важный элемент при  appstore-оптимизации. Но Джейн, глава Google Play поиска, говорит:

Заголовок-это "наиболее важный" кусок метаданных.

В ответ, некоторые ASO оптимизаторы, чтобы лучше адаптироваться к высокочастотным запросам меняют название. Они создают разные варианты названия чуть ли не ежедневно, путем изменения ключевых слов, добавления новых ключевых слов и переименования своего продукта. Однако, такие поступки вряд ли помогают рейтингу приложения. На самом деле, это может навредить ему. Роби Гангули в одной из статей по этой теме высказался:

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

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

1. Сделайте название приложения коротким — 25 символов.

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

2. Сделайте название креативным.

Почему название приложения должно быть более креативным? Джейн объясняет это поведенческими паттернами поиска - категорийный либо навигационный. Пользователь, который слышал или видел ваше приложение будет использовать навигационный паттерн поиска чтобы найти приложение. Если название является креативным, то с большей вероятностью оно будет более запоминающимся и это позволит пользователю быстрее и успешнее его найти. Навигационные запросы это что-то типа "angry birds" или "Evernote", а не категорийные типа как "birds game" или "notes app".

3. Сделайте название приложения уникальным.

Уникальность схожа с креативностью, но с некоторой изюминкой. Творческий подход, это то что будет выделять название приложения для пользователя. Если только вы не хотите чтобы ваше приложение утонуло в болоте таких как Flappy Flappy Pig, Wings, Monster, Hero и множества других клонов оригинального Flappy Bird. Клоны редко успешнее оригинала. При этом посмотрите сами, навигационный запрос по "Flappy" покажет целых 2193 похожих результата. И где-то в этой толпе ваше с не уникальным названием.  

4. Используйте ключевые слова, но не переусердствуйте.

Keyword stuffing (метод многократного повторения ключевых слов) так же плох в ASO  как и в обычном SEO. Apple сообщает, что

 "Повторяющиеся /или не имеющие отношения к названию, описанию ключевые слова могут привести к нежелательным последствиям вплоть до приостановки отображения приложения."

  Помните, что у вас всего 25 символов для названия. Короткое название и короткое ключевое слово все что вам нужно.  

Миф #2: Ключевые слова не так уж важны.

Реальность: Ключевые слова важны.

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

Название приложений содержащих ключевые слова имели более высокие позиции (более чем на 10%) чем те приложения, которые не содержали ключевых слов. Да, 10% не так уж много. Но если добавить ключевое слово в название довольно легко, то почему бы не использовать эту возможность? Давайте вернемся немного назад. Помните я приводил данные по количеству пользователей ищущих приложения?

Graph from Apptamin.

App Store и Google Play имеют алгорится поиска и эти алгоритмы используют вполне традиционные методы поиска - ключевые слова. Не принебрегайте ключевыми словами!

Миф #3: Это все о рейтингах.

Реальность: Рейтинги важны, но на этом не останавливаемся.

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

Правда, рейтинг приложения важен, но он не являются столь значительным, как думает большинство про ранжирование приложение в магазине. Чтобы раскрыть правду о влиянии рейтинга, InsideMobileApps провели исследование. Они сначала исследовали случайную выборку основанную на неконкурентных условиях поиска (1-25 результатов),  среднеконкурентного поиска (26-100 результатов), и конкурентных условиях поиска (100+ результатов), чтобы увидеть, как каждое приложение ранжировано в зависимости от рейтинга. Вот то, к чему они пришли для IOS при сравнении позиции / рейтинг:

Graph from insidemobileapps.com

Рейтинги этих приложений сваливается в пике после восьмой позиции. Также интересно то, что рейтинг, кажется, не имеет огромного влияния на первые восемь позиций. До восьмой позиции имеются колебания как вверх так и вниз. В «неконкурентном» списке поиска исследователи обнаружили, что 10-ое место занимает приложение с таким низким рейтингом  как 1,09, что, откровенно говоря, вообще "нецензурное слово". Ниже пример того, как Google Play ранжирует приложения. В отличие от IOS, там меньше шансов упасть к концу списка. Исследователи подозревают, что "алгоритм поиска Google Play, кажется, имеет более меритократическую модель к показу приложений, позволяя более качественным приложениям подняться на вершину."

Graph from insidemobileapps.com

Существуют и другие примеры готовые помочь разрушить миф  "рейтинг-это все". Смотрите сами, некоторые из высоко-конкурентных приложений в чартах не подкреплены высоким рейтингом. Посмотрите на некоторые рейтинги в топ чартах по iOS. Да, никто не хочет рейтинг от одного до двух звезд, но это то, что происходит, часто даже в TopChart.

Graph from insidemobileapps.com

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

Миф #4: Пока приложение в магазине, люди будут находить его.

Реальность: Потребуется много загрузок, чтобы получить признание.

  Есть некоторые специалисты по ASO которые считают, что приложению достаточно быть в Google Play или App Store чтобы его можно было найти и продать. Позвольте привести некоторые данные. По состоянию на июнь 2014 года в Itunes App Store 1,2 миллиона приложений. По состоянию на июнь 2014 года в магазине Google Play так же более 1 миллиона приложений. Независимо от вашей ниши, это уже очень много приложений. Для того, чтобы успешно конкурировать, необходимо больше, чем просто дифференциации нескольких умных ключевых слов в заголовке и описании. Мы должны разграничить миф со здоровой дозой алгоритмической реальности. Вам нужна популярность. Я показал вам в третьем пункте, что рейтинги имеют менее сильное влияние, чем мы могли бы подумать. Но влияние загрузок, наоборот, недооценивается. Это непростое дело, ведь для того, чтобы получить больше скачиваний, вам нужна дополнительная популярность. Дадим слово фактам: По графику видно, что у приложений с большим числом загрузок позиция выше. Скорость загрузок зависит от того, как работает маркетинг. Как сообщает SEW, высокий рейтинг приложений имеет дифференцированные скорости, в зависимости от их путь к популярности:

Image from Search Engine Watch.

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

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

Миф #5: Описание не очень важно.

Реальность: Описание очень важно.

  Я слышал о неудачных попытках ASO, которым впрочем не удивлен, потому что они забивали на описание. Вот один отчет, который утверждает, обучать вас, чтобы стать ниндзя ASO: Описание приложения не продвигает. Они заявляют: С точки зрения чистой ASO, описание для приложения не имеет влияния на позицию в поиске в App Store. С другой стороны, алгоритм Google Play учитывает контекст в вашем описании приложения для ранжирования. С позиции своего опыта и исследований, описание важно как для Play Google так и App Store. Даже если бы оно имело нулевое влияние на алгоритм ранжирования, качество описания и включение ключевых слов является толчком, чтобы заставить пользователей скачать приложение. Эта статистика загрузок, в свою очередь, имеют мощное алгоритмическое влияние на рейтинги. Search Engine Watch сообщает, что "Описание приложения" второй по значимости фактор для магазина приложений, следующий сразу за названием приложения. Среди их советов, по улучшению позиций в App Store номер один это "фокус на органическое включение ключевых слов в название и описание." AppTweak, точно так же, объясняет принцип включения ключевых слов в описаниях: Ключевые слова имеют огромное значение в ASO (App Store Optimization). В самом деле, можно ли найти ваше приложение по названию и/или ключевым словам для IOS и по названию и/или описании приложения в Google Play, ключевые слова имеют сильное влияние в алгоритме App Store. Таким образом, они должны быть выбраны с умом для того, чтобы дать вашему приложению максимальную видимость и шансы на нахождение.

Заключение

Эта статья является переводом статьи 5 Myths About App Store Optimization из блога Kissmetrics. Рынок приложений это большой бизнес. Очень большой. Продажи приложений оцениваются в 25 млрд долларов по сообщению от WSJ. Но эта цифра не включает доходы от других смежных отраслей, которые являются частью экономики приложений. По оценкам VisionMobile, глобальная экономика приложений достигнет $ 143 млрд в 2016, с темпами роста на уровне 30%. Приложения все еще являются одной из горячей областей экономики прямо сейчас. И да, экономика приложений все еще растет. Создание и продажа приложений находится на подъеме.

Graph from Moz.

  Уже сейчас приобретаются и устанавливаются приложения на 1 миллиард смартфонов во всем мире. Вот почему app store optimization (ASO) сейчас важная тема для маркетологов и специалистов по оптимизации поиска. К сожалению в такой новой области не обойтись без мифов. Имея дело со столь серьезным предметом,  мы не можем позволить себе недооценивать возможности ASO. В этой статье я собираюсь развенчать часть мифов и дать достоверную информацию, которая поможет вам доминировать в игре ASO.

Насколько важна App Store Optimization?

Для начала, давайте договоримся о стартовой точке: ASO действительно очень, очень важна! Почему? Не только  потому, что это большой бизнес, большей частью потому, каким образом пользователи находят эти приложения. Издание Apptentive сообщает, что 63% (данные по платформе iOS) приложений находятся клиентами по поиску и просмотру App Store. По Android эта цифра равна 58%.

Существует несколько различных путей поиска покупателем новых приложений — медиа, сайты, друзья и т.д. Но приложения все еще продолжают искать через поиск. Исследования Nielsen коррелируют с данными Apptentive:

Graph from Parisoma.

По словам руководителя поиска Google Play,  Джейн Ангина , 12% от числа всех ежедневно-активных пользователей ищут приложения каждый день. И целых 50% этих DAU (daily active users) ищут приложения хотя бы раз в неделю. В течение месяца Google Play обрабатывает шесть миллиардов уникальных поисковых фраз. Мы должны лучше понимать ASO и лучше всего этому поможет избавление от следующих мифов: Приступим.

 5 мифов об ASO (App Store Optimization )

МИФ #1: Изменяйте свое название, адаптируя к высокочастотным запросам.

Реальность: Выберите название и придерживайтесь его

Нет никакого подтверждающего аргумента, что Заголовок-это наиболее важный элемент при  appstore-оптимизации. Но Джейн, глава Google Play поиска, говорит:

Заголовок-это "наиболее важный" кусок метаданных.

В ответ, некоторые ASO оптимизаторы, чтобы лучше адаптироваться к высокочастотным запросам меняют название. Они создают разные варианты названия чуть ли не ежедневно, путем изменения ключевых слов, добавления новых ключевых слов и переименования своего продукта. Однако, такие поступки вряд ли помогают рейтингу приложения. На самом деле, это может навредить ему. Роби Гангули в одной из статей по этой теме высказался:

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

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

1. Сделайте название приложения коротким — 25 символов.

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

2. Сделайте название креативным.

Почему название приложения должно быть более креативным? Джейн объясняет это поведенческими паттернами поиска - категорийный либо навигационный. Пользователь, который слышал или видел ваше приложение будет использовать навигационный паттерн поиска чтобы найти приложение. Если название является креативным, то с большей вероятностью оно будет более запоминающимся и это позволит пользователю быстрее и успешнее его найти. Навигационные запросы это что-то типа "angry birds" или "Evernote", а не категорийные типа как "birds game" или "notes app".

3. Сделайте название приложения уникальным.

Уникальность схожа с креативностью, но с некоторой изюминкой. Творческий подход, это то что будет выделять название приложения для пользователя. Если только вы не хотите чтобы ваше приложение утонуло в болоте таких как Flappy Flappy Pig, Wings, Monster, Hero и множества других клонов оригинального Flappy Bird. Клоны редко успешнее оригинала. При этом посмотрите сами, навигационный запрос по "Flappy" покажет целых 2193 похожих результата. И где-то в этой толпе ваше с не уникальным названием.  

4. Используйте ключевые слова, но не переусердствуйте.

Keyword stuffing (метод многократного повторения ключевых слов) так же плох в ASO  как и в обычном SEO. Apple сообщает, что

 "Повторяющиеся /или не имеющие отношения к названию, описанию ключевые слова могут привести к нежелательным последствиям вплоть до приостановки отображения приложения."

  Помните, что у вас всего 25 символов для названия. Короткое название и короткое ключевое слово все что вам нужно.  

Миф #2: Ключевые слова не так уж важны.

Реальность: Ключевые слова важны.

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

Название приложений содержащих ключевые слова имели более высокие позиции (более чем на 10%) чем те приложения, которые не содержали ключевых слов. Да, 10% не так уж много. Но если добавить ключевое слово в название довольно легко, то почему бы не использовать эту возможность? Давайте вернемся немного назад. Помните я приводил данные по количеству пользователей ищущих приложения?

Graph from Apptamin.

App Store и Google Play имеют алгорится поиска и эти алгоритмы используют вполне традиционные методы поиска - ключевые слова. Не принебрегайте ключевыми словами!

Миф #3: Это все о рейтингах.

Реальность: Рейтинги важны, но на этом не останавливаемся.

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

Правда, рейтинг приложения важен, но он не являются столь значительным, как думает большинство про ранжирование приложение в магазине. Чтобы раскрыть правду о влиянии рейтинга, InsideMobileApps провели исследование. Они сначала исследовали случайную выборку основанную на неконкурентных условиях поиска (1-25 результатов),  среднеконкурентного поиска (26-100 результатов), и конкурентных условиях поиска (100+ результатов), чтобы увидеть, как каждое приложение ранжировано в зависимости от рейтинга. Вот то, к чему они пришли для IOS при сравнении позиции / рейтинг:

Graph from insidemobileapps.com

Рейтинги этих приложений сваливается в пике после восьмой позиции. Также интересно то, что рейтинг, кажется, не имеет огромного влияния на первые восемь позиций. До восьмой позиции имеются колебания как вверх так и вниз. В «неконкурентном» списке поиска исследователи обнаружили, что 10-ое место занимает приложение с таким низким рейтингом  как 1,09, что, откровенно говоря, вообще "нецензурное слово". Ниже пример того, как Google Play ранжирует приложения. В отличие от IOS, там меньше шансов упасть к концу списка. Исследователи подозревают, что "алгоритм поиска Google Play, кажется, имеет более меритократическую модель к показу приложений, позволяя более качественным приложениям подняться на вершину."

Graph from insidemobileapps.com

Существуют и другие примеры готовые помочь разрушить миф  "рейтинг-это все". Смотрите сами, некоторые из высоко-конкурентных приложений в чартах не подкреплены высоким рейтингом. Посмотрите на некоторые рейтинги в топ чартах по iOS. Да, никто не хочет рейтинг от одного до двух звезд, но это то, что происходит, часто даже в TopChart.

Graph from insidemobileapps.com

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

Миф #4: Пока приложение в магазине, люди будут находить его.

Реальность: Потребуется много загрузок, чтобы получить признание.

  Есть некоторые специалисты по ASO которые считают, что приложению достаточно быть в Google Play или App Store чтобы его можно было найти и продать. Позвольте привести некоторые данные. По состоянию на июнь 2014 года в Itunes App Store 1,2 миллиона приложений. По состоянию на июнь 2014 года в магазине Google Play так же более 1 миллиона приложений. Независимо от вашей ниши, это уже очень много приложений. Для того, чтобы успешно конкурировать, необходимо больше, чем просто дифференциации нескольких умных ключевых слов в заголовке и описании. Мы должны разграничить миф со здоровой дозой алгоритмической реальности. Вам нужна популярность. Я показал вам в третьем пункте, что рейтинги имеют менее сильное влияние, чем мы могли бы подумать. Но влияние загрузок, наоборот, недооценивается. Это непростое дело, ведь для того, чтобы получить больше скачиваний, вам нужна дополнительная популярность. Дадим слово фактам: По графику видно, что у приложений с большим числом загрузок позиция выше. Скорость загрузок зависит от того, как работает маркетинг. Как сообщает SEW, высокий рейтинг приложений имеет дифференцированные скорости, в зависимости от их путь к популярности:

Image from Search Engine Watch.

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

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

Миф #5: Описание не очень важно.

Реальность: Описание очень важно.

  Я слышал о неудачных попытках ASO, которым впрочем не удивлен, потому что они забивали на описание. Вот один отчет, который утверждает, обучать вас, чтобы стать ниндзя ASO: Описание приложения не продвигает. Они заявляют: С точки зрения чистой ASO, описание для приложения не имеет влияния на позицию в поиске в App Store. С другой стороны, алгоритм Google Play учитывает контекст в вашем описании приложения для ранжирования. С позиции своего опыта и исследований, описание важно как для Play Google так и App Store. Даже если бы оно имело нулевое влияние на алгоритм ранжирования, качество описания и включение ключевых слов является толчком, чтобы заставить пользователей скачать приложение. Эта статистика загрузок, в свою очередь, имеют мощное алгоритмическое влияние на рейтинги. Search Engine Watch сообщает, что "Описание приложения" второй по значимости фактор для магазина приложений, следующий сразу за названием приложения. Среди их советов, по улучшению позиций в App Store номер один это "фокус на органическое включение ключевых слов в название и описание." AppTweak, точно так же, объясняет принцип включения ключевых слов в описаниях: Ключевые слова имеют огромное значение в ASO (App Store Optimization). В самом деле, можно ли найти ваше приложение по названию и/или ключевым словам для IOS и по названию и/или описании приложения в Google Play, ключевые слова имеют сильное влияние в алгоритме App Store. Таким образом, они должны быть выбраны с умом для того, чтобы дать вашему приложению максимальную видимость и шансы на нахождение.

Заключение

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

Анимирование кнопки в индикатор загрузки и анимацию перехода на Swift

Установка через cocoaPod

pod 'TKSubmitTransition'

Подробности по ссылке https://github.com/entotsu/TKSubmitTransition    

Shake анимирование UI элементов на Swift

Установка через CococaPod

pod "SingleLineShakeAnimation"

    Подробности по ссылке https://github.com/haaakon/SingleLineShakeAnimation [caption id="" align="aligncenter" width="372"] shake swift animation[/caption]    

Анимация фигур в Swift 2

  Репозиторий с фремворком на Github. Фреймворк для векторной анимации для Swift основанный на SwiftGraphics для iOS 9 и OSX. С этим фремворком можно создавать свои вариации анимаций с использованием вполне понятного синтаксиса. [caption id="attachment_229" align="aligncenter" width="300"] ellipse_slider swift animation[/caption] [caption id="attachment_230" align="aligncenter" width="256"] moveonpath swift animation[/caption]                

RAMPaperSwitch  - Swift модуль, который позволяет залить родительский view элемент при включении.

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

Анимирование кнопки в индикатор загрузки и анимацию перехода на Swift

Установка через cocoaPod

pod 'TKSubmitTransition'

Подробности по ссылке https://github.com/entotsu/TKSubmitTransition    

Shake анимирование UI элементов на Swift

Установка через CococaPod

pod "SingleLineShakeAnimation"

    Подробности по ссылке https://github.com/haaakon/SingleLineShakeAnimation [caption id="" align="aligncenter" width="372"] shake swift animation[/caption]    

Анимация фигур в Swift 2

  Репозиторий с фремворком на Github. Фреймворк для векторной анимации для Swift основанный на SwiftGraphics для iOS 9 и OSX. С этим фремворком можно создавать свои вариации анимаций с использованием вполне понятного синтаксиса. [caption id="attachment_229" align="aligncenter" width="300"] ellipse_slider swift animation[/caption] [caption id="attachment_230" align="aligncenter" width="256"] moveonpath swift animation[/caption]                

RAMPaperSwitch  - Swift модуль, который позволяет залить родительский view элемент при включении.

В Swift 2 для Xcode 7 ввели новое ключевое слово  @testable, которое позволяет получить доступ к внутррениим API фремворков используя следующую строчку кода:

@testable import MyFramework

В Swift 2 для Xcode 7 ввели новое ключевое слово  @testable, которое позволяет получить доступ к внутррениим API фремворков используя следующую строчку кода:

@testable import MyFramework

Часто приходится сталкиваться с задачами при редактировании UITextField задавать тот или иной отступ. Увы, инженеры занимающиеся Xcode не продумали для нас такой возможности по умолчанию. И вот именно поэтому приходится идти на некоторые ухищрения, такие как начинать строку не с первого символа, либо вписывать UITextField в UIView не полностью, а частично, задавая отступ самим объектом. Но эти способы не единственные, поэтому предложу один вариант, который мне нравится.

Как сделать расширение для StoryBoard в Swift

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

import UIKit @IBDesignable class FormTextField: UITextField { @IBInspectable var inset: CGFloat = 0 override func textRectForBounds(bounds: CGRect) -> CGRect { return CGRectInset(bounds, inset, inset) } override func editingRectForBounds(bounds: CGRect) -> CGRect { return textRectForBounds(bounds) } }

Часто приходится сталкиваться с задачами при редактировании UITextField задавать тот или иной отступ. Увы, инженеры занимающиеся Xcode не продумали для нас такой возможности по умолчанию. И вот именно поэтому приходится идти на некоторые ухищрения, такие как начинать строку не с первого символа, либо вписывать UITextField в UIView не полностью, а частично, задавая отступ самим объектом. Но эти способы не единственные, поэтому предложу один вариант, который мне нравится.

Как сделать расширение для StoryBoard в Swift

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

import UIKit @IBDesignable class FormTextField: UITextField { @IBInspectable var inset: CGFloat = 0 override func textRectForBounds(bounds: CGRect) -> CGRect { return CGRectInset(bounds, inset, inset) } override func editingRectForBounds(bounds: CGRect) -> CGRect { return textRectForBounds(bounds) } }

Ранее я писал про работу с CocoaPods - инструментом позволяющим довольно легко устанавливать новые библиотеки. Не так давно у CocoaPods появился конкурент, причем уже вполне себе рабочий. Он обеспечивает установку новых библиотек и фреймворков еще проще и имя ему Карфаген)) Представляю Carthage. Давайте разберемся как он работает и как при его помощи устанавливать в проект новые фреймворки. Для начала необходимо его установить. Для этого достаточно поставить файл с расширением .pgk взятый по этой ссылке в официальном репозитории Carthage.

Скачали и установили Carthage.

2. Установим его в свой проект, для этого необходимо создать .cartfile Выполним в терминале

cd ~/Path/To/Starter/Project

Создадим пустой Cartfile при помощи команды touch

touch Cartfile

И откроем созданный файл в Xcode для редактирования

open -a Xcode Cartfile

3.  Добавим понравившуюся библиотеку в свой проект, для этого внесем в открытый Cartfile например что-то вроде этого:

github "raulriera/TextFieldEffects"

Эта библиотека добавит в проект возможность использования красивых эффектов в текстовых полях. Так же нужно выбрать для какого Xcode ставить

sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer

И выполните команду

carthage update