The iPhone is an island. A commercial, maximum security prison island with each and every data entry and exit very tightly controlled and tolled.

Apps can only be installed from Apple’s official app store after Apple has reviewed the app. One of the many things Apple checks when it reviews an app is to ensure the app does not leak data in a way that Apple or AT&T can’t profit from (Apple approves, pulls flashlight app).

Apple takes a cut from your app purchase. Free apps typically come loaded with ads which are served by Apple so it can take a cut there as well. The iPhone’s connector is a patented Apple design that can only be bought from Apple at a hefty price. iPhone accessories that communicate with the iPhone, speaker systems for instance, need to have an expensive Apple supplied authentication chip so the iPhone will agree to communicate with them. The iPhone’s Bluetooth capabilities are gimped to ensure no untolled data sneaks in or out of the iPhone. As a result, the iPhone works with Bluetooth headsets and can communicate with other iPhones over Bluetooth and little else.

In some sense, the iPhone is an irony. It’s the first true general purpose palmtop computer and universal communications device which can’t be used for very much computing or communication outside of Apple’s kid size prison cell.

So what does this have to do with LEGO NXT?

Well, I found a tiny little crack in the data prison that doesn’t require jailbreaking the iPhone (or iPod). It still requires the use of undocumented APIs but I find that more convenient than jailbreaking, as easy as jailbreaking has been recently. I managed to coax the undocumented Bluetooth facilities in the iPhone to let it communicate with a LEGO NXT brick.

Here’s a short unexciting video showing the two in action.

First Post.

The iPhone and LEGO NXT seem like a natural fit. The NXT can control motors while the iPhone has a lot more computing power, additional sensors and communications built in (camera, accelerometers, gyroscopes, microphone, speaker, Wifi and cellular connectivity). They also both have Bluetooth so getting them to communicate should be easy, right?
No, not really. Apple, in its infinite wisdom, has decided to lock down the iPhone in myriad bizarre ways. One of those ways is to hobble Bluetooth so that it is practically useless for anything other than ear pieces and playing games with other iPhones.
Well, not for long…. I hope…

Camera FX! was approved by Apple. Hopefully, it will get noticed a little bit…

It is available in Apple’s app store here:

http://tinyurl.com/3azu5r5

Promo Dispenser appears to be a good idea. Basically, for the developer, it ensures you get a review for every promo code you provide through the service. It does this by letting users download additional promo codes only after they have left an app store review for the previous app they got a promo code.
So far I’ve uploaded 5 promo codes each for FlashMaster and Flashlight 4.

The website does not appear to be too well known which is surprising as the idea seems solid. Solid enough that I think Apple should provide such an option as part of their promo code generation. If the developer chooses his promo code should require a review.

We’ll see how this experiment turns out…

Once I got the e-mails from Apple informing me that Apple “would require more time” to review the Flashlight 4 and FlashMaster apps I was convinced they were bound for rejection.
This morning I was pleasantly surprised to receive to approval notices from Apple and a request to add this notice to the app marketing texts:

Note: Continued use of the flash may dramatically decrease battery life.

Now have a twitter account with latest updates. Follow @xysternet

Free Mirror was approved by Apple today. It uses iPhone 4′s front facing camera to act as a magnifying mirror.
It is available, for free, here:

Free Mirror in App Store

Inspired by the Android linpack top 10 chart I set out to compile the linpack benchmark for the iPhone and try it on the 3G and 3GS. What I found surprised me.

I used a C implementation of the linpack benchmark from www.netlib.org to create the app.

To be clear, I don’t really know what the Android Java linpack benchmark is doing and how it relates to the C implementation I used so I have no idea how the numbers I got compare to the Android numbers. It also appears some of the reported Android numbers were manipulated by some users as a prank so it’s difficult to tell what is real and what is not.

That being said, what’s interesting is not the performance difference between iPhone and Android, especially since the Android phones are newer than these iPhones models and Apple will announce a new device tomorrow which should be viewed as a comparable competitor to the latest Android phones. With any luck, I’ll benchmark the new iPhone in the near future. What I find interesting is the performance differences between the 3G and the 3GS.

I ran the benchmark on a 1000×1000 matrix (see the linpack benchmark documentation to read about this) both in single precision and double precision modes with what I believe are the fastest code generation settings for the two devices.
I also have iPhone OS 4 Beta 4 installed at the moment which may not be ideal for performance testing as Apple beta’s can sometimes slow things down. Also, the multitasking in iPhone OS 4 on the 3GS may have an effect as we’ll see below.

	Double precision	Single precision
iPhone 3G	20.6 MFlops	28.5 MFlops
iPhone 3GS	18.2 MFlops	27.3 MFlops

And there you have it, the 3G and 3GS have essentially equivalent floating point performance. The 3GS actually shows a 10-12% disadvantage but this could be a result of the beta OS or the increased multitasking that occurs on a 3GS. I would guess they are essentially equivalent.
Based on these numbers it appears that the 3GS’ speed advantage over the 3G is strictly in the integer realm. Floating point performance is the same.

Update:

I’ve run the benchmark on an iPhone 4. Here are the results:

	Double precision	Single precision
iPhone 4	20.9 MFlops	36.2 MFlops

iPhone 4 has somewhat better single precision floating point performance while double precision is the same. This benchmark does not explicitly utilize the ARM NEON SIMD instructions available through the Accelerate framework. Apple claims (in their WWDC presentations) that NEON can provide an up to 8x performance gain for single precision floating point operations. So that 36.2 MFlops figure could be significantly improved by modifying the code to use iOS4′s BLAS libraries (assuming the very optimistic full 8x speedup that’s ~290MFlops!). NEON does not support double precision operations so those are relegated to the ARM VFP which has the same performance as the 3G/3GS devices.