Easily Overlooked New Features in iOS 7

Check out this list of easily overlooked features in iOS 7 – there will probably be a few you’ve never heard of! By .

Leave a rating/review
Save for later

iOS 7 has been out for some time now. By now, you’re undoubtedly aware of its groundbreaking visual design; you’re dabbled in the new APIs such as SpriteKit, UIKit Dynamics and TextKit; and as a developer you’ve probably taken at least a few first steps with Xcode 5.

However, this is one of the biggest iOS releases ever, especially in terms of new and deprecated features. Unless you’re the type to stay up all night reading the iOS 7 release notes, it’s pretty likely that there are one or two new changes that you might have overlooked.

We’ve compiled a handy (but non-exhaustive!) list of some of the more urgent and interesting changes in iOS 7. Have a read through and see what new gems you weren’t aware of before!

The Bad News, the Good News, and the Really Good News

There’s some bad news, good news, and really good news about iOS 7.

  • The bad news: There are a few app-breaking changes in iOS 7 which you need be on top of right away. If you haven’t already taken a close look at these changes in iOS 7, then you’d do well to read up on them, as they have the capability to break your existing apps when run on iOS 7!
  • The good news: A few of the features and APIs that you’re familiar with in iOS 7 have been enhanced — but there are a few other features that have been deprecated. Taking the time to review these changes would be a great investment in the future of your current iOS apps.
  • The really good news: The introduction of OS7 really shook up the mobile development world, but out of that tumultuous event came a bunch of really neat new features that have the potential to give your apps an edge, and may even serve as a catalyst for dreaming up really innovative apps for the future.

This article breaks down the easily overlooked features in iOS 7 into these three categories. Feel free to use this table of contents to quickly jump to the section you’re interested in – or keep reading to learn about all the changes!

The Bad News: App-Breaking Changes

  1. -[UIDevice uniqueIdentifier] is no more
  2. UIPasteboard as shared area is now sandboxed
  3. MAC addresses can’t be used to identify a device
  4. iOS now requests user consent for apps to use the microphone

The Good News: Enhancements & Deprecations

  1. Implementation of -[NSArray firstObject]
  2. Introduction of instancetype
  3. Tint images with UIImage.renderingMode
  4. Usage of tintColor vs barTintColor
  5. Texture colors are gone
  6. UIButtonTypeRoundRect is deprecated in favor of UIButtonTypeSystem

The Really Good News: New Features

  1. Check which wireless routes are available
  2. Get information about the cellular radio signal
  3. Sync passwords between user’s devices via iCloud
  4. Display HTML with NSAttributedString
  5. Use native Base64
  6. Check screenshots with UIApplicationUserDidTakeScreenshotNotification
  7. Implement multi-language speech synthesis
  8. Use the new UIScreenEdgePanGestureRecognizer
  9. Realize Message.app behavior with UIScrollViewKeyboardDismissMode
  10. Detect blinks and smiles with Core Image
  11. Add links to UITextViews

The Bad News: App-Breaking Changes

This section is dedicated to changes that you probably noticed during your transition to iOS 7, but you might not have known just how deep the changes go — and how they may affect your apps. The fact that these changes are all related to user privacy should tip you off to how important user privacy is to Apple (and hence to you)!

1. -[UIDevice uniqueIdentifier] is no more

Apple has always taken the privacy of users quite seriously. -[UIDevice uniqueIdentifier] was originally deprecated on iOS 5, but iOS 7 drops it altogether. Xcode 5 won’t even let you compile an app that contains a reference to -[UIDevice uniqueIdentifier]! Additionally, the behavior of pre-iOS 7 apps that use -[UIDevice uniqueIdentifier] has changed on iOS 7: instead of returning the device’s UUID, this call returns a string starting with FFFFFFFF, followed by the hex value of -[UIDevice identifierForVendor].

2. UIPasteboard as shared area is now sandboxed

UIPasteboard is used to share data among apps. While that isn’t an issue in itself, a problem arose when developers started to use it to store generated identifiers and share the identifiers with all other interested apps. One library using this trick is OpenUDID.

In iOS 7, pasteboards created with +[UIPasteboard pasteboardWithName:create:] and +[UIPasteboard pasteboardWithUniqueName] are now only visible to apps in the same application group, which makes OpenUDID much less useful than it once was.

It’s still fine to use this kind of Mac though

It's still fine to use this kind of Mac though

It’s still fine to use this kind of Mac though

3. MAC addresses can’t be used to identify a device

Using the iOS device’s Media Access Control (MAC) address was another common approach to generate unique identifiers on iOS devices. A MAC address is a unique number assigned to the network adapter at the physical network level. Apple has alternate names for this address, such as “Hardware Address” or “Wi-Fi Address” in some cases, but these terms all refer to the same thing.

A lot of projects and frameworks used this approach to generate unique device IDs, such as ODIN. However, Apple doesn’t want anyone to potentially identify a user by their MAC address, so all calls to retrieve the MAC address on iOS 7 return 02:00:00:00:00:00. That’s it. No crying. Put those tears away.

Apple made it pretty clear that you should use -[UIDevice identifierForVendor] or -[ASIdentifierManager advertisingIdentifier] as unique identifiers in your frameworks and applications. Frankly, it’s not all that hard to implement these changes, as shown in the code snippet below:

NSString *identifierForVendor = [[UIDevice currentDevice].identifierForVendor UUIDString];
NSString *identifierForAdvertising = [[ASIdentifierManager sharedManager].advertisingIdentifier UUIDString];

Each of these approaches is best suited to a specific use case:

  • identifierForVendor is a value that is unique to the vendor; that is, all apps released by the same company running on the same device will have the same identifier. However, this value will change if the user deletes a vendor’s apps from their device and later reinstalls those same apps. So this scheme isn’t persistent.
  • advertisingIdentifier returns the same value to all vendors running on the same device and should only be used to serve up advertisements. This value too may change in some scenarios, such as when the user erases the device.

You can read more about the various approaches to in this post written by Ole Begemann.