После переезда в солнечный Будапешт я осознал, что изучать новый язык по карточкам или с помощью онлайн-курсов — не для такого прокрастинатора, как я. А что если сделать приложение без карточек, курсов и механического заучивания, в таком контексте, который был бы мне интересен? Так родилась идея приложения, о котором я рассказывать не буду, но расскажу о том, с какими сложностями пришлось столкнуться, изучая программирование практически с нуля. Материал может быть полезен для людей, которые хотели бы развиваться в сфере мобильной разработки на iOS.
Swift или Obj-C
По поводу того, что изучать из двух языков, сломано много копий. Не буду углубляться в теорию (поскольку не теоретик). Плюсы Swift: простота, ясность, отсутствие страшных квадратных скобочек повсюду. Плюсы Obj-C: используется в большинстве старых проектов больших компаний, а поскольку почти никто не берет на работу джуниоров, кроме больших компаний, шансы трудоустроиться со знанием Obj-C выше, если вы знаете только Swift. Минусы Swift: если вы используете open source библиотеки, то далеко не факт, что она заработает из коробки. Был даже случай, что библиотека FacebookLogin не компилировалась на одной из версий, пока разработчики аврально не пофиксили баг. Словом, Obj-C это океан стабильности, когда как Swift это бурлящее море.
С чего начать
Я начал с того, что потратил 10 евро на курс Роба Персиваля на Udemy, который определенно стоит своих денег. Бывший учитель математики, Роб отлично и внятно рассказывает об основах Xcode и базовом программировании. Одновременно с просмотром роликов Роба хорошо бы почитать референс Apple по Swift, чтобы иметь представление о возможностях языка в целом. Если плотно заниматься по курсу Роба, для изучения самых основ будет достаточно полтора месяца. Под конец, когда уже пойдут проекты посложнее, нужно задуматься о своем проекте, начать продумывать функционал и, что самое главное для Apple, дизайн.
Дизайн
Сама Apple советует уделять дизайну не менее 50% от всего времени, затраченного на проект. Это золотое правило, правда дизайн нужно понимать в более широком смысле, чем привыкло большинство людей — не только как макет, но и структуру всех процессов в приложении. В условиях жесточайшей конкуренции и больших рекламных бюджетов достаточно сложно придумать приложение с уникальным функционалом, поэтому дизайн и user experience — это наше все. Я установил на свой телефон первые 10 приложений со сходным функционалом и сделал анализ по большому количеству параметров, начиная от онбординга и описания процессов и заканчивая скоростью загрузки и весом бинарного файла (что очень важно, поскольку без Wi-Fi могут быть загружены приложения весом до 150 мегабайт). Этот анализ дал мне представление о том, каким должен быть проект, чтобы получить хотя бы какие-то загрузки.
Дизайн существующих приложений можно и нужно переосмыслять, ведь и многие русские писатели Золотого века переосмысляли европейцев, как например, Толстой делал с Гюго. При этом не самым лучшим решением является заимствование "сахарного" дизайна с Dribbble или Behance — там много хороших художников, но дизайн — это скорее про аналитику и утилитарность, чем про красоту и вычурность.
В идеале хорошо иметь макет перед началом разработки кода, но на практике это два параллельных процесса, и поэтому очень хорошо, когда разработчик сам владеет навыками работы в Sketch (или Affinity Designer, не так удобно, но тоже можно работать).
Архитектура
Когда проект создается не для себя, а для компании, то архитектура становится одной из немногих отдушин, в которых можно проявить творческий подход в узких рамках технического задания. Я проанализировал более 100 вакансий на Хедхантере и пришел к выводу, что большие проекты все больше склоняются к VIPER с различными вариациями. Диджитал-агентства любят придумать что-то свое. Но если проект ваш небольшой и вы работаете над ним в одиночку — не стоит бояться банального Model-View-Controller, разве что стоит добавить отдельный router, если приложение сетевое. Даже если Controller становится массивным — это не так плохо, если у вас все в порядке с логикой и неймингом функций и переменных. С другой стороны, есть мнение, что количество классов прямо влияет на скорость загрузки приложения.
Сложности в разработке
Я, как человек без IT-образования, должен признаться, что не с первого раза смог освоить достаточно базовые принципы делегирования и хендлеров. Некоторые фреймворки тоже таят сюрпризы: например, как заставить Firebase синхронно запрашивать данные из базы? GCD не решает этот вопрос, ни группами, ни семафорами. В итоге проблема решилась обыкновенными completion handler'ами. Дешево и сердито, но работает.
Кроме того, для упрощения работы с дебаггером я стал добавлять к ключевым операциям и сразу после вызова функции вывод результата в консоль. Для новичка это значительно ускоряет понимание того, на каком моменте билд упал.
По итогам анализа тех же вакансий iOS разработчика, можно вывести примерный список самых популярных фреймворков, кроме стандартных UIKit и CoreData: Alamofire, Firebase, AVFoundation, MapKit (Mapbox), CoreLocation, CoreAnimation и Crashlytics.
Отправка в App Store
Изучение языка и нужных фреймворков заняло у меня 6 месяцев в режиме 3-5 часов в день, еще 3 месяца по 8 часов в день я занимался разработкой финального проекта. Что касается непосредственно отправки в App Store, то нужно иметь в виду:
- 99 долларов на Apple Developer Program нужно потратить, когда будет готова хотя бы бета-версия приложения. До этого большой нужды в этом нет.
- Нужно быть внимательным с in-app purchases. Сам фреймворк StoreKit достаточно хитрый, и если есть желание сэкономить время и нервы, то можно использовать SwiftyStoreKit — он делает жизнь намного проще. При отправке приложения на проверку нужно приложить скриншот места, где можно сделать покупку и добавить описание. Если сделать это неправильно, есть шанс, что бинарный файл отклонят.
- Скриншоты для всех экранов можно сделать через условно-бесплатный сервис App LaunchPad, однако с iPhone X могут быть проблемы, поэтому желательно сделать скриншоты для него отдельно.
- Срок проверки приложений сейчас составляет обычно два дня, на выходных все значительно медленнее.
- Если у проекта много локализаций, то можно использовать Fastlane — это ускорит деплоймент приложения в несколько раз.
Автор: aerlinn13
