Smart people like John Gruber of Daring Fireball seem to believe that Android development takes 3x as many developers as iOS. He believes it so strongly he mentions it again in another post about analysts who try to fit facts into a narrative.
Unlike John, we actually do Android development full time, and we have for many years. We’ve made big apps, we’ve made small apps. Sorry to disappoint you John, but a talented Android developer works at roughly the same speed as a talented iOS one. They make the same apps, of the same complexity, in the same amount of time. Sure there are differences in platforms and API. Some things are quicker to do on iOS, others on Android. Long story short, there’s not a lot of difference when it comes to development time.
Like the very analysts he mocks, Gruber is trying to fit a story to his pre-existing narrative. Does the BBC story offer a reason as to why the team is 3x bigger? Nope. Does it suggest any sort of causality? None. It’s a casually mentioned fact about an app which is currently being developed. It could be that the team is bigger because the app is playing catch up to the iOS one that came out first. It could be bigger because some of the iOS team is helping out. It could be bigger because the BBC is using developers who are less familiar with Android. It could be that the iOS team used to be the same size or bigger, but was ramped down after the first version of the app was completed. Which one is it? I have no idea, I don’t infer facts from stories that don’t explicitly state them. Justin Williams (an iOS developer by trade) speculates along the same lines. Your mileage may vary, but unlike most other people I speak from years of experience in actually developing on these platforms.
John is certainly not the only one doing this, people write articles like this almost every day on both sides of the fence. It’s just disappointing that these kind of myths are perpetuated in the echo chamber that the tech press occasionally becomes.
Update: Johns response is quite well done, and his research shows that indeed, the BBC iPlayer team is having a lot more issues on Android than iOS. He also links to a PBS Article where they’re having the same issues. Then states:
Maybe the problems the BBC faces are specific to the domain of streaming video.
Maybe? I’d say most likely since that’s all they talk about in the other articles John has now linked to. I realise however, that I should have provided examples of where Android development was faster, or the same as iOS. So here goes:
Skala View development on Android was easily 10x faster than the iOS version. The main reason? Networking is far easier on Android, as are most of the other tasks that Skala View needed to perform. The iOS version was also there for us to work from. To quote Marc Edwards of Bjango:
Backing up @shiftyjelly’s claim re Skala View. Android was way faster and has some additional abilities.
My Physio, a client app we developed was also done in a shorter amount of time than the iOS one. Again because the iOS version was already completed so a lot of the hard work had already been done. I’d say if they were done in parallel they would have been finished in parallel.
Pocket Casts on Android was easier to develop than the iOS counterpart, though the testing and support costs are higher. It’s no small project either, taking 6 months to complete the version 4 update.
Likewise our other apps like Pocket Weather take about the same amount of time to develop for Android as with iOS.
At this point I could scour the Internet for more examples like this one where the author explains how both platforms took him equal amount of times to develop for, and which aspects of each he prefers. That’s not my intention though, it was merely to point out that Android and iOS development in general, take about the same amount of time. In some cases is Android development harder? Of course. In some cases is it easier? Yes. I’m not here to champion Android and claim it’s not fragmented, because it is. I’m not here to tell you that it’s somehow superior to iOS, the truth is that it’s a lot more nuanced than that.
Up until recently we’ve had a todo list much longer than any human arms I’ve ever seen. Every week would see us complete one item only to add two more. Todo lists you see, often follow a very accelerated version of Moore’s Law. But we’ve got a secret weapon now: the time to do things (having gone out on our own almost a month ago) and the motivation to (in a very small way) set the world on fire.
So today we’d like to show off something that’s been on our todo list since we first released Pocket Weather AU HD for the iPad. Version 1.2 to be precise.
Yes indeedy, you can get your tides, state warnings, detailed forecasts, icons in landscape view and so much more in this new version.
At this point we’re providing an intermission for those who don’t care how this stuff is built. Don’t feel bad, the lights are on, we’ll clean up all the popcorn you’ve managed to spill everywhere. Last chance!
Now let’s talk about just why this release took so long. We promised that when we went into this full time we’d no longer accept compromise, and we meant it. This version was ‘ready to go to Apple’ 3 weeks ago. In the past it would have been myself, at 1am on my couch looking at things and going ‘close enough’ and pressing the submit to iTunes button. When you’re tired anything that’s working starts to look good. Since then we’ve rewritten the warnings feature twice, the tides three times and played with two different ways of showing you detailed forecasts.
After each re-write I’d hand the iPad over to Phil and ask him for feedback. Phil was brutal about everything he didn’t like, which initially made me very defensive, but I’d go and do it because I knew he was right. It was jarring, I wasn’t used to reworking features that worked, and were bug free, with the sole justification being ‘we can do better’. It was also hard to break out of the “we don’t have time for that” mould from our former lives as out of hours developers. After each iteration though we both knew we’d created a better product. Things you’ll never see like that the initial tides screen having left and right buttons (instead of swipe). Then there was the original detailed forecast design that had the day panels sliding left and right to show more or less content. Don’t even get us started the original warnings screen which had resizable panels of all things. In some cases we re-wrote it because we knew we’d taken shortcuts, other times (like with the slidey detailed forecast panels) we realised we’d gone too far the other way and made something a lot fancier and less intuitive than it could have been. In the end we finally had a version that Phil & I approved of, and one which was much better for the process we’d gone through.
There’s three obvious lessons from all of the above:
- Getting things right often means getting things wrong, but being willing to change them.
- When people look at a final product and estimate the effort required, they’ve left out the biggest component, all the rework and tweaking that led to that final version (common example from stack overflow).
- Pocket Weather AU HD is awesome…have you bought it yet?!
There are times in everyones lives, where you stand at a fork in the road, looking at two differing directions, and having to choose one. ShiftyJelly found itself at just such a point a month or so ago. We have been in the App Store now for two years, working on our apps in our ‘spare time’ while all working full time jobs. The problem is that we don’t really have spare time, that’s just a euphemism for time that we really want to be spending with our families, friends and having fun. Sure we’ve had fun doing this, but it was really starting to wear us down. The last few releases of our products have contained some fairly obvious bugs and it was getting harder and harder to maintain the motivation to open the laptop at 11pm at night and start coding. We are insanely passionate about quality, so this was really starting to get to us.
Introduction aside, we stood at a fork. In one direction was either selling or shutting down ShiftyJelly, in the other was resigning from our full time jobs and taking the leap into doing this full time. In truth there was only one option, but it was not an easy one. To those of you who think we sold out or were going to shut down, shame on you! We resigned our jobs, and it’s full steam ahead!
So what does this mean? Initially it means that we’ll be busy looking for office space, sorting out legal documents, registering various bits and pieces, so we’ll be distracted for a little while. Once the transition period is over though, it means that ShiftyJelly is about to bring it’s A game. No more late night rushed releases, no more cutting corners, just pure unadulterated awesomeness. If you’re one of our competitors, consider yourself on notice. If you’re one of the many companies we turned project work down for, we will now consider it. Best of all, if you’re one of the people that has purchased one of our applications, or supported us, we’re finally going to be able to devote 100% of our time and energy into making products that blow your mind. We’ll also be updating all of our existing products to finally make them what we’ve always wanted them to be, not just what we had time for them to be.
We’ll be keeping you up to date over the next few weeks as we make the transition, but for now we leave you with this teaser image. Who could that be in the shadows…
We’ve had a lot of email recently. Probably because some genius thought it would be a good idea to start putting email us buttons into all of our applications. While it has increased our workload a bit, we’d prefer that to people just getting frustrated, deleting our application then telling all their friends how bad it is. The emails vary from ones that are quite funny to ones that are quite angry. I’d estimate that 9 times out of 10 the answer is very simple, and people normally walk away (assuming that’s what you do after reading an email) very happy. It’s funny, sometimes it almost seems that people are happier to get a buggy application that you then fix (after they find the bug) than to receive a perfect, bug free application. In quite possibly the longest segue in ever, that’s what I want to talk about: Quality, Features and how shiftyjelly applications are made. Possibly unicorns and rainbows too, I haven’t decided.
Most people assume that we’re some large-ish corporation, which I’d like to put down to the amazing quality of our applications, and the fact that ‘shiftyjelly’ is a very serious business like company name. I can see the latest IBM board meeting: “Who did we outsource all our IT work this year Bob?”. “Why shiftyjelly Frank, who else? Dependable chaps the lot of them.”. In truth a typical day in the life of a shiftyjelly goes something like this (there are 3-4 of us btw, depending on who’s counting and how, you can read more about that here):
- Wake up
- Eat breakfast
- Go to our full time jobs (which have nothing to do with shiftjelly)
- Come home
- Eat dinner
- Be social
- Put the kids/wife/dogs to bed
- Decide whether to code like a mad monkey or just crash into bed
There’s a point here right? If you’re still reading my guess is that’s what you’re wondering. Well the point is this: we’re just 3-4 part timers working in the wee hours from our couches. It might sound more glamorous if I told you my couch is leather, but really, sometimes it’s just hard work. We make a little money, ’tis true. When split 3-4 ways it’s not a lot though, which you can probably guess by the fact that we still all work full time elsewhere. But we don’t do this for the money. If we did we would have been much better off working the graveyard shift at a service station (gas station for the Americans out there). It would pay more, and I hear the employee discounts are really awesome. No we do this because we love it. Not always, not every day, but we really do love it. Some days we hate it, we chase down excruciating painful bugs for hours on end, sometimes in circles. Some nights you end up giving up and just reverting all the changes you made (thank goodness for source control). But most times it just seems cool. We’re making applications that people use every day. Roofers, tradies, fishermen, office workers, cyclists…even grandma. We’re also motivated by our competitors, perhaps because we’re all alpha males, but every time one of them creeps above us in the charts the coding nights become more frantic, the features get more elaborate, the whole virtual office (we’re separated by many kilometres) hums. All this just for the pure fact that we refuse to be beaten.
So on to the point (yes I know I promised it paragraphs ago): we love you guys, we really do. We love hearing from you. It pains us that we cannot add features faster than we do, but we’re trying. Some days we feel like we’re working 2 jobs. So yes we’re upgrading all our apps to support that fancy new iPhone 4 display, yes we’ll keep adding features to our new iPad versions, yes we’ll never forget about the old iPhone apps, yes we’ll fix all those little annoying bugs that slip through our 2am testing…but it will take time. And until someone comes along and hands us a million dollars (I know, we’re cheap, right?) we’ll probably stay at our day jobs, and it will always take time.
In our journeys across the vast interwebz, we often discover little pockets of awesomeness that are almost too good to be true. This time around it’s two native iPhone applications that every developer out there should take a look at. Both of them are open source and all you need is the iPhone SDK and a valid certificate to be able to install them onto your iPhone:
App Sales Mobile is a very cool little app for the stats nuts out there (we’re looking at you Graham Dawson) who just can’t get enough of various stats to do with their applications. It basically scrapes the iTunes Connect site and presents things in a very clean and easy to read fashion (graphs, percentages & pie charts oh my!). Check it out, and donate if you like it!
Review Scraper was built to sell on the iTunes Store, but when the developer got rejected he open sourced it instead. It basically lets you choose any application in the store (even if it’s not yours) and see all the reviews for it worldwide. It’s killer feature is that it hooks into Google Translate, as the screenshot below shows. Again be sure to check it out, and donate if you like it.