So the other night I got annoyed at updating a script I made to dump iOS frameworks, and so I decided to re-write it. The result is a script which I am confident is good enough to share with the world.

I’m releasing it under the GNU General Public License Version 3.

These scripts dump all of the iOS frameworks (both public and private) and then patch the #import commands.
The headers are then merged with the existing iOS headers in your SDK, without overwriting any Apple headers.

Instructions for use are below, though these are also included in the zip.

You can download it here.

PRE-REQUISITES

You will need to download class-dump from here and then copy just the executable to “/usr/bin/” on your Mac.

You will also need to download subtrate.h from here and place it in the same folder as the scripts.

You will need to copy libsubstrate.dylib from “/usr/lib/libsubstrate.dylib” on a jailbroken iOS device with MobileSubstrate installed to the same folder as the scripts and substrate.h on your Mac.

USAGE

cd to the directory with the scripts and substrate.h in:

Burgch$ cd ~/Desktop/DumpFrameworks

The script takes one argument; the SDK directory for the SDK you would like to dump.

Run the script:

Burgch$ ./DumpFrameworks.sh /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk

When prompted, enter your super user password (this is required to copy the header files back to the SDK (you can check the script if you don’t believe me :P)

That’s it, you’re done, all header files for the SDK have been dumped, patched, and merged. You should receive a successful completion message to confirm. Wasn’t that easy? :P

This post is just some instructions on how the mappings of weathericon themes work. You can use this to use one image for multiple weather codes, and to save you renaming lots of files!

I’ve made a text file which shows the actual description and the weather number it corresponds to, which can be downloaded from here: Order

You can also take a look at this sample plist from the Katra theme. You can either edit this plist to match the names of your icons, or rename all of your icons to weather0.png weather1.png and so on. If you rename them, you can remove the mappings section of the plist.

In the plist, if you are going to use the mappings, just enter the name of the icon you want for that description (see the text file to see what it corresponds to) without the extension:

<key>weather0</key>
<string>tstorm3</string>

This will use tstorm3.png for weather0, which, looking at the text file, corresponds to a tornado.

Once you are done either renaming the icons (and removing the mappings dict from the plist), place all of the icons and the plist in a folder called “com.apple.springboard” without the quotes. This needs to go in a folder called “Bundles” again without quotes. This folder then needs to go in a folder called “THEME_NAME.theme”, where THEME_NAME is your chosen theme name.

You then copy this folder to /private/var/stash/themes.XXXXXX/ on your phone, where the “XXXXXX” is 6 random numbers/letters.

You should then be able to enable this in winterboard, and hey presto, you should have your icons.

You can change the size of the icons themselves or the size can be changed by editing the plist.

To change the forecast icon sizes in the LockInfo weather plugins, after these lines:

<key>ImageScale</key>
<real>0.9</real>

add:

<key>LockInfoImageScale</key>
<real>0.6</real>

This value will change the forecast icon sizes.

Hope that helps!

This post is an How To for iPad users who need to find their Yahoo Location Code for David Ashman’s excellent Weathericon tweak, which replaces your weather app’s icon with an icon for the current weather.

My advice on finding the code? Get an iPod Touch or iPhone :P

Jokes aside, this is a serious point. If you can get your hands on a jailbroken iPod Touch or iPhone, add your town/city to the weather app. Next, locate the weather plist using either SSH, a USB access program such as Phone Disk, iFuntastic or iPhoneBrowser, or iFile. The plist’s location is /var/mobile/Library/Preferences/com.apple.weather.plist

Open it up and find your town/city name. It should look something like:

<key>Name</key>
<string>Reading</string>

After a few keys for the sunset time and such, you should see the Zip key, like this:

<key>Zip</key>
<string>UKXX0117|32997</string>

The UKXX0117|32997 bit is the code that you will need to make a note of and enter on your iPad as the Location in the Override Location weather settings. All sorted, and you can delete the city from the weather app again!

However, if you don’t have access to an iPod Touch or iPhone, you’ll need to do a little bit more. Basically, the location you need for libweather comprises two separate codes combined with a vertical bar |. The first code is a weather code of the form: UKXX0117

The second code is a Yahoo WOEID (Where On Earth IDentifier).

I haven’t found any (easy) way to generate these two codes together other than the plist method above. However, they can be found quite easily separately. To find the weather code, go to The Weather Channel and enter your town/city. You may need to choose your location from a list of options. Once you’ve found it and got your forecast, you should find the weather code at the end of the URL, like this:

www.weather.com/weather/today/Reading+United+Kingdom+UKXX0117

So now you’ve got the weather code, what about the WOEID? Well, you can find this using Yahoo Weather and again searching for your town. Now, once you get the forecast up (again you may have to select from a list), the end of the URL will contain the WOEID, like this:

http://weather.yahoo.com/england/berkshire/reading-32997

Now, combine these two codes with the | to give:

UKXX0117|32997

exactly as we found it in the plist, and exactly as is required by the Location in the Override settings.

Enjoy iPad users :)

With dSYM files and Instruments, there is little cause for iOS developers to manually symbolicate Crash Logs anymore.

However, if you’re a Jailbreak developer, chances are you’ll be compiling dynamic libraries & executables and not apps. This means no Instruments and no dSYM files.

So what do you do when you get an email from Cydia (assuming it’s not blank ofcourse!) with a Crash Log and a disgruntled user who keeps getting SpringBoard crashes after installing your tweak?

Hopefully the log will be symbolicated with Crash Reporter, but this might not be much use. What I would do is take a look and see if I can work out what my code was doing just before the crash. Unfortunately, this is (in my experience) rarely enough to find a crash, unless it’s a fairly obvious mistake.

So you send the user an email thanking them for taking the time to send you the Crash Log and say you’ll do your best to fix it. Trouble is you’re still not sure where to start.

Before dSYM and Instruments, developers used a tool called ATOS. This same tool can come to the rescue now for Jailbreak devs. What ATOS does is converts meaningless stack trace addresses to useful filenames and linenumbers.

To use ATOS to it’s full potential, you’ll need to add the -gstabs compiler flag to your makefile. This will include the extra symbols required to give you line numbers. Without it, ATOS can’t tell you what is causing the problem in any format you will understand (as the relevant symbols will be stripped from the binary). Using the -g compiler flag will keep enough symbols to let ATOS tell you which function was running just before the crash, but it can’t tell you line numbers. It is a good trade off between debugging potential and executable size.
Remember to remove the -gstabs flag before you compile your production build, as the extra symbols massively increase the size of your executable and can apparently cause problems.

If you are compiling with theos/logos, use:
make CFLAGS=-gstabs DEBUG=1

OK so how do you use this magical tool? It’s an easy command line tool:
atos -o [Executable path] -arch armv6 [stack trace address]

For example, from this stack trace:
21  HTCPlugin 0x058ab084 0x5894000 + 94340

The memory address we need is 94340. This stack trace was the last of my code to be called in the crashed thread. This gives us the command:
atos -o [Path to HTCPlugin executable] -arch armv6 94340

This command will then tell me which line of which file was executing just before the crash occured, so I know exactly where to start looking when it comes to debugging the crash.

One final note, the executable you use with ATOS must be exactly the same as the one that created the crash log, or compiled from exactly the same source code. Even a minor difference will cause ATOS to either produce incorrect results or fail to find a line number at all.

Hopefully this will come in useful to some people – Happy Debugging!