First, woah, I’m posting.

Second, I think it’s time to look at what Apple may be announcing tomorrow, based on rumors around the internet and my own wild hopes and dreams. I’ll probably be completely wrong, so don’t go making stock decisions on this stuff.

iPhone Software Update – Definitely

The iPhone 1.1.3 software update is definitely expected to be released tomorrow (or at least formally announced). There have been several probable video leaks of the new firmware update, and even rumors that newer internal versions include copy/paste. These rumors are very logical next steps for the iPhone, given the impending SDK release and the need for more interaction for specific apps. I think a software update given the SDK is pretty much assumed to be happening, so I won’t spend any more time on it. But speaking of the SDK…

iPhone SDK Details – Definite

It may be Macworld, but Apple is growing far too diverse to limit Apple’s announcements to purely Mac stuff. Steve is going to spend some time talking about the details of the SDK for reasons I’ll illuminate in a moment. However, since the details are being released at an open trade show, and not behind the veiled curtain of WWDC, that means they’re going to be crowd-pleasers. So, I’m suggesting that the model will be open where anyone with a copy of Xcode can start building apps. No major details are going to be released (will there be developer tools for Windows developers, in the form of Visual Studio, Eclipse, or other tools? Is Apple porting Xcode to Windows? Will there be an iPhone emulator? How will you do testing on a physical iPhone? etc.), but you can be sure that there will be a business model involved, and it’ll almost certainly go through the iTunes Store.

As an aside, I’m going to predict right now that independent apps on the iPhone will have some sort of sandboxing that will restrict them from writing to the filesystem. To read/write data, they will need to use a database that’s local to the system or the process (most likely SQLite). One of the biggest advantages to this approach is the security that it provides, at least to Apple/AT&T. Since all of the UNIX underpinnings of the iPhone rely on using files, there’s very little possibility for files to get overwritten with malicious data. If nothing can write, then you can’t have a problem. This also starts pushing developers towards moving towards database development, which I’ll talk about later.

That being considered, Apple hasn’t had much time to write their own new apps, as they’ve been clearly busy finishing the SDK. Which is why they’re providing details now. Because, this way, they can announce…

Major 3rd-party iPhone developers – Definite

Expect there to be some major companies bringing some awesome new apps to the iPhone. Specifically, I’m predicting Twitter (partially because the CEO was quoted by, well, Twitter, as having said that he’s ”looking forward to a big week”) as a certainty. I think they’ll probably partner mostly with companies who provide Internet services, as Apple no doubt wants to push the connectivity options of the iPhone. With that in mind, I’ll predict Fandango (buy tickets on your phone!) as one of them, and Last.fm as another one (mobile scrobbling!), but there are a lot of services that apply. I’m guessing they’ll also probably want some gaming on the iPhone, and will have partnered with PopCap or, hey, maybe the Iconfactory. That would stir the crowd up in a Frenzic.

iPhone Hardware Update – Very unlikely

No hardware update is going to come for a while. Too many iPhone announcements would suck too much time out of the rest of the show.

iTunes Movie Rentals and on-the-DVD video files – Definitely

For crying out loud, the proof is all over the place. People are already even receiving DVDs with iTunes files on them. It’s happening.

Existing Mac Hardware Updates – Definitely

Well, duh. They always update some of the models. We’ll say the Mac mini and the iMac will get updates, as they were last updated at the event in August. Also, the MacBook Pro will definitely get a big bump, and will probably be the one that steals most of the time for the current Mac lineup. At this point, Steve will probably start talking about how their laptops are outselling their desktops, and it’s because people want to go more and more mobile in an ever-increasing way, and we here at Apple want to make that whole ecosystem work better, and so we’re going to announce some new products today…

Thin MacBook (MacBook Air) – Definitely

This is the big daddy of the rumor mill; the really, really, really, really, really, really, really thin MacBook. This device has been all over the rumor mill, with all kinds of mockups and photoshoppery being passed off. But I think there’s so much evidence at this point that it’s a certainty. I’m still unsure as to if it will replace or supplement the existing MacBook. My predictions on the thin MacBook:

• Core 2 Duo processor, with two models: 1.8 GHz and 2.0 GHz
• Intel X3100 Integrated Graphics
• 1 GB 667 MHz DDR2 SRAM, upgradable to 4 GB
• 32 GB Flash hard drive, upgradable to 64 GB
• No FireWire, 2 USB 2.0 ports, no ExpressCard slot
• 13″ display, 1440×900, 3 pounds
• Multi-touch trackpad, but not display, with the trackpad taking up the whole surface of beneath the keyboard
• 802.11b/g/n connectivity built in
• No EVDO or anything like it, no wireless induction power charging
• Priced at $1,299, with the beefier model at $1,599
• Black with a silver Apple logo. Period. That’s it.

Somehow, Steve would use his RDF magic to weave the keynote into a talk about mobile technology, and would talk about wireless networks like Wi-Fi. And then, the “one more thing” would come out, and be that which was in the air…

AirPort Digital Hub – Very Likely

The AirPort Digital Hub (which I’ll just call “the Hub”) is a new device that will be a souped up version of the AirPort base station and a NAS box. It will be a wireless router, but it would also act as a file server. It would include 2 mirrored 250 GB hard drives (with 500 GB models), as well as bays for extra hard drives. USB and Firewire ports aplenty in the back would provide external storage. The drives would mirror each other, using hardware RAID, but the user never sees it (although this would require adding two hard drives simultaneously; you wouldn’t be able to just add one). The data itself would be pooled using ZFS, and could be encrypted at the bit level. Combine this with the wireless router, which also happens to know about all of Apple’s networkable products, not to mention a way for developers to integrate with it, you’re talking about a home server that could keep your content in sync across every machine on the network.

Some possible uses for such a device:

• Automated Time Machine backups, encrypted and mirrored. You’re never, EVER losing that damn photo of the kids on that trip.
• One global iTunes database, where everyone in the family could contribute music to a huge pool and sync anything to an iPod. In fact, you could even sync your iPod from another computer on the network
• One photo repository for everyone in the house
• One calendar database, so I can remind my roommates that yes, the rent really is 3 weeks past due and you really do need to pay me
• Sharing files across the house network becomes a cinch
• Create your user account, log in anywhere on the network. Everything comes with you

In fact, properly done, the Hub could be coupled with .Mac. But, Apple can build off the premise of one of .Mac’s cooler features, Back to my Mac, to let you remotely connect to the Hub from anywhere. Oh, your laptop is in sleep mode at home, but you need that file while you’re in the office? Back to my Mac fails, because, well, the machine isn’t on. But “Back to my Hub” has that file (and, in fact, all the backed-up versions of it in Time Machine), and is always on. In fact, you could possibly set up a VPN server to run on the Hub and get access to every machine on your local network from remote locations. You could also create calendar events, and invite people to them (who don’t necessarily have .Mac), and they could accept or reject it, which would then update your calendar. Tons of possibilities of integration with .Mac.

In many ways, the Hub is an awesome mixture of bits of Leopard Server, Windows Home Server, Kerberos, rsync, and the old Apple finesse. But that doesn’t really reveal what it truly is. In a rare, one more, more thing…

Hub replaces the AppleTV – Likely

Oh snap! Turns out the Hub is actually a more sophisticated AppleTV! Steve conveniently forgot to show the back of the device, where the AV ports were. A more sophisticated version of the AppleTV firmware is up there, with integrated iTunes store a la the iPhone. Aside from that, I’m not really sure what else they’d do. However, I think the likelihood of the AppleTV and the Hub being combined is a great idea, and will give Apple some serious headway in the living-room computer space.

Apple Tablet! – Unlikely, but dammit I can dream

I definitely think Apple is going to release a new type of computing device this year, just not at Macworld. This device has commonly been called the “Apple Tablet”, although it is effectively a small notebook with a multi-touch screen. However, I’ve got pretty high hopes for what this device can be, so we’ll just call it the Apple Tablet for now. The Apple Tablet, not the Mac Tablet.

First, I don’t think this will be a tablet computer in the sense that Toshiba or Lenovo makes tablets. I think this device will fit somewhere in between the dismal failure of the UMPC and the dismal failure of the tablet, and will address all the problems that both have suffered. In the case of the UMPC, they’re very difficult to use, and yet they run a full version of Windows CE. The tablet is as large and heavy as a laptop, and just isn’t easy to write on without some effort. The Apple Tablet will be powered by OS X, have a screen size of somewhere between 7-9”, and weigh around 1 pound. I doubt it’ll have the tablet’s signature swivel-screen; instead, it’s just a solid, flat screen, much like the iPhone.

However, note that I’m calling it the Apple Tablet, and not the Mac Tablet. That’s because I don’t think this device will be a Mac. It’ll be powered by OS X, sure, but in the sense that AppleTV, iPhone, and iPod touch are powered by OS X – it doesn’t make them Macs. It’ll use Apple’s mobile device platform that they built with the iPhone, and extend it more onto this device. Of course, interface paradigms will have to change to take into account different screen sizes and use cases, but it’ll be a meld between the Mac and the iPhone. This means it’ll get to cherry pick some things from the Mac, and some from the iPhone. I firmly believe that Apple is trying to create a serious mobile version of OS X that can be used in all, or at least many, things that Apple makes that aren’t Macs. If that’s the case, then it’s plausible that Apple may be extending the idea of an SDK to the Hub, as well as to the Tablet.

So, since Apple is developing a mobile OS X for these devices, let’s look at where the three devices that Apple has released with it (iPhone, iPod touch, and AppleTV) differ from their Mac counterparts. First, there is dramatically less capability to edit and organize information (no ability to add IMAP folders in iPhone Mail, for instance). This is important for my second point: No user-visible file system. At all. Everything you see is organized into clusters of objects. Songs in the iPhone’s music player are physical files on the actual UNIX file system, but to the user, they are merely records. Same is true for calendar events, emails, contacts, and notes. The user never sees a file anywhere. My guess is that Apple is trying to move towards keeping the Mac the only place where you’ll ever worry about a file. The sacrifice comes in the fact that you can’t do as much editing on these portable devices.

In this sense, the Tablet will have an SDK similar to the iPhone. However, applications will have to store their data in a database instead of files. This is very important, because it effectively prevents developers from ever presenting a file-system to the user. If they do, it’s because they’re trying to hack the concept of files back into a database, and if you ever see an app doing that, you really need to run far away from it, because the developer has no idea what he’s doing. Even though this sounds really weird and foreign, it becomes very useful when you start to think about it. Even applications like Microsoft Word, which are completely tied to files, can be adopted to this architecture. The key is to present useful metadata to the user about the actual record the application is maintaining. Think about how Google Docs show you “documents”, not “files” for an idea as to how it would work. And as it turns out, this is a much better way to organize data than files, at least on a mobile device. iPhone has proven that much.

At a technology level, I think this thing will have a serious processor in it. Definitely an Intel x86 of some kind. A full multi-touch display with no keyboard other than onscreen. A pretty decent graphics engine (most likely Intel-integrated). If you’re detecting a trend, yeah, this is effectively a stripped-down Mac from a hardware level. Including all the connectivity options. Built in Wi-Fi, WiMax(?), and Bluetooth.

Oh, and a cell phone radio. Not just EVDO, but a full radio for making calls, doing text messaging, and everything else. It integrates with your iPhone if you have one, but attach a Bluetooth headset or use the built in speakers/mic for making calls (with voice dialing and spoken names when receiving a call).

That’s what I’m hoping for, anyway.

On June 11th, 2007, Apple held the WWDC Keynote where they talked about three things. Leopard, Safari for Windows, and iPhone apps. I don’t need to replay this for you all, but I will anyway – the Leopard announcements were for the most part rehashes, and Safari for Windows was simply fantastic news, both for users of Safari and for web developers. But the iPhone announcement definitely left a sour taste in many mouths, mine included. Not so much the lack of a true iPhone SDK, as I wasn’t really anticipating seeing that at WWDC (as hopeful as I was), but rather the buildup of the announcement.

One of those sour sour mouths is that of Wil Shipley, one of the founders of Delicious Monster. In his latest blog post, he decrys the idea of using JavaScript and Safari as a platform for developing iPhone applications. Many of his reasons, such as a lack of Keychain and difficulty in monetization, are valid. However, there are a couple things that I, as both a Cocoa and web developer, disagree with. Furthermore, it’s completely plausible that the iPhone SDK that we all want soooo bad will be something that runs in the iPhone’s JavaScript interpreter, which I’ll talk more about in a bit.

First, he spends a good time railing against JavaScript. Specifically:

JavaScript was thrown together by some dudes a couple years ago to make web pages kind of, like, do shit and stuff. It’s famous for being slow, hard to read, hard to program, and incompatible across different platforms.

This statement is pretty wrong on all counts, both with respect to JavaScript as a language and a platform for writing the client-side logic of iPhone applications.

1. Hard to read/write. JavaScript isn’t any harder to read or write once you get used to it. In fact, it’s arguably easier to read, as JavaScript’s method calling syntax is significantly closer to C than Objective-C’s is. Someone with experience can read a function like:

Foo.prototype.bar = function(baz) {
	var foobar = document.getElementById("ohsnap");
	foobar.style.backgroundColor = "black";
};

…pretty easily. Compared to the same ObjC method:

-(void)bar:(id)baz{
   id foobar = [document getElementById:@"ohsnap"];
   [[foobar style] setBackgroundColor:@"black"];
}

There isn’t really a readability difference. Once you get used to the prototype syntax in JavaScript, it’s completely a non-issue – and I went from knowing zero JavaScript to doing full OO stuff in less than a weekend.

2. Slow execution. This is mostly a per-browser thing (IE, I’m looking at you). And while I agree that, in generic web development, this is an issue, you don’t have to worry about any of that. Because the iPhone doesn’t run Firefox, Opera, or IE. It runs Safari, and specifically JavaScriptCore (which is part of the WebKit framework on OS X that runs as a JavaScript interpreter), which is the fastest out of any of them for most tasks.

Furthermore, the speed of JavaScript interpreters across the board (with the exception of Internet Explorer, as it’s pretty obvious that Microsoft, with Windows and Office, feels very threatened by web applications) is bound to increase significantly in the next couple years. With the rise of more JavaScript-heavy web apps, the optimizations should definitely continue as they have for the past couple of years. Stuff like JIT compilation of code will help a lot.

And all that being said, JavaScriptCore is already pretty damn fast. You can pull off some decent framerates with even full-screen animations on the iPhone’s version of Safari. It’s no Core Animation, but it’s usable.

3. Incompatible across platforms. JavaScript as a language is pretty standardized. The DOM bindings in the browsers are where the incompatibilities lie. It’s fairly easy to spot where to workaround browser incompatibilities.

And besides, if you’re not concerned with generic web development and are only focused on writing iPhone apps, who cares?! You’ve got one target, Safari. Period. You don’t have to do the cryptic tests, like checking for the existence of document.all, to determine what browser you’re running on.

Apple’s got a decision to make: it can try to fix all the myriad problems with developers actually trying to deploy non-free applications using AJAX, OR it can say, “Look, this isn’t going to be easy, but we’re smarter than hell, and we’re going to make a secure, tight, mini-Cocoa for the iPhone — this is our chance to start fresh and do everything right. No NSCells, everything animated, resolution-independent from the start, no CF stacks under and NS stacks, always garbage-collected, all database-driven…”

And now we come to the crux of my argument. Who’s to say that this new mini-Cocoa couldn’t be written as a set of JavaScript calls embedded in the interpreter? JavaScript is already all garbage collected. Apple could embed technologies such as Core Animation right into JavaScriptCore, so creating an animation with CA could be as simple as a couple JavaScript functions, exposed to John Q. Developer in a similar fashion as the window and document objects.

Here’s the kicker – since these functions and properties would be compiled into the interpreter, they would be running as native, (I’m assuming) Cocoa code, so any possibility of slowdown would come from the JavaScript lexer and not from the actual JavaScript code. Therefore, your only speed limitation is that of JavaScriptCore’s ability to quickly process code.

If Apple’s claim of security threats presented by Cocoa/Obj-C apps is real, then it completely makes sense for them to want to sandbox it. That’s not stopping them, however, from implementing an entire application framework into iPhone’s JavaScriptCore. Throw in SQLite storage and the ability to save the app to the iPhone’s app launcher, and you’ve got yourself a pretty rock solid, secure application platform. And it wouldn’t surprise me if this is the compromise that Apple comes up with.

Granted, there are definitely speed issues to contend with; Apple’s only got a 620 MHz ARM processor in the iPhone, so it may just not be fast enough. But languages like Python have much faster interpreters, and may be investigated rather than JavaScript. But if Apple really needs the sandboxing that something like Safari requires in order to open up to native application code, well, I’ll take what I can get.

Also, someone please tell Shipley that you can’t do “programming in AJAX”. 🙂

I wrote some crafty Javascript to dump out the contents of arbitrary objects in the DOM in iPhone’s Safari. After the jump is a list of what the iPhone’s got for window, document, and document.body. If you need more, let me know.

Safari on iPhone has a number of things that are NOT implemented. Here’s a list of things that don’t seem to work (and I’ll be adding more as time goes on):

• window.onmousedown
• window.onclick
• window.onscroll

• overflow:hidden
• position:fixed
• position:static
• -webkit-column-*

If you find any more, please leave them in the comments and I’ll add them to the list.

When I started this site in 2003, I didn’t really know what to do with it. It started off as a faux-blog, during the blogging revolution, but all I was trying to do was carve out a little hole in the Web where I could put stuff. Since then, it’s expanded to be a full blog, along with many other nice things, like my project showcase, my photos, etc. Up until now, everything’s been great.

But it’s time to give this blog some focus. So, starting immediately, this blog will be focused on the one thing I know best – software. Developing software for OS X, developing web applications, using software, designing UI, critiquing other software, etc. Apple software, Microsoft software, open source software, all of it. It’s the one thing that I’ve spent the last ten years of my life figuring out.

So what does that mean in terms of content? Well, I’ll be working to post more about those topics and more. I’ll also be working to clean up the archives to support this focus (nothing will be disappearing, but I will be moving a lot of it around). Also, I’ll be adding some stuff to the design of the site to facilitate it (such as last 5 reviews, iusethis apps, etc.).

I’ve been kicking this decision around for awhile, as is evident by my last two posts (on iTunes and Coda). I’m confident, though, that this is the best decision. This blog has never really been anything more than just a general soapbox for me to get on when the time comes, as seen by some of my more political posts, so I’m glad to actually be able to turn this into something that becomes more of a resource rather than just a melting pot.

Today, Panic released their first new major app in a long time. Named Coda, it’s a tool for serious web developers who want an Xcode-like tool for web development. It integrates a lot of tools into one app, which is a very nice thing. Unfortunately for me, Coda’s still missing a lot of what I need to make extensive use out of it, or enough to justify the $80 price tag. I’d like to point out the big 5 that are missing from Coda’s arsenal that would really make the app significantly more useful.

If you don’t understand the title of this post, don’t bother reading any further. If you do, here’s a nice regular expression that will, given an Obj-C source file (.h or .m), give you all of the method signatures. It should work in every case that I can think of, but if you’re doing anything involving weird types or preprocessor macros it should work.

iTunes was released on January 9, 2001, at Macworld San Francisco. It was a huge deal at the time. Like, really huge. The big deal Mac MP3 players at the time, well, sucked as music jukeboxes. They were just that – MP3 players. that left the organization up to the end user. So when iTunes came out and replaced SoundJam MP, it was not only revolutionary, but extremely welcome to those of us with large music collections.

However, iTunes 1.0 was more than just a rebranded SoundJam. It had a completely reworked UI. Gone were the completely horrific looking skins that accompanied it. It was a music jukebox, just like it had been advertised. And Apple made it dead easy to rip, mix, and burn. Suffice it to say, iTunes 1.0 was a pretty amazing app. But Apple didn’t stop there.

Microsoft’s Zune. I swore to give the Zune an honest look when it actually began materializing on the Internet. I wouldn’t be a Mac zealot for the sake of being a Mac zealot – I’d actually give it a fair and honest run through. Well, as it came out a couple days ago, a couple of my friends decided to each get a Zune at launch. Naturally, I got my grubby hands on it, and gave it a ten minute run-through.

I’m not impressed, but I am a bit worried. More after the jump.

Introducing Tubular, the brand new YouTube client for OS X. Why would you want a YouTube client? Simple.

• It’s pretty. Tubular was designed to have a simple, elegant, and out-of-the-way user interface that still manages to look gorgeous. With icons designed by Cyril Seillet and Tom Stoelwinder, and a user interface designed with the collective wisdom of dozens of people, Tubular is simply beautiful.
• It’s familiar. Anyone who has used iTunes will feel right at home with Tubular’s look and feel. We’ve taken the UI ideas given to us by iTunes and ran with them, producing a user interface that is intuitive and usable.
• It’s useful. Features like one-click iPod conversion and drag-and-drop playback really give Tubular incredible utility to anyone who uses it.

We’ll be unveiling more about Tubular in the next couple weeks. You can go check out the blog at TubularApp.com, where I’ll be posting updates periodically.