• In Depth
• iOS

Implications of WWDC 2015

Four new technologies and APIs introduced at WWDC

After watching the 2015 WWDC Keynote I was excited by some of the APIs that Apple have announced. I’ve now had some time to watch some specific WWDC sessions.

Also, I've had a play with some of the new and exciting APIs that will be available on iOS 9 and some of the new features of Xcode 7.

In this article we’ll cover the following four new technologies and APIs that were introduced at WWDC:



• UIStackView

• AppSearch

• Swift 2

• App Thinning

UIStackView

This is a brand new control that is being added to UIKit in iOS 9. If you’ve ever developed apps for Android then you’ll be familiar with Linear Layout, essentially UIStackView is Apple’s equivalent.

UIStackView takes a collection of views and lays them out in either columns or rows. You can adjust the stack view to distribute the views in different ways, set spacing between the views and add/remove views at runtime while animating the changes.

You can also nest stack views within other stack views and create complex layouts. Stack views leverage the power of Auto Layout to size and position their views without you having to worry about defining the constraints yourself. It’s never been easier!

Fig 1. Example of a Stack View in IB

The above image shows how you can use a stack view to display buttons vertically. The last row contains a horizontal stack view containing three more buttons.

The possibilities are endless. No constraints, outlets of code was harmed in the making of that layout!

When to use Stack View?

Apple thinks that stack views are so useful that they have added a dedicated button on the Interface Builder canvas to wrap the selected views in a stack view.

Stack views could be used to present a small list of images or buttons to the user without having to mess around with UITableViews and where you don’t need cell reuse or a datasource. Of course you could also use stack views to build entire interfaces and even grid layouts.

What makes them great?

The real power of stack views becomes obvious when you want to add and remove views from a stack at run-time.

Prior to iOS 9 you would have to layout all the views yourself, create lots of constraints, keep strong pointers to some of the constraints and enable/disable these constraints while managing the view hierarchy. This can lead to a lot of messy and convoluted code. In contrast, to remove a view in a stack view all you need to do is find the view you want from the stack view’s arrangedSubviews property, set the view’s hidden property to false and that’s it.

The stack view will automatically remove the view from the view hierarchy redistribute and position it’s other views shifting them up and resizing them if necessary. The example below shows how to remove a view simply by setting it’s hidden value:

UIView *myView = stackView.arrangedViews[2];
UIView.animateWithDuration(0.5) {
 
myView.hidden = true

}

To add a new view you just need to add it to the stack view’s array of arrangedSubviews by calling the addArrangedSubview method of UIStackView. You don’t need to call addSubview as this will be handled for you automatically.

An example

I’ve created a very simple example project that presents a series of buttons vertically and horizontally.

Tapping on a button will set its hidden property and cause the view to be removed. Tapping the Add button will add a new button to the stack view. Apart from the code to create new UIButtons the whole thing was just a couple lines of code to toggle the views hidden property and animate it.

https://github.com/cameroncooke/UIStackView

https://developer.apple.com/videos/wwdc/2015/?id=407

AppSearch

Since the introduction of Spotlight in iOS 3, developers have wanted a way to integrate their apps with Spotlight. While Spotlight could return app results that match apps by name it could not search within the apps and offer results. With iOS 9 this has all changed, and in a big way.

Apple have announced a series of APIs that allow app developers to expose content within their apps to be offered by Spotlight search results.

This means that it’s now possible for a 3rd party email client to offer up email results, or for a travel app to show bookings that match the user's input. It’s worth pointing out that app search is entirely local (unless you opt-in for remote indexing) and Apple point out that they take privacy seriously (maybe a little dig at Google there).

No spiders

Unlike traditional search engines AppSearch does not use a spider. Instead it requires developers to essentially inform iOS that something should be shown in the search results.

The developer has complete control over what they want indexed and what happens when the user taps on a result. The preferred option is to deep link the user to a screen within the app that is relevant to the result being selected.

No app installed, no problem

One of the most impressive things about app search is that items being indexed can opt-in to be indexed by Apple’s servers.

This means that every time a user does something that triggers an index, a hash of this index will be sent to Apple’s servers. If the server receives enough index requests for the same hash (Apple have not disclosed what these thresholds are) then Apple will index the content and offer search results to users who don’t even have the app installed!

Clearly you would not use this for indexing user specific data but you might use it to index main features in your app to allow people to discover your app.

Customisable results

Developers can customise the Spotlight results specifying a title, description and image and more.

Deep linking

One important feature of AppSearch is that you can deep link into your app from the search results presenting the user with information that is relevant to the result they just tapped on.

This essentially works in a similar way to deep linking from requests to custom scheme URLs.

Another example

A colleague and I have built a very simple example app showing App Search in action. The example displays a list of names in a table view and tapping a name takes you to a detail screen.

Once the app has been opened and indexed you can then search by those names in iOS 9's Spotlight, taping a matching result will then deep link you back to the detail view controller for that selected person.

https://github.com/cameroncooke/appsearch

There is a lot more to AppSearch so I urge you to watch the following WWDC session:

https://developer.apple.com/videos/wwdc/2015/?id=709

Swift 2

Apple have a made a lot of great improvements to Swift 2; mainly ironing out some of the issues surrounding Objective-C/Cocoa Touch and Swift interoperability. Some surprising changes are actually to Objective-C. It will make working with existing Objective-C code in Swift easier.

Lightweight generics

Apple have added what they call 'lightweight generics' to Objective-C.

@property NSArray *myArrryOfStrings;
...

self.myArrayOfStrings = @[@"Hello", @"World"];

This means that accessing myArrayOfStrings in Swift no longer needs to be typed AnyObject it will now be of type [NSString].

Improved error handling

Apple have implemented an elegant way to handle errors in Swift 2 with the new try, throw and catch keywords. This new error handling model provides a clear and expressive syntax for catching and throwing errors.

func loadData() throws { ... }

func test() {
 do {
 try loadData()
 } catch {
 print(error)
 }
}

Open Source

Yes that’s right, you are reading this correctly. Apple have finally embraced the open source community by promising to make Swift open source later this year.

This should enable adoption of Swift outside of the Apple ecosystem and lead to improvements to the language and move future development at an even faster rate.

Time to switch to Swift?

After ignoring it for ages, I believe now is the time to embrace Swift, even if it’s slowing introducing it into an existing Objective-C codebase.

It's clear that Apple are serious about Swift and I believe the language is now mature enough to be adopted without too many issues. You shouldn't require quirky workarounds or the depositing of random question and exclamation marks everywhere (while crossing your fingers, toes, eyes etc).

More about Swift 2:

https://developer.apple.com/swift/blog/?id=29

https://developer.apple.com/videos/wwdc/2015/?id=106

App Thinning

One of the more interesting things announced at WWDC was what Apple calls 'App Thinning'. One of the problems with apps of late has been their ever increasing size. Apps now have to support a mirade of devices and orientations. Keeping all the artwork and resources in the app bundle takes up a lot of space.

Large apps will obviously prevent some users installing your app, not really what you want!

The solution

Apple’s solution to this problem is quite clever. Apps built with Xcode 7 will now be built into an intermediate language that Apple calls Bitcode (aka Bytecode or IL).

When the app is uploaded to iTunes Connect the App Store will automatically compile and link multiple versions of your app targeted at different types of devices.

All the resources that your app needs are bundled as normal in the payload you upload, but the App Store will automatically split these out and create device specific versions of your app with only the assets and resources needed for that specific device.

Assets need no longer be just images. In Xcode 7 Asset Catalogs now support any type of asset i.e. video, sound, pdf etc. They can also be targeted for different device types.

Apps built using Xcode 7 will get all of this for free and the developer does not have to do anything for this to work. There are a few caveats though; when building apps in Bitcode all the dependent libraries that your app uses must also be compiled into Bitcode, libraries that have not been updated can’t be used.

Fig 2. Shows the app thinning process Apple have not stopped there.

They've also announced the ability to group resources in your app together and host them separately from the app bundle to be downloaded on demand asynchronously if and when the app needs them.

This, for example, could be used to load all the artwork for level 3 of a game when the user reaches that level. Previously all the artwork would have had to be included in the app bundle.

In conclusion

There is a lot of great stuff here. I urge you to watch the WWDC sessions. If you’re a registered developer try out some of it for yourself. Have fun!

This article was originally written for Brightec by Cameron Cooke