Xblaze

I’ve received a few emails asking why apps crash more often on Jailbroken iPhones. So I’ve collected my thoughts and written down a number of reasons why Jailbreaking is a pretty bad idea.

• Jailbreaking Allows Background Apps
  • Extra strain on the CPU
  • Extra drain on the battery
  • Heavy consumption of available RAM
  • Usage of your data connections (this might incur costs that you’re not aware of if you’re not on an unlimited data plan)
  • It’s impossible to know what the background apps are doing, if they request more resources and can’t get them because Xblaze is using the available RAM, maybe they’re written to kill other apps and take the memory for itself? No-one knows, except the developer of that app, and since Apple don’t approve these apps, they could be doing exactly that.

This reason alone is suspect enough to be a big cause of concern for people running Jailbroken iPhones. People forget that the iPhone is a mobile device, because it is so capable. It’s important to remember that the iPhone does have a very small amount of RAM compared to laptops and other computers. The iPhone was not designed to run many apps at the same time – this is why Apple restrict it to one 3rd part app at any time. They didn’t do it just to annoy people…

If there are several apps consuming vast amounts of RAM already running on the device (this include ssh servers, themes for springboard, notification apps, etc) then what hope does a legitimate app such as Xblaze have of surviving? Those not familiar with the iPhone SDK and how the iPhone works, may not know that the iPhone OS will kill an app if the device starts to run low on memory. Non official apps may be able to be coded in ways that ignore these warnings, forcing the OS to kill the legitimate apps that can’t ignore these warnings.

The result is that Xblaze will simply quit if there are low memory conditions on the iPhone it is running on, and since Xblaze only consumes a mere 4MB of RAM while running, the jailbroken iPhone would have to be using almost all the RAM before Xblaze is even started, which is actually quite likely considering some jailbroken apps such as themes that are rich in graphics and sounds.

• Modified Frameworks
  • Changes the expected behaviour of the iPhone so that a legitimate app will crash while trying to access a function or class that has been modified by anyone but Apple.
  • May cause the app to not even launch if the required APIs aren’t available at launch time.

When writing an iPhone app, a developer is given a set of Frameworks which allow them to access the iPhone’s functionalities, user interfaces, etc. Think of them as hand grips on a climbing wall. You need them to hold onto to be able to reach the top. If you tried to grab as hand grip and it wasn’t there, you’d fall. This is exactly the kind of thing that can happen to an application that relies on a framework being in the state that it was originally in when released by Apple. Changing these frameworks simply breaks any app that requires them. And once again, since it’s impossible to know which frameworks have been changed or how they’ve been changed, developers simply can’t program their app to work in that environment.

• Inter-Process Access
  • Jailbreaking an iPhone removes all restrictions. One app may be able to access the insides of another app.

If any malicious apps decide to snoop around the memory space of a legitimate app, anything could happen, ranging from the app crashing, due to memory corruption, to having something like your password and personal details stolen… Is that something you’re willing to risk? All restrictions are removed on a jailbroken iPhone – if you’re checking your online banking through Safari, what is stopping any malicious app from stealing your account details and forwarding them on to identity thieves? Are you happy with the possibility that your xfire password may not be safe when running Xblaze on a jailbroken iPhone, because there’s nothing I can do to protect it if it is. On a legitimate iPhone, Xblaze stores your password, encrypted using an SHA1 encryption algorithm, safely inside the iPhone’s Keychain (the same way passwords are stored safely on Mac OS X). The keychain can be accessed freely by any application when running on a jailbroken iPhone… Consider it carefully.

Unfortunately, due to the shady nature of jailbreaking iPhone devices, it is impossible to say whether any of this is 100% accurate, but I know I’d rather err on the side of safety, stability and security when it comes to my personal data, my entertainment and my overall mobile experience…

The truth to the question “Why does jailbreaking cause more crashes than normal?” is that I simply don’t know. If I knew, I’d be able to prevent it…

It’s 5:08am. I’ve just committed the typing notifications code to SVN. Sleeeepy.

I’ll release an update tomorrow at some point that will include the typing notifications support.

The incoming typing notes, (those that tell you who’s typing), were simple. A few short lines of code and they were working. But the outgoing typing notes, (those that tell your friends when you’re typing), were a lot more involved. The MacFire library didn’t have a packet to represent a typing notification, so I had to write one before writing the logic to send it.

I also learned something a little odd about the way Xfire handles typing notifications. According to all the documentation I’ve read about the Xfire protocol, the typing notification packet is the same packet that contains messages and message acknowledgments. The difference between these packets is the data structure within, their IDs are all the same. With that said, the typing notification packet contains a field aptly named ‘typing’ which represents an integer.
The documentation says this is treated like a boolean, 1 for typing, 0 for not typing. So my initial inclination was to send the packet with a 1 when a user is typing, and then again with a 0 when they finish typing.
I was wrong. This caused the typing notification to keep being displayed even after a message was sent. My only guess is that Xfire (for Windows) ignores this boolean value, and just assumes that any typing note packet that arrives means that the user is typing… Either that, or the field isn’t intended to be used as a boolean. We shall most likely never know.

Good night.