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 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.

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

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.

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.

This book is great for new iPhone developers as well as experienced ones.
You will need some Objective-C knowledge, but if you have some OOP (Object Oriented Programming) experience you should be ok with picking up an Objective-C book as well for as you work through the book.

If you are in a B&N stroll into the Geek, err, I mean Computer Programming section and look for the book.
Feel free to buy a copy to support my good friend and author of the book, Jiva DeVoe.
If you can’t get yourself to that level of geek, at least pick it up and look at the ‘Credits’ page, right before the Table of Contents and then you can go around to all the geeks in that area and say, “I KNOW THIS GUY!”

This makes 2 iPhone development books that I have been involved in, each one with more of a role than the last, however I can safely say it will be my last as after being involved with the book writing processes and having the author be a close friend of mine, I don’t really have a desire to write one myself (unless it’s an offer I just can’t refuse).

The book is called “Cocoa Touch for iPhone 3.0″ and is being written by my friend Jiva DeVoe and published by Wiley and Sons Publishing.

You can visit the current pre-emptive webpage for the book at: http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470481072.html

I was previously a Technical Reviewer for the programming book: iPhone SDK Application Development, 1st Edition

It will be interesting the see the differences between being a technical reviewer and a technical editor.

ChocTop is a system for rapid mac software DMG packaging.

In setting it up and using it I found that it lacked a feature I wanted.
Mainly the ability to specify that it should you a Debug build instead of the standard Release build that you would usually use.
The reason for wanting a Debug build is simple… I am packaging up a Beta.

So even though I don’t know Ruby (which is what ChocTop is written in) I set foot to add this feature.
Luckily like most computer languages I was able to understand it enough to understand what was going on and enough to add this new ability.

Once I was done and used it myself, I sent it back into the developer and he has already integrated it into the repo version of the code.

If you are a Mac developer checkout http://drnic.github.com/choctop/

Not being familiar with all the code and with a TON of methods being accessed in milliseconds, my attempts at stepping through the code just wasn’t working, as clicking ‘Step Into’ as fast as I could keep up and over an hour of stepping through I was still not even close to figuring out what I needed to know.

This lead me to the thought of logging every method that was accessed and then I could step look through it and skip around as needed.
However with 60 some odd files and say maybe 20 methods in each file, that would take a lot of NSLog’s.
I started looking around and was pointed to bbums blog about doing something similar.
However it still would take adding some code, plus I couldn’t get it working right with the iPhone.

This lead me to wonder about DTrace.
After a recent podcast from Scotty at the Mac Developer Network, featuring Colin Wheeler talking about DTrace, I have been very interested in learning more about DTrace.

The difficult thing I have been finding is that since DTrace was originally written for Sun, it is hard to find info related to MacOS and more so Cocoa.

I then found a video from Colin about using DTrace with Cocoa and XCode.
http://www.viddler.com/explore/Machx/videos/8

I wasn’t able to get what I wanted working, so I hit Colin up on Twitter and then talked to him a bit in email and he pointed me to the Golden Solution!

The solution is:
objc$target:::entry{}

So I took that and created a DTrace script.
You can grab it here:
http://kdbdallas.com/wp-content/uploads/2009/02/logallmethodsd.zip

To run it open Terminal and run:
sudo ./logAllMethods.d -p PID

Of course replacing ‘PID’ with the PID of your running program and remembering that for DTrace ‘sudo’ is required.

Also note that this works for iPhone programs running in the iPhone Simulator.
Just look for the PID of your iPhone app within Activity Monitor once it’s running in the simulator.

Be careful as depending on the program it can spit out a TON of data VERY quickly.

Running this against Adium for only a fraction of a second gave me a couple hundred lines of output.

The output looks like this:

tesseract:Desktop dallas$ sudo ./logAllMethods.d -p 4371
dtrace: script ‘./logAllMethods.d’ matched 71222 probes
CPU ID FUNCTION:NAME
0 59398 -retain:entry
0 34684 +retain:entry
0 32061 +idleAllMovies::entry
0 32062 -idle:entry
0 34707 -retain:entry
0 32914 -_usingVisualContext:entry
0 32878 -_resyncNaturalSize:entry
0 31935 -loadState:entry
0 31972 -naturalSize:entry

Hopefully this helps someone out there.
Just remember always use the info I post for good.
(or if its for evil make sure it profitable and then send me a cut)

Once again, special thanks to Colin Wheeler.

Screenshot:

Download: WhiteIntermProgIndicator.zip