I hate your smartphone

When people talk about smartphones, they often mean iPhones and Android phones. Sure there are still Blackberries out there, I think I once saw a guy using a webOS phone, and Microsoft has 89,000 employees who have to use Windows Phone 7, but it's mostly an Android and iPhone world right now. If you have a phone running Android or iOS, life is pretty good. You've probably got a really powerful phone, with a huge number of apps and games to choose from. You've also got a web browser that's more advanced than the one used by most desktop computer users. So given all of those things to be happy about, why is that smartphone owners are so hostile to each other?

iPhones user love to look down their noses and make derisive comments about Android users. Not to be outdone, Android users never miss an opportunity to mock iPhone users. There is an obvious parallel here to Mac vs. Windows, but I think it's actually much nastier than Mac vs. Windows ever was. Here's a list of my theories (in no particular order) on why there is such animosity.

1. It's so easy to do. The truth is that both iOS and Android are deeply flawed. Going back to the Mac vs. Windows comparison, think about how much less mature these smartphone OS's are compared to Windows and OSX. So if you have any inclination to make fun of either OS, it's embarrassingly easy to do. This is where things really differ from Mac vs. Windows. There's not much to debate there. If you wanted to say "Mac sucks", there is a short list of things that you can point to. Not true for iOS or Android.
2. Social networking. In this day and age of social networks, your "friends" shove what they are doing in your face constantly. Smartphone apps make heavy use of this, as a way to spread virally. But what happens when there is an impedance mismatch caused by apps available on one OS but not the other? The folks with the unsupported OS get a little annoyed, and the other folks get an artificial feeling of 133tness
3. It starts at the top. Apple and Google both frequently take shots at each other. They do it at developer conferences. They do it when reporting quarterly earnings. It doesn't stop there. Motorola, Verizon, T-Mobile and others have all taken shots at Apple in commercials seen by millions.
4. Big decisions. You only have one smartphone (unless you are weird like me) and in the US, you usually buy it on a two-year contract. So you have to pick just one, and then you are stuck with it for two years. Thus if anybody is gonna suggest that you made a bad decision, most people will defend their decisions vehemently.
5. The Apple effect. So this really is straight out of Mac vs. Windows. Apple wants their products to seem elite and luxurious. They want the owners to feel like they have purchased far superior products, and feel that they (the user) is superior because of this. It's brilliant marketing, and it totally works. The air of superiority hangs over any Apple product owners, but especially iPhone users. So naturally any non-iPhone users are going to react negatively to the haute attitudes of iPhone users.

The Tablet Wars Have Begun

A few weeks ago I picked up a Samsung Galaxy Tab. Being an Android developer, I thought it was a good idea to see how my apps as well as other apps function on the Tab. After all, it’s hard not to remember what it was like for iPhone developers when the iPad came out. iPhone apps run on the iPad, but they are virtually unusable. They either look ridiculously small, or you can “2x” them and they look like crap. So there was (and is) a lot of pressure on iPhone developers to port their apps to the iPad. Would the same thing hold true for Android developers and the Tab?

I am pleased to say that this is not the case for the Galaxy Tab. Most Android applications look good on the Tab. In fact, I would say that most of them look great. The extra real estate only adds to things. Now there are cases where the apps could make better use of space, or maybe their buttons look a little too big on the Tab. However these are minor issues compared to what it is like to run an iPhone app on an iPad.

That being said, there are some apps that suffer on the Galaxy Tab. Notably some popular weather apps (The Weather Channel’s app, Weather Bug) looked bad on the Tab. However in subsequent weeks these apps have released updates that now look good on the Tab. During that time ESPN’s Scorecenter app also released an update. The previous version of the app looked fine on the Tab, since it relied heavily on ESPN’s mobile website. The update brought a more native UI with less reliance on mobile web. However, it has some serious layout issues and looks bad on the Tab.

So why is it that most apps look good on the Tab, but a few do not? Is it something inherent to Android vs. iOS? Well, yes and no. It is not really anything inherent to Android the OS or Android the SDK. However, Android is designed to work on different sized screens and always has been. As a developer, you are given many choices for creating the layout of your UI, but you are encouraged to use relative/flow-based layouts. These are fluid and resize beautifully on different sized screens. So you take those apps and drop them on to a tablet, and they look just as good.

Of course you don’t have to use these kinds of layouts. You can use layouts that are more fixed and absolute -- which is the norm for iOS developers. However, then you run into Weather Bug and ESPN style problems. Their developers can make adjustments to make their apps look good on tablets, but they may find themselves doing this again when ten-inch tablets start showing up.

I think the fact that most Android apps run seamlessly on the Tab is a significant selling point of the device. If you have 200 iPhone apps, chances are that either many of them will not have been ported to the iPad, or if they were, then it will be as a different app (Blah blah blah HD!) that you will have to purchase. If you have 200 Android apps, then you are good to go on the Tab.

The Tab has a few other advantages over the iPad. The one most people talk about is that it is more portable. This is not a small advantage. I just got back from a trip to Portland. When I’m there, I often like to go to the Starbucks near Pioneer Square to get tea and a scone for breakfast. One time I took my iPad with me, because I wanted to read blogs or news, catch up on Twitter and Facebook, etc. while I ate my scone. However I didn’t like having to carry it, and it was especially inconvenient once I got my tea and scone (3 items, 2 hands.) So I took it with me one time and never again. Instead I would just use either my iPhone or Nexus One. However this time I had my Tab and I always took it. Even with it raining, I could just put it in the inside pocket of my jacket and it was no trouble at all.

Then there is the related issue of weight. I have often read books (via the Kindle app) on my iPad while on airplanes, or at a café, or just around my house. The iPad always makes my wrist very tired, and I find myself switching hands or trying to awkwardly prop it up on something. The Tab is so much lighter that this is never a problem. I am currently reading Stephen King’s The Waste Lands on the Tab (also via the Kindle app) and have had no problems with my wrist tiring out.

I would say that the above three things are the major advantages of the Galaxy Tab over the iPad. Android apps work much better on it than iPhone apps work on the iPad; it is portable; it is much lighter. There are some other things too, like it having two cameras instead of zero, or being available on Verizon, T-Mobile, etc. Just to be fair though, the iPad still has some significant advantages over the Tab.

The bigger screen is obviously the biggest advantage. This really opens up the iPad for a lot of experiences that aren’t possible on the Tab, or would suffer. Also, it makes using non-mobile optimized websites much better on the iPad. For example, ebay.com is pretty usable on the iPad. On the Tab, it is ok in landscape mode, but definitely not in portrait. So I would not really consider using it on the Galaxy Tab, but would on the iPad. Of course there is still a decent chance that a non-mobile optimized site is going to have problems on the iPad still.

The bigger size of the iPad also leads to a larger battery. To me the battery life of the iPad is amazing. I do not use my iPad that much, so often it will go many days on standby. It blows me away how little battery is drained from say five days of standby. I have the non-3G iPad, so that makes a big difference, but still you just cannot beat the battery life of the iPad.

Big screen and big battery are big advantages. However if you want to watch TV & movies on your tablet-of-choice, then the iPad has an even more bigger advantage: iTunes. There is no good way to download a movie and watch it on your Galaxy Tab. I think we will see Netflix on Android and thus the Tab in the next few months. That will help, but Netflix’s streaming selection is still very limited. However, iTunes has an excellent selection. I would guess that we will also see Amazon’s Video-on-Demand on Android, since it is on the Android-based GoogleTV. That will help with selection as well, but still it will fall well short of what’s on iTunes. Plus any streaming solution is more limited than iTunes buy/rent model. Not to mention that there is already a Netflix iPad app, and it would be shocking if Amazon didn’t have a VOD app for the iPad sometime next year as well. If you want to watch TV shows or movies on your tablet, the iPad is definitely the way to go for the foreseeable future.

Based on the above, if a friend/family member asked me if they should buy a Galaxy Tab or an iPad I would ask them three questions:
1.) Do you plan on using it primarily at home/office, or do you want to take it with you when you are out or traveling?
2.) Do you use a lot of apps on your phone?
3.) Do you want to watch TV shows or movies on it?

Regardless of how they answered these questions, I think that a tablet like the Galaxy Tab or the iPad can replace a laptop for most people, but not everyone. If you are a heavy user of office-apps (word processing, spreadsheet, presentation software), then a tablet cannot be your primary device. I think the new MacBook Air is perfect for such folks. This is also a space where the ChromeOS netbooks have a chance to compete, as well as traditional Windows-based netbooks. If you do more “creative” activities, like graphical design, photography, and of course programming, then you need a real machine with serious RAM & CPU. That’s why my MacBook Pro will remain my primary machine for a long time. A tablet will always be complementary for folks like me. That’s why I think the portability and lightness of the Galaxy Tab outweighs the bigger screen and battery of the iPad for people who really need a laptop or even a netbook.

Android Love

My colleague David Beach recently penned a great post about developing apps for Android. If you haven't read it, go read it now. Seriously. I know a lot of you will see that he's a product manager and stop right there, but get your lazy ass back over there and read it anyways. Look, even TechCrunch picked up his post. Ok I know that might actually be a disincentive for some of you, but still...

Anyways, I want to make a retort of sort to Beach and talk about why I love Android. However, I have to start by making a confession. My go-to phone is my iPhone 4. So why would I, an Android fanboy and somebody who is writing a book about Android development, use an iPhone 4? The answer is really quite simple. The apps are better.

My secondary device is a Nexus One, and I use it a lot. I would say I use it about 30-40% of the time. Many of the apps that I use a lot are available on both: eBay, PayPal, Facebook, Twitter, Foursquare, Yelp, Urban Spoon, Bank of America, Bump. However, in almost all cases, the iPhone app is just a lot better. This is definitely the case for the eBay app. It is most obviously the case for Facebook, which often dumps you off to their mobile web site to do things that you can't do in the app, even though you can do them on the iPhone app. The one app that I would say more than holds its own is the Twitter app, but even there I miss the conversations feature on the Twitter app for iPhone.

It's understandable that the apps on the iPhone are better. In many/most cases, these apps have been out 1+ year longer than their Android equivalents. So they have more features, less bugs, and are more refined in general. Further, most companies have a lot more iPhone users than Android (this is obviously changing), so they are going to invest more heavily in iPhone development. You probably want your best developer working on your iPhone app. Then again, Joe frickin' Hewitt is doing Android development now, so the developers have arrived.

I went off on this little tangent because it actually brings us back to the original topic. I use an iPhone still because its apps are better. I claim that the apps being better is mostly because of the head start that the iPhone is still enjoying. However, you could definitely infer from Beach's writeup (you did read it, right?) that it is easier to develop a great app for the iPhone than it is for Android. Heck, of the apps I listed earlier, the one that holds it own is the Twitter app. This is an app that was largely developed by Google -- who has to scratch their Android itch by developing 3rd party apps, because they largely focus on mobile web apps instead of native apps despite their ownership of the Android platform. Maybe all of us 3rd party developers have no chance of developing a great Android app because it is just too hard?

Obviously I do not think this is the case. The challenges that Beach lays out are absolutely spot on. For designers, there is no HIG, it is very much a free-for-all. I would add that the default controls and themes are also poor. You simply must do some significant styling to your app or it will look like ass. I think some/all of this will be addressed with the Gingerbread release. It is fair to say that Apple would have never gone this route, i.e. wait until the 3.0 version of their software to focus on user experience. That is fair, and since we haven't seen Gingerbread yet, maybe it will continue to fall short. Even if you can't rely on the OS+SDK to make your app look spiffy, you can still do it yourself. It's not that hard. I mean, it's not like you have to re-invent the button or something. It just takes some experience and knowledge of what is possible with Android.

Once you get past the eye candy, many things about Android development are actually quite nice. The development environment is excellent. Yes, there will be people who just don't like Eclipse and thus ADT, just as there are people who just don't like XCode. However, ADT's capabilities are quite advanced. One common complaint I have heard is about the amount of time that it takes to start an Android emulator image. This is contrast to the iPhone simulator, which starts up rapidly. However, if you consider that the Android emulator is an actual virtual machine being booted up, and not a shell that is simply relying on the underlying computer, then this is understandable. The advantages are obvious. Most apps run slower on the Android emulator than on a real device. The only advantage they may have over a real device is the network speed, but even this can be easily throttled to emulate edge or 3G conditions. If your app runs fast on the emulator, it is going to run great on a real device. You just can't say this about iPhones apps running on the simulator.

Going beyond the tools, Android is a more advanced operating system, at least from an application developer's standpoint. It lets you do things that are just not possible on the iPhone. The obvious thing here is multitasking. With Android's background services, you can always have the latest data from a remote server and never have to wait for it when your application launches. Imagine if you had an up-to-the-second Twitter stream always waiting for you before you launch the Twitter app. It is possible on Android. It is not possible on the iPhone.

It doesn't stop there. Communication between apps is formally supported on Android (though it could be improved) and can only be hacked on the iPhone. How many apps do you have that have some kind of "post it to Facebook" feature? Wouldn't it be great if you could just use the Facebook app to handle this -- thus no need to re-enter your Facebook name/password? It is possible on Android. It could sort of be hacked in a limited way on the iPhone, but it is not going to be pretty or seamless.

These are just a couple of examples. My point is that even though the UI/UX issues on Android are significant, they are not insurmountable. Once you get past them, the other advantages of Android are even more significant. As Android apps mature and Android developers mature, we should see the day where Android apps are better than iPhone apps. I don't think that day is too far off. Now would that counter-balance the arrival of the iPhone on Verizon and other carriers? I think so.

I will conclude on a more personal note once again. I work with all of the mobile teams here at eBay, including our iPhone teams. I've had a much more involved role on our Android app for awhile now, and I want it to be one of the first examples of an Android app that is significantly better than the iPhone equivalent. That's not because I'm an iPhone hater (though I'm sure we'd all agree that competition is a very good thing)  or something, it's just because I think that by fully tapping the capabilities of the Android platform, we can deliver something incredibly useful to our users. Mobile software development is an amazing experience. Our users get to connect with our software in a much more personal way. Our software literally runs in the palm of their hands. That's a remarkable place to be. Right now I think Android is the platform that can deliver the most in that place, and I'm going to put my money where my mouth is.

iOS Multitasking

By now you’ve seen the ads. Anyone who works in mobile totally saw it coming. It’s the supposed revolutionary way to do multitasking in iOS, the new name for the iPhone OS. It’s complete bullshit, and here’s why.

It’s Not Revolutionary
Personally, I don’t really care about this point. However, it must be noted that the multitasking on the iPhone is strictly speaking a proper subset of the multitasking architecture used by Android and Palm’s webOS. Does it really matter? No, not really, but it is certainly annoying to hear Apple talk about how they didn’t do multitasking in the past because they hadn’t figured it out yet. The notion that what they ‘came up with’ is some brilliant solution that it took four years to figure out is insulting to the intelligence of developers. Not that that matters...

It’s Not Multitasking
Even Apple is pretty honest about this ... to developers. For us they say “it’s actually something We call Fast App Switching, and it’s all most of you people need.” This is the feature that was done by Android and webOS for the last couple of years. On iOS, when a user switches apps or hits the home button, your app has a brief time when it “runs in the background.” Then it becomes suspended. In its suspended state, it is still in memory, but gets no CPU cycles. If the user re-opens it or switches back to it, then it picks up right where it was before. Assuming that it is like Android (and everything else about Fast App Switching is very similar), then as a developer you might need to save some transient data, like if there is a form that is half-filled by the user. However, often you will not need to do anything to take advantage of this, just recompile with iOS 4.0 as your target.
But wait, there’s more. You should not count on your app staying suspended indefinitely. In fact, there’s a very good chance it will be terminated (that’s the official word.) This is exactly what happens when you go to the home screen on previous versions of iPhone OS, your app no longer takes up any memory. Now the user can still ‘switch’ back to your app (or re-open of course), but now it will be a re-launch of the app. In other words, it is just like closing your app, then re-opening it on iPhone OS 3.x.
This can obviously lead to inconsistent app behavior. Sometimes the user might switch away from your app, then switch back and be back at the same screen in your app that they were at before. Other times, they could do the same thing, but instead they are back to the opening sequence of your app. Apple wants you to change your app to remove this potential inconsistency. They’ve kind of given you a way to do this. First, when your app goes from being active to suspended, a new event is fired to your application’s delegate. All you have to do is add this new method (applicationDidEnterBackground:) to your delegate. In that method, you can save the state of your application. However, you might not have enough time. You can wrap your code with a start/end task completion calls, and then get up to ten minutes to finish saving your state. Alternatively, you can incrementally save state. Now truth be told, many apps (especially games) already do this, so that when you restart your app, it always picks up right where the user left off. Apple has essentially taken this pattern that other apps have adopted, promoted it to a best practice, and give you some extra tools to make it a little easier to implement.
There is one other thing that you might want to do right before your app gets suspended. You can decrease the probability of your app getting terminated by freeing up as much memory as you can. The iOS Terminator is going to kill apps that use more memory first. So free up as much memory as possible, and maybe it won’t kill your app. There’s no guarantees though. If the user launches an app that needs a lot of memory (and don’t they all?) then it doesn’t matter how little memory your app takes up. Everything is getting terminated. Hence Apple’s desire for you to always save state and never rely on being suspended when the user switches back to your app. However, if you do that, then is there any point to freeing up memory? Well theoretically it should be quicker to switch to a suspended app than a terminated one, so by freeing up memory you will be increasing the probability that your users will get a slightly better experience.

What is Real Multitasking?
Well strictly speaking, true multitasking would be to allow any given application to continue running as  normal when it is no longer in the foreground. This is what happens on desktop computers, and that sort of sets the expectation for smartphones. I think this is actually how Blackberry works (or it used, it has been many years since I bought a new Blackberry.) It’s not how Android works, and it’s obviously not how iOS 4 works. The major problem with this on more limited devices is that it causes those devices to run out of memory and use virtual memory. This makes everything on the device run sluggishly, as everything becomes gated by the swapping between real and virtual memory. Those non-foreground apps can also consume CPU and network. The CPU consumption might be an issue if you tried to run multiple games simultaneously -- just like it would on your desktop computer. Apple claims the CPU/network access real kill your battery. We’ll examine that later. Regardless, once you decide that a background app can lose its right to memory, it can’t function anyways. CPU/network becomes a moot point. Both Android and iOS terminate background apps to free up memory, something no desktop OS will do.
So iOS and Android both use similar pseudo-multitasking to make it seem like multitasking to the user. To prevent memory from running out and hosing the system, they terminate background apps at will. Both operating systems give you a way around this, a way for you to continue to execute a program in the background. That is where the similarities end.
On Android, you can create your own background service. That service can be in its own process, i.e. it gets its own block of memory allocated to it. That way if your application gets terminated, the service lives on. However, a service can be terminated just like an app. So you cannot rely on the service always running, instead the service should be there to enhance your application. Further, Android gives you ways to get your service restarted/pinged on a regular basis to do work.
On iOS, there are just a couple of types of applications that are allowed to run as a background service. Even then, they do not get their own memory. Instead they stay suspended and the OS sends them events periodically that allows them to run in the background again while they do something. Apple says they do not want to provide the Android style background services, because they (Apple) decided that the great majority of apps would not benefit from this anyways. Further, they think that such an architecture would lead to many background services running, killing the device’s battery. So instead they picked the types of apps that they say will benefit from background processing: music players, navigation, and voice-over-IP. The most ironic part of this is that the enabled a class of app, navigation, that has the most harmful effects to your battery (well maybe games are worse.)
I’ll talk about battery life in a second. First I want to address this notion that Apple has determined which apps would benefit from background processing, and which would not. As both a developer and a user, this is offensive. Apple has little knowledge of how my app works, or of how my users interact with the app. Further, they are obviously wrong. I can give you three examples of apps that use background services on Android to greatly enhance user experience: eBay, Facebook, and Twitter. You’re probably not surprised that I cited my company’s app, but maybe the other two did surprise you. All three use a background service to periodically download time sensitive data (current price of items, friend requests, status updates, tweets, etc.) So when you launch the apps or switch to them, you do not wait for all of this data to be downloaded -- like you do on all three companies’ apps on the iPhone. Instead you are presented with some fresh data (maybe a few minutes old), while the absolute freshest data is being downloaded in the background. You get to immediately interact with the apps. On iOS it might be possible to allow immediate interaction, but the data can only be as fresh as the last time you ran the app. This will usually be hours old, which makes it virtually useless for these apps.
There is no question in my mind that user experience can be better on Android than on iOS for these apps, and I don’t think they are unique. I mean c’mon, we’re talking about eBay, Facebook, and Twitter. Perhaps you’ve heard of these companies? It seems obvious that any kind of real-time/interactive/social based website is going to benefit from background processing for their apps. That’s a pretty broad class of apps, but I doubt it’s exhaustive. I’m not smart enough to figure out all of the apps that would benefit from background processing -- and neither is Apple.

Battery Life FUD
Ok, but what about the last plank in Apple’s argument: battery life. Well, as I pointed out earlier, they enabled a class of application that is devastating on battery life: navigation. These apps require constant high precision GPS information, which is very expensive. So their argument is not consistent with their behavior, still that doesn’t make their argument wrong.
The apps that I mentioned earlier all are guilty of something that is supposedly deadly to battery life: they periodically use the network to download data. How bad is this? Well obviously it depends on how often, and how many network calls are made, along with how much data is being sent back and forth. I’ve done some experimenting on this -- hey I work on one of the apps on that list of naughty apps. In my experiment I had an app that downloaded 100K+ data every two minutes. The effect on battery life was less than 3%. That’s right. You could let such an app run in the background for days and days, and your phone would still have plenty of battery.
Now wait a minute, I know what you’re thinking. You can’t even go one day without recharging your phone, and you’ve got an iPhone that doesn’t have anything running in the background (by the way this is not true, Apple’s apps have been able to run in the background since the very first iPhone.) Further, you don’t even use it to make phone calls, yet it’s got maybe 12 hours of battery life. What gives? The answer is surprisingly simple, the screen. The screen on your beautiful phone is what drains your battery the most. So anything that involves the screen being on -- which is every kind of app on the iPhone currently -- will significantly drain your battery. Everything else they do has little noticeable effect on battery life, with two exceptions. Anything that rapidly changes that pretty screen will consume your battery even faster. That’s why many games will hammer your battery. I’ve had times where I played Civ on my iPhone for maybe twenty minutes, and it lopped off a third of my battery. That game doesn’t even have that much eye candy. The other battery blaster is the aforementioned GPS, for obvious reasons. All of those Android users with eBay, Facebook, and Twitter installed are doing just fine.

But You're Gonna Love It!
So with all of that being said... users will really appreciate Fast App Switching in iOS 4. Why am I sure of this? Because Android users have always loved it. It’s one of those things where iPhone users don’t know what they are missing. Thus it will be delightful for them, and they will think Apple is full of geniuses. Actually I think it will put some serious pressure on Apple to update the iPad to iOS 4 (or maybe 4.1? Will we ever run the exact same OS on the iPhone and iPad?) People will get used to having Fast App Switching on their iPhone, and they will be so annoyed that they don’t have it on their iPad. I hope we’ll eventually see the same thing with regards to general purpose background processing. Maybe one day this will be part of iOS, and then it will be annoying to use older versions on the OS that don’t have this feature.

Update: You can add Instapaper to the list of apps whose developer would like it to be able to run in the background, so that it can improve user experience. Marco has an interesting proposal to tweak iOS to suit the needs of his app, and no doubt many others. It's better than the current situation, but I still think it's foolish to try to figure out all of the types of apps that need background processing, and add special APIs for each such app. While at WWDC, I talked to developers who work on some very popular sports and weather apps, and they too were incredibly disappointed by iOS. One of them proposed a new type of remote push notification that would not be displayed and only processed in the background.

WWDC Wish List

Tomorrow is WWDC. Much like how I had an Android wish list for Google I/O (and I got my top two wishes!) a few weeks ago, I have one for the iPhone and WWDC. Given that OS 4.0 has been in beta for quite awhile, there is a little less suspense. So my wish list is a little more product based instead of development based.

1.) iPhone for Verizon. AT&T has nixed the generous data plans for the iPad (as well as for the iPhone,) so really why is there any reason for Apple to stay exclusive with them? In fact one could imagine that AT&T busted out the new pricing last week because they knew their exclusivity was coming to an end. I certainly hope this is the case. Personally I would not switch to Verizon, but I hope that many folks do. Plus I think that if folks had a choice of iPhone on AT&T or iPhone on Verizon, then both companies would compete much harder, improving networks and dropping prices. This is a key but subtle component of the Android strategy that fanboys/apologists often seem to miss.
2.) Non-AppStore apps. No way, right? Don't be so sure. How easy would it be for Apple to give folks a deeply buried user preference for allowing non-AppStore apps on their iPhone? An insignificant number of users would ever enable this "dangerous" option, but it would do so much. From a PR perspective, it would take the heat off Apple. Actually this might not just be PR, it might be legal as well. Want to use Flash to develop for the iPhone? Ok, just distribute it through your own channels to users who want to go outside of the AppStore. Obviously this would really make life easier on developers. The current provisioning process is ridiculous.
3.) Mobile Safari improvements. I expect that we'll hear about how Safari and/or Mobile Safari is fifty-billion percent faster than ... something else. Apple is fond of blowing up micro-benchmarks. I'd like to also see some new features. I'd really like to see Web Workers, especially since Safari already supports them. I'd be thrilled to see the Device API, so that we can get access to the camera (and how about that front-facing camera, too?) and how about access to a user's contacts? It feels like Android'd browser is really pulling ahead of Mobile Safari, so it would be great to see Apple take back their lead.
4.) Real multitasking. I'm probably going to hurl tomorrow when I have to hear Steve Jobs brag about multitasking in iPhone OS 4.0. It's bullshit. As I've said before, OS 4.0 does not implement multitasking, it implements a handful of multitasking use cases. There is a big difference. Of course there is no chance of this. The multitasking in OS 4.0 is obviously technology designed by marketing and business people, not by engineers. They want to put an end to those obnoxious Motorola Droid commercials that make fun of a "a phone that can't walk and chew gum at the same time." So instead of figuring out how to do multitasking right, so that it enables developers without sacrificing performance, we get a useless feature (unless you happen to be one of the three use cases) that will be hailed as revolutionary.

Mobile Zealotry

"You're either with me or against me!"
Does this feel like the rhetoric coming out of Google and Apple lately? Sometimes I wonder if Russell from Survivor is working for these guys. I was at Google I/O last week, and I have to admit that Vic Gundotra delivered a great keynote. It really got the troops excited.

"One man, one company, one device, one carrier would be our only choice ... Not the Future We Want"
Indeed. But before you go out and get an Android tattoo, and toss your iPhone off of the Golden Gate Bridge, take a deep breath and remember: You don't work for Google (unless you do, in which case I assume you've already got said tattoo.) You should not care who wins this jihad -- but make sure that you aren't collateral damage.

If you are a mobile developer, what you should most care about is delivering the best and most useful experience to your users. So first and foremost, you need to care about what kind of devices your users are using. If they are all iPhone users and you really want to build Android apps, well sorry. Further, if they are all Blackberry users, then you can just ignore the drama going on here in the Valley.

Of course the device of choice for your users today is quite possibly not what they will be using tomorrow. Former Android engineer Cedric Beust makes the point that the iPhone may well have peaked. Things look great when you're at your peak, especially if you don't realize that the descent has begun. So you might build a killer iPhone app this year, only to find that your users have moved on next year. Nobody ever said that this was an easy game.

Hedging your bets and investing in multiple platforms seems like the safe thing to do, if it's practical. But don't forget the other factor: delivering a great app. If you can't deliver a great app on Android, then don't bother. If you can't deliver on the iPhone, then don't bother. Both Apple and Google have gone out of their way to provide developers with fantastic tools and platforms for creating great apps, so this may be a moot point. There are definitely types of apps that are better suited for one platform than the other. For example, the iPhone seems to be superior for games. If you look at the success of consoles, you can see why that kind of environment where hardware and software are highly standardized, translates well to the iPhone. Similarly, the lack of background processing on the iPhone (and don't believe any hype about iPhone OS 4 changing this, it does not except in a few special cases) cripples the capabilities of many iPhone apps.

The most important thing to keep in mind in all of this is that it is in Apple and Google's best interests to be as divisive as possible. If they can convince you that they are "right" and that you should only develop for their platform, this is a huge win for them. So expect the rhetoric to only get worse. How many days until WWDC?

Apple, Flash, and The Truth

I'm sure by now you've read "Steve Jobs"'s Thoughts on Flash. Did it convince you? Do you think it was truthful? Not me. Sure it has some valid points, especially about Flash being buggy on OSX. As someone who has developed Flash applications using a Mac, I am especially aware of this bugginess, and part of me can't help but get a perverse sense of satisfaction that this bugginess is now coming back to haunt Adobe. However, this doesn't change the fact that Jobs's epistle is far from the truth. It is corporate slander, designed to make Adobe look as bad as possible. Why? So that when devices from competitor's ship with full support for Flash, this technological advantage can be discredited in the eyes of consumers. In other words, this well thought out post by Apple is not some intellectual/technical analysis, it is just marketing designed to boost Apple's profits.

The most dishonest thing about the post is what Apple says is "the most important reason" to ban Flash from their devices: that it will result in sub-standard apps and hurt their iPhone/iPad OS platform. This is complete bullshit. It's not like developers would suddenly only be able to create iPhone apps using Flash. It's not like they could no longer use all of the tools they use today. The difference is that they would have a choice. They could choose to use Flash. Or they could choose to use Objective-C/Cocoa/XCode.

But don't forget, that not only would developers have a choice, but so would consumers. If for some strange reason, some developers started choosing to use Flash,  it's not like consumers would be forced to buy those Flash-authored apps. No, they could still choose other, traditional apps. In fact, if, as Apple claims, Flash-authored apps would be of such low quality, then one would expect that few consumers would choose to purchase those apps.

So if Apple allowed developers to use whatever tools and technology they wanted to use, to create apps for the iPhone and iPad, what might happen? Well if Apple's claims are right, then there would be bad apps that nobody would buy (aren't there already a lot of such apps on the App Store?). Consumers aren't idiots, and they won't buy crappy apps when there will be better alternatives. So those Flash-authored apps will lose money. Developers aren't idiots, and they won't keep using technology that produces software that nobody wants. So they would abandon Flash and go back to Cocoa. So Apple's "concerns" would be unwarranted.

Or perhaps what would happen is that some developers would produce good apps using Flash that consumers bought for their iPhones. Certainly developers would continue to use Flash. However, in this scenario, Apple's "concerns" are proven to be false -- Flash produces some good apps. But wait, what about Flash holding back innovation on the platform? Apple would still be free to add new features to their OS, and make them available to developers through new APIs in the iPhone SDK. Who knows how long it would take Adobe to expose those features through the Flash authoring tools, but who cares? If those features greatly improve apps, and they aren't available in Flash authoring, then what happens? The power of choice wins again. Developers can still choose to use Cocoa, tap into these innovations, and user's can choose to purchase the apps that take advantage of these innovations. If these features are so great, one might expect that Adobe would try to bring them to Flash authoring as quickly as possible. Either way, the notion that the Flash platform would be held back makes no sense.

So Apple's self-described most important point is so false that it is laughable. Some of their other parts are equally false. For example, the notion of touch and Flash. Yes, many things in Flash are designed for users interacting with a mouse, not a finger. Such things don't work well on touch devices. However, this is not just true for Flash. It is equally true for HTML and JavaScript. If you've done a lot of surfing on your iPhone or iPad, you have surely experienced the "rollover" issues described in Apple's post. Want more examples? Check out this clever little video on HTML 5 and the iPad:


So why all the bullshit? As I said earlier, the reason for the post is to discredit any competitor that provides Flash support on their devices. First and foremost on that list is Android, which will support Flash in Android OS 2.2. That doesn't explain why Apple doesn't want to allow developers to use Flash to develop for the iPhone? The answer to that is simple. They want complete control of their platform. If you want to make money off of the iPhone, you have to be in bed with Apple. They saw how the web has hurt Microsoft, and they will not let this happen on the iPhone or iPad.

Now wait a minute, isn't Apple investing heavily in the web, namely HTML 5? Doesn't that demonstrate that they are willing to give up control of their platform? Yes, and no. Yes, Apple has invested into WebKit, a technology that in various forms implements a decent chunk of the HTML 5 standard. But you see, the key word here is "standard." This is how Apple fools you into thinking that they are providing an "open" alternative to their proprietary system.

It's easy to get fooled into thinking that any company that implements and open standard is innovative, but just the opposite is true. We think standards=innovation for browsers because of Microsoft IE 6. That browser dominated the world for a long while being completely stagnant. It was both non-standard and non-innovative, but this is an exceptional. It is rare that such technology can flourish. It took the unique nature of Windows, IE, and Microsoft's legal troubles to produce this situation.

Adopting a standard just means that you either change an existing feature of your technology to comply with the standard, or you copy a feature from others in the space. It is anti-innovation. When it comes to web standards, they are introduced post-hoc. XMLHttpRequest, the key technology behind Ajax, was proprietary Microsoft technology for many years before it became a standard. Many of the features of HTML 5 were introduced by various plugin technologies like Flash or Google Gears before they became part of the HTML 5 spec. You cannot innovate while waiting for some super slow moving corporate committee to vote on a new standard.

Going back to the iPhone/iPad, Apple is saying: pick either Cocoa and go through the App Store, or stick to the web, but only the "open standards" part of the web. They have given you a choice, but only the weakest, most impotent choice possible. You see this is where the other part of their Flash ban comes into affect. Not only have they recently banned compiling a Flash authored application into a native iPhone application, they have always banned Flash running in the browser. Why? Because with browser plugin technologies like Flash, Silverlight, and yes even Java, you can create user experience's on par with desktop applications. If they allowed Flash in the browser on the iPhone, then developers could create web applications that might rival the native iPhone applications. And we wouldn't want that, now would we? So Apple give you a single alternative to using Cocoa/XCode/AppStore, and then they horribly cripple it, by removing the most innovative parts and tying a design-by-committee-technology weight around its neck. Apple's endorsement of HTML 5 is one of the greatest marketing ruses ever. They stifle innovation, limit choice, and line their own pockets while getting everyone to believe they are being developer friendly and innovative.

After all of the above, you might think that I am very anti-Apple, anti-iPhone, anti-iPad. I'm not at all. I am anti-bullshit though. I don't like being lied to and treated like a lemming. Apple has every right to keep Flash off of their devices. It's their OS after all. They have very right to ban apps that were authored with Flash from their AppStore. It's their AppStore after all. Just don't lie to me about this stuff. Don't say it's better for developers or better for consumers, when it's actually worse for both. Just tell the truth: it's just better for Apple.

Thoughts on iPhone OS 4.0 and Section 3.3.1

I'm on vacation right now. Earlier in the week, I took my kids to the Kennedy Space Center:

Now I am in my hometown of Panama City, Florida visiting family and friends. However, yesterday Apple released the beta of iPhone OS 4.0. I read about it briefly on my iPhone while riding around town yesterday. Saw that it supported multi-tasking -- yay! Saw some nice features, like unified inbox, multiple Exchange accounts, geo-tagged pictures, etc. I was psyched, and planned on reading more about it later.

Later came, and I started reading more details on my laptop. Of course what everyone was talking about was Section 3.3.1. Soon I went from being psyched about OS 4.0, to being very annoyed about it. Now I know that some people do not think Apple is singling out Adobe, but it damn sure seems like a reaction to Flash CS5. Let's not forget that Apple also made several barely-disguised jabs at Google-owned AdMob while unveiling Apple's own iAd platform. OS 4.0 is all about Apple going after other big software companies that are making money or trying to make money off of the iPhone. However, in the process, Apple is going to take out other companies like Appcelerator. Not that Apple cares...

So yeah, Apple is screwing lots of other people who are trying to make a dime while at the same time enabling more developers to support the iPhone/iPad platform. Nothing to see here, move along. A number of people have pointed out that Microsoft in all of its monopolistic, evil ways never tried to pull anything like this. In fact, this is polar opposite of Microsoft. For all of their faults, Microsoft always supported developers. Sure they wanted to sell you Visual Studio, but if you wanted to use Java Swing or GTK or C++ using make, they did not care. Heck, they even weighed down Windows for years and years to maintain backwards compatibility APIs used by 3rd party developers.

Enough negativity... there are many good things about OS 4.0. The most obvious thing is its multi-tasking. To be honest though, it is fundamentally flawed. It is an "OS" feature that is purely designed around use cases. It's like Apple saw ads by Google/Verizon and Palm, that showed users listening to Pandora in the background, or using GPS, or receiving VOIP calls, and told their engineers "Can we do this without really enabling background processing?" Background apps are limited to these use cases: Pandora (music), Garmin/Magellan (GPS), and Skype (VOIP). That is lame. Background apps are also prohibited from networking (wait does this screw Pandora after all?) Better than nothing? Yes, but lame.

As part of this background processing stack, Objective-C blocks have finally come to the iPhone. Yep, that means closures. Of course, it's grafted on top of Cocoa, so that means you can't just take a button and set its event handler to a block of code. But again, better than nothing. Maybe we'll see some Cocoa evolution that will allow developers to take advantage of this.

Back to the meat of the background processing... One of the use cases mentioned above is geolocation. One of the new features added in OS 4.0 is advertising via iAd. As mentioned earlier, this is a clear attack on Google's AdMob platform. The impending explosion of advertising and constantly location-aware applications suggests that location based advertising could also see an explosion. Of course a background app that is location aware cannot make network calls, a prerequisite for fetching relevant ads. Ah, but they have iAd! Apple has positioned itself quite well to take advantage of mobile advertising.

Finally, I've probed the new version of Safari. It's version 532 of WebKit, up from build 528 in iPhone 3.1.3 and 531 in Safari 4.0.4. However, it still doesn't support Web Workers... Shortly after OS 4.0 was announced, Apple also announced WebKit2. This appears to be WebKit built on multi-processing, a la Chrome. No word on when it will come to the iPhone and iPad, but perhaps that is where Apple's efforts are these days.

iPad Web Applications

So you might have heard about this... This Saturday, April 3, there's a new computer coming out from Apple. You might have heard about it. Anyways, lots of iPhone developers have been scrambling to port their iPhone apps or write new iPad apps. A lot of folks have been predicting that developers would start to shun Apple after all of the controversies surrounding iPhone app submissions and the "walled garden" approach that Apple has taken. On the other hand, Microsoft has decided that a controversial walled gardens are once again the way to go, and is diligently copying Apple. Well if the iPad is any indicator, developers continue to agree with Apple and Microsoft. There is a lot of interest in developing native applications for the iPad.

Still, if you're like me and a big part of your job is to figure out how to build web applications for all kinds of devices, you have probably been spending a lot of time trying to figure out what to do about the iPad. On one hand, it's a big enough device that most websites will look just fine on it.

I think you must agree that the above looks a heck of a lot better than a "mobile optimized" site like this:

This seems great at first -- no work! Just make sure that if you are using any browser sniffing/redirecting code that it does not redirect for the iPad. However, there are some disadvantages to this. First, there are some issues with 'normal' sites that will not translate well to the iPad. There is the obvious thing with Flash... There are more subtle things like, "hovers", i.e. mouse-overs. That is when you toss up a UI layer when a user hovers their mouse over a link, or an image, or whatever. These are pretty popular, and they are not going to work on the iPad. Apple has quite figured out how to detect a finger hover... There are other events that are different on the iPad as well. There is also the question of how to best use the real-estate on the device, and the related question of dealing with landscape mode.

I think a lot of sites will look great in landscape mode, but that doesn't mean that they couldn't look better. It might be more optimal to go to a multi-column layout. That could let a site place useful content "above the fold", i.e. visible so the user does not have to scroll to get to it.

There's also the possibility of "embracing the native" on the web. There are a lot of iPhone-optimized websites that do a good job of making their website look and feel like a native iPhone application. Joe Hewitt's excellent iUi JS/CSS framework is an easy way to do this. The iPad has some of its own metaphors not found in the iPhone. Take a look at this native iPad app:


Notice all of those columns? We've kind of touched on that already. Did you notice the pop-over menus? These are likely to be ubiquitous on the iPad. Here is a picture of them from one of Apple's iPad apps, Numbers:

Obviously there is nothing in HTML-land that is quite like that. However, it is certainly possible to craft something similar. In a way, it's kind of like the mouse-over menus that are popular on the web, only the interaction model is slightly different and the UI is definitely more rich than the average mouse-over menu.

So what to do? Just stick with your "normal" site? Develop an iPad optimized site? Tweak your iPhone-optimized site to suck less on the iPad? Tweak your normal site to suck less on the iPad?

Testing Geolocation for Mobile Web Apps

Using geolocation in a web application is really cool. The JavaScript API is quite simple. Testing it, can be a different story. Here are some useful tips:

If you only need to get the user's location once, testing is not too bad at all. First, you can actually use Firefox 3.5+. However, make sure that you are using wi-fi, or otherwise you will never get a location. Your app will just seem to hang. Anyways, being able to use Firefox for testing is great because it is a full desktop browser with awesome developers tools like Firebug. Often you will have some pretty complex JavaScript in a web application that uses geolocation, so being able to debug with Firefox/Firebug is invaluable.

Of course you will also want to test on mobile browsers. You can definitely use the iPhone simulator that is part of the iPhone SDK. Geolocation works great on this, but it gives you a bogus location -- the location of Apple's HQ in Cupertino, CA. If you actually live near Cupertino, this can be really misleading. Anyways, it will only give you this location, never anything else. So it is somewhat limited.

Testing on an Android emulator is another possibility. However, in my experience, it is currently broken. On an Android device, when a web page wants your location, the browser brings up a window to prompt you for permission. On the emulator's browser, I never see this permission window and the app just hangs and never returns a location. That's a bummer, since the Android SDK makes it possible to send mock GPS coordinates to an Android emulator. It would be great if web developers could take advantage of this.

Testing on an actual devices is of course a possibility. Your web application needs to be reachable by the device. This could mean using wi-fi on your device, so you are in the same intranet as your development sever, or it could mean deploying your app somewhere public. I like using the Google App Engine for the latter, and then test on the assortment of devices that I have laying around.

If you need to test location updates, i.e. when the user moves you want your web application to know about it and respond in some way, then things get trickier. The iPhone simulator is out of the question. An Android emulator still suffers from the same problems. So now you are down to devices. There is no way to send mock GPS to an iPhone, so to test on an iPhone, you need to actually change your physical location. Coding and driving FTW!

However, it should be possible to test on an Android device. The Android SDK theoretically allows you to send mock GPS to a real device. The command that should work is "adb -s XXX shell geo fix AAA BBB" where XXX is the serial number of your device (get it by doing "adb devices"), and AAA/BBB are the fake latitude/longitude. Sounds good, right? I tried this on my Nexus One, and got a big fat permission denied. Turns out you need to be root to do this on a real device. Ok, so I rooted my Nexus One. Then I tried it. Result? "gps: not found." Suddenly the gps command was not recognized. So ... coding and driving FTW!

Nexus One vs. iPhone

I recently purchased a Nexus One, primarily for Android development. I needed a device for developing Android 2.0+ on. The 2.0 SDK has been out for almost three months now, and yet it is still not available for my old developer phone, the Android Dev Phone One. I had gotten pessimistic about HTC making Android 2.1 (since apparently 2.0 is being skipped) for the ADP1, which is essentially the G1, so it was time to buy a new phone for development. I decided to spend some quality time with the phone, i.e. as a user, not a developer, and share my thoughts.

First, a caveat... I plopped in my AT&T SIM card into the N1 before turning it on. That worked just fine -- with some known limitations. By working just fine, I mean that the N1 recognized the SIM card and configured itself for AT&T's APN without me doing anything. This was not the case with the ADP1, which was actually a pain to get working initially. You see, every Android phone that I have used wants you to sign in to Google before doing anything else. This can be a real problem if it cannot use the SIM card to access a data network. Anyways, it was no problem at all for the N1. However, as Google has pointed out, the N1 is not able to access AT&T's 3G network. It does not have the right radio for this. I have no idea why this is the case, but I will say this. Let's just imagine that I loved the N1 so much, that I decided that I wanted it to be my everyday phone instead of my iPhone. Even if that was the case, there is no way I would do this, since I would have to switch service to T-Mobile in order to access a 3G network on the G1, and for me (as well as most iPhone users) that would meaning breaking my contract with AT&T. On the other hand, if Google/HTC had only put the right radio in the N1, so that it could access AT&T's 3G network, then that would not be an issue. I bring all of this up now, because it does make it more difficult to compare the two phones. If you have one phone that is on 3G and another on Edge, you will prefer the 3G one unless the Edge phone is just way better in every other way.

Ok, so the good news is that the N1 is definitely a phone that I could live with. It is fast, I mean really fast. Navigating between applications, applications execution, startup, etc. are all very fast on this phone. I would say it is noticeably faster than my iPhone 3GS. In fact, I did some mini-benchmarking between the eBay Mobile app for the iPhone and our new eBay Mobile app for Android, running on the 3GS and N1 respectively. I put both phones on the same Wi-Fi network for this test. The N1 app was definitely faster than the 3GS app. Now the code is different, as our Android app takes advantage of some the Android features to speed up some common things in the app. Still, the Android app is running in an interpreted environment, the Dalvik VM, not as native code like the iPhone app. So even though it was definitely an apples to oranges comparison, I still found it relevant. Our app on the ADP1 (Android 1.6) was much slower.

The phone is also aesthetically pleasing. It is a pleasure to use. It looks nice. It is incredibly thin. In fact, the iPhone feels very chunky in my hand, after using the N1. Using the phone was very intuitive, but of course I have been using Android phones for over a year now, so I am certainly used to the OS. As a phone, it is on par with the 3GS, which is to say it is ok, nothing to brag about. The soft keyboard is easy to use for me, probably because I am used to using an iPhone. The word suggestions on Android are really nice, and it took me no time to start using them aggressively, thus saving myself a lot of typing.

My favorite part about the phone is the email. We use MS Exchange at work, and I am a long time GMail user for my personal email. With the N1, I could setup both to be in a push mode. On my iPhone, I can only setup one or the other to be in push. So on my iPhone, I have to check my mail to know if I have new GMail, but I immediately know about it on the N1. Also, I think email for both of my accounts looks better on the N1.

However, this brings me to a negative for the N1. It will connect to our MS Exchange server with no problems and can sync both email and contacts from Exchange, but not calendar. I have been told that this should be possible, but all solutions I have seen involved either 3rd party software, or using a workaround like syncing my Exchange calendar to a Google calendar first, and then syncing the Google calendar to the N1. I don't want workarounds, I just want something that works easily, so this is a huge negative for me. When I am at work, I often go from one meeting to another, and it is invaluable for me to be able to look at my phone to know when/where my next meeting is.

Speaking of apps, the Android Market is growing rapidly. The Facebook app for Android is very nice, and its use of the OS to allow you to integrate your friends list with your address book on the N1 is excellent. There are a lot of Twitter apps for the N1, I personally liked Swift. There are a lot of other quality apps out there as well. Here is a handy equivalency table of apps between iPhone/Android from Alex Payne. Still, this is definitely an area where the iPhone has a huge advantage. For me, the advantage is most pronounced for games. There are so many more games on the iPhone, with more well known titles (often backed by big companies like EA.) Also, the games seem to be much higher quality. The number/quality of titles will likely improve over time. Hopefully the quality of the games will too. Perhaps this is an area where the Dalvik VM gets in the way, though you can certainly go native for games, potentially reusing code developed for the iPhone.

A couple of more things, both good and bad... The browser on the N1 is excellent, definitely on par with the iPhone's. That is both from a user perspective and a developer perspective. Having multi-touch in the browser makes a huge difference for users. Adopting HTML 5 standards makes a big difference for developers. I never saw any pages that rendered noticeably differently on the N1 than they did on my 3GS. Usually it was the same only faster. Overall the browser, like most other things, tend to look better on the N1 than the 3GS simply because the screen is so much better... On the downside, the camera was a little more inconsistent for me on the N1. There have been times where I took pictures on it that came out completely out of focus. They certainly did not look out of focus when I took the picture. Maybe this is bad luck. The N1 has a 5MP camera, but I would not say that rates it above the 3GS. Don't get fooled the megapixel myth. I think pictures on both cameras were of similar quality -- except when the N1 would get things out of focus. The flash on the N1 seems useful however.

So there it is. If I lost both of my phones and AT&T cancelled my contract, it would actually be a tough decision between the 3GS and the N1. I would go with the 3GS because of the calendar issue and its big advantage in number of apps/games available for it. The calendar issue seems like an easy issue to address, and the apps/games discrepancy is become less pronounced. It's not like the Android Market needs to have parity with the App Store, at least not in terms of quantity. Also my issues are far from universal. So I could definitely see a lot of people picking the N1 over the 3GS.

The Truth About Europe

Earlier this week I read yet another fascinating post by Peter-Paul Koch. In this post, @ppk takes on developers who think that developing for mobile just means developing for the iPhone. He points out that the iPhone has a small market share, in terms of number of devices being bought or in use. He tackles the obvious counter-argument that the iPhone dominates in terms of mobile Internet usage in the US. In particular he points out that the US does not matter, since Asia and Europe account for a much higher percentage of mobile users worldwide. He is completely right, but if you are a mobile web developer, these facts are completely irrelevant.

It does not matter how many mobile web users there are in North America, Asia, or Europe. This has no bearing on how you design your site or what kind of technologies you choose to adopt. All that matters are the users of your site and what kind of devices they use. There can be 100x more smartphones in Japan than in Spain, but if all of your users are in Spain, then you should not care about Symbian's market share in Japan.

For a lot of sites, it is very easy to figure out where their users are because they are not localized. If your site is focussed on Brazil, then it's a good bet that most of your users are in Brazil. For sites that are international, things get trickier. This is a problem that I have had to deal with at eBay. Fortunately my job was easier because we already had a mobile site that was setup almost ten years ago. It is designed to support all devices, from old school WAP devices all the way up to iPhones and Droids. It has a presence in all of the countries where eBay has a presence. So there I had a lot of data to use where I could say "this % of our users are using iPhones, this % are using Blackberries" etc.

Most people do not have this luxury. If you do not have a specialized site for mobile, you can still look at your server logs and figure out what mobile devices are being used to access your site. However, you should be cautious with this data. If you do not have a specialized site, chances are your main site does not work properly on a lot of devices (especially true if you use a lot of JavaScript.) So chances are your users that use those devices will not use your site from their devices. However, chances are that your site does work properly on an iPhone, even if it is far from optimized for it. So iPhone users may be over-represented in your data.  You might want to fall back to using X% of users are from A, Y% from B, and the devices breakdowns in A and B are... Now if your site relies on Flash...

Let's get back to the @ppk's post and the iPhone for a moment. He makes a nice analogy to IE6 back in the day. When doing analysis on mobile eBay traffic and our strategy for the future, I actually made a similar analogy. There is one huge difference. The iPhone's browser, Mobile Safari, has been a front-runner in adopting HTML 5 standards. If you are optimizing for the iPhone, there is a good chance that you are in fact using HTML 5 standards. In other words, optimizing for the iPhone does not mean adopting a plethora of technologies that are proprietary to Mobile Safari. It's just the opposite in fact. This is the fundamental difference between Mobile Safari today and IE6 circa 2002. That is not to say that there aren't some technologies that are unique to Mobile Safari. There are. However, those are the exception, not the norm. Most of the code that you could write for Mobile Safari that would not work on other mobile browsers is actually standardized APIs that other browsers simply have not yet implemented. So yes, you could be excluding users -- this is where you need to figure out what devices your users are using -- but you are not putting up an iPhone-only wall. You are putting up a wall, but it is a "modern device that supports web standards" wall.

The iPad: A Brave New World

Has any piece of technology ever been more anticipated than the iPad? Has anything created as many extreme reactions? Has anything generated as much immediate ridicule?

Anyways, there are a lot of opinions out there, including some very good ones. I really like Alex Payne's take on the iPad. His post led me to Daniel Tenner's analysis, which is probably the closest thing I have seen to my own opinion. While we are at it, I think Timothy Blee's case against the iPad is definitely worth a read. Adobe's Mike Chambers has a very predictable reaction, but is still worth a read as well. But who cares about those guys, you're reading this because you want my brilliant insights, right?

I think the iPad is Apple's boldest move since the 80's. In the 80's, they liberally borrowed a lot of existing ideas and added some of their own twists to reinvent personal computing. It was no longer the command line driven process. There no need for Unix or DOS. The iPad is equally ambitious. 

Over the last two years, Apple has had a chance to experiment with a new kind of computing. The iPhone is accurately described as very capable personal computer that fits in your pocket. With it, Apple changed the way a user interacted with their computer. There was no more mouse, yet the keyboard was rarely needed. There was very little physical media to interact with, i.e. no floppy disks, CDs, or DVDs, only a very occasional physical linking to a desktop/laptop. Apple gave software developers a much more limited environment than they had ever had to deal with. Compared to desktop computer software, iPhone software is amazingly limited in how it can interact with the system (the iPhone). The distribution model was also controlled in a way rarely seen before. Apple had to approve your applications before they could be sold to users.

Yet even in this most restricted of environments, software developers have flourished. Why? As Joe Hewitt wisely points out, many of these restrictions really are for the best. I can install any app from the App Store, and I don't have to worry about it harming my iPhone. This is in stark contrast to desktop software, particularly the ubiquitous world of Windows. 

But wait, it's worse. At least if you're a software developer. The Draconian distribution machine that is the App Store and its approval process is a key part of this peace of mind given to iPhone users. It also makes their lives much easier. Just go to the App Store, and you can find whatever kind of software that you are looking for. Or just browse the games, or maybe lifestyle or social media apps, and you can find something interesting. Reviews are built right into the system. It could get better, and Apple is working on this with their Genius system, but it beats the heck out of anything else out there. 

The iPad takes this new model of personal computing and packages it into a personal computer. The iPad does not invent a new category. Just like the iPhone, it is going after an existing huge category, only this time it is the desktop/laptop category. Yes, this happens to be a category that Apple already plays in and is having a lot of success in. That is part of why this is so bold. The iPad is not going after the statistically insignificant category known as netbooks. Apple does not aim so low. Instead it is going after every person who owns a laptop.

Perhaps you think I am overstating, that Apple is not as bold as I claim. There were four new apps that Apple unveiled along with the iPad. One of those is iBooks, and I won't bother too much with that. The other three were Pages, Numbers, and Keynote. This is Apple's office suite. These are competitors of Microsoft's Word, Excel, and PowerPoint. Now you can read many Office documents on an iPhone, but it is largely a read-only experience. These are not read programs. These are content creation programs. If you think about the history of Apple, could there be anything more symbolic than them shipping a word processing application with their new computing platform? 

I bought my wife a laptop a couple of years ago. It was essential for her to have Office on it. Word processors and spreadsheets are the meat and potatoes of desktop software. Of course she uses photo management and media management software too. All of these things are available on the iPad. The truth is she could easily replace her laptop with an iPad. It would be easier for her to carry around, have better battery life, and the 3G would work even if she was visiting her mother (who does not have wi-fi.)

Think about all of the people whose job involves a computer. For most people, could they not do their job on an iPad? Wouldn't it even be easier in many cases? Of course it would be more convenient, again because of the size, battery life, and always being connected.

Now there will definitely be some people who cannot use an iPad for their job. I am one of those people. Maybe you could write code on it ok, but compile/debug? Don't think so. Designers who do intense things with Illustrator, Photoshop, etc. will need more than an iPad, too. Ditto for scientists, engineers, etc. There are more groups as well, but it's still probably a minority. For all of those people who have to do a lot of typing? Well there's a dock for that. You get the idea.

Apple is offering a new model for personal computing. They are attempting to disrupt an entire industry, once again. The iPad is not a big iPod Touch or a big iPhone. It is not Apple's attempt to go after Amazon's Kindle. It is an attempt to dominate in a way that even Microsoft never got close to. Apple is going to every person who owns a computer and saying "look there's another, better, easier way." I think it's an all-or-nothing bet. The iPad is either a world changer, or a total failure. Which one will it be? 

Cross Browser Geolocation

You might have heard that Joe Hewitt has given Apple the finger, and is moving on (or more accurately moving back to) mobile web development. You can do a lot on mobile web browsers -- more than you can do on desktop browsers. This can seem counterintuitive at first. However, flavors of WebKit have a huge share of mobile web use, and it supports a lot of features that you can't count on in the IE-dominated world of desktop browsers. One of those coveted features is geolocation. However, geolocation support is far from standardized even among the high end WebKit based browsers.

Geolocation on Mobile Safari is nice, or more accurately it is "standardized." It follows the W3C standard. All you have to do is access the navigator.geolocation object. Here is a super simple example:

var gps = navigator.geolocation;
    if (gps){
        gps.getCurrentPosition(successHandler);
    } 
}

function successHandler(position){
  var lat = position.coords.latitude;
  var long = position.coords.longitude;
  doSomethingUseful(lat, long);
}

Pretty easy, huh? This will work on Mobile Safari running on iPhone OS 3+. As mentioned, it is standard. It will also work on newer versions of Firefox, which presumably includes Mobile Firefox, a.k.a. Fennec. However, that is the limit of the portability of this code. It will not work in Android's browser.
Android's flavor of WebKit, does not support the standard. However, it does support geolocation via Google Gears. That's right, instead of supporting the open standard, it implements the same feature using a proprietary technology. Shocking, I know. So if you are going to run JS that should access geolocation on both the iPhone and one of the zillion Android phones out there, you will need to include the gears_init.js bootstrap file. Then you can re-write the above like this:

function load(){
    var gps = navigator.geolocation;
    if (gps){
        gps.getCurrentPosition(successHandler);
    } else {
        if (window.google && google.gears){
            gps = google.gears.factory.create('beta.geolocation');
            gps.getCurrentPosition(function (position){
               successHandler({coords : position});
            }) ;
        }
    }
}

function successHandler(position){
  var lat = position.coords.latitude;
  var long = position.coords.longitude;
  doSomethingUseful(lat, long);
}

So this is pretty close to the standard, but not quite. The Gears variant also supports the getCurrentPosition API. However, the object that it passes to the success function is different. It is a flatter structure. So in the above example, we wrap it inside another object so that we can reuse the same handler.
I haven't tried the webOS browser, yet or the Nokia WebKit variant yet. Here's hoping they are close to the standard used by Safari.

HTML 5 Features on Mobile Browsers

Earlier today I looked for some help from the smarty folks that I follow on Twitter:

Both @sophistifunk and my colleague @rragan responded that I should look at @ppk's HTML 5 compatibility table and WebKit comparison table. Now these are great resources, and I already had an appreciation for them. However, even put together, they do not, in my opinion, accurately describe the state of mobile web browser capabilities.

Let me take a step back. First it should be said that I hate web standards. Seriously. As someone who has spent much of his adult life developing web applications, I understand why people like standards. Having to write code that is specific for each browser will drive you insane. I don't want to do that anymore than anyone else. However, standards are ex post facto so to speak. It is great to take things and create standards around them, but it is a losing battle to look to standards for innovation. If we had done that, there would be no such thing as Ajax -- or it could only be implemented using hidden IFrames...

With that in mind, I have never given much faith to HTML 5 as a standards lead revolution. This is one of the flaws in the compatibility/comparison tables. Let me give you a couple of examples. The WebKit comparison table shows that neither Android 1.0 or 1.5 supports geolocation (I know, I know, geolocation is a separate specification, but practically it is lumped in with HTML 5). Anybody with an Android phone knows that this is patently false. The Android browser defaults to Google's mobile home page, which uses the geolocation API to echo your location to you -- if you browser supports geolocation. So did @ppk just get this wrong? No, not really. The catch is that the Android browser is not just WebKit, it is also Gears, which implements the HTML 5 geolocation completely. So anybody using an Android phone (and there's going to be a lot of such folks very soon), has a geolocation-enabled browser. But you would not know this from reading the WebKit table.

Another example is app cache. This is specification meant to enable offline applications. Again the WebKit table says that it is not supported in any Android browser. However, this functionality is once again implemented using Gears. In this case, I don't think it follows the specification exactly. Oh well.

Oh, and one last nitpick... The HTML 5 comparison does not even mention database APIs. This is supported by the latest versions of the browsers in the iPhone and Android (and it has been for 1yr+ in both I think.) Yeah I know, @ppk can only run so many tests, and that will probably be listed in the future...

I'm really not trying to diss @ppk and the data provided on quirksmode. It is tricky to assess mobile browser capabilities. That's why I was trying to be lazy in the first place and hope that somebody had done all of the hard work for me!

The End of The Aughties

There are 72 days left in the Aughties, y'know the current decade: 2000 - 2009. I was looking back at the decade, and what are its most important events. Here's my little list:

9/11 -- This is obvious. September 11, 2001 is clearly one of the most pivotal days in the history of the United States. In the previous century, there are probably only a couple of comparable events: the bombing of Pearl Harbor, V-E day, the moon landing, the JFK assassination. For several generations of Americans, 9/11 will be the most historical day of their life.

The Election of Barack Obama -- President Obama's election was historical in so many ways. Obviously it was historic that an African American was elected President. It also marked a transition to a new generation -- Obama is 15 years younger than Bush or Clinton (and let's not even mention McCain.) Obama is not only a Democrat, but is not from the more conservative, Southern Democrats of Clinton and Jimmy Carter.

Social Media -- Here's where maybe my perspective is skewed by living in Silicon Valley. Social media is not a single event, in fact it is a progression of events. To me, it really started with blogging and YouTube, and then exploded with MySpace, Facebook, and Twitter. It is a fundamental change in the Internet. Every user is a creator of content, as well as a consumer. It is the great democratizing effect of the Internet, and it is only getting started. Even now we are starting to see how businesses, celebrities, etc. realize that not only can they use social media as a channel to customers and fans, but that it is a two-way channel.

Hurricane Katrina -- What made Hurricane Katrina so pivotal is that opened the eyes of Americans. It made people realize that many of their fellow Americans live in awful conditions. The divide between socioeconomic classes in America were never so obvious as during Katrina. When Kanye West went on TV and said that George Bush didn't care about black people, he wasn't just being a jackass, he was stating a sentiment shared by a lot of people.

The iPhone -- What did I say earlier about having a Silicon Valley perspective? Anyways... The iPhone has completely changed so many things for so many people. In the 90's, The Internet changed people's lives by bringing them information. Now the iPhone lets them carry it around in their pocket. Other phones were certainly moving in that direction, but the iPhone broke through by combining a large display with highly usable touch based interface. This revolution continued with the release of the App Store. Now don't get me wrong. A lot of other phones are following suit -- but that's exactly why the iPhone was so historical.

That's my short list. I know it's obviously biased from me being American and living in Silicon Valley. What did I miss? What doesn't belong?

The Strange Loop

In October, I am speaking at the inaugural Strange Loop conference in St. Louis. This is not your run of the mill conference. It is organized by Alex Miller, who you might have seen speak the last couple of years at JavaOne. The speaker list is sweet: Alex Payne and Bob Lee are doing the keynotes, with sessions by Charles Nutter, Dean Wampler, Stefan Schmidt, Guillaume Laforge, Jeff Brown, and Alex Buckley. I am doing a talk on iPhone/Android development. It will probably be pretty boring compared to the other sessions. I may try to spice it up with some shameless plugging of Scala+Android balanced by some Fake Steve Jobs quotes about Android.

Hacking My iPhone 3GS

If you are a long time reader of this blog ... nevermind there are no long time readers of this blog. Anyways as it turns out, two of my most popular blog posts of all time have been about hacking my phone. First there was Hacking my A950. That was about enabling MP3 playback and Bluetooth dial-up-networking on my Samsung A950. A year later came Hacking my 8830. This was mostly about useful tips for the Blackberry, along with a failed attempt to get GPS working (thanks for nothing Verizon.)

Two weeks ago I deactivated my Blackberry after two years of excellent service, and bought the new iPhone 3GS. I have been working on iPhone apps (one app in particular) so this made sense. Oh and the iPhone is the best phone ever. The Exchange support is so good on it that it is an easy move for a Blackberry user, but I digress. Back to the point. As a rite of passage, it was time for me to write about hacking the iPhone.

There are two things that I will point you would-be hackers to. First up is ringtones. Just like with the Blackberry, there is no need to spend any money on ringtones for the iPhone. There are a few ways to create ringtones on the iPhone. This is the guide that got me going. If you don't want to read it (you should) the idea is simple. A ringtone for the iPhone is an AAC encoded, .m4r file. So clip a song down to less 40 seconds, convert it to AAC, and rename the file from .m4a to .m4r. It is a painless process. I created a half dozen or so ringtones in a few minutes, mostly Girl Talk songs...

The other tip is also pretty well known. The iPhone OS 3. 0 has support for tethering and MMS, but neither is currently supported by AT&T. However you can hack this at the software level, and pwn AT&T. Here is the best guide I have found for this. What is great is that it only involves going to a web page in Mobile Safari, and it is easy to undo. For me it works great for tethering, but MMS did not get enabled.