Another WWDC

This week, I had the opportunity to attend Apple's Worldwide Developers Conference (WWDC). I've been to a number of other WWDCs with the last one being in 2008. Things have changed significantly in the past years as the popularity of iOS (iPhone and iPad OS) increases. Unfortunately, I don't think that the changes are for the better.

I've been writing handheld software for almost 17 years and been writing Objective-C software for around 10 years which now makes me one of the old timers in this game. In order for Apple to cater to everyone (all 5200 attendees), they have had to dumb down many of the sessions. In addition as indicated in the keynote, WWDC was going to cover Lion, iOS 5 and iCloud. With iOS 5 being released in the fall, it will be a long time before I actually get to use features in iOS 5, so I've sat through many sessions containing information about stuff I can't use for awhile. Typically the apps I write can't drop support for an operating system for about a year. (There are some cases where we can use newer features, but for the most part, we have to use the same features across all OS versions.) As my products are now requiring iOS 4, I can learn some of the information from last year's conference.

WWDC has grown each year which caused it to sell out within hours this year. I was on top of things, so I was able to get a ticket. With all of these people clamoring to absorb all the informations they can, attendees end up waiting in lines for each and every session. This gets old quite quickly. Last year Apple put out the WWDC videos pretty soon after the conference and I hope they do that again this year; watching the videos may be as valuable, or even more valuable, then being at the conference.

The real value, for me, was hanging out with my co-workers and meeting other members of my group that I've only met by email. This, of course, is invaluable and there is really no substitute for it.

Will I be coming back next year? I'm not sure.

Trust in business

This week I've seen a number of "leaks" showing Lion and iOS 5 as well as people Tweeting about some of the information contained in WWDC sessions. Everyone that attends WWDC has to agree to an NDA (non-disclosure agreement for those not in the loop) and Apple stated everywhere that with the exception of the keynote, the content of the sessions was confidential and subject to the NDA. So, all these leaks are violations of the NDA. Besides what I've read on the web, the most flagrant violation I saw was someone taking a picture of the slide that said something on the bottom to the effect that photography was not permitted!

As Jason Snell tweeted a few days ago:

And with that, I declare the NDA completely dead. RT @daringfireball iOS 5 Screenshots and Tidbits at Engadget: df4.us/hqy

There are, unfortunately, no consequences to these NDA violations as Apple wouldn't accomplish anything by suing the small developer. However, that is no reason to violate it as it won't help any developer get ahead (I doubt the sites that have published information have paid the developers).

The first point of the Scout Law is "A scout is trustworthy". I always try to live by this and this includes everything I have done in every aspect of my life including business and work. I wish that more people, especially those in my field, would take trust seriously.

More pitfalls to synchronous networking

Anyone that reads my blog or talks to me professionally knows how much I hate dislike asynchronous network programming. While working on rewriting some networking code, I came across a few more reasons why synchronous networking is a poor decision.

The first issue occurs when a developer abstracts the networking, then forgets that when the call is invoked, it actually makes a network call and does it on the main thread. Synchronous networking should never be done on the main thread. For instance, let us use the following made up example:

- (void) displayUserPreferences
{
	Preferences *prefs = [[Utility sharedInstance] getPreferences];
	if (prefs)
	{
		// Update the user interface
	}
}

- (Preferences *) getPreferences
{
	NSDictionary *dict = nil;
	NSData *result = [Networking queryPreferences];
	if (result)
	{
		dict = [self parseData:result];
	}

	return dict;
}

+ (NSData *) queryPreferences
{
	return [NSURLConnection sendSynchronousRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://www.something.com/data.json"] returningResponse:nil error:nil];
}

In order to not block the main thread, the developer has to always make sure that displayUserPreferences is called on a secondary thread. While this may sound simple, forgetting to do this is quite easy especially for a developer that didn't initially write the code. Another developer might think that getPreferences is a local call and doesn't hit the network and therefore call displayUserPreferences on the main thread. This is, of course, a recipe for disaster.

The second issue isn't specific to networking, but has to do with threading. In the above example, the "Update the user interface" code under the comment must run on the main thread as user interface calls can/will crash when run on secondary threads. It is far too easy to forget to use performSelectorOnMainThread to run the code on the main thread. Having to keep track of what can and can't run on a secondary thread just adds confusion and inevitably will lead to mistakes. A simple call like:

[self.tableView reloadData];

run on the secondary thread for networking will cause a crash.

I've seen both of these issues in code and there really is no excuse for being lazy in writing networking code. Once you write a good networking class, it can be reused over and over; I've used a networking class I wrote a few months ago in 4 or 5 different projects. I wrote it once; tested it extensively and now reusing it is quite simple.

I'm tempted to file a radar bug to ask Apple to deprecate the synchronous call, but I know that they won't do it. The synchronous networking call screams lazy and should be avoided in my opinion.

Authentication security in iOS apps

When I read a post that John Gruber wrote today about OAuth in native Twitter apps and how much of a poor user experience it is/will be, I had to dig deeper into the article. On first read of the article, I disagreed with him as I thought he missed a very important point about security, but upon re-reading it, he did identify one of the major issues with how OAuth (and other types of service authentication) is done on iOS, in particular.

Developers can alleviate some of the context switching by using an embedded web view inside their native app for the OAuth authentication handshake, but at that point, why not just use xAuth and simply allow the user to enter their username and password in a native dialog box? So long as you remain within the app, there’s no security advantage for OAuth in an embedded web view over xAuth...

This is something that most users are unaware of when entering their credentials in any iOS app. As long as you are in the app, even if the page says Facebook, Twitter, Dropbox, etc. and you're not running an app from these companies, the app can capture your username and password. Some companies ship their libraries to developers in a form that doesn't let the developer modify the source code, but that offers zero protection from a malicious developer that wants to steal usernames and passwords.

I've seen one application launch Safari, ask you to login to Facebook and when done, returns you to the app. From a security point of view, this is the ONLY way to ensure that the application doesn't capture your credentials (provided that you trust that Safari isn't stealing your credentials). Any embedded web view offers no guarantee that the app isn't hijacking your credentials as the app can walk the hierarchy of views and grab info; in a kiosk I worked on, we presented web pages, but I modified the web pages before displaying to change the credit card field to a password field to mask the numbers; this type of modification of web data is quite easy when a developer controls the entire app.

Should you be worried? That all depends. Do you use different passwords for every service? If not, consider using 1Passwd. Yes, it may be a pain to enter the random password on a mobile device, but if some app got access to the password you use on all your sites, the risk is great. Are most developers honest? Yes, but bugs in the code could put your password at risk. Also when I tried out apps for Google Voice, I had some strange feelings about an app, so I ran my iPhone's networking through Charles Proxy to see where the app was connecting; it was connecting to a site that wasn't Google. I had no idea if my Google Voice password (which is my Google password for email) was going to some lone developer's server. Based on the developer's posting in various forums, I didn't trust his app with my password.

Should users be inconvenienced by having an app launch Safari, enter credentials and then go back to the app? Personally, as someone a bit paranoid about security, I think it is worth the one time inconvenience (per app). The average user may not think this way. However, if the user was better educated in the app indicating that for security purposes Safari will be launched, that may mitigate the issue.