Category Archives: development

You’re Not Loren Brichter

You’re Not Loren Brichter

Buy apps. And start encouraging everyone you know to pay for quality. If you balk at paying $1.99 for any app that genuinely interests you, get out of the business immediately. You’re part of the problem.

Brilliant. I can’t count how many times I’ve heard developers scoff at the idea of paying for an app. I can tell you I lost a good amount of respect for them when they did it, though.

Xcode 3.2.6 and Mountain Lion

There are a few notes on the net for setting up Xcode 3.2 on Lion. Without too much more trouble, getting these old tools working on the latest OS is also possible. Here’s how.

Follow these instructions at your own risk. Read them before you begin so you understand the risk you’re taking.

  • Follow the instructions linked above
  • Your machine will panic during the install (seriously)
  • Your machine will continue to panic every boot (seriously)
  • To fix the panic, remove these offending extensions from /System/Library/Extensions: *CHUD*.kext, *AppleProfile*.kext. To do this, you’ll have to do one of these two things:
    • Boot into Safe Mode (cmd+s) and remove the offending extensions
    • Boot to the recovery partition (cmd+r), open Terminal, and remove the offending extensions. The path to these extensions will be /Volumes/Macintosh HD/System/Library/Extensions if you’re using the recovery partition method.

Why is this happening?

My guess is that these are 32-bit kernel extensions, which are unsupported on Mountain Lion. They’re loaded during the install, which causes the first panic. During startup, they’re being loaded, and the panic happens again, forever.

Not Critical? Give It Away

This week, I attended the Velocity Conference, a conference focused on “building a faster, stronger web.” Many of the talks focused around gathering metrics, including RUM, synthetic performance data, and system health monitoring. The data points of interest go beyond simple web traffic and hit counts and focus on how users engage a site, how the experience and speed of the site affects conversions, and quickly diagnosing issues when they come up.1

Everybody Builds The Same Thing

“At [Acme], we built Widget X […],” was a phrase I heard innumerable times. Web development teams are faced with very similar problems, regardless of the market their business is in. They’re gathering data to show the business how visits convert to sales, as well as how the site performs across the combinations of browser, geography, and connectivity that constitutes their visitors.

In most cases, these tools are tightly coupled to business data, giving incredible visibility into how systems work, and how deployments impact site and business performance. Unfortunately, this tight coupling can make it difficult for others to benefit from this work.

It was discouraging to hear about talented teams doing the same work by building the same types of tools, mostly unbeknownst to each other. Of course, there is the egotistical issue of building the roundest wheel, but that didn’t appear to be the case. Instead, these teams weren’t in a position to share their work.

Give It Away

Aaron Kulick (@gofastweb) made a comment during his talk A Web Perf Dashboard: Up & Running in 90 Minutes that really resonated with me. While showing some screenshots of a dashboard used at WalmartLabs, he mentioned that he’d asked about sharing data, because it would be interesting to engineers, but wouldn’t mean much to competitors. Of course, the legal department had vehemently prohibited that. The good news was that the technology they’d used was available as open source; they’d simply stacked components together to build their monitoring.

Twitter has open-sourced a mountain of software developed by their engineering teams. Finagle is the foundation of their next-generation systems, and it’s available for anybody to build on. There are other companies building systems to accomplish the very same things Finagle does. The platform allows Twitter to build their systems more quickly, but isn’t directly related to the specific value they’re aiming to provide. Recognizing this, they’re generously giving it away.

Competitive Advantage

What about competitors? What’s to keep Facebook from coming along and “stealing” Twitter’s work by using Finagle in their own applications? If that were to happen, Facebook could successfully sidestep all of the effort required to build Finagle.

Yes, that’s a very narrow view of a bigger picture. It’s also a highly contrived example, because while their targets are similar, Twitter and Facebook seem to be aiming at different targets. If you’re going to make the argument, however, you should step back and remember that both companies are also heavily relying on the work of the other. 2 There is mutual benefit.

We All Move Forward Together

The effects of open source were plainly visible all week at Velocity. The web has a deep history built on the shoulders of open source: Apache httpd, PHP, Linux, MySQL, Python, Ruby, Perl. It’s currently moving forward quickly with Node.js, MongoDB, Scala, Redis, Tornado, Nginx, Varnish, Stud, HAProxy, and countless other open source projects graciously shared by their developers. These examples all highlight the incredible progress that has been possible because of open source.3

Did I mention Chrome, Firefox, and WebKit?

  1. One demo I saw showed the ability to diagnose a single customer’s issues on the site within seconds of an error, and backtrace their clicks on the site.
  2. Twitter has used Cassandra, a project Facebook started.
  3. As a cynical quip, consider a major alternative: IIS on Windows. Threads!

The Extra Detail

Good Morning

This morning, I had the good fortune of working out in a very nice gym here in Phoenix. I’m traveling for work, and the hotel we’re staying in is gorgeous. Undoubtedly, these accommodations are incredibly expensive, judging by the impeccable grounds and facilities I’ve seen.

For some reason, though, the most impressive part of the morning was the smallest detail. I’d just completed my run and felt a little shelled out. I made my way to the water cooler in the corner, and noticed a welcoming plate of freshly washed apples – green and red varieties.

That plate of apples cost seemingly nothing compared to the money each of the people in that gym was spending to stay here, but it got me thinking.

What’s the extra detail I’m putting into the things I do?

If I’m building something, have I put special attention that somebody will notice, and probably tell somebody else about? What about relationships? Have I put an extra amount of effort into something my wife wouldn’t expect me to think about or ask?

Sometimes the extra detail is trivially easy to execute, but just needs to be considered. It will be noticed, and somebody’s day may be different because of it.


[thoughts/IOS] PhoneGap vs. Native: Some Thoughts on Going Native

“I was /this close/ to being finished with the PhoneGap version. It was 99% done. Almost ready to go. And then… *pow*… performance issues”

An interesting take on web vs. native development for iOS. It’s worth noting the author only mentions iOS. It appears cross-platform wasn’t a goal for this effort.

App Impostors

iOS is currently the platform to develop software for. Last week’s acquisition of Instagram by Facebook is an example of a company that, prior to a couple of weeks ago, had only a single entry point to their platform: their iOS app. The entire user base was pushing thousands of pictures per hour through a single application on a single brand of mobile device. Only very recently did Instagram release an app for Android.

That Android release resulted in an additional 10 million new users within 10 days of launch. That’s an incredible number for a small company, much less a tiny company like Instagram.

The number of Android devices in use is what makes it a compelling argument against developing solely for iOS. You can’t walk into a shopping mall without finding a cellular retailer who is giving away an Android device. Naturally, giving away hardware is a great way to push the platform along. Android devices are what make smartphones so ubiquitous today. In January, there were an estimated 250 million Android devices in use.

Rather than argue that startups should focus on iOS, I’d like to move forward with the assumption that both platforms have their merits, and neither appears to be disappearing any time soon. Since both exist, companies are left asking: “Which should we develop for?”

If you’ve worked with a marketing department, you know the answer to that question: “All of them.”

In the last few years, there has been a growing belief that the answer to mobile application development has actually been with us for a while: the web. HTML5 and CSS3 are the revered children of those hoping for a nirvana of application development. Many believe that web apps are the future, and that native applications are merely a relic of the past. By some accounts, it sounds like a great idea. Web-as-mobile apps have some nice benefits:

  • No app review – skip Apple’s esoteric review process
  • No updates – push new versions live, users receive them on next load
  • Iterative development – no updates means small changes can be made quickly
  • It runs everywhere there is a web browser

The last item in the list is the real kicker: a magical application that works everywhere. Unfortunately, there are a number of problems with using web technology for apps:

  • The internet goes down
  • The internet is slow
  • Web browsers are slow
  • Nobody wants web apps12

The way to solve these problems has been clever:3 simply marry the two together. Create a web app, and then wrap a pretty native window around a web viewer. Bundle the result, and ship it to the proper store. The web app can take advantage of local storage (introduced in HTML5), so it’s not even necessary to use a native storage library like Core Data or SQLite.

These apps are impostors: bits of software masquerading as native applications, attempting to deny their true ancestry in the web.

Most people won’t mind, or may not even notice an app is built with web technology instead of native software. The app will look almost identical on all major platforms, which may be a selling point for marketing and branding.

However, iOS and Android have certain UI expectations in place, as set by their respective purveyors. iOS apps look and feel a certain way, and Android apps have their own style. More striking in style are native Windows Phone 7 apps, with their Metro styling. For enthusiastic fans of a particular platform, these design themes are important, because they help unify the experience of using a device.

Apps built outside of native toolkits can quickly reveal their true identity. Widgets looking out of place or choppy scrolling are usually the first signs that something isn’t quite right. After a few minutes, the keen eye will notice things are not as they should be.

Here’s an example I stumbled on this evening: Untappd, a social drinking app that’s been gaining popularity lately.

The main screen in Untappd is fairly typical of a social application. There is a timeline with recent activity is displayed, with a text box for searching, a row of tabs at the bottom (customary for iOS), and a title bar with the app’s branding in it. The first time I launched Untappd, I was greeted with a typical Login / Signup view, which wasn’t particularly startling.

After jumping around a few of the screens, there were a few bits of UI that bothered me: the masking / highlights on the tab bar was all wrong for iOS. You can see the selected tab in Untappd is white, whereas the native UITabBar highlights selected tabs with a blue gradient:

Pull-to-Refresh is an interaction (recently patented) common in many mobile applications, so as I jumped through the views, I attempted to pull a few of them to see if they’d reload. Imagine my surprise to see the title bar sheepishly vacate it’s position at the top of the screen:

After discovering this, I had a pretty good hunch about what was up. I decided to pull the view the other way:

The tab bar seems to wander from it’s southern position as well. These behaviors are common in applications created with PhoneGap, a framework that boasts support for “7 platforms.” I pulled the bundle off my phone to confirm the inner workings of the app:

The presence of PhoneGap.plist, along with a directory named www were enough to convince me of my guess: Untappd is a web app.

I didn’t choose Untappd in particular to pick on it. I’ve only used the app for a few minutes, and it works fine. It definitely doesn’t feel like native apps do on my phone, and I’m left to believe an Android user might say the same thing.

If the goal for Untappd was to ship apps that appear very similar, they have clearly succeeded. The iOS and Android versions appear very similar in form, though seem to leave a bit to be desired in function.

However, if the goal was to ship a polished, buttery smooth4 app for iOS, the choice to go with PhoneGap was not the way to get there. Their current offering feels a bit disingenuous, as if the platform wasn’t worth the focused effort.

Clearly, it is.

  1. When was the last time you went to Apple’s Web Apps on your iPhone?
  2. The fact that Steve pitched web apps as the development path for iPhone at launch is still embarrassing
  3. I’m being incredibly generous. A more accurate choice of words would be “… full of dirty, dirty hacks.”
  4. Will it ever be possible for Android to be as smooth IOS?(SIC)