I have this idea for an app that I would totally use myself. You know I started XcodeJobs.com and the @XcodeJobs twitter feed to go with it to have a channel to retweet all the iOS-related job offerings that flow before my very eyes. For the site I’ve been talking to people to create a login for themselves and post their jobs self-servingly. For the twitter feed I’ve been using the Twitter search features with a variety of search terms to find tweets where company owners of the developers themselves are tweeting about job postings.

Now the reality of the matter is that most of all Tweets are from recruiters, agencies, job sites and other kinds of services that a self-respecting iOS developer does not want anything to do with. So right now I’m manually filtering tweets. There are a variety of criteria that I want to be able to combine to end up at the real good retweet-worthy tweets.

For example I would do a search for “hiring iOS” …

Criteria for exclusion might include:

• Jack Patrick I found to be a recruiter
• Jobely.com and Jobrep.com are examples for job websites
• The jobmakesfun is pointing to a Freelancer site with a ridiculous project description.
• The one for Viki is pointing to a dubious URL that does not seem to correspond with the hiring company.

On the above screenshot the one tweet by Fable Technologies is the only one I deemed worthy of retweeting. It does not contain link bait, is by the guys for themselves, no commercially interested middle man in sight and they are so daring as to even post their e-mail address.

All of these manual steps surely can be automated. I’m envisioning several black lists of twitter accounts that I want to ignore. And the second big category would be to ignore tweets that are leading to job sites (like Bullhorn Reach) or agencies. The user (i.e. myself) could configure multiple elaborate search queries and have the app filter out all the crap. So ideally this would leave us with the true gems of Twitterdom.

What Twitter Engine to Use?

So I sat down in front of my home iMac and started to think to myself: “OMG that will be hell of a job. Maybe I should go look for a good Twitter engine to use first.”

The reason for this train of thought was that nowadays most of the interaction with the Twitter REST API has to be authenticated via OAuth. Which is why there are a bunch of OAuth frameworks in the wild, including one from Google because their APIs are OAuth-heavy as well. OAuth basically works by having a secret token that you have to add to all URL requests that need authentication. Of course one could program this from scratch but you’d certainly spend quite some time on this. Even using a third party OAuth library would not be straightforward because of the time it takes to figure out how to include it in your app.

All of these reasons would make this small project unrealistic for a couple of stolen hours on a Sunday.

Some people recommended MGTwitterEngine, but then it dawned on me that there was something new that Apple had introduced with iOS 5. So I checked the SDK documentation and – indeed! – besides the TWTweetComposeViewController that everybody now knows about there is a second class that is exactly what we need: TWRequest.

Tw…TW…TWRequest?

Hidden behind the simplest of names is a wrapper that you can do any kind of request with. Think of it as a block-based wrapper around NSURLConnection with all the trimmings needed to also do authentication where necessary.

Let’s dive right in, and start by doing a simple search. We added the Twitter.framework to the linked libraries and in the class where we want to call TWRequest we added <Twitter/Twitter.h>. I prefer to put that in the PCH file so that it is available everywhere without needing an extra inclusion of the header.

The search itself is deceptively simple:

NSURL *searchURL = [NSURL URLWithString:@"http://search.twitter.com/search.json"];
NSDictionary *parameters = [NSDictionary dictionaryWithObject:@"hiring ios" forKey:@"q"];
TWRequest *request = [[TWRequest alloc] initWithURL:searchURL parameters:parameters requestMethod:TWRequestMethodGET];
 
[request performRequestWithHandler:^(NSData *responseData, NSHTTPURLResponse *urlResponse, NSError *error) {
    if (responseData)
    {
        NSError *parseError = nil;
        id json = [NSJSONSerialization JSONObjectWithData:responseData options:0 error:&parseError];
 
        if (!json)
        {
            NSLog(@"Parse Error: %@", parseError);
        }
        else
        {
            NSLog(@"%@", json);
        }
    }
    else
    {
        NSLog(@"Request Error: %@", [error localizedDescription]);
    }
}];

To perform a Twitter request you need to have a couple of ingredients, which you can glean from the Twitter API Documentation, for example for the search function.

We needed the URL which is a composite of:

• the so-called endpoint: http://search.twitter.com
• the method name: search
• the response data format: json

The parameters need to be provided in a dictionary which is also straightforward, the keys are the parameter names and the values are the parameter values. Also we don’t need authentication for search, in fact it is not even supported according to the Twitter docs. This is to make it impossible for Twitter to track you based on what you search for… unlike Google.

TWRequests supports the three HTTP verbs GET, POST and DELETE. The documentation tells you which one to use. Note that different API functions might have different end points.

We could have also chosen xml format for the response format, but there is no simple way to transform that into something useful for us. NSXMLParser works event-based and we would have to do some work to get it into a structure. The second ingredient that we need is also new with iOS 5, Apple provides a handy high performance class to serialize and deserialize JSON data.By passing the responds of the TWRequest into NSJSONSerialization we get an NSDictionary containing the parsed JSON. With JSON and the de-serialization method provided we get a dictionary which is way more convenient.

If the deserialization worked you get a non-nil result, looking like this:

{
    "completed_in" = "0.027";
    "max_id" = 204150933297446912;
    "max_id_str" = 204150933297446912;
    "next_page" = "?page=2&max_id=204150933297446912&q=hiring%20ios";
    page = 1;
    query = "hiring+ios";
    "refresh_url" = "?since_id=204150933297446912&q=hiring%20ios";
    results =     (
                {
            "created_at" = "Sun, 20 May 2012 10:05:50 +0000";
            "from_user" = "fun_programming";
            "from_user_id" = 282845320;
            "from_user_id_str" = 282845320;
            "from_user_name" = jobmakesfun;
            geo = "";
            id = 204150933297446912;
            "id_str" = 204150933297446912;
            "iso_language_code" = en;
            metadata =             {
                "result_type" = recent;
            };
            "profile_image_url" = "http://a0.twimg.com/profile_images/1313148959/jobs_normal.gif";
            "profile_image_url_https" = "https://si0.twimg.com/profile_images/1313148959/jobs_normal.gif";
            source = "<a href="http://twitterfeed.com" rel="nofollow">twitterfeed</a>";
            text = "#ipad #project iOS Game Side Scrolling Battle by olimoli123: I require someone to make a game like ... http://t.co/LNqWsmLs #dev #hiring";
            "to_user" = "";
            "to_user_id" = 0;
            "to_user_id_str" = 0;
            "to_user_name" = "";
        },
                {
            "created_at" = "Sun, 20 May 2012 08:18:14 +0000";
            "from_user" = XcodeJobs;
            "from_user_id" = 539747758;
            "from_user_id_str" = 539747758;
            "from_user_name" = "Xcode Jobs";
            geo = "";
            id = 204123856812785665;
            "id_str" = 204123856812785665;
            "iso_language_code" = pl;
            metadata =             {
                "result_type" = recent;
            };
            "profile_image_url" = "http://a0.twimg.com/profile_images/1988345754/xcode-twitter_normal.png";
            "profile_image_url_https" = "https://si0.twimg.com/profile_images/1988345754/xcode-twitter_normal.png";
            source = "<a href="http://angel.co" rel="nofollow">AngelList</a>";
            text = "RT @CardFlick: CardFlick (@CardFlick) is hiring a iOS Engineer http://t.co/O7Wf0gtw";
            "to_user" = "";
            "to_user_id" = 0;
            "to_user_id_str" = 0;
            "to_user_name" = "";
        },...

We get the tweets in an NSArray below the “results” key, each tweet being represented by an NSDictionary. If we wanted to refresh the contents of this query we could use the value stated in “refresh_url”. Then we would only see tweets that were made after the ones we had already gotten here.

Also results are paginated. To retrieve subsequent pages there is a “next_page” value that would get us those. The default is to return 15 tweets per “page”. We could easily also increase this number by passing it as the optional “rpp” (results per page) parameter.

Later the same day …

I’m skipping over the part where I’m merging the result dictionary into a CoreData database and using an NSFetchedResultsController to display the tweets. That is a different story which I shall treat another day. Let’s just say, I got it to display in a very basic form and pushing a refresh button would redo the same query and merge the results into a database.

After getting all the basics wired up (CoreData Stack, methods to query by ID for user and message, merging function, table view controller, fetched results controller) I ended up with a view like this:

It is immediately apparent from this that we are seeing only tweets that we want to get rid of. 4 of these Twitter accounts would be blacklisted because of the reasons stated above. Also my own tweets are visible as they came from my own account and start with RT, those where the job tweets I had retweeted. OMG the amount of time this tool will save me not having to visually scan through all of this…

But like every TV cook I’ve already prepared this step as the details are of no interest for this tutorial. I added a long press gesture recognizer to each cell and a red “Blacklist” button that allows me to mark the TwitterUser as blacklisted and remove his tweets from the database. This results in a tremendous improvement.

Oh, look! Fable Technologies is at the top after having blacklisted all the clutter. They should pay me a referral fee for all this free advertising!

Now for the hard part of this tutorial. Now that we have leaned up the result, we also want to be able to retweet individual messages and of course somehow know if we have done so already to prevent a double-retweeting. Unfortunately there does not seem to be an easy we to get the retweet info included in the search results.

Dealing with Accounts

In order to do something that requires authentication we need to ask the global account store for a list of Twitter accounts and have the user pick one. First we add the Accounts.framework in our build phases. Then we add <Accounts/Accounts.h> to our PCH file.

The first time we want access to a given account type (as of iOS 5 only Twitter is supported) we need to ask the user’s permission. Subsequently we can query the ACAccountType if permission has already been given.

- (void)account:(UIBarButtonItem *)sender
{
    ACAccountStore *accountStore = [[ACAccountStore alloc] init];
    ACAccountType *accountType = [accountStore accountTypeWithAccountTypeIdentifier:ACAccountTypeIdentifierTwitter];
 
    if ([accountType accessGranted])
    {
        // have access already
        [self _showListOfTwitterAccountsFromStore:accountStore];
    }
    else
    {
        // need access first
        [accountStore requestAccessToAccountsWithType:accountType withCompletionHandler:^(BOOL granted, NSError *error) {
 
            if (granted)
            {
                [self _showListOfTwitterAccountsFromStore:accountStore];
            }
            else
            {
                UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Error" message:@"Cannot link account without permission" delegate:nil cancelButtonTitle:@"Ok" otherButtonTitles:nil];
                [alert show];
            }
        }];
    }
}

There is no shared instance of the ACAccountStore, so we have to create our own with alloc/init. Then we create the ACAccountType for Twitter and check if we might already have access granted. If not then we ask for it passing a completion handler. For sake of simplicity I opted to just show an action sheet for all the configured accounts. This does not deal with the situation of no configured accounts.

- (void)_showListOfTwitterAccountsFromStore:(ACAccountStore *)accountStore
{
    ACAccountType *accountType = [accountStore accountTypeWithAccountTypeIdentifier:ACAccountTypeIdentifierTwitter];
    NSArray *twitterAccounts = [accountStore accountsWithAccountType:accountType];
 
    UIActionSheet *actions = [[UIActionSheet alloc] initWithTitle:@"Choose Account to Use" delegate:self cancelButtonTitle:@"Cancel" destructiveButtonTitle:nil otherButtonTitles:nil];
    actions.tag = 2;
 
    NSMutableArray *shownAccounts = [NSMutableArray array];
 
    for (ACAccount *oneAccount in twitterAccounts)
    {
        [actions addButtonWithTitle:oneAccount.username];
        [shownAccounts addObject:oneAccount];
    }
 
    _shownAccounts = [shownAccounts copy];
 
    [actions showInView:self.view];
}

Since I don’t have any block-based action sheet handy I need to remember the list of accounts presented in _shownAccounts IVAR and then in the delegate method for the action sheet I can pick the correct one based on the index. The important thing here is that we end up with an instance of a ACAccount.

Now Let’s Sign This…

Let’s quickly check the Retweet API and what we need to perform such a request.

Just like above for the search we need to construct a URL from these parts:

• the endpoint: http://api.twitter.com/1
• the method name: statuses/retweet
• the identifier of the tweet to retweet: some number
• the response data format: json
• no parameters necessary

Here I stumbled across something that was not immediately obvious to me. You have to store the ACAccountStore in an instance variable. Otherwise the ACAccount’s ACAccountType will be released by the autorelease pool. At let’s that’s what happened to me, I got a memory exception and an authentication error in alternation. Could it be that there’s a bug in the Accounts framework? Seems to me that the accountType property of ACAccount should be a strong reference, but it isn’t.

But that aside, there’s no hurt making an IVAR for the account store, the function to retweet would then look like this:

- (void)_retweetMessage:(TwitterMessage *)message
{
    NSString *retweetString = [NSString stringWithFormat:@"http://api.twitter.com/1/statuses/retweet/%@.json", message.identifier];
    NSURL *retweetURL = [NSURL URLWithString:retweetString];
    TWRequest *request = [[TWRequest alloc] initWithURL:retweetURL parameters:nil requestMethod:TWRequestMethodPOST];
    request.account = _usedAccount;
 
    [request performRequestWithHandler:^(NSData *responseData, NSHTTPURLResponse *urlResponse, NSError *error) {
        if (responseData)
        {
            NSError *parseError = nil;
            id json = [NSJSONSerialization JSONObjectWithData:responseData options:0 error:&parseError];
 
            if (!json)
            {
                NSLog(@"Parse Error: %@", parseError);
            }
            else
            {
                NSLog(@"%@", json);
            }
        }
        else
        {
            NSLog(@"Request Error: %@", [error localizedDescription]);
        }
    }];
}

There are three differences here versus the search request. 1) this one is a POST, 2) there are no parameters and 3) we set the account property to the ACAccount we have selected earlier. And if this works we indeed see the retweets show up immediately.

If you get an authentication error, then there’s a problem with the ACAccount. If you get some error complaining that this cannot be done with the given tweet, then most likely you have already retweeted it before. And in case of success you get a response with some retweet status.

Conclusion

There are a couple more touches necessary to make this app really useful. For one, we also need to retrieve the timeline of own retweets to be able to mark the tweets we already looked at. Also the retweet response should somehow be used to mark the tweet as retweeted.

And of course the UI could use much more work. We want to asynchronously show the profile pictures, access and edit the blacklist, decode the shortened URLs and make a blacklist based on those and of course be able to specify multiple search query for a given topic. For the UI I’ll probably use my DTCoreText method that lets me render the tweets with interactive hyperlinks.

But the gist of this post is that if you know about the Twitter and the Account frameworks then it is quite easy to build your own specialized Twitter client. We can extend a heart-felt “Thank You!” to the engineers at Apple who built something as useful as these into the operating system. Interacting with Twitter couldn’t be easier!

My guest Paul Dunahoo won one of 150 Apple WWDC Student scholarships. We talk about what he did to win it, some hopes for iOS 6 and I share some of my tips for how to make your first WWDC more enjoyable.

Interview

Paul Dunahoo, 13. From Connecticut.

• Homepage
• PADGuy1 on Twitter
• Note Taking App Scrawl on App Store
• WWDC Scholarships Official Rules

PS: Right after we recorded the show he got a phone call from Apple. “Parents can go, but not to the keynote or sessions”.

There’s a bug – it seems – in Xcode 4.3.2 that was causing an issue with my DTBannerManager component. I’m documenting the workaround here and how to recognize that you are experiencing the bug.

DTBannerManger – a component to unite iAds, MobFox and Google AdMob – has a subfolder Externals that contains a clone of the MobFox iOS SDK from GitHub. Since the component only links in the Static Library product of the MobFox Xcode project this is the only file that I had added to my project. No use in adding any other superfluous files, right?

The first symptom of the issue was that you would get a weird ARC-related Warning: “Sending DTBannerManager *const __strong” to parameter of incompatible type “id <MobFoxBannerViewDelegate>”

Well, what do we do if we get a warning on a setDelegate:self? We check the header to see if the class is defined to comply with the protocol. There I found that the <MobFoxBannerViewDelegate> protocol declaration was missing. So we added that plus the import for the header where this protocol is defined.

Here’s a bit of a WTF. Why does it not find the header?

So next I went and checked the search path for the headers. I was pretty sure that this was working as of Xcode 4.3. The header search path is in the build settings:

This is set up correctly. The path from the project root is Core/Externals and the double asterisks mean that it should be searching recursively. And as I said before, this was working perfectly before.

The workaround is quite simple, but it’s not obvious. I only found it out myself after messing around for over an hour with a client who was having the same issue setting up my DTRichTextEditor as sub-project in one of his apps.

You need to add the header that cannot be found to the project, even though it is not associated with any targets. Apparently this is necessary for the Xcode indexer to be able to “see” the header.

That’s all it takes. I hope you remember reading about this workaround if you ever happen to stumble across this Xcode bug. I did so twice so far.

Episode 36, recorded Sunday May 6th, 2012

In this episode my special guest is Will Kiefer. He is the Senior iOS Engineer in charge of Google Currents. Will tells us why UIWebView isn’t all that bad and has some amazing performance tips for us with which to tame it. You should make lots of notes and you will feel like you visited a lab at WWDC and had your brain supercharged.

Show Notes

Google Currents iOS app on the app store, recently available internationally.

Performance Notes:

• Cache UIWebViews, saves time on setup
• When profiling also look at CoreAnimation tool and VM tracker
• JavaScript is slow (e.g. JQuery), because JIT compiler is not available for web views
• Avoid changing the frame of web views, that causes it to do overtime
• When communicating from web view to Objective-C it is faster to change the hash on a small hidden iframe
• The frame of a web view should be smaller than the size of the screen, or if that is not possible have a clipping view
• NSURLProtocol is a better choice for caching than NSURLCache because it is concurrent
• With CoreData Will has one MOC for UI stuff and a second for updating in background, changes are then merged in by UI MOC

Google Currents Producer Tool, requires Chrome at present.

Will Kiefer on Twitter, on Google+

I’m “totally” migrating my iCatalog framework project to ARC, GCD and blocks and I’d like to share with you some of the revelations that the use of these modern technologies brings with them.

Here are two examples of the kind of simplifications you will see if you do the same. This approach is compatible with iOS 4.0 and above.

Executing a Multi-Parameter Method on Main Thread

I was looking for instances of performSelectorOnMainThread so that I could replace them with a dispatch_sync on main_queue instead. Previously when calling methods that take more than one parameter you had to jump through hoops.

Before:

- (void)reportAddProduct:(Product *)product toBagAs:(BagItem*)bagItem
{
	SEL selector = @selector(onlineIntegrationManager:willAddProduct:toBagAs:);
	if ([delegate respondsToSelector:selector])
	{
		NSMethodSignature *signature = [self methodSignatureForSelector:selector];
		if (!signature) 
		{
			return;	
		}
 
		NSInvocation* invocation = [NSInvocation invocationWithMethodSignature:signature];
		[invocation setTarget:delegate];
		[invocation setSelector:selector];
		[invocation setArgument:&product atIndex:2];
		[invocation setArgument:&bagItem atIndex:3];
		[invocation retainArguments];
		[invocation performSelectorOnMainThread:@selector(invoke) withObject:nil waitUntilDone:YES];
	}
}

After:

- (void)reportAddProduct:(Product *)product toBagAs:(BagItem *)bagItem
{
	if ([delegate respondsToSelector:@selector(onlineIntegrationManager:willAddProduct:toBagAs:)])
	{
		dispatch_sync(dispatch_get_main_queue(), ^{
			[delegate onlineIntegrationManager:self willAddProduct:product toBagAs:bagItem];
		});
	}
}

The handy dispatch_sync on main queue can call any method, with any number of parameters on the main thread. The sync is equivalent to the waitUntilDone:YES. Since this allows for putting the main thread code inline you no longer need to have special methods that you then performSelectorOnMainThread:.

As a second note I found that it calls to the main thread should generally be done synchronously because I had a situation where a UILabel would not get updated if I did waitUntilDone:NO. Having everything as dispatch_sync now also takes care of that.

Abusing the UIView Animation Context

Before we had block based animation I would find myself often passing some context to the animationDidStopSelector so that I can do some wrap-up work when the animation is done. This is quite unsafe, even ARC complains about that unless you add a (__bridge id) to tell it to ignore the memory management of this object.

Context parameters didn’t get retained as a rule of thumb. In this example I needed to remove a view that has been animated out also from an internal dictionary after it was done. Having a dedicated instance variable would not have been an option because you could potentially have multiple animations going on at the same time.

Before:

- (void)removalAnimationDidStop:(NSString *)animationID finished:(NSNumber *)finished context:(void *)context { UIView *removedView = (__bridge UIView *)context;   for (NSNumber *oneKey in [self.viewsForItems allKeys]) { UIView *view = [self.viewsForItems objectForKey:oneKey];   if (view == removedView) { [removedView removeFromSuperview]; [self.viewsForItems removeObjectForKey:oneKey]; } } }   // the above being called by:   for (id oneItem in itemsToRemove) { // we must have a view for this item to remove it __unsafe_unretained UIView *itemView = [self viewForItem:oneItem];   if (animated) { [UIView beginAnimations:@"ItemRemoval" context:(__bridge void *)itemView]; [UIView setAnimationDuration:deleteAnimationDuration]; if (delaySoFar>0) { [UIView setAnimationDelay:delaySoFar]; } [UIView setAnimationBeginsFromCurrentState:YES]; [UIView setAnimationDidStopSelector:@selector(removalAnimationDidStop:finished:context:)]; [UIView setAnimationDelegate:self]; }   itemView.alpha = 0; itemView.transform =CGAffineTransformMakeScale(0.5, 0.5);   if (animated) { [UIView commitAnimations]; }   delaySoFar +=deleteAnimationOffset; }

After:

// moved into a convenience method - (void)removeCachedView:(UIView *)removedView { for (NSNumber *oneKey in [self.viewsForItems allKeys]) { UIView *view = [self.viewsForItems objectForKey:oneKey];   if (view == removedView) { [removedView removeFromSuperview]; [self.viewsForItems removeObjectForKey:oneKey]; } } }   // called from:   for (id oneItem in itemsToRemove) { // we must have a view for this item to remove it __unsafe_unretained UIView *itemView = [self viewForItem:oneItem];   [UIView animateWithDuration:(animated?deleteAnimationDuration:0) delay:(animated?delaySoFar:0) options:UIViewAnimationOptionBeginFromCurrentState animations:^{ itemView.alpha = 0; itemView.transform =CGAffineTransformMakeScale(0.5, 0.5); } completion:^(BOOL finished) { [self removeCachedView:itemView]; }];   delaySoFar +=deleteAnimationOffset; }

A boolean animated value can easily be replaced with a duration of 0. Animation delays are passed in the appropriate method and the beginsFromCurrentState is now a UIViewAnimationOption. This method is way safer because the blocks “capture” (i.e.) retain all the used variables making it impossible for the thing that was previously passed via the context to already been deallocated.

Conclusion

Sorry for not having more wise words to add here. The beauty of the possible simplifications you get if you decide to make iOS 4 your minimum deployment target should speak for itself.

When shrink-wrapping your code for later reuse you inadvertenly will come into the situation that you have some resources (strings, XIBs, images et al) in your project that you also want to be reused. So what do you do?

If only we had frameworks on iOS … then we could bundle the resources together with the code in a framework. But Apple does not want us to compile frameworks in Xcode since these could potentially contain code downloaded after the app review process.

Popular projects like ShareKit or the Facebook iOS SDK have approached this dilemma by simply putting all resources into a folder, giving it the “.bundle” extension and instruct users of their SDK to also add this bundle to the “Copy Bundle Resources” step of their respective apps.

In this here blog post I will show you a smarter way.

There are several problems with having resources contained in a bundle and having this bundle be a member of any projects.

Not Visible

Xcode does not directly “see” the contents of the bundle, instead the pbxproj only contains a reference to the bundle folder. This causes trouble for apps like our Linguan that parses the project file to find strings (and soon XIB) files. It simply cannot see them.

Here’s how it looks in the ShareKit project. If you ever see a x.bundle in a project you open, armed with the knowledge in this article, your reaction should be “that’s bad”.

Of course the maintainers of these projects “have their reasons”. But I hope that by reading this you will agree with me that the reasons to not do it like this are better.

Not Optimized

Another issue is that this approach effectively disables the build time optimizations that Xcode carries out on the resources.

• strings files get converted into binary property lists
• XIB files get compiled into binary NIBs
• images get pngcrush-ed
• and many other actions for which there are build rules set up

That means resources that are simply bundled (by means of copying them together) are slower and not optimized for the mobile devices. You probably wouldn’t notice that for only a hand full of items, but if you have a large number of resources then these delays will add up slowing down your app. And even if that does not bother you very much then the engineer inside of you should cringe. It just feels so dirty…

Not Updating

Another reason for why it is a bad idea to hide files from Xcode is that it simply won’t know to rebuild your app if you make a change in one of the files hidden in such a bundle.

The Xcode build system has what is called dependencies. Implicit dependencies are source code files and resources that are part of certain targets. If such a dependence is modified then the incremental build process can determine which parts need to be re-compiled or re-optimized.

Say you change something in a single .m file. Xcode will not rebuild the entire app, but only create the .o for this updated file and then link it with the previously built (and unchanged .o files). Same with resources. Xcode only replaces resources in the output product .app bundle if it knows they where modified.

Resources in static bundles are invisible to Xcode and thus you always have to clean your build folder when doing a new build after changing them. Otherwise your updates will not propagate into your app.

Enter the Resource Bundle Target

Xcode, iOS and OS X have a mechanism to deal with folders that are looking like a single file but are actually containing multiple resources. This mechanism is modeled by the NSBundle class. You probably have worked with bundles before, namely the .app bundles that make up your app. Have you ever written [NSBundle mainBundle] before? I bet you did.

For NSBundle to be able to manage bundles it requires a special info.plist inside the bundle that contains some meta information, like an internal identifier. But once you have the bundle set up correctly you have multiple great options for getting at the files as I will show you below.

How to Set Up a Resource Bundle Product

A resource bundle is a product that we will set up a target for. It just so happens that my DTPinLockController project is in need of some love, so it will serve as our example for this tutorial.

As a first step I needed to move the files into the modern way of structuring my projects. That is, for component projects I have a Core and a Demo folder at the project root. Then each has a Source and a Resources sub-folder. DTPinLockController has XIBs, Images and Localizable.strings files.

The source code goes into a Static Library target. All resources go into a Resource Bundle target. I’ve omitted the setup for the library here as we want to focus our attention on the resources.

Next we need to set up the Resource Bundle target. The template for this can be found in the OS X section, under “Framework & Library”.

When removing the dynamic framework template Apple also removed the template for the Bundle. But with some minor modifications we can change the Mac bundle into one suitable for iOS. Since our bundle will not contain any executable code we don’t care about the settings for ARC and which foundation we want to use.

I like to name the bundle product that same as my component so that in the end I have a DTPinLockController.bundle containing my resources and a libDTPinLockController.a library to go with it.

The template creates 3 files in DTPinLockController:

• an empty InfoPlist.strings file, we don’t need that
• a DTPinLockController-Info.plist file, this is the META plist we need
• a DTPinLockController-Prefix.pch file. No code in bundle means we can also remove that.

I grab the plist and move it in to the root of my resources folder. The rest we can safely remove. I also rename it to Resources-Info.plist as to give an unsuspecting observer a hint that this is for the resource bundle.

We use this approach because the info plist for the resource bundle is too long to manually create. Note that there are several placeholders that get filled in during the build process, like the bundle name. All these settings come from the build settings which we are going to adjust next.

The default setting is to use the target name as name of products. I don’t like this because as I said about I want several products to be named DTPinLockController, but have the targets reflect their actual purpose.

Because of this I end up with 3 targets with descriptive names like “Demo App”, “Static Library” and “Resource Bundle”. These have different product names “Demo”, “DTPinLockController” and “DTPinLockController” respectively. The different extensions and the prefix “lib” are automatically added by Xcode.

There are all the modifications we need to do on the build settings for the resource bundle:

• CMD-Backspace on the Base SDK to have it be the same as for the entire project: Latest iOS
• Same on the “Mac OS X Deployment Target”
• Same on the Architectures
• Remove the reference to the PCH file
• Remove “Installation Directory”
• Set “Skip Install” to YES
• Adjust “Info.plist File” to the correct path, e.g. Core/Resources/Resources-Info.plist

The important part is the correct paths for the info plist and pch (none) and that Skip Install is YES because otherwise you get problems when trying to archive an app using the resource bundle. Since there is no code the compiler-related settings are really inconsequential, but I like to have them inherit from the project settings to have it look like a native iOS target.

In the build phases of the bundle target there is still a framework in “Link Binary with Libraries”. Remove this as well. It does not hurt as there is nothing to link it with, but might be confusing.

The final step for building the target is now to add the resources to it. You select the appropriate files in the project tree and set the checkmark in the right panel next to Resource Bundle.

Xcode has added a scheme for the new target with the original name. So I remove all schemes and auto generate them from scratch. This will create one scheme per target and name them the same as the targets.

Then we can try and see if the bundle builds correctly.

you can open up each build step and see that Xcode carried out the optimizations I alluded to above. In the case of this strings file you see –outputencoding binary that tells us that the strings file in the bundle will actually be binary.

You now have a DTPinLockController.bundle in the Products group that you can inspect to verify that this indeed is the case.

Using the Resource Bundle

There is a bug in Xcode 4.3.2 that might cause the list of resource to copy for the app target might get out of sync with the check marks in the project navigator. I had to manually go in the build phases of the demo app target and remove all the references to resources that are now part of the resource bundle.

Since the resource bundle is now a proper target we can add it as dependency to apps using it. This tells Xcode that if this dependency is somehow “dirty” then the app target is also in need of updating. So it will first build the dependent target and then include the product in the app build process.

This shows the Static Library set up as dependency and in “Link Binary With Libraries”. Now we also want the bundle product to be in the “Copy Bundle Resources” phase. Click the Plus button and add the bundle product.

This will make the bundle appear in the “Copy Bundle Resources”. If it wasn’t built before the app target then it will be built first, causing it to appear in the build products folder and from there it will be copied and included in the app product.

A Few Code Changes

If you reference images from a XIB and you put these images in the same resource bundle as the XIB then you don’t have to change anything. XIBs will load images from the same bundle that they were instantiated from.

However there are a couple of changes you need to make to your code so that the resources can be found at their new location.

Strings

The default macros for getting localized strings look for the strings files (aka “string tables”) in the main app bundle. These are the definitions of the 4 default macros and you can see that the bottom two have a way to specify the bundle to get the strings from whereas the first two hardcode the mainBundle.

#define NSLocalizedString(key, comment) \
	    [[NSBundle mainBundle] localizedStringForKey:(key) value:@"" table:nil]
#define NSLocalizedStringFromTable(key, tbl, comment) \
	    [[NSBundle mainBundle] localizedStringForKey:(key) value:@"" table:(tbl)]
#define NSLocalizedStringFromTableInBundle(key, tbl, bundle, comment) \
	    [bundle localizedStringForKey:(key) value:@"" table:(tbl)]
#define NSLocalizedStringWithDefaultValue(key, tbl, bundle, val, comment) \
	    [bundle localizedStringForKey:(key) value:(val) table:(tbl)]

You can create your own custom macro or category or what-have-you to have a shortcut, but to promote understanding here’s the entire code that we need to first get an NSBundle instance from our resource bundle and then get one string from it.

Note that specifying a table of nil means that the strings file is called “Localizable.strings”, for a table name of “Name” the file is called “Name.strings”

// get the resource bundle
NSString *resourceBundlePath = [[NSBundle mainBundle] pathForResource:@"DTPinLockController" ofType:@"bundle"];
NSBundle *resourceBundle = [NSBundle bundleWithPath:resourceBundlePath];
 
// get a string
NSString *string = NSLocalizedStringFromTableInBundle(@"Set Passcode", @"DTPinLockController", resourceBundle, @"PinLock");

We probably want to have a category on NSBundle specific to our project to load and cache in a static variable the resource bundle. And to go with that a localized string macro that hard codes this resource bundle.

XIBs

You probably have several places where you call [super initWithNibName:@"MyViewController" bundle:nil]. The nil in this case causes the NIB loader to assume that you mean the main bundle. Just as easily we can get the resource bundle and pass there here instead.

// get the resource bundle
NSString *resourceBundlePath = [[NSBundle mainBundle] pathForResource:@"DTPinLockController" ofType:@"bundle"];
NSBundle *resourceBundle = [NSBundle bundleWithPath:resourceBundlePath];
 
// load View Controller from that
UIViewController *vc = [[MyViewController alloc] initWithNibName:@"MyViewController" bundle:resourceBundle];

Do we see a pattern here? You betcha! We always first get the NSBundle instance for the resource bundle and then pass this as a parameter to some method that does something with the resource.

Images

Ah, Graphics. With strings and XIBs both working the same way you would only be right to assume that there’s a imageNamed:inBundle: method, BUT… it is private. Radar rdar://10250430 by Cedric Luthi addresses this.

But fortunately for us we don’t really need this special method. The regular imageNamed can work with our resource bundles too!

All you need to do is prefix your image names with the name of the bundle, like this:

// load image from resource bundle
UIImage *image = [UIImage imageNamed:@"DTPinLockController.bundle/Image.png"];

This works because besides being a bundle object the resource bundle is also folder that can be traversed via its path.

The cool thing about loading XIBs, strings and images from resource bundles like this is that you retain the awesome powers of these methods. Like pathForResource:ofType: will automatically deliver the correct language version for the device if the resource is localized. Or imageNamed: will still automatically load Retina graphics where applicable or device-specific images with ~ipad or ~iphone.

I told you before that you don’t need to do anything special if these images are referenced from XIBs contained in the same resource bundle. So this is only necessary for the cases where you load the images from code.

Conclusion

This simplified tutorial has all targets and resource consumers in the same project. But the same concepts also work if you add the component project as a sub-project.

I hope that I could convince you of the many advantages of resource bundles over static bundles. I’ve been successfully using them in almost all of my commercial components and many internal projects.

Bundle targets allow you to streamline the resource building process in a way that make larger projects way more effective and less error prone. Make it so!

Episode 35, recorded Saturday, 28th of April 2012. “TapCaps”

Alice Ning discusses the ins and outs of having a Kickstarter campaign for physical products versus software, we learn a bit about the magic behind capacitive touch screens and we learn what goes on behind the scenes of the TapCaps Kickstarter campaign.

News

The big news this week of course have been the record sales of WWDC 2012 tickets. Most of the people at the US west coast missed out on tickets because the rush was over in just 2 hours. Compared to 10 hours last year.

This year Apple tried something new. Individuals could only purchase one ticket and company accounts could only purchase 5. Non-transferable, no refunds. Unfortunately the system to detect scalpers was a bit overzealous. Several people who used the same credit card and same IP address but different developer account received a cancellation notice from Apple.

The problem with starting too early was that some people tried to purchase multiple individual tickets like this because at that time they couldn’t get hold of the company account agent. I’m keeping my fingers crossed that Apple can work this out, it is a bit of an embarrassing situation. Apple – as usual – trying an engineering approach with technology to solve the problem of scalping, but them stumbling over a stupid bug.

Apple obviously wanted time the availability of tickets such that its early morning in the US, evening in Europe and before midnight in the far east. But what even surprised them was the speed at which the tickets went. Probably helped along very much by the WWDCalerts system that sent out messages to over 9000 people. I received my own such message about 10 minutes after the begin of the sales, that was 2:40 pm central european time. There where several people not so luck as SMS are known to be unreliable at times. Some received their notifications never or simply too late.

Now two hours still twice as long as Google IO, but hey, people get free hardware there. I think we can attribute the breaking of last years record mostly to twitter and the alert system. I got lucky myself as well. I had my phone on silent so I totally missed the starting bell. But fortunately for me some nice chap sent me a direct message on Twitter. Which only further solidifies my theory that when people organize over social networks then they will break any record.

Some other items, before we get to the interview.

Pro Tip by Cédric Luthi: You must use MyImage@2x~ipad.png NOT MyImage~ipad@2x.png when using the automatic process of imageNamed. You know, imageNamed can automatically give you the @2x version on iOS devices with a Retina display. But did you know that it can also give you automatically a different image for iPhones and iPads? Yes, it does! You just call imageNamed:@”MyImage.png” and if there is a ~iPad between the 2x and the extension then this will be returned on iPads. But the order matters. It’s Name, @2x, tilde device, extension. Remember this.

Shortly after being acquired by Facebook Instagram has opened up and nicely documented their API. You have an URL scheme to open instagram from your own app as well as web-based APIs to add and delete objects. In theory you could build your own Instagram client with that. Any takers? You probably won’t be purchased by Facebook though…

Peter Steinberger reminds us: “If Xcode 4.4 creates an entitlement with NSFileProtectionComplete and your app fails to start up, just delete it. Stuff isn’t ready yet.” and he references a developer forum thread discussing this. Well you shouldn’t be using Xcode 4.4 in product environments yet, making production apps with… but that doesn’t prevent many individuals from doing exactly that. This is apparently already in iOS 5 as the mentioned thread is in the Core OS iOS 5 beta archive. No longer under NDA. So I can mention the official responds from an Apple engineer:

One of my colleagues here in DTS discussed this issue with iOS engineering and the conclusion was that this stuff does not currently work.

App Review Weather: Both new apps and app updates have improved to 99% chance of being reviewed in under 5 business days.

Interview

Alice Ning, management consultant by day, inventor by night, from Washington DC.

Myth Busted: iPhones won’t work with Gloves

TapCaps Campaign on Kickstarter 

Alice Ning on Twitter, Homepage

TheTapCaps.com

I’ve seen it! The fabled XIB support for Linguan is almost done.

A week ago I received a preview for the next version of Linguan which will also allow you to localize XIB files. Initially this will be facilitated by the ibtool tool which is contained in Xcode.app as well as gets installed in /usr/bin if you setup the command line tools.

The guys at BytePoets – who we partnered with to make Linguan a reality – integrated it such that you can edit strings and XIB files with virtually no difference. Behind the scenes you have ibtool humming away extracting the tokens from the interface builder files and if you make a modification to write them back in.

There are a few minor adjustments still necessary. For one there needs to be a preference setting to specify the path to ibtool. Without it the XIB functionality has to be disabled. Then we need to disable editing of the name column for tokens coming from a XIB because that’s the key that ibtool needs to send the updated string to the right place. If users can edit that it would probably cause trouble.

I am hoping to have a similar approach as we did in the past with genstrings. You might remember that initially Linguan was calling the original genstrings, but I reverse-engineered a static library with the same functionality which is orders of magnitude faster. Once this was working properly we replaced the external function to an internal one.

As soon as I have some time I hope to getting started with ibtool2 in a similar fashion. Write a GCD-multithreaded super-charged open-source version of ibtool that we can put in a static library and thus eliminate this external dependency.

Oh, if you have not done so yet I strongly urge you to purchase Linguan now because we will definitely raise the price tag once XIB support is live. Also your purchase gives us the budget to add more exciting features in the future.

I’m working on my own file and image cache that uses CoreData for storage. The same way that NSURLCache is doing it, but with some optimizations that I know and understand. So I created DTDownloadCache and got it all working, but there was one minor thing that I didn’t like: The usual method of creating a CoreData entity model is by the entity editor built into Xcode.

This meant that I had to include the .datamodeld file in apps using this. But I didn’t want to have to create a resource bundle just for this single file as you would have to do if you keep your reusable code in static libraries. Ugh!

Fortunately there is a way how you can create a static model entirely in code so that you can make use of CoreData without having to ship an XML description of the model.

First, lets have a quick look at how the model looked like in the editor.

Plain and simple. The only special thing is to allow external storage for the fileData attribute. This allows CoreData to decide where to most efficiently store the file data. Small files will be stored in the entity itself. Large files get a GUID and will be saved in a subfolder of Library/Caches. If we wanted to support iOS 4 then we would have to create this mechanism ourselves which is available as of iOS 5.

In XML this is represented as:

The model is what CoreData needs to know how to translate between the SQLite database on disk and the managed objects in memory. Of course we could embed this model as a binary resource, but that would make out code unnecessarily more convoluted. I found a good example (Core Data Utility Tutorial) in the Apple documentation that explains the process.

The method to create the same model as in the editor in code looks like this. ARC = On.

- (NSManagedObjectModel *)_model
{
	NSManagedObjectModel *model = [[NSManagedObjectModel alloc] init];
 
	// create the entity
	NSEntityDescription *entity = [[NSEntityDescription alloc] init];
	[entity setName:@"DTCachedFile"];
	[entity setManagedObjectClassName:@"DTCachedFile"];
 
	// create the attributes
	NSMutableArray *properties = [NSMutableArray array];
 
	NSAttributeDescription *remoteURLAttribute = [[NSAttributeDescription alloc] init];
	[remoteURLAttribute setName:@"remoteURL"];
	[remoteURLAttribute setAttributeType:NSStringAttributeType];
	[remoteURLAttribute setOptional:NO];
	[remoteURLAttribute setIndexed:YES];
	[properties addObject:remoteURLAttribute];
 
	NSAttributeDescription *fileDataAttribute = [[NSAttributeDescription alloc] init];
	[fileDataAttribute setName:@"fileData"];
	[fileDataAttribute setAttributeType:NSBinaryDataAttributeType];
	[fileDataAttribute setOptional:NO];
	[fileDataAttribute setAllowsExternalBinaryDataStorage:YES];
	[properties addObject:fileDataAttribute];
 
	NSAttributeDescription *lastAccessDateAttribute = [[NSAttributeDescription alloc] init];
	[lastAccessDateAttribute setName:@"lastAccessDate"];
	[lastAccessDateAttribute setAttributeType:NSDateAttributeType];
	[lastAccessDateAttribute setOptional:NO];
	[properties addObject:lastAccessDateAttribute];
 
	NSAttributeDescription *expirationDateAttribute = [[NSAttributeDescription alloc] init];
	[expirationDateAttribute setName:@"expirationDate"];
	[expirationDateAttribute setAttributeType:NSDateAttributeType];
	[expirationDateAttribute setOptional:NO];
	[properties addObject:expirationDateAttribute];
 
	NSAttributeDescription *contentTypeAttribute = [[NSAttributeDescription alloc] init];
	[contentTypeAttribute setName:@"contentType"];
	[contentTypeAttribute setAttributeType:NSStringAttributeType];
	[contentTypeAttribute setOptional:YES];
	[properties addObject:contentTypeAttribute];
 
	NSAttributeDescription *fileSizeAttribute = [[NSAttributeDescription alloc] init];
	[fileSizeAttribute setName:@"fileSize"];
	[fileSizeAttribute setAttributeType:NSInteger32AttributeType];
	[fileSizeAttribute setOptional:NO];
	[properties addObject:fileSizeAttribute];
 
	NSAttributeDescription *entityTagIdentifierAttribute = [[NSAttributeDescription alloc] init];
	[entityTagIdentifierAttribute setName:@"entityTagIdentifier"];
	[entityTagIdentifierAttribute setAttributeType:NSStringAttributeType];
	[entityTagIdentifierAttribute setOptional:YES];
	[properties addObject:entityTagIdentifierAttribute];
 
	// add attributes to entity
	[entity setProperties:properties];
 
	// add entity to model
	[model setEntities:[NSArray arrayWithObject:entity]];
 
	return model;
}

This looks more complicated than it really is because of the verbosity of Objective-C. The process is simply to create an empty model, create an entity, create the attributes, stir it all up and cook on medium flame for 15 minutes. If you compare this with the XML model above then you’ll see a couple of differences, but those are merely because I made my code model more strict, with less optional properties.

The bare bones CoreData stack – consisting of the model, the persistent store coordinator and the managed object context might look like this:

- (void)_setupCoreDataStack
{
	// setup managed object model
 
	/*
	NSURL *modelURL = [[NSBundle mainBundle] URLForResource:@"DTDownloadCache" withExtension:@"momd"];
	_managedObjectModel = [[NSManagedObjectModel alloc] initWithContentsOfURL:modelURL];
	 */
 
	// in code
	_managedObjectModel = [self _model]; 
 
	// setup persistent store coordinator
	NSURL *storeURL = [NSURL fileURLWithPath:[[NSString cachesPath] stringByAppendingPathComponent:@"DTDownload.cache"]];
 
	NSError *error = nil;
	_persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:_managedObjectModel];
 
	if (![_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:nil error:&error]) 
	{
		// inconsistent model/store
		[[NSFileManager defaultManager] removeItemAtURL:storeURL error:NULL];
 
		// retry once
		if (![_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:nil error:&error]) 
		{
			NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
			abort();
		}
	}
 
	// create MOC
	_managedObjectContext = [[NSManagedObjectContext alloc] init];
	[_managedObjectContext setPersistentStoreCoordinator:_persistentStoreCoordinator];
}

Xcode turns the XML model into a momd file when building. The line that loads the model from this file is now commented out and instead the model is being constructed at runtime.

You can modify the model until the first time it is used to access the persistent store. After that time it is read-only because changing it then would make it impossible for CoreData to talk to the data it has already saved.

Also this approach does not bother with migrating models if something is changed. We simply remove the store file and retry adding the persistent store to the store coordinator. If that works then CoreData has created a fresh SQLite database on disk that fits our new model.

Conclusion

CoreData is powerful to be used for maintaining the META information of caches and with the above approach you can easily keep your custom caches in static libraries without the need of adding a clunky model file to apps that are linking in this lib.

The experts are still out as to the motivations behind Facebook’s iOS SDK strategy. But it is rather clear that if Facebook has their way then everybody is to be using their Single Sign-On (SSO) technique. Besides all potential advantages of having this SSO in place it has to leave your app for signing on.

Not exactly something that is useful for all use cases. We have one case (involving ShareKit) which works better with the old style of signing into Facebook. This “traditional approach” shows the login dialog in a web pop up instead of leaving the app.

In this post I’m sharing the 3 methods how to hack the Facebook class and bend it to our will.

When researching for a way to disable SSO and restore the “old style” you inadvertently come across several people telling you to simply hack the authorize: method in Facebook.m.

Original Code Hack

The code for it is Open Source and so that poses little problem for a simple modification. You simply replace the method with the version below:

- (void)authorize:(NSArray *)permissions 
{
	[self setValue:permissions forKey:@"permissions"];
 
	[self authorizeWithFBAppAuth:NO safariAuth:NO];
}

But unfortunately that means you’ll have to modify code that is owned by somebody else. And I’m not talking about licensing concerns but the simple fact that if Facebook updates the SDK you have to do this change every time after updating to the latest version.

I am using the Facebook SDK via a submodule in ShareKit and I generally want to avoid having to keep track of modifications in third-party code. Which brings us to method number 2.

Category Hack

We know that we can add methods to existing classes by simply adding them in categories. If you have a method that has the same name as an existing method then the new method simply replaces the old one. So we can wrap the above hack in a category like so:

Facebook+NoSSO.h

#import "Facebook.h"
 
@interface Facebook (NoSSO)
 
- (void)authorize:(NSArray *)permissions;
 
@end

Facebook+NoSSO.m

#import "Facebook+NoSSO.h"
 
#import "Facebook.h"
 
@interface Facebook ()
 
- (void)authorizeWithFBAppAuth:(BOOL)tryFBAppAuth
                    safariAuth:(BOOL)trySafariAuth;
@end
 
@implementation Facebook (NoSSO)
 
- (void)authorize:(NSArray *)permissions 
{
	[self setValue:permissions forKey:@"permissions"];
 
	[self authorizeWithFBAppAuth:NO safariAuth:NO];
}
 
@end

Notice that we need to define the authorizeWithFBAppAuth:safariAuth: in an anonymous category so that the compiler accepts us calling it from our own authorize: method. Without that we would get a compiler warning. This method is internal to the Facebook class and not exposed via the header.

This method has two problems: 1) I don’t think that Apple actually guarantees a certain order in which classes and categories are loaded. So this is a bit risky to rely on it having always been working. 2) As of Xcode 4.3.2 the compiler will actually warn you “Category is implementing a method which will also be implemented by its primary class”

Which brings us to the third – most elegant method.

Swizzeling Hack

Being dynamic in nature the Objective-C runtime allows us to dynamically changes classes and methods which our app is running. One such technique is called “Method Swizzeling” which basically means to exchange two methods. With this method you can substitute your own method implantation.

First I borrowed some code from ShareKit and adapted it for general use in DTFoundation:

NSObject+DTRuntime.h

@interface NSObject (DTRuntime)
 
+ (void)swizzleMethod:(SEL)selector withMethod:(SEL)otherSelector;
 
@end

NSObject+DTRuntime.m

#import <objc/runtime.h>
 
@implementation NSObject (DTRuntime)
 
+ (void)swizzleMethod:(SEL)selector withMethod:(SEL)otherSelector
{
	// my own class is being targetted
	Class c = [self class];
 
	// get the methods from the selectors
	Method originalMethod = class_getInstanceMethod(c, selector);
	Method otherMethod = class_getInstanceMethod(c, otherSelector);
 
	if (class_addMethod(c, selector, method_getImplementation(otherMethod), method_getTypeEncoding(otherMethod)))
	{
		class_replaceMethod(c, otherSelector, method_getImplementation(originalMethod), method_getTypeEncoding(originalMethod));
	}
	else
	{
		method_exchangeImplementations(originalMethod, otherMethod);
	}
}
 
@end

That takes care of the actual exchanging. I have to admit that I don’t quite understand the if, because in my tests it always ended up in the method_exchangeImplementations part. But as long as it is working…

Now we have to only have a method with a unique name (to avoid the warning) and then we can exchange this method for the original authorize: method by means of this swizzle. The modified category now looks like this:

Facebook+NoSSO.h

#import "Facebook.h"
 
@interface Facebook (iCatalog)
 
- (void)authorize_noSSO:(NSArray *)permissions;
 
+ (void)toggleSingleSignOn;
 
@end

Facebook+NoSSO.m

#import "Facebook+iCatalog.h"
#import "NSObject+DTRuntime.h"
 
@interface Facebook ()
 
- (void)authorizeWithFBAppAuth:(BOOL)tryFBAppAuth
                    safariAuth:(BOOL)trySafariAuth;
@end
 
@implementation Facebook (iCatalog)
 
- (void)authorize_noSSO:(NSArray *)permissions 
{
	[self setValue:permissions forKey:@"permissions"];
 
	[self authorizeWithFBAppAuth:NO safariAuth:NO];
}
 
+ (void)toggleSingleSignOn
{
	[Facebook swizzleMethod:@selector(authorize:) withMethod:@selector(authorize_noSSO:)];
}
 
@end

You see that I have also added a class method to toggle SSO on and off. I named it “toggle” because each call will exchange the two method implementations. While the first toggle will disable SSO the second call restores the original method and thus re-enables it.

With this you only have to call the toggleSingleSignOn once per app launch, the best place is the app delegate’s +initialize which is guaranteed to be called just once and also in a thread-safe manner.

@implementation MyAppDelegate
+ (void)initialize
{
	// disable Facebook SSO
	[Facebook toggleSingleSignOn];
}
@end

That’s all it takes.

Conclusion

Of the three ways how you can modify somebody else’s code’s behavior the one that actually replaces the implementation via swizzeling is the most convenient and least dangerous, at least if you know what you are doing.

This alternative does not have the drawback of original code hacking that you incur an additional maintenance overhead. And it does not have the drawback of compiler warnings for the category hack approach.

I read an article by Michael Abrash on the Valve blog that he signed up with Valve to investigate Augmented Reality. At the end of his article he mentions that Valve is hiring.

This prompted me to send him the following long email. And as I like for my writing to not go to waste I am posting it here as well.

Hi Michael,

I read the Valve employee handbook directly followed by your great article. There are many concepts in Valve’s philosophy that resonate with me. However I have the same problem that most people who read this have: Geography.

Granted, anybody is – theoretically – free to move to live near Valve’s Headquarters and few people do… The handbook mentioned like 44 international hires so far. This number is so low because of several obvious reasons

• too few H1B visas
• most engineering jobs in the USA require a bachelor’s degree or higher
• … Because that’s needed for the visa
• … But in many countries the education of engineers is vocational and not academic and therefore people have no such academic degree and it is quite a fuss to formally prove that the education and/or experience is equivalent.
• very few people are actually willing to move to the USA because the the quality of living is far greater elsewhere
• … Or they are married (like myself) and there is no chance our wives would ever consent to moving away from our rural town, let alone to the USA

But I am not writing to you because I am whining. I want to open your eyes to a problem that technology companies in the USA are facing. And where there is a problem an engineer will work on a solution.

To give an analog from recent history: if people ship physical goods the recipient has to pay customs taxes. This is why a recent Kickstarter project has a rewards tier that is entirely virtual. You get everything in digital form and downloadable over the internet as to not having to pay any customs or taxes for it.

Which brings me to the point I want to address: somebody needs to invent a way that somebody in a foreign country could work at Valve virtually. Basically a level of cyberspace that is of sufficient fidelity that it can replace actual in-person presence. There’s another Kickstarter project that went into this direction. It was a robotic cradle for an iPhone that you could remote control. The need to see and hear from a remote location, enhanced by the need that you want to be able to change the perspective.

Granted there are some ways how companies try to address this: Skype, Go2Meeting, video chat, Sharepoint. The most innovative development probably being Microsoft’s RoundTable device. But they all fall short because they simply don’t have the multi-disciplinary makeup of researchers that you need to solve this hard problem.

3D-Graphics and Immersion and virtual worlds and internetworking have always been the forté of Game companies like Valve. Companies like Google or Microsoft are working on small slices of the problem as they understand it. But where is the enthusiasm for immersive cyberspace that we all felt 20 years ago?

3D TV has become an “also ran”, cyperspace is no longer of interest for anybody, even Google with their glasses project is only focussing on displaying information (and probably enhance our reality with ads).

The great opportunity for Valve is to enhance the Source engine in several key areas:

• revolutionise motion capture and eliminate the need for markers
• implement real time 3D tracking and “world building”
• develop real time interpolation between these 3D scans
• let multiple such live 3D scanners work in tandem on internetworked servers
• develop mobile clients that can tap into these worlds and navigate them
• develop technology that can insert a remote worker’s avatar into your current reality

I think that the sub-problem of real time scanning and world construction can be solved sooner than the problem of how to get this onto people’s retinas. But the immediate benefits would be a dramatic increase in productivity for 3D graphics as used in computer animated and 3D live action movies. Also I think many people would be interested in being able to go into a room, taking a look around once and then having a 3D model of that for later use.

Sort of like the holo cam that Lt. Data had as a hobby in Star Trek: TNG.

Again it has to be a Gaming company to provide the technology for this next paradigm shift. Camcorder companies can only increase the number of pixels on their CCDs. And their “solution” for the 3D model problem is to not solve it, but let the viewer’s brain figure this out.

The next quantum leap in vision technology will no longer be to record pixels, but to record an actual 3D model of the real world. And I think this will come as a side-product of the greater goal of being able to “beam” reality to other places on earth for virtual consumption first and actual participation later.

Speaking of consumption … Could you please check on the progress of HL2:ep3?

Kind regards

Oliver Drobnik

Episode 34, recorded Saturday April 21th, 2012

We can learn about cool company philosophy from the Valve employee handbook, Objective-C is creeping up to C++ as the world’s almost most favorite programming language. And iOS 4 can now  be retired.

Show Notes

Still no WWDC, some people start to get nervous and some even try to jinx it. Marco Arment, of Instapaper, would prefer if WWDC 2012 didn’t happen in the week from June 11th through 15th because that would mean he couldn’t spent his birthday at home which falls in this interval. There are no other obvious candidate dates for WWDC so we keep on being stressed out by Apple with every passing day.

And yes, I am stressed too. Aren’t we all… for the next big update to my iCatalog framework I’ve spent the last week to migrate everything to ARC. The whole project started out as one iPad app and over time the number of target has grown exponentially. We’re now developing some more advanced features but decided that these will be iOS 5 only. So – of course – I’m switching to ARC. And of course there is ShareKit which has no hope of being migrated to ARC soon, so I had to pack that into its own static library with ARC turned off. In the end I want the iCatalog project to be only for the core functionality. All the iCatalog apps should be in a different project so that I don’t have to mess with the dozens of targets for all the catalog apps any more. I am telling you this for two reasons: 1) as an excuse for not having a better show prepared. and 2) as a pointer that you might want to have reusable core functionality also in your own modules and sub- projects.

Oh, and I have another excuse: my MacBook Air is still being repaired. I suspect that the power regulator had a problem. Sometimes it wouldn’t charge, then it would. If you were lucky you could start it, but then it would shut down by itself after a short while. And then you couldn’t start it until you reset it with these secret key combinations. But fortunately I have AppleCare for it and so that should be fixed next week.

And now for some interesting news … yes there where a few…

TIOBE Software publishes their Programming Community Index every month. This is sort of a hit parade of programming languages somehow measured by an elaborate methodology that uses search engines to determine the relative importance of programming languages. In the current April report the top position went to C which overtook Java on second place compared to a year ago. C++ stayed put on third place. The big winner in the top 10 is Objective-C which moved from 8th place last April to number 4. Objective-C also became the “Language of the year” in 2011 because it seems to be rising in these ranks like a rocket. All of us iOS and Mac developers using this for our favorite platform probably helps here quite a bit.

Google Currents launched internationally this month, after almost half a year being US-only. Will Kiefer, the iOS developer behind Google Currents, told me that they too make widespread use of UIWebViews for the main reason that their online publishing tool requires Javascript to run and that only the HTML5 CSS support in web views allows them to expose the customizability for their content partners. Will told me that to speed up image loading he replaced the normal NSURLCache mechanism with NSURLProtocol. This is faster because NSURLCache can only return one cached response at a time while NSURLProtocol can work concurrently. That’s definitely something worth looking into. I’m trying to get Will on the Cocoanetics podcast in one of the next episodes.

LLVM.org published in much greater detail the new Objective-C literal syntax for NSNumbers and Containers. Users of Apple’s compiler will be able to start using these features with Apple LLVM Compiler 4.0. Users of open-source LLVM.org compiler releases can use these features starting with clang v3.1. The 4.0 compiler will be in Xcode 4.4 which is due out about the same time as OS X Mountain Lion sometime this summer. The good thing will be that since this is compile-time technology it will mean that we should be able to use the new Literal syntax also in older iOS versions.

Valve software, makers of Steam and amazing games like Half-Life, have published a copy of their new employee handbook online. This manual is supposed to give new hires an overview of the Valve company philosophy. I recommend that you download this book and read it on your iPad because it is truly a piece of art. The manual in itself is a piece of art, it has beautiful illustrations and a ton of interesting content, even if you don’t plan to try to be hired by them.

Valve is nevertheless quite unusual in their philosophy. They don’t have a hierarchy or managers. Instead you are free to pick the projects that you would like to work  on. It’s like at Google where people have 20% for their own projects. Only at Valve this is 100%. I’m astonished that this can work, but I too will need to read the manual first before I can tell you how they do it. Quite inspirational!

Speaking of the value of employees: In the last quarter the profit per employee of Google, Apple and Sony were: $96,090 (33,464 employees) at Google, $215,200 (with 60,400 employees) at Apple and at Sony the average employee (of 168,200) lost the company $11,690. It’s interesting to see how Apple employees manage to make their company more than twice as much profit per person as Google employees. What is it that makes them so valuable? Possibly Apple selling boatloads of iOS devices?

David Smith published his latest 5.1 Upgrade stats and he reports:

Upgrades appear to have leveled off into the slow trickle phase. After the initial surge of upgrades (both OTA and otherwise) user adoption has transitioned into a more measured pace. Overall there is still a clear movement towards the newer OS variants. 82% of all users are now running some flavor of iOS 5.x.

What’s interesting in these statistics is that there is even greater adoption of iOS 5 than it seems because the numbers are drawn down by laggards on various versions of the iPod Touch. On iPad you’ll find no less than 86% on iOS 5.0 or higher. On iPod Touches this is only 65%. My theory is that these iPod Touches are mostly in the hands of children which don’t care for a newer iOS versions while the games they want to play still support iOS 4.

David Smith concludes that these numbers are good enough for him to drop iOS 4 support in his next major updates.

App Store Review Weather: As of April 20th there was a 3% chance of raining on your New Apps, 1% of bad weather for App Updates.

Kickstarter Projects mentioned:

• Geode from iCache! – An iPhone case with build in e-ink display for dynamically displaying loyalty card barcodes plus on-the-fly programmable credit card
• Galileo – an remote-controllable robotic iPhone stand for panning and tilting
• Pebble – E-Paper Watch
• Double Fine Adventure – previous record holder until the Pebble beat it
• Make Leisure Suit Larry come again – cutting it close to the $500,000 goal, Larry is dear to many but a bad influence for many more

I reported a while ago that I was forced to tag the current state of the DTCoreText master repository as 1.0.0. The reason for this was that CocoaPods was starting to gain lots of momentum and several people wanted to use DTCoreText via a podspec.

You can have podspecs point to the master branch as well, but then you never really know what you get. This can possibly cause many headaches especially in larger projects where you cannot track the state of each individual sub-project.

Therefore it is generally recommended – if not required – to make use of tags in GitHub.

Tags are like labels that you attach to the current state of a repository. You can create them simply by issuing the following command in the repository root folder.

git tag "1.0.1"

You can list the existing tags with:

git tag -l

There is an option on git push to have the tags also travel to the origin repository on GitHub:

git push origin master --tags

Once you’ve done that, GitHub provides snapshots of the tagged state as tar balls and zip files… though you probably don’t want to use these but rather have the project as a clone so that you can easily update it.

DTCoreText News

Amongst the fixes that made this maintenance release necessary where:

• Fixed Block-Retain-Cycle
• Fixed a second minor retain-cycle
• Workaround for Chinese Font cascade bug in iOS 5.x (radar://11262229)
• Workaround for a CoreText memory leak in iOS 4.3 (fixed in 5.0)
• Some Unit Testing corrections
• Updated Readme regarding necessary linker flags

I finally got around to also filing a Radar for the cascade bug. The memory leak issue is fixed as of iOS 5, the problem there was that if you replaced the paragraph style attribute on an NSAttributedString with a new one, the previous entry would leak. I fixed that by simply removing the attribute first before calling addAttribute with the new style.

The project has surpassed 1000 watchers on GitHub which tells me that it is definitely of use for many people. If you have any app making use of it, then please tell me about it as I like to feature your work. I especially love to receive testimonials like this one.

The changes to the Readme reflect the outcome of research done by David Hoerl. The question was to determine which linker flags are really necessary when linking in DTCoreText – or any other static library that contains categories – into an app.

Linker Flags Wisdom

The linker in general tries to only link in code that is actually used. So if you have C-functions then their code will not end up in the final app binary if it is never being called. This does not work for Objective-C category extensions because of the dynamic nature of method resolution.

Therefore you would generally use the -ObjC linker flag when dealing with static libraries that contain Objective-C code.

Greg Parker from Apple who refers to himself as “Runtime Wrangler” explains it like this:

-all_load and -force_load act at link time, not at load time. -all_load and
-force_load tell the linker to link the entire static archive in the final
executable, even if the linker thinks that parts of the archive are unused.

When you link a traditional C static archive (.a file), any code from the
archive that is never referenced in the final executable is simply omitted from
the executable. So if you had a static archive with 999 functions you did not
call and 1 function that you did call, your final executable would include only
that one function.

Objective-C categories break the C static archive model, because you want the
Objective-C category to appear in the final executable even though there are no
C symbol references to it from the executable.

The best solution for Objective-C categories in static archives is the -ObjC
linker option, which tells the linker that all Objective-C categories in the
archives are “used” but to apply the usual reference algorithm for everything
else in the archives.

The -ObjC option is broken in some versions of the linker. For those cases the
-force_load and -all_load options work. The final executable may be larger than
necessary with those options, if there were classes or C functions that could
have been omitted by the linker. If you have multiple archives and only some of
them have Objective-C code then -force_load may generate smaller output than
-all_load.

On iOS you’d typically only link in libraries that you need, as opposed to traditional C or C++ where you’d often link in large static libraries that are collections of utility methods. So in the case where the libDTCoreText.a is the only static library should be  no difference between force_load and all_load at all.

Personally I prefer the simplest approach which is to first try to get by with only -ObjC and if I get unrecognized selector crashes to additionally add -force_load because there I don’t need to know or specify the path to the specific library.

DTRichTextEditor

I’ve streamed all the 1.0.1 updates also into DTRichTextEditor which uses DTCoreText for display of rich text. Changes there include:

• Support Left, Center, Right and Justified toggling of paragraphs
• Preliminary work on supporting lists

I love to get feedback from people who are actually using the editor in shipping apps. The most prominent one is Dootrix who made the Simpl iPad app. I interviewed the maker on my podcast, if you haven’t done so I urge you to listen to it as I think it was one of the most enlightening conversations I ever had on air.

I keep getting requests for a ways to test the editor component before purchasing it. Also the work on lists as well as some feature requests are still open for the editor.

Unfortunately I won’t have any time to devote to these requests as we are in “crunch time” for a major project of maximum importance for the next two weeks. Therefore I ask for some patience.

The Future

I’m not making very much money from selling licenses. Only enough to justify it as a hobby. I might be forced to dramatically raise the price in the near future. So if you are thinking of buying then better do so now, because you then will have access to my Subversion repository and get the benefit of all future updates.

On the above mentioned podcast episode I also discussed what my thoughts where related to the future of rich text editing on iOS.

I am happy if Apple takes on more of the burden that DTCoreText and DTRichTextEditor are currently carrying. It is astonishing that they truly believe that people would use contentEditable UIWebViews for that task. As iPads become equal-partners in content creation this is an essential platform feature.

There are two levels that I can see Apple move forward on:

• Add the missing protocols and interfaces for interacting with selections and the magnifying glass – you would still have to create your own editor but at least you could do way more easily
• Enhance UITextView – which is using WebKit under the hood already – to be editable. Or alternatively create a totally new Rich Text Editing View.

Either way I will still have a market and and audience while people support 4.3 and above, or 5.0 and above when 6.0 finally ships. I would predict the former and not bet on the latter.

To cut a long story short: progress is being made and patience is required.

Episode 33, recorded April 14th, 2012

Everybody still waiting for WWDC. My MacBook Air misbehaves and thus I have no show prepared. But Kevin Smith from Dootrix saves us this week from having no show: we chat about Rich Text and the Simpl app which they made.

Show Notes

Kevin Smith is co-founder of Dootrix Ltd, a company that develops mobile apps for business and enterprise clients. We chat about rich text, display and editing and what went into the Simpl app they created for Simpl. And its all super-simpl, really…

Links:

• Company website: www.dootrix.com
• Blog: www.in-traction.com
• The Simpl App: www.simpl.com

Apps for taking only iPad to clients:

• iMockup
• Blueprint
• SketchBook Mobile

Feedback

I love to hear from you, you can email me at oliver@cocoanetics.com or tweet me @cocoanetics. If you want to give me audio feedback or have some interesting comment for me to play on the show please call my Google Voice mailbox:  (415) 860-4324

For a project that I am currently working on I needed to implement a custom container view controller. I was feeling my way forward in the dark for the most part because this does not seem to be a widely used technique. Developers – understandably – favor reusing and skinning existing view controllers over creating new containers.

However there are some scenarios where you should prefer to make your own container because it greatly simplifies your code over trying to bend a UINavigationController or UITabBarController to your will. Do you remember the times when those two where the only two containers available?

I distinctly remember using a UINavigationController with hidden nav bar as a view controller to contain multiple full views. And you probably had do do your own view juggling and animations because for the most part the standard transitions would be useless. Fortunately we can no file this as a fond memory of the past and move on to implementing our own containers.

The first thing to wrap your head around is the notion that besides a hierarchy of views you now also have to have a consistent hierarchy of view controllers. Before iOS 5 people would often create a new view controller and then slap this VC’s view into an existing view hierarchy. Now more!

Nowadays you never would resort to this. Instead you use the mechanisms afforded by UIViewController to add and remove child view controllers.

Another notion is that we’ve trained ourselves to think of view controllers as being responsible for one entire full screen, think of the sub view controllers of a tab bar controller. But ever since UISplitViewController which arrived with the iPad this is no longer the true mantra. Viewcontrollers are supposed to manage a coherent region on the screen, that can be the entire screen for lack of space on an iPhone, but it can also be a content bar at one of the sides of the screen. Like UISplitViewController which has two sub-viewcontrollers, one for the left (“master”) panel and one for the right (“detail”) panel.

UIViewController provides two methods to add a view controller as a child and to remove it later. Those are part of the “UIContainerViewControllerProtectedMethods” category extension for UIViewController:

@interface UIViewController (UIContainerViewControllerProtectedMethods)
 
- (void)addChildViewController:(UIViewController *)childController;
- (void)removeFromParentViewController;
 
@end

These two methods do exactly what their names suggest. Though what’s not quite obvious is how you are supposed to use them. And if and how you should combine these with addSubview and removeFromSuperview. Hence this exploration. Note: All this assumes we use ARC.

According to the docs it is up to us to define the kinds of relationships we want to model. Be it only a single VC visible at the time like nav controllers, or multiple that can be reached through tabs. Or even multiple VCs that are sort of like pages.

There are three possible things that you want to be able to do with your sub-viewcontrollers that have slightly different semantics:

• Add it to your container
• Remove it from your container
• Transition to another view controller (i.e. add the new and remove the old)

For any of these you also want to be be assured that the 4 view delegate methods get properly called, as well as the new 2 delegate methods that fire before and after a VC moved to a new parent. Note that a parent of nil means that it was removed.

Why is this attention to the delegate messaging necessary? You probably use the view(Did|Will)(A|Disa)pear methods to do some last setup or teardown and so you are interested that they get properly called. And also there is an ugly warning in the console about unbalanced messages if you get something wrong here.

We’ll dive into greater detail with a sample. Let’s say we want to get an effect similar to a tabbed view controller. i.e. we have an array of view controllers and we want to switch between these. Since this container VC will be our app’s root view controller we want to show the first sub-VC when it shows.

Basic Setup

Let’s put the necessary bare bones IVARs in the implementation because we only need to have access to these inside our own ContainerViewController.

@implementation ContainerViewController
{
	NSArray *_subViewControllers;
	UIViewController *_selectedViewController;
	UIView *_containerView;
}

The subVCs will be a static array of view controllers that the developer can set. The selected VC will hold a reference to the currently showing VC and the container view will be the area where we want our sub VC’s view to be positioned. Let’s start by setting up the container view in the container’s loadView:

- (void)loadView
{
	// set up the base view
	CGRect frame = [[UIScreen mainScreen] applicationFrame];
	UIView *view = [[UIView alloc] initWithFrame:frame];
	view.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;
	view.backgroundColor = [UIColor blueColor];
 
	// set up content view a bit inset
	frame = CGRectInset(view.bounds, 0, 100);
	_containerView = [[UIView alloc] initWithFrame:frame];
	_containerView.backgroundColor = [UIColor redColor];
	_containerView.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;
	[view addSubview:_containerView];
 
	// from here on the container is automatically adjusting to the orientation
	self.view = view;
}

I’ve colored the main view blue and the container view red for clarity. The sub-VCs will go in the red area and be automatically resized if we rotate the device.

The integration in the app delegate is a mere formality, add the import for the header, allocate an instance and set it as root VC.

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
 
	ContainerViewController *container = [[ContainerViewController alloc] init];	
 	self.window.rootViewController = container;
 
    [self.window makeKeyAndVisible];
    return YES;
}

Next we need a couple of view controllers to play the role of the sub-VCs. Let’s create a simple UIViewController subclass that has a UILabel as it’s main view, so that we can display something there to tell them apart. Do avoid overcomplicating things for this example we simple take the view’s own description in there. This way we see if the display changes.

- (void)loadView
{
	// set up the base view
	CGRect frame = [[UIScreen mainScreen] applicationFrame];
	UILabel *label = [[UILabel alloc] initWithFrame:frame];
	label.numberOfLines = 0; // multiline
	label.textAlignment = UITextAlignmentCenter;
 
	// let's just have this view description
	label.text = [self description];
	self.view = label;
}

I bet you never before had a view controller which consisted only of a UILabel. For Science!

Adding

Next we need to put a couple of these PageViewControllers into an array and have a method that allows us to set this array into our container. Let’s assume that you know how to create a property for the subViewControllers. In the app delegate we have these additional lines:

// make an array of 5 PageVCs
NSMutableArray *tmpArray = [NSMutableArray array];
 
for (int i=0; i<5; i++)
{
	PageViewController *page = [[PageViewController alloc] init];
	[tmpArray addObject:page];
}
 
// set these as sub VCs
[container setSubViewControllers:tmpArray];

So much for basic setup. Now let’s override the setter for the sub VCs to select the VC at index 0 and present it. Though we cannot present it in the setter, because the view might not have been loaded yet and so our _containerView IVAR is still nil.

- (void)setSubViewControllers:(NSArray *)subViewControllers
{
	_subViewControllers = [subViewControllers copy];
 
	if (_selectedViewController)
	{
		// TODO: remove previous VC
	}
 
	_selectedViewController = [subViewControllers objectAtIndex:0];
 
	// cannot add here because the view might not have been loaded yet
}
 
@synthesize subViewControllers = _subViewControllers;

Instead we do it at the latest possible moment, that would be in the viewWillAppear because here we are guaranteed that the loadView has taken place already. A nice lazy thing, if we find that the selected VC already has self as the parent then there’s nothing to do.

- (void)viewWillAppear:(BOOL)animated
{
	[super viewWillAppear:animated];
 
	if (_selectedViewController.parentViewController == self)
	{
		// nowthing to do
		return;
	}
 
	// adjust the frame to fit in the container view
	_selectedViewController.view.frame = _containerView.bounds;
 
	// make sure that it resizes on rotation automatically
	_selectedViewController.view.autoresizingMask = _containerView.autoresizingMask;
 
	// add as child VC
	[self addChildViewController:_selectedViewController];
 
	// add it to container view, calls willMoveToParentViewController for us
	[_containerView addSubview:_selectedViewController.view];
 
	// notify it that move is done
	[_selectedViewController didMoveToParentViewController:self];
}

The above shown sequence takes care of calling the viewWillAppear, viewDidAppear, willMoveToParentViewController and didMoveToParentViewController. Notice that all but the last are done for you automatically, but for some strange reason the didMove is not. So we have to do that manually. Upon starting our Demo we now see the VC at index 0.

Next we add the capability to transition from one VC to the next.

Transitioning

To move between the child VCs we’ll add a swipe gesture recognizer to our container. If we swipe left we want to go to the VC with a lower index in the array. If we swipe right we want to go higher. No wrapping. In loadView we add:

// add gesture support
UISwipeGestureRecognizer *swipeLeft = [[UISwipeGestureRecognizer alloc] initWithTarget:self action:@selector(swipeLeft:)];
swipeLeft.direction = UISwipeGestureRecognizerDirectionLeft;
[view addGestureRecognizer:swipeLeft];
 
UISwipeGestureRecognizer *swipeRight = [[UISwipeGestureRecognizer alloc] initWithTarget:self action:@selector(swipeRight:)];
swipeRight.direction = UISwipeGestureRecognizerDirectionRight;
[view addGestureRecognizer:swipeRight];

And the implementation of swipe is as follows. For simplicity’s sake we use two separate gesture recognizers because Apple does not provide an easy way to determine the swipe direction if you combine to directions.

- (void)swipeLeft:(UISwipeGestureRecognizer *)gesture
{
	if (gesture.state == UIGestureRecognizerStateRecognized)
	{
		NSInteger index = [_subViewControllers indexOfObject:_selectedViewController];
		index = MIN(index+1, [_subViewControllers count]-1);
 
		UIViewController *newSubViewController = [_subViewControllers objectAtIndex:index];
 
		[self transitionFromViewController:_selectedViewController toViewController:newSubViewController]; 
	}
}
 
- (void)swipeRight:(UISwipeGestureRecognizer *)gesture
{
	if (gesture.state == UIGestureRecognizerStateRecognized)
	{
		NSInteger index = [_subViewControllers indexOfObject:_selectedViewController];
		index = MAX(index-1, 0);
 
		UIViewController *newSubViewController = [_subViewControllers objectAtIndex:index];
 
		[self transitionFromViewController:_selectedViewController toViewController:newSubViewController]; 
	}
}

The logic to transition from one VC to another we package in transitionFromViewController:toViewController:. This is the really interesting part. There is a convenient method that again takes care of most of the boring work of adding and removing views. And again some non-obvious additional messaging is necessary to get it perfect.

- (void)transitionFromViewController:(UIViewController *)fromViewController toViewController:(UIViewController *)toViewController
{
	if (fromViewController == toViewController)
	{
		// cannot transition to same
		return;
	}
 
	// animation setup
	toViewController.view.frame = _containerView.bounds;
	toViewController.view.autoresizingMask = _containerView.autoresizingMask;
 
	// notify
	[fromViewController willMoveToParentViewController:nil];
	[self addChildViewController:toViewController];
 
	// transition
	[self transitionFromViewController:fromViewController
					  toViewController:toViewController
							  duration:1.0
							   options:UIViewAnimationOptionTransitionCurlDown
							animations:^{
							}
							completion:^(BOOL finished) {
								[toViewController didMoveToParentViewController:self];
								[fromViewController removeFromParentViewController];
							}];
}

And with that we have our transitions in the can.

You have a number of UIViewAnimationOptionTransition-s available, but you don’t have to settle for these. You can also pass 0 for the options and instead provide all animations you like the two views to execute in the animations block.

Before I discovered is method I was using the previous method of animating the views. Though this has a side-effect that we might not like in this case. Typically you want the “will” delegate methods to fire before the transition and the “did” to follow afterwards. If you animate the views yourself then iOS 5 will take care of sending these messages for you but it does so together. This looses us the ability to differentiate between stuff we want to do before and after the appearing and disappearing of the view controller.

Conclusion

It took me quite a bit of experimenting to also get all the messaging happening and equally balanced. The above sample has that working as it should.

But once you do figure out the two techniques outlined in this article you are on the road to implement your own view controller containment like you never did anything else.

One thing that I wasn’t able to figure out so far is why the transition method always adds the new view controller’s view to the container view controller’s main view. This simplifes the process somewhat because you don’t have to know at which stage in the transition it is ok to add and remove the views. But at the same time you might have a situation where you don’t want the animation to occur over the entire area of the container view controller.

For this scenario I can only think of covering up the parts with extra sub views. Or we could stack multiple container view controllers and have one to only cover the region where where have the container view. This could then clip its subviews and thus be only care for this area.

The main advantage of any kind of view controller containment is that rotation messages (should|will|did) reach the lowest leaves of your view controller tree. Unless you disable that by means of overriding automaticallyForwardAppearanceAndRotationMethodsToChildViewControllers and returning NO.

But who would really want that when we have waited for so long for public API to have these being forwarded? Working with view controller containers I get a feeling that they greatly simplified creating complex user interfaces consisting of multiple parts.

The project for this tutorial is in my Examples GitHub repository.

Episode 32, recorded April 8th 2012

Does Radar need to be fixed or not? Apple increases developer share for iAds. And we are on tenterhooks waiting for WWDC tickets to become available.

iAd Developer Share Raised

Apple raises revenue share going to developers from iAd to 70%, up from 60%. In a move that probably aimed at making iAd banners more attractive Apple raised the share to the same percentage developers are already getting for app sales and in-app purchases. The problem that people are still having with iAds is less the percentage they are getting, it’s the fill rate.

Because of this they are mediation networks like the one from Google or a component like my DTBannerManger which combines iAds, AdMob and MobFox to get 100% fill rate with the highest paying ads prioritized higher. Nevertheless we appreciate the gesture, personally I feel it’s a bit more rounded that Apple gets 30% share in everything.

Having a different percentage for a single service felt odd, not smooth, unlike Apple. At least they ironed this out for whatever reasons.

Miscellaneous Announcements

Apple has made new material available on the App Store Resource Center which you can use to promote your app with Apple’s blessing. On this page you can find the official “Available on the App Store” badge with instructions how you may and may not modify and use this. There are also official high resolution images for iOS devices which you can use in photo montages showing your app running on a device. The announcement mentioned new localized versions of the badge in Simplified and Traditional Chinese, Japanese, and Portuguese.

There where several great links in this week’s installment of the iOS Dev Weekly newsletter. I got the WWDC ticket availability stats post from there as well as the next two items:

There’s a cool guide on TheIconmaster.com that explains how to make a shortcut to new Photostream images in your Finder. This enables you to see new screenshots pop up right away on your Mac after you made them on your iOS devices. The advantage here is that you don’t have to have iPhoto running and iCloud sync working over peer-to-peer when your devices are on the same WiFi network. There is a smart search feature in Finder that automatically updates when new files appear. By combining this with a search for PNG files and the photo stream sync folder you’re set.

There is an extensive code style guide on NearTheSpeedOfLight.com. It describes in great detail how you should style your code. From naming conventions to tips on how to structure your APIs. This joins the ZDS Code Style Guide by Marcus Zarra and the Google Objective-C Style Guide in trying to bring order to our chaotic code. While the contained details in all three guides might remind you a bit of Obsessive Compulsive Disorder (OCD) there are nevertheless many good reasons for why it makes sense to do certain things a certain way. If not following it slavishly it might do wonders on your own code style and code readability if you pick up a couple of pointers when skimming through these guides.

App Review Weather Report: New Apps 97% chance of being approved in 5 days, Updates 99%.

This week was somewhat uneventful, probably because I was on vacation. Could it be that Apple is aware that many developers are taking the week off leading up to the Easter holidays? I mean, if they would have announced the 2012 Worldwide Developer Conference in this week then they would have annoyed all those vacationing people. I for one was glad that they didn’t because it saved me from having to deal with somebody else buying a ticket for me while I am incommunicado.

WWDC 2012, … NOT!

Somebody – whose name I forgot – did a linear regression on previous announcement dates and ended up seeing April 18th as the most likely date that tickets could go on sale. Scott McAlister compiled a complete list of when tickets went on sale in relation to the conference dates for the last 8 years. Before the iPhone there were around 4 months lead time. For the past 4 years there were between 40 and 88 days lead time, that equates to around 2 months.

If we take the speculative date of 11th of June then that means we are today just over 2 months way. By the way, the dates 11th through 15th of June are the only guess we have based on the Moscone West event calendar which has a “Corporate Meeting” by an unnamed company. Any day now….

Apple has no rush, its not that the event will not sell out in under 10 hours. To allow developers to be notified when tickets become available there is WWDCalerts.com which announced that they have 9000 subscribers so far. Mind you all these are competing for about 5000 tickets. Well that REALLY scares me.

I talked to John Geylense – head of developer evangelism at Apple – at last years Apple tech Tour in London. When I suggested to him that Apple should do one regional WWDC per continent he responded that he thought that this would be too expensive and that they couldn’t ship around all the engineers to the events. Then I pointed out that maybe 3 events – evenly distributed around the globe – would probably cost less than the 10 road show events combined because of all the flights and hotel rooms they would have had to book for the road show.

Though I fear that this suggestion – which probably many other developers have given as well – has fallen on deaf ears. If I were a betting man then I would still put my money on a single WWDC in June, followed by a 10 city road show later this year. Oh wait … I AM betting on this, because I already purchased a flight and hotel for 2 weeks in June. And apparently many others as well, because I found that the hotel room costs twice the normal rate during the rumored week of WWDC.

Either way Apple should announce the event at least 3 weeks beforehand simply for the reason that peoples who will fly to the USA for the event will have to register for Electronic System for Travel Authorization if their country is part of the Visa Waiver system. If I am not mistaken you’ll have to do that at least 3 weeks before traveling.

Some creative developers have begun filing Radars to express their frustration with not being able to buy a ticket or even knowing the official date. Unfortunately that seems to be the only way to communicate with Apple when we are dissatisfied with them. Just as unfortunately you cannot ever hope to get a useful response for these kinds of non-technical bug reports.

The other creative way I found how some people deal with the fear of missing out is to form Dub-Dub-Buddy-Teams. Thereby two developers both agree to buy an extra ticket for each other, just in case. This way there is a higher chance that both will get a ticket and if there are any left over it would be easy to find a buyer for that.

Radar, To Fix or Not To Fix

Speaking of Radar. The number of people who have registered their Radar-fixing Radar at Fix Radar or GTFO is holding at 329 which is a sad and low number. I would have thought that this cause should have been able to unite more than 300 developers. The goal of this initiative is to inspire Apple to improve their bug tracking and feature requesting system. I inquired why many more developers are taking objection to the goal of the initiative or the tone it is written in.

Some developers are afraid that they might anger somebody at Apple. And that this would cause Apple engineers to delay fixing the actual bugs they filed. While I can understand this fear, I refuse to believe that Apple engineers are vengeful and I refuse that this sort of egotistical thinking would be the norm.

Oleg Andreev even goes as far as calling the initiative “nonsense“. He wrote:

Developers do not need a radar. Apple needs it. And they make it good enough for themselves, not for 3rd party developers. If the UI sucks and they get 10 times less bugs than people would love to file, it must be something they are okay with.

I’m interested in your opinion. Did you file your duplicate Radar mentioning the one from the site? Or did you write a lengthy blog post explaining why this is futile? Or if you did neither, what is your reason for your inactivity? Could not be bothered? Leave me a voicemail under (415) 860-4324.

Peter Steinberger caught a glimpse of Apple’s internal Radar.app and tweeted:

The funny thing is, now that I’ve seen Radar.app, I totally understand why Apple never gonna release that. ^^

So it might be simple embarrassment why Apple does not let us have the Radar app so far.

I have my doubts that Apple will every open the issue tracking system even a tiny crack. So that’s why you should also post a copy of your bug report to the OpenRadar site hosted on Google Apps. Every now and then when I trip on a bug I found – when googling for it – that either somebody asked about this bug on Stack Overflow or there is an Open Radar entry for it. If you then file your own Radar you can mention the other Radar for reference. That probably makes the Apple engineer’s live easier to categorize the bug report as well as gives us some peace of mind that we can be reasonably sure that it is not our code that has a fault.

Xcode Jobs

In the previous episode I told you about this new hobby project I started and called XcodeJobs.com. The idea here is basically that through all the Twittering that I do I see many iOS developers and development companies looking to hire iOS developers for fixed staff positions. Now it is my believe that regular job adverts just don’t cut it any more to capture the attention of experienced developers. You need to be a bit more creative than simply list all the skills you are looking for. Why should this iOS expert be interested in working for you when can just as well can have his own small business doing contract work?

XcodeJobs.com is set up such that if you sign in you immediately have the rights to create a blog post with a creative description of what you do and why candidates should closer look at your company. The best example I’ve ever seen for a creative iOS job advert was by Polarbear Farms. They sort of a billboard that looked a bit like a blue print. This brilliantly examplifies how to create an advert that is both memorable and intriguing. The link to the one iOS Jobs rundown I did a while back on my blog is also in the show notes.

The blog goes together with a Twitter account by the same name which I’m now using to retweet all the job offers that come before my eyes. Though I’m filtering a bit there as well, I have a bad feeling about retweeting job tweets that have a #jobs hash tag or that lead to websites that are obviously commercial recruiting agencies. That’s another thing that you definitely shouldn’t use if you are looking to prove your originality to your next iOS developer employee.

So – long story short – if you’re ever looking for somebody, then please do a creative ad at XcodeJobs.com or if you couldn’t be bothered then at least tweet a link to a job offer on your own company website so that I can retweet it.

Feedback

I love to hear from you, you can email me at oliver@cocoanetics.com or tweet me @cocoanetics. If you want to give me audio feedback or have some interesting comment for me to play on the show please call my Google Voice mailbox:  (415) 860-4324

I reported late in 2011 on what the process is to move from an individual to a company developer account. One effect of this change is that you are getting a new developer account identifier which is a long number beginning with an 8. The main advantage of this move is that you can have multiple team members.

Having been on a company account for a couple of months you might notice that you get daily, weekly and financial reports for both the old and the new account. On iTunes Connect you have a selection to choose the old and the new account. While you cease to receive entires on the daily and weekly reports after a very short transition period you will see financial reports to go on in parallel quite some time longer.

I have been wondering why this is and through probing inquiry with Apple’s Finance Team I managed to uncover the reason for this.

I switched in October 2011 and you can see a drastic drop in the financial report numbers after the switch. But I still have  a couple of dollars of earnings as late as the March sales report for USA. The explanation in one word: Sarbanes-Oxley, in one sentence: It’s the law!

No Back-Dating Allowed

When a customer purchases an app they make that purchase with a credit card, since they are unable to submit payment with cash through iTunes. Once they click to buy your app, that sale will appear in the daily trend reports. The credit card company has to release these funds to Apple, which may be on the same day, within a week, or even longer.

Therefore, there are times that a customer clicks to purchase an app in one fiscal month, but the funds are released to Apple in a different fiscal month. When the credit card company releases the funds to Apple, they get reported in the financial reports. They are only allowed to report transactions that have completed their financial systems, and that may not necessarily be the month in which the transaction was initiated.

Apple has to report those funds when they are received and cannot back date them as that would be illegal accounting acceding to Sarbanes-Oxley rules. This is why you may see differences in the trends reports as opposed to the financial reports. Apple has no control over how long it takes the credit card companies to release the sales earnings to them.

Conclusion

In summary it is not Apple’s fault but entirely the credit card companies’ which apparently can take several months (!) to release funds for individual purchases.

I was told that this transitional period can last several months and while it is a pain to deal with those minute extra reports I can only hope that some day the credit card companies have found and reported all these individual purchases to Apple.

Oh well, maybe … some day …

Inspired by the Gmail Tap April Fools joke by Google I felt inspired to program the same thing for iOS. There we have custom input views as well as the UIKeyInput protocol and so I figured it should be an easy undertaking.

The whole affair took slightly more than one hour and I was hoping to record it in 1 second intervals with ScreenNinja. Unfortunately it seems that this otherwise fabulous app crapped out on me. I later discovered that the MOV file had actually finished before the crash, so to my delight (and hopefully yours too) you can follow this tutorial on YouTube.

In the video you see the whole process from start to finish. Let me just offer some clarifications in this post so that you better understand what I am doing.

http://www.youtube.com/watch?v=w5lRUE1Xet8

In iOS Apple provides us with two protocols, UIKeyInput for inputting single key strokes and UITextInput for everything that’s more than single keys, like text selection, auto correction etc. As part of UITextInput each conforming UIView implements an inputView property that can be any UIView.

If set this inputView is shown instead of the standard keyboard, if not then you see the keyboard. So for our example all we need is a UIView with one button for the Morse button.

The Gmail Tap prank interface uses two buttons, one for a dot, one for a dash. When researching Morse Code on Wikipedia I found one slight problem with this approach. Individual letters have to have a slight pause from each other because otherwise we wouldn’t know if by a dot the user intends to write an E or one of the other dozen or so combinations that have a dot as the first part of a sequence.

The Morse alphabet doesn’t just consist of 2 letters, but rather it uses 3 which are “dit”, “dah” and a silent pause. Given that “dit” is the shortest element, a “dah” is three times as long. Sequence elements are spaced one “dit” apart, Letters are spaced one “dah” apart and the length of 7 “dits” signifies a word break. Really, I am not making this up!

First step is to override canBecomeFirstResponder and return YES.

For simplicy I just wired up the UIControlEventTouchUpInside and the UIControlEventTouchDown to two methods and I’m using the time interval between the touch down and the touch up to determine if we saw a “dit” or “dah”. A bit of pause handling with performSelector:withObject:afterDelay: was necessary to get the breaks decoded.

Then there is a lookup table from which to draw the actual letters once a letter break is encountered.

+ (void)initialize
{
	morseLookup = [NSDictionary dictionaryWithObjectsAndKeys:@"a", @"··−·",
						@"b",@"−···",
						@"c",@"−·−·",
						@"d",@"−··",
						@"e",@"·",
						@"f",@"··−·",
						@"g",@"−−·",
						@"i",@"··",
						@"j",@"·−−−",
						@"k",@"−·−",
						@"l",@"·−··",
						@"m",@"−−",
						@"n",@"−·",
						@"o",@"−−−",
						@"p",@"·−−·",
						@"q",@"−−·−",
						@"r",@"·−·",
						@"s",@"···",
						@"t",@"−",
						@"u",@"··−",
						@"v",@"···−",
						@"w",@"·−−",
						@"x",@"−··−",
						@"y",@"−·−−",
						@"z",@"−−··",
						@"0",@"−−−−−",
						@"1",@"·−−−−",
						@"2",@"··−−−",
						@"3",@"···−−",
						@"4",@"····−",
						@"5",@"·····",
						@"6",@"−····",
						@"7",@"−−···",
						@"8",@"−−−··",
						@"9",@"−−−−·",
						nil];
 
	for (NSString *oneSequence in [morseLookup allKeys])
	{
		_longestMorseSequence = MAX(_longestMorseSequence, [oneSequence length]);
	}
}

The final piece of the puzzle is that we somehow need to have a pointer to the text control so that we can insert the detected characters. I was puzzled by the fact there does not seem to be an obvious method to do that. So I went for the obvious method of setting it in the init.

The input delegate (e.g. a UITextField) has to be compliant with the UIKeyInput protocol and therefore we know that it must have an insertText: method. This will insert the passed string at the current cursor position.

Conclusion

Turns out the by far hardest part of making our own custom keyboard is the input logic, which itself becomes way more complicated by having to invent algorithms to decode Morse sequences.

There are several improvements that spring to mind right away. Auto-Completion would be one where it could show a decreasing number of possible sequences based on the sequence for a single letter so far. Maybe that could be shown if the finger is lifted outside of the button.

Another question to tackle is how to actually delete text, the backspace key if you will. Maybe by doing a “dit” that begins on the button, but ends outside to the left of it?

Finally there should be no set amount of time for a “dit”, experienced Morse-o-graphers can have much shorter dits as long as the relation of dits, dats and pauses remains mostly constant. In this tutorial I went for the easiest method of simply using the latest dit’s duration, but it would be nice to average this over time.

Source code of the full project is available on GitHub.

I was already packing my suitcase for my vacation next week when I learned about the makings of the biggest scandal that is about to happen on the Apple campus. And I am not talking about AntennaGate or WarmGate, this is a REAL scandal! I just had to sit down and document the facts – as we know them so far.

A source close to the matter informed me (on condition of anonymity) that Apple CEO Tim Cook has set a plan in motion that will – so he fears – dramatically tarnish Apple’s reputation and throw them back to the technological stone age … at least when it comes to social media.

It is a little know fact that shortly after returning to save Apple in the late 1980s Apple founder Steve Jobs established a strict ban on smoking cigarettes on the Apple campus. This was not even known to his biographer and thus omitted from the book. Contrary to what was written in the biography it were not health concerns or even a public mandate, but Jobs had gotten hold of an internal chart that showed a correlation of number of source code lines dropping and the level of smoke addiction of individual employees. Smokers’ productivity was roughly 5% lower than their peers, and Jobs reasoned that the frequent smoking breaks must have been the reason for that.

Steve Jobs was well aware that this was a very unpopular move and so he mandated that this be kept a secret. This ban took place in 1998 one year after US President Bill Clinton signed Executive Order 13058 which banned “smoking in all interior spaces owned, rented, or leased by the Executive Branch of the Federal Government, as well as in any outdoor areas under executive branch control near air intake ducts. The rest is history, Apple was saved partially because of the invigorated productivity and rose again to become the most valuable brand in history.

Apple’s current CEO Tim Cook had not been aware of this unpopular decision because he joined Apple much later, in 1998. They say “those who do not know past mistakes are bound to repeat them.”. This post is a chronicle of one CEO probably proving this adage right.

Cook had already been acting as interim CEO when we learned in Spring 2011 that there had been a drastic decrease in programmer productivity as of late. This had resulted in iCloud being buggy and would not make the deadline of getting released at WWDC 2011 together with iOS 5 and the new iPhone. iCloud is Apple’s big bet and not being able to ship the iPhone 4S with iCloud in Summer  2011 caused the CEO to go on a rampage. No real solution was found and so Cook decided to preview iCloud to developers in June and do the actual launch of iPhone and iCloud in Fall.

About the same time as this happened Apple – quite uncharacteristically – had begun talks to enter a partnership with Twitter to integrate their popular social network with Apple products. We know that the partnership was fruitful, Twitter gained even more popularity because of the tight integration with iOS and Apple finally was able to shed the ridicule they incurred from launching Ping. One side-deal of this partnership was that Apple would get access to the Twitter “firehose”, the unfiltered unrestricted live-stream of all tweets.

This stream of tweets would be used to train the artificial intelligence product Siri which Apple had acquired in April 2010. But that was not the only use the CEO Cook had in mind for the combination of Siri and Twitter.

Being “old school” and an avid runner Cook is considering social networking as much as a waste of time (and health) as smoking. He developed the theory that all these frequent interruption and “quick tweets” would be detrimental to programmer’s productivity. But before the partnership with Twitter and the acquisition of Siri he had lacked a way to prove this theory.

Apple employees are living in constant fear of overstepping the line when it comes to social networking. My source told me that one of the first things that new hires are being told is that they should refrain from tweeting about work and keep their employment a secret from the public. This is why you often see profile descriptions like “I work for a fruit company” and “I speak for myself and not my employer” in Twitter profiles of Apple employees. Other ways of masquerading include discussing BMW cars, music and the liberal arts.

Ironically these terms are forming a recognizable pattern that an AI like Siri can look for and this identify the Apple employees who are spending way too much time in “tweeting around” during working hours.  This finally gave Cook the information he needed to produce a list of 1000 most-distracted individuals who will find themselves on the ejection seat as of coming Monday.

On a recent conference call with investors call Cook had mentioned that “we’re doing some things are differently now” and we now know what he meant. Cook is known to be ruling with an iron fist over the “regular foot soldiers”. So in stark contrast to Steve Jobs, who was content with a ban, he is going to be laying off the individuals on his hot list.

Why now? Well Apple’s stock price is on an all time high and the next big event will be WWDC 2012 in June. So the strategy is to do the layoffs in April because the “shareholder value” can digest this the easiest right at this time.

Apple has been hiring new employees like crazy in the past few weeks, partly because the company is growing in leaps and bounds, partly because Cook has instructed his VPs to buffer the coming bloodletting. Also managers were instructed to not hire people who are overzealous on Twitter, Facebook and Google+. Instead an internal memo is instructing them to respond with “sorry, but you weren’t a good fit” when asked for the reason of rejections.

My own reaction to this – despite my disbelief – is that I couldn’t believe it to be true. In my humble opinion this will cause a major outcry in the developer community and Apple will find it much harder in the future to find good programmer talent. Of course Apple will deny it and try to silence laid off individuals by threatening severe legal actions. And if you know Apple’s Legal Department then you are afraid of them.

It is because of this that I am asking you to tell everyone about this shady maneuver. We should not let Tim Cook get away with dismantling our beloved Apple this way. Social networking is not a crime and even less it can be likened to smoking. We should let Apple know that if they seriously will go ahead with the layoffs then we’ll all be switching to developing for Android. I know I will.

Update: April Fools!!! Sorry if I caused any actual Apple Employee’s to sweat and hastily delete their Twitter accounts.

Episode 31, recorded Saturday March 31st, 2012 – UDID FIre

Mach ado about UDID, jobs for iOS developers abound and my guest today is Appsfire Co-Founder Ouriel Ohayon.

News

Apple informed developers via e-mail that iTunes Connect will have individual reports for Sweden and Denmark from now on. For March, app sales earnings in Sweden and Denmark will be split and reported in two different documents, one covering the time period before the change and one covering the time period after the change. Earnings from sales that occurred before the change will be in the Euro-Zone (EUR) financial report. Earnings from after the change will be in the new financial reports for Sweden (SEK) and Denmark (DKK).

I am wondering what the benefit to us developers will be. Are the reporting guys SEARCHING for work to do that nobody actually cares about, just so that they are not bored?

Speaking of non-sensical changes: Apple invented two new price tiers. Tier 63 is $124.99 and Tier 69 is $174.99. Both tiers are available for both apps and In-App Purchases. Can anybody explain to my what this is good for? Are apps too cheap? Does Zynga want to sell more expensive In-App-Crap? You know, lower levels of tiers usually correspond with the price in dollars. The geek in me revolts, what is the secret algorithm here?

UDID, or didn’t you? Now that some rumors seemed to indicate that Apple might be beginning to reject apps that are using the unique device identifier developers are scrambling and are ripping out the trusty old identification code and replacing it with something new. But that only seems to be part of the story. Tapbots published the original rejection letter they received from Apple and this contains some very interesting information. This letter says that they where sending identity information to their server without having asked the user.

Apple seems to actually do a man-in-the-middle attack on HTTPS when reviewing our apps. Tapbots was sending the UDID in a HTTP GET request over HTTPS. If you simply look at the data packets then you don’t know the URL that is being requested because the first step in the HTTPS is to do a CONNECT. Then the GET is performed and already encrypted. This man-in-the-middle means that Apple has a tracing server that spoofs the HTTPS target and re-signs the packet such that it is still accepted by the URL connection on the device.

This is technically easy, I blogged about how to spy on any app’s traffic with the Charles debugging proxy app. What’s interesting that we learn for the first time that not even encryption is holy to Apple. So if you are sending something naughty to your server, then don’t rely on HTTPS thinking that nobody can see the contents. Better to send hashes instead of plain text. This is sort of similar to when the Path app sent your address book.

Many people ask: what should be use instead of UDID and the privacy advocates generally say: nothing. A user is not the same as a device. About the only market that requires to uniquely identify devices is advertising, especially when it comes to conversion tracking. If you need to have some sort of temporary identifier then you can use CFUUID to create one and then you can store it in the keychain. This will persist even when the app is removed as opposed to the user defaults.

For those who are developing libraries for ad networks the de facto standard has become the OpenUDID project which is available on GitHub. It was developed by on of the founders of Appsfire. There is a second competing project called SecureUDID but when I surveyed the market as to which is winning I found that most ad networks had switched to using OpenUDID. This includes the MobFox framework which you might know that I originally developed.

Flurry Analytics reports the relation of income of the three major app stores: Apple’s app store, the Amazon app store and Google Play (aka the Android app store). The comparison they came up with is this:

$1 on Apple’s App Store is 89¢ on Kindle and 23¢ on Android

What’s interesting is that Amazon is able to get the value proposition for developers into the vicinity of where it is for us iOS developers. Well it certainly helps to have the marketing experience of the world’s largest retailer and a dedicated device that locks people into their marketplace. And it still gives us a warm and fuzzy feeling that we are focussing on the app store where the most money is made. Our grass is greenest, yeah!

Here’s another good reason why we developers should always buy the latest Apple devices. An iOS forensics company has created a tool that lets law enforcement officials find out your passcode lock. There’s a video where you can see them boot an iPhone with their own custom boot loader. iPhone hacker Chronic has told me that iOS devices with an A5 chip are safe.

A5 devices can be jailbroken on a per-firmware basis, but their exploit(s) are userland-level, so passcode lock is safe.

That means you should have no less than an iPhone 4S if you are worried about that the law or some lawless thugs who got hold of this software can decrypt all your secrets. Hey, it’s a business expense and of course we need proper test devices for our jobs.

Speaking of security, the Australian Department of Defence has published a PDF that treats in great details all the security aspects involved in using iOS devices in official agencies. It’s a great manual to have and pass on to IT guys who are evaluating use of iOS devices in the enterprise, it contains background information as to which questions you should ask from government contractors whose apps are to be used on those Secret Agent devices. Conversely if you ARE such a developer who is interested in the vertical market of government software then this guide contains all the questions that you probably will be asked. So you can prepare yourself accordingly, and have your apps be secure by design.

If you are looking for iOS or Mac developers for your compony or are looking for employment as such then I’d like to draw your attention to my new hobby project. I wanted to have a blog – combined with Twitter feed – where you could get the pulse of our industry. Though I don’t want to have any extra work, so I made it such that if you create a login on XcodeJobs.com you can write a short blog post about the positions you are trying to fill. This I can then publish very early. If that is too much effort for you then you can also tweet me a link to the job profile on your own site and I’ll retweet it with the @XcodeJobs twitter account.

This is completely non-commercial and Recruiter-free. When I was looking for a name for this baby I realized that all my favorite platforms we use Xcode to develop for. And since the name was free I grabbed it. If I hear from Apple’s legal department I can always change it later. But they say: “we’ll cross this bridge when we get to it”. Right now there are record numbers of people tweeting about the site and following the Twitter account. So why not benefit from this attention too?

Oh and speaking of hiring. I have hired my first actual real employee! And it’s great! He’s going to start working with us next month and I can already feel our output increase. Many iOS developers shy away from this sort of commitment, OMG how much that costs. What if you don’t have any work any more? But the reality is, that work always grows larger and larger and frankly I cannot afford to pay for contractors. At the current rates an employee costs me about a third as much as a contractor based in USA or Europe.

Guest: Appsfire Co-Founder Ouriel Ohayon

We chat about why there is a need for a UDID-replacement and what is is used for.
Appsfire App on the App Store

Feedback

I love to hear from you, you can email me at oliver@cocoanetics.com or tweet me @cocoanetics. If you want to give me audio feedback or have some interesting comment for me to play on the show please call my Google Voice mailbox:  (415) 860-4324