Episode 94 – Objective-C for Swift Developers

This week we discuss the rumoured OLED display bar for the MacBook Pro line. We follow up on Mekorama, Mekorama Forum and Twitterrific’s Tip Jar. We discuss Apple Pay initial role out in Canada. We cover the Swift 3.0 Preview for developers. We discuss naming classes in code as well as delegates vs observers. Picks: MTJC T-Shirts Update, NSCache, Jazzy and Hyperdev

Tim’s conversation with Martin Magni
> How did you build it? Unity?

I wrote it from scratch in C and used the (open source) Bullet Physics library.
> Did you do all the work, art, music?
Yes. I’m a bit of a jack of all trades 😉
> What made you decide on pay what you want?
I wanted to try IAPs. But locking features down would hurt the game. Especially given its create and share functionality, which benefits from having many users contribute content. PWYW “solves” these issues and seems relatively untried in the app stores.
> We talk about devs charging decent money for their work. How has the IAP performed. Not to be to specific. Are you happy with the result?
I charge exactly what the app is worth to you, couldn’t get more decent than that.
Are people paying? Some. (Thank you!) Am I making minimum wage? No. Will I survive? Yes, I’m extremely frugal.
> What cause the app to tip? Was it marketing, interviews, luck?
Would it be presumptuous of me to suggest that the quality of the game played a role? Making it free helped too.
> How long did it take? Were you working on it exclusively?
I’m a full time indie dev. I worked exclusively on the game for almost a year and a half.
> How are your other apps doing, do you have any?
My first game (in my current solo constellation) was 2015’s Odd Bot Out. It’s pay to play and has done better than Mekorama (so far).

Episode 94 Show Notes

Episode 94 Picks

8 thoughts on “Episode 94 – Objective-C for Swift Developers

  1. Jessy Catterwaul

    Good show!

    On the topic of Delegates vs. Observers, Have any of you used C#’s events, or a similar one-to-many solution? It’s still Swift’s biggest missing feature, in my opinion, but I’ve worked around it with a what I’m calling “MultiClosures”, which are used like C#’s multicast delegates.

    Judging by the upvotes, it seems like a lot of people want this. (Check out my two links there for the MultiClosure code.) http://stackoverflow.com/questions/24111984/how-do-you-test-functions-and-closures-for-equality

    I still use delegates when I know that there is a clear 1-to-1 relationship, and I use static methods when I need to order execution of listening methods, but otherwise, mutliclosures are a good solution.


  2. third_beach

    FU for Aaron’s comment about a Objective-C for Swift Developers book. There is such a book, and it is called Objective-C for Swift Developers by Paul Hudson, which you can find at https://gumroad.com/l/objcswift I can also recommend this book as a great resource to use (it is only a day of reading and will help you get the basics down quickly).

    And why would someone want to read this book? Well even if you don’t ever have to program in Objective-C you could end in the position I did where you had to work with an API, and documentation, and sample code, that was all Obj-C. Or even just trying to find a solution to a problem you have online. There have been a few cases where I have looked for an answer and Stack Overflow has had a solution in Obj-C but not Swift because it is something obscure. In those instances knowing just a bit of Obj-C (or even learning more on the fly) can be a life saver.

    1. timmitra Post author

      Thanks. I thought I saw that book in my Twitter feed. I just could find the link for the realtime update.

  3. dannbeau

    Hi Folks,
    Great show!

    On the discussion of managers and singletons; Someone brought up the point that singletons were bad for TDD;
    One alternative is to revert your singleton back to allowing allow multiple instances; but in your application have a singleton that manages the ONE instance of this object and treat this object as a Single-Managed instance rather than a singleton.

    In this way your tests can work with multiple different instances of the object (in isolation); while in your application you have a manager (singleton) that holds on the one instance of this object. The API to the singleton is minimal and it only gives you access to the signle instance of your ‘manager’ object. You may also be able to switch out the instance in runtime too if you want to support changing instances like in your account switch example.

    One other comment I have on the topic of singletons, this was not brought up on the discussion of the cons of using singletons, but what about thread-safety? If you are using background threads in your applications and your singleton is managing some state (globally) should there be some concern on the safety of accessing the singletons state from multiple threads?

    1. Mark Rubin

      Thanks for the suggestion!

      You are absolutely right that thread-safety is critical when working with singletons (we should have mentioned this in the show). Fortunately Apple provides a very simple way of handling this, using dispatch queues in GCD (Grand Central Dispatch). When using GCD, you never have to deal with background threads directly; instead you pass your code into a GCD dispatch method (there are several types, depending on what you want to do) and iOS takes care of the threading on its own.

      To set up a singleton using GCD, you use a standard pattern. Create a subclass of NSObject called Singleton (or whatever you want to call it).

      In Singleton.h, declare a class method:

      + (instancetype)sharedObject;

      Then in Singleton.m, implement it like this:

      + (instancetype)sharedObject {
           static dispatch_once_t onceToken;
           static Singleton *sharedSingleton = nil;
           dispatch_once(&onceToken, ^{
               sharedSingleton = [[Singleton alloc] init];
           return sharedSingleton;

      “dispatch_once” is a GCD function that does exactly what it sounds like – it will execute the code passed to it exactly once, no matter how many times it is called, or what thread it is called on. “onceToken” is a variable of type dispatch_once_t, and is used by iOS to tell whether or not the code has been executed yet.

      When sharedObject is called the first time, it executes the code inside the block passed into dispatch_once. This code creates an instance of Singleton, and assigns it to the sharedSingleton variable. Then the method returns sharedSingleton.

      sharedSingleton is declared as a static variable, which means its value persists and doesn’t change each time you call the sharedObject method. So whenever the method is called after the first time, the dispatch_once function will not execute, and the method just returns the value of sharedSingleton every time. That is, it always returns the same Singleton object.

      Because sharedSingleton is a local variable which only has scope inside of the sharedObject method, it cannot be changed outside of this method. And inside the method it can’t change either, because of the dispatch_once function. So in the rest of the app, any time you call [Singleton sharedObject] you are guaranteed to get back the same object, no matter what thread you are on.

      1. dannbeau

        Thanks Mark for the reply…
        The case I was most concerned about was if the Singleton maintains a state in it. This is where there is some concern.

        So if on the main queue, you are accessing [[Singleton sharedObject] state] but in the background queue be it Network Operations or otherwise, [[Singleton sharedObject] setState:newState];

        The access to the Singleton’s state is not safe… depending on the complexity of the state being managed by your Singleton, you may have to use atomic access (or @syncronized) but I have also explored using GCD to serialize access to the managed state; This latter approach is recommended by Apple as well but it feels like overkill in some scenarios.

        I don’t have a good feel on the best approach for this in iOS, for a few properties atomic would work. For a more complex singleton (e.g. CacheManager) the GDC approach may work better.


        1. Mark Rubin

          Ah, I see what you mean now. Yes, you’re right, objects owned by the singleton aren’t necessarily thread safe even if the singleton itself is. In general, for exactly this reason, I think that keeping complicated state info in a singleton is probably not a good idea… I tend to only store states of things external to the app in singletons, for example authentication status, which can be represented by a BOOL or other atomic property. These properties are then managed internally by the singleton itself and are “read only” to the rest of the app (or at least only writeable under controlled circumstances). If I do need to modify a non-atomic object owned by the singleton, I’ll usually do the work on a copy, then, in a dispatch to the main queue, point the property for the real object to the copy. That way, access to the new / updated data is prevented until it is ready (for remote synching of core data objects, private queue concurrency using a context that is a child of the main context does essentially the same thing). Sounds like you’ve explored some similar concepts.


          1. dannbeau

            Thanks Mark, that last point on working on the copy is a good idea. Sounds similar but has less complexity in the Singleton than the GCD serialization approach I mentioned. I will give this a try! Thanks again for the extended discussion much appreciated!

Leave a Reply

Your email address will not be published. Required fields are marked *