The app will hopefully be reviewed and released in 4-7 days.

Hopefully after the release of Xcode 4.2 and iOS 5 my release cycle will have a more stringent testing procedure! For those that don't know the released Xcode 4.1 can't run debug versions of an app on iOS 5 and Xcode 4.2 can't bundle iOS 4.3 release versions.

So I have modified the TWIS app and resubmitted it.

I had heard that the review process for app updates was prioritized over that of new apps but this was a little ridiculous:
July 15th: app submitted to Apple for review.
July 21st: app enters "in review" state
July 22nd: app rejected
July 22nd: app rejection being appealed
July 26th: appeal being reviewed
August 2nd: appeal rejected - spoke with the non-Jobs Steve
August 3rd 8:22am: app update submitted to Apple
August 3rd 8:23am: app enters "in review" state.

-- Updated August 3rd 2:30pm

August 3rd 2:03pm: app enters "processing for app store" state
August 3rd 2:17pm: app is Ready for Sale

You can find the TWIS app in the App Store

11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy" button that goes to a web site to purchase a digital book, will be rejected.

I have appealed this decision as this provision is intended for in app purchases but the TWIS app does not do any in app purchases it has links to Amazon, iTunes and iBookstore so that the user can easily find the books that are read in the TWIS Book Club.

 http://gldis.ca/twis/

Overdue. What more is there to say? I hope the release of iOS 5 coincides with WWDC as I'm already getting tired of the current iOS notifications and I've only had an iOS device for just over a month.

Apple switching to Arm from Intel

I can see Apple making such a change. Apple likes to control the as much of the supply chain as they can. It allows them to tailor the hardware to their vision. That's why they made their own Arm processors for iOS devices in the first place.

Arm processors are quite often destined for the embedded market. They are quite often much lower Mhz than Intel desktop processors and have much smaller bus widths. This often limits their performance when compared Atom processors in such devices as NAS appliances. Reviews of such devices over at Small Net Builder demonstrate the limitations of such embedded systems and with these chips in mind it's obvious that Apple would never use them in their laptops or desktops.

But Apple wouldn't be using *those* Arm based chips in their laptops/desktops they'd be using their own Arm based chips. Arm has designs for 2Ghz dual core Systems on a Chip (SoC) that use 1.9 Watts. That's an absolutely tiny amount of power consumption compared to the Intel Core 2 Duos that are currently used in the MacBook Airs. Apple used to have some measure of control in their CPU designs back when they were involved with IBM and Motorola in designing the PowerPC chips. Steve Jobs would no doubt want that control back. Apple could conceivable make their own Arm chips that had the I/O bandwidth they required. Normal desktop usage doesn't require a super powerful general purpose CPU. How much CPU is required to input text into a text editor or display a website? Not much. While other systems typically perform all their necessary crypto or audio/video encoding/decoding on the general purpose ARM is a complete System on a Chip (SoC) that would include these co-processors in the same package as the ARM CPU cores. 

Some people have argued that Apple wouldn't switch from Intel chips after investing so heavily to make the switch so recently (announced in 2005, completed in 2007). But that is bullshit. Apple has switched their CPU architecture before. 3 times! From the 6500 to the 68k, from the 68k to the PowerPC and then from PowerPC to Intel. Apple has more experience performing CPU architecture changes than anybody and this time they'll be even better situated to perform the change on some of their systems thanks to the Mac App Store. In previous transitions Apple used Fat/Universal Binaries that would contain the programming instructions for both the old and new architectures to manage the transition. This time, using the Mac App Store, software vendors would simply upload both to the store and then the app store would decide which version would be needed for the users' system and only download that one. Easy.

Some have stated that Apple wouldn't make a switch to ARM until there was 64bit support in the ARM architecture. Apparently these people are unaware that the MacBooks and MacBook Airs with their limit of 4GB of RAM do not come with support for 64bit kernel and drivers.

Having the same CPU in the iPhone, iPad and Macs would bring a savings in hardware costs as they would benefit from the savings that come with mass production. It's even conceivable that the Macs could use multiple A(5,6,7,whatever)s to to meet the higher processor performance expectations of Apples laptop and desktop systems. I don't expect that current Apple ARM based processors are ready for the Mac Desktops or MacBook Pros, but perhaps the 11" MacBooks in Apple's version of a netbook. Too bad Netbooks died just like windows based tablet's died long ago. *snicker*

The best time to deploy new Arm based laptops would be with a new version of MacOS. With expected MacBook Air announcements coming in June as well as the expectation of MacOS Lion it wouldn't surprised me at all if the smaller MacBook Air is announced to be ARM based.

Since the news that Apple ordered 12 Petabytes of storage there have been rumours of Apple starting a music streaming service. Apple's not known for making just another example of a given product. To think that the Apple would make a simple music streaming service is a disservice to Apple.

The current model of iTunes is one where a desktop is the master of the user's media while ipod/iphone/ipad are all slave devices that are given a subset of the user's media. What if the master media management role were moved to the cloud? Then MacBook Airs with their limited SSD hard drive capacity could have a subset of the media library. Podcast subscriptions would be synced between devices allowing travellers to take only their iPad or low hard drive capacity MacBook Air and be able to download any new podcasts to their portable device instead of the home desktop. Downloading media such as podcasts or movies could be done once to a any of the slave devices and then synced between slave devices. iPads/iPods/iPhones could be used without a PC at all (this is the obvious result that has been discussed by others) allowing the devices to get software updates over the air. 

Currently my iTunes library is stored on a file server at home as it's 300GB's is way too much to fit on my MacBook Air's 128GB capacity SSD. This situation utterly prevents me from accessing my library while travelling as the data IO required would make a vpn to access it somewhat painful. Having the iTunes library file and some or all of the media in the cloud would resolve this issue nicely. If, instead of having the media library in the cloud, Castle only have the iTunes metadata library in the cloud this would still allow multiple devices to have and manage a subset of the media files and sync podcast downloading between devices as well as possibly allowing user devices to stream media data between themselves over the network/Internet.

Don't forget that iPhoto and other apps that sync with iOS devices, they could also be part of the Castle cloud service. Will Apple allow iOS/Mac developers to access/store misc app data in this cloud service? Being able to sync between iOS versions of apps and the Mac desktop versions could be very beneficial to some app developers allowing them to provide such synchronization without having to invest in their own server solutions but to use the user's cloud storage instead.

Eagerly looking forward to the announcement of Castle.

Some of the announced API changes for Honeycomb look interesting, however since there are no Honeycomb devices there's little point to getting to worked up and re-writing any apps just yet. Fragments look very interesting though.

Makes me wish that Android development followed a more BSD-style development model with Stable and Current branches.