The business of making native apps for mobile devices is dying, crushed by a fragmented market and restrictive business practices. The problems are so bad that the mobile web, despite its many technical drawbacks, is now a better way to deliver new functionality to mobiles.

We've seen this movie before

Since the article was written in February of 2008, 5 months before the release of the iTunes App Store, it’s easy to dismiss this as a prognostication gone horribly wrong. And looking at some of the figures, there are certainly things that happened that were unexpected: the number of native mobile apps exploded with the release of the iPhone SDK and Android SDK, and so far the number of apps keeps growing. But read the article again. Why was the native mobile app market so horribly broken in early 2008? Anyone who was there at the time knows that developing J2ME apps was difficult. Every phone had a different implementation, and more often than not applications needed to have different code and a different release for every phone.

Instead of the flash flood of developers moving to the mobile web, Apple made sure it was all diverted to the iPhone. Native apps changed from being on death’s door to the next big thing. And while some people have been making money at this, there’s really not many. The rest of crowd, already defeated by the App Store, moved onto Android as the next new ground to conquer. Here is where history is repeating itself:

We created a series of elegant technology platforms optimized just for mobile computing. We figured out how to extend battery life, start up the system instantly, conserve precious wireless bandwidth, synchronize to computers all over the planet, and optimize the display of data on a tiny screen. But we never figured out how to help developers make money.

Android is an elegant, developer-friendly system. It’s on track to beat Apple in market share, and it’s closing in quickly on RIM. However, it’s yet to prove that it can make developers money. And while the fragmentation is not nearly as bad as it was with J2ME, there’s no denying that it exists and it is a problem. And when the cost of developing a native iOS and native Android app becomes too great, where do you go? Well, you go to HTML5 and the mobile web.

Don’t misunderstand, I’m not proclaiming the death of anything. But it’s amazing to me that despite how different the mobile marketplace looks, we are still facing the same problems and solutions. Plus ça change?

The New York Times ran an article this week titled “Once a Dynamo, the Tech Sector Is Slow to Hire” that focused on the struggles of some in the tech industry who are having difficulty finding new work after being let go from their jobs. For everyone who has experienced a job loss in this economy, including me, it’s a sad fact that finding new work can be difficult even in the best of circumstances.

So why are recruiters constantly asking me if I know any “good people”? Shouldn’t there be plenty of them out there? It’s not that simple, as I’m certain that the market for engineers varies wildly depending on where you ask the question, so someone in Corvallis may not be finding any job offers while a recruiter in Seattle may be at wits end finding people to fill their positions. As the author writes,

The chief hurdles to more robust technology hiring appear to be increasing automation and the addition of highly skilled labor overseas. The result is a mismatch of skill levels here at home: not enough workers with the cutting-edge skills coveted by tech firms, and too many people with abilities that can be duplicated offshore at lower cost.

However, the very next paragraph suggests another potential reason:

That’s a familiar situation to many out-of-work software engineers, whose skills start depreciating almost as soon as they are laid off, given the dynamism of the industry. [Emphasis mine.]

This last sentence is what I have a bit of trouble with. It’s true that the tech industry is fast and, given the pace of mobile, is getting ever faster. But the pace of tech means that an engineer’s skills start depreciating even while they are at their jobs. The skills needed to succeed in the industry change quickly, and if you aren’t learning then you’re stagnating. If you’re stagnating, then when it inevitably comes time for your own search you may not have what the recruiters are looking for.

Got a good job writing C++? Hopefully you also know some Java, or better yet some Python, Ruby or some other higher level scripting language. Do you do databases? If so, then it might interest you to look into the current debate over NoSQL and see if that affects your marketability as an engineer. If you do find yourself out of work, then it’s the perfect time to make sure your skills are not depreciating by learning some new ones.

When my position was eliminated in July last year, I decided I wanted to learn Android. I wrote a simple app that integrated with a service I loved; that app is now used by over 10,000 people daily in the Seattle area. I knew my web development knowledge had holes, so I learned Django. I read developer blogs constantly to get back to the bleeding edge of technology. I still do.

Even in Seattle, the tech sector hasn’t regained the energy it had before the crash. It may never. But the demand for good engineers is still there. By keeping pace with the industry, and constantly learning and trying new things, you can help yourself get ahead of the others looking for that next opportunity.

It’s unfortunate the number of people who chose not to stay for this talk. I think a lot of people who are still relatively new to Android, or who are relatively new to mobile in general, may not concern themselves with frameworks and high-level languages like FLEX or ActionScript. Native apps are the way to go, right? Why write for Android if you’re not writing in Java, or maybe even C++ using the NDK? iOS developers, shouldn’t you be writing in Objective-C?

That may have been true a year or so ago. Today, browser support for HTML5 elements is constantly maturing, and JavaScript performance is getting better with each release of WebKit. The number of mobile web app frameworks is increasing. With AIR, you’ll be able to package a SWF directly into an APK without writing a single line of Java code. The new Netflix app for the iPhone uses a UI front-end implemented entirely in a WebView. Chrome OS is right around the corner, and with it an entirely new app store, where the “native” language is JavaScript.

Personally, I welcome this. If I can write a significant chunk of my app in a device-independent language like JavaScript, that’s code that I’m more likely to be able to reuse moving from the mobile web to Android, or to iOS, or to Chrome OS.

What does this mean for mobile developers? Should we be afraid for our jobs? Probably not. There’s plenty of stuff a browser can’t currently do, and many apps will probably want some level of integration that will warrant some device-specific coding. And anyone who can write Java or Objective-C can pick up JavaScript or ActionScript pretty easily — good developers will always learn new skills as different tools in their tool belt.

Unfortunately many of these apps that use the Dashboard pattern do something really annoying: they prevent the activity from changing from portrait to landscape. This may be acceptable for people sporting a Nexus One, an EVO 4G, or any of the other phones with virtual keyboards. But what about those with a first generation Droid? What about all the rumored phones in the pipeline with physical keyboards?

Sidetappin'

Alas, one of the offending apps is, in fact, Twitter. The new version of Facebook’s app, while adding a cool photo scroll on the bottom, is another culprit. It seems that, rather than make these activities work well in landscape mode, these apps have taken the easy approach that “works” but provides a poor experience for someone who likes using their phone in landscape mode — and serious texters practically live in this mode.

Don’t let a good pattern be let down by half-done implementations. Let’s give some love to landscape mode!

Time to get back on the horse. Hopefully I can continue with my Android tips, but I have some thoughts about general software organizational stuff brewing as well. I just need to pretend it’s not summer anymore.

I think the one clear difference between this and the announcements that we expect from Apple is that this new device is clearly evolutionary, not revolutionary. True, we now have a phone display that exceeds the limits of human perception. But if pixel density is the most interesting thing about a new device, then perhaps there a bit less magic to this announcement.

It’s also clear that this phone is not all that much ahead of its kindred, if it is ahead at all. And that says quite a bit about what is happening with mobile: three years ago the iPhone was proclaimed the “Jesus phone.” Now it is just one of a number of superphones with surely more to come. It’s also no small thing that two of those comparison phones — the EVO 4G and the Droid Incredible — are Android phones, being less than two years after the first Android phone was released.

This is the pace of mobile today. Two years ago, Apple was the clear leader. Today, it’s in the middle of the pack. Who knows what will happen next year?

Before I continue writing about all things mobile and Android, I do have to make one point of full disclosure: today was my first day as an employee and software engineer at HTC.

It’s an exciting place and a great opportunity. However, continuing to do personal blogging on the side now comes with the standard disclaimer: the opinions expressed here are my own and don’t necessarily reflect those of my employer.

You’ll be seeing that phrase appear elsewhere on this site, and of course whenever HTC comes up on this blog. And if the company gets referenced here as much as it does on other mobile sites such as Engadget and MobileCrunch, that may be quite a bit…

After all that we’re at The Orange Couch Coffee in the Marigny. It’s quite a different experience — considering it’s owned and operated by some California transplants, this says more about the new face of the Marigny than any of the old New Orleans style. Chic decor, ambient music, and mochi.

Misty and The Orange Counch

Or maybe not. New Orleans has always been a constant mix of cultures. The iconic wrought iron balconies in the French Quarter are actually from the time the Spanish rebuilt the city after Great Fires of 1788 and 1794. The muffuletta was made for the Sicilian farmers who ate at the Central Grocery. In the post-Katrina construction, one was likely to hear salsa or conjunto music out on the street rather than Cajun or Zydeco.

So why not have a place that serves kombucha among the shotgun houses?

Not the Moscone Center

This weekend, most of the tech world has their blogs fixed firmly on the Moscone Center in San Francisco (ground zero for Google I/O). I am not at the Moscone Center, and so I’ll let you follow the Android-related announcement action from all the other possible outlets. I’m at the CC’s Community Coffee House in the middle of the French Quarter in New Orleans.

It’s a nice place — mostly quiet as the Quarter seems to be relatively untouristed this weekend. The decor and ambiance is Starbucks-esque, which isn’t bad, but tomorrow I’ll be finding a place a bit more local.

The best part about this edition of The Cafe Project is cupcakes for breakfast! I know I wasn’t going there when I went to Café Verité. But this is New Orleans, and if you can’t have a cupcake for breakfast here, then where can you? Especially if they are fleur-de-lis cupcakes, as modeled by my wife Misty (who named them her “Who Dat” sunglasses).

Just as I wished, Twitter for Android is designed as a template for making great apps. I think this is wonderful, and the level of integration points will make Android the most superior smartphone development platform (if it isn’t already).

Let’s just hope they release the source to Twitter soon, and developers can start using the libraries to make even cooler Android apps.