KDBDallas

Universal Binaries are a wonderful thing, and not just if you are still writing Mac Power PC code, they are just as useful in the iOS development world.

If you do any amount of iOS development, chances are you have used (in one way or another) a static library.
Usually when you use a static library you get (or compile) 2 versions.
One for the device, and one for the simulator.

This is fine until you want to add the library to your app.
If you are using the simulator and the device for testing you have to play a swapping game with the corresponding library version.

Wouldn’t it be easier if you could just have 1 version of the library and it worked on the device or the simulator without you having to make any changes?
Sounds nice? I would say so, and luckily it is pretty easy.

The first thing you need to do is open a Terminal window (don’t worry, its just 1 command)

Use the following command (replacing the library path and name, with your libraries information):

lipo -output <StaticLibraryUniversal>.a -create <StaticLibraryDevice>.a -arch i386 <StaticLibrarySimulator>.a

Thats it!

Just use the new static library file in your project and you can move between the device and the simulator without worry about anything!

Have fun.

Mike Ash has turned his famous Friday Question and Answer series into a book, available in either iBooks or Kindle versions.

Mike is an amazingly smart guy, who knows more about programming then you could ever imagine.

If you work with Objective-C you owe it to yourself to check out his book and his site.

I am working on a project where I need to make a XMLRPC connection to an API in Objective-C, and someone pointed me to:
Eric Czarny’s XMLRPC project on GitHub.

While this is great, it was done as a framework for Cocoa and since the project I am working on is for iOS 3rd party frameworks are not allowed. Instead they have to built as a Static Library.

So I started a new iOS Static Library project and converted over Eric’s code.
I now have a XMLRPC iOS Static Library ready for SDK 4.0 and greater.

You can find my iOS version on my BitBucket account.
Specifically: https://bitbucket.org/kdbdallas/xmlrpc-ios

I have placed my decked out Mac Pro up for bid on eBay.

Don’t miss the chance to get a SCREAMING Mac at a fraction of the price!

Apple Mac Pro Dual Quad-Core Xeon 2.8G, 10G RAM, 2TB HD

iDeskCal has officially been approved for the Mac App Store!

Look for it when the Mac App Store is released on January 6th.

Inspired by a similar post I saw today, I thought I would take a snap of my computer setup at work and share it with all of you.

I have uploaded it to Flickr with notes on what everything is, but I will attach the basics to this post.

This is my setup at work – Moki Networks – mokinetworks.com
All Displays powered by the iMac.

27″ iMac – 2.8 GHz Intel Core i7. 8GB RAM – Running Xcode
Samsung 27″ Monitor – Running my Mac app ‘iDeskCal’ www.HashBangInd.com/iDeskCal and Safari viewing www.philhendrieshow.com
Dell 24″ Monitor – Powered via EVGA UV Plus+ 16 (USB Display Adapter) Running iPhone 4 Simulator and Xcode Console
iPad running as a monitor using the app Air Display. Using for Mac OS Dock, Twitter (Echofon), and IM (Adium)
iPhone 4 running Safari, viewing personal Mac and iOS company HashBang Industries. HashBangInd.com
iPhone 3GS
iPhone 3G (broken screen but working)
iPod Touch – 2nd Generation
iPhone – 1st Generation
Bose QuietComfort 15 Noise Canceling Headphones
Dr Pepper!

I was VERY disappointed that I was unable to make it to Apple’s WWDC (World Wide Developer Conference) this year (it was last week).

The sessions are always VERY informative, but it is also a excellent chance to not only meet with other Mac/iOS developers, but you have the chance to talk one on one with the very people who are writing the software and API’s (Application Programming Interface) that we write software for/with.

Apple does make the videos of the sessions (along with the slides) available to everyone that attends, and allows those that didn’t attend to purchase the videos.
Before last year, these videos usually took around 6 months to become available, however last year they had them released within a month.

This year Apple TOTALLY outdid themselves and have released the videos all today!
That is LESS than 1 week!
Not only did they release everything within a week, but Apple has made all of the videos and slides available to ALL registered developers (even the free developer accounts) FOR FREE!!! That is a $500 savings for those that couldn’t attend!

I only have 2 things to say…

First: Good bye to my Hard Drive space (The videos are available in HD and Standard formats this year)

and Secondly… Classy Apple! VERY VERY CLASSY!

Reminder: Even though the videos did not cost this year, they are still covered under an NDA that you agree to when signing up for a developer account. Don’t make them sorry that they were so giving.

On January 24th, 1984, Steve Jobs pulled a 128K Mac out of its case in front of a crowd of reporters, turned it on, and let the computer introduce itself to the world. The rest, as they say, is history.

On January 25th, 1982, I was born.

It’s kind of sad that I am only 2 years older then the Mac.

Recently I was doing some performance stress testing on my upcoming iPhone app, Newsprint, and ran into a little Core Data gotcha that I thought I would document for both myself and for Google to index for others.

Special thanks to Jeff LaMarche for guiding me in the right direction to figure this out. You can find his blog at: http://iphonedevelopment.blogspot.com/

This issue came to play when I needed to do a fetch request from Core Data and then run a couple of Predicate “searches”/”filtering” on the data.

My original thought was that doing a single fetch request and then running my different predicates on the returned set of objects would have better performance then doing multiple fetch requests since I would only have to pull from the Core Data SQLite DB once and then I would have everything in memory and I could just simply manipulate it.

Turns out that this is HIGHLY incorrect.

If instead you just do multiple fetch requests and implement your predicate into your fetch request, that Core Data and SQLite are smart enough to scan the records more efficiently and without causing Core Data Faults to fire.

This gives a MASSIVE speed increase!

So if you are ever doing something similar, make sure to check this method and see if it to can speed your app up.