WWDC 2015: Никаких сенсаций

Разрыва шаблонов и крушения стереотипов на этот раз не было. Разумно и предсказуемо, почти скучно. Прилично до неприличия. Последняя часть мероприятия удивила. Она была неуклюжей и неинтересной, наверное это был худший “One More Thing” за всю их историю. То что презентовали, на самом деле, было неплохо: доступ ко всем богатствам iTunes за 9,99 долларов в месяц, 24 часа в сутки 7 дней в неделю. Семейный доступ – за 14,99. Это называлось Apple Music. Сервис. Подобные сервисы уже существовали, Apple Music даже если он (“сервис”, значит “он”) чем-то и превосходил их, презентация обошла этот момент молчанием. То есть, ничем?

Трюк OMT (One More Thing) использовался для выделения главного и невероятного, он был чем-то вроде сигнала для утомленных слушателей: “внимание, сейчас будет интересно!”, то есть, этот сервис следовало воспринимать как что-то прорывное и революционное.

Сам сервис был намного лучше чем его представили. Инженеры, как всегда, выполнили свою часть работы на высшем уровне. Но, почему-то, он так и не “взлетел”. Если бы о нём ничего не сказали в тот день, а просто выпустили бы сухой и бесстрастный пресс-релиз, с перечислением достоинств и важных подробностей, было бы лучше.

Но OMT закрывал пресс-конференцию по случаю открытия WWDC 2015 года, предыдущие её части, как минимум, были исполнены качественно и отторжения не вызывали.

Главные темы

Если забыть про Apple Music, главных тем было три. OS X El Capitan, iOS 9 (с функциями “только для iPad”, за 4 года до iPadOS) и watchOS 2. И с дюжину тем калибром поменьше.

Например, Metal пришел в OS X. В системных фреймворках он заменил OpenGL и OpenCL. У сторонних разработчиков был выбор, никто не заставлял их немедленно уходить из этих старых и медленных технологий – время еще не пришло.

“Металлисты” (группа разработчиков Metal) приручили графические процессоры от Intel, AMD и NVIDIA, это вообще-то был настоящий прорыв, которому уделили намного меньше времени чем Apple Music. Эксперты предсказывали этот прорыв, но года через 3, не раньше. Или через 5. Но не прошло и года: невыполнимая миссия блестяще выполнена. Во что это обошлось “металлистам”, не сообщали.

Сторонние разработчики использовавшие в своём коде OpenGL и/или OpenCL не спешили бросать привычные и хорошо им знакомые “устаревшие” API. Главным препятствием было даже не нежелание изучать что-то новое (необходимость постоянно учиться – особенность профессии программиста, такая же как постоянная готовность к смерти у самураев).

OpenGL и OpenCL были кросс-платформенными технологиями. Metal – нет. Более того, в отличие от прежних эпох Apple даже не пыталась сделать Metal общедоступным, считая его своим конкурентным преимуществом. Популярность “яблочных” платформ в 2015 была беспрецедентной, но недостаточной чтобы убедить разработчиков тратить время на две версии нетривиального кода вместо одной, общей для всех платформ.

Еще одна важная тема была затронута мимоходом. В начале презентации OS X 10.11 “El Capitan” Крейг Федериги сообщил что на 55% Mac’ов установлена OS X 10.10 “Yosemite”, вышедшая всего за 8 месяцев до этого. Для сравнения, Windows 8.1, вышедшую в октябре 2013, за год до OS X 10.10 “Yosemite”, использовали только 7% пользователей Windows.

В начале презентации iOS 9, Крейг сообщил что iOS 8 установлена на 83% iOS-устройств.

То есть, 55% пользователей Mac’ов и 83% пользователей iOS имели доступ к новейшим технологиям этих систем, разработчики могли со спокойной душой концентрировать свои усилия на максимальной совместимости с последними версиями систем. Насколько важна концентрация усилий при написании программы, надеюсь, догадаются даже те кто никогда не работал в софтверной индустрии.

Почему “яблочные” платформы год за годом распространяются на порядок быстрее чем их конкуренты? Причин несколько, но самая главная из них – простота апгрейда. И его цена. И модельные ряды в которых очень просто ориентироваться (а зачем больше?), и вообще тот самый “особый путь Apple”, за который её все критиковали и продолжают критиковать,

Среди новостей “второго уровня” было несколько новостей более важных чем “главные”. А про самую важную новость для разработчиков на пресс-конференции не упомянули.

О ней рассказали во второй половине первого дня WWDC.

Подозрительная забота о разработчиках

В 2014 году Apple, внезапно, перепроектировала iTunes Connect, облегчив жизнь всем кого нелегкая привела в ряды iOS-разработчиков, их менеджеров, маркетологов и всех прочих вовлеченных в создание iOS-приложений.

Это было настолько удивительно, что мы задавались вопросом “а в чём подвох?” – но его не было. Просто, наконец, сделали то что должны были сделать еще лет пять назад.

Но некоторые думали иначе. Была и такая версия: число желающих зарегистрироваться в качестве участника iOS Developer Program резко сократилось, а тех кто не продлевает подписку на эту программу (99 долларов в год, в США) наоборот стало больше. И вот вам результат: приобретение компании Burstly, наем её ключевых сотрудников, и разработка iTunesConnect “с нуля”.

Что сказал бы наш коллега, которого я назвал в предыдущем абзаце “некоторыми”, по этом поводу – могу только догадываться.

До июня 2015 года у Apple было три “программы для разработчиков”, каждая из которых обходилась в 99 долларов в год. Mac Developer Program, iOS Developer Program и Safari Developer Program. О первых двух я был неплохо осведомлен, программа разработчиков Safari, по-моему, касалась разработки расширений для Safari (могу ошибаться).

В 2015 году платформ стало больше, появилась watchOS. Связанная с iOS, но особенная. Решение которое приняли в Купертино было неожиданным. И приятным. Для всех, кроме тех кто только-что обновил свою подписку на все три Developer Program. Впрочем, о них позаботились: срок обновления подписки на единую программу был для них увеличен до двух лет.

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

Видео

Видеозапись пресс-конференции (продолжительность 02:20:09):

Продолжение следует

Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.

Разработчики хотят отвоевать у Apple доступ к «Экранному времени»

Несмотря на публичные заявления Apple о намерениях конкурировать, компания до сих пор не предприняла значимых действий, чтобы доказать создателям приложений, что она считает их за равных себе и готова к честной борьбе за звание лучшего. Такого мнения придерживаются разработчики, пожалуй, самой обделенной категории приложений родительского контроля, которые решили выступить перед Apple с требованием перестать блокировать их ПО, а наконец официально признать его и пропустить в App Store.

Как сообщает The New York Times, 17 разработчиков объединились между собой и решили потребовать от Apple создать специальный API, чтобы дать им возможность создавать приложения родительского контроля. К сожалению, на данный момент такая возможность отсутствует, поскольку Apple ограничивает стороннее ПО в возможности отслеживать информацию об использовании установленных программ, а также блокировать их при исчерпании установленного лимита времени.

Родительский контроль на iOS

Чисто технически сегодня только Apple может создавать приложения [для родительского контроля] под iOS. Мы считаем, что компания должна пойти разработчикам на уступки и дать всем желающим возможность создавать такие приложения, — заявил руководитель студии Kidslox Виктор Евпак, говоря о функции «Экранное время», которая появилась в iOS 12.

По мнению разработчиков, Apple не имеет права присваивать себе возможность создавать ПО для родительского контроля, но фактически делает это. В Купертино ссылаются на то, что сторонним приложениям из соображений безопасности запрещено получать информацию о других приложениях, а также каким-либо образом влиять на них. Отсюда проистекает запрет на блокировку активации программ, которые, по мнению родителей, не должны открывать их дети.

Как обманывает Apple

Казалось бы, все логично, но дело в том, что до выхода «Экранного времени» правила были совершенно другими. Тогда приложения сторонних разработчиков для родительского контроля фактически имели широкие возможности, чем сейчас. Что это, как не попытка избавиться от конкурентов с целью продвижения собственного продукта?

Официальная позиция Apple состоит в следующем. Разработчики имеют право создавать приложения-аналоги «Экранного времени», но только при условии, если они будут соответствовать требованиям безопасности. Главное требование состоит в том, чтобы ПО не использовало систему MDM (Mobile Device Management). Сейчас такие приложения есть в App Store и их никто не удаляет, подчеркнул Фил Шиллер, вице-президент Apple по международному маркетингу. Другой вопрос – что могут эти приложения, и являются ли она настолько же эффективными, как и «Экранное время».

А как вы относитесь к инициативе разработчиков? Делитесь своим мнением в комментариях или нашем Telegram-чате.

Разработчик показал, как сделать iOS 13 в разы удобнее

Закрытость iOS серьезно усложняет жизнь пользователям iPhone и iPad. Конечно, с одной стороны, хорошо, что таким образом Apple пытается обеспечить нашу с вами безопасность. Но ведь с другой, зачастую все эти системные ограничения, запрещающие использование сторонних приложений для звонков и сообщений, приносят куда больше неудобств, чем пользы. Даже «Камера», которая по умолчанию может быть только штатной, к сожалению, не подлежит замене на сторонние приложения. Хотя могла бы.

Разработчик Гильерме Рэмбо показал, что Apple вполне могла бы позволить нам использовать в качестве камеры по умолчанию решения сторонних разработчиков. Благодаря этому мы смогли мы бы запускать их прямо с рабочего стола, как это позволено делать со штатным приложением. По словам Рэмбо, чтобы реализовать такую возможность, ему пришлось переписать всего лишь 20 строк программного кода операционной системы, что не составит никакого труда даже для начинающего разработчика, не говоря уже о специалистах, которые работают в Apple.

Быстрый запуск приложений на iOS

Таким образом можно запускать совершенно любые приложения. Если вы большой поклонник Snapchat и используете для съемки только встроенную в клиент камеру, вам будет приятно узнать, что теперь вы сможете делать это в считанные секунды без необходимости снимать блокировку и искать приложение на рабочем столе. Просто воспользуйтесь для этого пиктограммой на экране блокировки. «У пользователей определенно должна быть возможность выбора. Очень надеюсь, что она появится в iOS 13», — заявил Рэмбо.

В целом, если начать развивать эту идею, можно прийти к выводу о том, что таким образом можно запускать не только камеру, а вообще любые приложения. Ведь далеко не все пользователи испытывают необходимость в камере. Одни могли бы задать на быстрый доступ активацию сообщений, другие – ленту инстаграма, а третьи – банковское приложение. Словом, возможностей для кастомизации – целая масса, но учтет ли Apple пожелания пользователей, пока не ясно.

Подписывайся на наш канал в Яндекс.Дзен, чтобы ежедневно читать эксклюзивные материалы, которые не попадают на сайт.

Как выглядит настольная версия Android Q

Режим рабочего стола, пожалуй, самая игнорируемая функция в Android Q, потому что, честно говоря, ее не так легко обнаружить с точки зрения обычного пользователя. Однако интересен здесь не сам факт ее существования, а то, что он подтверждает планы Google по расширению Android до полноценных настольных компьютеров.

Компания уже вовсю агитирует разработчиков портировать свои приложения под соответствующие разрешения. Ко всему прочему, если вспомнить, что даже десктопная версия Android – это все еще Android, к которому мы все привыкли, то становится понятно, что и ее можно всячески кастомизировать. Этим, собственно, и занялся один разработчик ПО, добавив в знакомую систему несколько интересных функций.

Как выглядит десктопный режим Android Q

Сейчас кастомный лончер все еще находится на ранних стадиях разработки, но на видео ниже уже можно увидеть доказательство его существования и то, как он работает. Разработчик проекта Дэниел Блэндфорд (Daniel Blandford) упоминает, что Google предоставляет большинство API и своих сервисов, необходимых для создания собственной версии лончера настольной версии Android Q.

Правда, при разработке обнаруживаются некоторые неприятные ошибки. Например, если кликнуть правой кнопкой мыши и открыть контекстное меню, произойдет сбой запущенного в данный момент приложения.

Способен ли настольный режим Android Q заменить большие ОС

Как и предполагают многие, у этого настольного лончера действительно есть все основные преимущества, присущие «большим» ОС, такие как окна произвольной формы, которые можно перемещать по всей площади рабочего стола, поддержка мыши и клавиатуры, и другие привычные нам функции.

Однако есть здесь также некоторые ограничения API. Например, нет возможности отображать значки запущенных приложений на панели задач. Кроме того, нельзя выключить экран телефона, так как при этом в режиме рабочего стола будет запущен скринсейвер. В связи с этими неудобствами разработчик лончера заявил, что он не заинтересован в выпуске своего проекта пока не устранит все ошибки, но уже сейчас планирует, что запуск стабильной версии произойдет примерно в то же время, что и выход финальной сборки Android Q.

Когда выйдет настольная версия Android Q

Это приложение предназначено исключительно для дополнения десктопного режима Android Q, но разработчики обычных лончеров могут также интегрировать необходимые API от Google для добавления поддержки режима рабочего стола в свои приложения. Тогда вы сможете запустить режим рабочего стола и в вашем любимом лончере. Имейте в виду, что и Android Q, и ее десктопный режим находятся сейчас на стадии бета-тестирования, а стабильный релиз стоит ожидать где-то в третьем квартале текущего года.

Делитесь своим мнением в комментариях под этим материалом и в нашем Telegram-чате.

WWDC 2014: Философия вместо “золотой формулы”

Создателей первого iPhone мучили сомнения. Даже когда все стало складываться очень неплохо, когда его показ был встречен овациями и он стал главной темой СМИ, сомнения не оставляли их ни на минуту. Яркий взлет, минута (или две) славы и восторга и… пшик. Судьба большинства сенсаций, в том числе и в мире цифровых искусств. Помните NeXTcube? Помните iCube? Уроки судьбы обошлись Стиву очень дорого, но если бы не они судьба iPhone могла быть именно такой.

Одним из открытий Стива стала “золотая формула”, определяющая идеальные размеры мобильного устройства с тач-интерфейсом на основании размеров и физиологических свойств человеческой ладони.

В этой формуле все было правильно, лишь один неприятный момент был упущен. Вместо разума, публика (то есть, толпа) управляется эмоциями. Её желания иррациональны. Ей не нужны удобства, её неразумным атомам нужно выделяться на общем фон. А оплачивали мобильную вакханалию именно они.

Формула продержалась до iPhone 4s, потом ей пришлось изменить. То что пришло ей на смену и дебютировало вместе с iPhone 5, назовем “серебряной формулой”. Она прожила еще меньше, и подтвердила неготовность действующей философии к еще более другим размерам.

Представляете как были счастливы iOS-разработчики когда им пришлось переделывать приложения, которые, с верой в обещания Apple, размеры экранов считали константой. И задавали координаты экранных элементов напрямую, числами. До iPhone 4s это работало. Адский ад, скрежет зубовный, стоны. Было.

Среда разработки была разработана с учетом “золотой формулы”. То есть, к изменениям размеров устройств она не была приспособлена вообще. У iPad была своя формула, почти не связанная с формулой для iPhone. Вместо того чтобы автоматически перераспределять экранные элементы в отведенном им пространстве, нужно было разрабатывать интерфейс для iPhone и iPad раздельно.

Это продолжение серии про WWDC 2014, предыдущие части здесь:

Первая часть: WWDC 2014: по версии Apple, 25-я WWDC;
Вторая часть: WWDC 2014: Вспоминая QuickDraw 3D;
Третья часть: WWDC 2014: Metal – это очень серьезно;
Четвертая часть: WWDC 2014: Swift;
Пятая часть: WWDC 2014: Непрерывность (Continuity);
Шестая часть: WWDC 2014: Чистилище отменяется.

Жизнь и смерть золотой формулы

У этого подхода были реальные преимущества: интерфейсы разработанные для больших пространств использовали их разумно, результаты были замечательными. Apple говорила об этом обстоятельстве как об еще одной важной своей победе.

Но океан бушующих эмоций (публика) все настойчивее требовал устройств с большими размерами экранов, а конкуренты с радостью шли публике навстречу. В 2013 году стало ясно, что даже от “серебряной формулы” придется отказаться. В конце концов, она хоть и наследие Джобса, но не догма.

А чтобы не повторять адский ад и скрежет зубовный, а теперь должна была измениться не только высота (в “портретной” ориентации), но сразу всё, да еще и в двух вариантах, пути отхода с занимаемых позиций начали готовить заранее. Весной или летом 2013 года.

Перед Люком Хистерманом, инженерным менеджером проекта, поставили задачу: “лучшее сохранить, негативные последствия минимизировать, превратить iOS-интерфейс в самый адаптивный интерфейс в отрасли”. Задачи не имеющие решения – это именно то, зачем эти психи (инженеры Apple) шли работать в компанию. 2 июня 2014 года, во второй половине дня, то что у них получилось было впервые представлено участникам WWDC 2014.

Затем, в подробностях, с примерами, тайны “новой философии” раскрыли перед ними на десятке сессий посвященных Adaptability (адаптивности, способности приспосабливаться). На смену золотой и серебряной формулам в iOS 8 пришла философия адаптивности, из-за чего Люк Хистерман сравнил масштаб изменений в iOS 8 SDK с масштабом создания SDK в 2008 году.

По закону эволюции

Если бы Стив все еще руководил компанией (в роли председателя совета директоров, но это ничего не меняет), он представил бы изменение философии лично. Он не упустил бы возможность красиво и убедительно подтвердить интеллектуальное превосходство Apple, напомнив что естественный отбор оставляет в живых организмы которые лучше других умеют приспосабливаться к изменяющимся условиям.

И сколь бы не были мощны динозавры, царившие на планете сотни миллионов лет, закон эволюции не пощадил даже их.

Узнав про заявление Люка Хистермана, эксперты посчитали показателем масштаба iOS 8 числа: 4000 новых API (рекордно много), и едва ли не еще большее число API объявленных в iOS 8 устаревшими (еще один рекорд). Но Люк имел в виду именно изменение философии SDK, смещение акцентов и наступление новой эпохи в истории iOS.

Но Стива не было. Никто ничего публике не объяснил.

Все уже было

Задолго до iOS 8, программные средства для реагирования на изменение размеров уже работали в Android и Windows Phone. Число размеров устройств на этих платформах уже давно превысило все мыслимые пределы. Клиентам это нравилось, они за это платили, и в 2014 или 2015, добираясь на работу (а в метро что-то случилось, сгорели какие-то кабели, и ехать пришлось в битком набитом 27 троллейбусе) мужик напротив меня прижимал к уху устройство размером с малую саперную лопату, и сообщал начальнику что задержится.

Рука у него была огромная, но даже для него, как мне показалось, этот трюк легким не был. Но его лицо светилось от гордости за себя и за своего цифрового друга.

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

Философия адаптации к изменяющимся условиям позволяла применять старые добрые рецепты в новых условиях, ориентируясь не на тип устройства и его ориентацию, а на целую систему отношений между объектами нескольких классов для принятия верных решений.

Первой реакцией на Adaptability со стороны экспертов с “другой стороны” были вовсе не обвинения Apple в воровстве. Они поражались сложности придуманного, предсказывали неработоспособность подобной системы. Почти не ошиблись – проблем было много.

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

Как и следовало ожидать, механизм заработал, но без сбоев не обошлось. До его дебюта оставалось три с половиной месяца, официально зарегистрированные iOS-разработчики пробовали этот механизм в полевых условиях и в полной тайне (подписка о неразглашении не штука, санкции за нарушения лютые), сообщали о найденых багах. С каждой новой бета-версией механизм сыпался все реже, а в последней бете, по-моему, он уже работал идеально. К выходу iPhone с нетипичными типоразмерами все было готово.

Технические подробности про Adaptability я отложил на будущее. Когда-нибудь, когда дойдут руки, я о них напишу. Когда – не знаю.

Продолжение следует

WWDC 2014: Чистилище отменяется

Все легальные iOS-приложения, прежде чем попасть на полки App Store, прошли через iTunes Connect (iTC). С 2008 по 2014 года iTC был настоящим чистилищем. Медлительный, неудобный, бестолковый и невероятно неэстетичный интерфейс. Изменений уже даже не ждали. Их устали ждать. И вдруг, в июне 2014 году, все изменилось. Про прежний iTC никто и никогда не сказал ни одного доброго слова. Неудивительно. Ваяли его в страшной спешке, явно не мастера, дизайном интерфейсов не занимался никто, и нетрудно понятно почему. У создателей App Store и его инфраструктуры были куда более важные задачи, выполнить любую из них хуже чем идеально было бы просто бессмысленно – а времени не было совсем.

Решение опубликовать iPhone SDK и создать App Store было спонтанным и неожиданным. Все это нужно было делать года на два или на три раньше. Планомерно и с умом. Хотели ведь как лучше.

iTC не устраивал не только его пользователей, никто не любит публиковать уродливые вещи – но когда вся эта спешка будет позади и напряжение спадет, за него собирались взяться всерьез.

Прикинули нагрузку на разрабатываемую инфраструктуру. На основании объёма продаж и учитывая рост спроса на iPhone из-за сторонних приложений. На всякий случай, решили ориентироваться на еще большую нагрузку – на всякий случай. Времени конструировать что-то сложное и масштабируемое не было. Решились рискнуть.

Несколько месяцев App Store работал в отладочном режиме. Нагрузку ограничивали, в iOS Developer Program регистрировали только тех кто постоянно жил в США, и многим из них тоже отказали, предложив попытаться еще раз, когда закончится отладка. О работавших “по ту сторону” процесса узнать как все это было не удалось (молчат), но проблем было много, часто вся эта затея висела на волоске. Немного осталось, можно потерпеть.

А как только комплекс App Store — iTC — Портал разработчиков заработал в полную силу, нагрузка на него немедленно превысила ожидаемую, и продолжила расти, с ускорением.

Создатели iPhone и App Store, похоже, доигрались и запустили цепную реакцию ужасной мощи и неизвестной природы. Опять было не до интерфейса, iTC оброс заплатками как днище ракушками – и исправить ситуацию могла только разработка его с нуля. Заплатки плодились, аврал не кончался, казалось что так будет всегда. К нему привыкли.

И вдруг, в июне 2014, Apple показала радикально обновленный iTC. Даже публике. Совсем другой – живой и удобный. Участникам конференции его представили в подробностях, чем вызвали восторг и овации. Все это было здорово, но пугало: что случилось? Поток иссяк? В чем подвох?

Ужасы и чистилище ушли в прошлое. Никто не догадался сохранить эти гулкие давящие на психику казематы и канцелярскую тупость, в назидание потомкам. Не поверят ведь…

Это продолжение серии про WWDC 2014, предыдущие части здесь:

Первая часть: WWDC 2014: по версии Apple, 25-я WWDC;
Вторая часть: WWDC 2014: Вспоминая QuickDraw 3D;
Третья часть: WWDC 2014: Metal – это очень серьезно;
Четвертая часть: WWDC 2014: Swift;
Пятая часть: WWDC 2014: Непрерывность (Continuity).

Интерфейс

В загадочном последнем номере журнала develop (он существовал только в электронной форме, пришел вместе с рассылкой “для служебного пользования”, я его читал и вот уже не одно десятилетие (!) не могу найти, была отличная статья про UI (User Interface). Автор писал: “интерфейс плохой если он заставляет умных людей чувствовать себя идиотами”.

И иллюстрировал свою мысль убедительными примерами. А вот их я не помню.

В старом iTC интерфейс мог добавить в тот список еще несколько примеров, но как вы уже поняли, им просто никто всерьез не занимался. Теперь интерфейс был. Под капотом тоже все изменилось – независимо от нагрузки (она продолжала расти, никакого спада и близко не было) теперь все работало. Как если бы это web-приложение было написано для самых обычных пользователей, приносящих компании прибыль. А если подумать, так оно и было.

iTunes Connect образца 2014 года не был идеальным web-приложение, но вместе с ним в еще одну частичку наших жизней вернулся здравый смысл. Возможно, его обновление связано с приобретением Apple в начале 2014 года одной компании, о которой я расскажу подробнее чуть ниже.

Связки приложений, аналитика и “чего изволите?”

В 2010 или 2011 один из проектов умер не начавшись: клиенту требовалось не одно iOS-приложение, а несколько. В его целевой аудитории были пользователи нескольких типов, двух или трех – для каждого из них требовался свой набор. Старые солдатские способы (приобретать в App Store требуемые наборы вручную, реализовать наборы функций в виде приложений и тому подобное) клиента не устраивали.

В iTC 2010 года связки из нескольких приложений не поддерживались, следовательно их не могло быть и в App Store. В iTunes Connect образца 2014 года это стало возможно.

Технический менеджер проекта iTC Дейв ван Тассел с явным удовольствием показывал как это делается. До 10 приложений (из одного аккаунта, прошедших проверку в App Store) теперь можно было объединить в bundle, переведу это как “связка”.

Процесс создания связки запускался “нажатием” кнопки “New Bundle”. Разработчики iTC явно не читали Apple Human Interface Guidelines, или не знали что “New” – не глагол. Это я ворчу. Кнопка – это действие, действие это глагол. Вообще-то требование разумное.

Блок объединения приложений в связку, анализируя профили включаемых приложений, сам заполнял большую часть полей нужными данными. Обычно угадывая. Все эти поля были редактируемыми. Профиль самой связки, в основном, создавался на основе главного приложения в связке – того которое первое в списке.

Расположение приложений в списке менялось перетаскиванием. Надо же, UI в iTC!

У связки было собственное имя, своя цена (меньшая чем суммарная цена компонентов), а устанавливались приложения связки одновременно, в одно касание.

Прошедшее время я использую из-за того, что рассказываю про iTC 2014 года. В данном случае подошло бы и настоящее, в большинстве случаев.

До TestFlight

О том что такое бета-тестирование (тестирование бета-версий), рассказывать не буду. Это то, чего в принципе не может быть слишком много.

До 2014 года организовать бета-тестирование iOS-приложений было сложновато.

Если у вас одно или два приложения, а в команде разработчиков человек десять (вместе с начальником и штатными тестировщиками), особых проблем не возникало. iOS-устройства участников разработки вносились в список – тестируемое приложение устанавливалось только на устройства указанные в списке. Устанавливалось вручную. Не обходилось без любимых в народе плясок с бубном, но в основном все было достаточно просто.

Устройства всех тестировщиков извне тоже должны были включаться в этот список. Для этого тестировщик должен был прислать UDID (уникальный идентификатор) устройств на которых он собирается тестировать приложение, которые включались в список, для всех из них в iTC генерировались provision profiles, и вместе с инструкцией о том что и как надо сделать для их установки, отсылались тестировщику.

В список могло быть внесено только 100 устройств. При удалении записи из списка место, которое она занимала, продолжало считаться занятым. Освободить список от удаленных записей можно было один раз в год. После очередной оплаты членства в iOS Development Program, но до первого внесения в этот список новой записи. Жестко?

Если у вас десятки проектов, 30 человек (50 устройств), а заказчики каждого из проектов вместо двух-трех UDID (как бы их не просили) присылают по пять-шесть – как быть?

Выкручивались. Содержали несколько аккаунтов (99 долларов в год за каждый, плюс куча логистических сложностей) – нужда заставит и не так раскорячишься.

Происхождение TestFlight

В начале 2014 году Apple приобрела компанию Burstly, производившую в том числе и TestFlight, приложение для iOS и Android облегчавшее бета-тестирование, вместе с персоналом.

Приложение TestFlight было размещено в App Store и Google Play в конце декабря 2010 года. Разработали его Тристан Козминка и Бенджамин Сэттерфилд. Приложение и всю инфраструктуру необходимую для его работы в 2012 году приобрела компания Burstly.

А в начале 2014 года Apple выбрала именно их (на рынок подобные продукты поставляли сотни компаний, это был очень востребованный товар), закрыла все проекты для Android, и проекты TestPath (аналитика) и SkyRocket (управление монетизацией мобильных проектов).

Команде из Burstly поручили разработку (с нуля) нового iTC. Тристану Козминка поручили разработку App Analytics, техническим менеджером команды стал выходец из Burstly Дейв ван Тассел.

Сумма за которую Apple приобрела Burstly неизвестна. Скорее всего миллионов за десять долларов – в 2013 компания “стоила” 7,3 миллиона.

То есть, Apple (как всегда) украла эту программу. За деньги. Кроме шуток, их обвиняли в этом. Никому не рассказывайте о том, что вы постоянно, крадете продукты из магазинов, оставляя взамен презренные деньги. Я знаю что вы это делаете. Я и сам не без греха.

TestFlight в iTC

В июне 2014 года Apple объявила TestFlight. Это iOS-приложение, работающее в тесном взаимодействии с iTunes Connect. iOS-приложение, как и организация бета-тестирования, бесплатны.

Для добавления бета-тестировщика обмен UDID и Provision Profile больше не требовался. Все что для этого требовалось – адрес электронной почты тестировщика.

Отправлять релизы вручную тоже больше не требовалось. Их получала и устанавливала на устройства (на столько устройств, сколько нужно – ограничивалось число тестировщиков, не устройств) программа TestFlight.

Ограничения? Опять?

С точки зрения TestFlight, тестировщики делились на две категории: на внутренних (тех кто внесен в список аккаунта iTC), до 25 человек; и внешних, число которых в 2014 году было ограничено одной тысячью.

Внутреннее тестирование можно было начинать сразу, зарегистрировав приложение как бета-версию на iTC. Для внешнего тестирования требовалось пройти проверку, такую же какая необходима для размещения в App Store. Это несколько дней, возможен отказ, всё такое – но такова жизнь.

Сервис в iTC отвечавший за тестирование отслеживал действия тестеров: получили ли приглашение, активировали ли его, установили ли приложение и запускали ли его вообще.

В 2014 число внешних бета-тестировщиков ограничили 1000 человек, затем увеличили его до 2000, в настоящее время их число выросло до 10 000.

На одном аккаунте можно одновременно тестировать до 100 приложений. Есть и другие ограничения, но о них читайте в документации.

Продолжение следует

Обсудить историю Apple вы можете в нашем Telegram-чате.

WWDC 2014: история появления Swift

Главное событие пресс-конференции по случаю открытия WWDC 2014 года случилось в самом её конце. Ему уделили совсем немного времени. Крис Латнер, умеющий захватить внимание аудитории и делать с ней все что захочет, был скован и непохож на себя. И тем не менее, WWDC 2014 вошла в историю как “WWDC на которой был представлен Swift”. Новый язык программирования, название которого переводится просто и без затей как “Стриж”, пришел на смену Objective-C.

26 лет этот язык использовался в NeXTSTEP и во всех наследниках этой системы (Mac OS X, iOS, GnuStep, tvOS), стал одним из самых популярных языков в мире, а по моему мнению он был (есть?) лучшим из лучших. Я не могу быть объективным, с 2001 по 2016 Objective-C был моим основным языком программирования. До него были ObjectPascal и C++.

Все остальное, объявленное и представленное на той пресс-конференции (новые версии OS X, iOS и Xcode, и даже Metal) произвело значительно более слабый эффект.

Это продолжение серии про WWDC 2014, предыдущие части здесь:

Первая часть: WWDC 2014: по версии Apple, 25-я WWDC;
Вторая часть: WWDC 2014: Вспоминая QuickDraw 3D;
Третья часть: WWDC 2014: Metal – это очень серьезно.

Раскол

Восторг, охвативший самых разных людей, искренний и неподдельный, я не разделял. Мне было больно и неприятно читать и слышать восхваления в адрес нового языка, который нес в сплоченные ряды пишущих для “яблочных” систем раскол и неразбериху.

В исходных кодах библиотек iOS и OS X десятки (если не сотни) миллионов строк кода на Objective-C. Переписать их на Swift в ближайшие лет десять-двадцать было нереально, тем более переписать по-умному, чтобы не утратить что-то важное и приобрести что-то очень важное и нужное.

Даже если бы Apple удалось идеально надстроить существенно другой по своей природе язык над всеми этими миллионами строк, проблемы были бы неизбежны. А сложное никто и никогда не делает идеально.

Что до самого языка, то сначала он мне очень не понравился. Скачав книгу про Swift (это шедевр технической документации, без капли иронии), и открыв её в первый раз, я увидел что-то вроде let aNumber = 42. Как в самых древних вариантах Basic’а! Отсталых уже тогда, когда я их изучал, лет за 20 до конца предыдущего тысячелетия. Оператор присваивания в них выглядел именно так, почти в точности (примерно так: LET ANUMBER = 42).

Я плюнул и закрыл эту электронную книгу. Возвратившись с работы и преодолев себя, я приступил к чтению. Оказалось что “let” в Swift имеет вполне достойное предназначение, но язык мне активно не нравился.

Строгий контроль за типами данных, сплошные “нельзя” и “обязательно” – это же кошмар, правда? Идея с optionals интересна, но как-то все непривычно. Не по-людски! А мне с ним жить.

Язык мне не нравился очень долго. Целую эпоху. Неделю или две. Через месяц меня охватил восторг.

Смелые обещания

Публике Swift представили как Objective-C без C. Будто бы из-за этого освоить его будет легче. Молодёжь к нему потянется, и напишет шедевры невероятной мощи. Стоп…

Человек, который не способен освоить C, может быть гением в любой области, но шедевр программистского искусства он не напишет никогда. Это не его.

К счастью, это всего лишь маркетинговый лозунг. C в Swift’е присутствует на каждом шагу, это C-подобный язык. Хотя собственно C, как отдельной сущности, в нем действительно нет.

Swift сконструирован по-умному, в нем предусмотрено многое из того о чем раньше никто не заботился. Язык очень предсказуем, безопасен, многие из самых типичных ошибок в нем физически невозможны – но вообще-то он сложнее чем C. В нем очень много правил о которых надо откуда-то узнать.

Современный, быстрый, компактный, продуманный, безопасный – пожалуй, эти обещания в новом языке были выполнены, с самого начала.

Но в то что Swift, с первого его дня, станет “гражданином первого сорта” в iOS и OS X я не поверил. В этом направлении Apple им команда Латнера сделали очень многое, возможное и невозможное, и даже (забегая вперед, в 2014 году об этом еще никто не знал) несколько раз все это переделали, улучшив и углУбив.

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

Когда системы хотя бы наполовину будут написаны на Swift, тогда это обещание будет исполнено.

Порадовало что никто не пообещал что даже самые-самые альтернативно одаренные товарищи смогут без труда писать в Swift отличный “софт”. Увы. Ни один язык в мире не гарантирует от ужасных программ.

Обещания (их было дюжины полторы) были “придуманы” в маркетинговой службе, со слов инженеров и менеджеров знавших про Swift и языки программирования не понаслышке. Их общение, скорее всего, было нервным – но продуктивным.

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

Swift 1.0

При всех его удивительных качествах, первый Swift был очень сырым, многое в нем вело себя не так как обещала Книга (бесплатная, отлично написанная, книга про Swift).

Согласно теории Жана-Поля Гассé, любое сложное техническое изделие (компьютер, программа, операционная система, графический или центральный процессор) не может “состояться” раньше чем в третьей его версии.

Теория работает не всегда: процессоры от Apple “состоялись” уже в первой их версии, в той которая называлась Swift (это Apple A6 и Apple A6X), а Cyclone (центральный процессор в Apple A7) уже просто громил конкурентов. Были и обратные примеры (но о грустном не буду).

Swift-который-язык состоялся именно в третьей версии.

Когда Крис ушел из Apple, самым главным в проекте Swift стал Тед Кременек, один из тех кто придумал, продумал и сделал реальностью это язык. Мне показалось что чуду пришел конец – но, судя по нынешней версии языка, я ошибался.

А какой язык лучше – Swift или Kotlin или современный C++?

Джеф Раскин говорил что сравнивать сложные сущности на лучше/хуже также нелепо как сравнивать точки на плоскости на больше/меньше. Джеф говорил много разных вещей. С очень многими его утверждениями я не согласен – но не с этим.

Про сам язык не пишу – о нем столько всего уже написано.

Продолжение следует

Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.

Apple проводит набор студентов в свою Академию разработчиков

Огромное значение, которое Apple уделяет программированию, не ограничивается только ежегодной конференцией WWDC и высказываниями Тима Кука о необязательности высшего образования. Чтобы подчеркнуть свою приверженность профессии разработчика, в 2016 году Apple открыла собственную Академию разработчиков в Неаполе. А на этой неделе объявила о наборе студентов для третьей по счету годичной программы обучения, каждый из которых имеет шанс получить востребованную и, что самое главное, хорошо оплачиваемую профессию.

Всего в этом году Apple планирует принять на программу обучения 400 студентов. Обучение в Академии абсолютно бесплатное, поэтому попасть туда сможет только тот, кто успешно справится со вступительными испытаниями, которые пройдут в три этапа.

Как поступить в Академию Apple

  • Первый этап – подача заявки, которую можно отправить через интернет (это можно сделать через сайт Академии, который на момент выхода публикации почему-то недоступен).
  • Второй этап – тест, который проводится сразу в трех городах Европы для удобства абитуриентов: Париж, Лондон и Мюнхен.
  • Заключительный этап – собеседование. Его можно будет пройти в четырех городах Европы: Париж, Лондон, Мюнхен и Неаполь.

Предполагается, что в Академию будут поступать студенты, которые уже имеют некоторое представление о программировании. Учебная программа была специально разработана экспертами Apple в области образования совместно с профессорами Университета Федерико II в Неаполе. В процессе обучения студентам предстоит получить необходимые навыки разработки приложений, изучить новые языки программирования и среды разработки, а также более глубоко понять принципы работы собственных платформ Apple.

По завершении обучения выпускники смогут самостоятельно заниматься созданием приложений для iOS и macOS. К настоящему моменту в App Store уже доступно более 50 приложений, разработанных выпускниками Академии Apple, которые пользуется чрезвычайно популярностью. А наиболее талантливые студенты получат право посетить конференцию WWDC, которая проходит каждый год в Сан-Диего.

Подписывайтесь на наш канал в Яндекс.Дзен, чтобы не пропустить все самое интересное.

Тим Кук усомнился в необходимости высшего образования

Вопрос необходимости высшего образования, который еще несколько лет даже не стоял, сегодня вновь стал предметом дискуссий. Все больше компаний при приеме на работу уделяют внимание релевантному опыту и навыкам соискателя, закрывая глаза на отсутствие «корочки». Само собой, устроиться на должность хирурга с таким багажом, скорее всего, не получится, а вот программистом – запросто. Такого мнения, по крайней мере, придерживается генеральный директор Apple Тим Кук.

«Я не думаю, что сегодня так уж необходимо получать высшее образование, чтобы быть программистом, — заявил Кук. – Я считаю, что это устаревший взгляд на вещи. Мы выяснили, что, если мы будем внедрять обучение программированию еще в начальных классах, постепенно усложняя преподавание этого предмета, то к моменту выпуска ребенка из школы, он уже сможет самостоятельно писать приложения, которые можно будет опубликовать в App Store».

Где учиться на программиста

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

Apple прикладывает огромные усилия к популяризации программирования, называя его профессией будущего. Чтобы иметь возможность обучать молодых людей навыкам кодинга, в 2016 году компания совместно с Неаполитанским университетом Фридриха II открыла в Неаполе собственную академию на 600 студентов. Им предстоит изучить основы программирования, освоить несколько программных языков и научиться создавать приложения для различных платформ.

Поговорим об образовании? Присоединяйтесь к нашему Telegram-чате, там уже ведутся жаркие дискуссии.

За счёт чего iOS 13 станет быстрее

В прошлом году была представлена iOS 12. Разработчики сделали особый упор на производительность и улучшение скорости работы устройств. Эти заявления не были голословными — многие старые iPhone действительно заметно «ускорились» на новой ОС, после откровенно неудачной iOS 11. В этом году Apple решила продолжить курс, и пересмотреть свой подход к разработке уже в iOS 13.

Как сообщает авторитетный разработчик Гильермо Рэмбо, неоднократно демонстрировавший поразительную осведомленность о планах Apple, iOS 13 станет быстрее, поскольку Apple решила переработать логику главного рабочего экрана (SpringBoard). По словам энтузиаста, речь идёт не о визуальных изменениях, а именно о внутренних улучшениях.

Компания подошла к этому серьёзно и основательно — сообщается, что Apple разделит приложение Springboard на обособленные процессы и фреймворки. Каждый процесс Springboard будет запускаться и обрабатываться отдельно, что, в теории, позволит ускорить общую производительность системы.

По мнению разработчика, Apple добавит более десятка различных процессов:

  • SpringBoard
  • BulletinBoard
  • FrontBoard
  • BackBoard
  • SplashBoard
  • BaseBoard
  • ParticleBoard
  • PreBoard
  • SoundBoard
  • HeadBoard
  • PineBoard
  • SketchBoard
  • RunningBoard
  • ProtoBoard

Если эта информация соответствует действительности, то это одно из самых серьёзных внутренних изменений в работе iOS за последние несколько лет. Впрочем, учитывая количество нововведений, сомневаться в намерениях Apple не приходится.

Напомним, что первая бета-версия iOS 13 для разработчиков станет доступна для загрузки в начале июня. Выход общедоступной версии, традиционно, стоит ждать осенью этого года. О совместимости пока нет информации, однако рассчитывать на то, что устройства построенные на процессорах Apple A7/A8 получат обновление, совершенно точно не стоит.

Предлагаем подписаться на наш канал в «Яндекс.Дзен». Там вы сможете найти эксклюзивные материалы, которых нет на сайте.