на чем писать под ios
На каком языке пишут приложения для iOS
Хотите создавать революционные приложения, но не знаете, на каком языке? Мы подготовили статью, чтобы вы могли определиться (спойлер: Swift).
Разработка приложений под iOS может быть кросс-платформенной или нативной. Первый способ позволяет использовать код на Java, C++, Python и других языках — просто компилируете приложение под iOS, и оно будет работать.
Второй — писать на Objective-C или Swift — языках, которые лучше всего подходят для создания приложения под операционные системы Apple.
Разработка кросс-платформенных приложений
Как уже говорилось выше, создать приложение для iOS можно с помощью:
Вы пишете один код, а потом компилируете его для разных платформ. Такой способ быстрее и дешевле, но подобные приложения работают гораздо хуже, чем нативные. Это связано с тем, что реализовать многие возможности в них не получится без костылей.
Можно, конечно, оптимизировать код, но работать приложение все равно будет медленнее нативного. Чем больше функций должно быть в приложении, тем хуже оно будет функционировать, не говоря уже о бесконечных багах и уязвимостях.
Разрабатывать кросс-платформенно рекомендуется, если не хватает времени или бюджета. Также такой подход предпочтительнее, когда речь идет о корпоративных приложениях в больших компаниях, где сотрудники пользуются миллионом разных устройств.
Примеры кросс-платформенных приложений:
Нативная разработка для iOS
Нативные приложения отлично работают без всяких костылей, потому что используются языки, которые подходят для конкретной платформы. В случае с iOS — Objective-C и Swift.
Objective-C
В 1980 году Брэд Кокс в своей компании Stepstone создал Objective-C — позже он стал основным языком разработки для устройств Apple. Objective-C — это компилируемый объектно-ориентированный язык программирования (ООП), основанный на C.
С помощью объектов решается проблема повторяемости кода. Но делается это не так топорно, как при структурном программировании, в котором увеличение объема и сложности программы снижает качество.
Основное отличие Objective-C от C++ (тоже поддерживает ООП и тоже был разработан в восьмидесятых годах) в том, что вызов метода в нем интерпретируется не как функция, а как сообщение — как в языке Smalltalk. Такие сообщения могут содержать что угодно, а отправить их можно куда потребуется.
Также объект может переслать часть полученного сообщения другому объекту (даже если он находится не на этом компьютере), что позволяет делегировать задачи — по такому же принципу работают нейросети.
Objective-C — компилируемый язык. Однако сообщения привязываются к функциям исключительно во время выполнения программы, что позволяет создавать динамичные приложения. Еще в языке поддерживаются протоколы и метаинформация.
Синтаксис здесь значительно отличается от синтаксиса C-подобных языков. Для сравнения:
iOS-разработка: способы быстрого старта
Когда мы задумываемся о разработке под iOS, чаще всего в голове возникает пятизначная сумма входного порога: как минимум нужно iOS-устройство на последней версии ОС и Mac. Если вы уже пишете под iOS, вам наверняка известны альтернативные варианты, а если нет — посмотрите, вдруг пригодится? Приведенный ниже обзорный пост — как раз на этот случай. Под катом вы найдете довольно простую информацию, так что если хотите хардкорчика, вам не сюда!
Путь от Apple
Путь настоящего джедая тру iOS-разработчика лежит в плоскости следования идеям Apple. Свежий SDK, свежая же версия Xcode, документация от Apple по технологиям Apple, форумы разработчиков на технологиях Apple – если вдуматься, а что ещё нужно для создания отличного приложения, кроме толики времени? Польза очевидна: разработка идет самым близким к платформе и к идеологии Apple образом, с использованием всех новинок, предлагаемых Apple в текущем (и будущих) iOS API, так что постоянное изучение нового приносят больше хорошего, чем плохого.
Новинки Apple озвучивает регулярно. На последней конференции для разработчиков WWDC 2017 были показан новый SDK и новая версия среды для разработке Xcode. Список изменений довольно обширен (тем более в преддверии выхода iOS 11):
Xcode
Текстовый редактор в Xcode переписали на Swift, сделав его надёжнее и быстрее. Можно ли это почувствовать? Да! Подсветка синтаксиса работает (почти) моментально, открытие и навигация по файлу теперь без заметных задержек, а сообщения об ошибках больше не перекрывают исходный код. В beta все выглядит очень приятно, посмотрим, что нас ждет в релизе!
В Xcode появилась поддержка Markdown. Разметку можно использовать при документировании кода, и функциональность эта, на первый взгляд, косметическая, довольно заметно облегчает чтение кода, особенно чужого:
(Источник)
Редактор, кстати, научился подсвечивать блоки кода, удобно при изучении большого объёма кода.
(Источник)
Ещё одной важной фичей Xcode 9 стал рефакторинг кода на Swift, Objective-C, Objective-C++, C. Рефакторинг позволяет переименовывать классы, переменные, а также дробить методы на менее крупные.
(Источник)
Из менее выделяющихся, но тем не менее полезных фич, можно назвать:
Swift 4
Это изменение стоит особняком. Все, кто уже пережил чувство «в Swift 2 было, в Swift 3 пропало?!», могут ощутить дежавю, но сейчас ожидаются изменения, скорее, в лучшую сторону (впрочем, замечу вполголоса, когда это было не так, по мысли авторов-то?)
«Гибридное», «не совсем нативное» приложение
Уточню: термин, вынесенный в заголовок, даже по сути своей не очень верен. Приложения, которые мы получим в результате, самые что ни на есть нативные в смысле того, что они исполняются на той же iOS, на том же железе, что и любое другое ПО для iOS, просто сам процесс разработки позволяет использовать не только предложенные Apple технологии и языки программирования. Если человек умеет писать, скажем, на JavaScript, и не хочет разбираться в Swift, то Apple ему ничем не поможет (кроме, конечно, хорошего учебника по Swift), а вот вариант написать, условно говоря, приложение на JavaScript, а потом запустить его на iOS, как если бы оно было написано в Xcode (получив, таким образом, некий «гибридный» вариант) существует, и вполне востребован.
Ionic
Ionic – один из самых известных фреймворков для кросс-платформенной разработки. Он построен на базе Apache Cordova, что обеспечивает доступ к различным функциям устройства, таким как геолокация, push-уведомления, камера и прочим, и позволяет разработчикам создавать приложения для iOS и Android с веб-технологиями, такими как HTML, CSS и JavaScript.
В дополнение к фреймворку, Ionic может похвастаться целой экосистемой, облегчающей разработчикам-новичкам процесс изучения и вхождения. Ionic Cloud предоставляет разработчикам различные инструменты для управления, развертывания и масштабирования приложений на Ionic. Ionic Creator представляет собой визуальный редактор, который позволяет разработчикам быстро прототипировать и создавать мобильные приложения методом drag&drop. Наконец, существует Ionic View — бесплатное приложение для iOS и Android, которое позволяет разработчикам легко делиться своим Ionic-приложением с пользователями, тестерами и клиентами без необходимости развертывать приложение в магазине приложений конкретной мобильной платформы. Разработчики просто отправляют пользователям приглашение из приложения Ionic View, и как только оно принято, пользователь может загрузить и запустить конкретное приложение в своей копии Ionic View — так, как если бы приложение было установлено на его телефоне из магазина приложений.
Увы, есть и «ложка дегтя». Приложения, написанные с использованием Ionic, используют WebView, в результате мы получаем самое натуральное веб-приложение, со своей обычной (обычно не самой впечатляющей) скоростью работы. За счет этого трудно считать его подходящим для создания тяжелых приложений, таких, как игры, либо программы с интенсивным использованием графики. Разработка с Ionic требует хороших знаний Angular, по крайней мере при желании «выжать» из фреймворка как можно больше.
PhoneGap / Cordova
PhoneGap исходно был создан компанией Nitobi. В 2011 году, Adobe приобретает Nitobi и бренд PhoneGap. Adobe затем передает одну из версий PhoneGap (назвав её Cordova), в Apache Foundation, оставив себе бренд PhoneGap и его как продукт. В результате Cordova можно рассматривать как движок, стоящий под капотом PhoneGap (а также некоторе другие гибридные фреймворки). PhoneGap, в свою очередь, добавляет к возможностям Cordova свои, дополнительные, функции.
PhoneGap во многих отношениях очень похож на Ionic. Он так же дает разработчикам возможность создавать кросс-платформенные приложения при помощи веб-технологий, и так же построен на базе Apache Codova. Однако PhoneGap не привязан к какому-то определенному Javascript-фреймворку, поэтому разработчики имеют бОльший выбор, на чем и как они будут создавать свои приложения. У PhoneGap имеется десктопное приложение, мобильное приложение, и облачный сервис под названием PhoneGap Build, который позволяет собирать и деплоить приложение.
Увы, подобно Ionic, PhoneGap использует WebView (который в iOS работает довольно медленно), так что со скоростью у приложений, созданных на базе этого фреймворка, дела не всегда обстоят блестяще.
Xamarin
Основанная в 2011 году компания Xamarin, выпускающая семейство продуктов Xamarin через пять лет своего существования была купена компанией Microsoft. Сегодня продукты Xamarin представляют на рынке очень интересный подход к разработке кросс-платформенных мобильных приложений: приложения пишутся на C#, затем Xamarin компилирует его в нативное приложение для iOS, либо для Android, при этом в качестве базовой технологии Xamarin использует Mono, чем кросс-платформенность и обеспечивается. Разработчики Xamarin говорят, что полученные на выходе приложения используют нативное API платформы, для которой приложение компилируется, так что поведение полученного приложения никак не отличается от поведения любого другого приложения на этой же платформе. Разработку, кстати, можно вести при помощи Visual Studio (что совсем неудивительно).
Несмотря на то, что большая часть кода проекта может быть без изменений использована на каждой из поддерживаемых мобильных платформ, тем не менее, некоторые фрагменты потребуется писать специально для версии приложения под iOS и под Android.
React Native
Проект React Native появился на свет в Facebook, и построен на основе React. Наше JS-приложение крутится на встроенном в iOS движке: на нем выполняется код и производятся все манипуляции с нативными виджетами ОС. React Native сопоставим с Xamarin, при этом приложения, созданные с помощью React Native, очень похожи на нативные приложения iOS и Android (потому что они собственно, оперируют нативными UI-элементами).
Синтаксис React довольно прост, что облегчает изучение фреймворка, а Стандартная библиотека UI-компонентов в поставке React Native содержит много полезных компонентов, однако самым большим отличием React Native от других JavaScript-фреймворков называют возможность использования кода на на Objective-C и Swift (чаще для для улучшения производительности или более тонкого взаимодействия с мобильной платформой). На практике это означает, что разработчики могут использовать существующие собственные библиотеки в своих приложениях React Native.
Веб, чистый веб
Часто недооцениваемая возможность использовать веб-страницу как отдельное приложение тем не менее к нашим услугам: если нет особых проблем со связью, а приложение обладает несложной функциональностью (вывод таблицы данных, или вывод постоянно обновляемого списка), то нет причин не воспользоваться старым добрым веб-просмотром информации с сервера.
Разница между открытием той же страницы в браузере будет в оформлении экрана: элементы управления браузера (в т.ч. и адресная строка) будут спрятаны, а содержимое страницы окажется выведенным на весь экран устройства. Из неудобств нас, конечно, ждет довольно долгое время открывания такого «приложения» (что связано со скоростью ответа удаленного веб-сервера), но для ряда применений это, думаю, вовсе не проблема.
Разработка приложений для мобильных платформ имеет свой подвох: поначалу думаешь, что дело не стоит усилий и времени, затем твоим приложением начинают пользоваться люди, причем пользоваться, в буквальном смысле нося его с собой, и вот тут ты понимаешь, что дело оказалось глубже, и затянуло тебя больше, чем ты мог бы себе представить.
Если вы любите мобильную разработку так же, как любим ее мы, рекомендую обратить внимание на следующие доклады Mobius 2017 Moscow (да-да, в ноябре Мобиус едет в Москву, если вы еще не знали):
Что нужно знать перед тем, как писать под iOS
«Под Windows можно писать для iPhone?»
Анонимный разработчик
«Мы не планируем публиковаться в AppStore, это ведь возможно? И еще мы хотим версию под Android. »
Анонимный заказчик
Как заработать?
Тут все очень просто/сложно. Пишете приложение, выкладываете в AppStore, выставляете цену, получаете деньги от довольных покупателей. 30% процентов от цены забирает Apple. Есть шанс как захватить мир, так и попусту потратить свое время — все зависит от вас.
Верхняя планка цены реальна — в AppStore было уже как минимум два приложения за тысячу долларов:
«BarMax CA» — приложение для студентов-юристов;
«I Am Rich» — приложение, показывающее изображение красного, видимо, драгоценного камня. Из магазина оно было убрано через день после публикации, но 8 счастливчиков все-таки успели его приобрести. Сейчас оно вернулось в AppStore уже с ценой в 10 долларов, одной из фич указано, что приложение продается всего за 1/100 от оригинальной цены.
Реклама в приложениях — iAd
Тут тоже все достаточно прозрачно: размещаете в своем приложении рекламный баннер, Apple делится с вами выручкой за показ рекламы и за клики по баннеру. На хабре уже писали об этом сервисе и даже рассказывали как добавлять баннеры в свои приложения. Остается добавить, что стоимость рекламы 1 цент — за показ, 2 доллара — за клик. Разработчик получает 60 процентов от вырученной суммы.
Торговля в приложении — In-App Purchases
Apple предоставляет возможность торговать вам в своих приложениях различными житейскими ценностями — ресурсами в играх, доступом к заблокированным секциям приложений и так далее. Отличная статья на эту тему есть на хабре — iPhone разработка: Интегрируем In-App Purchases. Да, Apple забирает себе положенные 30 процентов выручки.
Сервис подписок
Тем, кто в детстве выписывал «Мурзилку», должна быть понятна суть этого варианта заработка. Обычная подписка на журналы, газеты, музыку, видео… Издатель устанавливает цену, Apple берет себе стандартные 30 процентов. Сервис был запущен 15 февраля 2011 года, подробности можно почитать в официальном пресс-релизе.
Разработка приложений под заказ
Тут все тоже предельно просто — клиент платит деньги, вы разрабатываете приложение. Обычно это имиджевые, корпоративные приложения или представление каких-либо сервисов клиента для iOS.
Последний путь заработка наиболее прост в плане оплаты работы. Так как все происходит по обычной схеме, без финансовых отношений с Apple (кроме платы за регистрацию). В остальных случаях необходимо озаботиться вопросами получения заработанных денег. Комментарии с положительным/отрицательным опытом по данному вопросу приветствуются.
Как зарегистрироваться в iOS Developer Program
При регистрации вы можете регистрироваться либо как компания, либо как индивидуальные разработчик.
При регистрации компании нужно быть готовыми предоставить определенные документы.
Для Российских компаний нужно предоставить выписку из Единого Государственного Реестра Юридических Лиц (ЕГРЮЛ) и ее перевод. Название компании при регистрации должно совпадать с названием в выписке. В этой статье можно подробнее узнать о регистрации компании — Регистрация приложения в AppStore — мы сделали это!
Обычно вся процедура регистрации занимает 3-4 недели.
Куда проще регистрироваться индивидуальным разработчикам — после заполнения всех форм на сайте попросят распечатать, заполнить документ-заявку (требуются паспортные данные, данные карточки, адрес проживания и т.д.) и отослать факсом в Apple. После рассмотрения этого документа Apple списывает с вашего счета 99 долларов и вы становитесь зарегистрированным разработчиком. Вся процедура занимает 3-4 дня. Если у вас возникли проблемы с поиском факса, то можно воспользоваться каким-нибудь online-ресурсом, например — www.myfax.com/free
Обязательно ли нужен Mac?
Вам обязательно понадобится Mac OS X, так как ни на какой другой платформе вы не сможете работать с iOS SDK. Есть много различных вариантов разработки iOS приложений, но минимум для сборки и загрузки приложения в AppStore вам будет необходима Mac OS X. Да, последнее время появляются различные сервисы, которые и пирожки за вас есть будут предлагают постить приложения за вас и различные другие услуги, и о них на хабре тоже писали. Но, на мой взгляд, все это пока несерьезно и пользоваться услугами подобных контор, при разработке сколько-нибудь значимого приложения не стоит. Хотя, конечно, все зависит от задачи, если вы сможете зарабатывать, используя подобные сервисы, то почему бы и нет:)
Разница между web и native приложениями
Хочу пояснить разницу между native и web приложениями для iPhone/iPad, пока мы не перешли к инструментам разработки. Первые распространяются через AppStore (или in-house приложения), вторые — всего лишь web-сайт или его часть, специальным образом сконфигурированный под iPhone.
Доступные web-приложения можно посмотреть тут — www.apple.com/webapps
Для публикации своего web-приложения в этом каталоге необходима регистрация в iOS Developer Program. При публикации вас просят указать url приложения и некоторую дополнительную информацию (сайт компании, загрузить иконку и так далее).
Как понимаете, каких-то особенных, отличных от обычных инструментов web-разработчика для написания таких приложений не нужно, хотя сейчас развелось довольно много фреймворков, позволяющих упростить создание подобных приложений и сделать их больше похожими на native приложения.
Среди пользователей iДевайсов web приложения особенной популярностью не пользуются, а многие, по крайней мере в России, даже и не подозревают о них. Так что дальше будем рассматривать только вопросы разработки нативных приложений.
Какие инструменты можно использовать для разработки?
Тут я коснусь только нескольких инструментов — после снятия Apple запрета на ненативные инструменты разработки, чуть ли не каждый день появляются новые IDE и фреймворки.
Нативные средства разработки
MonoTouch
Flash
Adobe Flash Pro CS5 поддерживает разработку под iPhone. Другое дело, что пока этот путь основательно не разработан и определенная сырость в подходе присутствует.
Titanium & PhoneGap
Два фреймворка-хэдлайнера в мобильной кроссплатформенной разработке. Краткое описание можно найти в этой статье. Позволяют использовать javascript и HTML5 для разработки native приложений сразу под несколько платформ, в том числе и iOS.
Unity3D
Для себя я пока выбираю Xcode и Objective-C, но пристально смотрю в сторону кроссплатформенной разработки.
Еще одно небольшое замечание, если вы решитесь разрабатывать приложения под заказ
Deadline
Срок сдачи работы не всегда зависит от вас. Перед появлением в AppStore приложение проходит ревью, которое длится минимум 5 дней. Если приложение было отклонено по каким-либо причинам, то, после внесения изменений, необходимо будет отстоять всю очередь снова. Так что обещать клиенту выпустить приложение в AppStore к определенной дате, если у вас нет в запасе двух-трех недель, — поступок довольно безрассудный. Лучше обещайте показать приложение на устройстве к оговоренному сроку и объясните ситуацию с ревью. Для установки приложения на устройство нужно знать его UDID. То есть, даже если вы работаете удаленно, то вы всегда можете собрать приложение и отправить заказчику, чтобы он посмотрел его на своем девайсе.
Лучшие практики и инструменты при разработке iOS приложений
Разрабатывая мобильные приложения, мне не раз приходилось создавать проекты с нуля. При этом я и моя команда всегда тратили много времени на основную настройку проекта, такие как интеграция сторонних инструментов, настройка структуры проекта, написание базовых классов, интеграция внешних библиотек и т.д.
Я решил, что время, затрачиваемое на запуск проекта, можно уменьшить, а основную часть процесса можно автоматизировать. При этом я собрал лучшие практики и инструменты, которые мы использовали, и подготовил шаблон проекта, который мы используем при запуске новых проектов. Такой шаблон должен сэкономить время разработчика на конфигурацию нового проекта, а также обеспечить общую структуру проекта, к которой привыкнет каждый член команды, чтобы больше не приходилось думать и изучать структуру нового для него проекта. Теперь это всегда одинаково.
Каждый инструмент или подход, добавленный в шаблон, заслуживают отдельной статьи, но я хотел бы попытаться суммировать каждый пункт и дать краткое объяснение того, почему я включил их в данную статью.
Cocoapods
Я не думаю, что Cocoapods требует представления. Это библиотека для управления внешними зависимостями для IOS проектов. Она существует уже давно и является надежной и проверенной на практике в тысячах (если не в миллионах) проектов. Также существуют и альтернативные менеджеры зависимостей, например: Carthage, но я решил продолжить с Cocoapods, потому что у нее самый широкий спектр поддерживаемых проектов с открытым исходным кодом. Использовать Cocoapods очень просто, и он предоставляется с search index, который позволяет легко находить пакеты, которые могут пригодиться в любой момент.
Проект шаблона предоставлен с простым Podfile, который содержит Swiftlint и R.swift. Шаблон также включает Gemfile для управления версией Cocoapods, используемой для управления зависимостями. Данное решение является часто игнорируемым разработчиками, но оно предотвращает проблемы, возникающие, когда разработчики Вашей команды устанавливают зависимости, используя различные версии Cocoapods. Gemfile принудительно использует одну и ту же версию Cocoapods для всей команды.
Swiftlint
Swiftlint — это очень полезный инструмент для обеспечения соблюдения определенных правил и стиля написания кода каждым разработчиком в одной команде. Данную систему можно было бы рассматривать, как автоматизированную систему проверки кода, которая предупреждает разработчика об опасных моментах, таких, как, например, force casts, force tries и т. д., но кроме вышесказанного, данная система применяет общий стиль написания кода, следя за тем, чтобы все разработчики следовали одинаковым правилам, связанным со «стилем кода», например: отступы или интервалы. Такой подход имеет огромные преимущества, не только выполняя экономию времени на проверку кода, но также делает файлы проекта узнаваемыми, что повышает их читабельность и, как следствие, их понимание всеми участниками команды разработчиков. По данной ссылке предоставлен список всех правил. В шаблоне, Swiftlint он устанавливается посредством Cocoapods и включается в шаг «Фазы компиляции», поэтому он покажет предупреждение разработчику при каждой компиляции проекта.
R.swift
R.swift — это инструмент для получения строго типизированных, автоматически заполненных ресурсов, таких как изображения, сегменты шрифты и локализации. Он выполняет все перечисленные действия путем сканирования проекта и создания классов, необходимых для получения ресурсов. Самым большим преимуществом этой библиотеки является то, что при использовании ресурсов она делает программный код:
Если вы ошиблись в названии изображения, вы получите ноль. Если какой-либо член вашей команды изменит имя ресурса изображения, этот код вернет ноль или его выполнение будет остановлено, если вы принудительно развернете изображение. При использовании R.swift это выглядит так:
Теперь вы можете быть уверены, что пиктограмма действительно существует (компилятор предупредит вас, если это не так, благодаря проверкам времени компиляции), и Вы будете явно уверены, что не сделаете опечатку в названии пиктограммы, поскольку будете использовать автозаполнение.
R.swift устанавливается посредством Cocoapods и интегрируется в шаблон в Фазе компиляции и будет генерировать классы оболочки Swift для каждой компиляции. Это означает, что если вы добавите файл / изображение / локализацию / шрифт / цвет / перо и т. д., то все это будет доступно посредством R.swift после компиляции проекта.
Отдельный файл AppDelegate для тестов
Очень часто забывают о хорошей практике использования отдельного класса TestAppDelegate при запуске тестов. Почему это хорошая идея? Обычно класс AppDelegate выполняет много работы при запуске приложения. Он может иметь логику конфигураций window, конфигурировать базовое отображение пользовательского интерфейса приложения, выполнить логику регистрации для получения уведомлений, иметь код настройки подключения к базе данных и даже иногда выполнять вызовы серверного API. Юнит тесты не должны иметь сайд эффектов. Вы действительно не хотите выполнять вызовы случайных API и настраивать всю структуру пользовательского интерфейса вашего приложения только для запуска юнит тестов?
TestAppDelegate также является подходящим выбором для того, чтобы получить код, который вы хотите запускать только один раз во время выполнения набора тестов. Он может содержать код, который генерирует мок-объекты, заглушки сетевых запросов и т. д.
Шаблон содержит файл main.swift, который является основной точкой входа для приложения. В этом файле есть методы, которые проверяют среду работы приложения, и, если это тестовая среда, они вызывают TestAppDelegate.
Флаги профилирования производительности компилятора
Swift — это отличный язык, более простой в использовании и более безопасный, чем Objective-C (IMO). Но когда он был впервые представлен, у него был один большой недостаток — время компиляции. Вернувшись в дни, когда я работал над проектом в Swift, в котором было примерно 40 тыс. строк кода Swift (проект среднего размера). Код был очень тяжелым, с параметрами настройки и выводом типов, а компиляция чистой сборки заняла почти 5 минут. При внесении даже небольших изменений, проект повторно компилируется и это занимает около 2 минут, чтобы увидеть изменения. Это было одним из худших событий, которые я когда-либо испытывал, и из-за этого я почти прекратил использовать Swift.
Тогда единственным решением было попытаться профилировать время компиляции проекта и изменить свой код таким образом, чтобы компилятор работал быстрее. В помощь решения таких проблем, Apple вводит некоторые неофициальные флаги компилятора, которые предупреждают разработчика, о том, что компиляция тела метода или определение типа выражения занимает слишком много времени. Я добавил эти флаги в проект шаблона, для предупреждения о длительном времени компиляции вашего приложения.
В наши дни, время компиляции значительно уменьшилось, и разработчикам очень редко приходится оптимизировать свой код только для того, чтобы уменьшить время компиляции. Но все же лучше обо всем знать заранее, чем пытаться решить данную проблему, когда проект становится слишком большим.
Dev/Staging/Production configurations
Еще один хороший подход (или, можно сказать, необходимость) — иметь отдельную конфигурацию и переменные среды для сред разработки, финального тестирования и публикаций приложения. В настоящее время почти каждое приложение должно работать с сервером, и обычно такие сервера развертываются в нескольких средах. Среда разработки используется для ежедневного развертывания разработчиками для тестирования своего кода. Среда финального тестирования используется для создания стабильных релизов или для тестирования тестировщиками и клиентами.
Одним из способов поддержки нескольких сред в проекте iOS является добавление конфигураций на уровне проекта.
Конфигурации уровня проекта
Определив конфигурации, можно создать файл Configuration.plist, содержащий переменные для каждой среды.
Configuration.plist
При запуске проекта имеется возможность указывать, какую конфигурацию следует использовать. Вы можете сделать это в схеме сборки.
Затем необходимо добавить еще одно свойство в файл проекта Info.plist. Значение данного свойства будет динамически подставляться во время выполнения в имя текущей конфигурации.
Все это предварительно настроено в шаблоне.
Осталось только написать класс, который может извлекать эти переменные во время выполнения в зависимости от конфигурации, выбранной в схеме сборки. Шаблон содержит класс ConfigurationManager, который может извлекать переменные для текущей среды. Также можно проверить реализацию данного класса на Github, чтобы увидеть, как он работает.
Readme
Каждый проект должен содержать файл Readme, в котором, по крайней мере, содержатся инструкции по установке зависимостей и запуску проекта. Он также должен содержать описания архитектуры проекта и модулей. К сожалению, разработчики не любят писать документацию (файл readme является частью этой работы), и я видел проект, который разрабатывался месяцами, и у него даже был файл Readme. Чтобы снять бремя написания файла readme, шаблон содержит стандартный файл readme, который охватывает установку и структуру проекта. При настройке нового проекта с использованием шаблонов, вы автоматически включаете файл Readme.
Gitignore
В настоящее время большинство проектов используют GIT в качестве системы контроля версий. При использовании GIT у разработчиков нет желания игнорировать некоторые файлы или папки в проекте, например папку сборки или папку производных данных. Чтобы избавить разработчика от необходимости поиска файла gitignore, подходящего для его проекта iOS, шаблон содержит стандартный gitignore, предоставленный участниками Github.
Базовые классы для обработки внешних ссылок и уведомлений
В настоящее время почти каждое приложение должно обрабатывать внешние ссылки и уведомления. Для этого разработчик должен написать некоторое количество стандартного кода в классе AppDelegate. В данном шаблоне имеется описание, как это выполнить, в нем также содержаться базовые классы, облегчающие работу с внешними ссылками и уведомлениями.