Let's Build Mobile Apps That Always Work

So let’s just put it out there.  I want to build great apps and I know you want to build great apps.  We both know that apps that don’t always work and aren’t always fast just aren’t great.  They just aren’t.

I’ve spent my last 18 months at Couchbase talking to tons of developers and customers about exactly what it means to build apps that always work and are always fast.  Most recently I’ve been talking about this in the context of User Experience (UX) since that is the new hotness that everyone likes to talk about.  Delightful User Interface (UI), delightful interaction design, delightful this, and delightful that.  It’s actually quite simple: for a great UX, build apps that look great, behave as expected, are always fast, and just work – all the time.

One of the key UX problems that most apps run into is availability.  Sounds like a network problem, right?  Sort of.  Actually while the network is the cause of an app not being available, it is not the problem. The problem is where the app’s data is located.  Data location dictates app reliance on the network.  If an app has to run to the cloud every time it needs to read or write any little piece of data, then it’s going to have problems. If the network isn’t available, the app can’t get to the cloud and isn’t going to work.  If the network is slow then getting data from the cloud will be slow and the app will be slow.  

So how should your app work?  We built this infographic to talk about it in a little more interesting way.  Check it out:

So the answer is…Local and remote data + sync.

We aren’t the only ones doing this (but I think we are doing it best). Although many may try to lay claim as the best database/platform for mobile, they fail to meet the minimum requirements to even be in the game.

Ok…let’s do it.  Your users are going to love it – on the go, in the air, underground, in a crowd, on the job, or anywhere else.

Learn more at http://developer.couchbase.com/mobile 

P.S. Writing apps this way always results in TONS less code.  You write against a local database with all the concerns of networking and distributed computing being handled by the database.  Most of the time you won’t ever need to touch a network connection (how great is that!).  You will mostly be writing code to handle UI and UX concerns and the rest of the concerns are pushed down to the data layer.