Lame and inelegant. This was our reaction when we discovered that a launch partner of OpenUDID, Crashlytics, decided to create an alternative to the UDID called SecureUDID. It’s not so much about the code and the product, but rather the process and the lack of disclosure. The issue here is really about Open Source project netiquette.

Back to the origins

When Apple announced the deprecation of the UDID almost a year ago, we were amongst the first to set time aside and start building an alternative. We wanted it to be open source and Appsfire would support it.

It was announced publicly and it instantly attracted the interest of hundreds of developers, including some nice brand names. Crashlytics was one of them – they wanted to contribute and also be part of the launch operation PR. We announced […]Read more


We’ve covered this issue before, preemptively. But now is the time to act!

Some reports have emerged that Apple is now massively rejecting apps that still use the “[UIDevice uniqueIdentifier]” a.k.a. the UDID (Unique Device IDentifier). This means that developers have two choices: drop using this entirely, or find a replacement.

Some have gone the MAC address way, which we strongly advocate against because it is an even more sensitive unique identifier typically used to authenticate devices on VPNs and other private WLANs. So it too faces the risk to be deprecated. And rightly so!

So, if you haven’t done so already, go and check the open-source drop-in replacement, an effort we participate in:


[…]Read more


With the introduction of iOS 5, Apple implicitly indicated that it will soon remove the ability for developers to access the unique device identifier, also known as UDID. While not the most important API in the entire iOS SDK, many in the app ecosystem have grown dependent on this UDID, for legitimate aggregate measurement needs, not for individual tracking purposes. The problem is real and yet both sides of the solution (!) have legitimate claims. A recent article on TechCrunch articulates the mobile conundrum very well.

In anticipation of this imminent restriction (which in some cases already appears to be enforced as alluded to here or here), a number of actors have adopted a substitute open-source approach that Appsfire helped bootstrap: […]Read more


Appsfire as a project started over 24 months ago. At the time, iOS was already fairly developed, but User Interfaces rarely erred outside of the recommended guidelines (also by fear of not being approved), except for games where everything goes. Apple had polished and optimized the vertical scrollable view (UITableView for our Cocoa readers), and effectively entrenched this browsing mode as the golden standard for long lists of objects, which remains, to this date, a perfect way to browse lists of strings, augmented with the occasional icon and corollary information.

This UI/UX element was fine for us back then. After all, the initial version of the Appsfire app for iOS (up to v2.0) just needed to present its users with a long list of applications to share or browse, all of which had a title name, an icon, and a category. In fact, this is also how the iTunes App […]Read more


After Apple’s apparent decision to discontinue use of the Unique Device IDentifier (UDID) in iOS5, a large segment of the iOS developer community has been searching for an alternative solution. To serve the community in a way that is both accessible and non-proprietary, Appsfire is introducing the open-source OpenUDID initiative thereby inviting all stakeholders to this much needed debate.

The Gist

If you’re not already familiar with UDID’s (and if you’re a developer, you’ve been missing out), it’s a critical tool for analytic or CRM purposes. A developer could use UDID’s as a means to track how much time a user spent in his free app before upgrading to the paid version. UDID’s are also helpful for tracking the source of a download when […]Read more