Выпущены iOS 6 beta 4 и Xcode 4.5 Developer Preview 4 для разработчиков

• Пользователи могут предоставлять или запрещать доступ к данным контактов для каждого приложения. Чтобы запросить доступ к данным контактов, вызовите функцию ABAddressBookRequestAccessWithCompletion после вызова функции ABAddressBookCreateWithOptions. Функция ABAddressBookRequestAccessWithCompletion не блокирует приложение, пока у пользователя запрашивается разрешение или отказ в доступе. До предоставления доступа объект ABAddressBookRef не будет содержать никаких контактов, и любая попытка изменить контакты завершится ошибкой kABOperationNotPermittedByUserError. Пользователю будет предложено только при первом запросе доступа; последующие вызовы ABAddressBookCreateWithOptions будут использовать существующие разрешения. Обратный вызов будет вызван в произвольной очереди. Если объект ABAddressBookRef используется во всем приложении, то все использование должно быть передано в ту же очередь для использования ABAddressBookRef потокобезопасным образом.

• Приложение может использовать API статуса авторизации, чтобы проверить, может ли оно получить доступ к контактам, календарям, напоминаниям или фотогалерее. Этот API не зависит от API запроса доступа и не будет запрашивать у пользователя разрешение или отказ в доступе. С помощью этого API приложение может настраивать отображение своих элементов пользовательского интерфейса, которые будут получать доступ к классу данных. Например, если доступ к контактам авторизован или еще не определен, то может быть отображена кнопка пользовательского интерфейса для выбора контакта.
• Для адресной книги вызовите функцию ABAddressBookGetAuthorizationStatus. Для Event Kit вызовите метод класса authorizationStatusForEntityType: из EKEventStore. Для Assets Library вызовите метод класса authorizationStatus из ALAssetsLibrary. Значение возвращаемых статусов следующее:
  • Статус авторизации не определен — пользователь еще не принял решение о том, может ли это приложение получить доступ к классу данных.
  • Статус авторизации ограничен — это приложение не авторизовано для доступа к классу данных. Пользователь не может изменить статус этого приложения, возможно, из-за действующих ограничений, таких как родительский контроль.
  • Статус авторизации отклонен — пользователь явно отклонил доступ к классу данных для этого приложения.
  • Статус авторизации авторизован — это приложение авторизовано для доступа к классу данных.

• DNSServiceBrowse
• DNSServiceRegister
• DNSServiceResolve
• DNSServiceRegisterRecord
• DNSServiceQueryRecord

• Пользователи могут предоставлять или запрещать доступ к данным событий и напоминаний для каждого приложения. Чтобы запросить доступ к данным событий и/или напоминаний, вызовите метод requestAccessToEntityType:completion:: из EKEventStore. Это не заблокирует приложение, пока у пользователя запрашивается разрешение или отказ в доступе. До предоставления доступа для типа сущности хранилище событий не будет содержать календарей для этого типа сущности, и любая попытка сохранить данные завершится ошибкой.
• Пользователю будет предложено только при первом запросе доступа; последующие экземпляры EKEventStore будут использовать существующие разрешения. Обратный вызов будет вызван в произвольной очереди.

• Электронные адреса icloud.com теперь доступны для пользователей iCloud Mail. Пользователи, регистрирующие новые Apple ID или впервые активирующие Mail в своей учетной записи iCloud, автоматически получат электронный адрес @icloud.com вместо электронного адреса me.com. Пользователи iCloud с адресами @me.com, которые использовались с iOS 6 beta 3 или новее, получат электронный адрес @icloud.com, соответствующий их адресу @me.com.
• Электронная почта icloud.com не может быть отправлена с icloud.com. Пользователям следует использовать icloud.com, если они хотят использовать веб-браузер для отправки электронной почты со своего адреса icloud.com.
• Адреса @icloud.com будут добавлены в течение двух недель с момента первого использования iOS 6.

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

• Замените CLActivityTypeVehicularNavigation на CLActivityTypeAutomotiveNavigation.
• Добавьте CLActivityTypeOtherNavigation для другого транспорта — например, лодок, поездов или самолетов.

• Совместимость API будет сохранена (см. известные проблемы ниже).
• Карты теперь поддерживаются в симуляторе.
• Данные карт будут продолжать развиваться — доступно лишь ограниченное количество спутниковых снимков высокого разрешения.

• Пользователи будут видеть диалоги доступа, когда приложение пытается получить доступ к любому из этих типов данных. Пользователь может включать и выключать доступ в «Настройки» > «Конфиденциальность».
• Разработчики могут установить строку «цель» для каждого класса изолированных данных. iOS отображает эту строку пользователям, чтобы помочь им понять, почему их данные запрашиваются. Эти строки можно добавить с помощью редактора проектов Xcode, который находится на вкладке «Информация». Соответствующие имена ключей начинаются со строки «Privacy -«.
• Внесены изменения во фреймворки Event Kit и Address Book, чтобы помочь разработчикам с этой функцией.

• ACFacebookAppIdKey
• ACFacebookPermissionsKey

Вы больше не должны добавлять этот словарь в файл Info.plist вашего приложения, как это требовалось в beta 1.

• Больше ответственности переходит к приложению и его делегату. Теперь контейнеры iOS (например, UINavigationController) не обращаются к своим дочерним элементам, чтобы определить, должны ли они поворачиваться. По умолчанию поддерживаемые ориентации интерфейса приложения и контроллера представления устанавливаются в UIInterfaceOrientationMaskAll для iPad и UIInterfaceOrientationMaskAllButUpsideDown для iPhone.
• Поддерживаемые ориентации интерфейса контроллера представления могут меняться со временем — даже поддерживаемые ориентации интерфейса приложения могут меняться со временем. Система запрашивает у самого верхнего полноэкранного контроллера представления (обычно корневого контроллера представления) поддерживаемые им ориентации интерфейса всякий раз, когда устройство поворачивается или когда контроллер представления представляется с полноэкранным модальным стилем представления. Более того, поддерживаемые ориентации извлекаются только в том случае, если этот контроллер представления возвращает YES из своего метода shouldAutorotate. Система пересекает поддерживаемые ориентации контроллера представления с поддерживаемыми ориентациями приложения (как определено в файле Info.plist или методом application:supportedInterfaceOrientationsForWindow: делегата приложения), чтобы определить, следует ли поворачивать.
• Система определяет, поддерживается ли ориентация, путем пересечения значения, возвращаемого методом supportedInterfaceOrientationsForWindow: приложения, со значением, возвращаемым методом supportedInterfaceOrientations самого верхнего полноэкранного контроллера.
• Метод setStatusBarOrientation:animated: не устарел напрямую. Однако теперь он работает только в том случае, если метод supportedInterfaceOrientations самого верхнего полноэкранного контроллера представления возвращает 0. Это возлагает ответственность за обеспечение согласованности ориентации строки состояния на вызывающую сторону.
• Для совместимости контроллеры представлений, которые все еще реализуют метод shouldAutorotateToInterfaceOrientation:, не получают нового поведения автоповорота. (Другими словами, они не возвращаются к использованию приложения, делегата приложения или файла Info.plist для определения поддерживаемых ориентаций.) Вместо этого метод shouldAutorotateToInterfaceOrientation: используется для синтеза информации, которая была бы возвращена методом supportedInterfaceOrientations.

• Вы должны убедиться, что ваши приложения не используют эти методы для управления компоновкой любых подпредставлений. Вместо этого они должны использовать метод viewWillLayoutSubviews контроллера представления и настраивать компоновку, используя прямоугольник границ представления.

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

• В целом, автоматическое размещение считает верхний, левый, нижний и правый края представления *видимыми* краями. То есть, если вы привязываете представление к левому краю его суперпредставления, вы на самом деле привязываете его к минимальному значению x границ суперпредставления. Изменение происхождения границ суперпредставления *не* изменяет положение представления.
• Класс UIScrollView прокручивает свое содержимое, изменяя происхождение своих границ. Чтобы это работало с автоматическим размещением, значение верхнего, левого, нижнего и правого краев *внутри* прокручиваемого представления теперь означает края его содержимого.
• Ограничения для подпредставлений прокручиваемого представления должны приводить к размеру, заполняющему его, который затем интерпретируется как размер содержимого прокручиваемого представления. (Это не следует путать с методом intrinsicContentSize, используемым для автоматического размещения.) Для определения размера frame прокручиваемого представления с помощью автоматического размещения, ограничения должны либо явно указывать ширину и высоту прокручиваемого представления, либо края прокручиваемого представления должны быть привязаны к представлениям *вне* его поддерева.
• Обратите внимание, что вы можете сделать подпредставление прокручиваемого представления «плавающим» (не прокручивающимся) над другим содержимым прокрутки, создавая ограничения между представлением и представлением вне поддерева прокручиваемого представления, например, между суперпредставлением прокручиваемого представления.
• Вот несколько примеров настройки прокручиваемого представления:
  • Смешанный подход:
    1. Разместите и задайте размер вашего прокручиваемого представления с помощью ограничений, внешних по отношению к прокручиваемому представлению — то есть свойство translatesAutoresizingMaskIntoConstraints установлено в NO.
    2. Создайте простое представление содержимого UIView для вашего прокручиваемого представления, которое будет иметь нужный вам размер содержимого. Сделайте его подпредставлением прокручиваемого представления, но позвольте ему продолжать преобразовывать маску авторазмера в ограничения:

       UIView *contentView = [[UIView alloc]

       initWithFrame:CGRectMake(0,0,contentWidth,contentHeight)];

       [scrollView addSubview:contentView];

       // DON'T change contentView's translatesAutoresizingMaskIntoConstraints,

       // which defaults to YES;

    3. Установите размер содержимого прокручиваемого представления, чтобы он соответствовал размеру представления содержимого:

       [scrollView setContentSize:CGMakeSize(contentWidth,contentHeight)];

    4. Создайте представления, которые вы хотите поместить внутрь представления содержимого, и настройте их ограничения, чтобы расположить их внутри представления содержимого. В качестве альтернативы вы можете создать поддерево представлений для размещения в прокручиваемом представлении, настроить ограничения и вызвать метод systemLayoutSizeFittingSize: (с опцией UILayoutFittingCompressedSize), чтобы найти размер, который вы хотите использовать для представления содержимого, и свойство contentSize прокручиваемого представления.
  • Чистый подход автоматического размещения:
    1. В этом случае translatesAutoresizingMaskIntoConstraints должно быть установлено в NO для всех задействованных представлений.
    2. Разместите и задайте размер вашего прокручиваемого представления с помощью ограничений, внешних по отношению к прокручиваемому представлению.
    3. Используйте ограничения для размещения подпредставлений внутри прокручиваемого представления, убедившись, что ограничения привязаны ко всем четырем краям прокручиваемого представления и не полагаются на прокручиваемое представление для получения своего размера. Простым примером может быть большое представление изображения, которое имеет собственный размер содержимого, полученный из размера изображения. В методе viewDidLoad вашего контроллера представления вы должны включить следующий код:

       UIScrollView *scrollView = [[UIScrollView alloc] init];

       UIImageView *imageView = [[UIImageView alloc] init];

       [imageView setImage:[UIImage imageNamed:"MyReallyBigImage"]];

       [self.view addSubview:scrollView];

       [scrollView addSubview:imageView];

       scrollView.translatesAutoresizingMaskIntoConstraints = NO;

       imageView.translatesAutoresizingMaskIntoConstraints = NO;

       NSDictionary *viewsDictionary = NSDictionaryOfVariableBindings(scrollView,imageView);

       [self.view addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"H:|[scrollView]|" options:0 metrics: 0 viewsDictionary:viewsDictionary]];

       [self.view addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"V:|[scrollView]|" options:0 metrics: 0 viewsDictionary:viewsDictionary]];

       [scrollView addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"H:|[imageView]|" options:0 metrics: 0 viewsDictionary:viewsDictionary]];

       [scrollView addConstraints:[NSLayoutConstraint constraintsWithVisualFormat:@"V:|[imageView]|" options:0 metrics: 0 viewsDictionary:viewsDictionary]];

       Это даст вам прокручиваемое представление, которое будет изменять размер по мере изменения размера представления контроллера представления (например, при повороте устройства), а представление изображения будет подпредставлением с прокруткой. Вам не нужно устанавливать размер содержимого прокручиваемого представления.

ContainerView

    |     OddHeightView

    |        |    EvenHeightView

    |    OtherFixedHeightView

и эти ограничения:

EvenHeightView.centerY == OddHeightView.centerY

EvenHeightView.bottom (or baseline) ==  OtherFixedHeightView.bottom (or baseline)

OtherFixedHeightView.top == ContainerView.top + 

В iOS 6 beta 4 на устройствах без дисплея Retina, нижние (или базовые линии) EvenHeightView и OtherFixedHeightView были сдвинуты на один пиксель, и разработчик ничего не мог с этим поделать. Эта проблема теперь исправлена.

• До изменений движок компоновки не целочисленно обрабатывал переменные положения для представлений, и эти ограничения всегда были выполнимы:

  ContainerView

  | OddWidthView

  | EvenWidthView

  OddWidthView.centerX == ContainerView.centerX

  EvenWidthView.centerX == ContainerView.centerX

  EvenWidthView.centerX == OddWidthView.centerX

  Теперь движок компоновки целочисленно обрабатывает переменные положения (x и y), а также переменные размеров (ширина и высота). Это означает, что он попытается удовлетворить три ограничения с *целочисленным* решением, которое может быть невозможно, и поэтому сообщит, что эти ограничения не могут быть удовлетворены. В этом случае, и во всех аналогичных случаях, разработчикам просто нужно удалить избыточное ограничение (или ограничения). В приведенном выше примере удаление любого из трех ограничений решит проблему.

• Обратите внимание, что поскольку спецификация все еще находится на стадии рабочего черновика, эти методы имеют префикс webkit, поэтому они являются window.webkitRequestAnimationFrame иwindow.webkitCancelAnimationFrame.