How to Check Bluetooth Headphone Battery Status Using iOS 9

Problem to be solved:

You’ve got your awesome Bluetooth headphones but you don’t remember how long it’s been since you charged them.  You hate to go out for a run or cycle and halfway through get that dreaded battery low alert.  In iOS 9 for iPhone, iPod Touch and iPad, you can quickly find the battery status of any Bluetooth connected device including the Apple Watch, Bluetooth headphones and speakers and even the phone itself.

Credit to Bart Busschots of for showing this to me.

Continue reading “How to Check Bluetooth Headphone Battery Status Using iOS 9”

How to Enable iCloud Photo Library

This tutorial will show you how to have all photos in their original size you take on your iOS devices to be uploaded to the iCloud and downloaded to your Mac. It will also enable all photos in an optimized size to be moved onto your iOS devices.  With this scheme you won’t run out of space on your iOS devices ever again, hopefully.  I’ve tested this with a 300GB+ photo library!

First check the size of your Photos Library, (Get Info on Photos Library in your Pictures folder).  You will need ot know this to figure out how much storage you will need in the cloud.

This process will use a lot of data, so it is suggested you perform these steps while on an Internet connection that doesn’t cost you a lot for data transfer.

Continue reading “How to Enable iCloud Photo Library”

Checklist to Limit Data Use on Travel (Updated)

Problem to be solved:

I have a shared data plan between my Mifi and my iPad. Under normal use at home I never go over my 4GB plan (not even close) but about 2 days into a vacation I get a 75% usage warning. I had Katie Floyd of the Mac Power Users Podcast on the NosillaCast Episode #448 to help me figure out the root causes and how to control my usage on travel.  These instructions are the checklist she helped me create to best manage my data. Your mileage my vary but I’m betting at least some of these ideas will help you too.

I updated this checklist in August 2015 to include new items that run automatically that could be the cause of significant data usage. In this post I recommend a tool called TripMode from to monitor and limit network access by application: Can TripMode Demystify My Massive Network Data Usage?

Continue reading “Checklist to Limit Data Use on Travel (Updated)”

How to Play Content from Your iOS Device On Your Mac

Have you ever wished you could play content living on your iOS device over on your Mac?  Maybe you have music on your phone or a podcast or even a video you’d like to play through the better speakers on your Mac.  If you’re running Yosemite, you have a new version of QuickTime that will let you do just that.  A new feature introduced in QuickTime 10 allows you to make screen recordings of your iOS device, and using some of that functionality we can trick it into simply playing the content from iOS to our Macs.

Continue reading “How to Play Content from Your iOS Device On Your Mac”

How to Recover Your Voicemails from an iOS Backup on a Mac (for free)

After the move to an iPhone 6/6+ many people lost their voicemails. If you have a backup made from your previous phone, this quick technique will bring them back.  Mike Reyes figured this out and wrote short Terminal only instructions, so for people a little less comfortable in the Terminal, here’s a visual guide.  Mike’s original explanation is here: if you’d like the short and concise version!

Continue reading “How to Recover Your Voicemails from an iOS Backup on a Mac (for free)”

How to Disable Auto-Play Videos in Facebook

Recently Facebook decided that we wanted our feeds littered with auto-playing videos.  The only saving grace is that the audio doesn’t also play but it’s still distracting and annoying to many of us. Luckily, there’s a switch to turn it off from the web-version of Facebook, and in a completely different place to turn it of for iOS.  This quick tutorial will show you how to stop the madness!

Continue reading “How to Disable Auto-Play Videos in Facebook”

Activity Monitor for iOS Using Instruments in Xcode

Activity Monitor is a great utility on the Mac to monitor what applications and services are chewing up CPU cycles, energy hogs, and other things that might slow your Mac down. in this tutorial, I’ll show you how to engage a version of Activity Monitor to track your iOS device. My particular interest in using Instruments was to see if I could figure out why my iPhone was chewing up battery while it was asleep. With Instruments I was able to monitor my device and it’s processes while it was sleeping.

Prerequisite: Download and install Xcode first from the Mac App Store:

Note that this download is more than 2GB.

Continue reading “Activity Monitor for iOS Using Instruments in Xcode”

How to Build Accessible iOS Apps

These notes were created by Donald Burr of Otaku No Podcast from Donald was the guest on episode #364 of the podcast. If you’d like to listen to the audio as you read along, click the link below:

Donald Burr on Accessible App Development

How to Build Accessible iOS Apps by Donald Burr

When the iPhone first came out, people assumed that the blind wouldn’t be able to use it because it’s a touchscreen device with only 4 buttons. Apple proved them wrong. They have embraced accessibility in a BIG way. The iOS platform is the industry leader in mobile accessibility. Android, Windows Mobile, Blackberry, etc. don’t even come close. That’s why I’m a Mac/iOS user – my vision has fortunately remained stable, but I am always afraid that things might take a turn for the worse… but if they do I am ready for it

When talking accessibility, what are we talking about?

Primarily will be talking about accessibility for the visually impaired, because that’s the one that requires the most effort from developers. There are some considerations for other disabilities which I will briefly touch on later.

Basically each thingie on screen (button, text field, label, icon, etc.) has certain attributes that the Accessbility API’s need:

  • Is it an accessibility element? (Should VoiceOver be able to “see” it and recognize its existence?) (isAccessibilityElement)
  • What is it? (accessibilityLabeland accessibilityHint)
  • What are its traits? (accessibilityTraits)
  • Type of item (static text, button, image, adjustable control, etc.)
  • Is it clickable (can you interact with it)?
  • If it’s a selectable object, is it currently selected?
  • Does clicking on it start some sort of media playback (audio/video)?
  • If it’s an adjustable control, what is its current value? (accessibilityValue)
  • What are its on-screen coordinates? How big is it? (accessibilityFrame)
  • Here’s the good news: Apple makes it really easy to make your apps accessible. They provide a very rich set of tools and APIs that help with this. Which means you have absolutely positively NO excuse not to! In most cases, all it invokes is literally just a few extra lines of code, and poof, instant accessibility. In some cases, no coding is required at all.

    Standard UI elements:

    • One of the great things about developing for iOS is Interface Builder – you can piece together your program’s UI by dragging and dropping from a large palette of UI widgets (text labels, buttons, sliders, etc.)
    • If you use these standard interface elements – guess what – the system automatically makes them accessible. Since Interface Builder knows what it is you’re putting on screen, it automatically fills in the necessary accessibility information.
    • Works best if your UI has obviously titled elements (i.e. a button titled “Play” that starts playing something).
    • Beware ambiguous labels (or controls that don’t have a label)!
    • Example: In the Otaku no Podcast app, in the Podcasts screen (first tab), there are entries for “Latest Audio Podcast” and “Latest Video Podcast.” Beside each is a “Play” button. It’s obvious to a sighted user what each Play button does; however, for a VoiceOver user, all they would hear if they tapped it is “Play” — play what??!
    • Example 2: In the Otaku no Podcast app, look at the Audio Player screen. The “play button” at the lower left uses the “play” graphic – no text label. In this case, since VoiceOver doesn’t have a text label to fall back on, it uses the filename of the image that the button is using. So you’ll hear something like “playbtn dot PNG” which is even worse!
    • In cases like this, we need to give iOS some more specific information.
    • In Xcode, highlight your UI element, then go to the Identity Inspector. There you will find a section on “Accessibility.”
    • “Enabled” – whether this item should respond to VoiceOver (You’ll almost always want this)
    • “Label” – What you want it to say (Example: for the “Audio Podcast -> Play” button I put “Play the latest audio podcast”; for the “play graphic” button I put “Play”)
    • “Hint” – This text is spoken after a short delay after the “label” is spoken. Useful to give the user additional information about this particular UI element. (Example: for the Refresh button, the button’s Label is “Refresh”, and its Hint is “Tap to check for new episodes…” – it gives the user some additional information if he/she is confused.)
    • “Traits” – Most of these options are very specialized, and you don’t want to go turning them on willy-nilly. Here are the important ones:
    • “Button” – is this a button?
    • “User interaction enabled” – can you “do” something with it? (I.e. tap a button, enter text into a text field, etc.)
  • You can still manipulate these values in code if you want (handy if e.g. you need to change your UI to respond to conditions when your app is running).
  • Some actual examples from the Otaku no Podcast app:
    Look at “OnP main screen – play latest button,” “OnP main screen – refresh button,” and “OnP player screen – graphical play button”
  • Custom UI elements

    • Sometimes the standard controls aren’t enough (you need more/different functionality); also sometimes you may use standard controls, but want to create and manipulate them in code (rather than using Interface Builder). In these cases, you will need to use code to set up all the necessary accessibility information.
    • All accessibility information can be set in code.
    • Example:
      Look at “adding to code 1” and “adding to code 2”

    Accessibility Containers

    • Sometimes you may have an object that is subdivided into multiple sub-objects. You need to provide accessibility information for those sub-objects.
    • Example: the Convention Calendar tab in the Otaku no Podcast app. The entire calendar view is a single object; each individual day is a sub-object. Unfortunately this is one area where I still need work; it is completely inaccessible. I’m using an open source calendar library that isn’t yet accessible. I’m working with the developer to add accessibility to it. For an example of this done right, take a look at the iPhone’s Calendar app, in Month view.
    • In this case, we use a series of “accessibility containers.”
    • Each container provides a full set of accessibility information to the OS (description/label, value, hint, etc.), as well as the bounds (the physical location/dimensions of the area where this accessibility information is attached to).
    • These elements are stored in an array (an ordered collection of objects). You need to provide three pieces of information to the Accessibility API’s: the number of items in this array, a way of retrieving a given item #, and a way of testing if a given item is part of the array. (In 99% of the cases, these will be trivial one-liners.)
    • Example:
      Look at “container code 1” and “container code 2”
      Another good (more real life) example can be found in the Use Your Loaf TaskTimer project (see below); look at theUYLCounterView.m file

    Accessibility Actions

    • If you are creating a custom adjustable control, you need to give VoiceOver information on how to manipulate its value.
    • VoiceOver has two standard gestures: swipe up (increases the value of something) or swipe down (decreases it).
    • So when coding your custom control, you need to create special “increment” and “decrement” code that VoiceOver can use to change its value.
    • A good example of this is the page turner in iBooks (the little dotted line with the box at the bottom that lets you quickly page through a book).
    • A third type of gesture is “scroll.” This is meant for a control that scrolls to a different part of your UI. Example: moving between home screens, or scrolling between cities in the Weather app.
    • Example:
      Look at “action code 1” and “action code 2”

    UI Changes

    • The iOS user interface is very dynamic. Things are moving around, morphing, swooping in and out, etc. Obviously blind users can’t see this. So iOS provides a way for developers to let the user know that “something happened” using VoiceOver.
    • There are three types of UI change notifications.
    • Screen changes: when your UI changes dramatically. Usually when a user moves into a different part of your app (navigates to a different screen). VoiceOver notifies the user with a tone, and it clears its caches and does other preparations to deal with a new set of accessibility data.
    • UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, nil);
  • Layout changes: if some part of your UI changes, but the user hasn’t necessarily jumped to an entirely different part of your app. (Example: in the iTunes Store app, tapping on the price label ($0.99, etc.) next to a song changes it to a “Buy” button.) This notification tells VoiceOver to re-read the current state of all accessible items that are on-screen, and by doing this it figures out what has changed and informs the user of those changes.
    • UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil);
  • Dynamic changes: if a part of your user interface is dealing with some dynamically changing information (state changes, data changes, etc.). This notification tells VoiceOver to read it out to the user. Example: in the Compass app, the compass value is constantly changing as the user moves his/her device in space. The Compass app sends a dynamic changes notification that tells VoiceOver to read out your current heading. Also useful for communicating any sort of significant status change in your app (“Loading complete,” “Connected to server,” etc.) You may only want to do this when a significant change in data has occurred, otherwise it can get real annoying. (for example, Compass only notifies when the compass value has changed by 5 degrees I believe.)
    • UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, @”Loading complete.”);

    VoiceOver-specific API

    • Sometimes it is useful to determine whether or not VoiceOver is running, and to do different things depending on whether it is or not.
    • A program can, at any time, test to see whether VoiceOver is enabled or not.
    • if (UIAccessibilityIsVoiceOverRunning()) {
      // VoiceOver is active; do something different
      }else {
      // VoiceOver is NOT active; do the usual thing (whatever that may be)
  • Also, programs can sign up for the system to notify them whenever the VoiceOver status changes.
    • [[NSNotificationCenter defaultCenter]addObserver:self selector:@selector(handleVoiceOverStateChange:) name:UIAccessibilityVoiceOverStatusChanged object:nil];
  • Your program can also tell where VoiceOver’s “focus” (the object that it’s dealing with) is, and when “focus” enters or leaves any given object.
    • accessibilityElementIsFocused
    • accessibilityElementDidBecomeFocused
    • accessibilityElementDidLoseFocus
  • A good use for this is, when a user is running VoiceOver, to present a more simplified UI to them, or otherwise change your UI to make it easier for VoiceOver users to interact with. Example: In the Photos app, the photo controls normally disappear after a few seconds to let you view the full image. This could be confusing to VoiceOver users; so if Photos detects that VoiceOver is in use, it prevents this auto-hiding behavior.
  • Testing Accessibility

    • Naturally, like any other aspect of software development, you’ll want to test your accessibility code.
    • In the iOS simulator
    • The iOS Simulator has a built-in Accessibility Inspector. It displays all the accessibility data of any given object on screen (just click on it).
    • Access it by pressing the virtual Home button, launching the Settings app (you might have to swipe right to get there), tapping on General, then Accessibility, then turn on the Accessibility Inspector.
    • Example:
      Look at “Accessibility inspector”
  • On real devices
    • Unfortunately the accessibility inspector doesn’t support certain actions (notably the swipe gestures that let you change values of controls). Also it doesn’t really give you a “feel” for how an actual blind user would interact with your app. For this you really need to test on real hardware.
    • To enable accessibility – Settings -> General -> Accessibility -> VoiceOver -> turn it ON.
    • A shortcut is to set up the triple-click home button shortcut: Settings -> General -> Accessiblity -> Triple-click Home -> set it to VoiceOver
    • If you’re feeling really brave, you can enable Screen Curtain (completely turns off the screen, the closest thing to actually turning yourself into a blind person, and much more comfortable than a blindfold (or poking your eyes out)). Just activate VoiceOver then triple tap using three fingers. Repeat to turn off screen curtain.
  • Of course, doing your own testing is fine (and indeed is essential), but you really should be sending your app out to others to test.
  • Miscellany

    • If you localize your app, you also need to localize your VoiceOver prompts! (VoiceOver is available in 30 languages)
    • If you’re not localizing, you really ought to. The App Store is global, why shut out a potentially huge user base? Getting translators is easy and relatively inexpensive (try Craigslist).
    • Remember that localization doesn’t just mean translating words and letters; some countries have different ways of expressing date/time, currency, etc. iOS has code that helps in these conversions.
  • It’s always good to think outside the box.
    • With clever use of the accessibility tools, you can make things accessible that you wouldn’t think were possible.
    • A good example is the Stocks app. You’d think that there is no way that the graph at the bottom could be made accessible. You would be wrong.
    • They used accessibility areas to slice up the graph. For each slice, it tells you a representative date within that period, and the stock price for that date.
  • Less is more.
    • Keep your labels short. Users are going to be scrolling through these dozens of times.
    • If you want to provide additional information, use an accessibility hint. (That way users only get the additional information if they actually need it)
  • The more buttons, interactive elements, etc. on a screen, the harder it is for a VoiceOver user to navigate it.
    • If you really want the fancy UI, check to see if VoiceOver is in use; if it is then present a simplified UI.
  • Do not include an object’s type (“button,” “slider,” etc.) in its accessibility label. iOS will automatically read out the item’s type itself, so there’s no need for you to do so also (besides it makes your app look amateurish).
  • Remember that there are other disabilities besides blindness.
    • Physical Disabilities:Try not to make your UI teeny tiny. Of course this makes it more difficult for sighted people to use your app. But it becomes orders of magnitude worse when you throw physical disabilities into the mix(motor control difficulties, CP/MS, or people who use a head-mounted pointer, etc.) It also makes it harder for visually impaired (but not completely blind) users to see your app as well. IMHO this might be a compelling argument for a larger-screened iPhone (more space to spread out your UI in).
    • Deaf/Hard of Hearing: Some programs use sounds to indicate that something happened. It’s always a good idea to also include some sort of visual feedback as well, for those who are deaf/HOH.
  • Use standard controls (text entry fields, buttons, etc.) whenever possible. Not only is this good for usability (users know what an iOS text box/button/on-screen keyboard/etc. look like, they may not be able to instantly recognize your weird nonstandard UI); but using standard UI elements also gives you the highest level of compatibility with alternative input devices (head pointers,braille displays/keyboards, etc.). (Bad example of this is Mac OS Ken’s Secret Crypto Wonder Badge. Totally nonstandard keyboard.)
  • Resources

    The obligatory plugs section

    • Check out my iOS apps!
  • My portal site – links to everything I do, as well as houses my blog.
  • I’m on twitter as
  • And finally, if you are at all interested in Japanese animation (Anime), comics (Manga), food, travel, culture, etc., check out my podcast, Otaku no Podcast.
  • Scroll to top