Harry Doyle & Xcode iOS Application Templates

Using Xcode to build your application is like joining a baseball team that already has a stadium, groundskeepers, uniforms, a team plane, a roster, a working scoreboard, and a couple questionable announcers.

Xcode, in other words, supports you with pre-existing code that does a bunch of stuff that you'll need to make your application function. Xcode will provide some starter building blocks for you to build your application off of. In other words, you will not need to build your apps completely from scratch.

That being said, you do not have to use all the building blocks that Xcode gives you. You can keep some and delete others as you see fit. The more you play with Xcode and get a feel for what it offers and what you need, the better you'll be able to decide to keep or toss the building blocks Xcode gives you.

Upon choosing to create a new project, you are quickly asked to choose one of the following five templates to base your new app on:



Specifically, you can build a Master-Detail Application, a Page-Based Application, a Single View Application, a Tabbed Application, or a Game. In this post, we'll run through the differences between them all so you have a better idea which to choose when starting to build your app.

Let's say you want to build that bullpen phone app that we discussed in the last post; the one where you are the manager and you get to choose which relievers from the bullpen to warm up and how quickly they need to get ready before actually making the call.

What will the app need to do? First, it needs to list all of your relievers. Second, it needs to let you choose up to two relievers to warm up. Third, it needs to let you review the stats of your relievers so you can make an informed decision. Fourth, the app needs to let you indicate how quickly the relievers are needed. And fifth, a way for the bullpen coach to communicate when the relievers are ready to enter the game.

Which of the above application templates should we use for our bullpen app? Let's run through the options.

1) Master-Detail Application

Between Apple's icon for Master-Detail and the brief description towards the bottom of the above image which reads, "This template provides a starting point for a master-detail application, using a split view controller to display a list of items and a detail view", we can make an educated guess on how Master-Detail works: Master-Details offers a column of items on the left and when we choose one of those items we then see it in greater detail in the larger space on the right.

Does this approach work for our bullpen phone app? Let's see.

In the bullpen phone app we can have master segments that cover: bullpen pitchers, pitcher stats, and ready pitchers. If we choose bullpen master, in the detail section we see a list all of our relief pitchers (for example, Betances, Clippard, Warren, Severino, Shreve, Layne). We can then choose up to two pitchers, indicate how quickly we need them to get ready, and make the call to the bullpen. If we need to review Warren's stats before making the call, we can tap the pitcher stats segment, choose Warren from the list of relievers and see his latest games log. If we have already chosen two pitchers to warm up and check their progress, we can tap the ready pitchers segment and see if the pitchers are ready or not, before choosing the one we want to go with. Which you gotta believe will have a confirmation GIF of a manager walking out to the mound raising his left or right arm and tapping it with the other.

But what if it's the seventh inning and we want to get up Adam Warren and Tommy Layne, a righty and a lefty, just in case the other team brings up a pinch hitter? Can we choose two relievers from the left-hand column and display them both simultaneously in the detail screen on the right? Unfortunately, we cannot in this setup.

So Master-Detail may not be for us this time.

When is a good time to use the Master-Detail Application template?
Master-Detail is particularly helpful for iPad applications as it provides a split-screen look that Tabbed Applications do not.

On to the next option.

2) Page-Based Application

Here too, Apple's icon for the template and their explanation give a glimpse into how a Page-Based Application works. Apple explains that this template, "provides a starting point for a page-based application that uses a page view controller."

From looking at the icon and seeing its three dots we can deduce that that app has three screens that we can swipe through. As a point of reference, the most popular example of a Page-Based Application is your iPhone itself: From the home screen you can swipe through all the different pages of apps that you have on your phone. In this case, the number of apps that you have on your phone that can fit on a screen will determine how many screens you'll swipe through.

Does the Page-Based Application template work for our bullpen phone app? Not so much. Page-Based apps are best for portfolio sites that want to show off information, such as images, rather than process information through functions that require user input.

So Page-Based is not for us either this time.

When is a good time to use the Page-Based Application template?
Page-Based applications are best for where you can read books or articles that have multiple pages in lieu of vertical scrolling.

3) Single View Application

While the Single View Application icon may not tell us much about how this template works, Apple's explanation helps: "This template provides a starting point for an application that uses a single view. It provides a view controller to manage the view, and a storyboard or nib file that contains the view."

Many apps are built on the Single View template. Why? Because it offers a lot of flexibility in terms of layout of images, text, buttons, and more. And it's not like you only have one screen to build your entire app on. Rather, you have as many individual views (or screens) as you need to build your app. Each view is a different screen and each screen is a different view controller.

Does the Single View Application template work for our bullpen phone app? It just might. Let's walk through it. On the Home screen we could create a table of all of our relievers, checkmark those we want to warm up, and then press a "Warm Up" button on the bottom to make the call. That works pretty well. If we want more information about a reliever, say a log of all the games he's pitched that season working backward by date, we can click on the reliever's name and go to a different screen (view controller) that provides that information. After making the call we can have another screen that asks the manager how quickly each reliever needs to warm up ranging from Next Inning to Next Batter. (We might even want to build this functionality into the first screen or make it like a checkout process where you pick what you want, confirm, pay).

The Single View template works well for our needs, but let's take a look the remaining two templates just in case they are even better.

4) Tabbed Application

Again, the Tabbed Application template icon isn't completely helpful and while Apple's description, "This template provides a starting point for an application that uses a tab bar. It provides a user interface configured with a tab bar controller, and view controllers for the tab bar items" helps, we can do better.

Do you use Instagram? Instagram is a Tabbed Application. How do we know? Along the bottom of the Instagram app are five tabs: home, search, camera, favorite, and profile. Tap any one of these tabs and you are quickly taken to that screen.

Is this a good approach for our bullpen phone app? Depends. What tabs would we need? We could have a Roster tab where we could see all of our relievers. We could have a Warming Up tab where we could see who is currently getting ready in the bullpen. We could also have a Stats tab where we can select specific relievers to see how they've done so far this season and how much they've worked lately.

So far the Single View and Tabbed Application templates may be our best bets for this particular app.

5) Game Application
So far we haven't thought of the bullpen app as a game because when your starter loads the bases the manager doesn't usually have time to spare: He needs to notify the bullpen immediately.

But could we turn this into a game? Sure we can. What would the game look like? You're the manager and you have to navigate your team through a treacherous seventh inning in which your starter starts the inning at 90 pitches thrown and the meat of the order is coming up. Can you, as manager, pull the right levers to keep your one run lead? That could be a game version of the bullpen app.

And that, in general, are your different application template options when looking to build your own app through Xcode.

Xcode Libraries & Frameworks: The Don't Call David Ortiz Episode

In the latter innings of a baseball game, there is no confusion over who calls who: The manager calls the bullpen. Question is, which pitcher(s) in the bullpen is the manager calling for and how quickly do the relievers need to get ready? 

It's questions like this that get developers thinking about new apps and what steps to take to build them. In our manager's case, he needs an app that calls the phone number of the bullpen phone, an app that displays on the bullpen phone screen images of the pitchers he wants to get ready, and indicates how quickly he wants them to get warmed up (maybe on a scale from next inning to next batter).  

If we were to build out this bullpen app we would have to navigate Xcode appropriately.  

Oh, and if David Ortiz calls the bullpen he's not much of a conversationalist. He prefers to let his bat do the talking.

Xcode may be most well-known for its ability to write software for Apple's iPhone OS (Operating System), but that's not all Xcode can create software for. In fact, with Xcode you can write software for iOS, watchOS, tvOS, OS X, and the always popular "Other". Not only can you create applications for each of these operating systems (OS), but you can also write frameworks, libraries, and system plug-ins for OS X. 

That's all great, but what does it all mean, why are libraries and frameworks important, and when do we use which? That's what we'll cover in this post as we dig a little deeper into Xcode.

Getting Started with iOS

When it comes time to start a new project Xcode gives you some options. Do you want to create something for the iPhone (iOS), for the Apple watch (watchOS), Apple TV (tvOS), for a Mac laptop or desktop (OS X), or something else? These options appear on the left hand side of this window:

In the above case, we see our iPhone application options. In the same way that a baseball clubhouse manager makes sure that all the uniforms are cleaned and hanging in each player's locker ready for the game, Xcode lays out some pre-existing software formatting for each format before we even write a line of code. If you're familiar with Ruby on Rails, it's akin to Rails scaffolding. Do you need it all? Maybe. Maybe not. Either way, it's there if you do. Specifically, Xcode comes with established code for apps that are Master-Detail, Page-Based, Single View, Tabbed, or in Game formats. 

What are frameworks and libraries? And how are they different?

A good question with, apparently, no single answer as this Stack Overflow page notes. Seeing how this is our first time with this subject, let's take a broad view for now. This visual representation of frameworks and libraries may help:



So what's going on here? Let's walk through it. Say that you're a manager building an iOS app that wants to keep track of your bullpen (the green "Your Code" rectangle above).

A framework is made up of one or more libraries. Libraries are pre-existing code that you call to use their functionality instead of building out that functionality yourself. A manager can go out and try to pitch the ninth or he can pick up the bullpen phone and call for the closer who already knows what he's doing and does it much better than the manager.

In the same way, your code calls a library when it needs to use that library's code. Here are some of the most popular Swift libraries currently found on the online code repository, GitHub:



A framework, on the other hand, calls your code (the way that Zack Britton probably tried to call Buck Showalter during the 2016 AL Wild Card game; that phone may still, in fact, be ringing...). Why, or more importantly, when would a framework want to call your code?

Broadly speaking, a framework calls your code when it needs to know what to do with what it has. Here are a few examples:



Those all sound great, but what are they talking about? Good question. In general, what Ben's talking about is this: The user of your app, in this case, the manager, chooses a reliever from the bullpen and calls him. Then what? Then the framework takes that information - that the app needs to call a specific reliever in the bullpen - and calls your code to find out what to do with the manager's action. In our case, the framework learns from your code that the headshot of the chosen reliever should appear on the screen of the bullpen phone.

That's the big picture of what it means for a framework to call you. In other words, the framework's not calling you, it's calling the code you wrote so the framework knows how to properly respond to an event in your app. The Hollywood paraphrasing that some software bloggers and teachers have adopted to explain frameworks ("Don't call us, we'll call you.") is cool, but potentially confusing. Hopefully this explanation clears things up.

Here is a long list of frameworks that come with iOS-based devices.  The list includes frameworks that allow users to access their address books, for determining a user's location, and for accessing a user's calendar for event data among others.

Our manager can even create his own frameworks and distribute them if he wants so teams from Rookie ball to the majors can use the technology.

On Deck: We'll continue to delve into Xcode.