A New Way to Build Interfaces

When building applications for any platform, the user interface is a significant portion of that work. Apple’s platforms – iOS, iPadOS, macOS, tvOS, and watchOS – are no exception, and the existing tools and APIs used to create interfaces for those platforms date back thirty years to NeXTSTEP.

In those thirty years, millions of apps have been made, new programming languages have emerged, and a lot of lessons have been learned on how to make interfaces simpler and with fewer bugs. And so we were excited when Apple announced SwiftUI – a brand new, unified way to build interfaces for all Apple platforms – at their Worldwide Developer’s Conference in June 2019.

The initial public release of SwiftUI was really promising, but the framework was still nascent and had many noticeable gaps. So, at the Ranch, we spent that next year learning SwiftUI internally and exploring how we might teach this exciting new technology.

Last June, WWDC 2020 came and Apple filled in many of those gaps in SwiftUI. At that point, we felt SwiftUI had the minimum feature set for most apps. Since that update, we’ve been hard at work planning, building, and refining our new SwiftUI course, and we’re excited to share it with you all now.

Before we talk more about the course, let’s talk briefly about what SwiftUI is, what we’ve learned about it, and how that’s ultimately influenced the course.

SwiftUI in a Nutshell

SwiftUI is a declarative, reactive framework leveraging Swift for building interfaces that run on all Apple platforms. SwiftUI has built-in support for features that users expect, such as Dynamic Type, Dark Mode, and VoiceOver accessibility. And SwiftUI adapts to the platform the app runs on, giving your interfaces a native look and feel with minimal effort. Taken together, building interfaces with SwiftUI can take substantially less development time compared to using UIKit and AppKit.

We’ve learned some things about SwiftUI since its introduction:

• The barrier to entry for SwiftUI is much lower than existing Apple platform frameworks.
• SwiftUI comes with a bit of a learning curve, especially as you build more complex interfaces.
• Building interfaces that target multiple Apple platforms is surprisingly easy.

Developing interfaces using SwiftUI is drastically different than doing the same using UIKit or AppKit, the existing native platforms for iOS and macOS platform development. Because of this, it’s a fresh start in many ways and requires a new perspective when building apps and interfaces.

If this sounds exciting or interesting, take a look at our new SwiftUI Essentials course.

var body: some View {
    Text("Hello, SwiftUI Essentials!")
        .font(.headline)
        .bold()
}

Whether you are new to making apps for Apple platforms, or if you’ve been doing it for years, you will feel right at home in our SwiftUI Essentials course. Our goal with this 3 and a half-day course is to give you the knowledge and tools to effectively and efficiently build cross-platform SwiftUI apps.

We’ve been using SwiftUI on our consulting projects for over a year. Even with years of collective experience, we still get stumped from time to time. We’ve taken these questions, these problems, and their solutions, and applied them to this course to help jump-start your journey into SwiftUI.

For more specifics on what’s covered, check out the course syllabus. We also have a talk on YouTube that shows a little of what we’ll be covering.

We’re thrilled to bring this course to you. Keep an eye on our social media or our website to see when we’re running our next Bootcamp. Also, if you’re interested to know how iOS development works, consider reading our book about iOS programming. If you’re interested in us bringing this training directly to your team, write to us at hello@bignerdranch.com.

The post SwiftUI Essentials: The Big Nerd Ranch Course appeared first on Big Nerd Ranch.

We’ve just released the 7th edition of iOS Programming: The Big Nerd Ranch Guide. It’s pretty crazy to write that! That means seven editions and ten years since the original release of iPhone Programming: The Big Nerd Ranch Guide.

iOS development continues to evolve year after year, and so what is considered essential knowledge likewise changes. In this edition, we’ve added new discussions on topics that all iOS developers should be comfortable with, removed some discussions that are not as relevant these days, and continued to refine the book as a whole—in large part from the feedback of students that have taken our bootcamps.

Notable changes

iOS has had a couple of significant visual changes in the past few years.

New discussions and deep dives into the “safe area”: In 2017, iPhone X was released. With it came the introduction of the sensor housing (aka the “notch”) along the top and the home indicator along the bottom. Developers need to account for these elements within their apps, and so the book has been updated to dig into the details across a number of chapters.

Expanded coverage on adaptive interfaces including dark mode: Last year, in 2019, dark mode came to iOS with the release of iOS 13. (Technically it came to iOS with the release of tvOS 10 in 2016, but it was never usable on iPhone and iPads.) Dark mode joins a number of other external changes, including the user’s preferred text size (“Dynamic Type”) and the app’s interface size (“size classes”), that the book discusses. Good apps need to adapt to these external changes, and the 7th edition shows you how.

Hello to some new friends …

A new chapter on “Container View Controllers”: A problem we often see in our consulting work is the “Massive View Controller” problem—a situation where developers add too many responsibilities to a single view controller. Sometimes a view controller can be split up into multiple smaller view controllers, each with their own responsibility. These smaller view controllers are recomposed using a container view controller, and we have a new chapter implementing a custom container view controller in a project new to the 7th edition.

A new chapter on “Custom UIControl Subclasses”: You start to feel the “Massive View Controller” approaching when building the new book project. To address the problem, you create a custom UIControl subclass in another new chapter, separating out more responsibilities and digging into how controls operate along the way.

… and goodbye to some old ones

So long to “Touch Events”: A chapter on Touch Events has been included since the 1st edition. Ultimately, higher-level APIs exist today such that the need to dive down to the low-level touch APIs is rare. We felt that dropping this chapter would give us room to discuss more relevant topics elsewhere in the book.

Farewell to “Gesture Recognizers”: A chapter on gesture recognizers has been in the book for some time as well. We felt that this chapter dug a little deeper into gesture recognizers than is often needed for app development. We’ve thus dropped this chapter and moved discussions on gesture recognizers into other chapters.

Other changes

While there are too many small changes, tweaks, and improvements to keep track of, here are some highlights worth mentioning.

• Updated for iOS 13, Xcode 11, and Swift 5.2
• Added coverage of the Codable APIs, including handling some common custom JSON decoded situations
• Moved from our custom Result types to Swift’s generic Result type
• Re-added discussion and use of NotificationCenter
• Moved presenting modal view controller discussions into their own new chapter
• Reworked the animations chapter for the new UIPropertyAnimator APIs

And finally, our wonderful Editor Liz Holiday has massaged the entire book. In the process, she has improved clarity, addressed errata, and added an amazing level of polish to the entire book.

Towards the future

We’re really excited about the 7th edition. We’ve been working hard on it for years and know you will love it. But the journey doesn’t stop here for us. We have a lot of other content that we’re working on and are excited to be sharing with you.

• We’ll be running a four-hour workshop on Combine on May 26. Combine is a new reactive programming framework that Apple introduced last year to help you process values over time. We’ve been using it on our projects and it has transformed the way we write iOS code.
• We have another four-hour workshop happening on July 21 discussing how to architect asynchronous code. Handling asynchronous code can be challenging and is a common source of bugs, and so it is important to have a strong understanding of these ideas.
• And as always, we’re excited to see what Apple has in store for us at WWDC this June. We’ll be working on updating our iOS development course and likely hosting more virtual workshop as a result of their announcements.

Keep an eye on our social media for more information!

The post iOS Programming: The Big Nerd Ranch Guide – 7th Edition Launches! appeared first on Big Nerd Ranch.

One of the most exciting announcements from WWDC this year was that native multitasking is coming to iPad. The ability to run two apps side by side is something that many iPad owners have wanted for some time to increase productivity.

What do you have to do to get this working in your app? The wonderful answer is that you don’t have to do anything whatsoever! It will Just Work.

Alright everyone, that’s a wrap for this blog post. Have a great week!

OK, OK, maybe I’m being a bit disingenuous. If you’ve been following Apple’s recommendations over the past few years, then you don’t have to do much of anything.

There are two requirements for multitasking: your app itself needs to support multitasking, and your interfaces need to lay out appropriately for different sizes. Let’s take a look at each of these.

Supporting Multitasking

To support multitasking in your app, you need to do the following.

• Build your app with the iOS 9 SDK
• Support all orientations
• Use a launch storyboard

By doing those three things, your app will now appear in the list of multitasking apps that the user is able to choose from. It’s that easy.

Updating Your Interfaces

Supporting multitasking in your app is unarguably the easier part. The hard part is ensuring that your interfaces lay out appropriately with all sizes.

Here are the currently supported Split View layouts for side-by-side apps:

Apple has been introducing key pieces of technology over the past few years, specifically Auto Layout and Size Classes. In order for your interface to look great at all sizes, you must use these two amazing technologies.

In 2012, Apple introduced Auto Layout to iOS with iOS 6. Auto Layout allows you to lay out your interfaces using expressive relationships. For example, you can have a view remain horizontally centered within the app’s window. As the size of that window changes, the centered view will still look great.

In 2014, Apple introduced Size Classes with iOS 8. Size Classes allow you to reason about the general size of horizontal and vertical dimensions of your app independent of device type and orientation. Size classes are crucial to iPad multitasking.

Here are the horizontal size classes for apps in different Split View layouts:

By using these two technologies, your interfaces will lay out appropriately for any size.

The Future

Users are going to expect your app to support multitasking. If you’ve been following Apple’s recommendations over the past few years, then you’re probably already good to go. If you haven’t? Well, you have a lot of catching up to do.

Apple often makes a point to emphasize certain, usually new, technologies. If you follow WWDC closely —or listen to us, who do—you will pick up on these. Apple will not only exhort you to use them but will usually provide extensive tooling and documentation to help you use them. When you see that, it’s often a sign that Apple knows something about the future that you do not and are trying to save you work in the long term.

I’m really excited about iPad multitasking. It is going to change the way that people interact with their iPad. New workflows will emerge that were previously relinquished to desktops and laptops. This will breathe new life into the productivity app market, and I cannot wait for it.

The post WWDC 2015: iPad Multitasking appeared first on Big Nerd Ranch.

In their opening keynote on Monday, Apple stated that iOS 8 is their biggest update to iOS since its initial developer release with iPhoneOS 2.0. It sounds hyperbolic, but it isn’t—this year is huge, both for users and developers.

As users, we’re in for a treat: we’ll have experiences on iOS that were never before possible. And as a developer, I see a number of big themes coming out of iOS 8:

• Improving the development experience
• Extensibility
• Adaptability

Improving the development experience

Apple has improved the end-to-end experience for developers. Starting with the new Swift programming language, developers will be able to write code more quickly and with fewer errors. The new Xcode has a lot of fantastic features to help with Swift development, and one of the most useful is the new Playground feature. Playgrounds allow for developers to quickly prototype and test Swift code, seeing the results of their code in real time. This new feature will be an indispensable tool to help new developers get accustomed to Swift, and we plan on taking advantage of this in our bootcamps in the near future.

At the other end of the developer experience, Apple has vastly improved the testing experience for developers. Now, internal and external beta testing is provided by Apple, and the experience will be much better than the (brilliantly) shoehorned experience that we’ve had to deal with in the past. There are so many other improvements that help during development, and I cannot wait to share these with you soon.

Extensibility

Apple has long been conservative with the degree to which third-party apps are able to interact with the device. With iOS 8, our apps can finally participate more fully in the user’s experience. Android has a similar feature called Intents, and Windows Phone’s is called Contracts.

Apple calls these Extensions, and they are certainly a game changer. There are several types of extensions. One type allows apps to share information with other apps. During the Keynote, Apple showed off posting to Pinterest directly from Safari. Another type of extension allows apps to have a Notification Center widget. Similar to the Stocks or Reminders widgets that we already have, developers can now create their own—and the possibilities are exciting.

Adaptability

A big focus for Apple this year is making our code more adaptive and more reusable. Too frequently, we write code or create interfaces for a specific device, screen size or orientation, and Apple has given us some amazing tools to free us from that bad practice. It’ll allow our applications to be written more quickly and more generally. I see this as one of the biggest changes this year. It’ll require thinking about your apps a little bit differently, but I promise that the results will pay off.

WWDC and Big Nerd Ranch

We at Big Nerd Ranch have been giddy all week. As a company, we are continuously learning and pushing our knowledge, and WWDC 2014 has elevated that to the nth degree. We are hungrily scarfing down all of the information we can get ahold of so that we can pass it along to you.

As Adam mentioned, our courses will have a Swift introduction very soon, with more big changes coming down the pipeline. It’s sincerely been an overwhelming week full of surprises, and we couldn’t be more excited to experiment with and learn more about them.

The post WWDC 2014: iOS 8 Will be Huge for Users and Developers appeared first on Big Nerd Ranch.

Although the iOS 7 adoption rate is now at 85 percent, many developers still need to support iOS 6. I’ve seen people struggle with designing their interfaces so that they look at home on both versions of the operating system. This blog post will show you the best practices for achieving this goal.

Problem

The problem initially occurred when developers first updated their apps for iOS 7. Everything looks great on iOS 6, but when you run the app on iOS 7, your subviews get cut off.

Here is an example from my iOS book that illustrates the situation in an application we call Homepwner:

You may have also come across a similar issue with UIScrollView; we’ll talk more about that shortly.

So the question is, how do you design your interfaces such that they look right on both iOS 6 and iOS 7? (Hint: if you aren’t already using Auto Layout, you’re going to want to start using it.)

Solution

We’re going to take a look at three different use cases:

• interfaces that do not have a UIScrollView

• interfaces that do use UIScrollView (or a subclass thereof, such as UITableView or UIWebView)

• interfaces that are built using storyboards

So you don’t have a scroll view

If you aren’t using a scroll view, adjusting the interface to work with both iOS 6 and iOS 7 is very easy.

1. Use Auto Layout.

2. Have a single view anchored to the top of your UI using a constraint [1. It doesn’t have to be a single view, but you’ll need to duplicate the remaining steps for each additional view that is anchored to the top.], with all other views anchored either directly or indirectly to that view.

3. Create an IBOutlet to that top NSLayoutConstraint.

4. Modify this constraint in viewDidLoad conditionally based on the OS version that the app is running on.

Let’s take a look at each of these steps.

I mentioned earlier that you should be using Auto Layout—and really, you should be using it for all of your interfaces. If you are not, you are doing yourself a huge disservice. Maybe this’ll be the subject of a future blog post, but for now, send me any “why?” questions by tweeting @cbkeur. I hope I don’t have to convince you.

Typically, you’ll have a subview at the top of your interface. I often refer to this view as the anchoring view (if you have a better name for this, please let me know). This subview will be constrained to the top of its superview via a top constraint, and the rest of the subviews will be laid out in some fashion relative to that top view.

Take a look at this screen shot (designed with iOS 7 in mind, unlike the previous screen shot).

In this example, I’m considering the name label the anchor view. The text field to its right has aligned its baseline with the name label to determine its y-position. As you can see, there is exactly one view that is anchored to the top. This makes updating our interface very easy, and will make fixing our interface for iOS 6 a breeze.

In iOS 6, there is going to be quite a bit of white space above the name label. This is because the top of the view is at the bottom of the navigation bar, as opposed to the top of the screen, like you can see in the Interface Builder screen shot above. To eliminate that white space, we just need to subtract the heights of both the status and navigation bars from the top constraint’s constant.

To do this, we first need to create an outlet to this constraint in code so we can modify it at run time. This looks like:

    @property (nonatomic, weak) IBOutlet NSLayoutConstraint *topConstraint;

Make sure to connect this to the NSLayoutConstraint that you have in your XIB file. (If you are doing things programmatically, then you already have a reference to that constraint, so you’re good to go.)

The last thing you need to do is actually update the constraint’s constant based on the OS version. viewDidLoad is the perfect time for this if you are using a XIB (as that is the first time your outlet is actually connected), or loadView if you are building your interface programmatically.

    - (void)viewDidLoad
    {
        [super viewDidLoad];
        // Check to see if we are running on iOS 6
        if (![self respondsToSelector:@selector(topLayoutGuide)]) {
            self.topConstraint.constant = self.topConstraint.constant - 64;
        }
    }

Let’s walk through this code. The code above uses the topLayoutGuide property of view controllers to determine if you are running on iOS 6 or iOS 7, as it is an iOS 7-only property. This property is closely related to laying out interfaces, so you use this as a reference point. If the view controller does not respond to that selector, you are on iOS 6, so you need to remove the white space that our XIB had at the top. To do this, subtract the height of both the status and navigation bars [2. I hardcoded this value, 20 from the status bar and 44 from the navigation bar, but it might be better to do it dynamically, especially if you support iPhone landscape. Just add the height of the UIApplication’s statusBarFrame to the height of the navigation controller’s navigationBar.].

(If you built your interface for iOS 6, and needed to support iOS 7 after the fact, you’d want to add in the white space instead of removing it, so you’d want to do self.topConstraint.constant = self.topConstraint.constant + 64;. This would fix the problem in the screen shot at the top of this blog post.)

Use Auto Layout; it’ll make your life much easier.

What about the scrolly things?

Say you have a scroll view (or subclass), and for one reason or another, your interface is wonky in iOS 6 or iOS 7. What can you to do fix it?

1. Use UIViewController’s automaticallyAdjustsScrollViewInsets if you have a single scroll view that is at the “back” of your interface (I’ll define this below).

2. Adjust the contentInset and scrollIndicatorInsets properties of the scroll view manually if you have multiple scroll views, or if it’s not at the “back” of the interface.

Let’s take a look at both of these circumstances.

With iOS 7, UIViewControllers have a property called automaticallyAdjustsScrollViewInsets, and it defaults to YES. This property can make your life much easier, provided you understand how it works.

If you have a scroll view that is either the root view of your view controller (such as with a UITableViewController) or the subview at index 0, then that property will adjust both the contentInset and the scrollIndicatorInsets. This will allow your scroll view to start its content and scroll indicators below the navigation bar (if your view controller is in a navigation controller). As opposed to manually adjusting the frame of the scroll view to start underneath the navigation bar, this solution will allow your scroll view content to scroll underneath the navigation bar, which is an important aspect of iOS 7.

If your scroll view does not meet the prior criteria (or if you’ve set automaticallyAdjustsScrollViewInsets to NO), then you’ll need to manually update those two properties:

    - (void)viewDidLoad
    {
        [super viewDidLoad];
        if ([self respondsToSelector:@selector(automaticallyAdjustsScrollViewInsets)]) {
            // For insetting with a navigation bar
            UIEdgeInsets insets = UIEdgeInsetsMake(64, 0, 0, 0);
            self.tableView.contentInset = insets;
            self.tableView.scrollIndicatorInsets = insets;
        }
    }

You might want to do this if you have a background image behind your scroll view, or if you have multiple scroll views within one view controller. Since this property does not exist on iOS 6, you get the existing behavior.

Storyboards

Ah, storyboards. Apple loves storyboards and they can do stuff that is seemingly magic. So what do you do for storyboards?

1. Use Auto Layout.

2. If you aren’t using a scroll view, create a top constraint to the “Top Layout Guide”.

3. If you are using a scroll view, you can use the scroll view steps above (and you’re able to set the automaticallyAdjustsScrollViewInsets property from within the Attributes Inspector on the view controller).

Well that was easy. Let’s take a look at both of these.

Creating a constraint to the “Top Layout Guide” is easy, as shown in this screen shot.

As long as everything is constrained relative to the top layout guide, then your interface will lay out correctly on iOS 6 and iOS 7.

“But wait, Christian,” you might say. “You said that the top layout guide is an iOS 7-only feature.” And you’d be entirely correct. Apple is working some magic here. On iOS 7, Apple is correctly adding a constraint to the topLayoutGuide, but on iOS 6, Apple is creating a UIView with a frame of {0, 0, 0, 0} and attaching that top constraint to that view instead. I wish it could work as nicely somehow with XIBs, but alas.

For scroll views, follow the same advice as in the previous section. If you need to set the automaticallyAdjustsScrollViewInsets property, you can do so from the Attributes Inspector on the view controller.

Deference

So why did Apple make these changes that can require a non-trivial amount of work on behalf of the developer?

One of the key areas that Apple wanted iOS 7 to improve upon was deference, which is defined by my Mac as “humble submission and respect.” Our interfaces should defer to the content, which is at the heart of the experiences within our apps. Apple’s Human Interface Guidelines state that “the UI helps users understand and interact with the content, but never competes with it.”

Take Safari for example:

When you first visit a site, you have all of the controls at your disposal. The URL bar and reload button are at the top, and the toolbar at the bottom contains the rest of the buttons needed to interact with the app.

Once you begin to scroll, the UI defers to the content on the screen. The navigation bar at the top shrinks to display only the base URL, and the toolbar at the bottom goes away completely. If a user needs to access these buttons, they can simply tap on the navigation bar at the top, or scroll back up [3. The way iOS handles this is a little interesting. If you scroll to the very top of the page, the navigation controls reappear. If you flick to scroll up with some velocity, the controls will also appear. But if you scroll up without flicking, the controls stay hidden. My gut tells me this is because Apple decided in the latter case you were probably deliberately still reading the page, and thus didn’t want the controls to appear.].

Some classes were changed in pursuit of deference throughout iOS 7. We’ll focus on UINavigationController, but the same principles can then be applied to UITabBarController.

In iOS 6 and earlier, the content view of a navigation controller extended from just under the UINavigationBar to the bottom of the screen. With iOS 7, on the other hand, the content view extends from the very top of the screen to the very bottom, underlapping the navigation bar.

Take a look at this screen shot of Maps taken on both iOS 6 and iOS 7. Notice that with iOS 7, you can easily see the blurred content under the navigation bar (and the toolbar at the bottom).

Content is clearly king here. The translucent UI elements hint at the content behind them.

Conclusion

• If you have an interface without a scroll view, use Auto Layout to shift your content up or down to support both iOS 6 and iOS 7.

• If you are using a scroll view, take advantage of UIViewController’s automaticallyAdjustsScrollViewInsets property to due the heavy lifting for you. If, for some reason, you aren’t able to take advantage of that property, then you’ll want to adjust the contentInset and scrollIndicatorInsets properties of the scroll view to achieve a similar result.

• If you are using storyboards, anchor views to the “Top Layout Guide”.

Today’s blog post comes courtesy of our iOS hero, Auto Layout. I’m a huge proponent of Auto Layout. With Xcode 5 (and even more so with Xcode 5.1), I find it quite easy to work with. You’ll probably see more from me on Auto Layout in the future.

The post Designing Interfaces for iOS 6 and iOS 7 appeared first on Big Nerd Ranch.