Tag: Apple

iPhone 5S’ fingerprint scanner; real or no?


We talked yesterday about the iPhone 5C and how, despite being the “ugly sister” of the 5S, it’s the one getting all the attention, mainly cause it’s new. Apple have never done budget before, so we’re all curious to see what it can do with the 5C.

Having said that though, we do still have the 5s on the way, and from what scant details we’ve had, there is highly likely to be a dual LED flash there, as well as; potentially, a fingerprint scanner. Now we’ve been hearing about fingerprint scanning tech in smartphones for years. The way we interact with them it seems almost like a done deal to the imagination.

We’re always putting our fingers on the screens, we don’t need to let anyone else use our phones so we don’t need multiple user accounts and also, it’s some mission impossible style stuff. Having a biometric lock, or using biometrics in general is something that makes perfect sense in a smartphone. Google are already doing it with Face Unlock (not that it works very well, but the sentiment is there) and the Moto X has its “always listening” voice activation.

Apple have always been trend setters and disruptors. If they release a phone with fingerprint scanning tech, it will only be a matter of time before the major Android manufacturers are out in force doing the same thing. Although there is even a rumour that the 5s may even sport NFC, despite Jobs having said that he didn’t see any point in the technology (yeah, cause Apple have been doing a great job of listening to those mantras).

As always, the “s” models of the iPhone are only a stepped upgrade rather than a leap and a bound, but we hope that fingerprint scanning tech isn’t the only thing the 5s brings to the table. After a fairly stale 5 launch and nothing exciting all year, Apple needs something to knock it out of the park. So now all eyes turn to Sept. 10th. We shall see what Apple brings to the fore.

Until then, if you’re an iOS app developer that wants to grab the new 5s excitement but need a Mobile Backend, talk to us at Kumulos. We’ve got you covered with a Mobile Backend as a Service that’s powerful, customisable and there for you in whatever form you need it to be. So why not talk to us today?

The iPhone 5C, Apple’s salvation or poison?


The rumour mill has been turning in overdrive since Apple’s announced September 10th 2013 conference date. We all speculating exactly what Cupertino are going to bring to the table after what feels like a long hiatus.

The 5C has had a lot of attention in the leaks circuit. Photos are cropping up daily, but we’ve not had an official yay or nay from Apple (not that’d we expect one, honestly).

The question, and we’ve looked at this a little bit before, is just what the 5C is going to do for Apple upon its release.

Apple is built on a premium branding, it’s whole design ethos is aesthetics, user experience and quality based. Releasing a budget handset seems like a step in the wrong direction when you take all that into account. It seems like it will cheapen the brand, add that plasticy tinge to an otherwise shiny metallic logo.

But then, the 5C isn’t for the premium crowd to begin with.

It’s for the emerging markets in India and China, and it’s for those of us who like our SIM only packages and aren’t as fussed as to whether we have the latest and greatest piece of hardware. After all, and it’s sometimes hard to believe when your daily existence is to keep yourself up to date with the cutting edge, but not everyone wants to be running a 2 month old handset that can run half the stock market on its own. A good majority of customers just want a handset that’s capable, reliable and of good quality; and the 5C will likely provide all that in spades.

It also makes business sense for Apple because their only budget offerings right now are the 4 and 4S, and they’re still being manufactured with aluminium and glass, which is expensive. The margins are low on these handsets now, and their 3.5inch form factor just doesn’t really cut it these days. The 5C will have the same size and shape as the 5 but will be much cheaper for Apple to produce.

When thought of that way, it looks like we could be onto a winner. What it may also do is inspire a whole new range of iOS app opportunities as those who couldn’t afford an iPhone before now suddenly have one in their grasp.

Whatever the case, Kumulos will be here to support your app development project from its initial conception all the way through to its launch and beyond. Our Mobile Backend as a Service is designed by app developers, for app developers. So why not contact us today?


The future of Apple, is it really that uncertain?


There’s been a lot of speculation in recent days about the future of Apple. They have been quiet essentially all year, with the biggest update to any of their products being the the MacBook Pro. Not that that was any slouch, the jet-engine looking computer promising to be a mid-range server instead of a computer in terms of power.

And it’s not like they haven’t got things in the pipeline, the iPhone 5s is almost certainly coming, and the budget iPhone has been heavily rumoured to be in the works; oh and there’s probably some kind of iPad update coming too. So lots of stuff on the horizon, but it’s being met with an overwhelming “meh”.

Don’t get us wrong, there will still be people lined up around the block to get their latest iCrack; a good number of us at Kumulos will be right there with them. Apple isn’t one of the biggest companies in the world for no reason after all. The trouble is that we all want more.

And that “we” happens to include the company’s board of directors, who are getting increasingly antsy with Tim Cook, claiming that the company isn’t “innovating fast enough”. Aside from the somewhat questionable untone that innovation is somehow something you can just control the pace of rather than something that comes in unpredictable fits and starts, there’s also the issue of whether Apple is really doing badly.

The answer is no.

Of course it is, they have more money than half of the developing world. Even if they start to bleed money for a couple of years whilst they look for that next big thing; they’ll still be doing better than Microsoft or Google in terms of pure profit. And if money is the goal, then why is everyone worried?

The unlying issue here is of course, that Apple showed absurd growth during the end of the 00s and they kept doing it for years. Whereas most company growth is only in spurts, Apple kept a consistent push going all the way through from the release of the iPhone to around Jobs’ death. And now they’re still growing, but they’re not growing fast enough. Wall St wants them to be pushing that 80% growth mark still, but since when has any company ever managed to do that? The answer is not one (that we know of at least).

Like an athelete who, due to a perfect storm of events, sets a near unbeatable record during one Olympics, Apple have raised the bar so high that they themselves can’t measure up in the long run. But that doesn’t mean they’re doomed, just returning to a more sustainable pattern of growth. Sure, it’s anti-climactic and a little disappointed, but what do you want? A flash in the pan, or a slow burn that lasts as long as you want it to?

$2.1 Trillion will be spent on IT in 2013 according to Forrester


The numbers are in folks, and IT looks like it’s only set to grow this year. Forrester just released their latest estimations of spend on IT, and the overall breakdown is that we are looking at around $2.1 Trillion spent by organisations around the world and that mobile apps are getting the heaviest investment.  The U.S. will also be the country leading the charge in investment in IT.  Gartner also recently released figures for the same subject but they had a much more optimistic view, pointing towards the higher figure of $3.7 Trillion.

The U.S. is looking stronger now currency wise and this is having a knock on effect on its position in the spending chart, with the stronger US dollar allowing them more financial muscle globally. The continuing recession in the EU and China’s now inevitable economic growth slow down are also aiding this current strength in the IT market.

Overall, the two main trends to be taken away from this are as follows:

Software is big

Out of that estimated $2.1 Trillion, software makes up a sizeable chunk, equating to something along the lines of $542 billion. “Software is where most of the big changes in technology are taking place,” writes Bartels, one of the writers involved in the report. This is something of a two part evolution. SaaS (software as a service) is becoming the new model for many major software developers, for example Adobe’s new Creative Cloud subscription service that has replaced their one time purchase model. The second part is mobile apps. Out of the entire spending on IT, apps are seeing a massive investment of over $230 billion alone. This, of course, bodes well for app developers out there.

Apple and tablets are where hardware is going

As we recently reported, the PC market is shrinking fast, and even though it’s still currently the biggest market in IT hardware, it’s fading out. If you’re looking for growth, of course you should look to Apple and tablets, with the iPad being the most significant merger between the two. Apple will be taking $14 billion more this year than last from the iPad and tablet market, whilst the tablet market itself will grow by a very noticable 36% or $21 billion.

So if you’re investing in IT, the way to go is Apple, tablets, SaaS and apps. If you’re already an app developer, you’ll be pleased to know that you’re on the right track. And as service providers, at Kumulos we’re pleased to provide you with a Mobile Backend as a Service that is designed to help your apps and you stay ahead of the curve and to get you a slice of that big IT investment pie.

So why not talk to us today?

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);

[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.


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.


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.


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.