First off, let me just say that I may be way off base here. I’ve only just begun moving into the brave, not so new anymore, world of working on iOS apps that don’t always terminate when you hit the home button. My side projects have sat idle since iOS 3.0 was in beta, and for the most part, the projects I’ve been on at work haven’t needed backgrounding. But, after more than a year running iOS 4, and now over a month running iOS 5, I don’t think I am all that far off here.

I fully admit, I saw a bit of a performance hit when I installed iOS 4 over a year ago on my 3GS. But it really wasn’t much. If I hadn’t been looking for it, I may not have even noticed it. Then the iOS 4 enabled apps started coming out, and OH. MY. GOD. I was killing apps like it was my job just to make my 3GS usable again. But it got better. Between a combination of iOS updates, and app updates, I didn’t have to constantly kill apps. From what I could tell, outside of the iOS updates, it was a combination of app developers both better managing what their apps did when backgrounded, and often just deciding their apps didn’t need to be backgrounded.

Then, shortly before iOS 5 was released, it started all over again. Only this time it was worse. App updates started coming out that looked like the only hardware they were being tested on were iPhone 4s and iPad 2s (I’m looking at you Facebook). Apps would hang for seconds, or sometimes even minutes while they tried to do something.

But wait, it gets even worse. iOS 5 came out. Which by itself wasn’t so bad for the 3GS. If you’re careful about which new features you turn on, the 3GS runs iOS 5 pretty well. Until you fire up an app like Facebook. Or, I should say, after you close the Facebook app. Should I forget to manually open the app switcher, and kill Facebook after I use it, my 3GS will very shortly become damn near unusable. Other apps will do this to a lesser degree, but Facebook is the worst offender that I use with any amount of regularity. Or at least I used to. If I don’t kill that damn app, it can take several seconds to actually see my home screen after I slide the unlock control over.

Now, don’t get me wrong, I’m not just bitching here, I actually have at least a shred of a point. And my point is this: Why, in the world, does the Facebook app need to run in the background? Or a lot of these apps? I’ve never had to kill Tweetbot for any reason, but why does it NEED to run in the background? Just because the default Xcode projects all come set to run in the background, doesn’t mean you have to leave it that way. Even the most well written app will still be sitting there taking up some amount of resources until the system decides to kill it.

So my point? The 3GS is going to be around for a while. And it’s being given away for free now with a two year contract. That means that in all likely hood, they’re going to be around for at least another two years. And even if the next major revision of iOS doesn’t support the 3GS, I’d be willing to bet a lot of money that still means the 3GS will be a first class citizen for at least another year.

So please, for the love of whatever you hold dear and/or holy, test your apps on a 3GS. Look at how it runs while it’s being used. And just as important, if not more, look at what it does to overall system perfomance while in the background. Especially on a 3GS.

And yes, this post was all prompted by the fact that one of the projects I work on will soon need to be ready to run in the background. And while I thought it was relatively well put together, when I did the simplest background test possible, and just turned on that flag, well, let’s just say I wasn’t proud of what it did to the performance of my 3GS, and I have some work to do to fix that.

There’s been a lot of talk lately about static, or “baked” blogs. Moving my blog off of Wordpress has been a thought I’ve had in the back of my mind for a long time now. As a matter of fact, the first blog I ever maintained was run on a home grown static blog engine. It was really basic, and the code for it has long since been lost to the sands of time.

It’s not that Wordpress is bad. Honestly, I’d just gotten bored with it. And it doesn’t hurt that I can now turn off PHP support in Apache, and switch it over to the worker model, instead of prefork, with much less work.

My static blog engine of choice, influenced by the likes of Matt Gemmell, among others, is Octopress. The initial setup was pretty straight forward, especially using Matt’s post as a guide. The one thing I still don’t have working is MarsEdit. There are a few options out there that more or less get MarsEdit working with Octopress, but I’m not really happy with any of them. To be perfectly honest, I’m very tempted to try my hand at writting a simple Metaweblog API, or AtomPub server to tie into Octopress, just so I can keep using MarsEdit. Yes, I may just be that crazy.

So, obviously even infrequent long form posts on this site just aren’t going to happen, but I don’t want to shutter this blog either. So I think I’m going to start trying out shorter form, even if it’s only slightly longer than a tweet would allow, posts, to see if I can get this updated on a somewhat regular basis. Maybe if I just start writing anything here, longer, more detailed posts will start to crop up naturally. Either way, there may finally start to be some new content here again, even if it’s mostly just useless drivel.

I’ve seen a lot of people complaining about how bad 2009 was on Twitter and Facebook, and pretty much everywhere else. And while there were definitely some down moments, I’d have to say that for my money, 2009 was one of the best years I’ve had. So maybe your 2009 was horrible. I’m not trying to dispute that. I’m just going to politely ignore it, and go about my day. First and foremost, our first child, Logan, was born this year. I can’t begin to put into words how awesome fatherhood has been. Watching this little person grow from barely being able to move, to already being able to walk a little in just about eleven months is incredible. Not to mention the personality he’s already got. Then there was my business that I finally got off the ground, even if only a little. It’s still not much more than a hobby, but it’s paying my server costs. I’m currently working on version 2.0 of Logbook, and hope to get it out the door before school starts up again at the end of January. But we’ll see what my work schedule has to say about that. And then there’s my actual day job. You know, the one that pays the bills. While 2008 saw me finally land a full time programming gig, it was Perl, and not really my first choice. But at least it wasn’t UNIX admin work anymore. Well, November of this year, I found my perfect job. I’m working for a small startup in Boston. And while I’m working primarily on iPhone software, which I LOVE, I also get to do some Mac software. I’m working with a great group of people, and am really looking forward to 2010, and the stuff we have coming down the line. So there you have it, my 20,000 foot view of 2009. And let me just say, I’m really looking forward to 2010 as well.

So, after my post back in March about Core Data being available for iPhone 3.0, I was asked if my enthusiasm for Core Data on in Cocoa Touch was misplaced, or at least premature. Well, now that I’ve converted the storage back end of Logbook from FMDB, which is a thin Objective-C wrapper on SQLite, to Core Data, I can safely say that Core Data is just as fast, and in some cases marginally faster. And this time I actually have some data to back that statement up. Before I did the conversion, I added some simple timing checks to the code, and recored the times for loading table view cells using FMDB, and using Core Data. If you look at the chart below, you can see that on average, Core Data is actually a little bit faster than FMDB, but not enough to alone make it worth the work of converting. The real win comes from the amount of code that you can just toss away after this is done. Now, one of the questions I’ve had asked, is what about the agregate functions that SQLite, and therefore FMDB, allows you to use? The answer is tricks using NSPredicate, NSFetchRequests, and the agregate functions provided by Key/Value coding. These three features of Cocoa combined more ore less give you the same power of SQLite’s built in functions, and may even use those features of SQLite under the hood.

I am extremely happy to see this finally be allowed. I was ecstatic when Apple announced in app purchases back in March. But then immediately crashed when we were told that “free apps remain free”, and there would be no in app purchases for free apps. Now that developers can use in app purchases to have upgrades from free apps, we’ve moved one step closer to the way most indie software is developed. We still can’t do time limited demos, but we can have feature limited free versions.

OK, so I’ve had this thought for a while, and it’s not going away. That thought is that we need a CocoaHeads chapter somewhere in central CT. I’ve enjoyed going up to Boston for their meetings, but it’s just too far to make it every month. So while I’d like to keep going up to Boston once in a while, since they’re a great group of people, I’d probably end up running the CT chapter sometime other than the typical second Thursday. So, the general idea is start a CocoaHeads chapter somewhere in CT, preferably somewhere near Hartford or Tolland. On the other hand, location and time would depend on who’s interested, and where we can find some place to meet. So, if anyone’s interested, drop me a line (craversp@gmail.com), and we’ll see if we can’t figure something out.

I should have posted this yesterday, but the price change took forever to show up in the App Store. Anyway, I just wanted to announce that Logbook, my fuel and maintenance tracker for the iPhone and iPod Touch is on sale to celebrate the one year aniversary of the App Store. It’ll be $0.99 until sometime tomorrow when I remember to change the price back. So go get it, while it’s cheap.

Well, Apple just finished up their iPhone 3.0 event, and let me say, they answered my prayers and then some. First off, they added Core Data (at least it was on one of the slides). As is evident from most of my previous posts, I spent a lot of time looking for a good ORM layer for the iPhone. I finally settled on FMDB, a thin wrapper around the SQLite API. It’s solid, but I wasn’t looking forward to using it instead of Core Data on one of my projects that was going to have both Mac and iPhone versions. Now, I don’t have to worry about that. Of course now I also need to consider picking up a copy of Marcus Zarra’s Core Data book, so I can really get down and dirty with it. Now I would have been plenty excited had Core Data been the only thing they announced for developers today. Instead, they also announced a Maps API. And while it makes you provide your own map tiles, that’s not going to be a problem for me. I had plans all along to use my own tiles. There were also a bunch of other developer centric announcements today, but those were the big ones for me. Mac <-> iPhone syncing for apps would have been nice, but I can live without that. And who knows, they may still announce it. Here’s hoping. On the other hand, I can’t expect Apple to do all of the heavy lifting for me. Now begins the wait for the iPhone developer’s portal to reopen, so that I can grab me a copy of the new SDK, and get to work.

While heading over to the UK for a developers conference is way out of my budget right now, anyone who is looking for a good Mac developer conference should go check this out.  It’s been put together by Scotty, from the Mac Developer Network, and he’s done one hell of  a job. He’s lined up a great group of speakers, all of whom are giving talksthat I wish I could attend. Go check it out!