Many words have been written on the Apples new iPad, but still there seem to be a few stones yet waiting to be turned. You can find a lot of disappointed voices already, but to be honest, there is possibly no way to satisfy anyone with this level of expectations. And while some might have a point, they still miss the bigger picture. I will reserve my verdict until I hold one in my hands, as this will change a LOT. Political things aside (Why, Apple, do you have to lock it down again?) I think what we have seen in hard and software rocks. But still, I have a suspicion, that whe have only been shown the very tip of a much deeper iceberg, both in software and, surprisingly, in hardware. But let me explain what I mean:
The Software – A Beta that isn’t
The iPhone OS in the iPad SDK is Version 3.2. It’s iPad only, the iPhone/iPod Version will come later. It is very weird that there is not a device version of it for the iPhone, so I think it is just a preliminary version that won’t be released. What will be released is Version 4.0.
The version that has been released, is more like an iPhone-to-iPad transition kit than anything else. It seems to work quite nicely for that and introduces a lot of new toys for developers to play with – but hardly does more than the bare minimum to provide the tools to create decent large-screen-multitouch UIs. Without being able to go into details here (NDA!), some key elements of the SDK, such as a decent alternative to tables (A Grid! A Grid!) are still nowhere to be found (and yet used a lot by Apple’s apps).
There are two reasons to hold back Version 4.0: One is that it is probably not yet ready. Apple accomplishes amazing things while holding secrecy, but a project like this can scale up far better, when the cat is out of the bag. But releasing 4.0 without having shown the next iPhone which will run it, too, will spoil their much-beloved game, so they create an in-between version for aspiring iPad developers to get their feets wet, until the rest is ready and all devices it runs on have been shown to the public.
The other reason is a financial one: Apple was not handing out free updates for the iPod touch, but for iPhone and AppleTV, since they do the accounting for the latter devices on a subscription based model. You can’t add features with a free upgrade otherwise, if I understood things correctly. This is also why the upgrade to 802.11n networking cost $2 for the first MacBooks. Now they changed their accounting standards. If I’m correct the distinction between the two ways to account for a device sale is gone, and they retroactively accounted $25 for an iPhone update and $10 for an AppleTV. In the future (and please correct me if I’m wrong here, I don’t speak accounting…) they have a unified upgrade strategy with either no carge for upgrades for all devices or charging for all devices. So – and here is finally my second point – if they charge for the update, they won’t release 3.2 and then after a very short time let their customers pay for 4.0. They will release it with 4.0.
Hiding Three Cores
Ever wondered why Apple calls their chip A4? Well, A is for Apple, and 4 is for the four cores this thing has. Wikipedia says the chip is based on the ARM Cortex-A9 Multicore Design which is capable of having 4 cores, and with Apples naming, and PA Semi (The company that has been bought by Apple for the chip design) being famous for their multicore-chips, it is highly unlikely that there is anything else than 4 cores inside. So, why do they hide the other three cores? That’s an interesting question, and I think the answer might also be that the software is not yet ready. Or they will overwhelm the public with a second moment of surprise, when they reveal Apps that actually use the available power. Underpromise and overdeliver is something that works brilliantly with the press, and also the stock market.
That brings us to another interesting question: Where is Grand Central Dispatch in the iPhone OS? This technology, together with Blocks give developers an easy way to actually parallelize their programs, so that the power of multiple cores can actually be leveraged. If the A4 is actually what I suspect, I would be surprised if this technology wouldn’t make its way onto the iPad very soon.
As is OpenCL, the General-Purpose computing framework that runs on the graphics card. Yeah, the A4 also seems capable of supporting this, since the “graphics card” is part of the chip and seems to be the PowerVR VXD from Imagination Technologies. By the way, it can do OpenGL 3.2, too. Yeah, the real OpenGL, without the “ES”. That opens a LOT of doors to game developers, if this is true. It’s going to be very interesting to see developers unleash all this hardware potential, once Apple provides some means of using it in an upcoming version of the SDK.
Whoever complains about the device now (and for non-political reasons), is probably way too early. I can’t wait to touch it for myself, and to see what new and unexpected uses developers create with the current version of the SDK. But still Apple hasn’t played all their cards yet – the big tablet revelation is far from over.
I know I update this blog way to seldom. One of the reasons is – of course – work. And I am proud that I can now announce my first “serious” open source project, that Ullrich and me did for SoundCloud. It’s an API wrapper for SoundCloud that works on both the Mac and the iPhone, that handles oAuth as transparently as possible and can upload huge files that exceed the size of the iPhone’s memory. It supplies your app with progress information while doing so, and generally makes asynchronous REST-Requests really easy. We’re quite proud of it and can’t wait to see what you do with it :-) Here’s more Info…
Die drittbeste Erfindung bei “Zurück in die Zukunft”, nach dem Hoverboard und der Zeitmaschine, ist die Uhr, auf die Michael J. Fox schaut und mit den Worten “gleich kommt der “Fünf-Uhr-Zwölf-Regen”* kommentiert. Sekunden später regnet es.
Gut, wir haben noch keine Hoverboards, Zeitmaschinen gibts nur für Festplatten, und auch der Essens-Hydralisierer, der in Sekunden aus Minipizzen richtige Pizzen macht, steht noch aus. Aber wir haben iPhones.
Was dem Regenvorhersager as dem Film am allernächsten kommt, sind Regenradare. Wenn man die Radarbilder animiert, kann man sehr gut einschätzen, wann es wo regnen wird. Und WetterOnline hat ein besonders schönes, weil man die Regengebiete schön scharf erkennen kann.
Das Problem ist nur, dass deren Website für das iPhone ungeeignet ist: Apples Telefon animiert GIF-Bilder nur, wenn die besonders klein sind, hier kommt also leider nur das Radarbild auf der Startseite in Frage. Und auf der ist so viel drauf, dass der mobile Browser aus Speichergründen gerne mal aufhört zu animieren.
Ich habe daher dieses Bild von WetterOnlines Startseite einzeln und vergrößert auf eine eigene Seite gestellt, und dem ganzen ein eigenes Icon verpasst, dass verwendet wird, wenn man auf “Zum Home-Bildschirm” klickt. Das ganze findet man unter
So, jetzt muss ich aber weiter am Hoverboard rumschrauben. Viel Spaß!
*) Der genaue Wortlaut mag anders sein. Aber: “You get the idea”…
I announced it months ago and then it rested for far too long on my Todo-List: Today I uploaded the Source of Readomatic to Google Code. It’s shiny new address is:
I updated the stylesheet to Jon Hicks’ gReader 1.3 and cleaned out almost all the debug code. All development will from now on take place at the new Google Code site. New releases will continue to be announced on this blog, too. Have fun!
iChat can do ICQ, but a bug that never got fixed made that feature unuseable.
I complained about it, hoping that it gets fixed. But waiting for a bugfix and telling every contact to switch messengers in the meantime is one thing, actually writing something that fixes the bug is another thing. So I did that ;-)
I wrote a simple InputManager and got a lot of inspiration from Chax on how to do it. Some parts of my code are based on Keith Sutherlands work.
But Inputmanagers are potentially a bad thing. This one is so simple, it should do no harm. But Apple changed some rules concerning Inputmanagers so make sure the following conditions are met:
- The folder “IChatICQFix” is in /Library/InputManagers
- This InputManagers Directory and everything in it is owned by user root and group admin (recursively!)
- Nothing in the directory is writeable.
- There is no ~/Library/InputManagers Directory or any other InputManager leftovers from Tiger. They don’t work anyway.
Some notes on this:
- If you don’t know what I’m talking about, don’t do it.
- I don’t provide any support for this. Take it as it is.
- If you want to write an installer, go on and do so. Send it to me and I will publish it here.
- If you have improvements, do the same
Here comes the first article pointing out why Leopard is a milestone besides the impressive list of 300 Features (of which some are lame and duplicates, but most are really nice to have).
It’s the developer’s frameworks that will make all the difference. Leopards frameworks are in most part really beautifully designed and easy to use once you get your head around the mountain of basic stuff. We will see a lot of developers switch to “Leopard only” immediately, not because Apple forces them to do so, or because being a 10.4 developer is a bad experience, but because the new release is a big leap forward. We will see a lot of articles about this when the info about the stuff in 10.5 is no longer under NDA on 10/26. If enough people are interested I will do a session about the stuff in Leopard that users don’t normally see on Barcamp Berlin 2 on the first weekend of November.
Steve finally announced that we can develop Cocoa applications on the iPhone from February. Apple needs this time to get the iPhone secure. Well, I suspect the real reason ist that they need to get their API stable – there have been several changes to UIKit from Version 1.0.x to 1.1.1. But aside from that: How can they make the iPhone more secure? By leveraging technologies from Leopard that they announced just yesterday and that one can read about in the security features of Leopard, of which the Phone runs some kind of variant:
- Signed Applications: The Developer signs his Apps. If there is a new App, with an unknown certificate, the phone asks the user for permission to run it. Apple signed Applications can run by default.
- Sandboxing: The App can only access what it needs to access. That prevents at least some viruses.
- Library Randomization: That’s making exploits a lot less likely, because you can’t assume the position of where to write your exploit.
- Tagging Applications also makes a lot of sense, especially with the signing described earlier.
So before an application is first run, it could present a screen like this:
“Do you want to run ‘’Super Atomic Bomberman’ signed by ‘John Doe’ which you trusted ealier with ‘Superfast Racing Game 3000’? It”s been downloaded from “supersoftware.com” on 08/03/08. It want’s to access the Wifi network as well as your contacts.”
Gute Ideen müssen kopiert werden :-) Das zweite Kölner Barcamp hat noch gar nicht stattgefunden, da schlägt Franz schon das nächste Event vor: Ein iPhoneDevCamp. In San Francisco hat das sehr erfolgreich mit 400 Teilnehmern stattgefunden, drehte sich jedoch mangels SDK nur um die Anpassung von Webapplikationen, nicht um native iPhone-Apps.
Das kann beim deutschen Äquivalent anders werden: Entweder bringt Apple bis dahin ein richtiges SDK raus, oder wir behelfen uns eben damit. Sollte ich bis dahin ein iPhone haben und ein bisschen Zeit finden, um mit UIKit herumzuspielen, werde ich sicher einen Vortrag darüber beisteuern…
Paul Kafasis of the independedent mac development company Rouge Amobea wrote an interesting piece called The Rise of the OS and another called Restarting Innovation that got quite a bit of attention in the mac development world.
Basically Paul says that the OS starts to make a lot of things that were formerly in the domain of third party applications. A modern operating system’s job isnt just to do Task scheduling, network and memory management and put a pretty UI on top of all this: Todays operating systems ship with mail clients, audio/photo/video management software, calendaring, contact management and a lot more. While this seems to be a good thing (You get more for less! Yeah!), it has some serious implications according to Paul: The developers of apps with similar functionality lose their markets and the Users don’t have many apps to chose from, since there is the OS vendor dominating the field.
This discussion began with some ranting about the missing functionality in Apple’s Mail and the fact that no developer wanting to improve that could possibly compete with the free Mail that comes with the OS. The solution proposed was to put Mail’s functionality into a Framework (named “MailKit”) and make it available for other applications. The Webkit framework is a good example for enabling successful applications by putting functionality into a reusable framwork, so why not do it for Mail, too?
I really like the Idea. Sure, Apple could concentrate more on existing frameworks instead of developing new ones, and while I agree with this point, I also think they are on the right track.
Operating systems need to provide the infrastructure that an application lives in. Formerly that was memory management and everything else that you learned in CS, but today’s MVC-driven applications need more things:
They want to share their Data model and make their data interoperable. This gets used more and more, the Address Book Framework is a good example of this, as is Leopard’s Calendar, Notes, and To-Do-List Framework (and some other Framworks that are still under NDA, but that are a huge deal.) A MailKit Framwork would fit right here: Providing a single Mail database to different Mail Applications and exposing functionality for sending and receiving mails. It would make it easy for the user to switch applications, since his actual Mail data is already there, all Mail Apps all access the same store. That’s a huge thing for developers: It doesn’t only cut down development cost for the Data model, it also makes the transition between apps very easy for the user.
In the Controller Layer, there can also be Frameworks, though most of this layser is really specific to the app. The speech Framework is an example, and we will also see some stuff in Leopard that will expose functionality to app developers that Apple used to have for themselves.
The View layer is a classic domain for Frameworks: Nothing here happens without them, as almost everything done here (Buttons, Windows, etc.) comes from AppKit. WebKit falls into this category, it’s a view framework.
This finally brings us to the point of this posting: I think the comparison between the fictional MailKit Framework and Webkit doesn’t fit. One is about shared Data, the other is about (isolated) use of the same view. I really like what Apple does with sharing data, however they can do a lot more. Frameworks are a very good solution of the problems that arise, when the OS is “taking over”. I hope to see ever more future Desktop Applications that work like “Mashups” of these Frameworks, and Leopard is bringing us a huge step into this direction. Also, a Framework that deals with the Data layer has to have the goal of sharing the data, and not only of sharing the model.