As promised, here is the Swift version of the slide out sidebar menu tutorial. Again we will make use of an open source library called SWRevealViewController to build the sidebar menu. Though the library was written in Objective-C, you can easily integrate it into any Swift project. You will see how easy you can access and interact with Objective-C classes using Swift.

Okay, let’s get started.

In this tutorial, I will show you how create a slide-out navigation menu similar to the one you find in the Gmail app. If you’re unfamiliar with slide out navigation menu, take a look at the figure on the right. Ken Yarmost gave a good explanation and defined it as follows:

“Slide-out navigation consists of a panel that slides out from underneath the left or the right of the main content area, revealing a vertically independent scroll view that serves as the primary navigation for the application.”

From what I know, the slide-out sidebar menu was first introduced by Facebook. Since then it quickly becomes a standard way to implement navigation menu. Nowadays, you can easily find this design pattern in most of the popular content-related apps such as Inbox, Digg, LinkedIn, etc.
The slide-out design pattern lets you build a navigation menu in your apps but without wasting the screen real estate. Normally, the navigation menu is hidden behind the front view. The menu can then be triggered by tapping a list button in the navigation bar. Once the menu is expanded and becomes visible, users can close it by using the list button or simply swiping left on the content area.

You can build the sidebar menu from the ground up. But with so many free pre-built solutions on GitHub, we’re not going to build it from scratch. Instead, we’ll make use of a library called SWRevealViewController. Developed by John Lluch, this excellent library provides a quick and easy way to put up a slide-out navigation menu in your apps. Best of all, the library is available for free.
The library was written in Objective-C. But it is very straightforward to integrate it in your Swift project. You will learn how it can be done in a minute.

iOS is an operating system with many possibilities, allowing to create from really simple to super-advanced applications. There are times where applications have to be multi-featured, providing elegant solutions that exceed the limits of the common places, and lead to a superb user experience. Also, there are numerous technologies one could exploit, and in this tutorial we are going to focus on one of them, which is no other than the Text to Speech.

Text-to-speech (TTS) is not something new in iOS 8. Since iOS 7 dealing with TTS has been really easy, as the code required to make an app speak is straightforward and easy to be handled. To make things more precise, iOS 7 introduced a new class named AVSpeechSynthesizer, and as you understand from its prefix it’s part of the powerful AVFoundation framework. The AVSpeechSynthesizer class, along with some other classes, can produce speech based on a given text (or multiple pieces of text), and provides the possibility to configure various properties regarding it.

The AVSpeechSynthesizer is the responsible class for carrying out the heavy work of converting text to speech. It’s capable of initiating, pausing, stopping and continuing a speech process. However, it doesn’t interact directly with the text. There’s an intermediate class that does that job, and is called AVSpeechUtterance. An object of this class represents a piece of text that should be spoken, and to put it really simply, an utterance is actually the text that’s about to be spoken, enriched with some properties regarding the final output. The most important of those properties that the AVSpeechUtterance class handles (besides the text) are the speech rate, pitch and volume. There are a few more, but we’ll see them in a while. Also, an utterance object defines the voice that will be used for speaking. A voice is an object of the AVSpeechSynthesisVoice class. It always matches to a specific language, and up to now Apple supports 37 different voices, meaning voices for 37 different locales (we’ll talk about that later).

Once an utterance object has been properly configured, it’s passed to a speech synthesizer object so the system starts producing the speech. To speak many pieces of text, meaning many utterances, doesn’t require any effort at all; all it takes is to set the utterances to the synthesizer in the order that should be spoken, and the synthesizer automatically queues them.

Following the release of iOS 7 (and iOS 8 as well), animation and motion effects became central to the design of apps from both Apple and 3rd party developers. iOS 7 introduced a flat, minimal design to apps which inevitably resulted in some apps having a similar UI. To distinguish their apps from other apps, developers employed such features as animations and motion effects to make their apps stand out.

Not only are animations used to set your app apart, they can improve the overall user experience of your application. For great examples of how animations are used to improve UX, you should look at how Apple uses animations in their apps. For example, in the Photos app, when you select a photo from a collection, the photo expands out from the selected one and on closing it, it shrinks back to the selected photo. This adds to the navigation of the app in that it lets you know exactly where you were, if browsing many pictures.

Facebook’s Paper also employs animations beautifully to add to the overall user experience of the app. You select an article to read by flipping it up. This action, the fact that the article expands out from its thumbnail version, suggests that in doing the opposite, i.e. flipping the article downwards, would shrink it back to its thumbnail. Here, animation is used to convey how the app works and even a first time user of the app would soon be able to make assumptions on its use and figure out its navigation without needing a tutorial.

Not only do animations add to the user experience of the app, but they could be what delights and impresses your users guaranteeing repeat usage instead of uninstalling the app for a better one from the App Store.[Read more…]

During the development of an application there are various steps involved in the whole process. Some of them are the definition of its specifications, the creation of graphics, the implementation, and the testing phase following the implementation. Writing the code maybe consists of the most important part, as this brings the application to life, but further than that, equally important is the proper documentation of the code. No matter how well-written the code is, if there’s lack of a good documentation accompanying it, future troubles it’s possible to arise. Unfortunately, many developers overlook or ignore the importance of the code documentation, and that’s really bad, as good software is not just good code. It’s more than that.

When talking about documentation, apparently I don’t mean just to add a few lines of comments somewhere in the implementation files. It’s definitely more than that. But first, why is it such a big deal to document the code? Well, there are two cases: Whether you’re working on your own, or you are a part of a team. Let’s see in short each one.

If you are the only developer of the under-development application, then it’s reasonable to believe that writing code documentation costs in time, so skipping doing that will bring you right into your target much sooner. Additionally, it’s easy to convince yourself that as you’re the sole developer there’s really no need to do that. But trust me, that’s the worst decision you might make during the app creation period. Suppose that you successfully implement the application, you sell it either on the app store or in a client of yours, and then you put it in the shelf. And after six months or so, you must create a new version of it by adding new features. When you open the project again and look to the existing code, a long before you write the first new line, you realize one killing truth: That you don’t remember almost anything! It’s hard to remember what you did, how you did it, and why! You must follow the one, painful way to wake that project up in your mind, which is no other than taking the project from the beginning and trying to “decode” your implementation line by line. Just a few comments here and there are not helpful, and eventually you end up making a super-effort for a long time until you understand everything. Many of you that you are now reading these lines may have come to that point, and I ensure you that there were times that I’ve been there too. This case is a real nightmare, and you often want to start building the project from scratch. And of course, the scenario described here would just be a… scenario, if we all invested a little time to write proper code documentation.

Editor’s note: Apple Watch is expected to release in the coming months. But as you know, the company already released WatchKit, the SDK that allows developers to create apps for its upcoming Apple Watch, along with Xcode 6.2 beta. So you may have already played around with it and started building Watch apps. If not, this beginner tutorial is for you. This week Julian from Julo’s development will give you an introduction to WatchKit and show you how to build a simple guess game using the SDK. You’ll learn how to create a Watch app, layout the app UI and test the app.

Enter the WatchKit tutorial.

WatchKit was first released by Apple on November 18th, 2014, along with Xcode 6.2 beta. The SDK allows developers to create and develop apps for the Apple Watch. To develop applications for the Apple Watch, you’ll need to have a paid developer account to download Xcode 6.2 beta. The demo app will be written in Swift. So I expect you have some basic knowledge of Swift programming.

When programming in iOS, there are certain aspects of the SDK that pull the developers’ attention and interest a lot more than others, and one of them is the Multipeer Connectivity framework. As you know, the MPC framework is not new in iOS 8, instead it was first-introduced in the seventh (7th) version of it, about a year and a half ago. In the past, I’d written a couple of tutorials about it, and to tell the truth, I was surprised from the interest that people seemed to have about it. Now, some months later, I return with a new post regarding it, as I believe that there are still things that need to be explained.

You may wonder why I bring to the surface a topic a bit old, and not something new included in iOS 8. Well, I’m doing that for three reasons:

Many readers have approached me through e-mail messages, asking how to perform various tasks in multipeer connectivity that were not mentioned in the previous two tutorials. By answering to all those messages, I found out that there’s a need that I hadn’t noticed earlier; People want more information about it, which is hard to find sometimes.

The implementation I presented in the last couple tutorials was based in the use of a default, pre-made view controller existing in the iOS SDK for inviting other peers and establishing a connection. I found out that people was asking for manual implementation, and that’s something we are about to see here.

I think that it will be quite useful and educational to see how to implement MPC in Swift.

During the lifetime of the multipeer connectivity framework, it has been proved that the possibilities that it came to offer gave birth to new ideas to a great number of developers. Connecting devices using such a simple way seems so attractive, and that’s why programmers want to integrate it into their applications. However, if you haven’t used the MPC framework yet, I must warn you: Sometimes it’s not as reliable as you may expect, and that’s something I’ve seen personally in my projects, and also other developers have reported to me. MPC uses both Bluetooth and WiFi to connect nearby devices, but even though it sounds too good and promising, sometimes the connection either fails or is to slow, leading to communication errors. That’s important in cases you need to transfer vital data. I would advice you to use a backup communication solution (such as a web service), so you make sure that there is an alternative and your application will continue to work even if the MPC fails. However, despite to what I just said, I still believe that MPC if a good tool for all iOS developers, so it worths it one (last) more tutorial.

In the first part of the WebKit tutorial, we covered the basics of the WebKit framework. In this tutorial, we’ll dive deeper into WebKit and look at how we can customize web pages loaded by our native app. We’ll also see how we can extract data from web pages and use it in our app.

We’ll build an app that is specifically meant to browse appcoda.com. To follow along, download the starter project. The starter project is a simple browser named Coda, much like the one we built in the first part of this tutorial. The only difference is that it doesn’t have a text field for the user to input a url to be loaded and I replaced the Back, Forward and Reload buttons text with icons.

If you’ve ever built an application that required a webview to load web content in your native app, then you have probably experienced the frustrations that came with using UIWebView. UIWebView is quite limited and its performance lags behind that of Mobile Safari. JavaScript, which powers just about every web application, performs poorly in native mobile applications.

However, all of this has changed with the introduction of the WebKit framework in iOS 8. With the WebKit framework, comes WKWebView which replaces UIWebView in UIKit and WebView in AppKit, offering a consistent API across the two platforms.

The WebKit framework enables developers to create web enabled native apps that can utilize the power and Speed of Nitro, which is the JavaScript engine that powers Safari.

In the span of two articles, we’ll build two applications which will explore some of the features that WebKit (in particular, WKWebView) offers. For the first application (built in this tutorial), we’ll create a web browser that has some of the functionalities of Safari. The second article will go deeper into Webkit and show the more powerful features like injecting JavaScript into a web page to modify content and extract data.[Read more…]

When the fifth version of iOS (iOS 5) was released to the public, it introduced a brand new, revolutionary approach to the way the interface of an application was designed. That was the use of storyboards, and it was meant to change the existing designing philosophy from the ground up. Before iOS 5, each view controller had almost always an accompanying Interface Builder file, known as nib or xib, and the idea was simple: The interface of each view controller was supposed to be designed in the respective nib file, whereas all the nibs together were composing the full interface of the application. From one hand, that was handy because developers could only focus on the interface they were designing at the time, but on the other side, too much files were eventually had to be created, and even more, developers could not have a whole overview of the app’s interface.

With storyboards all that became just history, as this new way has been used by almost the entire developer community. Storyboards had (and have) to offer three significant advantages compared to the old-fashioned technique:

The whole interface design takes place in just one file. The total number of the files in a project is dramatically reduced, especially in big-sized ones. Using extra nib files is optional and is allowed for creating auxiliary views only.

Developers have at their disposal an instant overview of the app’s interface and flow.

The transitions between the view controllers (named scenes in terms of the interface design) and how they happen are now perfectly defined and clearly presented to developers.

From all the above, the transitions between scenes consist of a special chapter of the storyboards, and they’re mostly known as segues.

A segue is closely related to the navigation and handling of an application, as it actually defines the transitioning details when moving from one view controller to another. These details specify whether animation should be applied or not, what kind of animation, and of course, the preparation and performance of the actual transition. But not just that. A segue can also be used to pass data to the view controller that’s about to be shown, and that’s a common case scenario for almost all developers.

Editor’s note: When Facebook released its Paper app, it generated a lot of buzz in the app world. If you’ve used Paper before, the visual news feed reader, you should be amazed by its beautiful and fluid user interface. The design and attention to detail on the app is unmatched. The app refrains from using buttons and menus, but was built to be gesture-driven, to a degree that was uncommonly found in iOS apps at the time of its release. It went beyond Core Animation. The team has built its own animation engine to support all the smooth animations and coordinate animations with touch inputs. When I first tried out the app, I was wondering how some of the animations were implemented. Honestly I didn’t know how. A couple months later, the company open-sourced Pop, the animation engine behind its iOS Paper app. As a Facebook’s engineer described, Pop drives the scrolling, bouncing, and unfolding effects that bring Paper to life. Thanks to Facebook team. With the Pop framework, this means you can create similar animations that were found on Paper in your own apps.

The Pop framework was first released in late April, 2014. So far we haven’t written any tutorials about the framework. Thanks to Hossam who is kind enough to share with us an introduction of POP and show us how to create a few simple animations.

Enter the Pop tutorial.

In this tutorial, we will talk about Facebook POP framework to make great and easy animations in your own iOS apps. Like any other tutorials on AppCoda, I will help you understand and master Pop by examples. We will create four simple animations together to explore the framework.

Pop is an extensible animation engine for both iOS and OS X. In addition to basic animations including Linear, Ease-In, Ease-Out, Ease-In-Ease-Out animations, it supports spring (at the time of its release, spring animation was not supported in iOS), decay and custom animations:

Spring – dynamic animation that creates a nice bouncing effect.

Decay – dynamic animation that brings a movement to a smooth halt.

Custom – because the engine is designed to be extensible, you can create your own custom animations.