I think that it’s well-established by now that the majority of desktop software will move to the browser at some point. It happened to e-mail, calendar, word processing and many more applications already. But here’s a crazy idea: what if we move the server to the browser as well?

The past week I’ve been playing with socket.io in mobl, my language for developing mobile web apps. Socket.io is a library that greatly simplifies building real-time web applications — applications that keep a connection (a socket) open to the server, allowing the server to push content to the client and vice versa. It was pretty straight-forward to build a library enabling use of socket.io from mobl.

The first thing I built was mobl draw (only works in modern versions of Chrome, Safari or Firefox). The client code, written in mobl, is pretty straight-forward. It uses the HTML5 canvas and responds to touch/mouse events. When you click/tap and drag, it will draw a line at that position and buffers your movements locally. A couple of times per second it pushes the buffer of movements to the server. The server broadcasts the update to all other connected clients. The result: everybody connected at the same time, can draw together in real-time. A pretty cool demo. In addition, the server keeps track of the entire drawing history, resulting in a quick replay of all the drawing that happened when you first open the page. The client part of mobl draw is written in mobl, of course, but the server component (albeit small) is written in server-side Javascript, using node.js.

I've decided to create a second blog at http://jeff-lamarche.blogspot.com where I'll put any posts that are not related to writing iOS software, Apple, or the mobile software industry. My first substantive post should show up some time this evening if all goes well.©2008-2010 Jeff LaMarche.
http://iphonedevelopment.blogspot.com

Facebook's commit properly attributing enormego
Late last week, we had a bit of a misunderstanding with Facebook. We probably jumped the gun and ended up rendering the title of the post a bit hypocritical, as many of you pointed out. We should have reached out to Facebook first to find out how this happened, but we were pissed off and wanted to tell the world. It's not easy to get in touch with Facebook, and we were in no mood to sift through their site to figure it out. As it turns out, we could have emailed them at opensource@facebook.com.
As it turns out, Facebook didn't even know they did anything wrong. EGOTableViewPullRefresh made it's way into Three20 by way of a fork merge from a third party. This obviously doesn't excuse Facebook, since they are responsible for their repository, but it does explain how it happened.
Within hours of our post going up, Jeff and David from Facebook's Open Source team became aware of the mix up and reached out to us resolved the issue quickly. All in all, we were pretty happy with the resolution. We received credit for our code in three20, and we helped make Facebook's iPhone app just a little bit better.

The original version of my Briefs.app blog post contained a snarky comment about the Director of the App Review team and a link to a Wired article about his past. A friend of mine, who happens to work at One Infinite Loop, privately took me to task for including that link in my post.It took me about two seconds, now that I'm a little further away from it and not as angry, to realize that he's 100% right. It was a dick move on my part and I'm sorry for it. I have removed the link and offer my apologies to Phillip Shoemaker. The fact is, I have no visibility into what's going on and don't know where the holdup is on Briefs.app. For all I know, Mr. Shoemaker could be valiantly fighting for Briefs.app against higher up forces in the company, so casting an ad hominem attack like that was juvenile and uncool.My basic feelings about the matter are unchanged, however. It was uncool when Apple left Google Voice in limbo, but that was one small product from one very large company. In this case, it's the sweat equity from one individual developer who worked very, very hard, sacrificing sleep, family time, and entertainment to create something very cool. The impact is much greater and much more personal and it's hard for me not to get angry about it.©2008-2010 Jeff LaMarche.
http://iphonedevelopment.blogspot.com

My co-worker and all-around good guy, Rob Rhyne has officially open sourced Briefs.app as of today. After three months of being dicked around by Apple's review team, he's finally given up on getting Briefs.app onto the App Store.Throughout the ordeal, Rob has taken the whole thing with tremendous grace and has only good things to say about the people involved in the entire process. I hope he'll forgive me for not being quite so gracious. I'm pissed on his behalf, since he won't be. Make no mistake: This sucks. This is no way to treat anybody, but especially him. Rob has bent over backwards throughout the process to be nice and work within the system and to avoid saying anything negative about the problems he's faced. Rob has kept the discourse on a level I think few of us could manage. He didn't he didn't go out and raise a stink the way many developers have when they felt slighted by the App Review team. Rob just calmly and patiently worked within the system trying to make his case and get a product he worked on for months onto the app store… while working a full time job, starting a new business, and being a parent to a toddler. Oh, and his wife works too. Rob's one of the few developers I know who spends more time sitting at a computer than me.If Apple's review team had just come out and rejected the app, it would have sucked, and it would have been the wrong decision, but it would have been an acceptable situation. The app review team's job is to make tough decisions. Sometimes they're going to make bad decisions, and sometimes they're going to make decisions that we developers are going to disagree with.

Just wanted to let you know that I will be speaking at the next Voices That Matter iPhone Developer Conference in Philadelphia, PA which runs from October 16 and 17th. I was originally asked to do a talk on 4.0 Multitasking, which I will be doing. I've also recently been asked to give a second talk on OpenGL ES. I've agreed to do that presentation as well, and now I have a few days to decide on the specific topic and audience and to write up the abstract.I was thinking of doing a "from 1.1 to 2.0" kind of talk, exploring the differences between the fixed and programmable pipeline and trying to explain some of the more daunting concepts of the programmable pipeline. The goal would be to make the jump from 1.1 to 2.0 (which Apple is pushing) less scary.I'm not sure if that's a topic with broad enough appeal, though. Are you going to VTM? What would you like to see from an OpenGL ES talk?©2008-2010 Jeff LaMarche.
http://iphonedevelopment.blogspot.com

Jailbreakme v2.0 was a great success, and it’s provided a nice leveling point for all jailbreakers and unlockers on all devices at firmware versions less than 4.0.2/3.2.2.  We hope that everybody ever interested in jailbreaks or unlocks was able to join in on the jailbreakme bonanza.  Those of you who had Cydia capture your SHSH blobs, or those of you who captured them locally, will always be able to benefit from the jailbreakme.com v2.0 release. Congratulations!
Now it’s a few weeks later, and Apple has closed the jailbreakme.com hole.  They’re shipping devices with FW 4.0.2/3.2.2, impervious to this particular jailbreak.  So now, people will begin to ask: will there be a jailbreak for devices that shipped with 4.0.2/3.2.2, out of the box?
No, there won’t be.  FW 4.0.2/3.2.2 was *only* released to fix the jailbreakme hole.  With FW 4.1 still in its beta stages, it makes no sense to escalate the “cat & mouse” with Apple for FW updates that only fix the jailbreak holes. To quote WOPR, “the only winning move is not to play”.

If the cat & mouse game escalates too quickly, especially during beta FW periods, nobody but Apple benefits.  For this reason, there won’t be a 4.0.2/3.2.2 jailbreak specifically during the period where 4.0.2/3.2.2 is the latest public release.  At best, some future 4.1x FW jailbreak *may* be compatible with 4.0.2/3.2.2 (but don’t count on that).
If any of this is confusing, please ask below in our comments section!
P.S.: For those of you with iPhone3G or iPod Touch 2G(not MC version), it’s true you can always use redsn0w to jailbreak your 4.x devices.   Don’t let that dilute the above message, though :)

A week or two ago, Jeffrey Sambells had a blog post about using Xcode's Enterprise distribution for ad hoc distribution. It's a great idea that a lot of developers saw had great potential, but it had several manual steps.Since that post, Hunter Hillegas of Hanchor, LLC and developer of Vegas Mate, has created an application to automate the entire process. The app is called Beta Builder, and it's free. If you do much ad hoc distribution, you should check it out.©2008-2010 Jeff LaMarche.
http://iphonedevelopment.blogspot.com

For all those people telling me that Google's App Licensing would put a definitive stop to piracy on Android and that Apple should implement something similar, all I can say is: I told you you were wrong and here's proof, and it didn't take even as long as I said it would.I understand Google has to address piracy because it's a bit of a black eye for the platform. They need third party developers, and a lot of third party developers are gun-shy about developing for a platform with a reputation for rampant piracy. Although the iPhone has its own problems with piracy, it's on a completely different scale. The closed nature of the platform is actually an advantage for third party developers, much the way gaming consoles are. Sure, Apple's protection scheme has been compromised and any App posted to the app store can be pirated easily. But, because only people who Jailbreak their phones can actually install the hacked software, and Jailbreaking a phone can cause problems with future updates from Apple, there's built-in damage control. It also helps that you can buy App Store apps in every country where you can legally buy an iPhone. On Android, you can only buy apps in 13 countries, meaning people in other countries either have to do without paid apps, or have to pirate. There's built-in incentive in that system for people who might be perfectly willing to pay for an app to go pirate it. Google would get more for their piracy-battling dollar by expanding the paid markets than by implementing more hare-brained licensing schemes that won't ever make a dent in piracy.

Many moons ago, I wrote convolution kernel for Cocoa. It had convenience class functions to do many different types of filters, including blurring, embossing, outlining, edge detection, horizontal shift, LaPlacian, soften, high pass, etc. Now, this was before Core Image and long before the switch to Intel. I don't remember exactly when I first wrote it, but I'm guessing it was around 2001 or 2002. The method that actually applied the filter to an image used AltiVec if it was available, and if it wasn't, it did a brute force filter on the CPU.Of course, once the switch to Intel happened, the AltiVec code was no longer was helpful, and then Apple came out with Core Image which includesda convolution kernel and all of the filter settings I had created and more. So, I stopped maintaining the code.Then, when the iPhone came out and didn't have Accelerate or Core Image, I saw a potential use for the old source code. I had a project early on where I needed to be able to blur an image. So, I blew the dust off the old code. I didn't convert the entire convolution kernel – I didn't want to go through the effort if it wasn't going to work — so I created a blur category on UIImage. And it didn't work.