Getting Started With Swift 3.0 Part I

The Evolution of Swift and Swift 3.0

In the summer of 2014 at Apple’s Worldwide Developer’s Conference, the programming Language Swift was revealed. Since then, the software engineering world has seen a passion for a programming language unlike anything seen before. Swift has inspired those who were never interested in programming, with tools like Playgrounds, which make programming more interactive and approachable.

The language is open sourced to encourage developer involvement, allowing developers to literally shape it’s evolution. And enterprises that have business incentives for avoiding the use of Swift have begun eyeing it for potential use on their own, non-Cocoa platforms. This especially after IBM’s adoption of Swift as the core language for their cloud platform.

But while Swift enjoys great success in enterprise and popularity, it has not been without hiccups. Since its release it has altered its API twice, and now Swift 3.0 is next in line. However, the switch to Swift 3.0 is a fundamental change to the language, hosting a complete rewrite to its core library. The aim of this text is to guide you, the reader, through this change.

In this article we will cover the following topics:
– The Great Cocoa Renamification
– Why it’s important to understand the changes from Swift 2.2 to Swift 3.0, even if it’s incomplete
– Building a better API
– Swift, Objective-C, and You
– The Importance of the ABI
– Why Apple’s strategy to convert individuals to Swift while simultaneously simplifying the language is a brilliant move

Swift Grows Up

bigkidAfter years in the making, the first “mature” version of Swift will be released in the form of Swift 3.0. The first proposals for Swift 3.0 were introduced December 2015 and every proposal accepted since make it clear that Swift 3.0 will bring disruptive changes. Even at the time of the writing of this text, the final changes to Swift 3.0 are not guaranteed.

While it is difficult to predict what shape Swift 3.0 will ultimately take there is a philosophical commonality amongst the proposed and accepted changes: namely, that it is adopted by an even greater number of developers, and to simplify, simplify, simplify.

Why is it important to understand the changes from Swift 2.2 to Swift 3.0

The change in Swift 2.2 to Swift 3.0 represents the most significant refactor of the language to date. The authors of Swift justified their significant changes as a necessary messiness; the last, code breaking push before walking down the highway toward sustainability.

With Swift 3.0 we see fundamental changes to the design of the API, optimized libraries that reduce redundant code, Foundation structs that replicate the functionality available jot their Swift counterparts. As such, the change from Swift 2.2 to Swift 3.0 will break all pre-existing Swift code.

In an interview with Infoq the original creator of Swift, Apple’s Chris Lattner, expressed that this simplification will take many forms but includes things like removing unnecessary words specifying the type of the expected argument in the name of a method, removing the ’NS’ prefix from the Foundation APIs,


would become

Subsequently, this “Renamification” modifies the current Swift core library, Foundation, UIKit, the Objective-C library, and even the clang importer Objective-c interacts with.


Swift’s greatest change is its paradigm shift. The Apple Swift team decided that clarity supersedes brevity, that documentation is everything, and that if you are to add code, it should maintain clarity. This sentiment is seen everywhere in the API design guidelines and in the new standard library.

Conversely, while a great deal was added to Swift, a great deal was taken away. Perhaps the greatest feature originally promised then lost is ABI compatibility. ABI Compatibility (application binary interface compatibility) “refers to the ability to link pre-built (binary) libraries with arbitrary versions of a compiler.” What this essentially means for developers is that when we write APIs using a version of Swift, until an ABI is completed, only libraries of the same version may work

ClQzii4UYAAHDlZIt should be clear that this release is available for non-MacOS users and others capitalizing on Swift’s presence on Linux. As Lattner himself states, “The #1 goal for swift 3 is source compatibility

Building a Better API

So we know the importance of understanding Swift 3, but when we talk about improving the clarity of Swift and maturing the language what does this actually mean and what does it look like?

So far, one of the key features is following the new guidelines to writing the API. Taking a cue from writing greats like William Zissner, the Swift team is focused on minimalist language and implementation that create an instantly recognizable style to Swift.

If a method name’s code appears to repeat its meaning through uncomfortably long method names, or misplaced parameters it will be simplified by the team.

Developers note that Apple cannot “keep pulling the rug from under them ( ) sic ()” and so Swift 3’s maturation is by making long-lasting changes that will not result in yet another major overhaul and subsequently require developers to relearn the fundamentals of the language. In their judgment this begins with the writing and simplification of the Swift API. As such the Swift guidelines include the following:

Clarity at the point of use The Apple team behind Swift has indicated this as the most important goal. In doing so they note: Entities such as methods and properties are to be declared only once but used repeatedly. The new design guidelines for the Foundation API and the Standard Library aim to make those uses clear and concise. When rewriting the Standard library you’ll notice an effort ensuring understanding via example.

Clarity is more important than brevity Although Swift code can be compact, the Swift team believes in enabling the smallest possible code with the fewest characters. Brevity in Swift code, where it occurs, is a side-effect of the strong type system and features that naturally reduce

Documentation is Key Write a documentation comment for every declaration. Insights gained by writing documentation can have a profound impact on your design, so don’t put it off.[1]

The Clang Importer

Along with the new guidelines for the Standard Library come the changes to the “Clang Importer.” The Clang Importer is responsible for mapping C and Objective-C APIs to Swift. In Swift 3 the guidelines for translation of these objects changed in conjunction with the formal API Design Guideline Revisions and Standard Library.

Translating the Swift API naturally affects the Objective-C API so changes were felt in parallel. But the coding guidelines for Cocoa introduced a problem; while the current Cocoa guidelines are clear and effective for Objective-C and what it was intended for—Swift is a different language.

So the authors of Swift implemented major changes to the Clang Importer and to the Objective-C library itself which not only more closely follow the new API guidelines but which ultimately feel Swiftier themselves. 

For example, one of the major changes to the Objective-C API is the rewriting of method signatures so that Objective-C Swift string constants may be used as Swift enums.

This change was implemented so what we could use objects that didn’t threaten the compiler, and so that Swift could become more readable. And because constants are a reoccurring theme in Objective-C, it’s a useful change. Consider the HealthKit API, which would have the following converted to an enum:

The above are constants typical to APIs used in Objective-C. When adjusted with the new Swift and Objective-C API guidelines, you’d add a nullable attribute in order to promote type safety and you’d create the below.

That’s ultimately what the code is reading. But if you were to use the 2.2 version of interoperability the ‘+ (nullable)’ would be nowhere to be found. And so, in Swift 3.0, we’d make it explicit. Method signatures in Objective-C would then use the new typedef:

When we finally import the code to Swift, it should look like the below:

This allows us to call quantityTypeForIdentifier() from Swift with the struct constant directly, rather than having to call rawValue on it to extract the underlying String. The Swift code would look like this:

Once a type is imported as an enum, other modules—and the user of the API—will not be able to add additional entries. But that’s fine for you dear reader. You, after all, are only after Swiftness.

We can summarize the changes made to Objective-C to the following:

  1. Generalize the applicability of the swift name attribute: The Clang swift name attribute currently allows limited renaming of enum cases and factory methods. It should be generalized to allow arbitrary renaming of any C or Objective-C entity when it is imported into Swift, allowing authors of C or Objective-C APIs more fine-grained control over the process.

  2. Prune redundant type names: The Objective-C Coding Guidelines for Cocoa require that the method describes each argument. When those descriptions restate the type of the corresponding parameter, the name conflicts with the omit needless words guideline for Swift APIs. Therefore, we prune these type names during import.

  3. Add default arguments: In cases where the Objective-C API strongly hints at the need for a default argument, infer the default argument when importing the API. For example, an option-set parameter can be defaulted to ().

  4. Add first argument labels: If the first parameter of a method defaults, it should have an argument label. Determine a first argument label for that method.

5. Prepend “is” to Boolean properties: Boolean properties should read as assertions on the receiver, but the Objective-C Coding Guidelines for Cocoa prohibit the use of “is” on properties. Import such properties with “is” prepended.

  1. Lowercase values: The Swift API Design Guidelines have non-type declarations lowercased. Lowercase non-prefixed values whenever they are imported, including enumerators (whether they end up in Swift as enum cases or option sets) and any other properties/functions (e.g., a property named URLHandler will be lowercased to urlHandler).

  2. Adopt Comparable to classes that implement compare(:) -> NSComparisonResult: The objective-c classes that implement

all have declared a capability of being compared in an ordered manner. Comparable formalizes this declaration into an implementable operator by the import process.[2]

To get a sense of what these transformations do, consider a portion of the imported UIBezierPath API in Swift 2.0:

And the same API imported under Swift 3.0:

In the latter case, a number of words that restated type information in the original APIs have been pruned. The result is closer to following the Swift API Design Guidelines. For example, this shows that Swift developers can now copy any object conforming to the NSCopying with a simple call to foo.copy() instead of calling foo.copyWithZone(nil).

[1]: Swift Evolution API Guidelines

[2]: src: Swift Evolution Objective-C API Guidelines

iOS Interview Problems via Swift 2.2: The Two-Sum

EDIT: My second problem was O(n^2). After crying for a few minutes I quickly put up a different, viable solution. 

Problem-solving for more data-structure/algorithm centered interview questions

If you’re a regular of mine, you’ll have noticed I’ve been silent for the past weeks. That’s because I’ve been buckling down and focusing on work. This week I’ve had the opportunity to resurface. Lately, I’ve been interested in data structures and algorithms; particularly those problems asked in interviews by major companies.

For whatever reason I’ve found these problems fun to solve (as challenging as they might be) and infinitely more interesting than the (four?) Tinder clones I’ve had to write. Whatever your feelings are regarding coding challenges, you cannot deny they are fun brain teasers.

I’ve been lucky enough to have a guide throughout my studying. Richard is a former employee of a few big four companies and is my inspiration for entering software engineering. Through him, I’ve seen the importance of individual structures that most programmers immediately dismiss as archaic or impractical.

So I figured I’d post the occasional problem here as solved via Swift. Starting with the ever popular “Two-Sum” problem. The Two-Sum problem has been asked of me several times throughout interviews. The problem is a variation of the “subset sum” problem. The subset sum problem requires dynamic programming (fun-fun) to solve, but the two-sum problem is much simpler and can be solved in O(n) time. (If you’re not familiar with that funny notation, click here).

On to the problem….

The Two-Sum problem asks you to find all the pair of two integers in an unsorted array that sums up to a given n. So let’s look at the following array as an example:

[4, 2, 5, 2, 9, -3]

Let’s say the sum we’re looking for is 6. Well the program should return [4, 2] [9, -3] because each pair adds to 6.

When I first approached this problem, or the “Naive Solution.”

The first thing Richard taught me to keep in mind when solving these sort of whiteboard problems is to think of the “Happy Path.” Lacking a formal education in software engineering (sans the Master’s I will finish… Maybe… One day…) I’d never heard of it. But it’s a useful conceptual tool we can use to figure out a case or potential solution to a problem. Happy path testing, specifically, allows us to concoct a test-case using a specific input. This input should proceed through the code and execute without error and produce an expected output.

I found this test-case thought process immensely useful. It’s completely changed how I code and how I think of problems when entering an interview. No longer am I paralyzed with fear wondering, “Where do I start?” Now I have a starting point. First, I think about the Happy Path test case. What will most easily solve this problem w/o thinking too deeply about edge cases? As soon as the Happy Path test case is determined, I move on to cases that would violate the problem and bring up errors. Or unique cases that I might not have originally thought of that solve the problem.

But how do I tease out these unique cases? Well by asking the proctor of the interview of course! This is where asking questions of your interviewer becomes intensely important. I was lucky to have Richard coax me into asking these questions, rather than immediately revealing what I should ask. In the case of the two-sum problem some great questions to ask your interviewer might be:

“Is there a limit to the number of items in the array?”

“Should I assume that each input has exactly one solution or more?”

“Are my returned answers zero based?”

And so on.

These sorts of questions ease the difficulty of the problem by limiting the scope of the question and demonstrate your thinking to the interview. If you can think of a particularly interesting question, you can even impress your interviewer (a task to aspire to indeed!).

Getting back to the code…

After asking the necessary questions the next step is to find the simplest solution called the “Naive Solution” or the “Brute Force” solution. My personal problem-solving style is to find quickly the simplest solution first, optimizing for Big-O notation afterwards.

In this case, the easiest solution is to loop through each number (or element)and then to loop again to find the value that sums up to n. (Another way to think about this is to loop through each eye, add, and find if there is a value that equals target-x plus i.

This approach’s runtime complexity is O(n^2), as finding the next value in the array requires us to loop through the rest of the array. How does this look?

In Swift 2.2, this looks like this:

While this code works, it eschews what’s most important: efficiency and scalability. We can reduce the runtime complexity of looking up value to O(1), however. How? By using a data structure, we constantly make use of in Swift: the good old dictionary. With a hash map (the true name for dictionaries–although I doubt an interviewer would hold it against you if you didn’t speak of them as such–we can map a value to its index.

Brace yourselves — higher order Swift is coming

2)This solution was created by Reddit User exorcyze  of r/Swift

Besides being much more efficient, this code also deals with edge cases we may not have initially considered. For example, what do we do in the case where our set of entered numbers is of count 1? In our first solution, we’d keep looking until we food the next number that added to the target. While the second loop would determine that there was no other number to find and simply end the operation. Note, however, that this problem is slightly different. In it, I was asked to return the indices of the numbers that add up to the required task. So the approach is different.

Notice this solution’s cleanliness. We’ve returned a hashmap that gives us exactly what we need: the indices which add up to the target sum we’re after. We have an O(n) for runtime and in space.

Of course, there’re other ways to go about this problem, and you certainly shouldn’t feel beholden to answering in the same way above. And if you do decide to knock these questions out and need a harder challenge here’s two variations:

(1)Performing the same TwoSum operation but with the array sorted.

(2) Designing and implementing a TwoSum class. It should support the following operations: add and find.

Add(input) – Add the number input to an internal data structure.

Find(value) – Find if there exists any pair of numbers which sum is equal to the value.

For example,

add(1); add(3); add(5); find(4) -> true; find(7) -> false

Happy puzzle solving and see you with a problem next time! (Brace yourselves, the next one I’ll post gets nasty). Oh and if you’re interested in this stuff shoot me an email. I have lots of problems.

References   [ + ]

1. x,y
2. This solution was created by Reddit User exorcyze  of r/Swift

Please Don’t Learn to Code Unless…

Silicon Valley
A million dollars isn’t cool

There’s an idea that’s been gaining ground in the tech community lately: everyone should learn to code.

But here’s the problem with that idea: coding is not the new literacy.

If you regularly pay attention to the cultural shenanigans of Silicon Valley, you’ve no doubt heard of the “Learn to Code” movement. Politicians, non-profit organizations like, and even former Mayor Michael Bloomberg of NewYork City have evangelized what they view as a necessary skill for tomorrow’s workforce.

There may be some truth to that, especially since the United States’ need for engineers shows no sign of slowing down.

But the picture is more complicated.

We live in an ultra-competitive world, with people turning to all sorts of methods to make ends meet. Selling coding as a ticket to economic salvation for the masses is dishonest.

Take coding boot camps. Since the mainstream learned the success of SiliconValley software engineers, everyone wants to own a startup or become an engineer. HBO’s Silicon Valley paints a picture of late twenty-somethings spending their nights coding and smoking weed, all whilst making millions of dollars. The American public is amazed by figures like Elon Musk and MarkZuckerberg, who make millions seemingly overnight. Coding fever has even reached the steps of the White House, with President Obama pushing for legislation to include computer science in every public school curriculum.

Inexplicably, it is not just boot camps and politicians encouraging people to learn to code.

Individuals are actively encouraged to do so from all sides of society, fromHollywood to current tech luminaries. Despite this growing buzz, I view boot camps with intense skepticism. While our culture tends to make SiliconValley sexy, and glossy bootcamp brochures promise well-paying jobs, the truth is that many of these institutions are not accredited, do not post job statistics, and do a poor job of ensuring their students’ post-bootcamp success.  While many coding bootcamps are legitimate and care for their pupils, an even greater number are run by modern snake-oil salespeople tapping into the averageAmerican’s desperation.

Don’t get me wrong; I do believe that engineering and programming are important skills.

But only in the right context, and only for the type of person willing to put in the necessary blood, sweat, and tears to succeed. The same could be said of many other skills. I would no more urge everyone to learn to program than I would urge everyone to learn to plumb.

Focusing on coding inflates the importance of finding the “right” method to solve a problem rather than the importance of understanding the problem.

Before we start working on a solution to a coding problem we have to decide what the problem is and if it’s truly a problem. If we let ourselves become fixated on how to solve a problem via code–regardless of if it is a programming problem ornot–and lose sight of why we gain nothing.

I have a close friend who is a former Association for Computing MachineryInternational Collegiate Programming Contest champion from Stanford. Thegreatest thing he taught me about his ACM championship days was the importance of understanding what problem you’re trying to solve.

You must ask yourself, ‘Do you even have one?’ and ‘Can you apply the Feynman principle and explain it in a way that others can understand you?’

This friend told me that even in the elite schools, students read the prompt to the coding problem only once, and then immediately code.

The year my friend won the championship he learned something: even those from elite schools dove headfirst into complicated problems, with code as their onlyweapon.

Meanwhile, my friend wrote his code only after thoroughly understanding the problem. He used almost all of the allotted time to think about the problem. He did not write code until minutes before the deadline.

He became a champion.

Because he knew that banging out code would not solve the problem, but cool, collected problem solving would.

An excessive focus on coding ignores the current plight of existing developers.

Technology changes at a rapid pace in this industry.

Just a few years ago I was using Objective-C, and now I code almost entirely inSwift. There are iOS Developers applying for jobs right now who have neverwritten a line of Objective-C. Swift is easier to learn, safer, uses moderndevelopment paradigms, and is elegant in a way that Objective-C never was. Thefact that new developers will never deal with Objective-C’s deficiencies is to great, but it ignores the reality of the profession.

Developers are expected to learn fast, with little guidance and little moreincentive than the faint rattling of the pink-slip guillotine. One could argue thatthis is simply one of the costs of the trade.

But if current developers are frustrated or falling behind—and there is evidencethat shows this to be the case—then why encourage individuals to enter such anuncertain realm?

What happens to the person who spent night and day studying Objective-C onlyto be horrified by the Swift announcement at WWDC 2014? Do they keep codingin what is quickly becoming the language of lesser choice, or do they start again?If you’re a young twentysomething, this may pose little difficulty, but if you’retaking care of a family–with bills to pay and mouths to feed–the task becomesHerculean.

People in these situations confront all of this without a solid grasp of actualprogramming or engineering.

The line between learning to code and getting paid to program as a profession is not an easy line to cross.


It took me over a year of self-taught study before I got a freelance gig. Even then ,the pay was poor. There were times where I could not afford a place to stay and had to rely on the kindness of friends to keep me going.

There were many nights where I wanted to give up. But I found the strength to keep going.

It was–and is–persistence that allows me to stay in this field. There were countless times I was refused even an interview because I didn’t have a computer science degree.

The truth is, it simply isn’t easy to slide into a development gig, even if it’s an apprenticeship. You need connections, people to vouch for you, a Github account maintained over time and more. Despite advances in equal opportunity ,if you’re an underrepresented minority, you’re going to have to be twice as good as everyone else. And that’s simply to demonstrate competence.

The gatekeepers are anywhere. They are Ivy League graduates who believe asking questions like, ‘How do you invert a binary tree?’ is the best way to gauge someone’s technical ability. They are the whiteboard test-obsessed project managers (confession: I own multiple whiteboards) and the clueless human resource managers who list requirements like, “5 years of Swift ProgrammingLanguage Experience needed” in job postings (hint: Swift release = 2014). These people, for better or for worse, stand between you and a decent job.

As far as I know, there’s no other way to get past these people than to play their game; even if it is unfair.

Final Thoughts

Look. If becoming an engineer is what you want, don’t let me—or anyone for thatmatter—get in the way of your goal. And don’t let traditional confinements like the educational system slow you down. There are no correct or incorrect ways to go about achieving your goals.

But don’t lose sight of reality while being charmed by our culture’s Silicon Valley romance. This field is not a get-out-of-debt-free card. You have to take the time to build your understanding of the field. You have to become comfortable with the fact that you are a problem solver and not simply a “fill in framework here ”developer. You also have to get used to the idea that any moment you might need to learn a new framework or language, and that you will have to fight for a job if you don’t have formalized credentials.

Software engineering is a lucrative field, but the transformation from ‘coder’ to‘engineer’ is challenging.

If you stick to it, you can not only change your life but change your entire way of thinking.

Sign up for my Swift Newsletter! Sign up via this link: 


Name that Tune!


by G. Patrick Bellot

One of the many jobs that we do as developers is naming. Coming up with simple descriptive names can be a daunting task altogether. As a new developer myself, knowing some of the Swift language characteristics is a good place to start.

Classes (class) – Are usually nouns. Apple recommends prefixing our classes with three or more letters to avoid linking to someone else’s code. Using the company name or project initials as a prefix is suggested. The name is capitalized with names written in UpperCamelCase. Meaning the first letter of the string is capital and the first letter of every string following is capitalized. Example: class GWRBAwesomeClass

Constants (let) and variables (var) – usually nouns with names written in lowerCamelCase. Meaning the first letter of the string is lowercase, and the first letter of every string afterward is capitalized. Like camel humps. Example: let thisBlogIsTotallyAwesome = true

Functions (func)– usually verbs written in lowerCamelCase. Pro Tip: functions should only do one thing, very well. Example: func doOneThingWell

Enumerations (enum)– the name is usually a noun written in UpperCamelCase.

Example: enum SomeEnumeration.

Switch– when matching enum values with a switch statement, the switch is usually a noun written in lowerCamelCase. Example: switch awesomeBlogs

Structures (struct)– the name is usually a noun drafted in UpperCamelCase.

Example: struct SomeStructure

Extension (extension)-name is generally a noun drafted in UpperCamelCase.

Example: extension SomeType

Protocol (protocol)– the name can be a noun or a verb written in UpperCamelCase. Frequently used with “able” such as “Hashable” or “Equatable.”  Example: protocol Hashable

Knowing the linguistics of Swift can make naming accessible. Coming up with the simple or creative names, that will help your future self or other developers working on your code, the real challenge.

If you like this blog, please share it. You can see more at or

Keep Coding!


Offer: I’ll Build Your iPhone App Idea for $300

Natashatherobot did an app  experiment like this and seemed delighted by the results. So I figure, while I prepare the next thing I’m building (coughs Metal), why not tackle some fun projects as a way of flexing some Swift muscles?

Email me at kacheflowe at “g” mail . com if you’d like me to build your app idea.

P.S. Some might notice that this is a teensy bit higher than Natasha’s offer ($200). Why did I raise it? Inflation, yo.

Also, rent.

Why Am I Doing This?

Because I enjoy the process of building and shipping apps.

This forces me to learn the ins and outs of Swift 2.2 faster.

Or, to put it in nerdier terms, this is my hyperbolic time chamber training a la Dragon Ball Z. Or my training atop Mount Myōboku (妙木山) a la Naruto.

How it Works

This is almost word-for-word what Natasha wrote as her requirements. I’ve made some of my own edits and additions.

  • First in, first out: The sooner you email me, the sooner you get your app. I’ll have a queuing system set up, so as soon as I’m done with the first app, I’ll move on to the next.
  • Once I’m ready to start working on your app, we’ll have a Skype call and keep in contact via email to clarify the requirements and figure out the business logic. Communication is key and I want to make sure you’re happy with my work, so please be available to answer questions promptly while I’m building your app.
  • Payment: $150 up front, $150 on completion.
  • Code Design: Everything will be written in Swift. I will not write your app in Objective-C.
  • Design: If you have a design ready to go, I’ll implement it. Otherwise I’ll be using the native UI components. You’ll need to provide the app store icon and loading screens.
  • Back-end: If you have an API to use, I’ll use it. I can also use Parse, but you’re responsible for paying for it. I’ll also implement CoreData as necessary. If you need a more heavy back-end API component, you’ll need to build it yourself.
  • You own the code, but I can blog about how specific features were implemented. You can see examples of my blog posts on
  • I have the right to refuse service to anyone for any reason.

One last note: You’re more likely to have success if you don’t ask me to to do something ridiculous (like create a social networking application that’s a combination of Facebook and Instagram — a real thing someone has asked of me).


Let me know if you have any other questions, and I’ll answer them in the comments.

Free Q&A Webinar w/your friendly, neighborhood iOS Engineer/Dork — Sign Up Now

My name is Basel. I’m openly geeky and openly dorky. I love technology, problem-solving, personal development, and know more about the Legend of Zelda video game series than any human should.

I also love Swift and work as an iOS Dev. Lately, I’ve received a slew of messages from people asking me questions about software, the industry, guidance, mentorship, and what have you. Normally I’m able to either message or call these people directly over the phone, but lately, I’ve received more messages than I can keep up with. I’ve also been giving answers that I feel are less than satisfactory. If I’m going to help someone, I like giving them my all.

So I’m writing this post to gauge interest in setting up a Q/A online video seminar. If you’re interested in picking my brain, please send me a message or add me on LinkedIn. If I feel I’ve received enough responses to warrant holding a session I’ll set up a time with those who’ve expressed interest and you’ll have the opportunity to ask me anything you’d like for as long as you’d like. From there I’ll set up a time that seems most fair for the group (I get a lot of messages from devs overseas as well, you see).

So send me a message. Add me on LinkedIn. Send me silly tweets @BaselNotBasil. Leave a comment. Email me at Whichever is most comfortable. And then we’ll get the ball rolling.

I’m excited! I hope people sign-up so I can be of service.


(Oh yeah, did I mention it’s free?)

Swift Dictionary Implementation via infographic

Ankit Agarwal is currently my favorite new Swift blogger out there. The guy showed up out of nowhere and consistently posts amazing stuff. Today is no different. Check out this graphic he created depicting the implementation of a Swift dictionary. So cool.

DEFINITELY check him out. He’s @aciidb0mb3r on Twitter and his blog is



A Deeper Look at the Nature of Optionals in Swift 2.2


Optionals? If they were optional I wouldn’t have to learn about them: Optionals Swift 2.2

Why does Swift have all these cumbersome exclamation points and question marks? What does it all mean? If you’ve happened upon the Swift language even once you’ll immediately notice the use of such symbols all over the code.

What is an optional?

At the granular level is an enum with two cases: ‘Some’ or ‘None.’ Let’s look at the following example:

Note that T is essentially the associated value of the type we’re working with.

Fairly familiar, right? But while the optional shares characteristics of the enum, as noted in the Apple documentation, optionals are a separate type, and not an augmented standard type.

So why are optionals useful? And why do we use them in Swift? The answer lies in their clarity. Ironically, despite using the question mark symbol to represent itself, the optional makes our code quite clear. As described in Apple’s Swift Programming Language text “an optional says,

-> There exists a value, such that it equals ‘x’


-> There does not exist a value”

You use an optional in a case where a value may be absent. This may seem strange at first until you take a moment to think about the greater meaning of Swift, and its philosophy. Swift is an opinionated language, and as we’ve heard in countless WWDC talks before, Swift is a language that focuses—and prides itself—on safety. Optionals decrease complexity and unify representations of “nothingness” in our code.

If you have programmed in the iOS world for a certain length of time and used Swift’s predecessor, Objective-C, you’ll likely recall that the concept of the optional does not exist in C or Objective-C. The closest thing that resembles an optional is Objective-C’s ability to return an object that is nil from a method that in any other circumstance would return an object. In the case where Obj-C returns nil it means that there exists no valid object. This, however, only applies to objects. This does not apply to basic C-types, structs, or even enumerations. In other words, primitives are left out in the cold and their value can return anything.

In those instances Obj-C returns a special value known as NSFound (add link here). While NSfound may mark a variable as valueless, the downside is that it assumes the method caller remembers that there is a special value to test against. Ultimately it adds a layer of unnecessary complexity. And worse, if you don’t remember to manually include a value to test against, you risk your app crashing.

Swift accounts for this complexity via the keyword let. With let you indicate the absence of a value for any type at all without the need for special constants.

This is where the power of the optional then comes into play. Because we can deal with any object. We no longer need to consider for special circumstances—which takes away a layer of complexity. Either the object exists or is nil. No strange third circumstance to account for.

To see this concept in action, create an optional in playgrounds and observe its returned value in the console. If all goes well you’ll see Optional(your value here).

So when would we see this being useful? Think of whenever you might have implemented a separate BOOL to track if a value has actually been set OR if it’s in the default state you set. In this case, Optionals are of obvious help because they can tell you immediately what’s happened to the BOOL.

The optional is further exotified by its use of a concept called “wrapping.” Wrapping is ultimately a structure. Any actual content or value cannot be accessed until its optional is unwrapped.

Why is this so hard to understand?

The usual reason: programmers poor way of describing things.

Once you realize that Optionals are their own distinct type AND that unwrapping them means dealing with their enum based structure, then the process of “wrapping” and “unwrapping” (again, something I’ll cover later), quickly make sense.

Anatomy of a Web App Attack

My friend Jack Leonard is an excellent iOS engineer  based in Ireland. He works for a security firm called Barricade and is a talented technology security strategist. I wanted to take a break from my usual entries and take a look at a sphere we iOS developers rarely think about: security. Jack created this lovely inforgraphic to explain what exactly happens when a website’s security is compromised. For more info on Jack and his work follow him @JackLeonardme and visit his company’s website 


ack Leonard

In 2015 alone it’s estimated that almost one billion personal records were illegally accessed, specifically: Healthcare, Financial, Educational & Employee records. The kind of thing you might think would be stored ever-so securely.  Moreover, in 2015 we witnessed some of the most infamous hacks to date, namely: Ashley MadisonU.S. OPMTalkTalk, Carphone Warehouse.

The stories of these breaches stormed popular culture. In fact the term ‘hack(ing)’ is so pervasive, driven by the media’s love affair with it as a buzzword, you could assume that knowing its meaning was second nature. Yet it remains an ambiguous, mysterious and frightening topic for most.

If there is one thing that you should take away from this Infographic, it is its motif: Without strong initial safeguards in place your system is increasingly defenseless. With each stage passed the probability of remediating the attack and putting a stop to the hacker lessens exponentially. Without an initial barricade there is not much you can do stop that hacker delving further into your system.