When I released the first version of Ohai a few months ago, it had a simple goal – to have a simple, beautiful place to keep track of memories. As with all first versions, it was limited; you could only capture location-based check ins with a comment and a photo. And as it was released shortly after iOS 7’s announcement, it quickly looked outdated and needed some visual touch-ups. Today I’ve released the first new set of features for Ohai to make it a better and more beautiful journal, with some of the most heavily requested features.

Much ado has been made about the idea of App Store apps getting discounted upgrades, where you buy an app once, and then pay a discounted amount for an upgrade. This idea is not new; for many years, developers sold apps under a model known as shareware. In an era when software was harder to use and people feared viruses, this model thrived among technically-savvy people who tended to spend more money on technology. The generally-accepted model in the Apple world has a fair bit of complexity, involving trials (some time-based, some feature-restricted), serial numbers or license files, and periodic requests for more money. Then the App Store came and replaced it outright with a new, simpler model that favors a traditional retail-style system of cheap software that you pay for once. It’s far more straightforward and easier to understand; if you want the app, you buy it, and then you own it.

Developers who have thrived under the old model have complained for a long time that they want discounted upgrades to make a return to iOS. Along with it comes the added complexity of managing different tiers of ownership, both technically and mentally. Apple has not offered this, instead opting to make major updates available as a separate, standalone app that existing users pay for in full, as was done recently with Logic Pro X. To me, this is far and away a better and simpler approach to handling upgrades in an era when non-technical people buy software.

In 2013, developers rely on web-based services to get much of their work done. Whether it’s looking up server API documentation, provisioning iOS devices, or registering API keys, a part of a developer’s day involves going to a website and looking something up. And that means keeping track of how to find all of these disparate websites. The problem is that there’s no real standard way or schema to get to them. Each service has a different URL for their developer site. Some examples:

• iOS: http://developer.apple.com/devcenter/ios/
• Android: http://developer.android.com/
• Chrome: https://developers.google.com/chrome/
• Dropbox: https://www.dropbox.com/developers
• Twitter: https://dev.twitter.com/
• Instagram: http://instagram.com/developer/
• Windows: http://msdn.microsoft.com/en-us/windows
• Heroku: https://devcenter.heroku.com/
• Twilio: http://www.twilio.com/docs/api
• Amazon Web Services: http://aws.amazon.com/documentation/

There’s 10 different examples, each with completely different URL structures. If you have to interact with more than a few of these, it becomes impossible to keep track of them all in your head. Now, you could rely on bookmarks or web searches, but these aren’t as fast as just typing a URL into your browser or using a shortcut in an app like Alfred. Speaking from my own experience, for the sites I can keep in my head, I’ll type part of the URL and hope that the browser’s URL autocomplete will finish the job, simply because it’s usually more efficient. But as a human, sometimes I’m wrong, which wastes time. Wouldn’t it be great if there was a simple, consistent URL structure for all these different sites?

So I built DevCenter.me to do this. DevCenter.me is a directory of developer sites that can be accessed via consistent URLs that either you or your browser can remember. Each developer site can be accessed via one or more shortcuts (for example, ios for the iOS developer center, or app.net or adn for App.net) through either of two different URL structures: shortcut.devcenter.me or devcenter.me/shortcut. These shortcuts are designed to be memorized. Frequently used shortcuts will end up getting persisted in your web browser’s URL field (the service sends a 302 temporary redirect, not a permanent one, so your browser will probably still cache it). After a few uses, you can just type fb into your browser’s URL field, and it will automatically recognize you’re typing fb.devcenter.me, taking you to the right site in just a few keys.

DevCenter.me was designed to be a productivity tool for developers. There’s a full list of sites and their shortcuts available in JSON, as well as on the website (with shortcuts shown by pressing the option key). You can even download an Alfred extension to open a site via one of these shortcuts (shout out to Will Smidlein for writing this, as well as providing the motiviational tweets to write this service). And if a site is missing. you can fork the project on GitHub, add it to the list, and submit a pull request. When I initially published the project, there were 10 sites. As of this writing less than 12 hours later, there are 56, and undoubtedly more pull requests for me to merge in. That’s really cool to see, and I hope people keep submitting requests for more sites.

I built DevCenter.me because keeping track of all these websites was a thorn in my side; wasted memory space in my head. Accessing developer sites may not be a world-changing problem, but saving a few seconds a few times a day adds up over time. A better solution keeps you focused on what you’re actually trying to do rather than requiring you to keep estoeric URLs in your head. I hope it finds value as a tool for lots of developers.

About three years ago, I had a simple idea. I wanted an app to keep track of the places I’ve been. Naturally I’ve tried all the services for this, jumping from Gowalla to Foursquare to Path. But they all want you to broadcast your location, all the time. They’re focused on the experience of letting other people knowing where you are. There’s certainly value in sharing your location, but I wanted something that benefited me first.

I built a prototype of this app a few years ago, but it didn’t go anywhere. The secret sauce behind any check-in app is a database full of points of interest (or POIs, meaning places like businesses, restaurants, tourist attractions, etc.), and mine was no different. I didn’t want to rely on a free API of places that could evaporate at any time. Buying API access to one was prohibitively expensive. And shipping without one meant checking-in became a huge data entry process that was not fun. The project got shelved.

Then, a few months ago, my friends over at App.net announced a new API for finding POIs, and attaching metadata about places to posts and private messages. A few months before, they released an API for, among many other things, creating a private timeline of posts for individual accounts. I saw both a way to get a sustainable POIs database and cloud storage for check-in data.

And thus, Ohai was born.

As I’ve stated before, your app needs to sync. This has not gone unnoticed by the startup world, who are offering more and more options for developers to build sync into their apps. Today, Dropbox announced a new datastore API, a system for syncing application data (that isn’t file-based) into and out of Dropbox.

At first glance, this looks like a wonderful solution. You get a drop-in component on iOS, Android, or the web to put your app’s data into the cloud, with very little thought by you. Data gets stored offline automatically. It even handles merging and conflicts quietly in the background. Pretty great, right?

I hope that the Dropbox Datastore API can deliver on these promises. I don’t think they’re necessarily impossible problems to solve. But these are the exact same problems that Core Data + iCloud claims to solve, and between iOS 5 and iOS 6, iCloud hasn’t been able to deliver on that promise. This certainly doesn’t mean Dropbox can’t, or that the Datastore API has problems. Dropbox is certainly well versed in the concept of syncing blobs of data between multiple systems, silently and effectively, as that’s what they’ve been doing for the last five years. But this solution should be approached skeptically and carefully.

Before you ship your app built with the Dropbox Datastore, these claims should be tested thoroughly. Test data sync across 1, 2, 3, 8 different devices. Test it offline. Introduce conflicts. Save data offline. Try multiple conflicts. Create conflicts on one machine while offline, etc. There’s a lot of ways a magic sync solution can fail.

Of course, the benefits to a drop-in solution are immense. You don’t have to write sync logic. You don’t have to wake up at 4 AM because your MongoDB process randomly died, taking your server API out with it. You don’t need to handle the differences in online and offline state. You know there’s a company whose goal it is to solve this problem for you; that’s their job.

Just be careful. When it comes to any tool that claims to be a cure-all, make sure it does the job.

In the last few years, an interesting alternative to paper currency has risen in the form of Bitcoin. I started paying attention to Bitcoin two years ago, and have owned some ever since. I’ve purchased physical and digital goods with it, as well as traded it for cash. It’s particularly intriguing to me because it maintains the core properties of economic models while creating a system of inflation guided by encryption algorithms rather than humans. And it’s grown in huge popularity over that time, with a net worldwide worth of over $750 million USD at the time of this writing.

Many people have asked me about Bitcoin, so here’s a basic introduction to what Bitcoin is and how it works.

Note: I am neither a lawyer nor an accountant. This should not be construed as legal or financial advice. If you use the information in this post, you agree that it is at your own risk.

At the last App.net hackathon, I unveiled Apparchy, a proxy server that converts your App.net timelines into data that looks like the Twitter API, which you could then connect to via Twitter’s official iOS apps to post and view to and from App.net. This was a really cool hack, but it suffered from many problems. It relied on a proxy server, which had issues relating to security and privacy, as well as being a single point of failure. If the proxy server went down, everyone’s app broke. Apparchy itself was built to work with Twitter’s official apps, which use a LOT of private methods on Twitter’s server API, and those private APIs changed often from release to release, meaning the app would break if you updated it. It was a big pain to set up, taking many steps that were easy to get wrong. But perhaps the most important and the most philosophical problem that plagued Apparchy was that the early adopter audience of App.net were not the kind of people who embraced Twitter’s official apps. They used Tweetbot or Twitterrific or some other app because it was better suited for their needs or looked better or some other reason.

Even with all these problems, it was fun and fascinating to make. Going into this weekend’s App.net hackathon, I wanted to top it. How? By building something that was just as mindblowingly cool, that also fixed all of those problems.

Since the last hackathon four or five months ago, App.net has been hustling on getting new APIs out, having added the Messaging API and the Files API, among other things. I’ve been dreaming for years of a better chat app with first-class, bulletproof file transfer support, and App.net has all the ingredients for a killer implementation. Similarly, for over a year, I’ve been sitting on the knowledge of the existence of the IMServicePlugIn framework, waiting for an opportunity to use it for something.

And thus, #ProjectAmy was born. App.net messaging integrated natively into Messages for the Mac.

Rene Ritchie on iCloud vs. Dropbox:

For all Dropbox’s automagical-ness, it’s a relic of the past. It’s a file system. It’s a hierarchy. It’s a folder sync. It’s a bunch of encrypted data stored on Amazon’s S3 network.

As much as iCloud is the right idea still not realized, Dropbox is the wrong thing done brilliantly well. And at the end of the day, that still amounts to the wrong thing.

There’s an important distinction here, and that’s separating files as UI from files as API. iOS (and, to a lesser but growing extent, Mac OS) has proven the value that users should not have to manage their own file system, that files as UI is a poorer user experience. You shouldn’t have to worry about where photos are stored in your photo library; iPhoto will manage collections of photos for you and they get stored on your disk somewhere. Apps can present organizational context that files cannot, letting one photo be in your library, your photo stream, an event, multiple albums, and with multiple people, all without having to exist in folders representing each of these collections. This is a good thing, it’s a significant advancement forward in human/computer interaction design, and it’s the model that computing on all platforms will be following going forward.

Files as API, however, are as important as ever. Besides being organizational chaos for a user to manage, a file system can be thought of as a structured way of mapping lots of pieces of separate data to a physical disk. Apps can store whatever data they want into a file, and the OS figures out how to actually store it. It’s a system that works very well. Using the iPhoto example, those photos may be interacted with in one or many collections with a smarter and more appropriate UI, but that photo is still being stored as a file somewhere on disk.

So while the UI has transcended the need for users to use the Finder for organization, the underlying data still relies on files, which is still the best way to save large amounts of disparate data. Just about every abstraction on files (e.g. databases or object stores) ultimately ends up writing files to the file system. Developers are still heavily reliant on files as API, even if we’ve moved beyond needing or wanting them in UI.

Besides the key/value store (which I believe uses a different syncing mechanism), iCloud advertises three mechanisms for syncing data – the file store, the document store, and the Core Data store. All of these are actually based on the same syncing mechanism for syncing files (a “document” refers to something like a Pages document, which is stored on disk as a folder with multiple files for separate images, text, and metadata; Core Data store refers to database-style apps that have lots of little pieces of data and maybe some files that go along with them). With iCloud, developers get a folder that the user never ever sees called a “container” to move files to and from the cloud. And it’s this basic file/folder synching mechanism that is apparently flawed, as there have been many reports of iCloud-based apps that have had problems, whether they’re based on Core Data, on documents, or on other storage with files.

Dropbox, on the other hand, was designed around files, both from a UI point of view and an API point of view. This means their file syncing is very, very good. If a file gets put into a Dropbox somewhere, it ends up everywhere quickly, basically with absolute reliability (short of network errors). If you’re building an app that needs to sync, that kind of reliability is exactly what you’re looking for. And you’re already using files to store stuff. The Dropbox file UI side of things is optional for users; they have to seek it out, either on the website or by having one of the Dropbox apps – there’s nothing stopping you from having a Dropbox account purely for syncing data, without ever installing the Mac app or viewing a directory on the web site. But their syncing of files works. Apps can build better UI on those files whether they’re stored locally, stored in Dropbox, or stored in iCloud. But Dropbox has proven it’s reliability, and iCloud hasn’t.

So while there is an argument to be made that Dropbox’s UI is a relic, its value as a syncing engine is still huge, precisely because it’s built around the paradigm of files, a paradigm we have decades of experience working with.