kaspartus

Я бы в начальный уровень знания Core Data включил:
- Знание основных элементов Core Data стека
- Знание возможностей фреймвока(писать, например, можно не только в базу)
- Умение писать/читать
- Работа с простейшими свзяками

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

Потом советую прочесть про NSFetchedResultsController, но в начале лучше почитать примеры без них.

А так есть книжка "Pro Core Data for iOS", на хабре даже есть перевод первых 4 глав: habrahabr.ru/post/198242

Ну тут на свой вкус.
- Можно положить UITableView и UICollectionView на одну вьюху и просто менять альфу.(Тут думаю и так все понятно)
- Можно сделать красивый переход(гуглить "custom transition ios 7"), но это может поломать порядок UIViewController, если они лежат в UINavigationController.

Из общих моментов:
- Я бы вынес реализацию всех делегатных методов в отдельный класс, это сильно повысит читаемость класса UIViewController, которому они будут принадлежать.( www.objc.io/issue-1/lighter-view-controllers.html )
- В качестве переключателя я бы использозвал UISegmentedControl, находящийся в верхнем баре, но никто не мешает придумать, что-то свое.

После покупки сертификата действия примерно такие
Для дебага - используется большую часть времени, если хотим дебажить не на симуляторе:
1. Подключаете железку
2. В XCode в Organizer находите ее и жмакаете на кнопку "Use for development"
3. Теперь там где можно выбрать тот или иной симулятор вместо Device появится реальное устройство, выбираем его для деплоя
3.1 Тут XCode может написать про профили/сертификаты и предложит выкачать их - соглашаемся
4. Запускаем

Если необходимо собрать релизную версию, то
1. Опять же выбираем железку
2. Product -> Archive
3. После сборки нас кинет в Organizer, там жмем на Distribute
4. Выбираем что хотим сделать: Ad Hoc - чтобы посмотреть релизную версию перед отправкой в аппстор, AppStore - отправить свое гениальное творение в магазин.

И на iOS и на Android есть достаточно вакансий/проектов. Имеет смысл выбрать то, что интересней.

На тему языков: это все тлен, языки учатся достаточно быстро, если есть некоторый опыт в каком либо другом. Основная проблема - освоиться с SDK.

iOS:
Если выбирать iOS, то я бы советовал сконцентрироваться на O-C, параллельно захватывая Swift. На самом деле общие концепции не поменяются, в целом все останется. Отдельно надо сказать, что джуном на свифте будет не так просто устроиться, если компания не начинает раз в полгода новое приложение, то приложение написано, а написано оно понятно на каком языке.

Android:
Опять же, более принципиально, что необходимо будет учить SDK, но предыдущий опыт в java будет однозначным плюсом.

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

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

Я так понял, что в основном вопрос на тему выбора структуры сущностей. Для этого неплохо было бы увидеть сами запросы. Самое простое - это держать объект Предмет с полями: Название, Преподаватель, Кабинет/Место, Время начала, Продолжительность.

Я бы напрямую биндил в сущности базы(с этой задачей отлично справится MagicalRecord), а далее уже фильтруем.

Касательно фильтрации, как написал @morozovdenis, используется класс NSPredicate.

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

В итоге победил модифицировав вариант, где кнопки лежат на contentView и масштабируются вместе с самой картинкой(1 гифка).

Решение:
Подцепился через делегатный метод -(void)scrollViewDidZoom:(UIScrollView *)scrollView

Там делаю трансформацию:

btn.transform = CGAffineTransformMakeScale(1 / self.scrollView.zoomScale, 1 / self.scrollView.zoomScale);

Думал что будет лагать, проверил на 100 кнопках - все работает идеально на третьей доске.

p.s. обновил репу

Два года назад имел такой опыт.

Виртуалка крутилась на средненьком ноуте на работе и на средненьком стационарнике дома. Эффект был один: прогать можно, но все начинало тормозить рано или поздно. Все сильно упирается в оперативу, так что жалеть ее на виртуалку не стоит, но при этом даже 2Гб она съедает без проблем, после чего лучше начать вырубать приложения, а лучше просто перезапустить виртуалку.

Скажу так: если это вам для работы, то смело просите мак. Mac mini стоит 20-40к, для компании это копейки, а для вас +100500 к производительности и столько же в минус к геморою и потере нервов. Если работодатель экономит на спичках, то его лучше поскорее сменить, никаких радужных перспектив от него ждать не стоит.

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

Так надо соглашение читать, но вполне очевидным было бы, если приложение принадлежало вам.

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

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

Если идеи стоящие и вы верите в успех, то возьмите кредит, или найдите спонсора.

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

1. Ну самый простой но трудоемкий вариант держать два сториборда. Для ipad ~ipad после имени, но перед расширением.
2. Можно попробовать держать один сториборд, там указать xibName.xib в сториборде, а на деле держать два варианта, для ipad опять же xibName~ipad.xib, по идее для доски он должен подцепить правильный xib, но я не пробовал.

Лично я себе вижу как плюсы, так и минусы.
Плюсы:
1. Кроссплатформа
2. Быстрое обновление, без необходимости проходить яблочную проверку каждый раз
3. Экономия на мобильном(ых) разработчиках(для самого простого случая)

Минусы:
1. Более медленное переключение между логическими экранами(отправляем запрос на сервер, получаем ответ, рендерим). Пользователи на мобильных привыкли к моментальному отклику приложений. Это очень важный пункт, история с приложением fb, на мой взгляд, показательна.
2. Потенциальные проблемы в связывании этого приложения с встроенными в iOS функциями, например с пуш-уведомлениями, геолокацией, фото-альбомом и прочим
3. Страдает взаимодейстиве с UI. Например мобильные браузеры намеренно тормозят реакцию на нажатие по кнопкам и ссылкам(можно решить). Перетаскивание элементов, смахивание ячеек таблицы достаточно сложно реализовать
4. Проблемы с реализацией оффлайн режима. В нативном приложении можно было бы поменять настройки профиля, посмотреть историю

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