A cup of cocoa to go.

Swift Singleton

Just 24 hours after the announcement of Swift, I was bugging Apple Engineers on how to implement the singleton pattern.  The solution was much simpler than the Objective-c implementation. Let’s take a look at a simple singleton implementation in swift.

let sharedExample = Example()

class Example {
    var number = 0

The very first line of code is the bare minimum you need to have a shared instance of the class. we are using let in order to declare a constant.  The line is outside of the class and thus it is global.  It is being set to Example() but not right off the bat.  Here is the beauty of Swift.  The constant sharedExample will only be set once you call it.  This means that it is lazy loading by default and will not take up memory as soon as you run the code.

Now let’s look at how we would access this shared instance.

sharedExample.number = 5

The above line is essentially the equivalent of the following line in Objective-c

[Example sharedExample].number = 5

So to recap what we have learned so far, we have replaced the following Objective-c implementation with one line of code in Swift.

+ (id)sharedExample {
    static Example *shared = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        shared = [[self alloc] init];
    return shared;

How exactly is this possible you might wonder? It is simple. In Swift, global variables are loaded lazily, thread safe, and allocated only once no matter how many times you call them, which is pretty much the gist of what the singleton pattern is. There are people who will want to stick to the Objective-c conventions and call a method to return a shared instance, that is fine.  This post is the simplest implementation of the singleton pattern in swift. As the goal of swift is to make code shorter, and easier to understand, this is a short and easy to understand implementation of the singleton pattern in Swift.


Edit: I decided it would be a good idea to show another way to implement the singleton pattern in swift.  Consider the following code:

class Example {
    class var sharedInstance : Example {
        struct Singleton {
             static let instance = Example()
        return Singleton.instance

    var number = 0

Above is a great way to implement the singleton pattern but might be a bit confusing to first time swifters or programmers so lets run through it real quick. Essentially what we are doing is wrapping the shared instance or the single living soul in the class itself so the format for grabbing a reference to that one living object would be cleaner.

First we are creating a class variable which is basically something you can access without having to instantiate the class, also called a computed property. Inside of that class variable we have a struct which is wrapping a static constant named instance. The static portion of the statement makes it so this object only exists once, hence the single part of singleton. The let part as stated earlier in the post makes it a constant. Now why is it wrapped in a struct? Well it is basically a trick you can use since you can not have a static in a computed property, but you can in a struct, and you can have a struct in a computed property. To wrap it all up, the computed property is returning the static constant which is in the struct. Like before, it is only allocated once and only when you first call it!

So how exactly do we call it? A little bit different than before but this is where the benefit of using this format comes in.


As you can see, it is tied to the class and is closer to the objective-c way that we showed earlier.

Local Notification Spam!

The notification center of an iPhone 5 running iOS7.  The image shows how local notifications can be used to spam messages to users.

The notification center of an iPhone 5 running iOS7. The image shows how local notifications can be used to spam messages to users.

Local notification spam has been an issue especially in the gaming categories of the app store.  Messages like “Your free spin is ready!”  riddle the devices of casual mobile gamers.  It is a way for mobile game companies to keep their user retention numbers up.  Users using the app longer means more money for developers / companies, this of course comes at the expense of a good user experience via abuse of a seemingly innocent API.

Local Notifications are as powerful as Push Notifications when it comes to grabbing the users attention, it’s about time that they are treated as such.  In iOS8, app developers will now need to ask users for their permission to schedule local notifications just as they would for sending push notifications.  Thats right! No more spam.  Users can now download games from the app store without the fear of being molested by the unsolicited notifications popping up on their phone, sometimes late at night.

This of course will impact the user base of many applications which are using the local notification reminder trick to keep their users coming back to their app.  There should be no impact on developers who were not abusing this system to keep their user retention high.  It would be interesting to see the advertising revenue graphs of some big name apps as I am sure they will be impacted by this seemingly small change in the framework.

The Mailbox Rollout

Mailbox was released to the iOS app store on Feb 7, 2013.  Many flocked to download the app, including myself, but very few were allowed to use it on that very day, or the next day, or even the day after that.  In fact, as of this post, I am still waiting in the Mailbox reservation queue so I can actually use the application.  I am currently in the 27,828th spot.  There are about 782 THOUSAND people behind me.  They are all just sitting there, waiting to use the app.  The icon sitting on their home screen, mocking them, taunting them to open it and catch a glimpse of how slowly through the line they have moved.

So what has gone wrong here?  How did such a promising app become a useless icon on a home screen for the majority of users right out of the gate?  The answer to that question is very simple.  Having hundreds of thousands of users log onto your servers within a 24 hour period, let’s just say that such surges would have probably caused the mailbox servers to become unresponsive.  It seems as though Mailbox had no choice but to turn their app into a long reservation queue.

What could then be done to keep so many users at bay without incurring the many one star reviews that Mailbox has received? While this may seem like a complicated answer, it is quite simple.  Apple, and other app stores such as Android need to offer developers the offer of doing a slow rollout for their application.  How exactly would this work?  I imagine it working one of two ways.

The first way would display the application in said app store with a “get in line” button.  Users would see the application and have the choice of getting in line to be able to download the application or check back later when the initial rush to get the application has dissolved and all that remains is a download button.  Using this method, users would have the expectation of waiting, while allowing them to just download the application would give them the expectation that it is already functional, thus incurring app deletions and one star reviews from many users who are upset about not being able to use the application.

The second option for a slow rollout would be to just not display the application in the app store depending on user location.  Slowly display the application to more and more users dependent on their current location as server resources are freed up.  Open it up on a city by city, state by state, or country by country basis depending on the restrictions of the application servers.

These two methods of slowly rolling out an application would be much better than that rollout that Mailbox chose but requires the collaboration of app stores with their developers.  As for the Mailbox app itself, I have yet to use it but have heard great reviews and am continuing to wait in line.

Are web apps really the future?

To start off this post, let me just say that the following text may be written with slight bias.  I chose a profession in native mobile development because I believed that it would be a good investment in time and knowledge.  Now that we have that out of the way, let’s continue to what I think the future of web, mobile, and software development as a whole will be.

In order to look into the future of software development and web, we have to look into the past.  Web originated as a means to share information among machines around the world.  It quickly evolved from a means of accessing information on other machines around the world to the art of displaying that information in an elegant way.  Software on the other hand was a way to process, create, and manipulate information.  Of course by default, most software must also focus on displaying this information for user consumption.

Next we will speak about the introduction of native mobile application development to this scene of web and computer software (Lets not forget that mobile apps are essentially computer software).  Native web applications have been around for a long time, about as long as cell phones with displays have been around.  I was very young during these times but who can forget the snake game that was running on their Nokia?  I was one of the lucky people that was able to own more advanced phones such as the Nokia n95 and Nokia n9500.  These phones were very powerful for their days and as a result, contained some more useful mobile applications above just a snake game.

As these three areas of technology were in coexistence, they quickly started to evolve and blur the boundaries between themselves.  Computer software started to become more focused on the use of the web as a form of storage and backup.  Web started to take on bigger roles such as information processing and manipulation on top of its information storage and display.  And mobile … well mobile was like the bridging sidekick for computer software and web.  mobile was there to make lighter versions of the software that you have on your computer, while at the same time creating an easier way to digest information from the web.  All of this while still adding its own “touch” to the equation.

So where is mobile now and where is it going?  As we all know, mobile phones and tablets are getting more and more powerful by the day.  This explosion and quick advancement in mobile technology is quickly blurring the lines between a computer, a laptop, a tablet, and a mobile phone.  To someone in the world of native mobile app development and computer software development, as myself, it is obvious that the world of mobile software development and computer software development are hurdling toward each other at a great speed.  It is very clear to me that in five to ten years, there will no longer be a difference between your mobile phone, your tablet, and your computer.  The device that you carry in your hand will take the form of all of these devices that you carry around with you today.  There will not be a world of computer software development and mobile software development as separate as they are today.

So where does this leave web apps?  Well this leaves web apps in the place where they have been and where they are today.  While web apps have been getting more advanced and will continue to become more advanced.  They can not replace the software that runs on mobile devices and computers that are around today, nor will they replace the software in that all in one device that you carry around with you in the soon to be future.  There is no reason for this to occur.  There is no void in computer software that web applications can fill and thus there is no use in trying to fill an already full cup.  Computer software in the future will just become more and more absorbent of all of the information stored online.

I will finish this article with a small note.  Some might have the misconception that native mobile apps are following in the footsteps of flash in the form that they are trying to fill a void which most web technologies are not able to fill.  This is not true.  Native mobile apps are bridging the gap between the powerful computers of today and the less powerful mobile devices that we own.  There is no web void being filled by native mobile apps and thus there is no point in using a technology which is limited to substitute a technology which is not.