gleb_kudr

Xamarin + мобайл.

Попробуйте воспользоваться вот этим https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/9_UsingApplicationLoader/UsingApplicationLoader.html

В Xamarin есть очень крутой кроссплатформенный компонент как раз для создания мобильных формочек - monotouch.dialog
Так что выбирайте его, не ошибетесь.

C# имеет неплохую поддержку ФП. Освоите лямбды, потом будет проще перейти на функциональные языки, если потребуется. Да и вообще, это в тренде. Вдобавок на C# можно писать под все актуальные платформы (Xamarin + Mono).
В общем мой голос за шарп :) Он быстрее развивается, а молодому разработчику лучше учиться на языках с богатым синтаксисом и возможностями. И сахар там вкусный :) С деревянными игрушками еще успеете наиграться.

Проблема связана с изменением положения контента относительно экрана в ios7. Раньше контент был под навигейшеном и над таббаром, а нижний и верхний оффсеты =0 (величина, на сколько верхнее и нижнее значение скролла отступает от границы контрола). В ios7 контент совпадает с размерами экрана, а оффсеты не равны нулю и определяются по хитрому и кривому механизму, который худо-бедно работает на нативных контролах, а с кастомными приходится их выставлять руками. В общем, гуглите «ios7 uitableview offset».

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

Аналогично можно не чарджить за быстрые ответы по почте на адекватные и простые вопросы. Т.е. уклон в сторону простого правила + скидки как вашей доброй воли.

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

Если вы не госорган и не большая бюрократическая структура, то главное — пишите нормальным человеческим языком. Все бюрократизмы выжигать каленым железом. Не должно быть словосочетаний типа «наша система должна осущствлять функции по взаимодействию...».
Вы создаете продуктовое описание для того, чтобы объяснить концепцию другому человеку. Объяснять нужно человеческим языком.
Очень многие (90%) недооценивают важности этого и пишут продуктовые документы так, как будто это расшифровки съезда КПСС.

Плюс, есть такое понятие, как дизайн-уровни. Не копайтесь в подробностях на высоком уровне описания. Выносите все это в отдельные документы, иначе получите кашу.
Соответственно, в ТЗ войдет все, что вы считаете нужным пояснить по продукту. Схемы, сценарии, расчеты и т.д. Но это обязательно структурируется по уровням. На одном уровне можно смешивать разное содержимое (сценарий + формальное описание, например), но ни в коем случае нельзя смешивать разные уровни.

Если я правильно понял вопрос, то вы спрашиваете, как вам это организовать на фронтенде.
Вам нужно загуглить в сторону «js multiselect dropdown».

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

iOS приложение не имеет возможности совершить покупку без ведома пользователя. Это моментальный реджект. Так что выше вам правильно рекомендуют.

Я не понял, зачем тег iphone, но в общем виде это делается графическими примитивами без всяких прогресс-баров. Бэкграунд + стрелка. У вас есть крайние точки шкалы и угол между ними, поэтому отклонение стрелки в зависимости от значения расчитывается элементарно. Отрисовываете стрелку повернутую на нужный угол любой доступной графической библиотекой. Можете сами написать, там простейшая тригонометрия.

XCode + Chrome + Photoshop это минимум 8 гб, а лучше 16 (по собственному опыту). Я бы не брал эир под такие задачи, а взял бы прошку, пусть даже и б/у. Макось очень жручая до оперативки.

Попробуйте протестить нативные элементы — таб или навигейшн. Если с ними все в порядке, значит у вас проблема с позиционированием контролов. Например, часто путают frame, bounds. Размер окна приложения может отдавать со статус баром или без него. В этом случае все зависит от версии оси и того, куда именно и как вы кладете контролы. Если и нативные глючат, значит проблема с эмулятором.

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

Я бы не переводил в контрастно черно-белое, а использовал бы greyscale. При любом сечении такой кривой получится кривая с горбиками. Выбираем порог высоты горбика, который учитывается и довольно легко получим количество.
Еще стоит поиграться с каналами, возможно один из каналов будет иметь стабильно больший контраст, чем другие (например, канал насыщенности). Тогда можно даже не переводить в черно-белое, а работать просто с каналом.

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

Экспертная система по классификации 3d объектов. Для 2d такое вроде есть (не слышал, чтобы хорошо работало, правда). Попробовать для трехмерных моделей.

Дело в том, что все ячейки которые вы прописываете на самом деле являются шаблонами. Чтобы их показать в TableView нужно к нему в коде подцепить datasource, где уже будут методы, чтобы для ячейки номер X вызвать шаблон Y и наполнить его такими-то данными. Это крайне типичный паттерн для списков и таблиц и не только на iOS.

Крупнейший русскоязычный molbiol.ru Оттуда куда пошлют :)

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

У меня это сделано так — словарь локализации (на базе SQLite) + собственный класс, таскающий оттуда значения во время выполнения. Проще некуда. И остается простор для разруливания сложных ситуаций, например, если у вас надпись в одном из языков не влезает туда, где должна влезть. Либо язык имеет иное направление письма.