Home > Articles > Mobile Application Development & Programming

  • Print
  • + Share This
This chapter is from the book

Adding Device Capability Restrictions

An application’s Info.plist property list enables you to specify application requirements when you submit applications to iTunes. These restrictions enable you to tell iTunes what device features your application needs.

Each iOS unit provides a unique feature set. Some devices offer cameras and GPS capabilities. Others don’t. Some have onboard gyros, autofocus, and other powerful options. You specify what features are needed to run your application on a device.

When you include the UIRequiredDeviceCapabilities key in your Info.plist file, iTunes limits application installation to devices that offer the required capabilities. Provide this list as either an array of strings or a dictionary.

An array specifies each required capability; each item in that array must be present on your device. A dictionary enables you to explicitly require or prohibit a feature. The dictionary keys are the capabilities. The dictionary values set whether the feature must be present (Boolean true) or omitted (Boolean false).

The current keys are detailed in Table 1-1. Only include those features that your application absolutely requires or cannot support. If your application can provide workarounds, do not add restrictions in this way. Table 1-1 discusses each feature in a positive sense. When using a prohibition rather than a requirement, reverse the meaning—for example, that an autofocus camera or gyro cannot be onboard, or that Game Center access cannot be supported.

Table 1-1. Required Device Capabilities

Key

Use

telephony

Application requires the Phone application or uses tel:// URLs.

wifi

Application requires local 802.11-based network access. If iOS must maintain that Wi-Fi connection as the app runs, add UIRequiresPersistentWiFi as a top-level property list key.

sms

Application requires the Messages application or uses sms:// URLs.

still-camera

Application requires an onboard still camera and can use the image picker interface to capture photos from that still camera.

auto-focus-camera

Application requires extra focus capabilities for macro photography or especially sharp images for in-image data detection.

front-facing-camera

Application requires a front-facing camera on the device.

camera-flash

Application requires a camera flash feature.

video-camera

Application requires a video-capable camera.

accelerometer

Application requires accelerometer-specific feedback beyond simple UIViewController orientation events.

gyroscope

Application requires an onboard gyroscope on the device.

location-services

Application uses Core Location of any kind.

gps

Application uses Core Location and requires the additional accuracy of GPS positioning.

magnetometer

Application uses Core Location and requires heading-related events?that is, the direction of travel. (The magnetometer is the built-in compass.)

gamekit

Application requires Game Center access (iOS 4.1 and later).

microphone

Application uses either built-in microphones or (approved) accessories that provide a microphone.

opengles-1

Application requires OpenGL ES 1.1.

opengles-2

Application requires OpenGL ES 2.0.

armv6

Application is compiled only for the armv6 instruction set (3.1 or later).

armv7

Application is compiled only for the armv7 instruction set (3.1 or later).

peer-peer

Application uses GameKit peer-to-peer connectivity over Bluetooth (3.1 or later).

bluetooth-le

Application requires Bluetooth low-energy support (5.0 and later).

For example, consider an application that offers an option for taking pictures when run on a camera-ready device. If the application otherwise works on pre-camera iPod touch units, do not include the still-camera restriction. Instead, use check for camera capability from within the application and present the camera option when appropriate. Adding a still-camera restriction eliminates many early iPod touch (first through third generation) and iPad (first generation) owners from your potential customer pool.

User Permission Descriptions

To protect privacy, the end user must explicitly permit your applications to access reminders, photos, location, contacts, and calendar data. To convince the user to opt-in, it helps to explain how your application can use this data and describe your reason for accessing it. Assign string values to the following keys at the top level of your Info.plist file. When iOS prompts your user for resource-specific permission, it displays these strings as part of its standard dialog box:

  • NSRemindersUsageDescription
  • NSPhotoLibraryUsageDescription
  • NSLocationUsageDescription
  • NSContactsUsageDescription
  • NSCalendarsUsageDescription

Other Common Info.plist Keys

Here are a few other common keys you may want to assign in your property list, along with descriptions of what they do:

  • UIFileSharingEnabled (Boolean, defaults to off)—Enables users to access the contents of your app’s Documents folder from iTunes. This folder appears at the top level of your app sandbox.
  • UIAppFonts (Array, strings of font names including their extension)—Specifies custom TTF fonts that you supply in your bundle. When added, you access them using standard UIFont calls.
  • UIApplicationExitsOnSuspend (Boolean, defaults to off)—Enables your app to terminate when the user clicks the Home button rather than move to the background. When enabled, iOS terminates the app and purges it from memory.
  • UIRequiresPersistentWifi (Boolean, defaults to off)—Instructs iOS to maintain a Wi-Fi connection while the app is active.
  • UIStatusBarHidden (Boolean, defaults to off)—If enabled, hides the status bar as the app launches.
  • UIStatusBarStyle (String, defaults to UIStatusBarStyleDefault)—Specifies the style of the status bar at app launch.
  • + Share This
  • 🔖 Save To Your Account