Making life easier for a mobile game developer

Hi everyone,

Making a good game is far from all the work. In order to get a finished product that can be successfully distributed, you need to integrate various kinds of marketing tools into the game: tracking referral settings, banner twists and off-routes, modules for subscribing to newsletters and showing other good games, various affiliate SDKs, etc. etc. In this post I will tell you what tools for this we use in Alawar we and our developers. Take our iOS projects as an example.

Having analyzed the main marketing tools that are used in the market, we have identified some groups of tools that share common features. For example, almost all such SDKs require session initialization in the application: didFinishLaunchingWithOptions: or applicationDidBecomeActive: methods. All install trackers are also practiced there.
Push notifications are always registered with the same calls.
Referral trackers usually need information after a successful in-app. And in-ups themselves need to be validated.
And usually you also want to “overweight” all these same places with events for collecting statistics, for example, through Flurry.

It is also worth noting that these tasks are common to all projects, the differences are only in IDs and other apiKeys for third-party services.

Gamedev for iOS is designed so that without marketing - nowhere. But developers in the first place should (and want) to think and work directly on the game, and not bother with the “marketing kit”. To make this possible, publishers provide their developers with various SDKs, frameworks, etc. Alawar is no exception. We have prepared the Alawar iOS Framework, which includes all the necessary marketing modules for the current versions and "does a little magic."

The “little bit of magic” is answered by the wonderful Objective-C runtime and its code mixing capabilities.

So, for example, to start sessions for several SDKs in the application: didFinishLaunchingWithOptions: method, we need to “intercept” this call from the Application Delegate and add our implementation to it. To do this, create a category over UIApplication, catch the setDelegate method:

@interface UIApplication(AlawarFramework)
@end
@implementation UIApplication(AlawarFramework)
+ (void) load {
	method_exchangeImplementations(class_getInstanceMethod(self, @selector(setDelegate:)), class_getInstanceMethod(self, @selector(af_setDelegate:)));
}
- (void) af_setDelegate:(id)delegate {
	Method method = nil;
	method = class_getInstanceMethod([delegate class], @selector(application:didFinishLaunchingWithOptions:));
	if (method) {
		class_addMethod([delegate class], @selector(application:AFDidFinishLaunchingWithOptions:), (IMP)AFdynamicDidFinishLaunching, "v@:::");
		method_exchangeImplementations(class_getInstanceMethod([delegate class], @selector(application:didFinishLaunchingWithOptions:)), class_getInstanceMethod([delegate class], @selector(application:AFDidFinishLaunchingWithOptions:)));
	} else {
		class_addMethod([delegate class], @selector(application:didFinishLaunchingWithOptions:), (IMP)AFdynamicDidFinishLaunching, "v@:::");
	}
	// устанавливаем "родного" делегата
	[self af_setDelegate:delegate];
}
BOOL AFdynamicDidFinishLaunching(id self, SEL _cmd, id application, id launchOptions) {
	// вызываем "родной" метод, если был реализован
	if ([self respondsToSelector:@selector(application:AFDidFinishLaunchingWithOptions:)]) {
		result = (BOOL) [self application:application AFDidFinishLaunchingWithOptions:launchOptions];
	} else {
		[self applicationDidFinishLaunching:application];
		result = YES;
	}
	// тут инициализируем библиотеки, стартуем сессии и т.д.
	return result;
}
@end

Similarly, we mix work with third-party libraries in applicationDidBecomeActive, initialize push notifications, etc.

Developers can only add a framework to their Xcode project and set the linker flag –all_load.

A slightly different situation with in-app, their validation and registration in referral trackers and statistics. Here we solved another side problem. Developers conduct initial testing under their Apple account and with some in-app IDs, and when passing through the QA in publishing and publishing, another account and other IDs are used.

To solve these problems, we implemented our API “wrapper” over the StoreKit API and additional protocols for notifying delegates about the results of payment validation. In this case, all product identifiers are placed in a separate configuration config.

Thus, the developer uses an API similar to StoreKit, but already without the need to weigh purchases with statistics, independently implement validation, etc.

At the end of the article, we note that we also provide similar tools for the Android platform.