A thing of minor note: we’ve updated the main zetetic.net website. Aside from giving a few of our pages a long-needed refresh, we’ve decided that we really wanted to get all this content out of the database and onto the filesystem.

For a long time, we’ve been using the Radiant CMS to run both the website and the blog. It’s had it’s ups and downs. Radiant is pretty cool, a Rails-based application that has a lot of brilliant tricks for building out a website with a lot of shared content and cross-marketing. However, for us it’s always been a tad volatile and clunky. For instance, it’s easy to accidentally double-submit on a new post to the blog which then creates a page with no parent_id and that makes your whole site impossible to access.

Major version upgrades have been a real nightmare, especially when it comes to getting plugins updated. Plugins are what make Radiant so dynamic, but they tend to be very brittle, and are complex to upgrade with a major update of Radiant. Simple things like tagging or comments really ought to be part of the core system.

Then there’s the memory usage, or rather Ruby’s memory allocator and garbage collector (which could be considered a form of entropy). We don’t see the need to incur and manage this overhead just to provide static HTML content and images.

Finally, we wanted to be able to build out our pages in HAML, manage them over time with Git, and we’ve found that the Ruby gem staticmatic is just the thing for this. It provides a Rails-like project structure, partials, layout capabilities, etc. I even managed to hack in an automatically generated sitemap.xml.

At this point our website is almost entirely static content, with a little jQuery here and there where needed, and the blog itself is still on Radiant, soon to be moved over to another engine. When we have some spare cycles I’ll try to post some of the tips and tricks we employed to make it happen, but it’s nothing that any competent Ruby programmer can’t handle.

As an aside, the staticmatic gem is maintained by Stephen Bartholomew, and he’s doing a great job of actively maintaining the project. The mailing list is pretty active and helpful, and there seems to be a good community of people using it. That tends to give a tool a longer shelf-life and makes us even more confident in our decision to make the switch.

The argument about the iPhone OS being too “closed”, or that Apple is controlling what you do with it too tightly, is still being pretty hotly debated, and I’m loathe to wade into it because most of what could be said has been said, usually with a lot of invective that’s unhelpful. For the most part, while I find it annoying, I try to keep in mind that nobody is forcing anyone to buy iPhones. Take it or leave it.

Yesterday, John Gruber brought up this interesting proposition by Jason Snell in which the latter proposes that allowing the “side-loading” of native apps would end the debate, and end the claims of critics that iPhone OS is too “closed.” I don’t agree with him that this will be the direct consequence, but I think it is worth considering. Happily, Gruber has pulled the money quotes for us:

I don’t think the company needs to stop controlling what apps get in the App Store. All Apple needs to do is add a new feature, buried several menu items down in the Settings app, that mirrors the one found on Android devices: an option that lets you install Apps from “unknown sources.” If a user tried to turn this option on, they’d get a scary warning about how these sources couldn’t be trusted, and that they may lead to instability, crashes, loss of data, you name it. Scary stuff.

Most users will never find that setting. Many who do will be loath to turn it on. But by putting it there, Apple immediately shuts up every single claim that the iPhone isn’t open.

Obviously, I like this idea, but I don’t think it “immediately shuts up every single claim that the iPhone isn’t open.” Gruber responds:

Personally, I’d welcome such a move, but I don’t think it would have the effect Snell envisions. Snell’s argument is that Apple should do this to nip the argument that the iPhone is too closed. But if Apple did exactly what Snell argues, critics would still harp on the closed App Store. iPhone critics have seldom let facts get in their way.

Maybe John’s right about critics of the App Store, at least some of them. But I think there’s another angle of influence to consider here, a better reason to do this, that will help achieve the goal of calming critics who might scare away potential customers, telling them that the device is “too closed.” Consider Gruber’s further argument later on in his post:

If there are people who think the iPad can’t read PDFs or play music and videos that aren’t purchased from the iTunes Store, then surely there would be people who’d think you can only install apps from the App Store even if sideloading were a supported option, as per Snell’s suggestion.

This is more likely than not the result of the tech-head discussion spilling over to blogs that normal people read and daily conversation in a kind of painful telephone game. It’s almost like watching political campaign spin and slogans propagating.

I’d like to offer a bit of dissent here. Perhaps I’m not the kind of critic John is writing about, since I’m already an iPhone developer, but this would certainly make me very happy and alleviate most of my concerns (in particular the very high risk of investing months of “opportunity cost” on an application that could be rather capriciously rejected from the App Store). Also, and more importantly I think, I’m one of those people who gets asked by friends, “should I buy an iPhone? I heard those things are really closed, that you can’t do what you want with them.” My answer to those folks would suddenly be radically different*.

Then there’s all my sysadmin friends buying Droids instead of iPhones. I think they’d have a radically different view of all this, too. Being able to load what they want is specifically the concern they have. In my circle of tech heads, we don’t care that the App Store is closed, we care that we are prevented from loading what we want onto the device. We’d still happily sell software on the App Store (I think few would choose to go it alone) and buy software on the App Store. And we’d be more inclined to develop software for the device itself. In fact, you’d probably have an explosion of freeware, further entrenching iPhone OS.

I think a lot of tech folks – who are not normal folks, but who end up being a product’s pro-bono (or de facto?) evangelists to the normal folks – do see the prohibition against side-loading native apps as being really heinous. They’re like howling monkeys on the issue! And they are very much the people coloring the discussion, starting this telephone game of “the iphone is locked down,” resulting in normal people thinking that they can’t read PDFs or load their own music. Maybe I’m wrong, but I think these are dots appropriately connected.

I think all this other stuff about the App Store itself being too closed is just window dressing for that issue. I don’t think Apple needs to do this to convince people to buy the iPhone or the iPad – so far it would seem they clearly don’t – so I don’t expect to see it happen.

An aside: I don’t think it can reasonably be said that the prevention of side-loading native apps is solely to protect the user experience, as it’s also been exercised by Apple in ways that have nothing to do with protecting the user experience (rejecting Google Voice, punting that 4Chan image scraper or whatever it was, etc). Furthermore, it obviously gives them a monopoly on revenue for the whole market place. The App Store is very convenient, but it’s very much the only game in town by force.

Allowing the side-loading of native apps really would change the discussion quite a bit, and does cut the rug out from under the whole “what iPhone doesn’t, Droid does (unless Verizon doesn’t want you to)” ridiculousness.

* Usually my answer is, “yeah, they’re great, I love it. No, you can’t load whatever you want onto it, but it’s still really awesome, despite regularly dropping all my calls.” And that right there is probably why Apple won’t change the policy. Still, “Yes, buy it, yes, you can do whatever you want with it, it’s really awesome, despite regularly dropping all my calls,” is a much better endorsement.

We’re a hair’s breath away from releasing the latest and greatest version of Strip, our password manager and data vault for iPhone OS. Just a few tweaks to make, then we’re on to App Store submission. Strip Sync is also available for general beta, just pop on over to the contact form and drop us a note if you’d like to participate.

We recently merged the development branch into master and tagged the release. I love looking at these stats:

113 files changed, 6956 insertions(+), 4447 deletions(-)

More prep work to do, we’ll keep you posted on our progress. Beta testers – the feedback has been great, please keep it coming!

One last thing to note: the Ad Hoc development and app signing quagmire that Apple has developed to control how we handle beta testing has been a huge hindrance to many of our beta testers. We’re sorry about the complexity, there’s not much we can do about it, but we seem to have most folks getting along alright.

Because I’m totally comfortable with allowing the phone company with the most contempt for its customers to access my bank account information:

I can’t wait to stop paying these jokers their “subsidy” once the contract ends and my monthly bill doesn’t go down. Need to be able to make phone calls, plain and simple. Why are they even bothering to spend R&D money on this junk? Perhaps they recognized that if they couldn’t force this stuff on their subscribers, they can at least make it available through the App Store. Still doesn’t make any sense.

It’s been suggested by Marco Arment and others that one of the reasons the iPhone isn’t available on Verizon yet is because Apple doesn’t go for allowing the carriers to dictate anything about the device, and Verizon is pretty much #1 at doing just that. I’m curious of any of my VZW-Droid-owning friends can elaborate on whether this is currently the case for them? Are there apps on there you don’t want and can’t delete?

Brent Simmons lays out the case for setting up a sort of gentlemen’s agreement between iPhone OS developers, or at least an agreement in behavior for the apps – in order to facilitate inter-app communication. The title of his article refers to iPad, but the concept applies well to all iPhone OS apps, and he asks if his solution is sensible or silly:

But we don’t have an easy way to get back to the calling app. Imagine a hypothetical case like this:

1. You’re in Twitterrific, looking at a web page, and there’s a link to a feed. You want to subscribe to that feed.
2. So you choose a “Subscribe in NetNewsWire” command. It opens NetNewsWire and subscribes to the feed.
3. Now that you’ve done that, you want to get back to your place in Twitterrific. You want it to be exactly as if it never quit.

We can do #1 and #2. It’s #3 that’s tricky.

So I have an idea. It just came to me, so I don’t know if it’s good or bad — but it’s worth posting, at least.

What if the calling app added, as a parameter to the URL, a URL to call when the task is completed?

Seems pretty sensible to me. It would be fantastic for Strip. I’ve been looking for ways to make our password manager more easily accessible from other apps so that it’s easy to take that very round-trip he describes into Strip and back out to another app to either store some data in Strip and go back, or to retrieve some data from Strip to use. It’s pretty easy now, but it could be better, it could just work.

I think Bret’s idea is a really good one, and provides for a lot of flexibility going forward. However, there’s still no way an app could “discover” what other apps are available and what services they provide under this scenario, and that’s really clutch for this sort of thing, for providing a button like “Fire a flame thrower in NetNewsWire” and knowing that it will in fact launch NetNewsWire and run some fictional “Fire a flame thrower” command.

Maybe apps should broadcast their services over Bonjour to the localhost? Right there we already have a very solid model for advertising and discovering “services,” although it doesn’t quite lend itself to application switching. And on iPhone OS 3 and lower, no application that isn’t running could advertise a service in the background.

In iPhone OS 4, that will no longer be the case, it would seem. Perhaps one could just run a bonjour advertisement for a service in the background in an NSOperationQueue? What an awful kludge that would be. I don’t understand why this isn’t a basic feature of iPhone OS 3 already.