The Problems with Frameworks


apple.gifI have been following Apple’s very recent lockdown on how apps must be written. The resultant communication between Steve Jobs and Greg Slepak and the related post by John Gruber are worth reading.

I will leave the many other sources to speculate why Apple have done this and discuss the ramifications on companies such as Adobe and others that create iPhone app generators and runtimes.

Instead, I find it more interesting to think technically about what Steve has actually said. This also has implications not just on iPhone apps but also on frameworks like Nokia’s Qt and widget frameworks (JIL’s and others) both of which are being promoted as the saviour of mobile development.

Steve said…

"We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform."

Much as I don’t like Apple’s tight control on developers, many of my past observations seem to be in alignment with Steve’s claims…

  • It’s very difficult to make a framework functionally complete. Most serious applications end up needing to use platform APIs that aren’t in the runtime. If this is the case then developers end up having to learn more (runtime AND underlying API AND how to bridge them) rather than less.

Additionally, something I haven’t previously mentioned is the memory-use issue. You can think of (most) use of a runtimes as consuming magnitudes more memory than the equivalent native application. Very recently, there have been great claims as to how many apps can be run at once under Symbian. However, what if a large proportion of these were using a runtime instead of being native?

It’s for this reason I believe Microsoft is being coy about multi-tasking under Windows Phone 7 (Apps run on Silverlight runtime). I also believe it’s another reason why Apple doesn’t like runtimes. They can significantly reduce the number of applications that can be run simultaneously.

Comments are closed.