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!
I was a guest on Daniel Jalkut’s Bitsplitting podcast. It was fun! Many thanks to Daniel.
Tom Harrington continues his series of posts on iCloud and Core Data.
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.
I wasn’t clear on it completely. So I asked Dave, and he answered.
WWDC sold out in three minutes. (Or less.) I didn’t manage to get a ticket, though I did try.
It was only a few years ago when WWDC didn’t sell out at all. It even had Early Bird pricing.
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.)
Alex Kessinger estimates the size of market that will pay for an RSS reader.
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.
Michael and I talk to Nick Bradbury in Identical Cousins 14: Partners in Crime.
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.
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.
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.
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.
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.
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.
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.
Yesterday the Verge posted Apple’s broken promise: why doesn’t iCloud ‘just work’?
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.)
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.
If you’re writing an RSS reader, you can’t ask iCloud to download feeds.
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.
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.)
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.
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.
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.