Tag: Kumulos

Apple’s Deprecated UDID: Rumour, Replacement, and Reality

With Apple announcing that its uniquIdentifier API is deprecated as of iOS 5.0, developers now have to find a suitable replacement to use in their apps. In this article, we’re going to examine the core issues with the Unique Device Identifier (UDID), the implications of deprecation, and the alternatives we can use as developers.

The UDID is an ID unique to each handset, which doesn’t change depending on which app is requesting it, or how many owners the phone has had. Privacy seems like Apple’s main motivation for deprecating access to the UDID, which in the past has allowed analytics providers to build up user profiles based on which apps their device has installed.

There has been much speculation that Apple would release an official replacement for the UDID at its developer conference this year. However, no such replacement was unveiled, leaving developers to continue wondering how to solve the problem of uniquely identifying devices.

When considered, it’s potentially more useful to track users of our application instead of physical devices in most cases anyway. Therefore Apple’s move may not only be good for privacy, but also good for making app developers reconsider what information they really need to collect in the first place.

So, being enlightened developers, shown the error of our ways by Apple, we can now explore the options to replace UDID with something equally unique, almost as persistent, and perhaps even ultimately more suited to our real requirements.

CFUUID with NSUserDefaults/Keychain Services

This is Apple’s official suggestion from their developer documentation. If a unique identifier is required, CFUUID should be used to create such an ID, and this should be written to the defaults database for the app.

The limitations of this are:

  • The preferences file can be deleted by the user, effectively removing your ID
  • If the app is deleted and reinstalled, a new ID would be generated because this clears the preferences file too
  • The ID is accessible to only the app it was created by, so you can’t share the same ID in all of your apps

To address some of these limitations, it’s possible to use the keychain to store the information instead. This has a few advantages:

  • It persists through app reinstalls
  • It’s possible to share access to items in the keychain between multiple apps

However, it’s still possible for the user to delete the entry if they really want, and it will only survive being transferred across devices if the backups of the device are encrypted. If device transfer would be required, then the shared preferences may be more suitable.

Let’s look at a code sample that shows how to generate a UUID and store it in the keychain. It makes use of the UICKeyChainStore library to simplify keychain access. (Note that the library is not ARC compatible so you should disable ARC for those files in the build phase settings as described here: http://www.leesilver.net/1/post/2011/8/disabling-arc-on-certain-files-in-xcode.html)

#import "UICKeyChainStore.h"
NSString* uuid = [UICKeyChainStore stringForKey:@"MyAppUUID"];
if (uuid == NULL) {
// Create UUID to use instead of UDID
CFUUIDRef cfuuid = CFUUIDCreate(NULL);
uuid = (__bridge_transfer NSString*) CFUUIDCreateString(NULL, cfuuid);
CFRelease(cfuuid);

[UICKeyChainStore setString:uuid forKey:@"MyAppUUID"];
NSLog(@"Generated and set UUID: %@", uuid);
}
else {
NSLog(@"Retrieved UUID: %@", uuid);
}

This means that you can effectively store a unique but anonymous identifier for the user of your app.

OpenUDID

If you’d rather not have to worry about managing the install ID yourself, then you can turn to an existing library, such as OpenUDID. This library tries to implement a UDID as similar to uniqueIdentifier as possible without using any features that may become disallowed in the future.

This library will return the same ID for any app on the device asking for the OpenUDID, and stores its information in a UIPasteboard (typically used for copy/paste operations).

This library addresses the issue that CFUUID has with being application specific. However, it has the following limitation: the user may opt out of having an OpenUDID for their device.

If your application can live with that happening, here’s an example of how you use it:

#include "OpenUDID.h"
NSString* openUDID = [OpenUDID value];

That’s nice and simple, but it still has its limitations.

SecureUDID

This option will allow you to access a device identifier for your app, which is encrypted when it is stored to make more secure. This option has the same limitations as CFUDID in that it is per app per device, not just per device, and it has the same option for users to opt out of having a SecureUDID accessible from your apps.

Whilst this solution seems the most secure, it does present the same limitations as some of the other options explored. Here’s an example of how to use it:

#import "SecureUDID.h"
NSString *domain = @"com.example.myapp"
NSString *key = @"difficult-to-guess-key"
NSString *udid = [SecureUDID UDIDForDomain:domain usingKey:key];

Slightly more complicated than OpenUDID but not quite as much trouble as managing it yourself. SecureUDID also uses a UIPasteboard to store its information, which means that it will not persist between device restores.

MAC Address

There is one more option which we wouldn’t recommend which is using the device’s MAC address for one of its network interfaces. This has a few risks associated with it, namely that it could potentially identify hardware which Apple seem to be discouraging. In the future, what if they decide the MAC address is privileged information too?

Also, the MAC address can be spoofed on a jailbroken device quite easily. Whilst this option may be a simple drop in for something device specific, we would steer clear of it and look at using another solution outlined above.

Conclusions

If you’re looking for a stand in replacement for the uniqueIdentifier, then unfortunately you’re out of luck — unless you’re willing to use the MAC address, which can have its own problems.

The choice between the other three options outlined here really comes down to an analysis of what you really require in your app. Doing it yourself with CFUUID is certainly simple enough, and it appears to be the most flexible because you have ultimate control over the ID you store.

That said, if you’re looking for something quick to integrate, the two libraries given are both superbly simple to use. However, with both you run the risk that a user will completely disallow use of an OpenUDID, or SecureUDID on their device, and if that’s the case, they’ll be useless to you.

References

https://github.com/kishikawakatsumi/UICKeyChainStore
http://www.leesilver.net/1/post/2011/8/disabling-arc-on-certain-files-in-xcode.html
http://shaune.com.au/ios-keychain-sharing-data-between-apps/
https://github.com/ylechelle/OpenUDID/
http://www.secureudid.org/
http://developer.apple.com/library/ios/#documentation/uikit/reference/UIDevice_Class/DeprecationAppendix/AppendixADeprecatedAPI.html#//apple_ref/doc/uid/TP40006902-CH3-SW12
http://oleb.net/blog/2011/09/how-to-replace-the-udid/

Kumulos: A Place for Cats

We’ve been busy putting together a new tutorial app for storing photos in our backend as a service, and it’s now ready for you to enjoy.
Kitten from placekitten.com

Armed with the sample XCode project and video walkthrough, it’s never been easier to create a mobile backend to store your data. So if you need to store holiday snaps, or a collection of cats in your next project — there’s an app for that!

Check out the tutorial today and learn how to get the most out of our API service for creating mobile app backends quickly and easily.

As always, if you have any questions or comments, just let us know by posting on our community or dropping a line to [email protected]

Example Photo Storage App & iOS Bindings Update

Hello everyone,

We’re excited to announce that we’ve been putting together a nifty example app which stores photos in Kumulos, and it will be landing with you next week. Learn how to model the data stores in the backend, and retrieve them through an API service from the app. It’s the perfect springboard which will allow you to get a handle on using our cloud service to enhance your mobile app projects.

In addition to this tutorial app, we’ve released an updated iOS ARC library which addresses a data storage issue affecting some users.

With the update and forthcoming tutorial, you’ll be armed to deliver even more feature-rich apps to your clients with less effort and fewer technical challenges.

We love to hear what you’re building with our backend as a service, so if you’re putting together the next Instagram or Draw Something, drop us a line and tell us why it’s cool (email Chris on [email protected]).

Cheers,
The Kumulos Team

Using Kumulos with the OSX Lion App Store

This month brought another high-brow Apple media event, and with it more juicy news for Apple iOS developers. Only this time the news isn’t centred on iOS, its all about OSX. In a nutshell Apple’s much respected and coveted app store distribution model is coming to OSX. As of OSX Lion coming 2011, iMacs, Mac Pros, MacBooks and Mac Minis will all have their own app store – presumably separate from iTunes.

This is absolutely fabulous news for developers. There are literally hundreds of thousands of developers world wide who, although perhaps never having actually done it, are equipped with the skills and expertise to build Mac OSX applications. Personally I was both amused and astonished at how similar the two systems are to build for. This is hardly surprising when you actually think about it, iOS is essentially a stripped out version of OSX and even runs the mach kernel. So this awesome distribution channel extends an iOS developers skill set across across an extra 20 million or so machines, almost instantly.

Developers can start submitting applications to OSX in November and we can’t wait.

So what does this mean for Kumulos? Well you can actually start building OSX apps with Kumulos immediately, and theres nothing stopping a cross over between devices – fancy building an iPhone app that talks to the same database as a native desktop OSX app? No problem, couldn’t be simpler – just load use the same bindings for both apps.

Getting stuff into Mac users hands has always been a little more difficult, but with a 70/30 split on sales this business model makes a tonne of sense. Removing all the distribution headaches from development studios allows them to focus on good software, not payment gateways and invoice processing.

Got an idea for an OSX app that uses Kumulos? We’d love to hear about it.

Make PHP & MySQL Vanish from iPhone Database-driven Apps

database

Our initial look at the tools available for working with databases and push notifications in iPhone app development showed us that there was nothing currently ready for what we wanted. We were fed up of writing PHP and MySQL code to glue databases into iPhone apps and send push notifications. We thought there should be a better way than re-writing the same core functionality time and time again. With that in mind, we set off to develop a tool to reduce our development costs.

So now you understand a little about why we developed Kumulos, let’s take a look at what it does, and why it’s more than slightly magical.

First off, Kumulos gives you a really simple way to create a database for your iOS (iPhone, iPad, iTouch) and OSX applications. No need to write any SQL or worry about managing the database from a command line. Our database tool was the first stage of the project and it gives you the ability to work with databases via a drag-and-drop interface.

We thought about how to make the developer’s life easier and so we started to take the repetition out of database design. Kumulos gives all of your tables a primary key (unique identifier for each record), and time created & updated fields by default. The time fields get filled in as if by magic every time you work with data, and can provide useful information for your apps.

Something we really wanted was to be able to define the relationships between data so that there’s less to think about in your iPhone app when it works with the database. We chose to abstract relationship modelling into a “belongs to” phrase. Data in the database can “belong to” other data. Pretty simple, but incredibly powerful.

Once we’d got the database tools working smoothly, we set about tackling the next challenge: how to allow you to design methods that work with the database without having to write SQL or know a web scripting language?

“I know! We can have drag-and-drop ‘actions’ that will let people build API methods from a set of building blocks!”

So, after a quick sketch, we developed an amazing interface to design API methods. It allows you to tell Kumulos what you want to do with your iPhone app’s database. By dragging. And dropping.

Once you lay out a set of instructions and hit “save”, the methods are simultaneously turned into native server-side code, and Objective-C libraries. You can achieve seamless iPhone database integration without having to write ANY of the PHP or MySQL yourself. That’s a pretty good deal if you think about it.

Kumulos manages all the nitty-gritty, repetitive stuff that slows down creating database-driven mobile applications.

We wanted to make it intuitive and fast to develop databases that could instantly talk to iPhone and iPad apps. We wanted to enable the developer to feel as if they could just jump in and start working, letting Kumulos make sure things line up properly.

The result is an incredible new tool for creating databases that can interface with mobile applications.

Sound good? Get started in Kumulos today with a FREE trial.