WWDC is the event of the year for the Apple developer community. The year I had the privilege to be there (it was my first time at a WWDC). WWDC17 was different than previous years as the conference moved back to San Jose after a 15 years run at Moscone West in San Fransisco. San Jose is not a new city for WWDC. The conference took place in McEnery Center from 1988 to 2002 (WWDC 2002 was the year that Steve Jobs announced the “death” of MacOS 9).

I arrived in San Jose on Saturday which is a must if you are travelling from a country with a very different timezone (I got there from Greece which is ten hours ahead of California) in order to have some time to fight jet lag and get ready for the long week ahead.

Sunday

Sunday is the day for badge pickup. You can pick up your badge on Monday before the keynote, but Sunday is the day to do so, as Monday is going to be a really busy day. Registration and badge pickup opened at 9am. I went in line at 8am and there were already around 50 people before me. Once the registration opens though, the line moves pretty fast. At registration you get a badge which you should not lose because they do not reissue it and a wristband which you have to wear for the whole week alongside the badge. After the badge pickup, I got in line for the swag, which included the famous WWDC jacket and, for the first time this year, some pins, including a country flag pin. After a while the line for the swag got bigger as anyone wanted to try out the jacket before leaving. Breakfast and lunch were offered on Sunday too despite the conference official kick-off was set for Monday.

After Apple we visited the Google campus (Googleplex) in Mountain View, which is open for public. You cannot enter the buildings without knowing a Google employee that can get you a guest pass, but you can freely walk around the campus. Final stop was The Stanford University which needs no introduction and is in the to-do list of everyone that visits Silicon Valley. The campus is huge and its architecture and history are mind blowing and one of a kind.

Monday

Monday is the big day. Keynote starts at 10am. Everyone’s question is what time should you get to the line in order to get a good seat for the keynote. The good thing is that this year at McEnery there was a large enough hall to accommodate everyone for the keynote, so all attendees got a seat and watched the keynote live. I went in line around 7am and I got a pretty good seat on the right side. The waiting in the line is also a great opportunity for socializing and excitement and anticipation is all over the place. The Apple stuff is super friendly and once again, when the doors open around 9:30am the line moves fast.

After the keynote there is the Platforms State of the Union session which is kind of a keynote for developers and is the must-attend session of the week for everyone developing for Apple platforms. Developers -including me- were super excited with the new features in Xcode 9 (hello Swift refactoring) and the CoreML and ARKit frameworks. Later on Monday there was a hands on session for developers for all the new products Apple announced. Of course everyone was in front of the new iMac Pro and the new HomePod. HomePod looks much better in person than in the videos.

I got a chance to try VR on the Mac using the HTC kit and the result was fully realistic and impressive but I used it for just a few seconds, so I do not have a clear opinion about it. Judging by the community reaction though, Apple is off to a good start with VR and AI.

Session & labs

The whole week after Monday is packed with sessions and labs. There are multiple concurrent sessions so plan accordingly. The WWDC app is a nice and convenient way to do that. All sessions are available online after a day or two so if two sessions that you want to attend are on the same time, just attend one and watch the other online. Labs are in my opinion the biggest privilege of being at WWDC. You get the chance to talk to Apple engineers, show them your code and get advice and guidance. It is simply amazing that you can actually talk to the people that have built the frameworks you are using and help you with any issue you have. I visited many labs about App Store, iTunes Connect, Swift and Xcode and in almost every single one of them I got my issues solved or got valuable advices. Even when my issue could not be solved right away, the Apple engineer sent me a follow-up email after a couple of days. Keep in mind that many labs are by appointment. Reservations for each day open at 7am in the morning online on the Apple developer website. So if you want to reserve a lab appointment, act fast because some labs like the UI/UX or the App Store lab have their time slots filled within minutes. If a lab is at the same time with a session you are interested to attend, just go to the lab and watch the session after through the Apple website.

Events & Bash

During the week there are multiple events and parties that take place in town. All of them this year moved from San Fransisco to San Jose. These events are a great place to meet other developers, share knowledge and socialize. Firebase party, Beard Bash by Jim Dalrymple and John Gruber’s Talk Show were some of the events that stood out this year. There also other conferences running in parallel with WWDC for those who didn’t get a ticket or for attendees that want to spend some time there too like Alt Conf and Cocoa Conf.

Apple holds its own party on Thursday night. The Bash this year took place at a park near McEnery. There was a live act, food from around the world, games and of course beer for everyone over 21 years old.

Tips for first timers

1. You do not need your laptop on Monday. Just an iPad or a notebook (a physical one) for keeping notes during the State of the Union is ok.
2. San Jose weather is much warmer than San Fransisco but during the night it gets cold so bring the appropriate clothes.
3. The week is long and exhausting so if you travel from far away it is better to get there on Saturday so you have the day prior to the conference free to accommodate yourself.
4. Visit labs. Bring your code and visit the labs to get help and advice from Apple Engineers.
5. Do not miss State of the Union. It is like the keynote in terms of vibes and applauses but specifically for developers and 100% techy and code oriented.
6. If you have a long-haul return flight, download sessions and watch them during the flight.

The feeling I got during this week can be best described using a quote that was written on a wall decoration during the conference:

A place where technology meets the liberal arts and the humanities to create new ideas that push us all forward. Where the moments you’ve lived, the songs you’ve heard, and all that inspires you find their application. This is where people unleash technology’s full potential. And vice versa. This is WWDC.

Attending WWDC was a massive experience. It is an exhausting week but it totally pays off. Talking to Apple Engineers about your code, getting advice and meeting all those talented developers from all over the world is a lifetime experience.

This year’s WWDC was full of surprises for developers. Apple chose the path of opening so many aspects of iOS to developers, which is something that we could not even think of some years ago. Users download more and more apps and spend more and more time on their smartphones. Apple aims to help this by eliminating the number of times users have to open apps and find what they want.

First and most visible change is the revamped lock screen. iPhone 6S and 6S Plus have so fast fingerprint sensors, that it became almost impossible to read notifications in the lock screen by pressing the home button before the screen unlocks. The only way to read notifications on a 6S on the lock screen is to use the sleep/wake button instead. In iOS 10, lock screen lights up when you raise your iPhone and notifications are presented in a much cleaner way and without dimming the background. Notifications are rich and even the widgets are right there in the lock screen. From a developer’s perspective, notifications now support rich user interfaces like seen in the image below. This means that for a third time in a row we have to change the way we register for notifications and how we handle them but this time for good. Notifications now support images too (something that was only available for bundled apps till now, for example the Messages.app) and all the APIs you would expect are there (for fetching images before triggering the notification for adding actions, etc).

Next big feature in the SDK is SiriKit. Apple is finally making Siri available to iOS developers (Siri got its way to macOS too but without a SDK for developers). Watching the WWDC sessions on SiriKit, it seems pretty straightforward to implement and the final implementation is just what the user’s expect when they interact with Siri and the built-in apps. There are APIs for registering vocabulary (localized), creating your intent UI, handle user’s input and even mark user’s input as details missing, so Siri can ask for more information. Creating a UI for Siri has some restrictions: UI cannot be interactive, for example you cannot add a map that users pinch or pan. Something that was not mentioned during the keynote is that that intent UI can be used also in the new Map extensions, which means that if you developer for Siri, you get the map extension for free.

Map extensions is the next big thing in this year’s WWDC. Apple has opened up the full power of MapKit to developers. If your app is a ride booking app or a table reservation app you can now fully integrate it with the Maps.app and let your users book a ride or table right from there. Note that this is not a deep link to your application, it is like your app running within the maps with full UI and user actions.

Next in the list are Messages and iMessage. In a few words Apple turned iMessages to a real equivalent of Facebook Messenger. Emojis are everywhere, links load directly within messages and a bunch of other cheesy effects are there. Apple got it one step further and Messages now let you replace all the suitable words within a message with their corresponding emoji. Developers can now create apps for iMessage. There can be two kind of apps for iMessage. Sticker apps that require no code from the developer, you just have to create a sticker app in Xcode 8, drag your images in the appropriate asset catalog, build, archive and submit, and apps that add functionality to messages which can range from games to collaborative apps.

Developer tools got also a lot of attention this years. I’ve been playing with Xcode 8 beta 1 since the day it came out, and I can definitely say that is much faster and smoother than Xcode 7, especially if you mix and match Swift and Objective-C code in your project. Indexing does not take a year to end and .xibs and large storyboards load much faster.

Swift 3 comes with a ton of changes that are source breaking. Xcode provides a migration assistant but it gets some time to get used to the new syntax and naming. Xcode 8 bundles also Swift 2.3 so you can build against the latest SDK and use all of the cool features of iOS 10, watchOS 3 and tvOS and move to Swift 3.0 when you are ready. A nice article on the source code changes in Swift 3.0 can be found here.

Small things that did not get much attention during WWDC are the new NSGridView on macOS which is like an enhanced StackView component and that Apple in iOS 10 marked all the iCloud core data sync methods as deprecated. Textfields also got smarter and now the predictive keyboard can also suggest all kind of data beside words, like addresses, phone numbers, emojis and urls. Last but not least code signing got much easier in Xcode 8 and this time it seems to work as advertised. Actually you do not even have to mess with certificates and provisioning if you do not want to. Xcode manages all the code signing process as expected.

Array is one of the most used collection types in Swift. Although it is extremely powerful (and the language provides much faster array iterations compared to Objective-C) it lacks many of the capabilities we were used to when working with NSArray and NSMutableArray collection types.

On easy workaround for the developer in order to deal with the missing functionality is to just cast Swift arrays to NSArray or its mutable counterpart. Another -more sophisticated- solution is to add this functionality to Swift Array, using Extensions. Extensions in Swift are what Categories are in Objective-C, an easy way to extend an existing object type with additional functionality.

Swift 2.0 added the capability to find an index of an item within an Array but it didn’t added a method to remove an object without knowing its index. Adding this is easy with an Array Extension:

import Foundation

extension Array where Element: Equatable {
    mutating func removeObject(object: Element) {
        guard let index = self.indexOf(object) else { return }
        self.removeAtIndex(index)
    }
    
    mutating func removeObjects(array: [Element]) {
        for object in array {
            self.removeObject(object)
        }
    }
}

Note that we are using mutating func here, because these functions change the value of our object. The first method finds the index of an object and removes it, while the second one does the same for multiple object.

Let’s say we need a sample method that returns a random object of our Array:

func sample() -> Element {
    let randomIndex = Int(rand()) % count
    return self[randomIndex]
}

Nothing tricky here. Let’s see a more complex example. Let’s assume that we need to shuffle our Array. We will add to methods for shuffling. One that shuffles the Array and one that returns a copy of our Array with the objects shuffled. The method that shuffles the existing Array needs to be a mutating func, while the method that returns a new Array doesn’t

mutating func shuffle() {
     if count < 2 { return }
     for index in 0..<count - 1 {
     let newIndex = Int(arc4random_uniform(UInt32(count - index))) + index
           guard index != newIndex else { continue }
           swap(&self[index], &self[newIndex])
     }
 }
    
func shuffled() -> [Element] {
      var list = self
      for index in 0..<list.count {
          let newIndex = Int(arc4random_uniform(UInt32(list.count-index))) + index
       if index != newIndex {
          swap(&list[index], &list[newIndex])
       }
      }
      return list
}

You can download a sample project with the extension here. Feel free to use it in your project or add extra functionality to it. Just the extension is also available in this Gist.

Following last year’s post about my expectations for WWDC14, this year I am going to write a similar article about what I would like to see from Apple in WWDC15. Last year’s conference was a great one for Apple Dev community. We saw many great frameworks like CloudKit, HomeKit, HealthKit, extensions and an entirely new programming language, Swift.

It is difficult even for Apple to keep up with a second straight year with such many new things for developers. Regarding OS X, I expect the next version of the Mac operating system to be what Snow Leopard was for Leopard back in 2009. A release that focuses on performance, stability and new technologies under the hood. There will be some design tweaks in the OS but I do not expect nothing special in the design area. Last year Apple redesigned the entire OS, so this year we can only expect polishing and some new touches exactly like with iOS 8.

Next big thing in WWDC15 will be iOS 9. Note that this is the first WWDC after the release of WatchKit, so I expect a lot of sessions dedicated to developing apps for the Apple Watch. I expect many improvements to the WatchKit SDK and I would love to see an SDK for native apps for the Apple Watch, but it is unlikely to be introduced this year due to the limitation of the Watch hardware (cpu power, internal storage). Access to the Watch sensors a feature that many developers would love to see. According to rumors iOS 9 will bundle few new features and the main focus area in this release will be stability and security. I totally agree with this direction. iOS needs to be refined in terms of stability. Although I do not expect to see many exciting new end user features, I expect to see new APIs especially in HomeKit and CloudKit. I would love to see an Apple TV SDK too but as with Apple Watch, the current Apple TV model has hardware limitations (internal storage), so if we see a SDK for Apple’s set top box, a new Apple TV model will be introduced too (Apple dropped the current model price in March, so a new model is very likely for introduction at WWDC).

Last but not least are the dev tools. Xcode used to be a really stable IDE a few years ago. That is far from reality after the release of Xcode 6. I’ve been using Xcode 6 from day one for large projects that include both Objective-C and Swift classes and the experience is awful. SourceKit crashes are very common (the latest version Xcode 6.3 seems to be a little better) and some times the only way to fix the lack of code highlighting is to manually delete the Derived Data folder. Even when code highlighting works, code completion is extremely slow in Swift. I totally expect Apple to refine Xcode and focus on its stability. The Swift debugger needs to be refined too and provide more accurate and useful information.

In terms of services Apple will probably (all rumors mention that) a music service similar to Spotify. If the pricing is aggressive and given the fact it will come built in with every new iPhone, it will be a huge hit. Spotify is ready to release an SDK for developers. Apple may preparing a similar surprise for its devs too…

Open Xcode and create a single view project with Swift as its default language. Leave the use Core Data checkbox unchecked. Click File>New>Target and select WatchKit app as shown in the image below.

After clicking next you will see a bunch of files added to your project as well as two new targets, a WatchKit extension and a WatchKit app. In order to preserve the Watch battery we will perform the network fetching on the iPhone and then pass the data to the WatchKit App. Apple provides delegate methods for such needs. Open Appdelegate.swift file and add the following code:

  func application(application: UIApplication!, handleWatchKitExtensionRequest userInfo: [NSObject : AnyObject]!, reply: (([NSObject : AnyObject]!) -> Void)!) {
        
        if let request = userInfo["request"] as? String {
            if request == "refreshData" {
                var parser = XMLParser()
                parser.startParsing(NSURL(string: "http://www.ds.unipi.gr/category/announcements/feed/")!, completionClosure: {(articles, error) in
                    if error == nil {
                        reply(["articleData": NSKeyedArchiver.archivedDataWithRootObject(articles!)])
                        return
                    }
                })
            }
        }
    }

This method gets a userInfo Dictionary as input (there we can the WatchKit app asks from the iPhone app) and returns also a Dictionary. Here we have defined that we are asking for refreshData and we use a simple XML Parser (the code for the parser is available on Github alongside with the WatchKit demo used for this tutorial). After parsing the XML we need to archive the array as NSData so it can “travel” back to the Watch.

Now open the Interface.storyboard within the WatchKit app group in your project. Drag a table on your Interface Controller scene. Click the “Group” section in the Table Row Controller section and drag two Labels on the Table Row. Click the Group again and change the layout from horizontal to vertical and size to Size to Fit Content as shown in the screenshot below. Change the firs label font (the top one) to Heading.

Now add a new file in your WatchKit extension group and name it ArticleRow. Add the following code (yes, rows in WatchKit are just NSObjects)

class ArticleRow: NSObject {
    @IBOutlet weak var titleLabel: WKInterfaceLabel!
    @IBOutlet weak var detailLabel: WKInterfaceLabel!
}

Connect the IBOutlets to the row controller in the storyboard. Open  InterfaceController.swift file and drag also an Outlet Connection for the Table.

Add the following code in Interface Controller file:

var articles = [Article]()
override func awakeWithContext(context: AnyObject?) {
        super.awakeWithContext(context)
        WKInterfaceController.openParentApplication(["request": "refreshData"], reply: { (replyInfo, error) -> Void in
            if let articleData = replyInfo["articleData"] as? NSData {
                if let articles = NSKeyedUnarchiver.unarchiveObjectWithData(articleData) as? [Article] {
                    self.articles = articles
                    self.reloadTable()
                }
            }
        })
    }

override func willActivate() {
        // This method is called when watch view controller is about to be visible to user
        super.willActivate()
    }

override func didDeactivate() {
        // This method is called when watch view controller is no longer visible
        super.didDeactivate()
    }

func reloadTable() {
        newsTable.setNumberOfRows(articles.count, withRowType: "ArticleRow")
        
        for (index, article) in enumerate(articles) {
            if let row = newsTable.rowControllerAtIndex(index) as? ArticleRow {
                var currentTitle: String! = article.postTitle
                let finalTitleArray = currentTitle.componentsSeparatedByString("–")
                
                var finalTitle: String = finalTitleArray[1].stringByTrimmingCharactersInSet(NSCharacterSet.whitespaceCharacterSet())
                row.titleLabel.setText(finalTitle)
                row.detailLabel.setText(article.postDescription)
            }
        }
    }

In the awakeWithContext method, we call the parent app (our iOS app) for the data we need in order to fill the table. After getting the data we call reloadTable() (no there are no table view like delegate methods here). Note that we set text to Watchkit labels using the setText method and not dot syntax like in iOS apps. Go back to the storyboard, select the Interface Controller scene and set the class to ArticleRow in the identity inspector of the Table Row Controller and the identifier as ArticleRow in the attributes inspector.

Finally we need a detail view for our articles (the article class for the parsed objects is also included in the full tutorial code on Github).  Drag a new interface controller on the Interface.storyboard in the WatchKit group and add a push segue from the ArticleRow controller to the new controller.

Drag a table on the new interface controller, add label on the row and create two new files in the WatchKit extension folder: one named ArticleDetailInterfaceController and called ArticleDetailRow. Set the same settings for the group layout and size for this controller. For the label set the number of lines to 0. Set the table row controller class and the identifier to “ArticleDetailsRow”. Add the following code to each of the newly created files.

import WatchKit
import Foundation

class ArticleDetailInterfaceController: WKInterfaceController {
    var article: Article!
    
    @IBOutlet weak var articleDetailTable: WKInterfaceTable!
    
    override func awakeWithContext(context: AnyObject?) {
        super.awakeWithContext(context)
        
        if let article = context as? Article {
            self.article = article
            self.reloadTable()
        }
    }
    
    //MARK: Table loading
    func reloadTable() {
        articleDetailTable.setNumberOfRows(1, withRowType: "ArticleDetailsRow")
        
        if let row = articleDetailTable.rowControllerAtIndex(0) as? ArticleDetailRow {
            var articleDescription: String! = article.postDescription
            row.textLabel.setText(articleDescription)
        }
    }
}

import WatchKit

class ArticleDetailRow: NSObject {
    @IBOutlet weak var textLabel: WKInterfaceLabel!
}

Connect the IBOutlets for the table and the row to the storyboard. After all the connections are in place select the segue and add “articleDetails” as identifier in the Attributes Inspector tab. Open InterfaceController.swift file and paste the following code in order to trigger the segue when a cell is tapped.

override func contextForSegueWithIdentifier(segueIdentifier: String,
        inTable table: WKInterfaceTable, rowIndex: Int) -> AnyObject? {
            if segueIdentifier == "articleDetails" {
                let article = articles[rowIndex]
                return article
            }
            
            return nil
    }

Click and run the app. In order to see the WatchKit app, select the WatchKit app from the schemes and when the iOS Simulator launches, click Window>Displays and select one of the available WatchKit displays. The full code for this project can be found on Github.

One of the most popular posts in my blog is the tutorial for creating a Pop-up window with iOS SDK using Objective-C. Since then many readers reached me out asking for a Swift version of the Pop-up. In general the process is exactly the same in Swift (except the language used to write the code of course…), so I am not going to dive into the process of creating the .xib files again. For this you can always refer to the original post.

The Pop-up controller is a subclass of UIViewController with a couple of methods for the fade in and fade out animations.

 override func viewDidLoad() {
        super.viewDidLoad()
        self.view.backgroundColor = UIColor.blackColor().colorWithAlphaComponent(0.6)
        self.popUpView.layer.cornerRadius = 5
        self.popUpView.layer.shadowOpacity = 0.8
        self.popUpView.layer.shadowOffset = CGSizeMake(0.0, 0.0)
    }
    
    func showInView(aView: UIView!, withImage image : UIImage!, withMessage message: String!, animated: Bool)
    {
        aView.addSubview(self.view)
        logoImg!.image = image
        messageLabel!.text = message
        if animated
        {
            self.showAnimate()
        }
    }
    
    func showAnimate()
    {
        self.view.transform = CGAffineTransformMakeScale(1.3, 1.3)
        self.view.alpha = 0.0;
        UIView.animateWithDuration(0.25, animations: {
            self.view.alpha = 1.0
            self.view.transform = CGAffineTransformMakeScale(1.0, 1.0)
        });
    }
    
    func removeAnimate()
    {
        UIView.animateWithDuration(0.25, animations: {
            self.view.transform = CGAffineTransformMakeScale(1.3, 1.3)
            self.view.alpha = 0.0;
            }, completion:{(finished : Bool)  in
                if (finished)
                {
                    self.view.removeFromSuperview()
                }
        });
    }
    
    @IBAction func closePopup(sender: AnyObject) {
        self.removeAnimate()
    }

In the viewDidLoad method, I styled the PopUp with rounded corners. You can customize that for square corners or other shadow styles. Note that in Swift we have to implement also the required init(coder aDecoder: NSCoder) and as we’ve created the UI in interface builder using .XIBs the override init(nibName nibNameOrNil: String!, bundle nibBundleOrNil: NSBundle!) method has to be added too. Add these two methods and we are almost done:

required init(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)
    }
    
    override init(nibName nibNameOrNil: String!, bundle nibBundleOrNil: NSBundle!) {
        super.init(nibName: nibNameOrNil, bundle: nibBundleOrNil)
    }

Now that the PopUp is implemented, we have to call it from the view where we want to display it.

self.popViewController = PopUpViewControllerSwift(nibName: "PopUpViewController", bundle: nil)
self.popViewController.title = "This is a popup view"
self.popViewController.showInView(self.view, withImage: UIImage(named: "typpzDemo"), withMessage: "You just triggered a great popup window", animated: true)

A fully working example alongside with the Objective-C and Swift code for the PopUp is available on Github. Feel free to use it in your projects and if you find any issue or glitch, do not hesitate to open an issue on Github.

A video version of the tutorial is provided by Webucator.

1. Open QuickTime in OS X Yosemite
2. Plug your iPhone using the USB cable
3. Choose File>New Movie recording from QuickTime menu
4. Select the iPhone screen as the input camera as shown in the image below
5. Note that you can rotate the iPhone in order to record landscape screens

   

Note that there is no ability to show touches in your screencast (a functionality that most third party screencast tools are offering) but it is nice to see a built in way to record iOS device screens especially  now that Apple offers the ability to upload video previews alongside screenshots to the App Store.

As almost all Apple developers, I was excited with the announcements Apple made in WWDC this year. Lots of new stuff, a revamped OS X experience, a new iOS version with refinements for the end user and great new APIs for developers and a whole new programming language: Swift.

Last year Apple completely redesigned its mobile operating system, leading to a lot of criticism, although most reviews where positive. iOS 7 was new and fresh but in many ways it seemed like an unfinished product. Except the icons, I loved the new design for iOS. My main issue was that it was the same OS with a new coat of paint. This year, with iOS 8, Apple did exactly the opposite. It kept the appearance of the OS almost the same, refined the user experience, added subtle but meaningful new features and proved huge new opportunities for developers. The slogan in iOS’s website: “Huge for developers, massive for everyone else” describes the new version of iOS exactly as it is. End users will have almost the same experience using the stock apps, but third-party apps built for iOS 8 will provide a bunch of new features.

So lets start with the end-user features enhancements. The most notable new feature is the revamped messages app. Users will be able to mute group conversations, see all the attachments in a thread at once, and share their location with other users in the same thread. Also you can know capture sound or video and share it with others with a single swipe. These all are features provided by other apps for years, but seen them built in with Apple elegance is a nice addition to the whole experience.

Second noticeable feature are the recent and favorites contacts addition to the multitasking screen. This will provide a fast way to call or message all of your favorite contacts. Keeping with the UX refinements, Apple finally gave iOS one of the most wanted features: widgets. Widgets will be available in notification center, providing at a glance info to anything the user chooses, similar to the stock widget in iOS 7.

Huge changes -though not eye catching- come also to the photos.app. iOS 8 will store all the user photo to iCloud. This will give instant access to your whole photo library from all your devices, while also freeing some storage from your iPhone (most users’ iPhones have gigabytes of photos).

Another great new feature for users that have more than one Apple device is HandOff. With HandOff users will be able to continue their work exactly where they left it in another device with a simple swipe in the home screen (or by clicking the blinking app icon if we are talking about OS X). This, with the addition of iCloud drive, makes finally Apple’s cloud service something more than a hobby, and a solution worth thinking of using it for something else than just device backups and app data. 5GB are to few though, but thanks to the new pricing, bigger storage plans are way more affordable than before.

iOS 8 might not be a big release in terms of end-user features but it builds on top of iOS 7 with some needed refinements. It is iOS 7 as it should be, exactly like what Mountain Lion was to OS X Lion.

Now lets dive into the huge part of the story: APIs. I plan to cover the developer releases announced in WWDC14 in depth in a separate post, but iOS 8 related APIs worth a brief mention in this article. iOS 8 will bring extension. In simple words, app developers will be able to add extensions to safari, photos.app etc. For example Pinterest will be able to provide the Pin-It functionality straight in Mobile safari, without the need to leave the browser for pinning something to your boards. In the same way editing a photo with Instagram and sharing it will be possible inside the photos.app. Extension will be able to project UI to other apps. Next is Home Kit. Home kit will provide a standard API for home automation apps. This will explode apps of this kind, as now developers have to develop their own protocols to communicate between their apps and their hardware. Last but not least is  HealthKit. iOS 8 has a new app (the only new one) called Health. Health is all your health related data organized within an app. User can add data related to his health manually. But apps built in with HealthKit will be able to aggregate user’s health data (with permission from the user of course) and provide data that will be visible to Health app. Imagine that you are using to apps like Runkeeper to track your activities. If both apps are built using HealthKit, you will be able to see your activity summary (from both apps) in the Health.app.

I’ve installed the first beta of iOS 8 in an iPhone 4S since day one and I have to admit that I experience far less crashes than I did with iOS 7 beta. Performance is also tweaked and 4S seems to handle the new OS fine even though the hardware is 3 years old.

During the WWDC keynote last Monday, Apple unveiled the next version of OS X. The new version of OS X is called Yosemite and alongside a new design it comes also with great features.

So let start with the design. I have to admit that after the radical redesign of iOS 7 last year, I expected the same thing to come to the mac with Yosemite. I expected a completely flat look, very simplified -even childish- icons,  with translucency  in some places to give a sense of depth. Instead of that -and I am very happy for this- Apple chose to maintain the mac elegant aesthetics and make it more modern and eye appealing. A touch device, like iPad and iPhone, is a completely different use case from a desktop where the user uses a mouse and has to deal with multiple open windows. Instead of providing almost the same experience in both desktop and touch devices (like Microsoft does with Windows 8), Apple brought the same in design language in the mac but kept the desktop characteristics of its operating system almost untouched. So windows still have shadows (more subtle than before), icons are richer than their iOS counterparts and fonts are not ultra-thin like in iOS 7. System font in OS X Yosemite is changed from Lucida Grande to Helvetica Neue which brings the system in line with the iOS platform. Icons have brighter colors, but they maintain their shape variation and some light shadows. Translucency is used in sidebars, title bars and the new notification center, providing a sense of depth and context and making the whole os feel more elegant and polished. The use of white space is much less in OS X Yosemite compared to iOS, but compared to Mavericks it is much more. I do not think that the amount of white in the new system will cause eye bleeding to all of us who spent many hours a day in front of our mac display, but if you think so, Apple built in a dark mode in Yosemite, which will probably be one of the most loved design changes (especially from devs and designers).

OS X 10.10 will have a dark mode. Devs will love it @goldstein #WWDC14

— Nikos Maounis (@Psy2k) June 2, 2014

Except the design revamp, the new version of OS X comes with a ton of new features. And these features in most cases demonstrate exactly what Apple does. Instead of unifying the desktop and mobile OSes, it unifies the experience. The biggest improvements come to the messages.app. In Yosemite, when your iPhone is nearby, you can receive and send iMessages as well as SMSs from the built in message.app. You can even receive and place phone calls exactly like you placed Facetime calls up to now. Another great features is Continuity. With continuity you start something in your Mac (like a document, spreadsheet etc) and your iOS device is notified immediately, so with a simple swipe in your home screen, you can continue your work from your other devices. Mail.app got also a huge feature bump. The biggest new feature in mail is the built in markup capability. You attach an image, and you can add shapes, text, and callouts by drawing on the Multi‑Touch trackpad. Also using mail drop you can send up to 5GB attachments with mail. If the recipient uses mail.app, he gets the mail in his inbox with the attachment inside, exactly like before. If he uses another client, he gets the mail with a link to download the attachment from iCloud. Personally although I love these enhancements, I do not know if I will leave Airmail for mail.app after last year’s fiasco with the gmail accounts. Last but not least is iCloud drive. In simple words, iCloud drive is Apple’s answer to Google drive and dropbox. A folder in the finder that syncs across all your devices and keeps your documents organized per app.

Later this year Apple will release a new photo.app for the App with all the editing and organizing capabilities found in the iOS Photo.app. This photo.app will serve many of the duties of iPhoto, so it has to be seen what the future of iPhoto will be.

Worth mentioning is that this year Apple made the OS X beta available to all registered developers (not only those enrolled in the Mac dev program) and it will also give access to beta testers applied for the Mac beta program.

For the last 5 years Apple has focused almost on iOS, providing the mac with subtle improvements. I love that this year OS X got so much attention. Yosemite is the next step for OS X and compared to the previous steps it i a giant step forward which makes the mac look modern, even more sophisticated and the Apple ecosystem more unified than ever.

I didn’t mention anything about the new dev tools in this post, because there are so many new things for developers in iOS 8, Yosemite and Xcode 6 that they worth a separate post.

In WWDC 2013, Apple introduced Xcode 5 and iOS SDK 7 with a built-in framework for testing: XCTest.framework. Unfortunately Apple documentation lacks details for this framework. In this post I am going to present a simple way to test a UITableView using XCTest framework.

First, we need an Xcode project with a simple UITable. Open Xcode and create a new single-view application project. Open the storyboard file and drag a UITableView onto your view controller.

In the identity Inspector set “testTableView” as the Storyboard ID. Open up the ViewController.m file and place the code to poulate the dummy UITableView (do not forget to connect the IBOutlet to the TableView in the storyboard):

#import "ViewController.h"

@interface ViewController ()

@property (weak, nonatomic) IBOutlet UITableView *tableView;

@end

@implementation ViewController

#pragma mark - View loading methods
- (void)viewDidLoad
{
    [super viewDidLoad];
    self.title = @"XCTest Tutorial";
	// Do any additional setup after loading the view, typically from a nib.
}

#pragma mark - Memory warning methods
- (void)didReceiveMemoryWarning
{
    [super didReceiveMemoryWarning];
    // Dispose of any resources that can be recreated.
}

#pragma mark - UITableView delegate methods
-(NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    return 15;
}

-(NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
    return 1;
}

-(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    NSString *reuseId = [NSString stringWithFormat:@"%ld/%ld",(long)indexPath.section,(long)indexPath.row];
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:reuseId];
    if(!cell)
    {
        cell =[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:reuseId];
        cell.selectionStyle = UITableViewCellSelectionStyleGray;

    }

    cell.textLabel.text = [NSString stringWithFormat:@"Row %ld", (long)indexPath.row+1];

    return cell;
}

@end

As you can see the code is pretty self-explanatory. We just create a UITableView property with 15 rows and print the row number in each row (note that in your ViewController.h file you have to declare that the controller conforms to UITableViewDatasource and UITableViewDelegate protocols).

As you can see, I declared the UITableView property in my .m file interface section (which is the correct way to do it, because there is no need in our case to expose the UITableView to our .h file so it can be accessed by other classes). But we need to access it from our XCtest class. The easy solution would be to just move the declaration to the .h file, right? Yes, but it is not the most sophisticated solution. What are we going to do, is create a class extension which exposes the UITableView property for us. To do this, navigate to File>New>New file and create a Objective-C class extension file.

Name the file “Private” and select ViewController as the class. Open up the newly created header file and just redeclare the UITableView there as shown in the following snippet:

#import "ViewController.h"

@interface ViewController ()

@property (weak, nonatomic) IBOutlet UITableView *tableView;

@end

Connect the IBOutlet in the tableView in the storyboard again. Now we are ready to write some tests for our UITableVIew. Open up the Tests.m file which is automatically created by Xcode 5 with every new project. Import the private header file we just created and declare a ViewController property:

#import <XCTest/XCTest.h>
#import "ViewController_Private.h"

@interface XCTestTutorialTests : XCTestCase

@property (nonatomic, strong) ViewController *vc;

@end

The first thing we want to test is that the view loads and has a UITableView as subview. In the setup method we put the code we want to run before each test -in our case we just want to load the viewcontroller- and in the teardown method we put the code we want to run after each test invocation:

- (void)setUp
{
    [super setUp];
    UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"Main" bundle:nil];
    self.vc = [storyboard instantiateViewControllerWithIdentifier:@"testTableView"];
    [self.vc performSelectorOnMainThread:@selector(loadView) withObject:nil waitUntilDone:YES];

    // Put setup code here. This method is called before the invocation of each test method in the class.
}

- (void)tearDown
{
    // Put teardown code here. This method is called after the invocation of each test method in the class.
    self.vc = nil;
    [super tearDown];
}

#pragma mark - View loading tests
-(void)testThatViewLoads
{
    XCTAssertNotNil(self.vc.view, @"View not initiated properly");
}

- (void)testParentViewHasTableViewSubview
{
    NSArray *subviews = self.vc.view.subviews;
    XCTAssertTrue([subviews containsObject:self.vc.tableView], @"View does not have a table subview");
}

-(void)testThatTableViewLoads
{
    XCTAssertNotNil(self.vc.tableView, @"TableView not initiated");
}

The testThatViewLoads method checks that the viewcontroller’s view is not nil. Pretty simple test to check that a view is initiated. The testParentViewHasTableViewSubview tests that our view has UITableView subview and the testThatTableViewLoads tests that our tableView is not nil. Next we have some tests for the UITableView property:

#pragma mark - UITableView tests
- (void)testThatViewConformsToUITableViewDataSource
{
    XCTAssertTrue([self.vc conformsToProtocol:@protocol(UITableViewDataSource) ], @"View does not conform to UITableView datasource protocol");
}

- (void)testThatTableViewHasDataSource
{
    XCTAssertNotNil(self.vc.tableView.dataSource, @"Table datasource cannot be nil");
}

- (void)testThatViewConformsToUITableViewDelegate
{
     XCTAssertTrue([self.vc conformsToProtocol:@protocol(UITableViewDelegate) ], @"View does not conform to UITableView delegate protocol");
}

- (void)testTableViewIsConnectedToDelegate
{
    XCTAssertNotNil(self.vc.tableView.delegate, @"Table delegate cannot be nil");
}

- (void)testTableViewNumberOfRowsInSection
{
    NSInteger expectedRows = 15;
    XCTAssertTrue([self.vc tableView:self.vc.tableView numberOfRowsInSection:0]==expectedRows, @"Table has %ld rows but it should have %ld", (long)[self.vc tableView:self.vc.tableView numberOfRowsInSection:0], (long)expectedRows);
}

- (void)testTableViewHeightForRowAtIndexPath
{
    CGFloat expectedHeight = 44.0;
    CGFloat actualHeight = self.vc.tableView.rowHeight;
    XCTAssertEqual(expectedHeight, actualHeight, @"Cell should have %f height, but they have %f", expectedHeight, actualHeight);
}

- (void)testTableViewCellCreateCellsWithReuseIdentifier
{
    NSIndexPath *indexPath = [NSIndexPath indexPathForRow:0 inSection:0];
    UITableViewCell *cell = [self.vc tableView:self.vc.tableView cellForRowAtIndexPath:indexPath];
    NSString *expectedReuseIdentifier = [NSString stringWithFormat:@"%ld/%ld",(long)indexPath.section,(long)indexPath.row];
    XCTAssertTrue([cell.reuseIdentifier isEqualToString:expectedReuseIdentifier], @"Table does not create reusable cells");
}

The code is pretty easy to understand. Note that in every assertion we have an expression and a format. The format acts like [NSString stringWithFormat:] by default, so there is no need to use stringWithFormat there.

Unit Tests are an essential part of a modern development flow and is nice to see that Apple acknowledges it and provided a framework for that. Unfortunately XCTest does not offer a way to create mock objects. To do that you have to rely on a third party framework like OCMock.  You can download the demo project used in this tutorial from Github.