chpwn blog

Why not Siri for iPhone 4, iPod touch right now?

As @stroughtonsmith and I demonstrated a few days ago, it is possible to run Siri on iPhone 4 and iPod touch. However, as we are currently unable to distribute the port or the procedure we used, I think I should at least explain the reasons why that isn’t happening.

For a little background information, it’s important to understand the fundamentals of how copyright law works. Apple owns the copyright on the software, images, and data used inside iOS: they created them. Because of that, they have the ability to decide what other people can — are licensed to — do with them: copy, distribute, adapt, modify, or any number of other protections of their works. Pretty simple. But this does lead to one important, if somewhat counterintuitive, fact: just because a piece of data is available freely on the internet does not mean that you have the rights to redistribute that data (or any part of it) without an applicable license. In practice, that means that just because certain files are freely available on a device or inside a firmware (.ispw) file freely downloadable from Apple’s website, it does not imply that those files can legally be distributed by anyone else.

In the context of Siri, this means that the resource files, images, and code that makes up Siri cannot be freely shared. These frameworks and plugins that work together to build Siri are not included on other iOS builds besides the ones running on the iPhone 4S. Therefore, these files must be copied from a running iPhone 4S, or from the iPhone 4S’s firmware (.ipsw) file. The first method requires you to own an iPhone 4S to copy the files from, so it is not useful for most people: if you already own an iPhone 4S, you already have Siri. The issue with the second method is more technical: the firmware files are distributed encrypted, and we do not yet have the decryption key to access the Siri files inside of the iPhone 4S firmware file.

Just from that, you currently must already own an iPhone 4S to install Siri on it without a blatant copyright violation. But even that’s not all: if you do all of that, there’s still a few more reasons why Siri won’t just work.

Many people have managed to display the Siri UI on the iPhone 4; it is, in fact, reasonably trivial with access to the files copied off an iPhone 4S (as explained above). But only Steven and myself — yes, I know there are others that claim to have: I’ll tell you this, they haven’t ;) — have managed to make Siri successfully contact the Apple servers and receive responses. Why? Here, the answers become slightly more murky. Partially this is because I don’t want to reveal too much about the procedure to try and ensure that you all will be able to use it in the future, and partially because it requires a jailbroken iPhone 4S, something which is currently not publicly available. Anyway, the general gist of it is that you almost certainly need the access provided by the a jailbreak to extract all of the information necessary to get Siri working on another device, and that’s not yet availble. (And, no, I don’t know when it will be. You can follow along with me while we wait, though!)

Anyway, I hope that clears up some of the technical and legal reasons why distributing a build (or instructions) to run Siri on older hardware isn’t possible at the moment. When we have the ability to decrypt the encrypted iPhone 4S firmware file — to extract the Siri files legally, without the need for an iPhone 4S — and we have an iPhone 4S jailbreak to obtain the other nececssary information at a mass scale, hopefully this can become a reality and everyone can try out Siri on their older devices. Until then, showing you a video that it is possible is the best we can do.

(Oh, and to answer another popular question: nobody has tried it on an iPhone 3GS or iPod touch 3G or an iPad on iOS 5, so we don’t have any clue if it will work or not there. But we can hope it will!)

Blocks for Target/Action?

Blocks are an awesome extension to C. And, since iOS 4 (the first version that supported blocks) now has enough adoption to make it safe to be minimum version that I support, I’ve been checking out blocks quite a bit to see where they could make blocks easier.

Some of the UIKit and Foundation APIs have been updated to use blocks, but many of them are still using the older target/action mechanism or delegation where blocks would probably be a better choice. Lately, there’s been a bunch of projects designed to add block support to the places that Apple hasn’t (or has decided against) adding it.

That got me thinking: blocks are Objective-C objects, why can’t they act as the target, with the body of the block as the action? (Note: I’m not posting this up here as a suggestion that you use this (yet!), but as a way to ask if this makes any sense.)

Since I couldn’t find any documentation on what Objective-C class blocks are (except that they inherit from NSObject), I decided to add a category to NSObject to give me a selector to invoke the block with. To do that, I came up with -[NSObject startBlock], which ended up looking like this: (((void (^)(void)) self)());.

However, when I tried target:^{ NSLog("in a block!"); } action:@selector(startBlock), I got a crash, because the block was never retained (as targets shouldn’t be), so it no longer existed by the time -startBlock was called on it. Just copying it wouldn’t work, either, because it wouldn’t ever be released, and adding an ivar to release it yourself removed any of the advantages of using a block over an additional selector in the first place.

My next idea is when things got a little crazy. Associated objects (added in iOS 3.1) could get around those issues, since they’re automatically released when the object they are attached to is deallocated. I added another method to my NSObject category, -copyWithOwner:, that took advantage of that to force ownership of an object onto another object. Using that, I ended up with something that you use like this: [object addTarget:[^{ NSLog("block!"); } copyWithOwner:self] action:@selector(startBlock)], with the below code used to implement it:

@implementation NSObject (BlockTargetAction)
- (void)startBlock {
    (((void (^)(void)) self)());
}
- (id)copyWithOwner:(NSObject *)owner {
    // copy ourself to the heap
    self = [[self copy] autorelease];

    // this key is unique until self is deallocated,
    // so it should last as long as the owner does
    void *key = (void *) self;

    // automatically released when the owner object is deallocated
    objc_setAssociatedObject(owner, key, self, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
    return objc_getAssociatedObject(owner, key);
}
@end

I’m not sure, though, that I’ve fully thought through all the possible implications of using this hack, especially the memory management aspects. Does this make any sense, or am I wasting my time?

Sliding UITableView Header Views

The “dickbar” (as Gruber puts it) may be the big news item lately, from my “Twizzler” to remove it to the various websites springing up about it. But, this post is about something much more mundane and technical in Twitter for iPhone: sliding headers for UITableView.

When you first open Twitter for iPhone, you get this screen. Looks like just a standard UITableView and a custom -tableHeaderView set, yeah? Not quite. There’s actually an interesting effect here: when you scroll, the header actually slides under the table view. If that didn’t make sense (and it’s not a good explanation, sorry) I’ve uploaded a video that demonstrates the effect:

Read More

Moving to Micro USB?

Today, some people began receiving the first of the new, streaming-only, Apple TV. Engadget has a nice review of the device itself here, but the most interesting thing for me was in the ports on the back. It wasn’t the HDMI output, or the Ethernet jack, but the small, unlabeled Micro USB port.

No iOS device, until this one, has had a Micro USB port, especially not one used for restoring (or communicating with iTunes at all). However, that may soon be changing. The new European “universal charger” will require all smartphones sold there, including the iPhone, to use a Micro USB charger rather than the explosion in proprietary chargers we’ve been seeing.

The Apple TV may very well be preparation for what is coming soon for other iOS devices. While it’s not required for any devices outside Europe, Apple has been hesitant, to say the least, to have physical differences in their iOS devices in different regions, so the rest of the world’s devices will probably be moving to Micro USB as well. How this will impact the design — and third part accessories — still isn’t known, but we do know that some major changes will have to be made, and this new Apple TV may be a way for Apple to test those out in a much more controlled environment.

(Unrelated note: I do plan on posting more often to this blog. Maybe if I set a once-a-week post schedule, I can actually keep to it and keep you guys more up to date.)

Update November 2011: Looks like Apple released what they plan to use for Micro USB support. Lame.

iOS 4 Status

None of my apps so far run on the new iOS 4. This is because my iPhone 4 and my iPod touch 3G just don’t have an available jailbreak running iOS 4, not because I have abandoned my applications.

Once a jailbreak is released, I will work to quickly update Infinidock and Infiniboard. These are my paid apps, and I will support them at least through iOS 4.1, and likely longer. Preliminary support is already in place (my internal versions aren’t complete, but don’t crash), and a full update will come reasonably soon after my devices are jailbroken.

ProSwitcher is a different story. Personally, I prefer the multitasking switcher that iOS 4 introduced, although I understand that many of you prefer the Palm webOS/ProSwitcher interface. I have decided that I am not going to continue updating ProSwitcher past OS 3.2, a version compatible with which is currently in Alpha. Ryan may still update ProSwitcher himself, but I feel that it is no longer necessary with the new Apple release.

Finally, there is Pulldown. I was originally planning to release this as a paid tweak, but I think I will just post the source code to my GitHub soon and try to find a maintainer to have it as an open source project. If any developers are interested, please contact me via email or Twitter, and I’ll see what I can do.

A Blog!

I’ve never managed to keep a blog going beyond just a few posts before. I always have these great ideas for blog posts, and I’m sure they would be great, but I no longer have the inspiration when I’m just sitting at a computer. Maybe I’d just rather be coding, not sure.

But I’ve decided that for the iPhone scene, I want another blog. I can’t promise that I’ll do any better than I’ve done in the past, but I’ll try. I don’t know if anyone even wants to read what I have to say, either. But hopefully this will give me somewhere to rant besides annoying everyone on IRC.

If I do get around to posting here reasonably often, expect to see both technical and non-technical posts. Maybe I’ll make categories for the two, who knows. Hopefully it’ll all be interesting, but again, I haven’t been too great about this in the past. Maybe I should just stick with Tweeting: there, I can post what I’m thinking about while it happens. Then again, maybe that’s not the best either.

Now to find something to talk about.