История разработки iOS-приложения. В основном про грабли

[Flanker_4]

Помогу немного

В этом случае, Вы сравнивали одинаковость указателей.

 (c.priceCriterion == [NSNumber numberWithInteger:EDEvaluatePriceHundredPoint])

Правильно сравнивать объекты по значению нужно так

[c.priceCriterion isEqual:[NSNumber numberWithInteger:EDEvaluatePriceHundredPoint]]

Еще можно использовать сахар @(EDEvaluatePriceHundredPoint)
и сравнивать сразу методом для NSNumber (если уверены, что оба объекта этого класса)

[c.priceCriterion isEqualToNumber:@(EDEvaluatePriceHundredPoint)]

Что касается этого " Проблема оказалась в представленных в xcode 6 constraint to margin"
Не скажу, нужно смотреть экраны. Может ваш девайс был на iOS7, а айфон 6 на iOS8?

[Konstantint]

Точно. Сравнение указателей, вот я болда. Спасибо. Именно поэтому не работало на 64 битных системах.

По поводу constraint to margin, вот тут мне непонятно зачем их ставить по умолчанию и везде. И проблема проявлялась только на экране iPhone 6 Plus на остальных устройствах только при наличие системной плашки в верху экрана. В остальных случаях и на разных ios все было нормально.

[miksayer]

Есть подозрение, что на 32-битных системах простые константы NSNumber(типа @1, @2 и т.д.) создаются один раз и переиспользуются потом, поэтому сравнение по указателю у вас прокатывало без вопросов. А на 64-битных системах используется оптимизация tagged pointers и константы уже по какой-то причине не переиспользуются. О tagged pointers можно почитать тут.

[jaguard]

Жуткий рунглиш на скриншотах, надеюсь, не пошел в продакшн?

[Konstantint]

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

[i_user]

Хотелось бы вставить свои 5 копеек — очень популярно сейчас говорить «прикрутите статистический модуль в начале разработки».
1. Крэш-аналитика однозначно нужна на первом этапе. В этом плане от себя могу порекомендовать HockeyApp — у них есть отличный клиент, облегчающий работу с крэшами. И в хороших деплоймент-скриптах навроде fast lane есть интеграция с этим сервисом в отличии от Яндекс.Метрик
2. Статистика же использования сама по себе абсолютно бесполезна до понимания двух вещей:
-Статистика до 5-10к пользователей попросту нерепрезентативна
-Покрывать приложение статистикой «авось пригодится» рано или поздно приводит к тому, что выдача статистики становится бесполезной и ненужной — крайне рекомендую перед тем как включать сбор статистики — написать на отдельной страничке — а что вы, собственно, хотите узнать. Набор гипотез, которые вы хотите проверить — и уже для этих гипотез формируете минимальный набор лог-ивентов, которые позволяют разделить все гипотезы.

[Konstantint]

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

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

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

[ZhukV]

Мне казалось это логичным, тем более это работало у меня на телефоне. Хотя тут сравниваются два разных объекта.
А вот на iPhone 5S и новее это уже не работало и появлялись пустые ячейки. Странная история, которую я до сих пор не понимаю. Но решается просто:

Дело в том, что Objective-C — объектный язык, и уже NSNumber, это ни какой не int, не float и другая фигня. В частности, эта скажим некоторая обертка, над цифровым типом данных, с которого Вы можете получить уже любое значение.

В результате, Ваше сравнение получилось что-то вроде (сравнения числа и объекта):

int == NSNumber (id)

На самом деле, я считаю это очень верным подходом в объектном языке. Вы не паритесь, какая архитектура (32, 64), ну если Вы не пишете там «большущие» вычисления, а также получаете большое количество helper-ов, с помощью которых Вы сможете многое сделать, не напрягаясь.

Аналогичным образом работают и NSString и другие обертки над типами.

В частности, я много видел людей, которые используют базовые типы: int, float, unsigned int… Лично я бы советовал использовать типы объявленые в Objective-C — NSInteger, CGFloat, NSUInteger… При таком подходе Вам пофигу будет, что там потом придумает Apple (ну не прям пофигу, но совместимость наверное таки будет).

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

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

К примеру:

+ (BOOL)isRetina;
+ (BOOL)isIos8
+ (BOOL)isIos7
// .....

Вот как один из примеров: github.com/ericjohnson/canabalt-ios/blob/master/flixel-ios/src/Flixel/FlxG.m

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

А почему не использовали GoogleAnalytics для статистики? Как по мне, очень даже хороший вариант, да и еще в связке с AdMob-ом.