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.

Kevin Whinnery: Comparing Titanium and PhoneGap

Really nice and lengthy look at the two main cross-platform frameworks out there:

whinnery:

A common question I get asked at developer events and conferences is how Titanium compares to PhoneGap. I thought I would take some time to explain how each technology works at a high level, and assess how the two technologies compare to one another.

From 10,000 feet, PhoneGap and Titanium…

Source: whinnery

Parse & StackMob: Some Thoughts

I think Parse is great: I have said as much before - but I also wanted to know a bit about the alternatives that were out there. StackMob seems to be Parse’s main competitor: there are others around, but they are either rather small or part of a much bigger ecosystem (e.g., Appcelerator Cloud Services): Parse and StackMob have both staked their claim as the mobile back-end provider.

Outsourcing your app’s backend is quite a big decision: the last thing you want is your provider to disappear into the dead of night never to be seen again. In the interest of fairness I thought I’d do an objective comparison of Parse and StackMob - hopefully this will prove useful to those looking to use a cloud provider for their next app. If you think I’ve made a mistake or omission in this comparison please do get in touch - it’s just my personal opinion, and perhaps you disagree.

Introduction

Parse and StackMob are backend as a service, or ‘BaaS’, providers who specifically target mobile apps (both native and web). They provide APIs for account management, object storage, file uploads, and push messaging amongst other things.

Parse has been around for just under a year, and is backed by $7 million in funding.

StackMob was founded over two years ago, and has a similar amount of capital behind it ($7.5 million).

Both companies have similar goals, but as we’ll see go about it in very different ways.

The Basics

First off, here’s what you get out of the box with both providers:

  • User management with social (Facebook & Twitter) integration
  • Object storage and retrieval (with GeoSpatial support)
  • Push messaging
  • Native SDKs
  • REST APIs
  • Built-in scaling

There’s a significant amount of overlap, but the proof is in the details. As a mobile app developer I’m particularly interested in the native SDKs that are available, so let’s tackle that first.

Native Clients

Both Parse and StackMob offer platform SDKs for Android and iOS. From the outset, I feel Parse has considerably better documentation and I find their SDK much easier to integrate and use. Parse also have the killer saveEventually feature, which will automatically push data back to Parse when the user is next online, and will keep trying until it succeeds. This can save a lot of code, because you don’t have to worry about the user being offline or the request failing - the next time your app is running with connectivity the Parse SDK will automatically complete the operation.

To get a feeling of how the two SDKs operate here’s the Android code you’d use to save a single object with a single property:

Parse
    ParseObject gameScore = new ParseObject("comment");
    gameScore.put("body", "Hello world!");
    gameScore.saveEventually();
StackMob
    Map<String, String> args = new HashMap<String, String>();
    args.put("body", "Hello world!");
    StackMobCommon.getStackMobInstance().post("comment", args, new StackMobCallback() {
        @Override public void success(String responseBody) {
        //POST succeeded
    }
        @Override public void failure(StackMobException e) {
        //POST failed
        }
    });

The iOS code is broadly similar: I have cheated a little, because as far as I know there’s no like-for-like saveEventually method in StackMob - regardless, I personally find Parse’s implementation to be cleaner.

If you’re an iOS developer Parse also provides a series of native UI components for you to quickly integrate into your app, such as log-in and sign-up views. I don’t find these particular useful myself, but I can see their value for those looking to get something together in a quick-and-dirty environment like a hackathon. Parse also update their SDK regularly (weekly, and sometimes daily), although it is closed source (in contrast to StackMob, but more on that later).

File Uploading

Amazon S3 is the name of the game here, and it’s used by both providers to store binary data. However, Parse encapsulates files in a PFFile object, and makes retrieving files as easy as retrieving normal data objects. StackMob does not: you’ll be given the Amazon S3 URL, and it’s up to you to figure out how to download it. For native apps this can add a fair amount of code, particularly if you need to sign and authenticate your Amazon S3 URLs.

You’ll also need to set-up your own Amazon S3 account with StackMob, whereas Parse take care of the actual storage process for you. Parse’s free-tier includes 1GB of storage, and 20 cents per additional GB. Their Pro package offers 10GB, and a reduced rate of 15 cents per GB. Out of the two, Parse appears to offer the quickest and easiest way to deal with binary file storage for native app development.

Server-side Logic & Versioning

Parse doesn’t currently support custom server-side code, so this is a clear win for StackMob. For many developers this will make StackMob the obvious choice, in which case there’s probably not much point reading on! I would suspect this is fairly high on Parse’s most-wanted list, as for many people it’s going to be a big deal.

StackMob also offers versioned APIs, a feature I’m not using so won’t go into too much detail on: suffice to say, this potentially could be quite important for you depending on your requirements.

Free Tier

There’s no competition here: Parse’s free tier goes way beyond what StackMob offer:

Parse StackMob
API Calls 1,000,000 60,000
Push Notifications 1,000,000 60,000
File Storage 1GB n/a
Additional Calls 7¢ per 1,000 $1 per 1,000


Of course, there’s no guarantee these tier limits won’t be adjusted in the future…you’d be rather foolish to plan your business model around it. But if you’re looking for something to power your ‘weekend-app’ Parse’s free tier is very hard to beat.

Portability

The ability to bulk export your data is very important: who knows what lies around the corner. It wouldn’t be unknown for a service to be acquired and disappear into the night. Fortunately, both StackMob and Parse will export your data should you ever want to migrate away. StackMob’s native SDKs are also open-source, and available on GitHub, which could be very helpful should you wish to move onto a different platform or internal solution. Note, however, that StackMob require you to request a data export through support, whereas Parse will let you generate exports through their web interface at-will.

Summary

Doubtless by now you’ll have drawn your own conclusions, and you might not agree with mine. From my own perspective:

Parse wins on…

  • Price: Parse’s free tier is sixteen times larger than StackMob’s, and their Pro package is similarly better priced for the number of API calls you get.
  • File storage: if your app needs to support things like photo or video sharing you’ll find Parse’s PFFile support much more intuitive than StackMob’s integration with S3
  • Speed: in my own experience, getting up and running on Parse is a lot easier than StackMob. Parse also seem to be rapidly iterating, with new platform features going in every month. I started using Parse for my apps in January: in just over four months a number of hugely helpful features have been added
  • Simplicity: features like saveEventually and native UI components make Parse highly accessible.

StackMob wins on…

  • Maturity: features like server-side code and versioned APIs show what a year’s head start can achieve (although I’d place even money on Parse catching up)
  • Enterprise: A number of StackMob’s platform features such as analytics and distinct development/production environments lend themselves well to an enterprise buy-in.
  • Web apps: I haven’t touched upon StackMob’s hosted HTML feature because I’m primarily a native app developer, but it’s a nice feature that may be useful to you if web is your thing.

If you came here hoping for a clear-cut winner you’ll doubtless be disappointed. StackMob is very attractive for those building apps that require complex business logic, and if you’re trying to sell a BaaS provider into your company you’ll probably have more success with StackMob.

On the other hand, I’ve never felt the same kind of joy and happiness using StackMob as I have with Parse, and the rapid roll-out of new platform features makes me excited to see what the future will bring. I will be using Parse at the next Hackathon I’m at, simply because it’s the quickest way I know to get a backend up and running.

In the end, both services have much to offer mobile app development, and I’ll be revisiting this post in the next few months to see how much has changed.

Erratum

@steveflack has pointed out that my Twitter avatar has an error in it: since appeasing the Twitter Gods by joining last week I had a quick hunt around my laptop for a suitable photo and found a three year old grab of some code that I’d photographed for some reason (the reasons for doing so escape me).

Steve correctly points out that in my avatar [super dealloc] is called before everything else. In mitigating circumstances, svn blame informs me that I was not behind this particular sin. By sheer coincidence I was working on the codebase the picture came from today, and it’s now happily fixed. I would offer to buy Steve a beer, but I believe he brews his own which are probably of a much higher quality.

Perhaps I should correct the avatar too, but for posterity maybe it should stay!

Twitter, Joined

Going beyond ‘fashionably late’, I have finally dived into Twitter, a ‘mid-life social-media crisis’, if you will.

ReactiveCocoa: First Impressions

GitHub have just open sourced their ReactiveCocoa framework (or RAC for short) which powers their GitHub for Mac App. It’s a very cool piece of code, but reactive programming can also be a scary concept if you’re not familiar with it. I’ve been playing around with the framework today and have really enjoyed what I’ve found - I’m definitely going to be looking to integrate ReactiveCocoa into my new projects, and I think it’s going to both save a lot of time and make my apps more responsive.

What is ReactiveCocoa

RAC [Reactive Cocoa] is a framework for composing and transforming sequences of values

But what does that actually mean? To get to grips with RAC it’s helpful to understand what reactive programming actually is. Let’s take the following assignment:

x := y + z

In a ‘normal’, or imperative, language like C this expression evaluates instantly. If you were to change the values of y or z at some point in the future x would be unaffected. In reactive programming, the value of x would be updated automatically based on the future values of y and z.

Imagine for a moment how we might achieve a reactive programming paradigm in Objective-C: this sounds like a job for Key Value Observing, or KVO: a mechanism that allows objects to be alerted to property changes. KVO has some problems though - it’s not the easiest API in the world to understand, and the syntax in Objective-C is not that pretty. KVO also still doesn’t support blocks, which can make our code unwieldy.

ReactiveCocoa solves these problems by providing a vastly improved interface for key-value observing:

[RACAbleSelf(self.username) subscribeNext:^(NSString *newName) {
    NSLog(@"%@", newName);
}];

… and that’s it. But ReactiveCocoa can do much, much more, as well. Let’s look at some examples.

UITextField Madness

Here’s a fairly common scenario: the user is asked to input a username into a UITextField. Usernames are at least six characters long, and we want to visibly show when the input is valid. To do this we’ll make the background of the text field red for incorrect and green for correct input.

Normally we’d use a UITextFieldDelegate, but if we have more than one text field to check and differing validation criteria this is quickly going to become an unwieldy amount of code. But with ReactiveCocoa we can do this in six lines using blocks:

// Bind a NSString property to our textfield
[self rac_bind:RAC_KEYPATH_SELF(self.text) to:self.view.textField.rac_textSubscribable];


// Change the text field background to represent valid/invalid input    
[RACAbleSelf(self.text) subscribeNext:^(id x) {
    if ([self.text length] > 5) {
        self.view.textField.backgroundColor = [UIColor greenColor];
    } else {
        self.view.textField.backgroundColor = [UIColor redColor];
    }
}];

Every time the user changes a value in the text-field the subscribeNext block is executed, with no delegates and no mess. This is a considerable improvement on traditional approaches such as delegates or key-value-observing.

Completion Callbacks

ReactiveCocoa also lets you get callbacks where there were no callbacks before. For example, merging two large arrays could take some time, and perhaps you want to update your UI upon completion.:

[[RACSubscribable merge:[NSArray arrayWithObjects:[self bigArray], [self veryBigArray], nil]] 
     subscribeCompleted:^{
        NSLog(@"Merge complete, reloading table");
    [self.tableView reloadData];
}];

Beyond KVO

‘So what?’, I hear you say, ‘It’s a nice wrapper for KVO, big whoop’. Well, it gets better: in addition to a simply KVO API, ReactiveCocoa lets you express complex conditional behaviours.

GitHub’s example is as follows:

[[[[RACAbleSelf(self.username) distinctUntilChanged] take:3] 
        where:^(NSString *newUsername) {
            return [newUsername isEqualToString:@"joshaber"];
        }] 
        subscribeNext:^(id _) {
            NSLog(@"Hi me!");
        }];

Here’s their explanation of what’s going on:

We watch username for changes, filter out non-distinct changes, take only the first three non-distinct values, and then if the new value is “joshaber”, we print out a nice welcome.

Using KVO alone this simple isn’t possible: we would need to track and retain the value of username to compare it with the new value and keep a counter around to increment every time we receive a non-distinct value. This would certainly be more than six lines of code.

Scratching the Surface

This is really only the beginning of what ReactiveCocoa can do: it’s a very powerful tool, with a lot of applications. If you’re using Key-Value-Observing already I think RAC will save you a lot of time. If you’ve been put off KVO because of its complexity then ReactiveCocoa will definitely get you on the right track. I can already think of lots of use cases, particularly around chaining of asynchronous network operations and input validation.

ReactiveCocoa is totally open source, and you can get hold of a copy here. Be sure to clone it rather than download a ZIP file from GitHub, because you’ll need to check out some submodules for the included examples to work correctly - the commands you’ll want to run are:

git clone https://github.com/github/ReactiveCocoa.git
git submodule update --init

Happy coding!

RIM Make a Bet

…if BlackBerry 10 devices sell as well (or rather, as poorly) as Windows Phone 7 devices did during their first 12 months I can see RIM regretting this. I hope their projects are based upon a worst case scenario, and not just an ‘average’ one.

Pass by Parse

If you happen to read this blog regularly (unlikely, given my traffic stats, but still) you’ll know I quite like [Parse], the instant mobile backend service.

I have, however, noticed one problem with the service: if you happen to tell people about the service with a normal (OK, ‘British’) accent you can encounter some communication problems:

You say:

Check out this great service at parse.com

Your colleague hears:

Check out this great service at pass.com

…because unlike American English, ‘pass’ and ‘parse’ have identical pronunciation. My suggestion to Parse: buy some AdWord keywords for pass.com.

Update About 12 hours after I wrote this TestFlight [updated their blog] with an apology and information about the downtime, so a plus there. On the other hand, it pays to keep users in the loop even whilst downtime is occurring. In the future maybe TestFlight could consider some sort of status page a la Twitter et al. How not to communicate with your customers TestFlight went down today. TestFlight is a development tool used by iOS developers to ease the pain of distributing beta versions of apps. Because (I assume) the company is US based, and because the downtime seemed to occur at about 12AM PST, it went unfixed for a good eight hours or so. Now, TestFlight is free, for now. A free service going offline for a few hours is nothing to write home about. On Twitter some people were getting quite indignant, but the old adage holds true - &#8220;you get what you pay for&#8221;. However, TestFlight also isn&#8217;t a charity. They need users to make money, whether it&#8217;s through selling premium packages in the future or through some other business model. Users don&#8217;t like unreliable sites - so you&#8217;d expect TestFlight to be fairly up-front with their users about what exactly went on. No such luck: TestFlight&#8217;s twitter account and blog are resolutely silent on the matter - no mention of any downtime at all. They&#8217;re in complete denial. Some users are understandably frustrated, and many are looking at alternatives: @nkgraham I&#8217;m just looking at @hockeyapp now. Tired of TestFlight being down. I&#8217;d rather pay a small fee for increased reliability— Phil Harvey (@pjharvey) April 23, 2012 Anyone have experience w/HockeyApp over TestFlight? Really unhappy with TF and want something more reliable.Hesitant because of big move— Mel Gray (@melgray) April 23, 2012 Again, I don&#8217;t think people inherently expect a free product to be flawless. But they do expect some communication: some acknowledgement that there&#8217;s actually a problem, and what will be done to prevent it from happening in the future. Hopefully in the future TestFlight will think about how best to leverage their corporate communications to help, rather than frustrate, their users.
View Separately

Update

About 12 hours after I wrote this TestFlight [updated their blog] with an apology and information about the downtime, so a plus there. On the other hand, it pays to keep users in the loop even whilst downtime is occurring. In the future maybe TestFlight could consider some sort of status page a la Twitter et al.

How not to communicate with your customers

TestFlight went down today. TestFlight is a development tool used by iOS developers to ease the pain of distributing beta versions of apps. Because (I assume) the company is US based, and because the downtime seemed to occur at about 12AM PST, it went unfixed for a good eight hours or so.

Now, TestFlight is free, for now. A free service going offline for a few hours is nothing to write home about. On Twitter some people were getting quite indignant, but the old adage holds true - “you get what you pay for”.

However, TestFlight also isn’t a charity. They need users to make money, whether it’s through selling premium packages in the future or through some other business model. Users don’t like unreliable sites - so you’d expect TestFlight to be fairly up-front with their users about what exactly went on.

No such luck: TestFlight’s twitter account and blog are resolutely silent on the matter - no mention of any downtime at all. They’re in complete denial. Some users are understandably frustrated, and many are looking at alternatives:

Again, I don’t think people inherently expect a free product to be flawless. But they do expect some communication: some acknowledgement that there’s actually a problem, and what will be done to prevent it from happening in the future. Hopefully in the future TestFlight will think about how best to leverage their corporate communications to help, rather than frustrate, their users.

Windows Phone & Updates

Last week, I bought a Nokia Lumia 710 - it’s quite a nice phone. In fact, for the price (less than $200 in the UK, pre-paid) I don’t think it can really be beat: speedy, solid, and a well put together piece of hardware, particular compared to the Android phones in that price range.

So it’s a bit sad and/or unfortunate that Microsoft are having a rough time getting their story straight over whether existing devices will be able to upgrade to Windows Phone 8, due later this year.

But that’s not what I’m here to complain about: no, it’s the attitude of analysts who seem to think it doesn’t matter. Here’s a quote from Gartner:

Consumers are buying based on today. People bought iPad 2s right up until the new iPad > was released. In the end of the day, it becomes a non-issue.

…so there are two issues with this. Firstly, iPad 2s are still being sold. Whereas, like with desktop Windows, you’d imagine the transition between Windows Phone 7 and 8 to be fairly binary. And secondly, Apple have always provided all devices under contract the latest software: iOS 5 runs all the way back to the iPhone 3GS.

When you buy an XBox you’re ‘buying for today’. When you buy a phone, you’re usually buying into a contract. It’s a commitment. Hopefully Microsoft will do the right thing, and at least allow Lumia devices being sold today to have an upgrade path to WP8.