Collection Views

Making Life Easier Since 2012™

One of the great things about Cocoa / iOS development is also one of its downsides: you don’t need to know exactly what’s going on behind the scenes. Judging from some of the questions that come up on StackOverflow with surprising regularity, a sizeable number of users don’t realise that a UITableView is actually recycling views and cells to conserve memory.

This introduces a lot of problems when developers come to implementing things like galleries. Almost every other day there’s a question along the lines of “I put ten images into a scroll view and my phone crashed, what’s going on?”. Inevitably it’s down to memory simply running out. Until iOS 6 you were faced with several far from ideal options to fix this: write your own recycling system, use one of several open-source options (of varying quality), or hack a UITableView to pieces.

Collection views change that, in a good way. Some people describe them as “gallery views”, but that’s actually not the case - UICollectionView goes deeper than that. Unlike a table view, the display logic (how your items are laid out on the screen) is totally decoupled from the recycling logic. A collection view is paired up with a layout class that describes where and how elements should be positioned.

The most common layout - a gallery - is provided through the built-in UICollectionViewFlowLayout class, but by substituting your own layouts you are free to display your items however you want: cover flow, 3D-like layouts, circular layouts, pile layouts (à la Mail) - they’re all easily achieved by switching out the layout class.

Version Parity

There is, of course, a downside to all these benefits: collection views are only available on iOS 6. To be honest, for many people this shouldn’t be a problem. Some of the apps I work on show over 80% of users running iOS 6, and that’s only two months after it was released.

However, there’s good news for those looking to implement flow and gallery layouts - Peter Steinberger has put together a great drop-in replacement class for iOS 4.3-5 that has a 100% compatible collection view API.

Stop Writing Custom Galleries

The upshot of this is it would be absolutely crazy to implement your own recycling gallery view from scratch, even if you have to sub-class a collection view or write your own layout to get the effect you want. Setting aside the fact that in the vast majority of cases using a collection view will save development cost and time, you’re also backed by code that’s received far more testing time than your custom written class ever will.

The take away lesson: collection views are a fantastic addition to iOS, and you should be using them wherever possible in your apps rather than custom or third-party code. Learn to love them, and you will be rewarded.

PINs and Needles

It’s well known that the more complex your password the more secure you will be. Exactly how to achieve that complexity is a matter of some debate, but at least we can all agree that 1234 isn’t going to cut it as your Gmail password.

Alongside complexity sits enforcement: some providers, like Google, simply require a minimum password length. Others are stricter: Apple’s list of requirements is too long to reproduce here, but includes such gems as “passwords must not contain more than 3 consecutive identical characters” and “passwords must have at least one capital letter”.

Despite all this complexity enforcement, many users do indirectly use 1234 to access not just their Gmail, but their social networks, photos, text messages, and more. I am of course talking about the PIN, unchanged since its debut thirty-five years ago, and often the only thing protecting a cellphone.

A Short Historical Detour

The modern PIN was invented by a Scot - either John Shepherd-Baron or James Goodfellow depending on your sources, who both claim some credit to inventing the modern day ATM. Shepherd-Baron’s machine required users to authenticate themselves with a four digit numeric code. Why four digits? Shepherd-Baron claimed his wife vetoed a six digit PIN, as four digits was the most she could remember1.

Even though ISO 9564 (the international standard for ATM systems) specifies PINs of up to 12 digits should be supported, the overwhelming majority of users and banks have stuck with Shepherd-Baron’s original suggestion of 4 digits.

But what does this have to do with phones? Twenty years ago, when SIM cards were actually the size of credit cards, making calls on the go could be an expensive business - your monthly plan was much more likely to come with 50, rather than 500, minutes. A way was needed to secure a phone and prevent someone running up a huge bill on a phone without the subscriber’s knowledge. A PIN was deemed to be the best option - after all, users were familiar with them from banking - and in 1992 in was mandated that phones should support a four digit security code.

What’s important to note is that at this point PINs didn’t really protect any data outside of an address book: phones made calls, and that was that. As time went on, more and more personal information made its way onto mobile, until we ended up with our phones basically containing carbon copies of our entire lives: our calendars, e-mails, social networks, photos, and more.

PIN Locking

Because a four digit PIN is self evidently not very secure (with only 9,999 combinations to try) both ATMs and mobile phones will lock users out after n number of incorrect attempts. Smartphones can even be setup to erase the entire devices after a set number of tries.

If you have had the misfortune of locking yourself out of your phone you’ll know you typically need to obtain a PUK (‘PIN Unlocked Key’) from your mobile operator. Here we see the first problem with PIN codes: you only need to read about Mat Honan’s recent experience to see that it’s not out of the question for an impostor to convince a customer service rep they’re you.

In fact, this is exactly what News Corporation did in the recent phone hacking scandal - by ringing up telcos and pretending to be subscribers, News of the World employees were able to convince telcos to release PIN codes to them, allowing unfettered access to voicemail accounts.

PIN Breaking

Whilst a four digit PIN is undeniably very insecure, there is of course one thing I’ve omitted - to make any use of it you’re going to need physical access to the phone in question.Still, this doesn’t offer us much hope, given how often phones can be misplaced, left at a desk, or stolen. Let’s assume we have access to the phone we want: how can we get into it?

Guess

Guessing is a risky gamble if you’re entering the codes directly onto the phone, as you may well be locked out. However, it’s not quite as risky as you might think - a University of Cambridge research paper suggests a significant minority use highly guessable PINs such as 1234 or their birthdate/year. Still, guessing is a very clumsy approach.

Brute Force

Given that a phone will typically lock you out after several incorrect attempts you may think you don’t have to worry about brute force. This was certainly true in the past - for a long time, PINs were stored directly on the SIM card. However, smartphones now typically store the PIN in flash memory - once you’ve imaged the phone onto another computer you can carry out an offline dictionary attack, given you as many attempts as you require.

Because a four digit PIN is so short, brute-forcing it is extremely straightforward. How straightforward? Here are some of Apple’s own estimates on how long it would take to crack an iOS 5 device with varying passcode complexities:

Complexity Time
4 Digit PIN 13 minutes2
9 Digit PIN 2.5 years[^apple]
6 character password 5.5 years[^apple]

Android is not immune either - several forensic houses have documented brute force approaches that can break ten digit PINs in an hour or so. The only

Social Engineering

Whilst not limited to just PINs, the fact users have certain expectations around PINs and phone locking means some very simply social engineering tricks can work exceptionally well. Users are not conditioned to treat phone PINs in the same way as their banking PINs - banks have spent considerable sums of money educating users to ‘shield’ their PINs by covering up keypads.

Phones can also be swapped out with identical devices that display ‘dummy’ lock screens - customs apps that look and behave like a traditional look screen but with one major difference. Rather than unlocking the phone, these apps will transmit the PIN being entered by the user back to you. It’s also going to display an ‘incorrect PIN’ error regardless of what the user entered, and after three attempts it will ‘lock’ the phone.

So?

You may well wonder whether you need to care about any of this. You might never let your phone out of your sight, and the idea that somebody might go to the trouble of duplicating your phone to get access to your PIN may seem laughable.

On the other hand, at this very moment several highly paid executives of News Corporation are awaiting trial for perjury and conspiracy to pervert the course of justice, all relating to offences involving breaking into services protected by four digit PINs. Many of victims were not celebrities, but ordinary people who for whatever reason found themselves in the news.

We’re Stuck in a Hole

Unfortunately, the PIN isn’t going away. Why? Because an expectation has been established: PINs are quick and easy to enter, and allow access to your phone in seconds. Apple is more than happy for you to use an alpha-numeric password, but wave goodbye to your 9-button keypad and hello to a full QWERTY keyboard.

Not to say that manufacturers aren’t trying different things: Google have introduced facial recognition lock screens for Android, although their effectiveness is dubious at best (Jellybean now has an option to require ‘eye blinking’ whilst unlocking, which perhaps tells you how badly the first iteration worked when presented with a photo).

So what can we do to improve PIN security? Whilst users requiring the highest levels of security may well accept using a highly complex password instead, I suspect the average smartphone owner will not. Biometrics are one potential avenue, but without custom hardware such as fingerprint readers the technology simply isn’t there yet.

One thing is certain: until we part ways with the PIN we’ll continue to live in the strange situation whereby your e-mails, social networks, and other sensitive accounts will require a complex password to view through a desktop, but allow total unfettered access with a simple four digit code on your phone.

  1. This sounds a little too apocryphal for its own good in my opinion. ↩

  2. iOS Security White Paper, Apple Inc, May 2012, working under the assumption of 80ms per attempt ↩

iZettle: Square Killer?

(Now with an update from iZettle: see below)

iZettle, a card payments company, is getting some press today due to their UK launch. They’re pitching themselves as a European Square, the key difference being they accept EMV ‘smart’ (chip) credit cards through their iPhone compatible reader. I’ve already blogged about Square’s difficulties with the Chip & PIN sector before, so I was interested to see how iZettle are tackling the problem.

Their solution is something of a compromise, mainly due to restrictions imposed by card issuers. Whilst anything to allow more convenient payments is good, I’m worried about how iZettle will deal with fraud and liability. Here’s why:

PINs and Terminals

Although iZettle’s reader takes EMV chipped cards, you don’t use your PIN to pay for a purchase. Instead, you sign on the iPhone’s screen. It turns out there’s a reason for this: card issuers only allow approved hardware terminals to be used for Chip & PIN purchases. There is simply no way to run PIN transactions through a standard mobile device.

This means that the only difference between iZettle and Square is the former reads cards using the chip, and the latter using the magnetic strip. In terms of security, the only advantage iZettle has is that it’s much harder to clone an EMV card. Unlike Chip & PIN proper, iZettle doesn’t protect against someone stealing your card - all they need to do is mimic your signature. What you sign on the screen with your finger is not likely to bear much resemblance to the signature on the back of your card anyway: this is hardly a blocker for fraud.

This would be less concerning if you as the retailer weren’t liable for fraudulent transactions:

Liability

If you search iZettle’s help portal for ‘Fraud’ or ‘Liability’ you won’t find any results. In fact, iZettle are very careful to avoid mentioning that in the UK retailers who don’t accept Chip & PIN are liable for all fraudulent transactions.

What does this mean in practice? Let’s say someone steals my credit card and buys something at a shop with an iZettle terminal. Later on, I find out my card is missing and call the bank. Who’s liable for that fraudulent purchase? Since I didn’t use Chip & PIN it’s the retailer, who ends up out of pocket.

To put it in plain English: it’s my understanding that by using iZettle you will be liable for any payment fraud your customers commit, rather than iZettle or the issuing bank. The only place this is mentioned on iZettle’s site is in their Terms of Service, and even then it’s opaquely phrased.

iZettle’s target market is clearly people who currently don’t take card payment. These people may not know much about how the market works, and may be totally in the dark when it comes to who’s liable for fraudulent transactions. I applaud iZettle for trying to shake-up the market, and I have nothing against them or the product. I do, however, think that they could be much clearer on their site in terms of who’s responsible for fraudulent transactions. iZettle have said they’re going to look at their FAQs, so hopefully some more clarity will be forthcoming.

Update 17/5/2012

iZettle have updated their FAQ page to make it clearer that liability mainly rests with the person taking the payment (in the small set of cases where a stolen card that hasn’t been reported is being used). I think this is a great improvement, and they’ve been very pro-active in dealing with it.

iOS & Android WiFi Consumption

ComScore have a report out that’s been passed around the usual suspects that looks at WiFi consumption across mobile devices in the US and the UK. The point that’s causing the most interes:

The analysis shows a significantly higher percentage of iPhones than Android phones connecting to the Internet via Wi-Fi networks.

Jon Gruber reckons this shows that:

a large number of Android owners use their devices just like they did their previous non-smart phone

I suspect this is true, but I don’t think it’s what driving increased WiFi consumption on iPhone. I think it’s more technical than that: it’s EAP-SIM. EAP-SIM is an authentication technology that allows clients to log into services using the SIM card as a set of credentials.

In particular, EAP-SIM can allow seamless log-in into secured wireless hotspots. Carriers can pre-load phones with a list of supported hotspots (for example, T-Mobile HotSpots or BT OpenZones), and devices can automatically connect themselves when in range. Even better, they can connect to encrypted networks rather than open ones, increasing user security.

This is completely automatic: users don’t have to even connect once. Carriers can use it to offload data from their own networks seamlessly - many already do, such as Vodafone in the UK. Updates can be send over the air, so compatible hotspots can be added and removed as a network operator so desires.

It sounds like a great technology, and it’s one that’s not supported by Android (it’s been an open issue for nearly two years now). But iOS has offered full support for some time, meaning users on iOS devices are being actively off-loaded from 3G to WiFi networks by carriers, often without realising it.

So whilst user behaviour could definitely be a factor, I think technology has its part to play: the ability of iOS to support WiFi EAP-SIM authentication naturally means a higher uptake of WiFi data by those with iPhones.

Add some ads, kill your battery

The Verge has a great story about researches who’ve profiled popular apps and found mobile advertisements are basically killing your battery.

In particular, analysis of Angry Birds on Android 2.3 revealed that 70% of the total energy consumption was taken up by uploading metrics and downloading adverts themselves.

The article is a little short on technical detail, so to extrapolate here: smartphones are highly optimised for energy consumption. A game like Angry Birds is not graphically taxing or complex: most mobile games aren’t - most devices are going to be handing the graphics over to a dedicated GPU, which brings both performance gains and significant energy efficiencies.

It’s a little different when it comes to transmitting data over a network: sending data is expensive, energy wise. You have to power up the radio, which is often one of the most energy consuming parts of a phone, and then keep it powered up for as long as you’re transmitting. And if your ad refreshes every thirty seconds…well, that’s a lot of work. Developers know this, or they should know it, because it’s well documented in both Google and Apple’s guidelines.

In my experience, developers aren’t taking enough notice of energy efficiency - users will pick up if your app is draining their battery, and they’ll move on to something that doesn’t. iOS has some great energy profiling tools within XCode/Instruments, and Android has similar energy profiling options: there’s really no excuse!

The Obnoxious App: Splash Screens

Everyone has an ‘obnoxious app’ - an app that you find useful, or really need to use for work or play, but is so obnoxious that actually using it opens up a world of pain. Perhaps it’s your carrier’s account management app, or maybe it’s an app for your favourite retailer.

I’ve got several of these apps on my phone, and I always wonder how they ended up to be so bad. It’s hard to understand how things could go so wrong, particularly on iOS where Apple provide generous human experience guidelines. In an attempt to warn people away from design decisions that you’re bound to regret later, I thought I’d collate some of the worst offenders into a series of posts. Today’s post is all about splash screens, and why you’re probably ‘doing it wrong’.

Some people think that mobile apps are following a very similar trajectory to the early web: certainly in terms of uptake and usage, but also in terms of repeating the same old mistakes over and over. Back when Netscape and IE were kings and Flash was owned by Macromedia plenty of websites had splash pages. Typically, these consisted of some overly complex Flash animation or pretty picture.

Nobody liked them:

Splash pages are useless and annoying. In general, every time you see a splash page, the reaction is “oh no, here comes a site that will be slow and difficult to use and that doesn’t respect my time.” - Jakob Nielsen, March 1999

…that’s from thirteen years ago. Today, web designers understand that splash screens and ‘intro animations’ on websites are representative of a fundamentally flawed design. Which leads you to wonder: why do app developers keep using them??

It’s not just small apps either - the O2 Priority Moments app is a particularly bad offender: not only does it have a video splash screen, it displays it every time you resume the app, even from the background. This is an app that had a huge media push behind it in the UK, with blanket TV advertising.

A lot of developers will argue that their apps are faster than the mobile web, and users appreciate that. Adding a video splash screen is akin to shooting yourself in the foot. You’re not helping your users, and you’re just slowing down their experience.

Imagine if you had to watch a video every time you started up your Mail or Browser apps? You’d go mad! Does anyone using video splash screens really think their apps need it? That users will appreciate the pretty animations? They won’t. Users will just stop using your app. I’ll leave it to Apple to sum up:

The launch image is not meant to provide an opportunity for artistic expression; it is solely intended to enhance the user’s perception of your app as quick to launch and immediately ready for use.

Quick Friday Review: Jira Mobile Connect

Recently I gave Jira Mobile Connect a spin: the idea is pretty simple. You integrate Atlassian’s SDK into your app, and any crashes get automatically logged back in Jira. There’s also a nice optional front-end UI you can use to communicate with users about issues they’ve logged.

Currently it’s only available on iOS, but the client code is open source and there’s some effort going on to get an Android client up and working.

It’s actually been quite an effective tool, but I think Atlassian are rather optimistic when they say:

Tired of deciphering one-star ratings on iTunes? Connect with users individually to learn more about their complaints or feedback.

Personally, I think Jira Mobile Connect is better suited to collecting feedback from test and QA users: I’m not totally sure larger development houses would really want customer facing feedback being put into Jira, and it’s also difficult to ‘bulk’ issues together (for example, you might have a dozen customers enquire about the same issue, and maybe you’d like to respond to them all at once).

But these are niggling issues: given obtaining crash logs can be quite unintuitive, any tool that automatically takes care of it and can log direct bug reports / issues is useful in my book. I don’t think I’ll deploy live apps with it in, but it’s definitely going to make a positive improvement to how I test apps generally.