Simple Script for Getting a Device’s UDID

When I need to grab a device’s UDID, it has always felt heavy to me to have to launch iTunes or Xcode just to get a simple 40-character string. After years of sighing about it, I finally did something. Below is a simple bash script that uses OS X’s system_profiler command to grab the UDIDs of any iOS devices connected to your computer. It will print all UDIDs to your terminal’s stdout and copy the last UDID to your clipboard for easy pasting.

iOS 8 Location Services PSA

When Apple announced their changes to Location Services in iOS 8 at WWDC this year, a couple of things jumped out as being potentially problematic for developers (as well as users). I wrote about the changes in-depth on [iMore](http://imore.com/changes-location-permissions-ios-8) back in June, but now that iOS 8 is out, and the changes are causing some confusion for people, I think it’s time to revisit them and discuss possible problems.

Software development, QA, and the reality of bugs

There was a lot of chatter this week after Apple pushed out iOS 8.0.1 with bugs that left some iPhone 6 and 6 Plus users without cellular service or Touch ID. If Apple has ever published an iOS update with such significant bugs, I can’t remember it. In the wake of the release, some publications thought the best thing to do would be to write defamatory articles pinning the failure to a single person: Apple’s QA manager who oversees iOS testing. As a QA lead and somebody who has worked in software for a number of years, this was cringeworthy to read. It’s not only a shitty thing for a news site to do, but also demonstrates that they lack any sort of understanding of software development. In response, I decided to write [“Why bad bugs hit good people”](http://www.imore.com/hugs-not-bugs). Head over to [iMore](http://www.imore.com/hugs-not-bugs) for my full not-quite-rant.

Security & Privacy Changes in iOS 8 and OS X Yosemite

I’ve been sifting through this year’s WWDC videos looking for all of the interesting bits around security & privacy. I’m not anywhere close to being done. Fortunately [Luis Abreu](https://twitter.com/lmjabreu) has done the hard work for all of us and compiled his findings into a [very handy post](http://lmjabreu.com/post/ios-8-privacy-updates/). The post has a lot of great info for developers, QA, and designers around what’s new and what’s changing. Of course you’ll still want to go do your own research before implementing any changes, but Luis’ post serves as a great quick-start guide.

What Developers Should Know About Apple’s TestFlight

When Apple acquired Burstly, makers of TestFlight, [earlier this year](http://www.imore.com/burstly-maker-testflight-app-testing-platform-acquired-apple), many were hopeful that Apple was finally ready to provide developers with an easy way to manage beta testing. So naturally, developers responded to Apple’s official announcement of the (re)launch of [TestFlight](http://www.imore.com/testflight-ios-8-explained) at WWDC with great applause. Since then, many (including Apple) have rejoiced that the days of dealing with UDIDs and provisioning profiles are over. Many already believe that TestFlight spells the end for [HockeyApp](https://hockeyapp.net/). But looking at what we know so far about TestFlight, I’m not so sure that’s the case.

Why Pull-To-Refresh Isn’t Such a Bad Guy

A couple of weeks ago, Austin Carr wrote a post titled [“Why The Pull-To-Refresh Gesture Must Die”](http://www.fastcodesign.com/3023421/why-the-pull-to-refresh-gesture-must-die). The article is pretty much what the title implies– an explanation of reasons why pull-to-refresh is no longer needed and should go away. Ignoring the overly-aggressive title, the post simply doesn’t make a compelling argument for why we need to abolish pull-to-refresh. At best it offers some reasons why developers may want to reconsider whether or not their app needs pull-to-refresh.

iPhone Touchscreen Accuracy – A lesson in understanding test requirements and goals

Effective problem solving requires that you fully understand the problem you’re trying to address. This holds true in life and in programming. Effective testing requires that you have a good understanding of what you are testing and why. Without this solid foundation, at a minimum you’ll cause some confusion, and often times you’ll end up wasting time, money and energy investigating problems that aren’t really problems. This week, a company called [OptoFidelity](http://www.optofidelity.com/) provided the perfect opportunity to discuss this challenge that engineers and testers commonly face.

Evaluating the Security of Hosted Build Servers

A few weeks back there was an [abuse of Apple’s Enterprise Developer Program](http://www.imore.com/how-gameboy-emulator-finding-its-way-non-jailbroken-devices) that gathered a lot of attention after it was used to distribute a GameBoy emulator outside of the App Store. Obviously the focus at the time was on the fact that anybody could build an app to distribute outside of the App Store by using one company’s enterprise certificate. What got no attention, as far as I can tell, was the lack of security on the build server.