Throw everything you thought you knew about Apple UDIDs out the window. Historically, Apple’s UDIDs have always been a hexadecimal string exactly 40 characters long. Last week, Apple released new hardware. Most notably the iPhone XS, iPhone XS Max, and iPhone XR. On those new devices, they seem to have changed the format of UDIDs. They are now a string of 8 characters, then a hyphen followed by 16 more characters. XXXXXXXX-XXXXXXXXXXXXXXXX
TL;DR: Navigate to Settings > General > About > Certificate Trust Settings and turn the switch on for your custom certificate.
Last year, with iOS 9, Apple introduced App Transport Security; an enforcement of best practices for encrypted networking. By default, App Transport security requires the following:
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 mac OSes 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.
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 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.
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”. Head over to iMore for my full not-quite-rant.
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 has done the hard work for all of us and compiled his findings into a very handy post. 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.
When Apple acquired Burstly, makers of TestFlight, earlier this year, 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 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. But looking at what we know so far about TestFlight, I’m not so sure that’s the case.
A couple of weeks ago, Austin Carr wrote a post titled “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.