Unfortunately neither project really showcases a modern, sane, secure way of adding a priveleged helper tool to your application.

BetterAuthorizationSample

With BetterAuthorizationSample (BAS), your application includes an installer tool and a helper tool within the application bundle. Your application then jumps through the following hoops to use the helper tool:

1. Your application runs the installer tool as root via AuthorizationExecuteWithPrivileges(), specifying the helper tool as an argument.
2. Installer tool copies the helper tool into /Library/PrivilegedHelperTools.
3. Installer tool creates a launchd.plist file for the helper tool in /Library/LaunchDaemons. The launchd.plist file specifies the path to the tool and that it should be launched when a connection is made to a UNIX domain socket located at /var/run/<application bundle ID>.socket.
4. Installer tool executes launchctl load -w <path to helper tool launchd.plist>.

At this point your application can connect to the socket at /var/run/<application bundle ID>.socket and start sending commands to the privileged helper tool. Your application might ask the helper tool to “open TCP port 80”, to which the helper tool might respond with “here’s the descriptor that I opened”.

Note that while the BAS sample code’s README claims that it’s “the recommended way to access privileged functionality from a non-privileged application on Mac OS X”, that’s no longer the case. AuthorizationExecuteWithPrivileges() was deprecated in in Mac OS X v10.7, and has been replaced with SMJobBless().

SMJobBless

Introduced in Mac OS X v10.6’s Service Management framework, the SMJobBless() API provides a more modern, secure replacement for the AuthorizationExecuteWithPrivileges() technique used in the BAS sample. Improvements include:

1. The installer tool is unnecessary, so there’s fewer moving parts.
2. The helper tool & launchd.plist are automatically copied into correct system folders and registered with launchd.
3. A trust relationship is established between the application and helper tool via code-signing identities. This means that the helper tool can only be used by explicitely identified applications.
4. Subsequent calls to SMJobBless() will check the version of your helper tool and automatically upgrade it if necessary.

The SMJobBless sample code does a good job of outlining registration & execution of a privileged helper tool, but unlike the BAS sample it does include any form of inter-process communication (IPC) between the application and helper tool. Most developers combine the UNIX domain socket communication code from the BAS sample with the SMJobBless sample code and call it a day.

But surely there’s a more modern IPC mechanism than defining your own custom command protocol over raw UNIX domain sockets?

XPC

Apple introduced the XPC services API in Mac OS X v10.7, providing a modern, lightweight IPC mechanism integrated with GCD and launchd. The typical way of using XPC is by embedding lightweight helper tools in your application (called “XPC services”), which perform work on behalf of your application.

Sound familiar? That’s exactly what we’re after.

So if XPC helps us create these “lightweight helper tool” bundles, can we simply run an XPC service in a privileged context? Apparently not:

Elevating a [XPC] service’s privileges to root is not supported. Further, an XPC service is private, and is available only to the main application that contains it.

So XPC services are out if your helper needs elevated privileges, but that doesn’t mean we can’t use the XPC APIs independently of XPC services.

A quick look at the XPC APIs for creating an XPC connection reveals this:

1

xpc_connection_t xpc_connection_create_mach_service(const char *name, dispatch_queue_t targetq, uint64_t flags);

By registering a Mach service (instead of a UNIX domain socket as per the BAS sample code) with launchd (see man launchd.plist(5)), we can connect to it from our application using xpc_connection_create_mach_service(). Neat!

SMJobBless + XPC

To demonstrate how this works, I’ve modified the SMJobBless sample code and added XPC-based IPC support which you can find on Github.

The initial revision is the original SMJobBless sample code, so you can see all the modifications I’ve made by looking at the commit history.

Summing Up

Neither SMJobBless or BetterAuthorizationSample provide the full picture of how you would create a privileged helper tool and communicate with it from your application. SMJobBlessXPC is a step in the right direction.

Let me know if you have any suggestions for improvements.

e.g. A third party has provided you with a static library (libProprietary.a) which uses KissXML internally for parsing & generating XML. You also have an internal static library (libBitsAndBobs.a) which also uses KissXML. If you use both libraries, you’ll get duplicate symbol errors for all the KissXML classes (DDXMLDocument, DDXMLElement & DDXMLNode).

A brutish yet simple workaround is to remove the offending classes from one of the libraries, so I’ll show you how it’s done.

Firstly, we need to see if the static library is a “fat file”, which means it contains code for multiple architectures. You’ll find most iOS static libraries are fat files, since they need to work both on the device (armv6/armv7) and in the Simulator (i386).

$ lipo -info libProprietary.a
Architectures in the fat file: libProprietary.a are: armv6 i386

As you can see, we have a fat file on our hands.

The tools we’ll be using require us to split the static library into seperate files for each architecture if it’s a fat file. To do that, we’ll use lipo again.

$ lipo -thin armv6 libProprietary.a -output libProprietary-armv6.a

We can now use ar to peek inside one of these thin archive files, listing the included object files.

$ ar -t libProprietary-armv6.a
__.SYMDEF SORTED
FOOBar.o
DDXMLDocument.o
DDXMLElement.o
DDXMLElementAdditions.o
DDXMLNode.o

As expected, in addition to the FOOBar.o file containing code specific to libProprietary.a, we also have object files for each of the classes defined in the KissXML project. To delete those, we’ll need to unpack the object files from the archive, delete the object files we don’t want, and repack the archive.

First, the extraction:

$ mkdir libProprietary-armv6
$ cd libProprietary-armv6
$ ar -x ../libProprietary-armv6.a

We now have a directory containing the contents of the archive:

$ ls -1
DDXMLDocument.o
DDXMLElement.o
DDXMLElementAdditions.o
DDXMLNode.o
FOOBar.o
__.SYMDEF SORTED

Simply remove the KissXML related object files and repack the archive like so:

$ rm DDXML*.o
$ libtool  -static *.o -output ../libProprietary-armv6.a

And to confirm we’ve successfully removed the correct object files from our archive, we can list the contents again:

$ ar -t ../libProprietary-armv6.a
__.SYMDEF SORTED
FOOBar.o

So far we’ve only stripped the armv6 archive, so we need to repeat the process for the i386 archive:

$ lipo -thin i386 libProprietary.a -output libProprietary-i386.a
$ mkdir libProprietary-i386 && cd libProprietary-i386
$ ar -x ../libProprietary-i386.a
$ rm DDXML*.o
$ libtool  -static *.o -output ../libProprietary-i386.a

Now for the final step, we recombine the thin files into a fat file again:

lipo -create libProprietary-armv6.a libProprietary-i386.a -output libProprietary-noKissXML.a

If you’ve done everything correctly you can now replace libProprietary.a with libProprietary-noKissXML.a and you won’t have any more duplicate symbol errors.

Or is it?

While I was researching my previous article on enabling WebGL on iOS via private WebKit APIs, another API caught my eye while I was class-dumping the private WebKit.framework.

1
2
3

@interface WebView (WebPrivate)
+ (void)_enableRemoteInspector;
@end

I did a little bit of research and found an article by Pavel Feldman (@repenaxa) on the Surfin’ Safari blog about WebKit’s remote debugging feature. This private +[WebView _enableRemoteInspector] API enables those same features in mobile WebKit.

Note: This API is available as of iOS 5.0. To use it, you’ll need a copy of Xcode with the iOS 5.0 SDK. You’ll also need to make sure that if you’ve got the iOS 4.0 SDK installed alongside the iOS 5.0 SDK, that you’ve selected iOS 5.0 in the iPhone Simulator via the Hardware → Version menu. Hat tip to Phil Oye (@philoye) for pointing that out.

Enabling remote debugging in a UIWebView

To see if I could get it working, I checked out a copy of my UIWebViewWebGL project, and called the private API in application:didFinishLaunchingWithOptions:

1
2
3
4
5

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
  // ...Snipped...
  [NSClassFromString(@"WebView") _enableRemoteInspector];
  // ...Snipped...
}

The Surfin’ Safari article said the remote debugger runs on port 9222, but connecting to http://localhost:9222 while the app was running in the simulator didn’t seem to work.

Using lsof showed that UIWebViewWebGL.app was actually listening on port 9999:

$ sudo lsof -i TCP -a -p $(pidof UIWebViewWebGL) -P
COMMAND    PID   USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
UIWebView 3748 nathan    9u  IPv6 0xffffff800fa25d80      0t0  TCP localhost:9999 (LISTEN)
UIWebView 3748 nathan   13u  IPv6 0xffffff80111ba340      0t0  TCP localhost:9999->localhost:52483 (ESTABLISHED)

Now when I pointed my browser at http://localhost:9999, it worked!

Logging document.location.href in the web inspector console shows I’m successfully inspecting the web content from UIWebViewWebGL.app running in the iPhone Simulator.

Huzzah!

Enabling remote debugging in Mobile Safari

Enabling the web inspector in an embedded UIWebView is handy, but what about content running in Mobile Safari?

To do that, we need to call the +[WebView _enableRemoteInspector] API from within the Mobile Safari app. The easiest way to do that is by launching Mobile Safari in the iPhone Simulator, and then use gdb to attach to it and call the private API.

1
2
3
4
5
6
7
8
9
10
11
12
13

MobileSafari_PID=$(ps x | grep "MobileSafari" | grep -v grep | awk '{ print $1 }')

if [ "$MobileSafari_PID" == "" ]; then
  echo "Mobile Safari.app must be running in the Simulator to enable the remote inspector."
else

  cat <<EOM | gdb -quiet > /dev/null
  attach $MobileSafari_PID
  p (void *)[WebView _enableRemoteInspector]
  detach
EOM

fi

Browsing to http://localhost:9999 will show an index page listing the URL of each tab open in Mobile Safari. This allows you to have a remote inspector open for each tab in Mobile Safari.

Summing Up

I haven’t used the remote inspector in anger yet, but so far it’s been incredibly useful.

Note that you can’t use gdb to inject code on a device, so enabling remote debugging in Mobile Safari is limited to the Simulator. Hopefully Apple will provide the option to enable it, much like the debug console in Settings → Safari → Advanced → Debug Console.

In the meantime, you can load your web content in an embedded UIWebView. Enabling the remote inspector on a UIWebView in an app running on the device doesn’t seem to work. Using nmap shows that my iPhone only has port 62078 open for OTA syncing, so it’s likely there’s a firewall preventing connections to the remote inspector port.

Have something to say? Discuss on Hacker News.

Earlier this year, Flipboard developer Charles Ying (@charlietuna) fairly & accurately criticised Android’s immature graphics pipeline & subsequent poor drawing performance.

Android’s UX architecture needs work. UI compositing and the view system are both primarily done in software. Garbage collection and async operations frequently block UI rendering.

It sparked a wildfire of comments on the article, Hacker News, and a writeup by John Gruber, who like many others found amusement in the defensive comments of Jonathan Rockway (@jrockway) and other Android apologists. Rockway later admitted to turning off animations entirely, adding to the amusement.

Setting aside the arguments of people who seem content with hands over their eyes and fingers in their ears, Charles had a point. Technically, Android’s architecture was inferior, and it had a measurable effect on the user experience.

Things have come a long way since then, so I think it’s only fair to take another look at Android’s graphics pipeline to see if the issues have been addressed.

A short disclaimer

I write software exclusively for iOS, so you should consider what follows to be biased, at least by observation. I lack insight into the technical depths of Android development, however I like to think I’ve made an attempt over the years to keep abreast of Android technologies & platform capability.

Google Developer Day Sydney

One of the ways I keep up to date with Android is to attend Google Developer Days. At these events, a subset of content from Google I/O is shown in various cities around the world.

At the most recent GDD Sydney, Ankur Kotwal (@ankurkotwal) gave a talk on High-performance graphics for Android which is the catalyst for this article. I’m not sure if Ankur’s slides are online, but they’re near identical to the slides from Romain Guy’s (@romainguy) Google I/O 2011 talk on Android Accelerated Rendering.

Android pre-3.0, the problem restated

As Charles pointed out in his article, the 2D primitives (lines, boxes, text, gradients, images etc.) used to compose a view in an Android app prior to 3.0 are drawn/rasterised on the CPU by the Skia graphics engine. The contents of each view are then combined/composited by the GPU before being displayed on the screen.

Drawing on the CPU isn’t the problem, though. Quartz 2D / Core Graphics — Skia’s equivalent on iOS — performs the majority of rasterisation on the CPU too.

So if the issue isn’t drawing on the CPU, what is? It’s that on Android pre-3.0, the view hierarchy is redrawn on the CPU on each tick of the render loop if any view changes.

Scroll a list? Redraw. Pinch & zoom? Redraw.

That’s fine, if you can keep up.

You need to be able to draw on the CPU & copy the pixels to the GPU quickly enough that you don’t lag behind the display rate of 60hz.

Android phones can this just fast enough, most of the time, so this solution is considered “good enough” by Google. Start running Android on a bigger screen with more pixels, and you’ve got yourself a pipeline problem. TVs & tablets mean bigger screens.

The problem is illustrated quite clearly in a chart from Romain Guy’s Google I/O 2011 talk on Android Accelerated Rendering comparing pixel count and memcpy performance on the HTC G1, HTC Droid, Google Nexus One, Google Nexus S & Motorola’s XOOM tablet:

Interestingly, both the HTC Droid & Nexus One didn’t quite have enough memory bandwidth available to transfer screen-sized pixel buffers to the GPU. The Nexus S gained some speed, but the Motorola XOOM made it clear that something had to change.

The Solution

When you’re scrolling a list, the pixels of the views within the list aren’t changing, they’re simply moving. The GPU already has the pixels of each view in the form of textures, so why not move the texture instead?

This is exactly what iOS does, and is why it’s never suffered any consequences of CPU-based rasterisation.

In the case of scrolling a list we’re simply moving a view, but views can also be scaled, rotated, clipped, made translucent, transformed in 2D or 3D space, or even have pixel shaders applied to them. All these things (and others!) can be done to a view’s contents without needing to redraw & send a new texture to the GPU.

You can find out more about this works on iOS in the View Drawing Cycle section of the View Programming Guide for iOS.

Android Catches Up

Android 3.0 (Honeycomb) bridged the gap between the iOS & Android rendering architecture, allowing developers targeting API level 11+ on tablets to opt-in to the new hardware accelerated pipeline.

Android 4.0 (Ice Cream Sandwich) has done the same, bringing the hardware accelerated pipeline to phones and turning it on by default for all applications built against Android API level 14.

Android Goes One Step Further

Rather than simply generating a CPU-rasterised bitmap ready for the GPU, the Skia 2D drawing APIs generate an ordered list of operations. Each view maintains a list of those operations in a DisplayList. Android 3.0 introduced a new OpenGL-ES Skia backend, which takes each of those DisplayLists and runs the operations on the GPU. Pretty neat!

This technique of keeping an ordered list of drawing operations is similar to PDF’s object graph:

…each page in a PDF document has a page content stream—an ordered list of drawing operations that describes how to render the page-content when it is drawn.

Some of you may have noticed that quote’s from a book on Mac OS X’s Quartz framework. Here’s why:

Quartz’s internal imaging model correlates well with the PDF object graph, making it easy to output PDF to multiple devices.

i.e. Quartz & Skia have a similar internal model.

In fact, Apple released something similar to Skia’s OpenGL backend called Quartz 2D Extreme in Mac OS X 10.4 (renamed QuartzGL in 10.5), but never ported the technology to iOS.

I’d always thought QuartzGL wasn’t ported due to lacklustre performance, based on Matt Gallagher’s article comparing Quartz & QuartzGL performance on Mac OS X. However, it seems Google’s results have been rather positive, as can be seen in this chart from Romain Guy’s Google I/O 2011 talk on Android Accelerated Rendering:

These results seems rather impressive!

Conclusion

The changes to Android’s rendering pipeline in 3.0 & 4.0 bring it into the same league as iOS & Windows Phone 7. Hopefully the migration 2.x to 4.x is smooth, given the minor incompatibilities between Skia’s CPU & GPU backends.

It’ll be interesting to see whether Apple decides to provide a GPU rasterisation backend to Quartz 2D / Core Graphics on iOS. It doesn’t seem to be a pain point, but you never know.

I’ll definitely be keeping my eye on the Nexus Prime. If they’re any good, I may need to stop spectating from the edges and get my hands dirty.

Even more incredible is how quickly creative folks have taken the idea and run with it. Marcin Ignac (@marcinignac) & David Gauthier from the Copenhagen Institute of Interaction Design built a gesture-driven WebGL-enabled browser called GoWebGL, and put together a demo video showcasing WebGL on an iPad 2:

The framerates are slow at times which seems to justify Apple’s tentative rollout of WebGL, however the potential is excitingly clear!

Others won’t know who Blaine Garst is, despite being exposed — at least indirectly — to the phenomenal body of work he’s been responsible for at both NeXT and Apple.

You only need to look at the lineage of his accomplishments to get an impression of the dent he’s made on the universe:

1971 PLATO user, bit-mapped graphics, chat rooms, dogfights
1974 University High School, Math & Science award
1974 exposed to UNIX by Greg Chesson
1976 University of Illinois, BA Economics
1977 UCLA MS degree requirements met, Bell Labs
1981 first person to boot UNIX on 11/782 dual processor
1984 Manager System V R2.2 (?), 1st dual processor support
1986 purchased VFS/NFS for System V Release 3 (?)
1987 co-architect of SVR4 as part of 20% purchase of Sun
1988 On “Phase-3” team when/where “Spring” named/derived
1989 “Fizix” nanokernel built on Cheriton’s “door” IPC idea, 20x cost to do remote vs local procedure call
1990 NeXT Computer, Inc.
1991 Objective-C Protocols, “ripped-off” in Java as Interfaces
1992 Foundation: “Distributed Objects”, retain/release, NSLock, NSRunloop, NSTimer, NSThread, …
1993 Direct Embedding Fast Elliptical Encryption
1994 “Foundation” on HPUX, Solaris, DEC, …
1996 JavaBridge - Java subclassing of ObjC
1998 two-GC cycle recovery in JavaBridge
2003 @try…, @synchronized
2007 ObjC2: GC, for..in, @properties, …
2008 Blocks C,ObjC,C++; TLC: 10^6 alloc+recovery/sec/core
2009 n-GC cycle recovery (generalization of 2-GC)

Humbling.

Have something to say? Discuss on Hacker News.

I’ve become a lot more interested in WebGL lately, and remembered reading on Hacker News a while back that WebGL would be available in iOS 5 as part of the iAd framework.

WebGL will not be publicly available in iOS 5. It will only be available to iAd developers.

When iOS 5.0 went GM, I decided to knock up a quick WebGL demo to see what was involved & how well it performed.

Unfortunately it didn’t run at all — creating a webgl-experimental context via the canvas element’s getContext() API would fail.

Breakthrough

I shot through a tweet to Antoine Quint (iAd JS/iOS software engineer at Apple), asking for confirmation of Chris Marrin’s email:

Chris Marrin suggested that WebGL would be available in iAds as of iOS 5.0. Is that actually the case?

To which he replied:

WebGL has been supported for iAds since iOS 4.2.

That’s even better news than I had anticipated! However, it still doesn’t explain why I’m unable to create a WebGL context.

With a little bit more prompting, I got to the bottom of why HTMLCanvasElement was returning null when I called getContext("experimental-webgl"):

You also need to have “uses-webgl” in your ad’s plist. Sorry, forgot about that.

The uses-webgl setting is completely undocumented, but it certainly works!

Demo iAd WebGL Project

I’ve put together a demo WebGL iAd project that can simply be dragged into the Simulator or synced to your device via iTunes.

Drag the WebGL.ad directory into the iOS Simulator & the built-in iAd Tester app will launch. You’ll see a banner at the bottom, which when tapped will bring up the WebGL demo:

If you’re having difficulties getting the iAd running, take a look at the Testing on the iOS Simulator and Testing on the Device sections of the iAd JS Programming Guide.

Do standard UIWebViews (secretly) support WebGL?

So if the iAd framework is using a UIWebView, perhaps we can get the same behaviour in our own web views?

Looking at the output of ps while running iAd Tester in the iOS Simulator, you’ll notice an app called AdSheet running. Using otool, we can see what private frameworks it’s linked against:

otool -L /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk//Applications/AdSheet.app/AdSheet | grep PrivateFrameworks
  /System/Library/PrivateFrameworks/iAdCore.framework/iAdCore (compatibility version 1.0.0, current version 1.0.0)
  /System/Library/PrivateFrameworks/SpringBoardServices.framework/SpringBoardServices (compatibility version 1.0.0, current version 1.0.0)

iAdCore.framework looks interesting. Let’s take a look for WebGL-related functionality using class-dump:

class-dump /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/System/Library/PrivateFrameworks/iAdCore.framework/iAdCore

Searching through the output, it’s pretty clear that we’ve found what we’re after:

1
2
3
4
5

@interface ADWebView : UIWebView {
    BOOL _webGLEnabled;
}
@property(nonatomic) BOOL webGLEnabled; // @synthesize webGLEnabled=_webGLEnabled;
@end

Turns out we can simply link against the private iAdCore.framework, and use ADWebViews instead of UIWebViews. Here’s an implementation which does just that:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@implementation WGLAppDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
  Class ADWebView = NSClassFromString(@"ADWebView");
  UIWebView* webView = (UIWebView *)[[[ADWebView alloc] initWithFrame:self.window.bounds] autorelease];
  [webView setWebGLEnabled:YES];

  NSString* htmlPath = [[NSBundle mainBundle] pathForResource:@"WebGL" ofType:@"html"];
  NSURLRequest* request = [NSURLRequest requestWithURL:[NSURL fileURLWithPath:htmlPath]];
  [webView loadRequest:request];

  UIViewController* viewController = [[[UIViewController alloc] init] autorelease];
  viewController.view = webView;

  self.window.rootViewController = viewController;
  [self.window makeKeyAndVisible];

  return YES;
}
@end

Is ADWebView really doing that much?

Perhaps we can get rid of ADWebView altogether & just implement whatever -[ADWebView setWebGLEnabled:] is doing in our own custom UIWebView subclass. We’re still going to be calling private APIs, but at least we won’t need to link against private frameworks.

To reproduce -[ADWebView setWebGLEnabled:], we’ll need to disassemble it using otool -tVv, or install objdump via Homebrew & use gobjdump -d. Here’s the bit we’re interested in:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

0005aba3 <-[ADWebView setWebGLEnabled:]>:
   5aba3:       55                      push   %ebp
   5aba4:       89 e5                   mov    %esp,%ebp
   5aba6:       56                      push   %esi
   5aba7:       83 ec 24                sub    $0x24,%esp
   5abaa:       e8 00 00 00 00          call   5abaf <-[ADWebView setWebGLEnabled:]+0xc>
   5abaf:       59                      pop    %ecx
   5abb0:       8b b1 89 e4 04 00       mov    0x4e489(%ecx),%esi
   5abb6:       8a 45 10                mov    0x10(%ebp),%al
   5abb9:       8b 55 08                mov    0x8(%ebp),%edx
   5abbc:       88 04 32                mov    %al,(%edx,%esi,1)
   5abbf:       8b b1 d5 65 03 00       mov    0x365d5(%ecx),%esi
   5abc5:       89 75 e0                mov    %esi,-0x20(%ebp)
   5abc8:       c7 45 e4 00 00 00 42    movl   $0x42000000,-0x1c(%ebp)
   5abcf:       c7 45 e8 00 00 00 00    movl   $0x0,-0x18(%ebp)
   5abd6:       8d b1 50 00 00 00       lea    0x50(%ecx),%esi
   5abdc:       89 75 ec                mov    %esi,-0x14(%ebp)
   5abdf:       8d 89 c1 d9 04 00       lea    0x4d9c1(%ecx),%ecx
   5abe5:       89 4d f0                mov    %ecx,-0x10(%ebp)
   5abe8:       89 55 f4                mov    %edx,-0xc(%ebp)
   5abeb:       88 45 f8                mov    %al,-0x8(%ebp)
   5abee:       8d 45 e0                lea    -0x20(%ebp),%eax
   5abf1:       89 04 24                mov    %eax,(%esp)
   5abf4:       e8 d7 45 00 00          call   5f1d0 <_WebThreadRun$stub>
   5abf9:       83 c4 24                add    $0x24,%esp
   5abfc:       5e                      pop    %esi
   5abfd:       5d                      pop    %ebp
   5abfe:       c3                      ret    

0005abff <___29-[ADWebView setWebGLEnabled:]_block_invoke_0>:
   5abff:       55                      push   %ebp
   5ac00:       89 e5                   mov    %esp,%ebp
   5ac02:       57                      push   %edi
   5ac03:       56                      push   %esi
   5ac04:       83 ec 10                sub    $0x10,%esp
   5ac07:       e8 00 00 00 00          call   5ac0c <___29-[ADWebView setWebGLEnabled:]_block_invoke_0+0xd>
   5ac0c:       5e                      pop    %esi
   5ac0d:       8b 7d 08                mov    0x8(%ebp),%edi
   5ac10:       8b 47 14                mov    0x14(%edi),%eax
   5ac13:       8b 8e 54 66 04 00       mov    0x46654(%esi),%ecx
   5ac19:       89 4c 24 04             mov    %ecx,0x4(%esp)
   5ac1d:       89 04 24                mov    %eax,(%esp)
   5ac20:       e8 a7 46 00 00          call   5f2cc <_objc_msgSend$stub>
   5ac25:       8b 8e 50 66 04 00       mov    0x46650(%esi),%ecx
   5ac2b:       89 4c 24 04             mov    %ecx,0x4(%esp)
   5ac2f:       89 04 24                mov    %eax,(%esp)
   5ac32:       e8 95 46 00 00          call   5f2cc <_objc_msgSend$stub>
   5ac37:       0f be 57 18             movsbl 0x18(%edi),%edx
   5ac3b:       8b 8e 94 6a 04 00       mov    0x46a94(%esi),%ecx
   5ac41:       89 54 24 08             mov    %edx,0x8(%esp)
   5ac45:       89 4c 24 04             mov    %ecx,0x4(%esp)
   5ac49:       89 04 24                mov    %eax,(%esp)
   5ac4c:       e8 7b 46 00 00          call   5f2cc <_objc_msgSend$stub>
   5ac51:       83 c4 10                add    $0x10,%esp
   5ac54:       5e                      pop    %esi
   5ac55:       5f                      pop    %edi
   5ac56:       5d                      pop    %ebp
   5ac57:       c3                      ret    
   5ac58:       0f 1f 84 00 00 00 00    nopl   0x0(%eax,%eax,1)
   5ac5f:       00

I won’t go into detail about how to read the disassembly, but hopefully you’ll be able to see that at 5abf4 we’re running a block of code on what seems to be the UIWebView’s dedicated web thread (_WebThreadRun$stub). The block itself seems to be making 3 consecutive Objective-C method calls (_objc_msgSend$stub) at 5ac20, 5ac32 & 5ac4c.

By running the previous snippet where we were linking against the private iAdCore framework and using ADWebView, we can set a symbolic breakpoint on ___29-[ADWebView setWebGLEnabled:]_block_invoke_0 and see what the values of the $eax & $ecx registers are prior to calling objc_msgSend. Look at the i386 ABI for objc_msgSend(), and you’ll note that these registers correspond to the receiver ($eax) of the message and the selector ($ecx) being called.

Stepping through, we see:

• At 5ac20, $eax is an instance of ADWebView, and $ecx is _browserView.
• At 5ac32, $eax is an instance of UIWebDocumentView and $ecx is webView.
• At 5ac4c, $eax is an instance of WebView and $ecx is _setWebGLEnabled:.

From this, we can piece together our re-implementation of -[ADWebView setWebGLEnabled:]:

1
2
3
4
5

- (void)setWebGLEnabled:(BOOL)enableWebGL {
  UIWebDocumentView* webDocumentView = [self _browserView];
  WebView* backingWebView = [webDocumentView webView];
  [backingWebView _setWebGLEnabled:enableWebGL];
}

I’ve put together an Xcode project demoing the results of this, which you can find on Github.

Summing Up

Apple are clearly working towards supporting WebGL in a more general sense, as can be seen in their support for it in iAds.

Instead of whinging about it only being available in iAds, I’ve demonstrated that it’s possible to take advantage of WebGL using standard embedded web views (albeit using private APIs).

This will let developers track the progress of Apple’s commitment to WebGL, and skate to where the puck is going to be.

I’m really looking forward to seeing what you all come up with!

Have something to say? Discuss on Hacker News.

But it’s not all doom and gloom. I see two major issues:

1. Carriers are barring applications they deem disruptive to their business
2. The submissions process is completely opaque

If history is anything to go by, the first issue is going to be very difficult to resolve directly. It’s the second issue I think we’re in a position to easily fix.

First, I think it would be productive to look at the J2ME platform.

One of the biggest issues that’s plagued J2ME has been greedy carriers standing in the way of developers trying to bring their applications to market (ring any bells?). To access run-of-the-mill features like the address book, networking or GPS APIs you need to sign your application. Problem is, certificates from well known CAs like Verisign are stripped from carrier-branded phones in favour of carrier issued certificates. Many carriers run their own developer program to facilitate code-signing of applications that will run on their network.

The industry’s “answer” to this problem was to come up with Java Verified, a process that allows developers to submit their applications to one of a handful of “Authorized Test Houses” and pay around $300USD to have it taken through a standard test procedure. If it passes, you get a signed application which will run on most carriers and devices. If it fails, you pay again for the privilege of having it retested. Also note that you’re paying to have your application tested on a specific device of your choosing, so if you’d like your application tested on multiple devices, you pay per device.

Disregarding the fact that the Java Verified process will leave you thousands of dollars poorer once you’ve released a few versions of your application to a handful of devices, it’s quite similar to Apple’s verification process. You submit your application, it gets tested according to a criteria that carriers are happy with, and if your application passes you’re good to go.

BUT, there’s one minor difference; the Java Verified testing houses are all following the same open, standard test script. It’s called the Unified Testing Criteria (PDF), and it’s made available to developers so that they know how their applications are being scrutinised by the testers.

I think Java Verified’s Unified Testing Criteria would form a great basis for a similar document to be written for the App Store submission process. It would cover areas like:

• High-level APIs being used (GPS, address book etc.), how frequently they’re used, and whether or not they remove user data (address book entries etc.)
• Remote content used in the application. Where does it come from? Is it interpreted and/or executed to change the behaviour of the application? Could it contain offensive content? Does the application’s rating take into account mature content?
• Data usage over 3G, including a clear set of quantitative guidelines that take into account what carriers deem appropriate on their networks
• Rights to publish content, either through ownership, licensing or fair use
• Use of advertising
• Whether or not behaviour, usage and metrics about the user are recorded
• Stability, performance, memory, network and battery usage tests
• Adherence to the Human Interface Guidelines (HIG)
• Handling of memory warnings
• Handling of registered URL schemes
• Ability to run during a call or tethering
• Ability to handle lack of network access or network delays
• Appropriate use of the keychain for secure storage

The document would likely take the form of a questionnaire, with a clear definition of pass/fail conditions for the various questions. If a developer filled out the questionnaire and received a clear pass but Apple’s testing produced a fail, the difference between their questionnaires would form the basis for productive communication to resolve the issues and allow for resubmission. The document would evolve over time, hopefully reaching a point where if you filled out the questionnaire yourself and got a pass, you’re almost guaranteed to get through the submission process.

I really think this would make a world of difference, and wouldn’t require any drastic changes for Apple other than a little bit more open documentation of the existing process.

• http://feeds.feedburner.com/atnan-articles
• http://feeds.feedburner.com/atnan-all-comments

Sorry for any inconvenience – I know I’ve found it a bit of a pain when other blogs have changed their feed URLs on me!

You can grab a copy of the configuration profile directly from my site, or by visiting the original thread Matt attached the file to on Apple’s developer forums.

To install the profile on your device, you can point Mobile Safari directly at the file on my site, email the file to your device, or install it via the iPhone Configuration Utility. For those of you who are unfamiliar with *.mobileconfig files, you should read Apple’s Enterprise Deployment Guide which provides much more detailed instructions.

The first time I grabbed a beta version of the SDK, all I did was hit the install button and let it do its thing. However, if you don’t change any of the default install settings, you’ll quickly find that the beta SDK has been installed straight over the top of your stable version of the SDK.

The solution is to install two copies of Xcode and the SDK; the stable version goes in /Developer, and the beta version goes in /Developer-Beta.

If you’ve already installed a beta version of the SDK in /Developer, you’ll need to remove it. To do this, you should run the following from the command line:

$ sudo /Developer/Library/uninstall-devtools --mode=all

You can then proceed to install the stable SDK in /Developer and the beta in /Developer Beta. If you ever need to blow away your beta copy of Xcode and the SDK, you should run the same command as above but from the beta directory instead:

$ sudo /Developer Beta/Library/uninstall-devtools --mode=all

Finally, to launch Xcode with the stable SDK you run /Developer/Applications/Xcode.app and to launch Xcode with the beta SDK, run /Developer-Beta/Applications/Xcode.app.

If you’ve configured a bunch of CalDAV calendars in iCal, unfortunately they’re synced to the iPhone as read-only calendars which is a real pain. In lieu of a fix by Apple, we’ll need to remove the iCal CalDAV accounts from the iTunes calendar sync list, and configure them on the iPhone itself.

To set up a new CalDAV account, you’ll need to navigate through the following screens on your iPhone:

Settings → Mail, Contacts, Calendars → Add Account... → Other → Add CalDAV Account...

Once you’re there, you’ll be presented with a dialogue that lets you enter a CalDAV server, username, password and description. This dialogue is incredibly misleading, because the “server” field will not only accept a hostname like “www.google.com”, but also a full CalDAV URL like https://www.google.com/calendar/dav/<CALENDAR_ID>/user. If you’re using Google Calendar with only one calendar, enter your Google Calendar credentials like the following example:

If you’ve got multiple CalDAV calendars, it starts to get a little bit hairier. Initially, I emailed myself a list of my CalDAV URLs (4 in total) and used the new copy-paste features to manually configure each account using the previous instructions, only instead of using “www.google.com” in the server field, I pasted the entire CalDAV URL instead. As you can imagine, this is incredibly tedious.

Fortunately Apple also released a new version of the iPhone Configuration Utility (ICU), which is a really handy tool for creating iPhone configuration bundles for deployment in enterprise environments. Among other things, this new version allows you to configure CalDAV accounts. If you haven’t already, you should grab a copy of ICU for Mac OS X or Windows.

Launch ICU, create a new configuration profile, and open the CalDAV pane. For each CalDAV calendar you want to configure, you’re going to want to fill it in like this:

If you’re looking at the Principal URL field and wondering what is, you’ll find it in the calendar settings page of Google Calendar under Calendar Address (it should look like an email address).

Once you’ve entered all your CalDAV accounts, plug in your iPhone, select it in ICU and open the Configuration Profiles tab. You should see the configuration profile you just created, with an “Install” button next to it. Hit the “Install” button.

You iPhone should show a screen like this:

If you hit “More Details”, you’ll see the CalDAV calendars listed:

Hit “Install”, confirm, and open up the Calendar App to see if everything works as expected. You should be able to create, edit and delete calendar entries in your CalDAV accounts, and have them update in iCal / Google Calendar. If you ever want to add a new CalDAV calendar, I think you need to remove the configuration via the iPhone Configuration Utility and re-install the edited configuration bundle.

Hopefully it doesn’t take too long for Apple to make the CalDAV integration between iCal and the iPhone more seamless.

UPDATE: I’ve downloaded the Telstra and Vodafone bundles and made similar modifications, so they’re now available in the guide. If you’re using Telstra/Vodafone and my modified settings bundles work, please let me know in the comments as I’m unable to test it myself.

The following instructions are intended for members of the Apple Developer Connection (ADC), running an iPhone with a developer version of the iPhone OS 3.0 software. This guide also only provides Australian carrier settings for Telstra, Vodafone and Optus (plus resellers like Virgin), but if you follow the link to Crunchgear in the first step there are instructions on downloading and modifying the carrier setting bundles.

1. Download Telstra_au.ipcc, Vodafone_au.ipcc or Optus_au.ipcc, which were created as per the AT&T instructions on Crunchgear (note that the file should have an “.ipcc” extension, not “.zip”. If your downloaded file has a “.zip” extension, unzip it to produce a “Carrier_au.ipcc” file)
2. Open iTunes
3. Plug in your iPhone
4. Select you iPhone under devices
5. In the Summary tab, ⌥-click (option-click) the “Check for Update” button
6. Select the previously downloaded Telstra_au.ipcc, Vodafone_au.ipcc or Optus_au.ipcc file and click “Open”
7. Once the settings have been copied, disconnect your iPhone
8. Restart your iPhone
9. Open the Settings application on your iPhone, and navigate to General, then Network, and finally Internet Tethering
10. Turn Internet Tethering on. At this point, tethering is now possible via USB when your iPhone is plugged in. If you’d like to use Bluetooth, continue reading
11. You will be prompted to turn bluetooth on if it’s not on already. Select yes if prompted
12. On your laptop, turn on bluetooth and open the Bluetooth Preference pane
13. Click “Set Up New Device…”, which will open the Bluetooth Setup Assistant
14. Select “Mobile Phone” as the Device Type
15. Select your iPhone from the device list
16. A number should appear on your laptop, and your iPhone should prompt you for a pin
17. Enter the pin from your laptop into your iPhone
18. Once paired, make sure you keep “Use device as network port” selected
19. In the Bluetooth Preference Pane, make sure “Show Bluetooth status in the menu bar” is selected, since it makes things easier for starting and stopping tethering
20. Click the Bluetooth icon in your status bar, where you should now see your iPhone under devices
21. Click on the menu item for your device, and select “Connect to Network”
22. On your iPhone, you should now notice that the top of the screen has a blue bar titled “Internet Tethering”
23. You can now use the Internet!
24. As an optional extra, you can open Network Preferences and rename the two new network devices to “iPhone USB” and “iPhone Bluetooth”

Not really a difficult process, but it can be a bit fiddly. Downloading my preconfigured files also saves mucking around in Property List Editor, which most people will attest is a bit of a pain.

Thankfully as of two days ago, that hack is no longer required if you’re using Passenger.

Hongli Lai (the lead developer of Phusion Passenger) has checked in a change that enables support for chunked transfer-encoding, which means no more dreaded HTTP/1.1 411 Length Required responses. So the fix is checked into the tree, and according to the bug report will be made available in the next release of the Passenger gem — version 2.1.4.

One of the commenters was concerned that J2ME developers suffering from this problem might find it difficult to find my article since I didn’t really mention J2ME MIDlets much at all. So, if you’re a J2ME developer suffering from problems like those described here, here or here…check out the original article for a simple solution.

So if you’re trying to do chunked HTTP POST requests using the CFNetwork stack, make sure your Apache configuration can deal with the chunked header:

RequestHeader edit Transfer-Encoding Chunked chunked early

Not sure who had the bright idea, but one of the developers decided to try passing in the HTTP body as an NSInputStream (via -[NSMutableURLRequest setHTTPBodyStream:]), rather than as NSMutableData (via -[NSMutableURLRequest setHTTPBody:]). Magically, this seems to have solved the memory leak issues.

Unfortunately, it created another issue.

You might remember that 3 months ago I wrote an article on how much of a pain in the arse it was to accept HTTP POST requests from user agents specifying a Transfer-Encoding HTTP header value of chunked (resulting in a POST request with no Content-Length header). In that article, I proposed a solution using Apache 2 and mod_proxy’s proxy-sendcl option to get things working again. This worked fine for our J2ME clients, but when our iPhone application started blowing chunks at us, our server crapped out with the dreaded 500 error I thought I’d fixed for good:

Chunked Transfer-Encoding is not supported

After whipping out Wireshark, we realised that there was a tiny difference between between what our J2ME client was doing and what the iPhone was doing.

This is the header the J2ME app was sending:

Transfer-Encoding: chunked

And this is the header the iPhone was sending:

Transfer-Encoding: Chunked

As much as I’d like to think the different casing of chunked and Chunked wouldn’t affect the behaviour of mod_proxy, it seems it does. Fortunately, we can work around this problem too by using Apache’s mod_headers module. This allows us to do the following:

RequestHeader edit Transfer-Encoding Chunked chunked early

When combined with the solution from my previous article, this leaves us with the following complete solution:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

ProxyRequests Off

<Proxy http://localhost:81>
  Order deny,allow
  Allow from all
</Proxy>

Listen 80

<VirtualHost *:80>

  RequestHeader edit Transfer-Encoding Chunked chunked early

  SetEnv proxy-sendcl 1
  ProxyPass / http://localhost:81/
  ProxyPassReverse / http://localhost:81/
  ProxyPreserveHost On
  ProxyVia Full

  <Directory proxy:*>
    Order deny,allow
    Allow from all
  </Directory>

</VirtualHost>

Listen 81

<VirtualHost *:81>
  ServerName ooboontoo
  DocumentRoot /path/to/my/rails/root/public
  RailsEnv development
</VirtualHost>

And then mobile phones came along.

The service I’m working on at the moment is consumed by a bunch of clients, including but not limited to web browsers, WAP browsers, the Flash player, iPhones, J2ME devices. It’s the last one that’s causing headaches at the moment.

You see, despite the fact that HTTP/1.1 is about 9 years old, not all web servers support the features that were introduced. The particular one I’m talking about is chunked tranfer encoding, but I’m sure there are many others.

To give you a general idea, the HTTP implementations on many mobile handsets will decide to use a chunked transfer encoding if the payload of a PUT/POST request is over an arbitrary threshold. This causes issues with servers like Nginx, Lighttpd, Thin, since most of those assume that an incoming HTTP request with a payload will also include a Content-Length header.

Well guess what? As of 9 years ago, that hasn’t been the case.

Take a look at this request:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

POST /search.json HTTP/1.1
User-Agent: curl/7.16.4 (i486-pc-linux-gnu) libcurl/7.16.4 OpenSSL/0.9.8e zlib/1.2.3.3 libidn/1.0
Host: ooboontoo
Accept: */*
Transfer-Encoding: chunked
Content-Type: multipart/form-data; boundary=----------------------------ab5090ac7869


92
------------------------------ab5090ac7869
Content-Disposition: form-data; name="query"

zoooom
------------------------------ab5090ac7869--


0

Notice anything? If not, try and find a Content-Length header. Pre-HTTP/1.1 you’d expect to get an HTTP 411 error (length required), but after HTTP/1.1 it’s pretty clear what the HTTP/1.1 applications are obliged to do:

All HTTP/1.1 applications that receive entities MUST accept the “chunked” transfer-coding (section 3.6), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.

That’s why I find it so surprising that hacks are involved in allowing mobile clients to POST/PUT to what I’d traditionally thought of as HTTP/1.1 compliant web servers.

But anyway, you want to see the solution right?

Well, our initial solution involved Gerald Kaszuba writing a little web server in Python which went by the name of “Dechunker”. You can imagine what it did, but we quickly found that while it was the simplest way to avoid the problem, it also meant that over time we would end up needing to implement the functionality that was already available in most other web servers. Servers like Apache2 and Lighttpd have become incredibly hardened over the years, and we’re not going to achieve that overnight.

So I then took another look at Apache2, knowing that some modules do support chunked transfer encoding while others don’t. What I discovered was that Apache’s mod_proxy module could be used in front of anything that doesn’t support chunked encoding, since it can be configured to “dechunk” requests before passing them to a backend.

It looks a little something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

ProxyRequests Off

<Proxy http://localhost:81>
  Order deny,allow
  Allow from all
</Proxy>

<VirtualHost *:80>
  SetEnv proxy-sendcl 1
  ProxyPass / http://localhost:81/
  ProxyPassReverse / http://localhost:81/
  ProxyPreserveHost On
  ProxyVia Full

  <Directory proxy:*>
    Order deny,allow
    Allow from all
  </Directory>

</VirtualHost>

Listen 81

<VirtualHost *:81>
  ServerName ooboontoo
  DocumentRoot /path/to/my/rails/root/public
  RailsEnv development
</VirtualHost>

As you can see I’ve got Apache2 listening on port 80, which uses the proxy-sendcl environment variable available in mod_proxy to repack the HTTP body and add a Content-Length header to the request. This request is then passed back to a virtual host running on port 81, which is configured to use Phusion Passenger.

Turns out it’s pretty simple, and from what I’ve seen there haven’t been any negative performance impacts by proxying all requests. It’s not a permanent solution, and as soon as Phusion Passenger fixes the chunked encoding bug, I’ll drop mod_proxy from our configuration.

This little patch solves that problem by allowing you to decorate your Rails models with model-wide serialisation options, like so:

1
2
3
4

class Article < ActiveRecord::Base
  has_many :comments
  serialization_options :include => :comments
end

This means that whenever you call to_json or to_xml on an instance of Article, you’ll get the comment association thrown in for you. You’ll find you can clean up your Controllers and remove explicit calling of to_json, which previously would have looked like this:

1
2
3

respond_to do |format|
  format.json :json => @article.to_json :include => :comments
end

But can now be change to this:

1
2
3

respond_to do |format|
  format.json :json => @article
end

While it’s very simple, some people might find it useful. If you do, chuck this in your /lib directory and require it in RAILS_ROOT/config/environment.rb.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

module SerializationOptions
  def serialization_options(options = {})
    class_inheritable_accessor :serialization_options
    self.serialization_options = options.dup
  end
end

ActiveRecord::Base.send(:extend, SerializationOptions)

class ActiveRecord::Serialization::Serializer
  alias_method :old_initialize, :initialize
  def initialize(record, options = {})
    if record.respond_to? :serialization_options
      options = record.serialization_options.merge(options)
    end
    old_initialize(record, options)
  end
end

• Cameron Adams
• Jina Bolton
• Mark Boulton
• Dan Cederholm
• Andy Clarke
• Jeff Croft
• Aaron Gustafson
• Jon Hicks
• Roger Johansson
• Richard Rutter
• Jonathon Snook

From what was explained, their aim is to work through the CSS specifications and give feedback and examples for some of the more difficult issues, and then provide a body of work to the W3C and/or browser vendors with the hope that it things along a little faster than is currently the case. More details are sure to appear on the CSS Eleven website.

Here’s a snap of his slide: