“Developer Tools Access is trying to take control of another process. Type your password to allow this.”

Open up a Terminal and try

sudo /usr/sbin/DevToolsSecurity –enable

Hopefully you end up with a console message along the lines of

“Developer mode is now enabled.”

This resolved the prompt issue for me … thanks to kenster for his post on stackoverflow.

I have been working on an application that makes use of multiple UIWindows within its view heirachy, mostly because it is quite a secure application and so the easiest way for us to block access to the app is to present a UIWindow above all other windows in the app.

Happy day scenario (VoiceOver disabled):

I am currently presenting a UIAlertView to the user and for whatever reason the app gets interrupted and goes into the background.  When this happens I put up our UIWindow (lets call it our security window) so you can no longer interact or see any part of the app, including the currently displayed alert.

When the user resumes the app from the background the security window is displayed and functions as expected.  We can dismiss it and low and behold our UIAlertView is there and we are all happy.

Accessibility scenario (VoiceOver enabled):

Same as before we present a UIAlertView to the user (accessibility does its thing and reads it out) and for whatever reason the app gets interrupted and goes into the background.  When this happens I put up our security window so you can no longer interact or see any part of the app, including the currently displayed alert.

Now when the user resumes the app from the background the security window is displayed and is interactive as expected however the UIAlertView that is displayed but not seen is actually read out!!!  This is really annoying because you cant interact with that alert view and you can’t see it.

My observations regarding how iOS handles UIAlertViews when VoiceOver is enabled

It appears to me that regardless of the windowLevels you set on your windows, if you are displaying a UIAlertView anywhere in your app and you cover it with a UIWindow and resume from the background.  Apple take the initiative and assume that the UIAlertView is super important so they read it out using something like

UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, <Text from UIAlertView>);

even though you can not actually see the UIAlertView or interact with it for that matter!

Furthermore I noticed that when the app resumes from the background if there is any UIAlertView it will make it the keywindow whilst VoiceOver is running and once it has finished reading out the alert it is more than happy to resign itself again.

If anyone has any further insight into this issue drop me a line as I would be interested to know how if at all possible you managed to resolve this issue.

Why would I want to use multiple UIWindows?

Well I guess a couple of the reasons would be that maybe you want to display a view that shows above system UIAlertViews, can cover the default keyboard or even make your app look like it is modifying the statusbar like Reeder.

Another great reason could be that you want to cover everything on your iOS application before it is placed into the background so that no screenshot can be taken of sensitive data, if you have any of course.

Getting started with using multiple UIWindows

UIWindows are simply special UIViews that can have their display order controlled via the windowLevel property.  You dont need to add a UIWindow as a subview of any other view.  By simply creating a new UIWindow and calling either [window setHidden:NO] or [window makeKeyAndVisible] depending on the level you gave it it will most likely appear on your screen.

All iOS apps start off with a UIWindow that you normally know as the [UIApplication sharedApplication].keyWindow or [UIApplication sharedApplication].delegate.window, this is the window where you normally set a window.rootViewController and from that point on you normally just deal with UIViewControllers.

There are 3 default window enum levels defined which are:

UIWindowLevelNormal
UIWindowLevelStatusBar
UIWindowLevelAlert

If you wanted to create a window that displayed above the statusbar but underneath UIAlertViews you could create a window with a windowLevel of UIWindowLevelStatusBar. If you wanted to create a window that sat above everything in your app you could simply set it to something like window.windowLevel = UIWindowLevelAlert + 1 would be fine.

Benefits I have found with using multiple UIWindows

1. It is super simple to display a view above everything else on your screen.
2. You can create your own custom UIAlertViews or Progress Overlays that can sit above everything else.
3. Allows you to hide sensitive data quickly when your app is moving to the background.  Before you app moves to the background simply put up a UIWindow that covers the whole screen, this will stop iOS from taking a screenshot and saving it on your device … of course this is only a concern for the extremely paranoid.

Some issues / gotchas you might run into when using your own UIWindows

1. You have to handle any rotation events manually.  Your custom UIWindows will not get any rotation notifications you must subscribe to these yourself and layout your window for the given orientation manually.
2. If another window in your application has a higher window level than your and your not in a position to change it well there is nothing you can do, your window will simply not appear above it.
3. UIAlertViews and UIActionSheets are displayed on the level of UIWindowLevelAlert, if you need to cover them up keep this in mind.
4. UIPopovers seem to appear on the UIWindowLevelStatusBar, alerts still appear over UIPopovers so this makes sense.
5. UIAlertViews have their own special window which can be a pain in the arse which I will go into more detail in a follow up post.
6. When you make a UIWindow the keyWindow it means it will become the first responder for the ios keyboard etc.

There are plenty of posts out there that cover simply using the Keychain but not that many cover sharing data between apps.  So that is exactly what this post will be about.  Sharing data between your iOS apps via the Keychain.

Creating your first app that will write to the Keychain

Setting up your project

1. Add the Security.framework to your project
2. Download UICKeyChainStore and add the files to your project
3. Create a new Entitlements.plist file and specify a keychain group you want to write to in this case we will just specify our apps bundle identifier.
• 
• $(AppIdentifierPrefix)$(CFBundleIdentifier) this will be resolved to your app Identifier prefix (aka bundle seed identifier) and your bundle identifier which is from your Info.plist.
• For this example assume the value is $(AppIdentifierPrefix).com.my.firstapp
4. Browse to your current app Targets Summary tab. Scroll down the bottom and you will see a section called Entitlements specify your Entitlements.plist file and make sure Enable Entitlements is checked.

Saving data and reading data from the Keychain

Now all you need to do is start using the UICKeyChainStore and you’ll be saving data to the Keychain.

[UICKeyChainStore setString:@"supersecret" forKey:@"password" service:@"MyService"];

[UICKeyChainStore stringForKey:@"password" service:@"MyService"];

Specifying the service allows you to store keys for a particular service, maybe you have a Twitter or Facebook specific set of keys you wish to save.

As you can see we are not specifying the accessGroup. By default it will pick the first access-group specified in your Entitlements.plist when writing and will search across all access-groups when none is specified.

Allowing your second app to access your shared keychain data

So we have our first app which is saving data to the keychain group ($(AppIdentifierPrefix).com.my.firstapp) Now lets just say we decide to release a second app but we dont want users to have to re enter the same data, maybe we are persisting a login token or something so we want to try and read it if the user has our first app installed.

All you have to do to in order to be able to read from a shared keychain group is make sure both your apps use the same AppIdentifierPrefix and specify the keychain group of the keychain you want access to.

All apps that share the same AppIdentifierPrefix / Bundle Seed Id can access each others Keychains if permission has been granted in your Entitlements.plist file.

Setting up your project

1. Add the Security.framework to your project
2. Download UICKeyChainStore and add the files to your project
3. Create a new Entitlements.plist file and specify the keychain group of the first app you want to be able to read data from.
• 
• We want access to the Keychain group $(AppIdentifierPrefix).com.my.firstapp for reading but we still want the default writing to occur in our own keychain group so we still specify $(AppIdentifierPrefix)$(CFBundleIdentifier) as the first / default group.
4. Browse to your current app Targets Summary tab. Scroll down the bottom and you will see a section called Entitlements specify your Entitlements.plist file and make sure Enable Entitlements is checked.

Reading data from the shared Keychain

Try and read the value from the shared Keychain exactly how we did in our first app.

[UICKeyChainStore stringForKey:@"password" service:@"MyService"];

This should return the value supersecret.

Congratulations you just successfully shared some data between two different iOS apps via the Keychain!

For more details checkout:

Generic Keychain Example

Keychain Services Programming Guide

A couple of months ago I was doing some iOS work at Sensis with regards to the Yellow Pages iPad app + SAPI integration. Rochana Attale and I needed to come up with a way to make it easy to hook up UI Automation acceptance tests written in Jasmine to our Jenkins CI environment.  Please keep in mind at the time the zucchini testing framework wasn’t released which is why we put together our own solution.

And to be fair what we put together has worked out quite well.  It is a bit rough around the edges but at the same time extremely quick to get acceptance tests up and running.

Acceptance tests are critical for any application which is intended to be around for a while, and they are even more important if your intending to make some major changes (such as swapping out a backend API … which is what we did on Yellow iPad). So before we started making any massive changes to our app we wanted to find a way to automate the UI testing of our iOS application and ideally hook it up to jenkins.

Hopefully you find this post useful, as we were surprised as to how quick writing the tests were once you had your environment up and running. At the end of the day its only UI Automation with some BDD love via Jasmine.

Download the example projects

I have created 2 projects, one for writing / running our acceptances tests and the other is the app which our tests will run against.

So go ahead and clone the following two projects from github into the same parent directory:

jasmine-ios-acceptance-tests
Make sure you remember to run git submodule update –init to grab the jasmine-reporters dependency.

jasmine-ios-acceptance-tests-basic-app
Build and run the app to make sure it is running in the simulator correctly.

Running the tests in Instruments

Firstly we will run our acceptance tests in Instruments so you can see how easy it is.

1. Make sure you have Xcode 4.2 installed as a minimum.
2. Start Instruments
3. Select the Automation template and click Choose
4. Select the Choose Target drop down -> Choose Target -> Choose Target…
5. A prompt will appear. Browse to the location of the BasicApp.app file and click Choose. For example mine is located at: /Users/shaune/dev/blog/jasmine-ios-acceptance-tests-basic-app/build/Debug-iphonesimulator/BasicApp.app 
6. Now back to the Instruments window on your left hand panel you should have a section called Scripts under it is a drop down button called Add. Click Add -> Import…
7. Browse to the location of our ci.js file and click Open. For example mine is located at: /Users/shaune/dev/blog/jasmine-ios-acceptance-tests/ci.js
8. Now that we are all setup you should be able to click the little red button to launch the simulator and see our tests running.

Running the tests from the command line

Also checked in is a basic shell script that you can use to kick off the acceptance tests from the command line OR from a Jenkins job.

$ ./runTests.sh ci.js “/Users/shaune/dev/blog/jasmine-ios-acceptance-tests-basic-app/build/Debug-iphonesimulator/BasicApp.app”

Hopefully the output you see is: Build Passed

Viewing test results in Jenkins

To add this to Jenkins simply setup a new unix shell job and execute the runtTests shell script with your own test script + app.

If you now look in your jasmine-ios-acceptance-tests directory a new directory called test-reports has hopefully been created with a test-results.xml file.

All you need to do is now add this into Jenkins for your acceptance test job to look for JUnit reports and you will then be able to see your Jasmine + UI Automation acceptance tests reports in Jenkins!

Super simple… but gets the job done

Keep in mind that our solution is quite simple, but it was super quick to integrate with Jenkins and it works. Also I found that writing the Jasmine specs were really quick and using the script recorder in Instruments does half the job for you.

What would I like to change?

I would like to update the jasmine.uiautomation_junit_reporter.js so that it actually writes the test-reports/test-results.xml file instead of simply logging it and having the runTests.shfile grep for the output. This could be done via the UIAHost.performTaskWithPathArgumentsTimeout call that can execute system commands.

Still hungry for other test frameworks?

If you are serious about setting up acceptance tests for your iOS application you should really consider checking out zucchini as well. It came out after we had already setup our acceptance test environment and is quite polished. It gives you the ability to write Gherkin’ish feature files and image comparison for verifying successful scenarios. If you have a UX team on board this will be ideal because you can test down to the pixel!