Category: Tools

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.

What Developers Should Know About Apple’s TestFlight

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.

The Promise

TestFlight will bring two big changes to ad hoc app distribution as we know it. First, test devices are now managed using email addresses, rather than UDIDs. Second, the test device limit was drastically increased from 100 devices per account to 1,000 users per app. Many developers have been frustrated for some time now with Apple’s 100 device limit, and this has only gotten worse over the years with more new devices being released. The current system of UDIDs and provisioning profiles unnecessarily wastes a lot of developer time, requiring close monitoring and management of test devices and troubleshooting esoteric error messages.

With TestFlight, developers won’t need to ask testers for UDIDs anymore—they will simply send them an email invite from iTunes Connect. Once a user accepts the invite and installs the TestFlight app, they’ll be able to view details for apps, install betas, and provide feedback to developers. Developers will be able to use iTunes connect to upload builds, manage users, and even get insights into how testers are using the app. So far, so good, but here come the caveats.

Internal Testers vs. Beta Testers

TestFlight users will fall into two buckets: internal testers and beta testers. Beta testers will be the ones invited via email and, as previously mentioned, you will be able to have up to 1,000 of them per app. Internal testers will be managed in iTunes Connect by creating an account for each tester; you are limited to 25 of these. Builds for beta testers will need to be reviewed and approved by Apple before testers will have access to them, while internal testers will have access to builds as soon as they are uploaded. As others have already pointed out, reviews will only be required for the initial submission and any builds that contain major changes to the app—minor changes won’t require another review. But this is already a hurdle that developers didn’t previously have to deal with. And for many companies, 25 internal tester slots simply won’t be enough. It’s great to see Apple get rid of the 100-device limit, and for a lot of developers it may be sufficient, but for many the hassle of dealing with the 100-device limit isn’t going away, it’s just being replaced with a similarly frustrating limitation of 25 internal testers.

Supported Platforms

Not surprisingly, TestFlight is only available for iOS 8. While TestFlight originally worked on Android, that support was dropped shortly after Apple acquired Burstly and there’s no indication it will return. There also hasn’t been any mention of TestFlight supporting Mac apps (which Hockey does). So if you’re planning on making an iOS 8-only app, then you’re in good shape. But anybody supporting older iOS versions, Android, or wanting to have a Mac app will need to look elsewhere.

Build History

The demonstration shown in Apple’s iTunes Connect session seems to suggest that testers will only be able to install the latest version of a beta. When a new build is uploaded, the previous build is marked as Inactive. Most of the time this is perfectly fine, but it’s not uncommon for developers and testers to need to install previous builds of an app. You may need to go back and reproduce a bug in an old build, or go back to compare a design element that has changed, or check old builds to determine when a regression was introduced, or to test database migrations from old builds… there are plenty of perfectly valid reasons for needing the ability to install previous builds. Perhaps I’m reading into Apple’s demonstration too much, but if this winds up being the case, Hockey will be able to add this to the list of features it has over TestFlight.

Automated Builds & Continuous Integration

TestFlight builds will be uploaded and managed through iTunes Connect. Unless Apple provides command line tools for this (which there has been no hint of), any developers who use any sort of continuous integration environment for automating builds and uploads will be out of luck. Each update for testers will require a developer to manually build and upload through iTunes Connect. Obviously there are plenty of developers who currently do manual builds, and for them this won’t be a big deal. But for the many of us using CI to upload multiples builds a day, this lack of functionality alone is enough to immediately rule out moving from Hockey to TestFlight.

Crash Reporting

Another big feature that TestFlight will have is crash reporting. Apple has provided crash reporting for App Store apps for a while now, but many have found it to be lacking and utilize 3rd-party solutions instead. Apple has only mentioned TestFlight supporting crash reporting for App Store submissions, not betas. It’s better than no crash reporting at all, but it’s not a complete solution and it’s still subpar to the many 3rd-party solutions currently out there. Oh, and one more thing. Apple said that crash reporting and symbolication will be available later next year.

Support

Last but not least, let’s talk about support. Hockey won me over early on with their beyond-stellar support. I frequently receive responses to my support requests in less than 15 minutes, and at all hours of the day and night. One time I submitted a support request to find out if I could aggregate crash information in a particular way through the Hockey website, but was told it wasn’t currently possible. The next morning Hockey support sent me a Ruby script to accomplish what I wanted using their API. Apple won’t be, and likely has no interest in, providing that kind of support.

Where TestFlight Fits In

Believe it or not, I’m not trying to talk anybody out of using TestFlight. I’m quite glad to see TestFlight; I think it’s a big step in the right direction. TestFlight will be entirely sufficient for many developers’ testing needs, and the fact that those developers will be able to utilize TestFlight instead of relying on, and having to pay for a 3rd-party service, is great news. Even developers who continue to use services like Hockey to fulfill needs unmet by TestFlight will likely benefit from TestFlight. Hockey may make the most sense during development when you’re cranking out builds and rapidly iterating, but as you’re getting ready to ship to the App Store, being able to get your app into the hands of a much larger group before finally shipping to the App Store is a huge plus. The more users you have testing your app on more devices, the greater your ability to catch strange edge cases and eventually ship a more polished app. That’s not only great news for developers, it’s great news for users who easily become collateral damage of insufficient testing.

Maybe down the road Apple will expand TestFlight to compete more aggressively with Hockey. Maybe they’ll even kill off manual management of distribution profiles for good. But looking at what we know about these upcoming changes so far, TestFlight and HockeyApp are two different services that serve two very different needs. TestFlight isn’t going to kill Hockey, it’s going to complement it.

The Real Value of Panic’s Status Board

Today Panic announced the release of their new iPad app, Status Board. I was fortunate enough to have the opportunity to spend some time with it before its release and I can confirm what most of you probably already anticipate; it’s a phenomenal app. I’ll spare you another review, because there are already great ones to be read elsewhere. But there are a couple of features in Status Board that I wanted to talk about. Ones that I think have a tremendous amount of value and potential.

The first feature that I’m really excited about is HockeyApp integration. One of the widgets available in Status Board is a custom graph. HockeyApp has made it incredibly simple to pass URLs from Hockey to Status Board which will feed your widget the data necessary to chart a graph of your crash numbers. You can fit up to 6 different graphs comfortably in Status Board’s landscape orientation, and up to 8 in portrait. I’m hopeful that daily crash numbers are just the beginning. The HockeyApp API offers a lot of useful data, and the data you can graph in Status Board is really only limited by what people decide to make scripts for. This leads me to the second thing that I’m excited about.

IMG_0083

Status Board also has widgets for custom tables and do-it-yourself panels. Combined with the custom graph widget, there are countless possibilities for the data and information to be displayed in Status Board. I have a suspicion (or possibly more of a hope) that a lot of users will quickly see different scenarios and opportunities to create scripts that will populate interesting and useful data for various widgets. Maybe the number of builds they have each day, or GitHub pushes, or Pivotal velocity, or bugs closed in Lighthouse. The list goes on and on. I’ve already seen a number of people on Twitter getting excited just thinking about the possibilities. As developers create tools to generate data for their own widgets, I hope they’ll be kind enough to share them with others. Before long we may have a laundry list of tools that you can use to create entertaining and helpful widgets for your status board.

So with that, I encourage you to go check out Status Board if you haven’t already, and get cracking on one of the first must-have dataset generators for Status Board.

Update: Chris Patterson has already gotten the ball rolling over here.