Adding apps to a hacked iPhone - how to compile?

[nagromme]

I'm sure people will eventually hack the iPhone and modify its contents, just like they've done with iPods and Apple TV. I enjoyed re-skinning my iPod UI in red, and plan to dual-boot Linux on it too. Real OS X devices like Apple TV and iPhone have even more potential for inventing fun new uses that Apple tech support won't help you with

That said, I see a choice of TWO different philosophies in making such a device:

1. Make a flexible PLATFORM. (Advantage: much larger ecosystem of 3rd-party software. But some of them will crash or work differently from each other in confusing ways.)

2. Make a rock-solid APPLIANCE. (Advantages: stability and interface consistency: it "just works"--the way an iPod does and computers don't always. Any 3rd-party additions go through Apple, so they're small in number but high in quality.)

Both ways DO have their merits. I'm sure most of the public would want #2 in a PHONE, and that's the direction Apple has gone. I agree with the choice. Make a very capable device but NOT a full "pocket computer." Keep it rock-solid, stable and secure, without a hodge-podge of add-ons disrupting the usability that makes an iPhone stand apart from everything else. Without add-on apps failing in ways that reflect badly on the device. And most importantly, with #2 Apple can update the device more quickly and easily, adding new features or tweaking the UI--and even releasing new models or screen sizes--without fear of breaking 3rd-party apps.

However, some of us are willing to accept a little chaos on our phones, and want #1. We DO want a fully-flexible pocket computer, able to do "anything," more than we want top reliability or security. And if the Apple TV is any sign, Apple will allow us to have it! But we'll be on our own, unsupported as we hack the device to our liking. Maybe even installing apps that Apple never approved?

So I'm wondering, technically, how this might be done.

Ars Technica seems to have good reason so speculate that the processor(s) in iPhones are ARM, possibly by Samsung, but not XScale. (Anyone have newer links with more info? That's the best I could find.) In other words, OS X (in some form) has now been ported to run on THREE different chip architectures--as best we can guess right now.

ARM is neither PowerPC nor x86 compatible. So as I understand it, current Mac apps CANNOT possibly run on an iPhone even if you hacked the unit to get the files installed. No matter whether they are PPC, Intel, or Universal, they're not compiled for ARM and will not execute (short of adding slow emulation software). Apps would have be PORTED to iPhone and a new architecture. Am I correct?

And without source code, you can't port or recompile--so we can forget about adding existing apps unless they're open source or the app's DEVELOPER chooses to make it happen, right?

But in cases where source code IS available, I'm wondering what would be needed in order to port an app to iPhone and ARM?

What would the tools be? Would we need a custom ARM-ready version of Xcode that only Apple has? I'm interested in any theories.

I'm guessing we'll only see two kinds of iPhone apps:

A) Apple-approved, Apple-guided, Apple-tested. Not necessarily all BY Apple--iPod games aren't--but probably all sold through Apple, and maybe some included free with periodic software updates.

B) Open-source projects for hacked iPhones. Because selling a COMMERCIAL product for a hacked, unsupported platform sounds like asking for trouble--it could break with any iPhone update, with no recourse.

Assuming the chip(s) are ARM, I'm wondering how easy B will be. Any thoughts?

 

[Eraserhead]

You've got your numbers the wrong way round .

 

[pilotError]

Well...

There is a Gnu gcc compiler for the Arm chip. Arm has been around quite a while and is certainly not an unknown quantity. You can find Arm chips in quite a number of devices from phones to some of the Nintendo stuff if I remember correctly.

The libraries would require a re-compile with a target of Arm with the gcc compiler, so theoretically, you could cross-compile from a Mac and deploy on an iPhone. I would think Apple would have to deliver the cross-compiler environment though since you would have access to the Apple Librararies. I not sure if an open source version of the cross-compiler exists for OS X.

 

[nagromme]

I should further divide it into two methods:

* Linux apps when someone gets Linux going on an iPhone. (Just like has been done with most iPod models. iPods use dual-core ARM processors.)

* What we REALLY want--OS X apps. (But accessing them would depend on modifying the iPhone system software to add a new menu, or modify an existing one, and that step may or may not be practical.)

I'm interested in how to achieve the latter.

You've got your numbers the wrong way round .

That I did! Fixed Thanks.

The libraries would require a re-compile with a target of Arm with the gcc compiler, so theoretically, you could cross-compile from a Mac and deploy on an iPhone. I would think Apple would have to deliver the cross-compiler environment though since you would have access to the Apple Librararies. I not sure if an open source version of the cross-compiler exists for OS X.

So in theory you'd need an ARM compiler, which is available--but specifically one which supports Apple Libraries, which may not be available?

 

[Eraserhead]

I think this sounds really interesting, but as we personally don't know what the situation is of the iPhone (or even who's chips it uses) we are stuck. Personally I don't see why running dashboard widgets on the thing would be a problem, I suspect that is the sort of application initially that you will run on the iPhone, much like Java applications on current phones. If you are allowed to it makes dashboard make more sense as it's not particularly useful on a computer, but if it worked on iPhone, it would give the iPhone more software than most other smart phones.

 

[nagromme]

Personally I don't see why running dashboard widgets on the thing would be a problem, I suspect that is the sort of application initially that you will run on the iPhone, much like Java applications on current phones.

Good thinking, especially if Flash makes the final feature set. (Which it had better, for the sake of popular web sites... like Apple.com!)

Widgets (maybe not quite Dashboard but an iPhone-sized variation) could be the most likely area Apple would open the phone up to for un-approved 3rd parties. Or if not (since concerns of a widget failing or being weird to use remain), then at least they'd be the most fertile ground for hackers, since they can be interpreted rather than compiled.

Another avenue: the Notes application and/or iPhone Safari.

The iPod Notes reader can interpret a very limited HTML-like hypertext format, including image links. The iPhone may well have the ability to view FULL HTML documents stored on the device, either via a Notes folder or by browsing its own HD in its Safari.

If that's the case, then JavaScript (and Flash?) applications could be accessed through Notes or through your bookmarks, with no need to be online.

Failing that, WORST case, you could run JavaScript/Flash apps online off of a server. It's not what people would want from custom-app capability, but it would be a nice benefit of the iPhone's full "desktop class" browser.

(I hope the iPhone Flash support isn't limited to Flash Lite like other phones--that would break some pages and be very limiting.)

 

[nagromme]

Also note, as posted by Evangelion in this thread, that not ALL of OS X is on the iPhone (that would waste a ton of space).

So apps would need to be modified by the developer to not depend on any "missing parts." Probably a difficult task in many cases.

But look at what people have done with Linux on the iPod real "Mac" apps may never come to iPhone, but SOME kind of custom hacked apps probably will.

 

[savar]

You're correct: PPC and x86 apps will not run on an ARM processor without being recompiled or running on an emulation layer. The latter sounds overwhelming for such a small device, so the former is probably the best option.

If the iPhone is hypothetically running full OS X, then all you would need to do is:

1) Get ARM versions of any static libraries you want to use, as well as ARM stubs of any dynamic libraries.
2) Compile your source code to ARM target.

Of course, the iPhone likely isn't running full OS X, I would imagine, since there's tons of stuff a phone would never need to use. Conversely, the iPhone has some features (notably interface widgets) that the desktop OS X doesn't seem to have. So I'm guessing there are some special libraries for making iPhone applications that won't be available to developers.

In theory, we could copy the libraries off the iphone onto a Mac and try to reverse engineer the API.

I think the more likely scenario is that in about 12 months Apple will start to let 3rd parties under the hood. As far as I can recall, there were no iPod accessories for sometime after the iPods initial release (not counting generic audio products packaged as iPod accessories), but eventually Apple let a few select developers into the circle of trust and we got the direct recording gizmos and the flash memory card reader, etc. Now we've got some 3rd party games even.

Apple needs to stablize the platform first, then they can let others join the game. I seriously doubt there be a public API for the iPhone anytime soon, just as there is still no public API for the iPod.

 

[whooleytoo]

Until we get our hands on iPhone devices, no one can tell how hard it will be to write 3rd party software. My guess is any well-written Mac app (that makes no presumptions about the hardware it runs on - minimum screen size or aspect ratio, type of persistant storage etc.) would make a fair attempt at running if re-compiled with no code changes needed.

Of couse, we know little about the iPhone OS, but it makes sense that Apple would re-use existing frameworks from the "full" OSX as much as possible. Of course it has no menubar, but Cocoa apps don't normally explicitly set their own menubar anyway - it's done by the OS from the app's nib file. I suspect the app would launch without a menubar - but obviously much functionality wouldn't be available.

All speculation I know, but it's interesting.

That said, I suspect Apple has no interest in enabling 3rd party applications - not as we know them now. I reckon it's far more likely they'll push the iPhone as an always-on, web/Flash client. Considering how powerful Flash is these days, that still gives developers a lot of power & flexibility.

 

[buymeaniphone]

Call me a Weenie, but I don't think I'd want to hack into a $600 device. If something goes wrong and it really gets jacked up then you'll just be left with a nice looking paper weight. Although, I'm sure you could still get someone to bid on it on e-bay .

 

[nagromme]

You... you weenie!

I'd let others take the risk before I did... and it depends on just HOW much hacking is needed. (There's only so far I will go.) But software hacking can usually be reversed by a reformat/restore operation--so while Apple would not support your efforts, they would not necessarily void your warranty in the event of unrelated hardware failure. Firmware hacks would be the riskier sort--and anything that requires disassembly or physical modification would be unwise! (But some will do it anyway )

Note that Apple does not seem to support OR punish Apple TV software hacks:
http://www.engadget.com/2007/04/05/apple-not-fighting-back-against-apple-tv-hacks

See also http://www.appletvhacks.net

(Plus it's only a $499 device )