Nice! The man who invented whatever Adam Curry invented likes flook:
Best to worst:
1. Ms Super Keen. Uses the application every day, upgrades immediately every time there’s a new release, files masses of detailed bug reports, makes tons of sensible suggestions on product features. If you have one of these, thank her warmly and send her the biggest box of chocolates you can afford.
2. Mr Thorough. Uses the application every few days, upgrades pretty quickly when there’s a new release, files bug reports, makes a suggestion or three on product features. If you have one of these, shake him by the hand and thank him warmly.
3. Mrs Harsh-but-true. Refuses to be a beta tester, saying “Sorry, I don’t have time to spare right now.” Surprisingly, these are worth their weight in gold*.
4. Miss. Dabbler. Uses the application every couple of weeks, upgrades once when your email coincides with a dull Friday afternoon at the office, files a bug report or two. Don’t ask her to beta test your next product.
5. Mr. No-bloody-use. Runs the app once or twice, then never uses it again. Doesn’t file a single bug report, doesn’t suggest a single product feature. When asked what he thinks of your app, says it’s fine and then goes off on a tangent about something else entirely. Avoid, preferably with the help of a bargepole.
*Yeah, it’s better to refuse to help than to say you will help and then fail to do so. We poor iPhone developers just get 100 seats in our beta tests per year, and we can’t turf out someone useless to add in someone better. Apple madness, yes, but we’re stuck with it. So when someone next asks you to be on their iPhone beta, please think hard about whether you have the time to help.
It’s been great coming back to coding after several years in the management and marketing purdah. After a year of coding and now, shipping flook to the App Store, I’ve been doing some thinking about how much has changed for developers both in the devices we’re targeting and the tools available. This was heightened by Apple’s TechTalk London yesterday.
My last programming job was on the Psion Series 5 – the last real British computer. It was the first device to run Symbian OS (or EPOC 32 as it was called then). I ran the team who wrote all the comms software and implemented the sockets, comms and device driver frameworks myself. There is some chance that your shiny new Symbian phone still includes a few bytes of my code. The specs for the Series 5 were:
- ARM710T with MMU @18 – 36 MHz
- 4 – 16 MB (RAM)
- 640 x 240 4-bit greyscale LCD
Compare that to the iPhone I have on my desk:
- ARM1176JZ @412 MHz
- 128 MB RAM and 8GB Flash
- 320 × 480 18-bit color LCD
That is an order of magnitude more memory and possibly two orders of magnitude more processor  but only twice as much display to service. If you look at the high level specs for the machines they’re similar – or actually iPhone looks to have gone backwards – the series 5 suported full multitasking and background apps.
The iPhone isn’t exactly snappy either. My phone still goes dead occasionally, flook still has to be careful about allocating memory and I still have to spend hours optimizing to get good performance at the UI. It doesn’t feel right when the phone I’m now developing for is about as powerful as the NT machine I was compiling on for the Series 5.
The answer is that the iPhone is doing a couple of things that the Series 5 could never do and other phones are only just starting to do. One I see benefit from as the user: the user interface on an iPhone makes heavy use of transparency and animation. Transparency means that everything I draw on screen is actually drawn off screen and then composited onto the screen buffer. Those glassy see-through dialogs are drawn in memory and then blended with the view they’re drawn over… in real time… 30 times per second. Each pixel needs calculating by combining my see-through dialog colour and the colour of the pixel it is shown over. Even with the 3D hardware helping that’s an overhead.
The second thing isn’t that obvious to me as a user. It really only shows in the fact that there are a gazillion apps in the app store. Developing for iPhone is easy. It’s perhaps too easy. I can write some apps without writing any code at all. It won’t be a good app but I can do it. With a little effort, I can write an OK app – with (more or less) one line of code, I can include a fully interactive Google Map. With another line of code I can bring up an eMail editor, another and I am playing back stereo sound. I can access Core Data just like on a desktop and when I need to manage my own data I can call on one of any number of collection classes.
When I’m building, testing and debugging my app, I have amazing  tools at my disposal. Xcode itself is stupendous compared to the mish-mash of Microsoft and command line tools we used at Psion. Interface builder is something other phone platforms can only dream of. Add Shark, Instruments and some of their smaller cousins Guard Malloc and NSZombies to this and developing for phones has never been so easy.
Or maybe seemed so easy. Making a simple app is easy. Making a large or complicated app still needs skill. The problem is that all of these frameworks are very generic – they do a lot of stuff for you and as such, they are difficult to optimise. Apple do a great job but it is not unusual to get a crash in your app and see a stack trace 40 or more frames deep. That’s a deep deep stack for a phone. All those collection classes and clever string classes make for quick development but they are slower and more memory hungry than really understanding and managing your own memory. The frameworks themselves consume a lot of memory.
The tools are great but you need them to understand the complexity that is present on the phone. on EPOC 32 we could debug nearly all memory problems by snapshotting allocations on entry to a function and checking memory was the same (alloc heaven for those who remember) at a known point later. On iPhone, it is nearly impossible to do this (although we have built a prototype tool to do this) because the frameworks are more complex.
When all is said and done, its easy to build an OK app for the iPhone. Some people have done so in a day. When you want to go beyond that, developing for phones is still exactly as it was 15 years ago. You have to care about memory, you have to care about processor and you have to care about battery.
Apple seemed to agree with that. Although I got a lot of useful information at the TechTalk I felt that even the scary “deep dive” sessions weren’t that technically challenging. The strong message of the day seemed to be summed up in the opening keynote and echoed in the closing talk: polish your app, attention to detail in all areas counts, you still need to optimise for memory, bettery and CPU.
It feels like Apple are again ahead of the curve here – whilst the rest of the platform vendors are setting up their app stores and recruiting developers Apple realise they have have fixed one problem (lure developers to iPhone) only to unearth a bigger one (educate all those developers not to flood the App Store with crap).
 I’m actually too lazy to check this but it sounds believable. The iPhone also has a PowerVR MBX lite.
 it’s an British English word for awesome.
TechCrunch are reporting on a great new idea – pushing ads to people as they walk past Starbucks. Awesome! Dude! Great idea! I wonder why nobody thought of it before… Well, I don’t wonder, I can only assume that there are new people entering the mobile industry who haven’t been around long enough (or are too stupid) to remember what a very bad idea this was when Nokia first suggested it 10 years ago.
Ad men and marketeers have always wet themselves about pushing ads to the phone. What simplistic thinking like this fails to acknowledge is that the same attributes that make your phone so attractive to advertisers – it’s personal, it’s always with you, it makes beeping noises – are the same reasons why you don’t want ads pushed to it. And, if you do, you certainly don’t want those ads delivered as unsolicited SMSes from people I don’t know.
Quoting OSStatic on Android:
In Google’s recent earnings call, CEO Eric Schmidt said “Android adoption is about to explode,” adding that all conditions for that event have been met. There are 12 Android phones available now, and there will be close to 20 by year’s end, including the highly publicized new Droid phone, It will run Android 2.0, and is a result of a three-way partnership between Google, Verizon and Motorola.
I’ll just replace a few words:
In a press release yesterday (21st October 2000) Symbian said “Symbian OS adoption is about to explode,” adding that all conditions for that event have been met. There are 12 Symbian OS phones available now, and there will be close to 20 by year’s end, including the highly publicized new Symbian phone It will run Symbian OS R5, and is a result of a three-way partnership between Symbian, DoCoMo and Sony.
…don’t get me wrong, I would love to see Android be a success. Android success means means more platforms for flook and it means pressure on Apple to fix some of the glaring holes in UIKit and OS X for iPhone. I also like shiny new toys and, lovely as it is, iPhone is a little uniform.
It feels to me like this success is not to happen though. Or, more accurately if it does it will only be a success for Google – they will be able to point to a huge number of Android phones – perhaps even as many as Symbian did. The handset manufacturers will have their BoM reduced slightly . For the wider ecosystem – and specifically for mobile application developers – I see little to be happy about.
Mobile Entertainment picked up on the demo on Monday and wrote this rather nice piece on us. Thanks Stuart.
He even had his muppet hair and beard trimmed specially for the event.
So we’ve been heads down for a few months finishing flook. Sorry that like every other blog on the planet, this one went stale. We’re eternally sorry. Well, quite sorry. OK so really, this blog is a bit of a ginger haired unwanted child and we’ve been spending time with the pretty blonde one who plays in the school orchestra. Anyway… we’re coming up for air ever so slightly and starting to talk a bit more about flook. Actually, quite a lot – young Tristan went to MoMoLo yesterday and demoed flook to the lovely burghers of London Town. Seems like people liked it and at least one of them has a blog.
If you’re planning a birthday part or bar mitzvah, give us a call and Tris will come round to entertain your guests with his demo skillz.