Swift Weekly – Issue 07 – The Swift Runtime (Part 5) – Operators

I thought I’d write about operators a bit in this issue. I don’t like to teach how operators work, but rather show you some cool things that we can do with operators. but then again, many websites do that already. you can just search online and find hundreds, if not thousands of blogs/websites that can teach you how to use operators and how to create your own in Swift. so how can i be different and offer something else? well, we will talk about operators in this issue and how to write your own, but, i will also show you how custom operators are compiled by the Swift compiler.

Continue reading this article on GitHub by clicking here.

iOS 8 Swift Programming Cookbook Videos, 50% off, only for 1 week

Hello interwebs,

I was informed today by O’Reilly that my title “iOS 8 Swift Programming Cookbook” videos is 50% off for a week

Here is a direct link to the video including the discount code

If you have no luck with the above link, just go to O’Reilly’s website and purchase the book with the discount code of VDWK


Swift Weekly – Issue 01 – Pointers

I have started working on a new project called Swift Weekly. The reasons behind this decision are plenty. I’ve noticed throughout years of publishing books that the best way to learn is to teach. In my quest to learn Swift better and better every day I have decided that I want to write about it. My son has recently been born so I am very busy at home too which means that I don’t have much time to write. So the weekly nature of Swift Weekly is perfect for me. Also, I believe in giving to the community so that is the third reason.

Swift Weekly issue 01 focuses on the niche subject of pointers in Swift. Swift Weekly is all hosted on GitHub and you can find it here:

Swift Weekly on GitHUb

Have a read through the first issue and see what you think. Ideas and suggestions are welcome. Also spread the word and share this with your Swift lover friends!

Building and Running Python Scripts with Xcode 6.1

Follow these steps:

  1. Open Xcode
  2. Create a new project and select Other from under the OS X category when the dialog appears, and then choose External Build System:

    Screen Shot 2014-10-20 at 20.20.47

    Tap to enlarge

  3. In the next page, give your project a name “product name” and then in the “build tool”, choose the path of your Python interpreter. If you don’t know where your Python interpreter is, open Terminal and type in which python to get the path to the interpreter, like so:

    Tap to enlarge

    Tap to enlarge

  4. Then save your project on disk
  5. From the Product menu, choose Scheme and then Edit Scheme or just Option-click the little Play button on top left of Xcode. Now you should see the Edit Scheme screen which looks like this:

    Tap to enlarge

    Tap to enlarge

  6. Now tap on the Info tab on top of the dialog and then press on the Executable combo-box (which currently says “None”) and then from the list, choose “other…

    Tap to enlarge

    Tap to enlarge

  7. An open-dialog will appear waiting for you to select your build tool, again! This is a bug in Xcode. So press the Cmd+Shift+G button in the open-dialog and when the “Go to the folder” dialog appears, enter the path of your Python interpreter again like so:

    Tap to enlarge

    Tap to enlarge

  8. Once you are done, press the Go button and then press the Choose button
  9. Back in the Edit Scheme dialog, uncheck the “Debug executable option as you don’t want Xcode to attach the LLDB debugger to Python. That’s not useful. This step is very important.

    Tap to enlarge

    Tap to enlarge

  10. Now tap on the Arguments tab and then under the “Arguments Passed on Launch”, press the + (plus) button and then type in “test.py” without the quotation marks, like so:

    Tap to enlarge

    Tap to enlarge

  11. Now tap on the Options tab and then under the “Working directory” section, tap the “Use custom working directory” and then tap on the little Folder button. Once the open-dialog appears, choose the root folder of your Xcode project:

    Tap to enlarge

    Tap to enlarge

  12. Now press the Close button to close the Edit Scheme dialog
  13. Press the Cmd+N combination on keyboard or just select from the menus, File->New->File…
  14. In the New file dialog, from the left hand side, choose OS X and then Other and then choose Empty and then press the Next button:

    Tap to enlarge

    Tap to enlarge

  15. Name your file “test.py” (without the quotation marks) and then ensure that you are saving it under your project’s main folder, the same folder that you set your “Working directory” to a few steps ago. Once you are done, press the Create button.

    Tap to enlarge

    Tap to enlarge

  16. Write a simple Python script in your “test.py” file like so:

    Tap to enlarge

    Tap to enlarge

  17. Now run your application and have a look at the console in Xcode to see your Python script successfully executed:

    Tap to enlarge

    Tap to enlarge

That was it really. Good luck everyone. If you have any questions, just let me know.

Creating string enumerations in Objective-C (The ultimate solution)

A while ago I wrote on my blog about a solution to one of the most common questions asked by Objective-C programmers which is “How can I create string enumerations?”. Well, the solution that I’ve given has immediately become one of the top subjects that attracts developers to my blog, as I can see in my stats. I thought I should now take it to a whole other level and get rid of the limitations that I had presented in the old solution, and come up with a fresh perspective.

The following video is the result of my work on this subject. I hope you’ll enjoy watching it.

Hiding sensitive business logic in Objective-C

So you have some business logic in a class that you want to hide from the users of your class? Let’s say that you are working on a library project and you have to expose the header file of this particular class to your user but once you do that, it’s easier for dubious programmers to find the class name behind your business logic and potential reverse engineer your app.

In Objective-C, we can hide the implementation of our business logic by taking advantage of the Objective-C runtime. Here is our action plan:

  1. We will create our class called Person (the class whose header file is going to be exposed to evil programmers out in the wild!)
  2. We will create another class called PrivatePerson and will include our business logic in there
  3. We will then redirect requests from the Person class to the PrivatePerson class

And obviously we will not export the PrivatePerson’s header files for the programmers, are we crazy? No!

Ok so let’s begin by creating the interface for our Person class like so:

Screen Shot 2014-01-17 at 16.10.09

The properties are fine. But the method named fullName is going to have business logic in it. It will return the current first name and the last name, separated with a space. We don’t want the logic for this method to be inside the Person class so what can we do? We will go first and create the class named PrivatePerson and we will put our business logic for the fullName method in there. Let’s start with the header file. But before we do that, remember that the firstName and lastName properties are in the Person class. So how can the PrivatePerson class that contains the business logic calculate the full name without having those values? Well, we just have to pass those values to PrivatePerson as parameters like so:

Screen Shot 2014-01-17 at 16.25.54

Then we will implement the PrivatePerson class:

Screen Shot 2014-01-17 at 16.26.45


Now what we have to do in our Person class is to implement 2 methods. The first method is methodSignatureForSelector: and this method will be called on our Person class whenever the fullName method is called. Since Person doesn’t implement fullName, the runtime will, in the process of throwing an exception, first find out whether the Person class can handle this message. By implementing the aforementioned method, we get a chance to return a method signature that corresponds to the fullNameFromFirstName:lastName: method in the PrivatePerson class, like so:

Screen Shot 2014-01-17 at 16.31.39


Note: self.privatePerson is a private property of our class. Look at the next screen shot to learn how we implement that property’s getter.


Then we will implement the forwardInvocation: method using which we redirect the call for the fullName method into the fullNameFromFirstName:lastName: method in PrivatePerson class:

Screen Shot 2014-01-17 at 16.33.21


Perfect, in your app delegate for instance, test this out:

Screen Shot 2014-01-17 at 16.34.39


You can see the correct value of “Vandad Nahavandipoor” will be printed out to the screen.

That’s all good and fluffy and warm and nice. But LLVM will be nagging at the incomplete implementation of the fullName method in the Person class since we haven’t implemented it there. Remember? That was our goal! Doh!

Screen Shot 2014-01-17 at 16.37.22

So using the awesome techniques described by the lovely people behind LLVM, we will silent these incomplete-impelemntation warnings in our Person class like so:

Screen Shot 2014-01-17 at 16.39.56


Awesome, problem solved. Happy coding everyone! 🙂