Rockerman

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

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

NSUserDefaults, NSKeyChain, iCloud.

Проверяют не 2 недели, а по-сути 1-2 дня. До 2-х недель может длиться время очереди пока не возьмутся за ваше приложение.
При непосредственно проверке смотрят на UI, насколько приложение правильно работает и особое внимание на встроенные покупки или покупки "на стороне". Apple очень не любит когда с помощью приложения разработчик зарабатывает мимо кассы Apple.
Перечень всех требований вы можете найти по ссылке выше.

Правильно пишут, ваше приложение скорее всего не пропустят в App Store. Нельзя использовать in-app для покупки реальных товаров и с другой стороны, нельзя использовать сторонние платёжные сервисы, то есть мимо кассы Apple. То, что существуют приложения типа ebay - это исключение, которого вы скорее всего не добьётесь от apple. По крайней мере, так оно было до сегодняшнего момента. Так что, скорее всего вам нужно отказаться от этой идеи сразу пока не выкинули кучу денег или сил на разработку.

Особо нет разницы для приложения на iOS, android или нечно другое. Используйте restFull API на сервере, для соц сетей нужна реализация этих методов на стороне сервера - передавайте туда полученные из приложения ID пользователей и проверяйте через API соц сетей их валидность.

Храните в каком-нибудь NSKeychain если больше думаете о безопасности и NSUserDefaults если без разницы. Используйте уже асинхронные способы для работы по http - AFNetworking или вариант с блоками.

Каждый год WWDC, где презентуются новые фишки в разработке под iOS. Вполне возможно, что вам далеко не все они и нужны в повседневной работе, но не нужно особо рассчитывать на то, что вы раз написали и это не нужно будет никак менять в дальнейшем и адаптировать под новые требования. UI вполне себе тянется, но бывают огрехи, которые при не особо грамотной разработке можно самому же и допустить. Ну и вопрос - выходит 64bit архитектура и как никак нужно адаптировать приложение. Короче.. Книжки всяческие полезны только для первого старта. Затем официальная документация, гугл, wwdc, stackoverflow, статьи на хабре.. В литературе всё это будет описываться с большим запаздаванием, особенно на русском языке. Года так 2-3, за которые вообще может многое поменяться в SDK и платформе. Интеграция с iWatch, допустим.. И я далеко сомневаюсь, что QT или другие подобные инструменты будут позволят делать всё, что и родной SDK.

Собственно под сам iOS никакие сторонние библиотеки не нужны, просто регистрируйте устройство для получения уведомлений, получайте токен и отправляйте его на свой сервер или иной сервис. А со стороны сервер - смотря на чём пишите?
Под ruby есть гемы, для php тоже должны быть готовые решения. Проблемы начинаются когда нужно чистить "протухшие" токены от устройств иначе APN просто закрывает соединение. Наверное проще всего использовать какие-нибудь агрегаторы типа http://www.pushapps.mobi, pushwoosh и др.

К сожалению, большая часть информации будет на английском, к этом нужно быть готовым. Если в двух словах, то нужно создать запрос на сертификат на Maс где ведётся разработка, загрузить его в портал, создать там сертификат, загрузить его обратно на компьютер. Потом создать id приложения и провизию приложения. Скачать провизию в выставить в настройках Code Sign проекта. Короче, это долгий путь если делать в первый раз.. Лучше найти tutorial и видео чтобы понять всю эту кухню. Но технический английский must have.

Возникла трудность при проверке receipt для mac os x.
Беру я его так:
NSURL *receiptURL = [[NSBundle mainBundle] appStoreReceiptURL];
if([[NSFileManager defaultManager] fileExistsAtPath:[receiptURL path]]){
NSData *receiptData = [NSData dataWithContentsOfURL:receiptURL];
}, но преобразовать к словарю, подобно как для iOS нем могу.
Такое ощущение, что у него совсем другой формат.
Кто-нибудь делал проверку покупки для mac?

Я читал, iCloud может быть выключен. Надо тогда предупреждение как мимимум сделать, чтобы включить iCloud для шаринга подписок. Получается нужно хранить последний UUID (или md5 от receipt) покупки в iCloud, а при запросе с сервера статуса подписки проверять по этому UUID (есть ли он в базе). При этом, нужно локально сохрянять reciept до тех пор, пока не выполнится запрос проверки покупки на сервере. Мало ли, может интернет пропасть, программа зависнуть и потеряется транзакция покупки. Я правильно всё понимаю? Много тонкостей может всплыть

И как насчёт если сделать без регистрации/авторизации, а только через iCloud синхронизацию, завернёт это apple или нет?

Восстановление возможно только если пользователь зарегистрируется или достаточно mac адрес отправить?
Если пользователь сначала купил подписку, а потом захочет привязать покупку к аккаунту, то у него соответственно нет уже шансов?

Рекомендую CoreData + MagicalRecords. Практчиески из коробки будет синхронизация базы через iCloud. Мелочь, а приятно.