iOS 6 beta 4, Xcode 4.5 Developer Preview 4 released to developers

• Users are able to grant or deny access to contact data on a per-app basis. To request access to contact data, call the ABAddressBookRequestAccessWithCompletionfunction after calling the ABAddressBookCreateWithOptions function. The ABAddressBookRequestAccessWithCompletion function does not block the app while the user is being asked to grant or deny access. Until access has been granted, the ABAddressBookRef object will not contain any contacts, and any attempt to modify contacts fails with a kABOperationNotPermittedByUserError error. The user is prompted only the first time access is requested; any subsequent calls toABAddressBookCreateWithOptions will use the existing permissions. The completion handler is called on an arbitrary queue. If the ABAddressBookRef object is used throughout the app, then all usage must be dispatched to the same queue to use ABAddressBookRef in a thread-safe manner.

• An app can use the authorization status API to check if it can access contacts, calendars, reminders, or the photo library. This API is independent from the request access API and will not prompt the user to grant or deny access. With this API an app can adjust the display of its UI elements that would access the data class. For example, if access to contacts is authorized or not determined, then a UI button to pick a contact can be displayed.
• For Address Book, call the ABAddressBookGetAuthorizationStatus function. For Event Kit, call the authorizationStatusForEntityType: class method ofEKEventStore. For Assets Library, call the authorizationStatus class method of ALAssetsLibrary. The meaning of the status values that are returned is as follows:
  • Authorization Status Not Determined—The user has not yet made a choice regarding whether this app can access the data class.
  • Authorization Status Restricted—This app is not authorized to access the data class. The user cannot change this app’s status, possibly due to active restrictions such as parental controls being in place.
  • Authorization Status Denied—The user explicitly denied access to the data class for this app.
  • Authorization Status Authorized—This app is authorized to access the data class.

• DNSServiceBrowse
• DNSServiceRegister
• DNSServiceResolve
• DNSServiceRegisterRecord
• DNSServiceQueryRecord

• Users are able to grant or deny access to event and reminder data on a per-app basis. To request access to event and/or reminder data, call therequestAccessToEntityType:completion:: method of EKEventStore. This will not block the app while the user is being asked to grant or deny access. Until access has been granted for an entity type, the event store will not contain any calendars for that entity type and any attempt to save data will fail.
• The user will be prompted only the first time access is requested; any subsequent instantiations of EKEventStore will use the existing permissions. The completion handler is called on an arbitrary queue.

• icloud.com email addresses are now available for iCloud mail users. Users signing up for new Apple IDs, or enabling Mail on their iCloud account for the first time, will automatically receive an @icloud.com email address instead of a me.com email address. iCloud users with @me.com addresses that have been used with iOS 6 beta 3 or later will receive an @icloud.com email address that matches their @me.com address.
• icloud.com email cannot be sent from www.icloud.com. Users should use http://beta.icloud.com at this time if they wish to use a web browser to send email from theiricloud.com address.
• @icloud.com addresses will be added within two weeks of first using iOS 6.

Additionally, when the file is conflicted, the iCloud daemon will not wait until it has all the conflict losers of the file available to make the file available to your app. It will make the different versions of the conflicted file available as soon as it can. Your app can use the existing file coordination and the UIDocument callbacks to be notified when the conflict losers have been downloaded and are available.

• Replace CLActivityTypeVehicularNavigation with CLActivityTypeAutomotiveNavigation.
• Add CLActivityTypeOtherNavigation for other vehicular navigation—e.g., boats, trains, or planes.

• API compatibility will be maintained (see known issues below).
• Maps are now supported in Simulator.
• Map data will continue to evolve—only a limited amount of high-resolution satellite imagery is currently available.

• Users will see access dialogs when an app tries to access any of those data types. The user can switch access on and off in Settings > Privacy.
• Developers can set a “purpose” string for each class of isolated data. iOS displays this string to users to help them understand why their data is being requested. These strings can be added using Xcode’s Project editor, which is in the Info tab. The relevant key names begin with the string “Privacy -”.
• There are changes to the Event Kit and Address Book frameworks to help developers with this feature.

• ACFacebookAppIdKey
• ACFacebookPermissionsKey

You should no longer add this dictionary to your app’s Info.plist file, as was required in beta 1.

• More responsibility is moving to the app and the app delegate. Now, iOS containers (such as UINavigationController) do not consult their children to determine whether they should autorotate. By default, an app and a view controller’s supported interface orientations are set to UIInterfaceOrientationMaskAll for the iPad idiom andUIInterfaceOrientationMaskAllButUpsideDown for the iPhone idiom.
• A view controller’s supported interface orientations can change over time—even an app’s supported interface orientations can change over time. The system asks the top-most full-screen view controller (typically the root view controller) for its supported interface orientations whenever the device rotates or whenever a view controller is presented with the full-screen modal presentation style. Moreover, the supported orientations are retrieved only if this view controller returns YES from its shouldAutorotate method. The system intersects the view controller’s supported orientations with the app’s supported orientations (as determined by the Info.plist file or the app delegate’sapplication:supportedInterfaceOrientationsForWindow: method) to determine whether to rotate.
• The system determines whether an orientation is supported by intersecting the value returned by the app’s supportedInterfaceOrientationsForWindow: method with the value returned by the supportedInterfaceOrientations method of the top-most full-screen controller.
• The setStatusBarOrientation:animated: method is not deprecated outright. However, it now works only if the supportedInterfaceOrientations method of the top-most full-screen view controller returns 0. This puts the responsibility of ensuring that the status bar orientation is consistent into the hands of the caller.
• For compatibility, view controllers that still implement the shouldAutorotateToInterfaceOrientation: method do not get the new autorotation behaviors. (In other words, they do not fall back to using the app, app delegate, or Info.plist file to determine the supported orientations.) Instead, theshouldAutorotateToInterfaceOrientation: method is used to synthesize the information that would be returned by the supportedInterfaceOrientations method.

• You should make sure that your apps are not using these methods to manage the layout of any subviews. Instead, they should use the view controller’sviewWillLayoutSubviews method and adjust the layout using the view’s bounds rectangle.

• The class now supports the customization of the animations created during rotation. The names of methods for customizing insert and delete animations have also changed, so the same hooks can be used for rotations as well as for insertions and deletions.
• The class has changed some method names. Specifically, decoration views are no longer referred to by “reuse identifier” but rather by “element kind.” Apps that are using decoration views will need to modify their code and rebuild to accommodate this.

• In general, auto layout considers the top, left, bottom, and right edges of a view to be the visible edges. That is, if you pin a view to the left edge of its superview, you’re really pinning it to the minimum x-value of the superview’s bounds. Changing the bounds origin of the superview does not change the position of the view.
• The UIScrollView class scrolls its content by changing the origin of its bounds. To make this work with auto layout, the meaning of the top, left, bottom, and right edgeswithin a scroll view now mean the edges of its content view.
• The constraints on the subviews of the scroll view must result in a size to fill, which is then interpreted as the content size of the scroll view. (This should not be confused with the intrinsicContentSize method used for auto layout.) To size the scroll view’s frame with auto layout, constraints must either be explicit regarding the width and height of the scroll view, or the edges of the scroll view must be tied to views outside of its subtree.
• Note that you can make a subview of the scroll view appear to float (not scroll) over the other scrolling content by creating constraints between the view and a view outside the scroll view’s subtree, such as the scroll view’s superview.
• Here are some examples of how to configure the scroll view:
  • Mixed approach:
    1. Position and size your scroll view with constraints external to the scroll view—that is, the translatesAutoresizingMaskIntoConstraints property is set to NO.
    2. Create a plain UIView content view for your scroll view that will be the size that you want your content to have. Make it a subview of the scroll view but let it continue to translate the autoresizing mask into constraints:

       UIView *contentView = [[UIView alloc]

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

       [scrollView addSubview:contentView];

       // DON'T change contentView's translatesAutoresizingMaskIntoConstraints,

       // which defaults to YES;

    3. Set the content size of the scroll view to match the size of the content view:

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

    4. Create the views you want to put inside the content view and configure their constraints so as to position them within the content view.Alternatively, you can create a view subtree to go in the scroll view, set up your constraints, and call the systemLayoutSizeFittingSize: method (with theUILayoutFittingCompressedSize option) to find the size you want to use for your content view and the contentSize property of the scroll view.
  • Pure auto layout approach:
    1. In this case, translatesAutoresizingMaskIntoConstraints must be set to NO on all views involved.
    2. Position and size your scroll view with constraints external to the scroll view.
    3. Use constraints to lay out the subviews within the scroll view, being sure that the constraints tie to all four edges of the scroll view and do not rely on the scroll view to get their size.A simple example would be a large image view, which has an intrinsic content size derived from the size of the image. In the viewDidLoad method of your view controller, you would include code like the following:

       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]];

       This would give you a scroll view that resized as the view controller’s view resized (such as on device rotation), and the image view would be a scrolling subview. You don’t have to set the content size of the scroll view.

ContainerView

    |     OddHeightView

    |        |    EvenHeightView

    |    OtherFixedHeightView

and these constraints:

EvenHeightView.centerY == OddHeightView.centerY

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

OtherFixedHeightView.top == ContainerView.top + <space>

in iOS 6 beta 4, on non-Retina display devices, the bottoms (or baselines) of the EvenHeightView and the OtherFixedHeightView were off by one pixel and the developer could do nothing about it. This issue is now fixed.

• Before the changes, the layout engine did not integralize the position variables for the views, and these constraints were always satisfiable:

  ContainerView

  | OddWidthView

  | EvenWidthView

  OddWidthView.centerX == ContainerView.centerX

  EvenWidthView.centerX == ContainerView.centerX

  EvenWidthView.centerX == OddWidthView.centerX

  Now, the layout engine is integralizing the position variables (x and y) as well as dimension variables (width and height). This means that it will try to satisfy the three constraints with an integer solution, which might not be possible, and thus will log that these constraints are unsatisfiable. In this case, and in all analogous cases, developers just need to remove the redundant constraint (or constraints). In the example above, removing any one of the three constraints will resolve the issue.

• Note that because the specification is still at the Working Draft state, these methods have the webkit prefix, so they are window.webkitRequestAnimationFrame andwindow.webkitCancelAnimationFrame.