Only companies with small armies of testers and voluminous device libraries can hope to put a dent in the mountain of device and OS combinations out in the wild. Those of us in the trenches without such luxuries need to prioritize. After considering platform and OS support requirements, the next step in paring down the choices is to know the target audience. Who are you or your client attempting to reach? Tech-savvy early adopters staking out a place in line for the latest iDevice, or perhaps parents who retain their progeny on permanent IT duty? Whatever the target, it’s likely to help shift your focus toward either latest and greatest or legacy device support.

Knowing these basic criteria helps immensely in picking devices to focus on. While this varies from project to project, below is a list some of the devices we use and the reasons we keep coming back to them for testing.

The best device is the one you have.

The first and perhaps most obvious choice is to use your personal device. Hopefully if you’re testing apps you’ll be at least somewhat up to date with your hardware, and unless you’re testing software that could brick your daily, this is the easiest selection to make. You’ll be most familiar with the device you use every day, you know how long on average it takes to do things and because of this familiarity you’ll be able to spot issues rather quickly.

iPad 1 – iOS 5.1.1

The Apple crowd is often seen as the party of early adopters, quick to abandon old devices. However, this behavior is often aided by carrier subsidized upgrade perks which are largely unavailable for tablets. Even those who upgrade their phones like clockwork will find less incentive to update their tablet. In addition, as these devices still work well for many users they often find a second life as a hand-me-down. Aside from these demographic considerations, this is also a good device for testing UI responsiveness and application speed. Your application will reach its limits quickly on an iPad 1 and can provide early indication of where optimization may be needed.

iPad – 4th Generation

Always test your app to make sure it looks and runs great on the latest and greatest out of Cupertino. Don’t let those fancy Retina displays go to waste.

iPhone 5

The most obvious difference between the iPhone 5 and its predecessors is the extra screen real estate. UIs that have been designed for previous iPhones can sometimes look a little caddywompus on the 5. The anchoring and sizing of UI elements can cause an app’s appearance to differ between phones, and functional items such as how far drawers expand or what data is visible before scrolling may need some revisiting after being viewed on the larger screen.

iPhone 3GS

like the iPad 1, the longest running iPhone sold by Apple provides a good way to test for performance inefficiencies. The 3GS also has support for more iOS versions than any other iPhone, making the 3GS a great device on which to test your minimum supported iOS version.

Google Nexus device family

Co-developed by Google and various OEMs, the Nexus family of devices represent what Android should look and act like according to Google. With Android it can be easy to back yourself into the corner of writing support for specific devices, especially if a representative of your client has a particularly finicky device they are keen on having supported. However, if your app works on these devices, it’s likely to work elsewhere, and if it doesn’t, it is likely not your fault.

Amazon Kindle Fire, 2nd gen

While Amazon is mum about their user demographics, some independent research shows the Kindle demographics trending more towards female and older users than the iPad. In addition, the Kindle attracts more price-conscious users, so apps focused on frugal folks would do well to be deployed in the Amazon Appstore. This device also provides a way to test the Amazon Appstore, one of several departures the Kindle makes from vanilla Android tablets. Aside from the different app store, the Kindle OS is forked from regular Android and includes other differences such as the cloud-enhanced Silk browser and a different UI. One should not expect their app to run flawlessly on a Kindle without testing.

HTC EVO 4G – Android Gingerbread(2.3.3)

As almost half of Android users are still using Gingerbread, it’s a very good idea to keep a device hanging out with good old API level 10. The EVO 4G saw wide distribution during its deployment and is our go-to device for testing apps on an aging Android. In addition, many of these devices are still kicking around, and your app is likely to find a home on an EVO somewhere. This is also a great opportunity to find bugs related to the old version of HTC Sense that will inevitably pop up in production.

Samsung Galaxy Note

This family of comically large phones is gaining wide popularity, and while it may look odd to see someone smaller than LeBron James actually using one to make phone calls, it makes testing Android phone issues a bit more convenient.

With the device landscape ever changing, this list is sure to be obsolete in short order. Even so, I hope the reasons these devices were selected will help alleviate some initial testing paralysis well into the future.

The post QA Tool Belt: Our Testing Devices appeared first on Double Encore.

From a marketing and interaction perspective, Second Screen holds a lot of promise.  Being able to “sync” the two devices together, having a call-to-action on the TV screen to push deeper interaction on a tablet or smartphone, is a great avenue to extend exciting new functionality, tools, info and offers to consumers.  This is a great approach for consumer loyalty, something that mobile is well-suited to tackle.

The syncing of mobile devices and TV is still in its infancy and not overly user-friendly.  Auto Content Recognition, also known as ACR, has emerged as the primary way to sync the two screens together.  Essentially, ACR technology on a mobile device listens to what is playing on the TV screen and attempts to ‘sync’ and display the appropriate information.  Unfortunately, the technology is not inherently user-friendly, but app developers currently don’t have any better options at their disposal.  This issue, in my mind, could very well be stifling the evolution of Second Screen as a whole.

Today, apps like ConnecTV, zeebox and IntoNow are utilizing ACR to sync social conversation and additional content to your mobile device, based on what show, movie or game you are watching. While this approach provides the best syncing options readily available today, I don’t feel ACR is the permanent solution for Second Screen and its users.  For example, for ACR to work consistently, a room has to be relatively quiet, the app has to be opened and ready to sync, and every time you turn the channel, the user has to be prepared to resync to the new channel.  There’s entirely too much demand placed on the user during a lean-back, relaxed experience to make Second Screen work for the long-term.  Second Screen needs to cater more to the ‘lean-back experience’ that the living room is known for.

In my mind, there are three fundamental issues that need to be remedied to make Second Screen more user-friendly:

1. ACR needs to be replaced with direct integration between mobile devices and set-top TV boxes to provide an ideal and accurate user experience.  As I briefly mentioned in my previous Second Screen article, opening up set-top box API’s to Second Screen app developers is huge step in evolution for user experience. By opening up these API’s, Second Screen apps can communicate directly with the box to figure out what is playing, without any user input or dependency. Regardless if you flip between channels, play some DVR’ed content or just channel surf for an hour, your mobile device will always and automatically be synced with what’s on the TV. It also provides an ideal route into our next point, intra-episode syncing, which allows the two screens to be synced to the second.

2. Syncing needs to happen at an intra-episode level. Many Second Screen apps focus on syncing to the episode level right now, a teaser on tonight’s plot or new character for instance, but that is about it. This is one huge problem for the vertical right now, it provides a one-time burst of useful info that lasts about thirty seconds but nothing more to draw you back into an app. Intra-episode syncing and content is where the true value of Second Screen resides. Users want content or interaction based on what is happening on the TV that second. Ideally, it’s using the mobile device to interact with the programming by participating in a real-time poll, quiz or contest based on what the user just saw.  In the future, focusing on this could even open the door to “choose your own ending” approaches, a Holy Grail for Second Screen offerings.

3. App developers need to get away from automated or pre-programmed premises that determine what content to display on the Second Screen. Some apps are trying to sync at the intra-episode or intra-game level, but most are experiencing one large roadblock: Live, linear television is unpredictable, and using automated curation will provide an experience that is neither deep nor accurate. For example, using one ACR-based application while watching an NBA game on TNT, I was constantly being given information on the weather in Miami, simply because the automated ACR premise could not decipher between the different types of “Miami Heat.”

This is one consistent problem from Second Screen apps that are trying to tackle intra-episode syncing…content accuracy.  Knowing the difference between November Rain from Guns N’ Roses and the November rain outside makes a huge difference in the type of interactions and content presented within a Second Screen app.  Furthermore, not being able to adjust your content based on what is happening on the TV screen can make your app look unresponsive and unprepared.

Just like tweeters who use automated approaches to tweet their content, every time there’s a breaking event that captivates us, like the Boston bombing, seeing tweets coming thru at that time about ‘how to increase your social media leads’ makes that tweeter look lazy and unprepared. Not being able to adjust the content in your Second Screen app when big unexpected events happen on TV will undoubtedly land you in the same predicament at some point. Proof in this can be found in last year’s Super Bowl when the power at the game abruptly went out.  Oreo cookies was on the ball, reactively changing their social postings to reflect this unexpected event. The amount of PR and praise that Oreo got for this approach should be an indicator on the value end-users find in responsive, reactive and accurate supporting content.

Social media is a content-driven space, and you don’t need automation; you need content experts driving your app. The Second Screen app that becomes the catalyst for the space will not rely on automation, it will have content experts guiding users through the synced two-screen experience. It won’t be an app auto-pulling high-level, Wiki-like info for a topic or person I’m watching on TV. Rather, it will be a live, interactive and responsive experience between an expert and fans focusing on what is happening that moment in the show or game.

For Second Screen to be more user-friendly, we largely have to get away from thinking technology can help us automate and manage content accurately.  The space is live and linear, and we need a living, breathing soul who can adjust appropriately to make this concept truly work.

The post Making Second Screen More User-Friendly appeared first on Double Encore.

Here are five reasons to take your engineering to higher altitudes:

1. Original Content Meets Technical Expertise

“Overall, our speakers are some of the best and brightest in the industry,” notes John Wilker, who runs Denver’s highly acclaimed iOS Developer Conference, 360iDev. Hand-picked by Wilker himself, the speakers not only must demonstrate their knowledge in the field, but also must propose a talk that is both useful and relevant:

“We try to avoid a common trap events fall into, and that’s the “speaker circuit,” where the same people present the same information at many events all year long. We emphasize original content from our speakers and make it clear that, if they’ve presented a topic at four other events that year, it’s not fresh or interesting, and we most likely won’t accept it.” – John Wilker, on 360iDev

2. The Price is Right

Colorado tech conferences tend to give you a lot of bang for your buck. “Every year people come to us on Monday and tell us that X session was worth the price of the conference… and that’s just Monday. They haven’t even gotten to Tuesday or Wednesday,” exclaims Wilker.

Some of the developer events are even offered for free, notably iOSDevCamp Colorado which oscillates between Denver and Colorado Springs. According to Saul Mora, who organized Denver’s most recent iOSDevCamp, “It’s a great way to encourage developers from all over to visit and attend, contribute, and become part of the community.”

Denver Startup Week, for example, paired up with Eventbrite to promote an impressive lineup of tech networking events at no cost to attendees.

3. Big Names When You Want Them…

Twelve years after its inception, Fortune Brainstorm TECH is returning to Colorado with some large names. Last year’s speakers came from:

Google, Sony, Disney, Qualcomm, Airbnb, Nest, Klout, LinkedIn, Facebook, Path, Zynga, Electronic Arts, Living Social, and Roku… just to name a few.

With three full days of sessions on four specialized tracks, Brainstorm TECH is a “hot ticket” for which you will pay $4,500.00 – if you get invited. Participation is by invitation only and subject to approval, making this one of the tech industry’s most exclusive events.

If you can’t get a golden ticket but still want to breathe the same air as a tech-lebrity, Denver Startup Week has you covered. Last year’s event packed a full house to see Gary Vaynerchuck. And, unlike Fortune’s $4,500 price tag, Denver Startup Week was willing to get you up close with the tech-superstar for the bargain price of free.

4. …Intimacy When You Don’t

So maybe the big names (or big crowds) aren’t for you. You’re looking for something a little more hands-on, a little more technical. Well, allow me to borrow some “Jobsian” rhetoric: there’s a conference for that.

360iDev boasts some multi-hour intensive sessions such as “Advanced Debugging,” a session in which attendees get much more technical than a typical one-hour lecture would allow. Attendees can also participate in Game Jam, a 13-hour development marathon during which engineers – solo, or with a team – build iOS games from scratch.

iOSDevCamp Colorado boasts an even more intimate format in which attendees not only participate in the forum, but also vote on the content they want to hear from the event’s speakers.

5. Community

Ask any conference host why they enjoy holding tech conferences in Colorado, and you’re sure to hear a familiar answer: Community. Referring to not just the speakers, but the attendees at iOS Dev Camp as well, Saul Mora boasts that “there is a vast resource of world class development skill right here in Colorado.”

Colorado keeps its tech community alive with weekly meetups and gatherings for the locals, but residents are eager to share the magic. “There’s a thriving tech scene in Colorado, as much or more than in places like Silicon Valley, New York, Seattle, etc. We wanted to give all these developers and companies a bit of home court advantage, as well as emphasize Colorado’s awesomeness,” said John Wilker, on returning 360iDev to its Colorado origins for the second year in a row.

And, just to give you an idea of how impactful the networking in this community can be, just last year we hired an impressive developer whom we first met at 360iDev’s 2011 conference.

What’s your experience with Colorado tech conferences? Do you have a favorite event? Let us know on facebook or twitter.

The post The Value of Colorado Tech Conferences appeared first on Double Encore.

Here’s one possibility:

CGFloat offset = 20.0f;

CGRect blueViewFrame = self.blueView.frame;
blueViewFrame.origin.x = self.whiteView.frame.origin.x + offset;
blueViewFrame.origin.y = self.whiteView.frame.origin.y + offset;
self.blueView.frame = blueViewFrame;

CGRect greyViewFrame = self.greyView.frame;
greyViewFrame.origin.x = self.whiteView.frame.origin.x + self.whiteView.frame.size.width - self.greyView.frame.size.width - offset;
greyViewFrame.origin.y = self.whiteView.frame.origin.y + self.whiteView.frame.size.height - self.greyView.frame.size.height - offset;
self.greyView.frame = greyViewFrame;

This works, but it’s a bit clumsy; it takes some studying to figure out exactly how the frames are being manipulated, and it doesn’t read naturally.

Here’s an easier way:

CGFloat offset = 20.0f;

self.blueView.deFrameLeft = self.whiteView.deFrameLeft + offset;
self.blueView.deFrameTop = self.whiteView.deFrameTop + offset;

self.greyView.deFrameRight = self.whiteView.deFrameRight - offset;
self.greyView.deFrameBottom = self.whiteView.deFrameBottom - offset;

Much better.  We’re now describing our view layout in far more expressive terms, and we’ve even trimmed out a few lines of code.

We’re able to do this by defining a category on UIView that exposes a set of new frame manipulation properties.  These properties serve as simple wrappers around UIView’s frame property, and getter and setter methods are defined for each of them.  They allow us to express frame manipulations on UIViews (and subclasses thereof) far more naturally, and with fewer lines of code.

The code for this category is available at this gist.  Snag it, drop it into your own projects, and let me know how it goes!

The post FRAMED: A UIView Category – Write Smarter Layout Code appeared first on Double Encore.

Promotion is a necessity in the mobile space as app stores were never designed as discovery vehicles.  With thousands upon thousands of apps hitting iTunes and Google Play every month, the process in which to discover these applications have failed to keep pace with the exponential amount of applications to choose from.

The reliance is on you and your team to push awareness of your mobile product.  While you will undoubtedly get SOME download traction by people stumbling on your app, this is not a recipe to generate much use, value, downloads or revenue.  Two-thirds of applications fail to reach 1,000 downloads in their first year, unless that sounds like a suitable goal, you really need to think above and beyond to get users to download and use your mobile product.

Over the past six years I have planned and executed many integrated mobile campaigns, and below is a method I’ve found to be most effective when wanting to generate awareness of your mobile application:

1.    First integrate into existing assets. Oftentimes your best marketing assets already exist elsewhere, in the form of websites, print material, video content, e-newsletters, etc.  Before you look at paid promotional routes, start here. Your existing assets should already be connecting with your audience. Look to your print, photo and video assets to integrate simple but eye-catching callouts of the app and location of app stores it can be found in.

2.   Seed the app to bloggers and Key Opinion Leaders (KOL’s). Many people look for social recommendations to download an app, and seeding your app as a pre-release to bloggers, journalists and other Key Opinion Leaders (KOL’s) can help push awareness via their portals to a targeted audience. Furthermore, allowing these KOL’s to have pre-release access to your app can provide a great foundation of feedback for your first application update.

3.   Look for ways to promote via mobile. Promoting in the space in which your product lives is an efficient way to generate conversions. Mobile, compared to desktop, is still cheap, effective, and productive when it comes to generating awareness and especially conversions (aka downloads). Oftentimes, you will find that the “one-click to download” proximity will generate upwards of 50% of your downloads, with over 30% of the people clicking on your mobile ads downloading your application. Large Mobile Ad networks like Google’s AdMob, Apple’s iAd, and ValueClick’s Greystripe can create full-screen Interstitials and target traditional mobile ads to a variety of mobile devices, platforms and carriers. Targeting in the space is improving, and using analytics services like Flurry can help you identify key behaviors and habits that might help one target more accurately on these mobile networks.

4.   Look for ways to promote via digital/social. Promoting via digital (and even social) routes can be another effective way to push awareness of your app. This route provides the most targeting options as everything from Nielsen profiling to re-targeting can be applied to push your apps’ availability to only your most targeted, high-indexed audience. While digital won’t get the conversions that mobile will, it is amongst the best ways to push awareness of your app. Over the decades, all marketing channels have shown a consistent premise: The more awareness you push, the more your product will be recognized and adopted by consumers.

Social is also another channel worth mentioning, as promoting your app’s availability via Facebook, Twitter and other networks can be a potent, targeted way to push downloads.  Caution should be used, however, as social media should NEVER be an extension of one’s marketing/advertising efforts, it should be used only as a channel to connect with customers, take their feedback, and inform them with the most valuable information.

5.   Don’t forget about print media. For all its sophistication, the best integrated marketing when it comes to mobile is often with traditional, “old-school” media. Print media, such as newspaper ads, posters, and brochures, is a great way to push awareness and visibility of your application. Unlike watching TV or listening to radio, reading commands a user’s full attention, so print ads can be very effective in pushing awareness in such a way that the consumer will retain the information for at least a short period of time. In a very controlled, thoughtful manner, print media can even use aspects like QR codes to help push conversions in the space as it allows a user to easily get the application on his/her phone.  While QR codes are not ideal mobile strategies in most areas, this approach is germane and proven.

Recent studies have shown that over 80% of apps in iTunes are considered “zombie apps,” meaning they aren’t downloaded, used, utilized nor rated. (See our recent article on this here) Make no mistake, failure to market and promote and app is one BIG reason why there are so many zombie apps.

The mobile space has become very competitive in recent years, and unlike 2008, one can’t make an app, put it in an app store, and just sit back and watch the downloads and revenue come in. Mobile today requires a good product AND a good plan to push awareness to your audience….it’s not an “either-or. “

The post The 5-Step Plan to Promote Your Mobile App appeared first on Double Encore.

A great example of this single completion block pattern from Apple’s own APIs is found in one of NSURLConnection’s newer async methods. The sendAsynchronousRequest method was added in iOS 5.0, and provides a single completionHandler argument to handle any result.

+ (void)sendAsynchronousRequest:(NSURLRequest *)request 
                          queue:(NSOperationQueue *)queue 
              completionHandler:(void (^)(NSURLResponse *, NSData *, NSError *))handler;

Collin’s article sparked the urge to do some refactoring. We have several internal libraries with async methods that are currently designed to have two, and in some cases even three, separate callback blocks. These libraries have been in use for a long time, and were originally designed to use delegation. With the delegation pattern, there is typically a one-to-one relationship between signal and outcome. For an example, we need look no further than NSURLConnection’s own delegate methods:

- (void)connectionDidFinishLoading:(NSURLConnection *)connection;
- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error;

When converting a library that uses delegation to blocks, or perhaps more importantly when adding blocks as an option to such a library, the path of least resistance is generally to add a block for every delegate method. This thinking leads to the pattern that Collin is arguing against.

// Classic delegation
- (void)myOperationDidSucceed:(id data) {
    [myView hideLoadingIndicator];
    // Do something with data
}

- (void)myOperationDidFail:(NSError *)error {
    [myView hideLoadingIndicator];
    // Do something with the error
}

- (void)myOperationDidReachAnotherOutcome:(NSDictionary *info) {
    [myView hideLoadingIndicator];
    // Do something with info
}

// Separate blocks
[myOperation startOperatingWithSuccess:^(id data) {
    [myView hideLoadingIndicator];
    // Do something with data

} failure:^(NSError *error) {
    [myView hideLoadingIndicator];
    // Do something with the error

} anotherPossibleOutcome:^(NSDictionary *info) {
    [myView hideLoadingIndicator];
    // Do something with info
}];

So what’s the harm? Having one signal per outcome has served us well for years. Why do we need to change now?

Stylistically, we’re talking about where to put the curly braces. Do you want to use them to encapsulate separate blocks, or do you want to use them for flow control within a single block? If this were the only concern, it would definitely be more of a personal preference issue. Inlining several blocks within an async task’s initialization method can get ugly (do you line up with the parameter colons, or with the indentation level?). On the other hand, so can several levels of conditionals. But beyond code formatting, in terms of nuts and bolts, we’re talking about efficiency, on several different levels.

Efficiency Begets Efficiency

As Collin notes, there are often common tasks that occur in both success and failure blocks. A good example would be hiding some loading UI or turning off the app’s activity indicator. This can result in duplicate code, or at least unnecessary abstractions. Having a single block means you only have to write that code once.

Having one block also means you have to do some value checking to determine what the final state of the async task was, and how to respond. Since you’re combining multiple outcomes into one signal, you need to determine the state before you act on it. One could argue that this results in unnecessary boilerplate code, but that’s only looking at one side of the API. In the multiple block pattern, the async task itself would likely use the same or similar logic to determine which block to execute. Moving that logic client-side can allow the task’s code to be written more efficiently, and can put the decision of “what to do next” more firmly in the client’s hands.

Let’s go back to that sendAsynchronousRequest method and look more closely at the completion handler:

+ (void)sendAsynchronousRequest:(NSURLRequest *)request 
                          queue:(NSOperationQueue *)queue 
              completionHandler:(void (^)(NSURLResponse *, NSData *, NSError *))handler;

Notice that the block is equipped to handle any result, and more importantly, almost any basic developer need. You get more than just data and an error. You get data, an error, and a complete NSURLResponse, which encapsulates significantly more information about the completed task. This allows your code to be much more nimble within that block. You have more than enough information to handle any completion outcome in a single signal. Go nuts.

// One completion handler
[myOperation startOperatingWithCompletionHandler:^(id data, NSError *error, NSDictionary *info) {
    [myView hideLoadingIndicator];
    if (error) {
        // Do something with the error
    }

    // Do something with data and/or info
}];

Efficiency at a Lower Level

Blocks are objects. Blocks are allocated, messaged, copied, and retained in memory. All of those things take time and space. Async tasks (generally) only have a single outcome. It really shouldn’t be possible for a task to both succeed and fail at the same time (though sadly, sometimes it is). In general, that means only one completion block is going to be used, which means that any other completion blocks that were allocated and passed along are essentially just taking up space. This is a cost that the delegation design pattern doesn’t incur, so it’s easy to overlook when migrating to blocks.

Admittedly, blocks are tiny, and the likelihood of these unnecessary allocations causing problems is pretty much nil. Generally, the time and memory costs of allocating a block are not statistically significant, and shouldn’t be worried about. But fewer blocks also means fewer chances for “typos” that end up creating retain cycles, leaking memory, or messaging a garbage pointer. If you’re interested in making the tightest loop possible, the realization that these costs exist might help you remember to steer clear of unnecessary block allocation. Future you will thank present you.

Living in a Block World

From a fundamental level, using blocks for async completion handling is completely different from delegation, and it should be handled differently. Blocks are handy, and they allow us to be more concise and efficient with our code. But if we treat them like encapsulated delegation methods, we’re not taking advantage of those benefits.

My thanks to Collin for writing the article that sparked our introspection. We’re refactoring our libraries and our code to be better block world citizens, and encourage everyone to adopt this pattern as well, whether for an open source library or private app-specific code.

The post Put a Block on It – Block Usage in API Design appeared first on Double Encore.

I mentioned before that the Provisioning Profile is just a plist. Let’s start at the top and look at the key/values of this plist. I have a sample Provisioning Profile .plist posted for you to follow along with:

1. The first item in the dictionary is “AppIDName.”  This is the name you gave your App ID in the iOS Provisioning Portal.

2. Next is “ApplicationIdentifierPrefix.”  This is the 10 character string that the provisioning portal generated for you when you created your App ID. It is known as the Bundle Seed ID (App ID Prefix) in the iOS Provisioning Portal.

3. “CreationDate” is the date-time stamp for when this Provisioning Profile was created.

4. “DeveloperCertificates” is interesting for a few reasons. First, it is an array, so it can contain multiple certificates. However, I have only ever seen one certificate in here. Second, it is the base64 encoded developer certificate. You can copy the text inside the <data> tags and paste it into a file between the “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” lines. You will get something like this:

-----BEGIN CERTIFICATE-----
MIIFnTCCBIWgAwIBAgIIDlfxd9Mb0+gwDQYJKoZIhvcNAQEFBQAwgZYxCzAJ
BgNVBAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBs
ZSBXb3JsZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFEMEIGA1UEAww7QXBw
bGUgV29ybGR3aWRlIERldmVsb3BlciBSZWxhdGlvbnMgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkwHhcNMTIwODAzMjEzNDQxWhcNMTMwODAzMjEzNDQxWjCB
kDEaMBgGCgmSJomT8ixkAQEMClc1OFo3OVc4WDkxMjAwBgNVBAMMKWlQaG9u
ZSBEZXZlbG9wZXI6IEpheSBHcmF2ZXMgKEU2TDg3NlFGTTYpMRMwEQYDVQQL
DAo5SzlGOUxDVjc0MRwwGgYDVQQKDBNNYXNzaXZlbHkgT3ZlcnJhdGVkMQsw
CQYDVQQGEwJVUzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANdD
4hK9TjfXqoe1p0WpxvEULd575mhDpaKkvuUPG29bFEDIQrf2h0DTIGbvu6rR
z09+nxI0JkN56A0JO2OygfJGG5hcKm78CRtNFrDrOksOKD12PJkubnxhAi4y
sMI9M5+WCE+zV48VwMMI7dHLG7Pg5irMaqecnqNpRCoKxMeeziki+fD3H7jU
MiC6CA7iKCVHoDZKycF9Q3CeA5+sGWO28IqDYbOiCdeFhaiLYVVZJlmdKjqU
gHBsQWjj/vCeyikf+Ls52pPrD9+e0VgBnzrK2RcDPdNZON9gVAp1GeNNsmte
gmHGMlEzpLXF3/4RxOr2eLQ5iy5W/2SBUWpdSRUCAwEAAaOCAfEwggHtMB0G
A1UdDgQWBBSQHWHglRuqJq0gR4KzILT29p9ZIDAMBgNVHRMBAf8EAjAAMB8G
A1UdIwQYMBaAFIgnFwmpthhgi+zruvZHWcVSVKO3MIIBDwYDVR0gBIIBBjCC
AQIwgf8GCSqGSIb3Y2QFATCB8TCBwwYIKwYBBQUHAgIwgbYMgbNSZWxpYW5j
ZSBvbiB0aGlzIGNlcnRpZmljYXRlIGJ5IGFueSBwYXJ0eSBhc3N1bWVzIGFj
Y2VwdGFuY2Ugb2YgdGhlIHRoZW4gYXBwbGljYWJsZSBzdGFuZGFyZCB0ZXJt
cyBhbmQgY29uZGl0aW9ucyBvZiB1c2UsIGNlcnRpZmljYXRlIHBvbGljeSBh
bmQgY2VydGlmaWNhdGlvbiBwcmFjdGljZSBzdGF0ZW1lbnRzLjApBggrBgEF
BQcCARYdaHR0cDovL3d3dy5hcHBsZS5jb20vYXBwbGVjYS8wTQYDVR0fBEYw
RDBCoECgPoY8aHR0cDovL2RldmVsb3Blci5hcHBsZS5jb20vY2VydGlmaWNh
dGlvbmF1dGhvcml0eS93d2RyY2EuY3JsMA4GA1UdDwEB/wQEAwIHgDAWBgNV
HSUBAf8EDDAKBggrBgEFBQcDAzATBgoqhkiG92NkBgECAQH/BAIFADANBgkq
hkiG9w0BAQUFAAOCAQEAApeWS6BrVv0jOFY7F0kCUR5h/RrXaMnUwjyFsF6r
HilDf70nvgIgIohtK2Uez5lkYavyDBzQGsN6gHbGLvg+4camDfT28quRPumk
qcIwZBCyB5A11HGlrer0Jz6iev6NAX5SSODWbAuzXJBs72EKuwF/+pGB5x1n
2YsKuQd8nQ+vD7kIHenP4n7goY8RSv8QQ8DhIkkgXqSbnZ6Xp4DKSTWgzb0T
a28g57YJlFjYioqkVFDi+5BANXxL0lHNeLAPXIY+TqQ/MWho/F6L2ONZyNT6
K6cadeQuTDgimoiTIjUGnAAR33SW7rIfHJNr2tNEtKu/aerKYCfWDLHf0QK9
1g==
-----END CERTIFICATE-----

Using the command openssl x509 -text -in MassivelyOverrated.pem allows you to inspect all of the certificate’s information, which will look like this:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0e:57:f1:77:d3:1b:d3:e8
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Apple Inc., OU=Apple Worldwide Developer Relations, CN=Apple Worldwide Developer Relations Certification Authority
        Validity
            Not Before: Aug  3 21:34:41 2012 GMT
            Not After : Aug  3 21:34:41 2013 GMT
        Subject: UID=W58Z79W8X9, CN=iPhone Developer: Jay Graves (E6L876QFM6), OU=9K9F9LCV74, O=Massively Overrated, C=US
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:d7:43:e2:12:bd:4e:37:d7:aa:87:b5:a7:45:a9:
                    c6:f1:14:2d:de:7b:e6:68:43:a5:a2:a4:be:e5:0f:
                    1b:6f:5b:14:40:c8:42:b7:f6:87:40:d3:20:66:ef:
                    bb:aa:d1:cf:4f:7e:9f:12:34:26:43:79:e8:0d:09:
                    3b:63:b2:81:f2:46:1b:98:5c:2a:6e:fc:09:1b:4d:
                    16:b0:eb:3a:4b:0e:28:3d:76:3c:99:2e:6e:7c:61:
                    02:2e:32:b0:c2:3d:33:9f:96:08:4f:b3:57:8f:15:
                    c0:c3:08:ed:d1:cb:1b:b3:e0:e6:2a:cc:6a:a7:9c:
                    9e:a3:69:44:2a:0a:c4:c7:9e:ce:29:22:f9:f0:f7:
                    1f:b8:d4:32:20:ba:08:0e:e2:28:25:47:a0:36:4a:
                    c9:c1:7d:43:70:9e:03:9f:ac:19:63:b6:f0:8a:83:
                    61:b3:a2:09:d7:85:85:a8:8b:61:55:59:26:59:9d:
                    2a:3a:94:80:70:6c:41:68:e3:fe:f0:9e:ca:29:1f:
                    f8:bb:39:da:93:eb:0f:df:9e:d1:58:01:9f:3a:ca:
                    d9:17:03:3d:d3:59:38:df:60:54:0a:75:19:e3:4d:
                    b2:6b:5e:82:61:c6:32:51:33:a4:b5:c5:df:fe:11:
                    c4:ea:f6:78:b4:39:8b:2e:56:ff:64:81:51:6a:5d:
                    49:15
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                90:1D:61:E0:95:1B:AA:26:AD:20:47:82:B3:20:B4:F6:F6:9F:59:20
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier:
                keyid:88:27:17:09:A9:B6:18:60:8B:EC:EB:BA:F6:47:59:C5:52:54:A3:B7

            X509v3 Certificate Policies:
                Policy: 1.2.840.113635.100.5.1
                  User Notice:
                    Explicit Text: Reliance on this certificate by any party assumes acceptance of the then applicable standard terms and conditions of use, certificate policy and certification practice statements.
                  CPS: http://www.apple.com/appleca/

            X509v3 CRL Distribution Points:
                URI:http://developer.apple.com/certificationauthority/wwdrca.crl

            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage: critical
                Code Signing
            1.2.840.113635.100.6.1.2: critical
                ..
    Signature Algorithm: sha1WithRSAEncryption
        02:97:96:4b:a0:6b:56:fd:23:38:56:3b:17:49:02:51:1e:61:
        fd:1a:d7:68:c9:d4:c2:3c:85:b0:5e:ab:1e:29:43:7f:bd:27:
        be:02:20:22:88:6d:2b:65:1e:cf:99:64:61:ab:f2:0c:1c:d0:
        1a:c3:7a:80:76:c6:2e:f8:3e:e1:c6:a6:0d:f4:f6:f2:ab:91:
        3e:e9:a4:a9:c2:30:64:10:b2:07:90:35:d4:71:a5:ad:ea:f4:
        27:3e:a2:7a:fe:8d:01:7e:52:48:e0:d6:6c:0b:b3:5c:90:6c:
        ef:61:0a:bb:01:7f:fa:91:81:e7:1d:67:d9:8b:0a:b9:07:7c:
        9d:0f:af:0f:b9:08:1d:e9:cf:e2:7e:e0:a1:8f:11:4a:ff:10:
        43:c0:e1:22:49:20:5e:a4:9b:9d:9e:97:a7:80:ca:49:35:a0:
        cd:bd:13:6b:6f:20:e7:b6:09:94:58:d8:8a:8a:a4:54:50:e2:
        fb:90:40:35:7c:4b:d2:51:cd:78:b0:0f:5c:86:3e:4e:a4:3f:
        31:68:68:fc:5e:8b:d8:e3:59:c8:d4:fa:2b:a7:1a:75:e4:2e:
        4c:38:22:9a:88:93:22:35:06:9c:00:11:df:74:96:ee:b2:1f:
        1c:93:6b:da:d3:44:b4:ab:bf:69:ea:ca:60:27:d6:0c:b1:df:
        d1:02:bd:d6
-----BEGIN CERTIFICATE-----
MIIFnTCCBIWgAwIBAgIIDlfxd9Mb0+gwDQYJKoZIhvcNAQEFBQAwgZYxCzAJBgNV
BAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMuMSwwKgYDVQQLDCNBcHBsZSBXb3Js
ZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFEMEIGA1UEAww7QXBwbGUgV29ybGR3
aWRlIERldmVsb3BlciBSZWxhdGlvbnMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMTIwODAzMjEzNDQxWhcNMTMwODAzMjEzNDQxWjCBkDEaMBgGCgmSJomT8ixk
AQEMClc1OFo3OVc4WDkxMjAwBgNVBAMMKWlQaG9uZSBEZXZlbG9wZXI6IEpheSBH
cmF2ZXMgKEU2TDg3NlFGTTYpMRMwEQYDVQQLDAo5SzlGOUxDVjc0MRwwGgYDVQQK
DBNNYXNzaXZlbHkgT3ZlcnJhdGVkMQswCQYDVQQGEwJVUzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBANdD4hK9TjfXqoe1p0WpxvEULd575mhDpaKkvuUP
G29bFEDIQrf2h0DTIGbvu6rRz09+nxI0JkN56A0JO2OygfJGG5hcKm78CRtNFrDr
OksOKD12PJkubnxhAi4ysMI9M5+WCE+zV48VwMMI7dHLG7Pg5irMaqecnqNpRCoK
xMeeziki+fD3H7jUMiC6CA7iKCVHoDZKycF9Q3CeA5+sGWO28IqDYbOiCdeFhaiL
YVVZJlmdKjqUgHBsQWjj/vCeyikf+Ls52pPrD9+e0VgBnzrK2RcDPdNZON9gVAp1
GeNNsmtegmHGMlEzpLXF3/4RxOr2eLQ5iy5W/2SBUWpdSRUCAwEAAaOCAfEwggHt
MB0GA1UdDgQWBBSQHWHglRuqJq0gR4KzILT29p9ZIDAMBgNVHRMBAf8EAjAAMB8G
A1UdIwQYMBaAFIgnFwmpthhgi+zruvZHWcVSVKO3MIIBDwYDVR0gBIIBBjCCAQIw
gf8GCSqGSIb3Y2QFATCB8TCBwwYIKwYBBQUHAgIwgbYMgbNSZWxpYW5jZSBvbiB0
aGlzIGNlcnRpZmljYXRlIGJ5IGFueSBwYXJ0eSBhc3N1bWVzIGFjY2VwdGFuY2Ug
b2YgdGhlIHRoZW4gYXBwbGljYWJsZSBzdGFuZGFyZCB0ZXJtcyBhbmQgY29uZGl0
aW9ucyBvZiB1c2UsIGNlcnRpZmljYXRlIHBvbGljeSBhbmQgY2VydGlmaWNhdGlv
biBwcmFjdGljZSBzdGF0ZW1lbnRzLjApBggrBgEFBQcCARYdaHR0cDovL3d3dy5h
cHBsZS5jb20vYXBwbGVjYS8wTQYDVR0fBEYwRDBCoECgPoY8aHR0cDovL2RldmVs
b3Blci5hcHBsZS5jb20vY2VydGlmaWNhdGlvbmF1dGhvcml0eS93d2RyY2EuY3Js
MA4GA1UdDwEB/wQEAwIHgDAWBgNVHSUBAf8EDDAKBggrBgEFBQcDAzATBgoqhkiG
92NkBgECAQH/BAIFADANBgkqhkiG9w0BAQUFAAOCAQEAApeWS6BrVv0jOFY7F0kC
UR5h/RrXaMnUwjyFsF6rHilDf70nvgIgIohtK2Uez5lkYavyDBzQGsN6gHbGLvg+
4camDfT28quRPumkqcIwZBCyB5A11HGlrer0Jz6iev6NAX5SSODWbAuzXJBs72EK
uwF/+pGB5x1n2YsKuQd8nQ+vD7kIHenP4n7goY8RSv8QQ8DhIkkgXqSbnZ6Xp4DK
STWgzb0Ta28g57YJlFjYioqkVFDi+5BANXxL0lHNeLAPXIY+TqQ/MWho/F6L2ONZ
yNT6K6cadeQuTDgimoiTIjUGnAAR33SW7rIfHJNr2tNEtKu/aerKYCfWDLHf0QK9
1g==
-----END CERTIFICATE-----

Apple and iOS use this certificate to verify the code is signed by the appropriate developer.

5. Next is “Entitlements.” This is a dictionary that can contain many key values pertaining to iCloud, Game Center, Push Notifications and attachment of a debugger to the app. Going into all the possibilities is outside the scope of this post. However, if you ever get the error, “The executable was signed with invalid entitlements,” you can copy this dictionary and paste it into your app’s Entitlements.plist file to make sure that the app’s and the Provisioning Profile’s entitlements are an exact match.

6. “ExpirationDate” is the date this Provisioning Profile expires.

7. “Name” is the name you gave this Provisioning Profile in the iOS Developer Portal.

8. “ProvisionedDevices” is an array of all the device UDIDs on which the app associated with this Provisioning Profile can be installed.  I consider this to be the meat of the file. 90% of the time when I am opening a Provisioning Profile, it is to determine if a UDID is included in this array.

9. “TeamIdentifier” is another array, but I have only ever seen one value in here. This is the identifier for the team to which this Provisioning Profile belongs.

10. “TeamName” is the Team to which this Provisioning Profile belongs. I find it interesting that “TeamIdentifier” is an array, yet “TeamName” is not.

11. “TimeToLive” is the number of days that this Provisioning Profile is valid. Apple sets this to 365.

12. ”UUID” is interesting because the value can often find its way into your Xcode project file. This UUID changes every time you generate an updated Provisioning Profile. If you ever select a specific Code Signing Identity in Xcode, instead of the more generic “iPhone Developer” or “iPhone Distribution,” this UUID gets set into the “PROVISIONING_PROFILE” section of your Xcode project.pbxproj file. Your SCM diff will look like this when you change from one Provisioning Profile to another in Xcode:

- PROVISIONING_PROFILE = "D8F8CD60-CD85-4FEA-BF87-CD5D67FDC3EA";
+ PROVISIONING_PROFILE = "9B44F36C-328F-45C0-BC62-4A272CB9DAD7";

13. “Version” is the version of this file data format. Apple sets this to 1.

I mentioned above that 90% of the time when I check a Provisioning Profile, it is to inspect the “ProvisionedDevices” array. The other 10% is almost exclusively to inspect the “Entitlements” and the “UUID.”  If you work with Apple’s Push Notification service, the “Entitlements” field holds the value for the “aps-environment.” This value can either contain “production” or “development,” and shipping an app with these values mixed up, or not set at all, guarantees that Push Notifications will not work in your app. I am extremely paranoid that I will ship an app to Apple that has the “aps-environment” not set to production. Therefore, I manually inspect the Provisioning Profile “aps-environment” of each app before I submit to iTunes Connect.

I use the “UUID” to force Xcode to build with the specific Provisioning Profile. I like being able to have full control over this instead of relying on Xcode to automatically choose the right one, which it often does not do correctly. With automated builds, Jenkins makes it very easy to override the “UUID” using an .xcconfig file. You can expect to hear more about that soon.

The post What is a Provisioning Profile? Part 2 appeared first on Double Encore.

The way you decide to utilize Xcode’s location spoofing will depend on how your app will use it. For example, if you’re making a gorgeous weather app for the iPad, you’ll want to spoof a static location to simulate getting a user’s local weather. On the other hand, if your app does something like map a user’s bike ride, you’ll need to spoof a set of locations that simulate a user’s location changing over time. Xcode has some presets you can use for both scenarios, but more than likely you’ll want to construct your own custom data to feed to Xcode.

First, you will create a GPX file. GPX is a standard file format used for expressing GPS locations. The format for GPX files that Xcode looks for is fairly straightforward:

<gpx>
    <wpt lat="38.897678" lon="-77.036517"></wpt>
</gpx>

This GPX file gives the latitude and longitude for The White House. Throw that text into a text editor, and save it as WhiteHouse.gpx. In Xcode, open a project you have for an iPhone or iPad app, and build it to your device. Once the app is running on your device, go to Product > Debug > Simulate Location, and select the last option in the list that says “Add GPX File to Project…”, then select the WhiteHouse.gpx file we just created. Xcode will pop up some options for adding the file; the defaults should be fine, so just click on Finish. Now, if you go back to Product > Debug > Simulate Location, you should see WhiteHouse near the top of the list; click on it (you can also get to this list from the debug bar at the bottom of Xcode, just click on the location services arrow icon). Your device should now think you’re at the White House. To check, press the home button on your device to close your app and go to Maps app. If it didn’t seem to work, check Xcode and make sure the location arrow in the debug bar is blue. If it’s still gray, Xcode doesn’t like something about your GPX file.

One thing you might be wondering now is if Maps uses your simulated location, will other apps use it also? The answer is yes. Think about all the apps you have and what they are using location services for. Twitter clients posting your location with tweets, sports apps using your location to black out games, camera apps that put your location into Exif data, apps like Foursquare that check you into places – they will all look at your simulated location. I won’t go into detail here, but you should play around with this; it can be interesting.

Visiting the White House was fun, but what if you are making an app for people to track their sweet rollerblade workouts? You will need to make a GPX file with multiple location points. The format is the same but with more wpt elements that have additional latitude and longitude coordinates. I found a GPX file for the New York City Marathon here but had to make some modifications for Xcode to like it. Grab the modified file here. Click on the location button in the debug bar of Xcode, and select “Add GPX File to Project…” again. Point it to your New York City Marathon file, and accept the defaults as before. Finally, click the location button again, and select New York City Marathon from the list. Now, if you go back into Maps, you should see your blue dot making its way through the New York City Marathon; every rollerblader’s life ambition.

We’ve had quite a day so far. Any developer or tester would be exhausted after visiting The White House and rollerblading the New York City Marathon, so I won’t keep you much longer; just one more thing to show. With your app still running in Xcode, unplug your device (I will not be held responsible for any bootstrap errors that result). If you go back into Maps, you’ll find your rollerblader is stuck hanging out in New York. If you don’t stop your app in Xcode before unplugging your device, your device will continue to use the simulated location until you restart it, or until you plug it back in and turn off the location simulation. This is extremely handy for testing without being tethered to your computer. However, this can also be confusing for your mom when she sees your Facebook post from Antarctica, so don’t forget to turn it off when you have finished playing.

Hopefully, Apple will eventually give us the ability to control how quickly Xcode advances through the file. Maybe if we’re really lucky, they’ll give us a way to easily generate GPX files, or let us just specify a location without the need to create a GPX file. In the meantime, Location Simulation, while requiring a little bit of hands on work, is an extremely handy tool for testing location services in your app.

The post Using Xcode to Test Location Services appeared first on Double Encore.

So we’re going to change that.

Instead of another op-ed piece about the undeniably real and albeit discouraging difficulties for women in engineering, we instead want to tell you why we want to hire women, why female engineers are successful, and why our industry can thrive with all of our capable minds at work.

Women Are Capable Engineers

Many studies (including this one by the University of Illinois) have found that women generally score at the same level as men on assessments in computer science courses. Despite lower enrollment, women continually fare incredibly well with the software engineering curriculum.

The truth is that gender has as much to do with your coding ability as your height. Great engineers are, at their core, great problem solvers; there is no requirement that you grow a beard to know how iOS source code should be managed.

And it’s not just a “nerd thing” either: it’s an intelligence thing. Men in technology fall into a variety of social categories that do not limit them to Star Trek-watching, Reddit-reading, video game fans; it’s no surprise that women in technology are just as infrequently categorizable. The one quality we look for in an engineer is an incredibly active, problem solving, creative mind – and we’ve found that these minds can come from a person of any gender, age, or personality type.

“There’s all kinds of different women who do this. You can wear ruffles; you can be a jock, and you can still be a great computer scientist, or a great technologist, or a great product designer.” – Marissa Mayer (CNET Panel Interview, 2012)

Women Are Successful Engineers

Our industry may be flooded with the Zuckerbergs, the Pages and Brins, but it’s also flooded with some incredibly talented women. Here are just a few women who are killing it in our industry:

Jessica Kahn, former VP of Product, Engineering & Operations at Disney Mobile, has a beast of a brain. In her almost ten years at Apple, Kahn was listed as an inventor on several US patents that the tech giant produced. Kahn’s engineering skills brought her to Tapulous, where she orchestrated the engineering efforts behind Tap Tap Revenge, taking it to the coveted #1 App Store position. She now serves as VP of Engineering for BandPage.

In an interview with David Zax, Kahn confessed that she initially thought she’d pursue law until she sat in on her first coding class at Dartmouth:

“I just sat there and thought, ‘Oh my god, people will pay me to do this? This is so much fun! It was logical like law, but there was more tinkering and playing games and solving puzzles.”

Kahn has a mind for engineering that not only comes from skills, but her passion as well.

Andria Jensen cofounded Appsolute Genius where she is currently the CTO. Andria hails from Alabama where she’s been programming since high school, but you can catch some of her acclaimed iOS development sessions online.

Jocelyn Goldfein is Facebook’s Director of Engineering, where she heads up projects like News Feed and Photos. Golfein was drawn to a CS degree at Stanford where she graduated before directing the engineering department at an email management startup.

“The only way to really stay current is to actually do the work. That means writing and reviewing code. If that doesn’t fit easily into your day job, try making time for side projects or a hack night every couple months. Also, don’t ever be afraid to ask questions until you really understand something.” -Goldfein, in an interview with the Anita Borg Institute

Goldfein went on to VP and GM at VMware, where she headed the company’s desktop projects before finally landing her current position at Facebook.

Women Are Practicing Engineers

So where do you get started? Where can you, a full-grown, educated woman start exploring engineering to see if it’s for you?

Luckily, the female engineering community is growing and active in many cities. Here in Denver, we’re lucky to have Women Who Code, a Meetup group with everything from hackathons to study groups to social functions all for women engineers (or aspiring engineers).

Women Who Code was originally founded in San Francisco and has since spread to many other cities. Search meetup.com to see if there’s a Women Who Code branch near you.

“A Rosie the Riveter Moment”

In the recently filmed documentary, SHE++, Jocelyn Goldfein calls on women to embrace their “Rosie the Riveter Moment.” That is, she recognizes that the demand for engineers outnumbers our current computer science graduates and that there is a great opportunity for women to step up and dominate the field.

We’ve currently got six female employees in our 43-person team, but I think we can do better.

Let’s embrace our time in history to take another industry by storm. Join Women Who Code, register for a computer science class (like this one, at gSchool), and apply for an engineering job. I can’t wait to read your resumes.

For more insight on this topic, please attend the Denver/ Boulder screening of SHE++, the documentary on Tuesday, April 23rd at Galvanize. Or find a screening near you.

The post Changing the ‘Women in Technology’ Dialogue appeared first on Double Encore.

The five reasons why Second Screen apps have yet to go Mainstream:

1.     Most of what’s out there fails to cater to existing second screen behaviors that created the space to begin with. Second Screen was born out of boredom and defined by consumers; they looked to their smartphone or tablet when the TV content was boring them or there was an extended break between programming. The space has focused so much on a synced experience between the TV and mobile device, it has lost sight of these core habits and times of use.

Many of today’s Second Screen apps are coming from programmers and advertisers who are side-tracked with pushing their show/product in the space, so they can’t really provide the tools and functionality that second screen habits dictate. Again, one of the main uses of Second Screen right now is a byproduct of boredom; the first screen is boring or there’s a commercial on, so the viewer decides to check Gmail, Twitter or Facebook. Think of one Second Screen app that allows users, whenever they choose, to easily check their social networks and email while interacting with the programming. They don’t exist. Second Screen was created by consumers but hijacked by content creators, and the viewing audience has not responded well to how the space has evolved.  They’re still largely choosing their own Second Screen experience, not the ones the apps are providing.

2.     Too many are trying to make the Second Screen the first screen. TV viewing is a lean-back experience; people want to relax, turn their minds off and absorb easy entertainment. Many of the available Second Screen apps today are very complex, even after the user has the learning curve down, the app still requires constant focus, and this brings a conflicting lean-forward user experience to a lean-back environment. The best Second Screen apps will eventually have limited interaction, but these interactive aspects, such as choosing your ending, participating in game shows, and entering contests, will be pushed at key times when it doesn’t distract from the first-screen experience.

3.     Fragmentation is in full-effect and getting worse. Various studies have shown that people download dozens of apps on their mobile devices but use just a handful consistently.  This is yet another area where content providers and app producers in this space are not recognizing established consumer habits. Networks and programmers should put out one app for ALL of their programming and advertisers, not one for each show.  A consistent, flowing experience keeps users engaged, while requiring them to fire up a new app each time they change the channel or between shows is a horrid UX.

The current Second Screen app space is simply too watered-down to get suitable traction. From Walking Dead to Celebrity Apprentice, Conan to the Game of Thrones, every show seemingly has its own second screen app these days, but no consumer is going to learn/use 20 different apps for a good Second Screen experience.

Applications like Zeebox and IntoNow are trying to remedy this issue by allowing you to view any live, linear content on the TV from within one app, one UI, one experience. While I see apps like this as the most promising avenue for Second Screen, there are few offerings like this, and they are very reliant on ACR technologies that are not overly user-friendly. For apps like this to crack the mainstream, the Zeebox’s of the world need to talk directly with set-top boxes through open API’s to figure out what the user is watching consistently and without user input.  Once apps like this fully integrate with the DirecTV’s and Comcast’s of the world, we’ll know this movement has taken one step closer to going mainstream.

4.     There is little involvement from the networks or cable/satellite providers. While they are providing numerous apps, if you really look at what the studios and networks are doing, Second Screen is something that has evolved as an afterthought. They create the content then look for ways to create Second Screen content around it.

The Second Screen vertical will only take off if there are related concepts and approaches implemented from the very beginning, as in when the show or movie is being written, shot, and edited. Imagine if, when watching The Matrix, you could choose the blue pill instead of the red pill. Just think of how much more you would watch your favorite movie if it had 20 or 30 different paths you could select throughout it, all taking you to different battles, relationships or endings? This is the promise of Second Screen at its core – that we can determine the outcome of the content we are watching by our input. Unfortunately, we are nowhere close to this. Hollywood needs its own visionary – its own Steve Jobs – to make this a reality.

Right now so much of the focus on Second Screen is focused on Social TV. While knowing what’s hot and what’s trending is good for social discovery and water-cooler talk the next day, creating social content during a show is too distracting from the first screen to be a heavy-hitter.  Choosing the show’s direction, participating in a quiz, guessing the next play the team is going to run, that’s what the players in the TV space need to be focusing on to push this movement to the masses.

5.     We need more tablets in homes. While smartphones can be second screen devices, there’s no doubt that the bigger screen size of tablets, even smaller ones, is much better for this experience. Thankfully, this issue won’t take long to resolve; tablet growth is exploding, with iPad sales at three times the pace of the iPhone. While 30% of households today have a tablet, new offerings in the form of the iPad Mini, Nexus 7 and Kindle Fire HD will hopefully push tablet ownership from early adoption to the early majority over the next couple of years. Inevitably, the more platforms and screens there are to conduct Second Screen activities, the more attention and focus the space should receive.

The post 5 Things Keeping Second Screen From the Masses appeared first on Double Encore.