Тренды iOS–разработки 2014 года


    Подходит к концу 2014 год, и сейчас самое время подвести итоги и выделить ключевые тренды в iOS разработке.

    Functional Reactive Programming


    Благодаря фреймворку ReactiveCocoa, новая парадигма программирования все чаще используется среди iOS разработчиков.

    Отказоустойчивость, отзывчивость, ориентированность на события и масштабируемость — вот четыре принципа реактивного программирования. Подробности можете узнать в реактивном манифесте (перевод на Хабре).

    Для себя я выделил следующие преимущества реактивного подхода:
    • loose coupling — потоки события позволяют уменьшить связанность между различными частями кода;
    • explicit state — состояние программы определяется набором событий, и поэтому им становится легко управлять.

    В качестве альтернативы реактивному подходу рекомендую посмотреть на Futures. Есть как минимум два интересных фреймворка: PromiseKit и CollapsingFutures

    MVVM


    Model-View-ViewModel (MVVM) представляет из себя UI design pattern и призван заменить привычный всем MVC. Благодаря ReactiveCocoa, MVVM начал бурно набирать обороты. Вы можете начать свое знакомство с MVVM с этого туториала.

    Swift


    Появление нового языка шокировало и одновременно обрадовало многих разработчиков.
    Все мигом кинулись осваивать новый язык, и как грибы после дождя, стали появляться различные Swift библиотеки.
    Пока что, из-за сырости среды разработки, язык считается непригодным для продакшн. Но это не значит, что его стоит игнорировать. Кстати, не так давно поддержка Swift появилась в AppCode.

    Realm


    Realm представляет из себя базу данных для мобильных устройств и является заменой SQLite и CoreData.

    Ключевые особенности Realm:
    • низкий порог вхождения
    • высокая скорость
    • эффективное использование памяти
    • большой набор платформ (доступна под Android, iOS, OSX)

    Благодаря этим особенностям и тому, что всем лень читать документацию по CoreData, Realm стал очень популярен, поэтому непременно обратите на него свое внимание.

    iOS 8


    Как всегда, выход новой версии iOS можно назвать главным событием года. Разработчикам стали доступны новые возможности, из которых хочу особенно выделить следующие:
    • Handoff — интеграция мобильного и desktop приложений;
    • HealthKit — вся информация о здоровье пользователя в одном месте;
    • App Extensions — появилась возможность расширять функциональность системы при помощи расширений. Теперь можно делать кастомные клавиатуры, виджеты для Today;
    • TouchID — наконец-то появилась возможность для работы с TouchID;
    • Metal — новый низкоуровневый фреймворк для работы с графикой;
    • Size Classes — новый подход к построению интерфейса для устройств с разной диагональю экрана;
    • WKWebView — новый WebView с улучшенной производительностью. Гибридные приложения получают еще один шанс.

    В общем, обязательно почитайте What's New in iOS 8 и поиграйтесь с новым API. Эта информация поможет сделать ваши приложения намного привлекательнее.

    Apple Watch


    Начиная с iOS 8.2 появилось API для сопряжения телефона и часов от Apple. По сути Apple Watch можно считать вторым экраном телефона, так как без находящегося рядом телефона данное устройство бесполезно.

    Коротко про Apple Watch:
    • есть два набора разрешений 38mm (136w x 170h) и 42mm(156w x 195h) или в пикселях 272x340 and 312x390
    • нужнен iOS 8.2;
    • есть три вида отображения: стандартный (запуск приложения с часов), glance (аналог виджета, т.е краткое представление данных приложения), кастомный UI для уведомлений;
    • приложение для часов является расширением приложения для iOS, то есть без использования iPhone на часы ничего не установить;
    • карты показываются в виде скриншота. т.е. скролить и зумить не выйдет;
    • весь код выполняется на телефоне, и это значит, что нет необходимости апдейтить firmware на часах;
    • можно использовать только storyboard;
    • анимации можно делать только при помощи набора картинок.

    Симулятор для Apple Watch уже давно доступен, так что можете начинать встраивать поддержку данного девайса в свое приложение.

    Чего ожидать в 2015 году


    Касаемо разработки, все должно остаться так же. Популярность Swift, MVVM и ReactiveCocoa продолжит расти, будут создаваться новые фреймворки.

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

    А какие тренды выделили бы вы?

    e-Legion

    113,82

    Лидер мобильной разработки в России

    Поделиться публикацией

    Похожие публикации

    Комментарии 28
      +2
      Тренды какие-то… типа как понизить производительность ваших приложений, чтобы они на iPhone 6 лагали точно также, как и на iPhone 4. Единственное интересное — Realm.
      Из другого интересного: в этом году FB выпустил такие библиотеки, как AsyncDisplayKit и pop, которые позволят нивелировать весь оверхэд от ReactiveCocoa.
        0
        Это вы по опыту работы с UI с помощью ReactiveCocoa? А то присматриваюсь к ReactiveCocoa в качестве описания цепочек обработки/загрузки данных.
          0
          И правильно делаете! В качестве примера приложения, нарисаного полностью на RAC пожете глянуть на QIWI
          0
          Кстати у FB была интересная презентация, в которой они рассказывали про опыт использования MVVM при разработке Paper.
          К сожалению они там не рассказали технические детали. Возможно это был RAC, но скорее всего, запилили что-то свое.
          +4
          Apple зашерлочил Reveal, а также приобрел TestFlight.
            0
            По-моему, встроенный view hierarchy убогий и, по сравнению с Reveal, совсем бесполезный. Он останавливает приложение и нет возможности изменять значения пропертей. Лично мне редко когда мог помочь просто факт наблюдения иерархии: когда что-то не так, то обязательно хочется что-нибудь подвигать или хотя бы перекрасить в другой цвет. С помощью Reveal я иногда подгоняю верстку под макет — кладу в бекграунд скриншот с макета, выставляю демо-данные и прикидываю, что и на какое расстояние не совпадает с макетом.
              0
              Тоже ожидал от интеграции Reveal большего. Получился огрызок какой то вместо полнофункционального ViewDebugger'а.
            +1
            Futures все таки не замена сигналам это как сигнал с одним next. С помощью сигналов удобно связать компоненты интерфейса и вобще всей программы в единый поток информации. Так же из трендов я бы отметил уход в сторону immutable структур. Помню, на RACDC в этом году все офигели от доклада Jon Sterling vimeo.com/98100160. Это то куда стоит смотреть и развиваться.
            P.S. State is the root of all evil.
              +1
              Realm ещё очень сырой. Был негативный опыт использования. Например, за время разработки несколько раз была ситуация когда после падения приложения база Realm'а становилась полностью неработоспособной.
                +1
                спасибо e-Legion. Попробую Reveal.
                  +1
                  Очень надеюсь, что популярность ReactiveCocoa будет падать, ибо пока что этот фреймворк приносит только вред, а не пользу. Вместо loose coupling получаем на выходе бешеную колбасу из блоков и коллбэков, которая в определенный момент становится совершенно нечитабельной

                  Пример

                  На мой взгляд фреймворк не решает никакой проблемы в принципе, только их создает.
                    0
                    Полностью поддерживаю, часто RAC внедряют не потому что оно надо для каких то целей, а потому что «в тренде», «модно» и т.д.
                    Без сомнения, RAC можно использовать в некоторых моментах, но, опять же, в тех же случаях можно обойтись делегатами или KVO.
                      0
                      Если получается бешеная колбаса, это явный признак того, что разработчик не умеет RAC готовить.

                      А по ссылке — все еще разрабатываемое нестабилизированное Swift API.
                        0
                        А если задуматься, как подобное бы выглядело на одних коллбэках, то по ссылке все очень даже неплохо.
                          0
                          Хочу обратить внимание на то, что автор кода по ссылке и автор Reactive Cocoa это одно и то же лицо, Justin Spahr-Summers.
                            0
                            Спасибо за уточнение, уже догадался.

                            С удовольствием бы посмотрел на более лаконичную и простую (в смысле simple, не easy) реализацию на коллбэках и делегатах.
                      +2
                      Довольно приятными нововведениями в XCode6 для меня стали Live Rendering и IBInspectable параметры. Ну и конечно нормальная поддержка custom шрифтов.
                        0
                        IBInspectable + IBDesignable вместе со свифтом просто божественны, без фреймворков позволяют сразу видеть, как вьюха будет выглядеть на любом размере экрана.

                        Немного не хватает поддержки UIViewController для IBDesignable, надеюсь Apple допилят, все-таки prepareForInterfaceBuilder обьявлена в категории на NSObject, а не на UIView.
                          0
                          а как по-вашему должен выглядеть IBDesignable контроллер?
                            0
                            Контроллер имплементит prepareForInterfaceBuilder, закидывает стабнутые значения для моделей, и выглядит так, как в живом приложении. Как вариант можно даже не стабать модели, если используете тот же OHHTTPStubs.

                            В данный момент сториборды могут рендерить вьюхи, но не могут рендерить UIViewController. Хотя метод prepareForInterfaceBuilder находится в категории на NSObject, что намекает на то, что рендерить можно не только UIView.
                              0
                              Просто я к тому, что, UIViewController никак не выглядит. У него есть аутлет на view, которой можно сделать кастомный класс, например.
                                0
                                Для 99% UIViewController используется стандартный UIView, заменять его на кастомный ради рендеринга — костыль. И как раз UIViewController очень даже нормально выглядит, и показывается в live preview на разных разрешениях экрана. В данный момент удобно открывать превью с 3.5, 4, 4.7, и 5.5 inch, чтобы сразу видеть, правильно ли настроены те же autolayout constraints.

                                И за исключением IBDesignable части, все статические элементы прекрасно видно. Если они допилят IBDesignable — будет потрясающе, необходимость запускать симулятор практически отпадет.
                                  0
                                  Это его view показывается в live preview, а не viewController. View в контроллере совсем не наглухо вмонтирована, Ее можно просто взять и удалить, останется контроллер совсем без view. Что он тогда должен показывать?
                                  По-моему, делать кастомный класс вьюхи в контроллере – совсем не костыль, а наоборот true way. Чтобы сама кастомная вьюха умела себя показывать в зависимости от своего состояния, а не контроллер бы знал как в обычную UIView напихать всего подряд и моргать на ней лампочками. Тогда эту вьюху можно будет переиспользовать в других местах, где не нужен контроллер (appear/disappear/отслеживание ориентации, связь с другими компонентами и др) и просто добавлять её как subview.
                                    0
                                    Не согласен с вами. Кастомную вьюху имеет смысл делать, когда у нее есть функционал, которого нет в стандартной. Например — у меня в проекте есть UIButton, который через IBInspectable поддерживает borderColor, borderRadius, и так далее. Для использования достаточно подкинуть, и выставить значения в IB.

                                    А что будет делать вьюха контроллера, если вы сделаете ее кастомной? Все равно за весь контент отвечает контроллер, а не UIView.

                                    Любую UIView, которую можно реюзнуть, разумеется стоит делать кастомной, но вьюха UIViewController имхо не тот случай.
                                      0
                                      Но ведь у всех ваших вьюх в контроллерах функционал, которого нет в стандартной UIView. В ней куча каких-то сабвьюх, лейблов, кнопок и так далее.
                                      В моем идеальном мире, все вьюхи имеют наружу только «примитивные» типы (NSInteger, NSString, NSDate), а все аутлеты скрыты в имплементации. ViewController лишь подписывается на разные экшены от этой вьюхи и манипулирует вьюхиными пропертями. То есть просто наполняет вьюху данными, но сам за отображение не отвечает. А у нас обычно что — куча аутлетов на всякие контролы, там же всё двигается, показывается, прячется и тд. Данные тоже прям в контроллере получаются (запросы в сеть, в бд, etc) – это же полная лапша
                                        0
                                        Я и не говорил, что UIViewController должен отвечать за отображение. Это может быть иерархическая структура.

                                        Делаем IBDesignable UIViewController, в нем IBDesignable UIView и так далее. Каждый из этих классов имплементит prepareForInterfaceBuilder. И мы сразу видим результат в preview. Прекрасно же было бы.

                                        В вашем же случае, вам доступна только вторая часть с UIView, что режет полезность функционала в два раза.
                                          0
                                          UIViewController не отображабельный, у него нет никакого интерфейса, чтобы тот был Designable. Это просто такой сабкласс NSObject, у которого есть проперти типа UIView. Всё, что он делает, так это заполняет эту проперти в loadView и вы там можете загружать всё что угодно (если сегодня четверг — то UIView, а если пятница — то UICollectionView) – как здесь понять, что должно загружаться в таком контроллере?
                                          Допустим, UITableViewController в initWithStyle просто запоминал бы style и потом загружал бы или UITableViewPlain или UITableViewGrouped вьюху, обе UIView<UITableView> — какой здесь у контроллера должен быть «интерфейс»?

                                          Интерфейс контроллера — это его View, которая IBDesignable, как и положено. Вот эту View и надо рендерить, ее и надо конкретизировать.
                                            0
                                            Ну вообщем думаю, дальнейший спор бесполезен =) Обе стороны не переубедить.

                                            С моей точки зрения, у UIViewController как раз есть интерфейс. Все примеры, которые вы приводите, прекрасно можно обработать в prepareForInterfaceBuilder().

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

                      Самое читаемое