I'm dummy in iOS especially in private API.
I have application for testing and now I need to use private API (this application not for App Store).
I downloaded generated headers from iOS-Runtime-Headers and what next?
Under /System/Library/ I have list of libraries that contain Frameworks, ... ,PrivateFrameworks as well.
Do I need to replace original framework with ones I copied from iOS-Runtime-Headers?
Because I have other applications that use Public API only and I don't want to damage them.
From posted link they tell to validate library for example by:
NSBundle *b = [NSBundle
bundleWithPath:#"/System/Library/PrivateFrameworks/GAIA.framework"];
BOOL success = [b load];
But here the path points to original path.
Or I miss something,
Thank you
First of all, don't replace any headers which are provided by Apple.
Generally, it's done one of two ways:
1) You can copy some of these headers to your project and just include these files the same way as you include any other headers
#import "SomeHeader.h"
2) Sometimes you have to sanitize them (edit them) a little bit. Quite often, these headers has something like in in them:
#import "NSObject.h"
And compliller won't be able to find it, because NSObject is built-in class. So, you need to remove this like.
3) If you just need couple of methods out of it, then Tuukka Nori solution is right.
On top of these, you will need to link (statically or dynamically) against appropriate private framework (just including headers isn't enough).
Don't replace any files. Instead, write a header file with the symbol that you intend to use. If you need an Objective-C method, add a category with a unique name, e.g.
#interface NSString (MyOwnPrivateCategory)
- (void) privateMethodDeclaredInRuntimeHeaders;
#end
Import it and use the method as you like.
The sample code given shows how to load a framework at runtime in case you don't want to link to it. Since some frameworks are private, they might not be available in all versions of iOS.
Related
I am building an SDK that iPhone developers can include in their projects. It is delivered as a compiled ".a", without source code. Let's call my SDK "AAA".
The customer in his project (let's call it "BBB"), in addition to use AAA, may also use a 3rd party library called "CCC" - which also comes pre-compiled, closed-source. I do not sell CCC, it's a different company.
My SDK, AAA, can optionally use CCC to improve the product, using those 3rd party features. For example, let's say CCC is a security SDK to encrypt something. AAA does not require CCC, but will be more secured if the customer chooses to include CCC in their project as well.
Now here is an extra tricky part - the CCC library, is pure C code, made of C Structs and C functions - nothing object-oriented about it.
The issues are:
How can I compile my AAA SDK to use functions/structs from CCC, without including CCC in my project (not legally allowed to, and don't want to keep up to date with version updates).
How can I detect if the customer has CCC in his project, to use those extra features only if available?
Use dlsym to get the C function pointers by function name. If it can find them, they're there. Otherwise they're not. Just use RTLD_DEFAULT as the first parameter.
EDIT: having cast around for an iOS example, see Mike Ash's write up of PLWeakCompatibility, particularly the section on 'Falling Through'. You'll see he checks whether objc_loadWeakRetained (a runtime call related to weak references) is present. Under 5+ it is and his version calls the real one directly. Under 4 it isn't so his version does something else instead.
EDIT2: sample code:
Sample 1:
#import <Foundation/Foundation.h>
#include <dlfcn.h>
int main(int argc, char *argv[])
{
#autoreleasepool
{
NSLog(#"%p", dlsym(RTLD_DEFAULT, "someFunc"));
}
}
Outputs 0x0. Sample 2:
#import <Foundation/Foundation.h>
#include <dlfcn.h>
void someFunc()
{
}
int main(int argc, char *argv[])
{
#autoreleasepool
{
NSLog(#"%p", dlsym(RTLD_DEFAULT, "someFunc"));
}
}
Outputs an address other than 0x0.
Sample 3:
#import <Foundation/Foundation.h>
#include <dlfcn.h>
void someFunc()
{
NSLog(#"Hi!");
}
int main(int argc, char *argv[])
{
#autoreleasepool
{
void (* func)();
func = dlsym(RTLD_DEFAULT, "someFunc");
func();
}
}
Outputs Hi!.
Structs have no presence in a .a or elsewhere at runtime, they're just instructions to the compiler on how to format data. So you'll need to include either the actual structs or a compatible restatement of them in your code.
You can do it using weak functions.
In your static library, declare all function of ccc that you want to use like this:
int cccfunction(void) __attribute__((weak));
Don't include ccc in you lib.
Since the functions are declared as weak, the compiler wouldn't complain about their absence, however you will be able to reference it in you code.
Then, when you distribute the library to your users, give them a .c file with empty ccc functions inside, returning 0/null.
This is necessary when the ccc lib is not available.
The user must delete this file if the CCC library is imported.
LOOK at this project
execute IOSLibraries and look at the log.
At the first execution, you will see in the log
CCC not found <--- this line is printed by libstatic (your library)
if you go in the optional.c file and comment the cccfunction(), you will see in the log
Executing a function of CCC <--- this line is printed by libccc
CCC has been found and the function has been executed <--- this line is printed by libstatic (your library)
If you remove both the ccc lib and the optional.c file you will see
Undefined symbols for architecture xxxxxx:
"_cccfunction", referenced from:
_wrapper_cccfunction in libstaticfirst_universal.a(wrapper_cccfunction.o)
This is the reason why you need to ship the optional.c file, so the user compiler won't complain about not found methods.
When the user has the CCC lib, he can simply delete or comment the optional.c file.
In your library you will be able to test for the presence of the CCC library looking at the return value of some control functions
EDIT - old answer: after realizing that you are on iOS, the below (and first) answer became not valid. Dynamic linking works only on OSX. However, I leave the old answer for persons using OSX
OLD ANSWER
I think that
I assume that CCC is a static library (if it's dynamic it's simpler). In this case, AFAIK, you can do nothing "automagically", but a good compromise can be something like this, using Dynamic libraries
user project --include--> your static library --include--> a dynamic library --can include–-> the CCC library
create two version of the dynamic library:
one that implements, for example, empty functions of the CCC library -> when you call the function, they returns 0/null and you know that the library is not implemented. You can even use something smarter (a simple control function)
give to the users the source code of a second dynamic library, that they can compile simply by doing drag-drop of the CCC library inside the project, and then moving the compiled library in the right place. This is not the source code of your library (your code is compiled in the static part), but only the code of the wrapper functions that you call from your static libraries.
your static library don't call directly functions of the CCC library, but only wrapper functions that always exists (in both the "empty dynamic library" and in the "compiled-by-user dynamic library")
By doing this, the user can replace the "empty" dynamic library with the one that include CCC.
If the dynamic library is the one with the CCC linked, the final project will use the function of CCC, otherwise it won't.
Look at the attached example:
LibTests project implements the lib libstaticlib.a and call its function "usedynamic(int)"
libstaticlib.a implements the dynamic library libdynamic1 and call its function "firstfunction(int)"
libdynamic1 has two different copies: one has a firstfunction() that returns the number passed, the other returns the number*2
now, open LibTests (that should be project of your user), copy the first of the two compiled dynamic libraries in /usr/local/lib/ , then execute LibTests: you will see "10" in the console.
Now, change the dynamic library with the second, and you will see "20".
This is what the user have to do: you sell the library with a dynamic "empty" component. If the user has bought CCC, you give instruction and code on how to compile the dynamic component with CCC bundled with it. After the dynamic library has been built, the user has simply to switch the .dylib file
This is tricky, but manageable. If you only needed Objective-C classes from CCC, this would be easier, but you specifically said you need access to structs/functions.
Build a proxy class around all the CCC functionality. All CCC functionality must be encapsulated into instance methods of the proxy. All CCC types must be adapted into your own types. No part of CCC can be included in the anything outside the proxy class's implementation file. I will call this class MyCCCProxy.
Never directly reference the MyCCCProxy class object. More on this later.
Build your library without linking MyCCCProxy.m
Build a second static library with only MyCCCProxy.
Customers who have CCC will need to link AAA, CCC, and CCCProxy. Customers who don't have CCC will only link AAA.
The tricky step is number 2.
Most of the time when you create an instance of a class, you use:
MyCCCProxy *aCCCProxy = [[MyCCCProxy alloc] init];
This directly references the class object for MyCCCProxy and will cause user linking issues if MyCCCProxy is not included.
Instead, if you instead write:
MyCCCProxy *aCCCProxy = [[NSClassFromString(#"MyCCCProxy") alloc] init];
This does not directly reference the class object, it loads the class object dynamically. If MyCCCProxy does not exist as a class, then NSClassFromString returns Nil (the class version of nil). [Nil alloc] returns nil. [nil init] returns nil.
MyCCCProxy *aCCCProxy = [[NSClassFromString(#"MyCCCProxy") alloc] init];
if (aCCCProxy != nil) {
// I have access to CCC through MyCCCProxy.
}
so Here is the gist of your problem...
a static library can't be swapped by your own process... that is at link time I linked against libfoo.1.a now at run time this process can't reliably swap in the symbols for libfoo.2.a
so you need to get around this limitation.
the simplest is to use a dynamic library and the dynamic linker... but you are using iOS so you don't have access to that.
if you could run a helper you could possibly change the actual objects in the first process, but you are on iOS and that won't work...
so that leaves trying to make an object modify its own contents... which code signing won't let you do...
so that leaves building an overflow into your program and trying to get it to execute :)
actually it is much simpler than that...
make a buffer
fill it with code fragment
set uo stack frame (requires a little asm)
set up arguments for the function you plan to call
run buffer + offset to your method
profit
as a side note I wrote a little thing that demonstrates dynamic binding at run time... but you need to have a compiler etc... this strategy won't work on iOS
https://github.com/gradyplayer/cfeedback
EDIT I actually re-read your problem, and it is a much easier one that I thought you were trying to solve...
you can use whatever is #def'ed by the other headers to do conditional compilation...
and if there are places where you have to include one of these structs into an object you can just typedef the struct then only use pointers to it, as long as the library has construction and destruction functions.
It is not exactly runtime, but may solve your problem depending on CCC license.
Option 1 (compile time)
Create a CCC_wrap library with #ifdef, and give the instructions to compile it with and without the CCC_library.
For each CCC_function, you must have a equivalent CCC_function_wrap
If HAVE_CCC == 1 the wrapper function should call CCC library, otherwise, do nothing or return error.
Create an extra function to discover how your library was compiled
int CCC_wrap_isfake(void) {
#if HAVE_CCC
return 0;
#else
return 1;
#endif
}
Option 2 (binary ready)
Create two new libraries, CCC_wrap and CCC_wrap_fake
Both libraries must contain all functions/classes needed to run the program, but the fake library all functions will do nothing, just return 0;
Than you create a extra function CCC_wrap_isfake
CCC_wrap_fake:
int CCC_wrap_isfake(void) { return 1;}
CCC_wrap:
int CCC_wrap_isfake(void) { return 0;}
Now you know if your code is running with the real wrap, or the fake one.
On compile time, you need to set a flag to determine how your library will be linked to your client software
CCC_wrap_fake:
LDFLGAS=-lCCC_wrap_fake
CCC_wrap:
LDFLGAS=-lCCC_wrap -lCCC
Both options should link correctly.
About license requirement
If you deliver the CCC_wrap library source, your client will be able to update the CCC library, without having any access to you main source.
In both cases, it will not be required to you to ship the CCC library together with your source code.
Your problem is more easly solved at compile time since your clients are already required to link everything by themselves.
Since your client is supposed to statically link all your "AAA" code together with "CCC" code, your problem can be solved by instructing your client to compile together "AAA.a" either with "AAA_with_CCC_glue.a" if they have "CCC.a" or "AAA_without_CCC_glue.a" if they don't. Both _glue.a would implement the set of functions that potentially uses CCC.a, difference is if they actually use it.
To solve this at runtime, you'd need at least to be able to call dlsym() (this post made me think that yes, you can, but it is old). Try that to look for all CCC.a functions that you care inside your app own memory.
It's possible to add extensions to existing Swift object types using extensions, as described in the language specification.
As a result, it's possible to create extensions such as:
extension String {
var utf8data:NSData {
return self.dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: false)!
}
}
However, what's the best naming practice for Swift source files containing such extensions?
In the past, the convention was to use extendedtype+categoryname.m for the Objective-C
type as discussed in the Objective-C guide. But the Swift example doesn't have a category name, and calling it String.swift doesn't seem appropriate.
So the question is: given the above String extension, what should the swift source file be called?
Most examples I have seen mimic the Objective-C approach. The example extension above would be:
String+UTF8Data.swift
The advantages are that the naming convention makes it easy to understand that it is an extension, and which Class is being extended.
The problem with using Extensions.swift or even StringExtensions.swift is that it's not possible to infer the purpose of the file by its name without looking at its contents.
Using xxxable.swift approach as used by Java works okay for protocols or extensions that only define methods. But again, the example above defines an attribute so that UTF8Dataable.swift doesn't make much grammatical sense.
I prefer having a + to underline the fact it contains extensions :
String+Extensions.swift
And if the file gets too big, you can then split it for each purpose :
String+UTF8Data.swift
String+Encrypt.swift
There is no Swift convention. Keep it simple:
StringExtensions.swift
I create one file for each class I'm extending. If you use a single file for all extensions, it will quickly become a jungle.
I prefer StringExtensions.swift until I added too much things to split the file into something like String+utf8Data.swift and String+Encrypt.swift.
One more thing, to combine similar files into one will make your building more faster. Refer to Optimizing-Swift-Build-Times
Rather than adding my comments all over the place, I'm surfacing them all here in one answer.
Personally, I take a hybrid approach that gives both good usability and clarity, while also not cluttering up the API surface area for the object that I'm extending.
For instance, anything that makes sense to be available to any string would go in StringExtensions.swift such as trimRight() and removeBlankLines().
However, if I had an extension function such as formatAsAccountNumber() it would not go in that file because 'Account Number' is not something that would naturally apply to any/all strings and only makes sense in the context of accounts. In that case, I would create a file called Strings+AccountFormatting.swift or maybe even Strings+CustomFormatting.swift with a formatAsAccountNumber() function if there are several types/ways to actually format it.
Actually, in that last example, I actively dissuade my team from using extensions like that in the first place, and would instead encourage something like AccountNumberFormatter.format(String) instead as that doesn't touch the String API surface area at all, as it shouldn't. The exception would be if you defined that extension in the same file where it's used, but then it wouldn't have it's own filename anyway.
If you have a team-agreed set of common and miscellaneous enhancements, lumping them together as an Extensions.swift works as Keep-It-Simple first level solution. However, as your complexity grows, or the extensions become more involved, a hierarchy is needed to encapsulate the complexity. In such circumstances I recommend the following practice with an example.
I had a class which talks to my back-end, called Server. It started to grow bigger to cover two different target apps. Some people like a large file but just logically split up with extensions. My preference is to keep each file relatively short so I chose the following solution. Server originally conformed to CloudAdapterProtocol and implemented all its methods. What I did was to turn the protocol into a hierarchy, by making it refer to subordinate protocols:
protocol CloudAdapterProtocol: ReggyCloudProtocol, ProReggyCloudProtocol {
var server: CloudServer {
get set
}
func getServerApiVersion(handler: #escaping (String?, Error?) -> Swift.Void)
}
In Server.swift I have
import Foundation
import UIKit
import Alamofire
import AlamofireImage
class Server: CloudAdapterProtocol {
.
.
func getServerApiVersion(handler: #escaping (String?, Error?) -> Swift.Void) {
.
.
}
Server.swift then just implements the core server API for setting the server and getting the API version. The real work is split into two files:
Server_ReggyCloudProtocol.swift
Server_ProReggyCloudProtocol.swift
These implement the respective protocols.
It means you need to have import declarations in the other files (for Alamofire in this example) but its a clean solution in terms of segregating interfaces in my view.
I think this approach works equally well with externally specified classes as well as your own.
Why is this even a debate? Should I put all my sub classes into a file called _Subclasses.swift. I think not. Swift has module based name spacing. To extend a well known Swift class needs a file that is specific to its purpose. I could have a large team that creates a file that is UIViewExtensions.swift that express no purpose and will confuse developers and could be easily duplicated in the project which would not build. The Objective-C naming convention works fine and until Swift has real name spacing, it is the best way to go.
This is more of a coding style question but i believe it is valid. Coming from an obj c background i always create a .h and a .m when creating a class. However with swift that changes and all that goes into a single file. I know that for some people this is cool but i miss having these two things separate.
Quoting a comment from Zaph
"What I miss is a list of public methods as opposed to searching an
entire source file for methods not marked private. There is a
programming concept of "writing to the interface". And the public
methods should be carefully picked, not just because the developer
forgot to make some private."
is there a way to have a header - implementation class in separate files using swift? Maybe some trick?
Thanks
May be you can use Generated Interface to view all the public methods and properties. You can find that option at the bottom of related files popup in the upper-left of the source editor window. To switch back, click Original Source in the same pop up.
Shortcut: control + cmd + down arrow
This is how generated interface file looks.
As far as i'm aware, this cannot be done. That being said, if set out your .swift files correctly then they are still very readable. I tend to follow this as a guideline for styling in swift and i find that it breaks things up into readable sections, especially by using // MARK: as well.
In short, no.. But what do you miss..? Once you get used to it, you will probably prefer it like this! The old separation has no clear advantage over this new one!
More and more languages use this approach, as it reduce coupling and errors.
So when you change the signature of a function, to need to check another file to update it, it's only duplication without any added value.
The problem you describe (how to see only "public" functions) is usually done buy tools( IDE) or documentation generators.
You can create 2 swift files:
YourClassNameHeader.swift
class YourClassName {// put here all your properties
}
YourClassNameMethods.swift or YourClassNamePrivate.swift
extension YourClassName { // put here all private methods and
properties }
But in general its not good practise
I found the excellent resource of the open source iOS GPX Framework (http://gpxframework.com/) which allows me to create and read GPX files. However I would like to add a custom extension to store data specific to my app. I can see that the GPX framework implements a file GPXExtensions.h and .m, but I am not sure how to go about adding say a tag for storing the speed data at a particular coordinate in the GPX.
I am guessing I would have to add the data I would like to add as an extension to the GPXExtensions class as a property and then somehow modify the code in this method:
- (void)addChildTagToGpx:(NSMutableString *)gpx indentationLevel:(NSInteger)indentationLevel
{
[super addChildTagToGpx:gpx indentationLevel:indentationLevel];
}
But I am not sure what this method is supposed to do, any ideas?
That's basically the right idea. Jaime Machuca's fork contains a commit where he added heart rate, etc. It should give you a pretty good template from which to create your own modifications. Note that if you want something more sophisticated, you may need to create your own subclass of GPXElement so that you can take advantage of the tree structure.
How do you add "objects" to an existing app ?
For example, the EasyRefresh for Chrome tweak, enables a new button inside the iOS Chrome app, as do many other tweaks.
How may i add a simple UIButton to, for example, the Twitter app ?
Is there any GitHub projects that might help me to understand how it's done ?
Image Source: ModMyI
Thanks.
The trick involves some (very basic) reverse engineering and is made up of several steps; I'll try to explain them as clearly as possible.
Step Zero: if the app is downloaded from the AppStore, it's encrypted. You have to decrypt it using one of the scripts/applications normally used to crack apps; one command line script is poedCrack.sh (google it, you'll find it quickly on one of the paste sites), one GUI application is Crakculous (it's available in Cydia). Note that one of these are needed for easy (automatic) decryption -- the manual decryption method is way too involved to put in a StackOverflow answer, that's why I'm suggesting these tools.) However, I don't in any way encourage you to crack apps! (Basically I'm asking you not to use these tools for their original purpose :) If you want to have a look at the manual decryption process, head here.
Step One: you need to do what classes the application uses/creates. For this, you need the class-dump or class-dump-z utility. This command-line application reverses the app's binary executable file and generates interface declarations for all Objective-C classes the app uses and has inside. You can find class-dump-z, the more advanced and preferred variant here.
Step Two: after you have the class declarations, you'll have to guess which class does what and when (yep, a bit confusing). For example, in one of the files generated from above app, Google Chrome, by class-dump-z, you may find something similar:
#interface ChromeUrlToolbar: UIToolbar {
UISearchBar *urlBar;
}
- (id)initWithFrame:(CGRect)frame;
- (void)loadURL:(NSURL *)url;
#end
Well, that sounds good, doesn't it? You can see that its implementation has an initWithFrame: method (as all UIView subclasses) -- why not try to modify it?
Step Three: for this modification, you'll need MobileSubstrate. MobileSubstrate is a developer library created by Saurik, the creator of Cydia, in order to make code injection to apps easy. You can find some really good tutorials on the web, including this one.
So, you've got a class and you wanna 'hook' it -- so you write some code like this:
static IMP __original_init; // A
id __modified_init(id __self, SEL __cmd, CGRect frame) // B
{
__self = __original_init(__self, __cmd, frame); // C
// D
UIButton *newButton = [UIButton buttonWithType:UIButtonTypeRoundedRect];
[newButton setTitle:#"Chrome Pwned"];
newButton.frame = CGRectMake(0, 0, 100, 40);
[__self addSubview:newButton];
return __self;
}
// E
__attribute__((constructor))
void init()
{
Class clazz = objc_getClass("ChromeUrlToolbar"); // F
MSHookMessageEx(clazz, #selector(initWithFrame:), __modified_init, &__original_init); // G
}
Explanation: let's begin from the end. The init function (E) is declared __attribute__((constructor)). That means it's automatically called when the library we'll create out of this code will be loaded into Chrome. That's exactly what we want beause we want to alter our application's behavior prior to having started it.
On the line marked // F, we capture the class object itself we want to modify. Objective-C is a highly dynamic language; that means we can get and modify information about the classes and objects at runtime. On the line marked // G, we use the most important function of the MobileSubstrate API: MSHookMessageEx. To understand how it works (rather what it does), you must know the following: Objective-C itself is implemented as a plain C library -- the language itself, under the hoods, is just simple C. So every message send in Obejctive-C is actually a C function call. These C function have two special arguments: self and cmd -- the former is the pointer to the object being messaged, the latter is the selector (a special, unique pointer to the name of the message being sent). So what MSHookMessageEx does is it takes a class and a selector, finds the implementation of the function corresponding them, and exchanges that function with the function supplied in its 3rd argument itself (__modified_init in this case). In order not to lose data, it also returns the function in its 4th parameter (here it's __original_init).
So, now the initialization of the Chrome URL toolbar is redirected to our function, what to do next? Well, nothing special: first we just call the original initialization function (notice the first two special arguments, __self and __cmd!) which creates the toolbar as if normally (this line of code is denoted by // C). Then, we do the actual alteration: in section // D, we create an UIButton, set its title and place, and add as a subview to our freshly created toolbar. Then, knowing this is an initalization function, we return back the original instance along with our button's code injected into it.
Well, that's basically what you'll need to know about this; if you're interested in deeper details of how Objective-C works and how you can create cool iOS tweaks, I suggest you to read Apple's official documentation on the topic and you can browse through some of my opensource Cydia tweaks. as well.
I hope this will help you!
You need in order to do this to understand how the Objective-C runtime works. Especially the messaging system (ie. calling a method). In particular, the methods to call are determined at runtime, vs other languages where it is at compile time.
This allows for global changing of particular methods, aka method swizzling.
Using the Mobile Substrate library you will be allowed to replace any method implementation with your own, and even call the original implementation. You need for that, of course, to know the method's name and the argument it takes, as well as the class it belongs to.
So to modify the SpringBoard for instance, you'd have to know which class in contains and which method. You'll have to use the class-dump or class-dump-z utility which does that for you (class-dump-z is more recent and more used for iOS dev, class-dump is more versatile and compatible with older binaries as well as 64 bit).
So to class-dump the SpringBoard, you'd need to enter in Terminal.app
class-dump -H /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/System/Library/CoreServices/SpringBoard.app/SpringBoard -o ~/Desktop/SpringBoard
For class-dump-z, the -p option will generate #property instead of getters/setters, which is more clear, so you'd probably type in
class-dump-z -p -H /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/System/Library/CoreServices/SpringBoard.app/SpringBoard -o ~/Desktop/SpringBoard
That line will create a folder on your desktop with all the classes definitions of SpringBoard.
Of course you might need to change path to one suited to your system (about that, for recent versions of Xcode, the Developer folder is in Xcode, so you'd need something like
/Applications/Xcode/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk/System/Library/CoreServices/SpringBoard.app/SpringBoard
You can also find on the internet people who did that for you for most of the existing frameworks, this is pretty handy if you make sure they are at the right version for you're system.
Now, for AppStore applications, you will first need to decrypt them as they are protected. You will probably need to find the names and links of that yourselves as this is probably against the ToS of Stack Overflow, though using gdb can achieve that purpose.
To ease the work, some tools such as Logos (you will probably also need to see Theos) has been created that reduce the boilerplate code needed. There also is a (quite old) xcode template & tutorial for mobilesubstrate that provides good help.
Logos makes it easy to hook method method from class classname :
%hook classname //declares the class from your application you're going to override
-(void)method {
dosomethingnew(); //put all your new code for the method here
return %orig; //this calls the original definition of the method
}
%end //end hooking classname
For a list of the frameworks in the system and what they are usefull to, see here
Last thing : a list of popular tweaks that are opensourced (links to GitHub when possible) :
Chrome Customizer
MobileNotifier
UISettings (iOS 5 version was here also but seems to be pulled ?)
Spire
IconRenamer
Maxoimizer
IconRotator
QuickReply
WinterBoard
Veency
Some little tweaks
Finally, have a look at the WeekTweak, they release opensource tweak each week so you can learn by looking at someone else's source to try & do your own stuff. And the #theos chan on IRC (irc.saurik.com) will also provide help if you ask it kindly.