Some thoughts about Swift

Apple announced a new language for iOS development at WWDC 2014. I anticipated this would happen at some point (not necessarily this year, but this year or next). I got that much right, but what I got wrong was the language that was announced.

I thought the language would be JavaScript, but it turned out to be a new language called Swift. I was wrong about what language would be used, but I had a feeling that there would be some new language added to Xcode.

Starting in 2013 I started seeing some signs from Apple. The first sign was that every single demo at WWDC used Storyboards and not code-based building of UI – or even nib-based UIs. The second was the embedding a stand-alone JavaScript engine inside of the iOS framework.

The third was really a continuation of the first: not only did every demo at WWDC 2013 use Storyboards, but every single demo app from the developer portal was redone using Storyboards.

I saw this as a two-part sign. The first part I saw as a natural evolution of Interface Builder, in which Storyboards started to get more functionality (and overall attention) from Apple than nib-based files.

The second part was that I was hopeful that eventually JavaScript would be a language that could be used across all mobile platforms, not in a Cordova/PhoneGap way using HTML5, but in a WinJS way, à la Windows 8 (possibly the only part of Windows 8 that I think was a good idea).

I saw that emphasizing Storyboard development could facilitate two important future-proofing functions.  First, to help future-proof against different device screen resolutions, second, to future-proof against new languages.

The more “code” accomplished in a Storyboard, the easier it becomes to hook up the Storyboard’s outlets and actions to code written in a language other than Objective-C. (Objective-C is a language that I really love BTW, but I understand others’ distaste for it in the same way I love Uni – aka Sea Urchin Roe – but I understand that it isn’t yummy to everyone’s palate).

So I thought a logical language that could be used to bridge between the UI and the UI framework (in this case UIKit) could be JavaScript. 

This will be the last time I will say it: I was both right and wrong at the same time.

So what do I think about Swift?

Looks like a cool modern language.  Some parts of it reminded me right away of C# -

One of the creators of Swift – – posted that C# was one of the languages from which they drew ideas, so that made me feel better right away.

My other take-away from the language is that, despite what everyone else seems to be saying, I don’t see a future Swift programmer being able to be a successful iOS programmer without knowing a lot (if not everything) about Objective-C.

Although Swift isn’t built on Objective-C the language, it is built on the Objective-C runtime, and (for the for-seeable future) will continue to use the Objective-C runtime during app execution.

It’s also important to remember that the frameworks that Swift programs will use (i.e. UIKit, SpriteKit, etc.) are all built with Objective-C. Apple’s samples are all in Objective-C. Over time, I am sure that more and more Apple samples will be ported to Swift, but until that happens many pieces of Objective-C code will persist in the wild.

Also remember that there is a large Objective-C-based set of samples, frameworks, and libraries built outside of Apple. Many of them will likely be ported to Swift as well, but it may also be that Swift developers will need to learn how to translate Objective-C code.

Another pertinent point: many APIs from Apple aren’t in Objective-C at all. The iOS AddressBook API is a C-based API. Again, it may be that Apple will end up wrapping all its C-based APIs with Swift-compatible APIs (e.g. an Objective-C-based API), but until that happens (and it hasn’t happened yet for Objective-C programmers and believe me – we’ve wanted it) some code will have to still be written in Objective-C.

I also notice that people are getting a number of things wrong about Swift.  For example this article: states that Swift has “automatic garbage collection” which isn’t technically correct.  Swift builds on the compiler technology for Objective-C that Apple added into the Clang compiler a few years ago: automatic reference counting or ARC.

So in conclusion, I think that Swift will cause current Objective-C programmers to be even more productive creating iOS apps than we already were .   It also is going to make the introduction to iOS much easier for new developers, since it has many more modern language features that developers are used to than Objective-C has/had.  But, since the Objective-C runtime is still underlying Swift language for at least the next few versions of iOS (if not forever), each Swift developer is going to need to understand those Objective-C runtime features, just like every C# developer needs to understand the CLR, and every Java developer needs to understand the JVM.


Building A Video-Streaming App: A Review of LeaseWeb’s CDN

I’ve had an idea for a while to create a mobile app that would enable people to easily find and view films that are part of the public domain. Many of these movies have substantial historical significance.

Of course, because of the size of these movies, generally players can’t simply download all the videos, but rather must download them on demand, or even better: stream them smoothly.

The best way to accomplish this is use Apple’s HTTP Live Streaming (HLS), which is automatically integrated into iOS’s video-playing APIs.

But where to host these files becomes the next architectural issue to tackle when designing the end-to-end functionality of such an application.

Scalability isn’t generally the first thing you think about when you create a website or an application. However, if you are planning for the future, or when you start to run into scalability issues, making sure that your static content (images, videos, etc.) is served from a cache rather than a server’s file system is essential to creating a set of happy users.

The obvious choice is to serve the videos from a super-fast Content Delivery Network (CDN) that is optimized for serving up videos.

LeaseWeb’s CDN is exactly the kind of CDN that I’d choose for this kind of application. LeaseWeb’s CDN has a number of unique features that make it the right choice for any number of different CDN-based solutions, but it has a special set of features that makes it a particularly good choice for building video-based applications.

One of those features is its superior bandwidth. LeaseWeb CDN has capacity of 500 GBps and growing, thanks to the placement of what they call SuperPoPs around the world (remarkable for a product that has been on the market for less than a year).

For large file distribution, like video, bandwidth is a more important measure for CDNs than latency. Large and consistent bandwidth can make (or break) the video viewing experience in an app or webpage. Buffering during the middle of watching a movie is a quick way to get customers to stop using your app, give you bad reviews, or both.

LeaseWeb CDN’s superior network bandwidth, along with its low latency due to edge server locations in Europe, US, and Asia, makes it a perfect choice for global video-based applications.

On top of the infrastructure, LeaseWeb also has a sophisticated HTML5-based CDN Control Panel that takes away the complicated configurations that most Content Delivery Networks have.


The CDN Control panel not only has a dashboard that can show you your bandwidth usages in real time and historical information about your traffic, it also has all the functionality necessary to completely manage your Pull and/or Push Zones. Your configuration can be fully managed through this UI, but is also accessible via an easy-to-use API.


The CDN has support for static files (including video), as well as support for HTTP Live Streaming, or Video on Demand HLS.

Using a Pull Zone is an easy way to keep your content on your servers, and allows the CDN to push your content out to its edge servers in its data centers around the world.

Because the video content is already hosted in LeaseWeb’s data centers, this makes using LeaseWeb’s Cloud Server for hosting login and other API functionality a natural choice.

Putting all of your content in one place, and having that place take advantage of LeaseWeb’s fast virtualized computer resources as well as the fast connection between those computer resources and the CDN, make it the perfect pairing, especially for dropping new video files, or processing on those files.  Having your content and your cloud-based server functionality all in one place means that functionality will be as fast as possible.

Learn more about LeaseWeb:



Disclosure of Material Connection: I received one or more of the products or services mentioned above for free in the hope that I would mention it on my blog.  Regardless, I only recommend products or services I use personally and believe my readers will enjoy.  I am disclosing this in accordance with the Federal Trade Commission’s 16 CFR, Part 255:  “Guides Concerning the Use of Endorsements and Testimonials in Advertising.” 

SSL Pinning for NSURLSession

One thing that really bothers me when I review or test apps is that they are so easy to subvert using an SSL Man-in-the-Middle attack.   I’m no security expert (although luckily I count one as a good friend - )

This is a good start – but it doesn’t take into account iOS7’s new NSURLSession API.

The first thing to do with NSURLSession is to implement the NSURLSessionDelegate protocol.  Even if you plan on using the NSURLSession block helper methods, having a class in your project to manages all the calls to NSURLSession makes sense and and enables you to implement that NSURLSessionDelegate on that class – as long as you pass the same object to each block call on NSURLSession, they can all use the same NSURLSessionDelegate class (or instance if you are into using static classes , which I use quite often – but not going to get into the whole “statics are always evil” discussion here – maybe in another post).

This code gets called each time an SSL handshake happens.  It is pretty simple, it turns the cert presented by the server into a NSData object.  It then loads the cert from the bundle, and compares them.  If the comparison succeeds – we know that the cert presented by the server is the same as the cert we are looking for.  This of course means we need the cert to be a resource in the app.

We also need to make sure to fire the completionHandler passed into this method.  It is only with a “use” or “reject” enum passed to the completionHandler – will the NSURLSession know what to do.  If you forget to do this – all your networking basically just shuts down.

I’m also defining another delegate – so that based on the results, I can notify another part of the app to do something useful.  If  the cert is rejected – I know that the cert isn’t the right one, and likely there is a MTM attack going on.  You can test this by running your app through a proxy that does SSL decryption – like

//this will be in an imported header file:
//this is my definition of a delegate that my "ServerConnenctionManager" uses to notify interested parties if a connection fails
typedef NS_ENUM(NSUInteger,ServerConnectionManagerStatus) {


@protocol ServerConnectionManagerDelegate
//this will be in the class that implements the 
- (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential *))completionHandler{

	if ([[[challenge protectionSpace] authenticationMethod] isEqualToString: NSURLAuthenticationMethodServerTrust]) {
		SecTrustRef serverTrust = [[challenge protectionSpace] serverTrust];
		(void) SecTrustEvaluate(serverTrust, NULL);
		NSData *localCertificateData = [NSData dataWithContentsOfFile: [[NSBundle mainBundle]
																		pathForResource: SSL_CERT_NAME
																		ofType: @"crt"]];
		SecCertificateRef remoteVersionOfServerCertificate = SecTrustGetCertificateAtIndex(serverTrust, 0);
		CFDataRef remoteCertificateData = SecCertificateCopyData(remoteVersionOfServerCertificate);
		BOOL certificatesAreTheSame = [localCertificateData isEqualToData: (__bridge NSData *)remoteCertificateData];
		NSURLCredential* cred  = [NSURLCredential credentialForTrust: serverTrust];
#ifdef DEBUG
		certificatesAreTheSame = YES;

		if (certificatesAreTheSame) {
			completionHandler(NSURLSessionAuthChallengeUseCredential,cred);		}
		else {
			[self.delegate connectionFailure:ServerConnectionManagerStatusWrongSSLCert];



Where I've been…

Sorry this blog has been quiet. I’ve been heads down getting new courses up on Pluralsight.

I plan to be back here on a more regular basis as I get into the groove now of moving from doing mostly instructor lead training to online training. I’m really enjoying the transition, and I think Pluralsight is in the forefront of this area.

Here’s a couple of the courses I’ve done recently.

1) iOS for .NET developers  – since refocusing my work on HTML5 and mobile – I found the need to be able to deal with native code on mobile devices as well.  iOS is my favorite mobile OS (the one that I use every day at least).  So I went to dig down into that.

I’ve written and talked a lot about building Hybrid mobile applications - and I still think that Hybrid applications have a great future for almost all apps – and a great present for a wide range of applications.

But the limitations are there for many apps today – so the best option IMO (and I’ll be blogging more about this in the coming days) is to go native.

Objective-C and xCode aren’t as scary as many .NET developers think and this course should help jumpstart you if you want to make the leap from MS technologies to Apple.

2) Introduction to xCode


In keeping with my move over to iOS I thought it was important to have an xCode course in order to help all iOS developers master their tool – so I hope this course does that.

3) Introduction to Arduino

I’ve always been interested in Arduino and prototyping hardware designs.  Working with Pluralsight gave me the change to purse this interest and I hope this course is useful for other people who want to do the same thing.

4) Mobile First Responsive Web Design

This one just came out today!  If you are interested in learning more about Responsive Web Design and how to do it using a mobile-first approach this course is an introduction for developers to learn the ins and outs of the concepts – as well as the tools and skills you’ll need to be able to implement responsive designs.