I've spent a fair few words on this blog discussing my perception of the Android SDK. To sum it all up simply, my overall opinion is that programming for the Android SDK is good, but nowhere near as good, nor as fun, as programming for iPhone SDK. Although Android has some places where it shines, there are relatively few where it outshines the iPhone SDK.
There is one, however. One where the experience is worlds better in the Android camp: ad hoc distribution.
When you do contract programming, ad hoc distribution is a big part of your life. A lot of people who hire others to write software aren't programmers themselves, so we have to have a way to get the applications we develop to our client for their review and for testing. On the iPhone, we have to go through this relatively convoluted process where we create an ad hoc distribution certificate then create an ad hoc provisioning profile that ties the application to certain, specific devices based on a unique identifier called a UDID. The client then has to install the provisioning profile on their phone, and then install the app.
When it works, it's not too terrible. It's a bit of a pain in the ass, but it's not too awfully time-consuming.
The problem is when it doesn't work. When a client reports that an app won't install, trying to remotely figure out why can be really tedious and time-consuming and the process creates a negative impression of the platform in the eyes of the client. And there are many reasons it can go wrong, and it does go wrong way too often in my experience. If the application bundle gets changed in any way, code signing fails and the app won't launch. If the provisioning profile doesn't get installed properly, installation of the app fails. Often, when the problem is finally fixed, we have no idea what we did that fixed it.
And we developers are left holding the bag. We're left spending hours and sometimes even days trying to get the app working on the client's device. Usually, that time we spend figuring out what the hell is going on is unbillable. When a client isn't a programmer, especially when a client isn't particularly tech-savvy, the whole process can be extraordinarily painful and frustrating both for us and for our clients. On top of that, we're limited to 100 devices that we can even do this process with. With several models of iPhone and iPod Touch, plus the iPad and the fact that most developers have multiple clients in the course of a year, we have the added hassle of having to manage our devices so we don't exceed our limit.
On Android? I drop the compiled app into my Dropbox folder and e-mail the client the URL to it. I instruct them to tap the link from their phone. That's it. It just works. No hassles, no worries. There's a one-time instruction I have to give them that involves tapping a checkbox in their phone's settings to allow third-party apps, but after that, it's just the URL. The user still has control of whether it gets installed, so it's relatively safe, but there's no provisioning profile, no iTunes requirement, no worries about the application getting corrupted or accidentally changed in transit. No angry customer calls or e-mails.
In most ways, I wish Android was more like the iPhone. In this way, I really, really wish the iPhone was more like Android. This whole process lacks the polish and ease of use that I ordinarily associate with Apple products, and after two years of developer complaints, it has improved a bit, but not nearly enough.
There is one, however. One where the experience is worlds better in the Android camp: ad hoc distribution.
When you do contract programming, ad hoc distribution is a big part of your life. A lot of people who hire others to write software aren't programmers themselves, so we have to have a way to get the applications we develop to our client for their review and for testing. On the iPhone, we have to go through this relatively convoluted process where we create an ad hoc distribution certificate then create an ad hoc provisioning profile that ties the application to certain, specific devices based on a unique identifier called a UDID. The client then has to install the provisioning profile on their phone, and then install the app.
When it works, it's not too terrible. It's a bit of a pain in the ass, but it's not too awfully time-consuming.
The problem is when it doesn't work. When a client reports that an app won't install, trying to remotely figure out why can be really tedious and time-consuming and the process creates a negative impression of the platform in the eyes of the client. And there are many reasons it can go wrong, and it does go wrong way too often in my experience. If the application bundle gets changed in any way, code signing fails and the app won't launch. If the provisioning profile doesn't get installed properly, installation of the app fails. Often, when the problem is finally fixed, we have no idea what we did that fixed it.
And we developers are left holding the bag. We're left spending hours and sometimes even days trying to get the app working on the client's device. Usually, that time we spend figuring out what the hell is going on is unbillable. When a client isn't a programmer, especially when a client isn't particularly tech-savvy, the whole process can be extraordinarily painful and frustrating both for us and for our clients. On top of that, we're limited to 100 devices that we can even do this process with. With several models of iPhone and iPod Touch, plus the iPad and the fact that most developers have multiple clients in the course of a year, we have the added hassle of having to manage our devices so we don't exceed our limit.
On Android? I drop the compiled app into my Dropbox folder and e-mail the client the URL to it. I instruct them to tap the link from their phone. That's it. It just works. No hassles, no worries. There's a one-time instruction I have to give them that involves tapping a checkbox in their phone's settings to allow third-party apps, but after that, it's just the URL. The user still has control of whether it gets installed, so it's relatively safe, but there's no provisioning profile, no iTunes requirement, no worries about the application getting corrupted or accidentally changed in transit. No angry customer calls or e-mails.
In most ways, I wish Android was more like the iPhone. In this way, I really, really wish the iPhone was more like Android. This whole process lacks the polish and ease of use that I ordinarily associate with Apple products, and after two years of developer complaints, it has improved a bit, but not nearly enough.
0 comments:
Post a Comment