Первый опыт разработки iOS-приложения и размышления о маркетинге и рекламе

[usgleb]

Для аналитики есть более подходящие инструменты, например Flurry и mixpanel.

[RedRoseSinging]

Здорово. Благодарю, почитаю про них.
А, если вкратце, чем они лучше Parse.Com? Или просто предоставляют больше возможностей?

[Igor_Sib]

А чем parse плох? Мне например нравится (хоть и это побочная фишка у него), хочу с фларри переехать на него.

[dmrt]

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

[RedRoseSinging]

Да, это было интересно. Кроме того, создавалось ощущение, что на ЛЮБОЙ мой вопрос был ответ где-нибудь в Сети, что радовало.

[4ikist]

Удивительно, где нашли девайс за 2 т.р.?
И дополнительно к нему вопрос: в 4 процессор 32-бит, сейчас не принудительна разработка в том числе и для 64-бит?

[RedRoseSinging]

1. 2 тыс. рублей заплатил я сам. Ещё трое коллег скинулись по 2 т.р. Уже восемь тысяч. А за эти деньги можно было найти iPhone 4.
2. На iPhone 4 было просто дополнительное тестирование. Кроме того, он использовался, когда можно было обойтись без эмулятора. А 64-х битное устройство дополнительно бралось со стороны у хороших людей. Кроме того, судя по письму от Apple, обязательная поддержка 64-х битных процессоров и iOS 8 SDK будет обязательна лишь с 1-го февраля этого года и лишь для НОВЫХ приложений. А с июня она будет обязательна и для обновлений.

[CrazyAngel]

«еще трое коллег»
Это прямо суп из топора. Случайно еще пару коллег не скинулось по паре миллионов?

[Beltoev]

Написали бы в самой статье полную стоимость.
Иначе получается, что «я потратил на разработку 10 рублей, а в сети пишут, что минимум тратится 100 рублей. Кстати, скинулось 10 человек, но я ведь потратил на игру всего 10 рублей, в сети лгут!»

[Beltoev]

Кстати, различие в цене объясняется контентом.
Вы рисовали сами, либо использовали какие-то готовые картинки (авторство не нарушили?), а при расчёте стоимости разработки учитывают стоимость контента. И стоимость может выходить в разы выше самой разработки

[EvilPartisan]

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

[RedRoseSinging]

Начальник у меня самый лучший. И на работе у меня недостатка в оборудовании нет. ^_^
Просто игру я делал исключительно дома, после работы по вечерам (возможно, я в статье не очень понятно написал). Поэтому пришлось выкручиваться виртуальной машиной и старым iPhone 4.

[bezumkin]

Начальник у меня самый лучший.

… и читает Хабр!

[Kirpa]

Принудительно надо будет добавлять slice для 64-битной архитектуры. Это делается в настройках проекта и касается только старых проектов, в новых всё добавлено по умолчанию.

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

[outcoldman]

> учитывались какие-то ещё параметры, т.к. в моём случае явно вышло меньше
Вы, наверное, работаете за бесплатно. ;)

[RedRoseSinging]

И это, судя по всему, правильный ответ! :) Ну вот, одной тайной в мире стало меньше.

[yul]

И папа-художник тоже.

[RedRoseSinging]

И очень много хороших людей на работе, которые помогали с переводом и тестированием. :)

[nochkin]

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

[outcoldman]

Я рад конечно за вас, но причем тут я или мой комментарий? :) В статье был вопрос, а я ответил.

[nochkin]

Показалось удивление в том ответе. Похоже, просто показалось.

[Kirpa]

У вас база в директории для кеша, операционка может стереть её пока ваше приложение не активно.

[RedRoseSinging]

Вот как? Пока такого не было. Не активно = свёрнуто? Или закрыто полностью?

[Kirpa]

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

В вашем случае, лучше использовать NSApplicationSupportDirectory вместо NSCachesDirectory. Более подробно можно посмотреть тут:

developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/AccessingFilesandDirectories.html#//apple_ref/doc/uid/TP40010672-CH3-SW5

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

[RedRoseSinging]

Вот это да… Благодарю за подсказку. Сделаю, как вы сказали, хотя бы ради опыта. А база там и правда смехотворно маленькая :)

[vsns]

к сожалению размер вашей базы не имеет значения. когда место кончается ios действительно чистит все подряд из nscashesdirectory. был печальный опыт(

[cher11]

Из интереса — а ради чего используете SQLite и FMDB, чем не устроили NSUserDefaults?

[RedRoseSinging]

Т-а-а-ак… Причины были такие (и не все умные):
1. Про словосочетание SQLite я узнал сильно раньше, чем про NSUserDefaults. А stackowerflow рассказал про то, как здорово работать с FMDB. По этой причине, наверное, сохранения хранятся именно в базе SQLite.
2. В другой базе я храню заголовки к картинкам, которые показываются пользователю во время игры и заодно заполняют пустое место. Соответственно, если я добавлю новые картинки, то добавляются и новые названия к ним. Во время обновления на устройствах новая база затирает старую и все довольны. Как это по умному сделать с помощью NSUserDefaults не представляю. :)

[cher11]

Да, FMDB очень упрощает работу с SQLite, тут не поспоришь. До его появления использовал сишные функции, вроде и не очень сложно, но время лишнее тратилось.

Насчет детекта обновлений приложения — я в своем проекте использовал что-то подобное:

if ([[NSUserDefaults standardUserDefaults] valueForKey:@"appVersion"]==nil)
{
    [[NSUserDefaults standardUserDefaults] setValue:[NSNumber numberWithInt:1] forKey:@"appVersion"];
    // ...
    // устанавливаем остальные параметры
    // ...
    [[NSUserDefaults standardUserDefaults] synchronize];
}
else
{
    int app_version = [[NSUserDefaults standardUserDefaults] valueForKey:@"appVersion"];
    // далее можно проверить, отличается ли текущая версия от пользовательской app_version и, например, добавить в настройки новые поля
}

Во время обновления на устройствах новая база затирает старую и все довольны

— я правильно понимаю, что речь идет просто о файле в bundle вашего приложения? Если так, и если он обновляется только при обновлении приложения целиком (версии 1.0 => 1.1, например), то в NSUserDefaults вообще нет нужды. Другой разговор если у вас данные можно обновить через интернет — тогда есть смысл держать актуальную версию, и выбор между NSUserDefaults и SQLite зависит от структуры самих данных.

Пример: различные NSArray и NSDictionary отлично пишутся в NSUserDefaults (который для программиста и выглядит как key-value хранилище), ну а SQLite он и есть SQLite — его стезя это SELECT, ORDER BY, WHERE и т.д.

Ну и последнее: присмотритесь к JSON, легкочитаемый формат, без проблем сериализуется в Foundation классы.

[cher11]

Поправлю себя, конечно же должно быть так:

int app_version = [[[NSUserDefaults standardUserDefaults] valueForKey:@"appVersion"] intValue];

[ASkvortsov]

Пример: различные NSArray и NSDictionary отлично пишутся в NSUserDefaults

[зануда mode on]
При условии, что содержащиеся в них объекты поддерживают NSCoding.
[зануда mode off]

[cher11]

Век живи — век учись. За три года умудрился ни разу не попробовать сохранить кастомный объект, только десериализованные JSON'ы да свои массивы и словари. Спасибо!

[Smrdis]

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

[RedRoseSinging]

За правду, вообще-то, награждать надо, так что вы молодец. :)
А по поводу игры — как уже говорилось, это была проба пера. Хотелось изведать процесс от начала и до маркетинга. Будут ещё идеи, программы и уйма нового опыта.

[bubuh]

Люди прекратите делать «пробу пера», да ещё и «раскручивать» и писать статьи о своём «великом» опыте «разработки» под iOS. Хватит уже захламлять АппСтор подобным Г. Что вы хотите сказать этим продуктом пользователям? Я понимаю, если вам интересно изучить новый язык программирования, готовую платформу распространения продуктов, это одно, тогда и распространяйте это среди друзей или просто бесплатно, потому что идея нулевая и ваши затраты минимальны, а ожидания слишком завышены. Получили опыт разработки отлично, надо двигаться дальше, очень много и усердно работать и тогда возможно через год сможете создать что-то разумное в плане реализации. Но главное это всё же это идея, попробуйте создать что-то что действительно будет кому-либо интересно и в первую очередь это должно быть интересно вам лично. Честно ответьте себе, что вам это интересно и вы будете этим пользоваться не раз. Изучите конкурентов, это поможет определиться с уникальностью вашего продукта или функций. Оцените насколько лучше вы сможете реализовать чем конкуренты и сколько им потребуется времени, чтобы скопировать вашу хорошую идею. Подобных вопросов множество и всё это складывается из огромного труда и усилий чтобы сделать действительно интересный проект, затраты на который будут куда больше чем $5000, но не обязательно в денежном эквиваленте.

[askl]

Абсолютно поддерживаю!

[unlying]

и арт, и геймдизайн, и перевод, и qa…

[jarvis]

5000$ цена за качественное приложение, а у вас все таки пока приложение до современных стандартов не дотягивает. Так что наверное имеет смысл его доделать и улучшить, прежде чем заниматься продвижением)

Идея то конечно требует значительной доработки.

Можно например сделать не просто картинки, а например что-нибудь более трендовое, например СЕЛФИ :)

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

В качестве названия взять «собери селфи», может что и получится

Конечно, есть еще вариант сделать что-нибудь попроще и собирать паззл из звезд и известных людей, политиков и тд, но такие скорее всего есть

[RedRoseSinging]

Да, конечно. Можно однозначно попробовать доделать и улучшить. Всё, что угодно, но только без слова на букву С. У меня от него мурашки по коже. Может, себяшки? ;)

[petyamorozov]

> 1. Были отправлены запросы на БЕСПЛАТНЫЙ обзор на сайты:

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

А так — имхо надо сделать более примитивным (мультяшным) интерфейс, сейчас он слишком реалистичен, не дает расслабиться и получить удовольствие. Либо сделать с модным ныне flat ui дизайном.

[RedRoseSinging]

По поводу интерфейса: сделал его таким, потому что нравится. Видимо, нравится только лишь мне ^_^ Так что и правда можно сделать более яркий мультипликационный. А модный ныне плоский дизайн мне не очень по душе, если честно. Это касается только мобильных приложений. Хочется, чтобы блокнот, например, выглядел как блокнот. С кожей, бумагой и текстурой. Но это дело вкуса. :)

[askl]

Я бы посоветовал Realm в качестве базы данных. Эта ORM очень проста для понимания + имеет кучу различных преимуществ перед стандартным CoreData и тем более NSUserDefaults.

[classx]

странно — ни названия игры, ни ссылки на AppStore… может я невнимательно читал?
и еще вопрос — как вы определяете политику ценообразования для встроенных покупок?