Материал может быть полезен для людей, которые хотели бы развиваться в сфере мобильной разработки на iOS.


Swift или Obj-C


По поводу того, что изучать из двух языков, сломано много копий. Не буду углубляться в теорию (поскольку не теоретик). Плюсы Swift: простота, ясность, отсутствие страшных квадратных скобочек повсюду. Плюсы Obj-C: используется в большинстве старых проектов больших компаний, а поскольку почти никто не берет на работу джуниоров, кроме больших компаний, шансы трудоустроиться со знанием Obj-C выше, если вы знаете только Swift. Минусы Swift: если вы используете open source библиотеки, то далеко не факт, что она заработает из коробки. Был даже случай, что библиотека FacebookLogin не компилировалась на одной из версий, пока разработчики аврально не пофиксили баг. Словом, Obj-C это океан стабильности, когда как Swift это бурлящее море.


Дизайн


Сама Apple советует уделять дизайну не менее 50% от всего времени, затраченного на проект. Это золотое правило, правда дизайн нужно понимать в более широком смысле, чем привыкло большинство людей — не только как макет, но и структуру всех процессов в приложении. В условиях жесточайшей конкуренции и больших рекламных бюджетов достаточно сложно придумать приложение с уникальным функционалом, поэтому дизайн и user experience — это наше все. Я установил на свой телефон первые 10 приложений со сходным функционалом и сделал анализ по большому количеству параметров, начиная от онбординга и описания процессов и заканчивая скоростью загрузки и весом бинарного файла (что очень важно, поскольку без Wi-Fi могут быть загружены приложения весом до 150 мегабайт). Этот анализ дал мне представление о том, каким должен быть проект, чтобы получить хотя бы какие-то загрузки.


Дизайн существующих приложений можно и нужно переосмыслять, ведь и многие русские писатели Золотого века переосмысляли европейцев, как например, Толстой делал с Гюго. При этом не самым лучшим решением является заимствование "сахарного" дизайна с Dribbble или Behance — там много хороших художников, но дизайн — это скорее про аналитику и утилитарность, чем про красоту и вычурность.


В идеале хорошо иметь макет перед началом разработки кода, но на практике это два параллельных процесса, и поэтому очень хорошо, когда разработчик сам владеет навыками работы в Sketch (или Affinity Designer, не так удобно, но тоже можно работать).


Архитектура


Когда проект создается не для себя, а для компании, то архитектура становится одной из немногих отдушин, в которых можно проявить творческий подход в узких рамках технического задания. Я проанализировал более 100 вакансий на Хедхантере и пришел к выводу, что большие проекты все больше склоняются к VIPER с различными вариациями. Диджитал-агентства любят придумать что-то свое. Но если проект ваш небольшой и вы работаете над ним в одиночку — не стоит бояться банального Model-View-Controller, разве что стоит добавить отдельный router, если приложение сетевое. Даже если Controller становится массивным — это не так плохо, если у вас все в порядке с логикой и неймингом функций и переменных. С другой стороны, есть мнение, что количество классов прямо влияет на скорость загрузки приложения.


Отправка в App Store


Что касается непосредственно отправки в App Store, то нужно иметь в виду:


  1. 99 долларов на Apple Developer Program нужно потратить, когда будет готова хотя бы бета-версия приложения. До этого большой нужды в этом нет.
  2. Нужно быть внимательным с in-app purchases. Сам фреймворк StoreKit достаточно хитрый, и если есть желание сэкономить время и нервы, то можно использовать SwiftyStoreKit — он делает жизнь намного проще. При отправке приложения на проверку нужно приложить скриншот места, где можно сделать покупку и добавить описание. Если сделать это неправильно, есть шанс, что бинарный файл отклонят.
  3. Скриншоты для всех экранов можно сделать через условно-бесплатный сервис App LaunchPad, однако с iPhone X могут быть проблемы, поэтому желательно сделать скриншоты для него отдельно.
  4. Срок проверки приложений сейчас составляет обычно два дня, на выходных все значительно медленнее.
  5. Если у проекта много локализаций, то можно использовать Fastlane — это ускорит деплоймент приложения в несколько раз.