Apple seeds iOS 6 beta 3 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 theABAddressBookRequestAccessWithCompletion function after calling the ABAddressBookCreateWithOptions function. TheABAddressBookRequestAccessWithCompletion 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 kABOperationNotPermittedByUserErrorerror. The user is prompted only the first time access is requested; any subsequent calls to ABAddressBookCreateWithOptions 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 photo library. This API is independent from the 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.

• Pick remote speakers in Settings > AirPlay.
• Set an onscreen code for AirPlay in Settings > AirPlay.
• Save multiple iTunes Store accounts in Settings > iTunes Store.
• Press and hold the Select button to rearrange icons on the main menu.
• Hide the main menu icons in Settings > General > Parental Controls.

• 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 only be prompted 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 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 send email from their icloud.comaddress using a web browser.

Starting in iOS 6 beta 3, when you start a coordinated read operation on a file or package for which you already have a local version, the coordinated read will be granted as soon as possible, and the new version, if any, will download in the background. This call will block for downloading reasons only if you do not have any version of the file available locally.

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.

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

• The Done button is missing when adding a new reminder.
• The app crashes when you tap the Edit button to edit a reminder.

• 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, 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
• ACFacebookPermissionGroupKey

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 and UIInterfaceOrientationMaskAllButUpsideDown 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 both the topmost 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 YESfrom 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’s application:supportedInterfaceOrientationsForWindow: method) to determine whether to rotate.
• The system determines if 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 topmost fullscreen controller.
• The setStatusBarOrientation:animated: method is not deprecated outright. However it now works only if the supportedInterfaceOrientations method of the topmost 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 used to synthesize the information that would be returned by the supportedInterfaceOrientationsmethod.

• 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 that 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 edges within 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 the UILayoutFittingCompressedSize option) to find the size you want to use for your content view’s size 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.

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