inessential.com

NickB Snatched Up by Blog Company

Sat, 18 May 2013 14:51:58 -0700

Nick Bradbury — my friend, co-worker at NewsGator and Sepia Labs, developer of HomeSite, TopStyle, FeedDemon, and Glassboard — starts work at Automattic on Monday.

Congratulations to Automattic on hiring a great developer!

Identical Cousins 16

Tue, 14 May 2013 12:31:00 -0700

In this episode, Michael and I have the fun of interviewing Chris Liscio, who makes the super-mega-ultra-groovy audio apps Capo, FuzzMeasure, and TapeDeck.

Brentsplitting

Fri, 10 May 2013 19:51:23 -0700

I was a guest on Daniel Jalkut’s Bitsplitting podcast. It was fun! Many thanks to Daniel.

30 Minutes To Sync

Tue, 07 May 2013 12:21:20 -0700

Tom Harrington continues his series of posts on iCloud and Core Data.

I’ve seen addPersistentStoreWithType:etcetera: block for 30 minutes. And keep in mind, this is when iCloud is working normally. This is not an error condition, this is “working as designed.”

He suggests a solution: using two separate databases, one for normal use and one just for syncing, with custom code that shuttles data between the two.

That solution points to what bothers me about the whole thing, which is that this is all too tightly-coupled. Ideally your storage system and syncing system are not the same thing, and you could swap out one for another.

This would allow for flexibility and efficiencies that you can’t get when you just say “here’s my database; please sync it, iCloud.”

Apple and Backend Services for Apps

Imagine Apple announced something that worked like this:

You go to a website somewhere at apple.com and set up a backend for your app.
You create a database for it and a custom https API. You might have to write some code — but it would be in a popular scripting language, nothing weird. All this with a browser-based UI.
Apple provides a client framework for making calls to the server.
Authentication is completely taken care of — the system uses iCloud credentials, and your app doesn’t have to do anything. (It just knows if you’re authenticated or not.) In your app a user never has to sign in or create an account or anything like that.
Everything Apple stores is automatically encrypted. Apple’s server takes care of encrypting/decrypting automatically, so your code (in the client or on the server) never has to deal with that.
Apple’s system provides the ability run periodic tasks (like polling Twitter, App.net, or RSS feeds).

This would be more general than just a syncing solution, but you could use it just for syncing. Or you could add more sophisticated backend services. (You could write an RSS reader with this or something social like Glassboard.)

It would have to cost money, of course.

And you’d have to write code; you’d have to design your syncing system. But it would give you abilities you don’t have with iCloud Core Data syncing, and it would decouple your database and syncing, which is the right way to go.

I’ve mentioned Azure Mobile Services before, which I like because it’s in spitting-distance of an idealized Apple service. I would go so far as to suggest that Apple and Microsoft should partner to provide this service. Play to each company’s strengths.

(Disclaimer: Mobile Services paid me to do some videos for them and has sponsored my podcast.)

Syncing is only part of the future

Even if Apple works out syncing — somehow — that’s just not enough. That just gets us to where we should have been in 2008. The future belongs to apps with more sophisticated services.

And the future belongs (in part) to whoever provides those services. If you’re an iOS or Mac developer, you’d like it to be Apple.

Here’s what should worry folks at Apple: that Google provides something like the above for Android developers. Google obviously has the expertise, and it wants to make Android more attractive to developers.

(Yes, there’s Google App Engine, but I’m imagining something easier.)

Or, put another way: the backend system will become nearly as important as the UI frameworks, and plain-old-syncing isn’t enough.

What Is a River of News Reader?

Tue, 07 May 2013 10:40:42 -0700

I wasn’t clear on it completely. So I asked Dave, and he answered.

AltWWDC

Thu, 25 Apr 2013 10:40:51 -0700

WWDC sold out in three minutes. (Or less.) I didn’t manage to get a ticket, though I did try.

I have a feeling that AltWWDC is gonna be huge this year. (I’ll be there — I’m speaking. I’d be there even if I weren’t.)

It was only a few years ago when WWDC didn’t sell out at all. It even had Early Bird pricing.

Identical Cousins 15

Tue, 23 Apr 2013 11:40:45 -0700

Michael and I just winged it with episode 15.

Identical Cousins Sponsorship Slots Open

Fri, 19 Apr 2013 15:55:52 -0700

We have some sponsorship slots open for future episodes of Identical Cousins, the podcast I do with Michael Simmons.

If you might be interested, contact me or Michael. (There’s Twitter info on the site. Or you can email me using brent plus the domain name of the business I own.)

Past sponsors have included Windows Azure Mobile Services, FastSpring, and Pinbook. You’d be in great company.

RSS Reader Market Size

Thu, 18 Apr 2013 10:57:36 -0700

Alex Kessinger estimates the size of market that will pay for an RSS reader.

Fargo

Wed, 17 Apr 2013 11:58:14 -0700

Small Picture, Dave Winer’s new company, introduced Fargo today. It’s an outliner that runs in your browser and saves to Dropbox. The file format is OPML, so you can edit those documents in other apps (such as OmniOutliner) that support OPML.

With Nick Bradbury

Tue, 09 Apr 2013 11:36:18 -0700

Michael and I talk to Nick Bradbury in Identical Cousins 14: Partners in Crime.

Join App.net

Mon, 08 Apr 2013 10:36:12 -0700

I have a whole bunch of invitations to App.net — you can sign up here.

If you don’t know much about App.net, check out the weblog, where they promote third-party apps, link to their podcast, and talk about the APIs they’re building. It would be wrong to call it a Twitter alternative — it’s very much its own thing, and worth checking out.

I’m a fan. Love the vibe. I’m @brentsimmons there.

Debug Roundtable on iCloud Core Data Sync

Fri, 05 Apr 2013 10:14:07 -0700

I appeared on the Debug podcast along with Daniel Pasco and Justin Williams.

Will Apple Be Whitelisted for CalDAV?

Thu, 04 Apr 2013 16:53:43 -0700

The Blink fork of WebKit has me wondering about Apple’s and Google’s tactics.

Specifically, I think back to Google’s recent spring cleaning, where it said that the CalDAV API will be available for whitelisted developers only.

I wonder if Apple will be on that whitelist.

Tom’s iCloud State of the Union

Wed, 03 Apr 2013 15:02:27 -0700

atomicbird:

Users hear about how great iCloud is and how apps can use it to sync their own data. They quite reasonably wonder why your app isn’t using it. Syncing data is a great idea, Apple gives you iCloud, why aren’t you using it, dammit? But if you did use it, the app would be so unreliable that users would (again, quite reasonably) complain that it was a steaming pile of shit.

Regressing

Tue, 02 Apr 2013 17:24:02 -0700

Ryan Holiday writes in Our Regressive Web:

Google Alerts, Delicious and RSS were designed in blogging’s early days as innovations to help readers reduce this noise—to help improve their reading experience. But now those gains are disappearing. I feel that the tech press has allowed this to happen.

I had not realized that Google Alerts was having problems. But it doesn’t surprise me.

I wonder if it will go away on the same day as Feedburner, or whether the two will succumb in separate clean-outs.

Identical Cousins 13

Tue, 02 Apr 2013 11:38:20 -0700

On Identical Cousins 13 we talk about Google Reader, iCloud, Microsoft, Dave Morin, and Summly and other things. It’s a grab bag.

It’s also our best audio quality. We’re getting the hang of this.

A Clarification Regarding Web Services and Control

Thu, 28 Mar 2013 10:33:59 -0700

Responding to yesterday’s post, a number of people pointed out to me that it sounded weird if one minute I suggest checking out Azure Mobile Services and the next minute tell developers they should take control of their app’s web services.

I meant no contradiction, but I could have explained better.

When creating web services, you should consider high-level systems, low-level systems, and everything in between, and figure out what makes sense for you.

Here are some — not necessarily all — of the things to consider when choosing:

Does it support iOS, Android, and browser-based apps? (Knowing that you may — may — want to move beyond just iOS.)
Can you create a social component?
Can you add additional services — push notifications, feed-polling, sending email, whatever — to the system?
Can you get aggregate data and learn how people use your app?
Perhaps most importantly: is it possible to migrate to something else (even if takes some work)?

The answer is yes to all of these for Mobile Services. (While the answer is no to all of them for iCloud syncing.)

The answer is also yes if you want to work at a low level — it’s yes if you get a virtual server on Linode and run Ruby on Rails and MySQL.

And it’s also yes if you work at a medium level and deploy apps using services like Heroku, Engine Yard, Amazon, and Google App Engine.

At some point you have to outsource some things, right? You’re not going to build your own server machine that runs your own operating system in a data center you constructed with hammers and saws that you made.

So you choose what makes sense. And if it can be a high-level system, that’s cool — it will probably save you time and be easier to maintain. But you might have good reasons to choose something medium or low level, and that’s cool too.

The key is this: you need control of the data.

iCloud Core Data syncing is, once again, completely opaque and outside your control. It fits none of the criteria listed above.

Why Developers Shouldn’t Use iCloud Syncing, Even If It Worked

Wed, 27 Mar 2013 12:37:28 -0700

Yesterday the Verge posted Apple’s broken promise: why doesn’t iCloud ‘just work’?

It’s not the first article on the topic — bits and pieces of this issue have come up before. But The Verge did an excellent job putting it all together. Good reporting.

Here’s the thing: if you’re a developer, you shouldn’t use iCloud syncing anyway. I’ll explain.

Android and the web

You may think you’ll never want an Android or browser-based version of your app. But are you sure? Really, really sure?

You hope your app will be a hit. (If not, then quit writing it and choose something else.) If it’s a hit on iOS, it could be a hit on Android too — and you can bet that customers will ask for a web app version.

You don’t want to limit the success of your app just because you didn’t want to write your own server.

And even if you’re sure that you’ll never want an Android or web version, is it possible you’d want a Mac version that isn’t sold on the App Store? (Only App Store builds are allowed to do iCloud syncing.)

Social software

We’ve been living in a social world for years. But iCloud syncing is not social: it’s per-user syncing.

If you write your own server, you can write the social bits, so your users can share recipes, weather forecasts (look, Mom, it’s going to be sunny on Thursday!), favorite articles, or whatever-it-is your app does.

People expect social.

Additional services

If you’re writing an RSS reader, you can’t ask iCloud to download feeds.

iCloud can’t poll Twitter to see if your follower count has gone up or down. iCloud can’t generate weather forecasts. iCloud can’t track ships.

There are all kinds of services that make sense on the server side. You could do some of them on a client, but at the expense of timeliness and battery life. If it’s a good idea, and you don’t do it on a server, your competition just has to write a server that does it, and your app is finished.

Learning how people use your app

You shouldn’t look at private data.

With Glassboard we made the decision — there was no debate — to encrypt messages in the database, so that we couldn’t see private data.

But we could still look at aggregate data. It was interesting to know how many boards were created each day, how often people used invitation codes, and so on.

There’s no substitute for learning about how people use your app. You can guess how people use your app. You can — and should — get all the feedback you can via email, Twitter, and App Store reviews.

But seeing actual data makes a real difference, because it helps you figure out where your resources need to go.

Costs

It used to be expensive to develop, run, and maintain your own server. You’d buy a machine or a few machines, get them installed in a data center, figure out how Apache works, install MySQL, and write a ton of scripts. Perl or PHP scripts, most likely. (Ugh.)

You’d use Subversion (if you were lucky) or cvs. You’d write your own testing system from scratch. You’d write a bash script that copied the files up to the server.

And you’d spend a bunch of money.

Everything has gotten easier and cheaper. These days you’d run services on Amazon, Azure, Engine Yard, or Heroku. Or get a virtual server on Linode. You’d choose from one of the many excellent systems like Ruby on Rails, Sinatra, Node.js, and Django. You’d deploy via git or Mercurial.

If you can learn Cocoa, you can learn this stuff. (And so much of it is wonderful — you’ll enjoy learning it.)

Control

Tim Wood, CTO of The Omni Group, tweeted the very wise words: Own the Wheel.

Here’s the thing: half the mobile revolution is about designing and building apps for smartphones and tablets.

The other half is about writing the web services that power those apps.

How comfortable are you with outsourcing half your app to another company? The answer should be: not at all comfortable.

Do it yourself.

The Small Town Volunteer Fire Department

Sun, 24 Mar 2013 14:30:06 -0700

My Mom has the scoop on goings-on in Newfield, a small town in south Jersey where my family comes from, where my Mom lives, where my grandfather was chief of the volunteer fire department.

The city council wanted — for stupid reasons — to shut down the fire department, which had been serving the town for more than 100 years. The council voted to shut it down before changing its mind. Narrowly.

Mom writes:

All I can think about is that this mess marks the passing of the two important groups - those responsible for the original Borough bargain of lower taxes thru volunteerism and the Great Generation that Ever Was. Political/social decision making has passed into the hands of the baby boomers and we are not prioritizing the welfare of the town, state, nation, world above our own petty egos. This is not the legacy past generations wanted us to embrace.