I believe Apple’s new runtime language successor to be (or very close to) JavaScript with an Objective-C bridge. Here’s why:

1. JavaScript is already one of the iOS platform languages.
2. JavaScriptCore Nitro is fast.
3. JavaScriptCore already bridges with Objective-C.
4. Apple uses JavaScript in deep, key areas: iAd, iTunes 9, Mobile Me
5. DashCode (and PastryKit).

Apple is probably still sorting out:

1. Security + sandboxes. I once asked Doug Crockford what he thought was in JavaScript’s future and this was it.
2. LLVM compilation. For Apple, it makes sense to have a compiled language story that improves JavaScript performance even further via compile-time analysis and optimization, courtesy of LLVM. It’s great for iOS code validation too.
3. Framework design. Apple is known for taking time to try out features and APIs to get them right before publishing them.

Update To Jesper’s point about replacing Objective-C. I believe this successor adds a new level to the Apple language family and doesn’t replace Objective-C. Use JavaScript where appropriate: high level memory safe, dynamic, functional code with a productive, concise syntax. Drop into Objective-C to do performant, memory efficient, or security-privileged things. Drop into C for more speed, more efficiency. It’s turtles all the way down, and in many ways, we’re already there.

Technorati Tags: Apple, LLVM, JavaScript, WebKit, Objective-C

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

The thing to understand about Section 3.3.1. is that it is the legal letter of the SDK agreement, but not the desired intent.

Developers are allowed to use SQL for database operations. Developers are encouraged to use GLSL via OpenGL ES 2.0 for fast graphics. SQL and GLSL are not languages in the Objective-C family and they are compiled / interpreted. But they also don’t directly link against the Documented APIs (e.g., there’s no “SELECT subviews FROM UIView”).

Regular expressions and XSLT (ugh) are also similarly permitted.

How I intend to interpret Section 3.3.1., as an independent iPhone developer is as follows: Use Objective-C where it makes the most sense: directly interfacing with the iPhone SDK. When I need different tools to achieve something application specific, like an AI in Lua or printing commands in PostScript, I’m going to use them.

For me personally, I feel that this is what Apple permits and practices in the course of mobile software development.

Practices? Yeah. Have you looked at what iPhone OS itself uses? XML and JSON for data serialization. Nibs, property lists, XSLT in XML domain specific languages. TinyScheme to interpret Scheme code for sandboxed process permissions. hunspell’s DSL drive the spell check dictionaries.

For sure, Apple has impure motives. But that doesn’t mean they’re wrong. Mobile constraints are different. Battery life and performance matter. A lot.

Use the right tools for the job: Objective-C when talking to iPhone OS. But whatever your application’s brain needs to think different.

Technorati Tags: Apple, iPhone, Flash, programming, languages, mobile

With 52 days to go, and the iPad rumor mill kicking into gear, the question of the day is, “what is the iPad’s mystery icon?”

So, if you think it’s crazy for Apple to be hiding mystery iPad software and hardware, remember that history tends to iRepeat itself.

Personally, I’m looking forward to iChat and Dashboard widgets on iPad.

Update: Felipe makes a good point in the comments. On June 18, 2007, 11 days before the iPhone launch, Apple also upgraded the display hardware from plastic to glass. Glass display parts are $16 today, while camera parts are roughly $10.

Technorati Tags: iPad, YouTube, Apple

• 1440 x 960 10″ multi-touch display – Even multiples of iPhone OS resolution for easy app scaling up
• ARM Cortex A9 CPU – Fast with long battery life
• PowerVR SGX 545 GPU – OpenCL, baby!
• iPhone OS 4.0 – With tablet frameworks and multitasking
• $599 / $699 – Quoting Steve Jobs, “We don’t know how to make a sub-$500 computer that’s not a piece of junk”.
• Names: iBook, Canvas… or iDroid XP 2010 Tablet Edition

Technorati Tags: Apple, tablet, finally, PowerVR, GPU, iPhone

It seems that all rendering is done on the CPU, when it should’ve been on a GPU accelerated compositor or tiled surface manager.

That would save significant battery life (which we haven’t heard anything about) and really kick ass at performance.

Offloading rendering to the GPU also frees you up to, oh, say, reliably detect touch input events.

System on Chip GPU + CPU combos are fairly inexpensive parts these days. Even with a GPU as simple as the first gen iPhone PowerVR MBX lite would’ve had reasonable performance.

UI latency and scrolling performance make all the difference in multi-touch form factor devices. A true multi-touch contender needs to get this right.

Update:

I just realized that JooJoo plays video smoothly at 1080p. So they definitely have a GPU or DSP in there. They’re so close, they just need to get the software up to snuff, maybe with Clutter?

More Reading: On Mobile Phone OS Design and GPUs

Technorati Tags: JooJoo, GPU, CrunchPad, Arrington, TechCrunch

Tablets will have even bigger screens.

If you want your mobile phone OS to matter in 2010, you’d better optimize for rendering graphics on the GPU.

GPUs are far more power efficient and faster at drawing graphics. As mobile device screens get really large, drawing the graphics “old school” on the CPU is moving from “unacceptable” to “impossible” pretty quickly.

Today, Motorola Droid runs at about half the frame rate of iPhone 3GS. The GPU in both is a PowerVR SGX 530 series chip.*

A PowerVR SGX 530 has a fill rate of 200 million pixels per second. That means Motorola Droid’s GPU could theoretically drive 8 full screen refreshes at 60 fps on a Droid-sized (WVGA) screen. All without the CPU’s help.

Parts of Android’s graphics subsystem seem to be GPU accelerated, but more is needed.

Imagine if the Android UX ran at a rock solid 60 fps. Then, I think we’d have something pretty sexy.

I wonder if Apple’s PA Semiconductor unit is designing GPUs instead of CPUs?

* It’s unclear what the exact model of the iPhone 3GS GPU is, and so the exact fill rate is not known… (though if it were, say, a PowerVR SGX 535, its fill rate would be 400 million pixels per second)

Technorati Tags: Android, Droid, Motorola, Apple, Google iPhone, GPU, PowerVR, graphics

Chocolux is a real-time recursive GPU raytracer using four spheres by Auld. Today, Chocolux now can run in your web browser.

The implications of this are pretty mind blowing. WebGL now allows compiled code to run on the GPU. Imagine what games, image processing, and applications will be possible with compiled shaders and general GPU computing (OpenCL?) now in the browser. And with WebGL gaining widespread adoption, it’s going to be here fairly soon.*

For more information about cutting edge fragment shader GPU raytracing and rendering, check out Rendering Worlds with Two Triangles (PDF).

*pending completion of a stable WebGL spec, naturally.

Technorati Tags: OpenGL, WebGL, graphics, GPU, raytracing, OpenCL

Revisiting my post on Google Chrome Lite from February:

In 2009, Google should embed Google Chrome into Google Toolbar, which has a HUGE install base. This would be a huge driver to accelerate Google’s web platform, convert more folks over to a modern browser experience. Imagine a Chrome “Lite” running inside Toolbar inside IE, billed as a “web accelerator”.

(Insert humorous smug remark here. Okay, it’s out of my system.)

This is the right strategy for Google to use against Microsoft in the browser wars. Google’s 2009 playbook probably looks similar to this:

1. Let Google Chrome Frame mature in open source into a completely awesome (and hopefully secure) web plugin. Web developers get excited and really start using HTML5 instead of talking about it. Security issues are vetted and addressed.
2. Bundle Chrome Frame 1.0 into Google Toolbar (hell, Google everything), with huge established (and unpublicized to date) distribution.
3. Launch both as part of a multi-prong “death by a thousand cuts” attack (Chrome standalone, OEM, Chrome OS, Chrome Mobile, YouTube HTML5 video, etc.) on Internet Explorer.
4. ???
5. Profit!

What should Microsoft do? Get busy. Find a differentiator (graphics, JavaScript, sync, hardware port, XBOX, etc.), stop looking at WebKit and start shipping it already.

Technorati Tags: Google Chrome Frame, Chrome, WebKit, Microsoft, Internet Explorer

User-Agent: iTunes/9.0 (Macintosh; Intel Mac OS X 10.5.8) AppleWebKit/531.9

Survey says: Yes.

It’s important to understand that iTunes is only using WebKit to render the iTunes Store and iTunes LP. The rest of the iTunes UI still remains native in Carbon.

Previous versions of iTunes had a custom native UI for viewing the iTunes Store and were definitely not WebKit based prior to iTunes 9.

Technorati Tags: Apple, iTunes, WebKit