“I’m excited, I’m curious, I’m terrified, I’m angry, all at once…”

—Anonymous

Opening its Worldwide Developer Conference for a 33rd year, Apple’s keynote Monday did its best to rival Avengers: Endgame both in duration and in eliciting gasps from an enraptured audience. By the frequency of applause lines alone, Apple’s announcements for 2019 have knocked us at Big Nerd Ranch off our feet.

For developers or the developer-adjacent in the Apple community, there’s no shortage of news affecting each of the platforms that will affect the work you do this year and in the years ahead.

With 14 new frameworks and hundreds of new APIs, you’d hardly be alone in feeling overwhelmed. We want to share with you what announcements we’ve been thinking about the most, and dive into them deeper over the coming days and weeks here on our blog.

I Want to Break Free

As is now tradition, the satellites — Apple TV, Apple Watch, and HomePod — lead the event as an appetizer. All three devices are being given room to leave their awkward adolescence and grow into their own.

Apple TV will allow associating users of a device with their preferences and tastes in your app, making it function far better as a device for the whole family (both in your own homes and in your customers’ homes!). So too follows HomePod, using the messages, music, and, most importantly, Siri Shortcuts for the correct user in a home. Enhanced single sign-on, including support for more telecoms and a new Sign in with Apple, grease the wheels on what is probably the hardest part of building Apple TV apps today.

Apple Watch will soon set off on its own, gaining more independence from a paired iPhone. Your apps can sever ties with their containing iPhone apps and be installed from a new fun-size App Store directly on the watch. Apps will install — and data will sync — far faster in this new world: no more waiting painfully long for that Bluetooth connection! Streaming audio and extended background time also top the list of making speedier and more useful wrist-based apps.

Finally, a major frustration with watch development is being tackled: say goodbye to the constraints and limitations of building out your app’s UI with WatchKit, and say hello to SwiftUI. It hopes to marry the best parts of WatchKit’s ease of getting started with the real scale of Apple’s other platforms. We’ll talk more about SwiftUI by the end of this post.

Long Dark Mode Tea-Time of the Soul

Mobile platforms exist in a paradox of maturity and progress — where we rely on them to be with us all day, yet excitedly awaiting the shiny new thing every year like clockwork. This is no better representation of this than in Dark Mode for iPhone and iPad, coming to iOS 13 in its 12th iteration what took the Mac 18 years. Finally, checking your texts from bed won’t sear your eyes.

But these design changes aren’t simply a new coat of paint. They give developers a renewed opportunity to embrace iOS adaptivity and meets their users where they are, whether they have vision impairment, motor limitations, or are simply in a dark room. Your customers will notice when your app meets their needs in this way.

So, too, will they notice speed when they’re trying to get things done. A whole host of launch time, download time, and download size improvements enable packing even more into your apps. With improvements like this year-over-year, it’s no wonder that iOS 12 sits at an 85% penetration: users love using the apps you make on their devices that are constantly getting better.

For developers, we’ve seen a theme of addressing common pain points. The SDK has been updated massively for affecting how you build, react to changes, and update the content in your UI, taking inspiration from popular patterns from the open-source community. These areas are sources of bugs in all our apps, and the iOS SDKs are here to help with data transform in the Combine framework, diffing for UITableView and UICollectionView, and layout composition in UICollectionView.

It’s not just iOS, anymore, either. iPad has restored its birthright with iPadOS — the same iOS we already know, souped up for larger screens just like tvOS is for TVs. Banner features include multi-window support and further integration of drag and drop. With a simple shift in API, your one app will be able to host multiple instances of its UI without all the bookkeeping traditional window management entails.

Developers that deal with any kind of user input will benefit from deep changes to text input, particularly with rich text support that would previously take hundreds of developer hours. And with still deeper file management, applications that work with a document paradigm become more useful and allow you to focus on what makes your app great.

There’s also been major developments to address the frustrations from last year’s launch of Siri Shortcuts. Parameterizing shortcuts lets you make your app offer more of its features to voice interaction, without the typical headaches of user discovery.

Mac Coming Off The Mountain

For years, the Mac has been on walkabout, learning what it means to be a desktop platform in an age of friendliness, security, and stability. At times, the refocusing on simplicity and user consent have left the Mac passionate in the cold. Developers have felt this cold shoulder too, and often avoided what they saw as a platform of cruft and complexity.

But it’s time to remember what makes the Mac great: customization, automation, and performance. Of course, the elephant in the room here is Project Catalyst — Apple’s new method of deploying iPad apps as great Mac apps, with augmentations to handle all the features that make the Mac, the Mac. With the simplicity, convenience, and passion mobile apps have brought to users, your team can benefit from your investment in mobile on the desktop as well.

Swift Takes Flight

Now five years old, Swift is ready to take a major leap forward. By shipping it with and integrated into the OS, Apple is ready to share the Swift innovations they’ve been working on internally all this time.

Many of this years’ brand new frameworks are in Swift, and these are no small additions. Combine is a new generation of data flow management. CryptoKit brings a stable API to the world-class cryptography implementation on Apple’s platforms. RealityKit further lowers the barrier to entry of putting 3D content into AR. All of these are made to make your applications simpler, safer, and faster — just like Swift brought to your application code itself.

A great, big, heaving, “Finally!” was heard as Xcode fully integrates with the open-source Swift Package Manager and its package ecosystem. For years, we’ve relied on third-party tools to manage dependencies for our apps. And though the efforts of those volunteer teams have been incredible, there’s nothing quite like being built into the platform IDE.

With an uncompromised UI in Xcode, you can integrate, audit, and build dependency code from your team or open-source into your app. You can even use Swift packages to organize your own app code easier than ever. (And, yes, we can hear you Java folks snickering in the corner!) It’s hard to overstate how much of an effect this will have on our day-to-day work as developers.

Then, much like Swift’s unveiling in 2014, Apple decided to surprise (and terrify) us a bit. SwiftUI is clearly inspired by the functional-reactive wave affecting much of the software industry, but with additional Swift flavor, embracing the safety and performance that are a big part of the language. It eschews the traditional compile-run-debug loop of Apple’s platforms with a supercharged next generation of the Interface Builder that responds live to changes in your code, and can even manipulate your Swift code directly.

The things that make a modern mobile app great — speed, interactivity, localization, and reacting to changes from the internet or the device environment — are all defaults in SwiftUI. And the most common sources of bugs, errors, and crashes? Like in Swift itself — gone, by design. There’s a huge opportunity for us as developers to learn how to leverage this in the future to make better apps in less time and with less code, and we’re going to have a lot to say about it over the coming weeks and months.

What’s important to keep in mind is that your investment in Apple’s platforms — in learning UIKit, in learning Swift, and more — has not been in vain. Opportunities abound for being able to simplify the complex parts of your apps, but that’s the further-off future. Today, Swift improvements also reflect back into the native UI toolkits and will remain first-class for many years.

Signed, Sealed, Delivered

In building a platform, you make a kind of a promise. You promise flexibility and customers, sure, to get folks in the door — but to you keep them around, you make a promise to keep making things better.

Sometimes these promises go ignored. Sometimes they get broken. And sometimes, dramatically, they are fulfilled. If you read our WWDC Expectations: Hopes and Dreams, we’ve seen nearly all of our expectations and 5 of our out-of-this-world dreams.

Nothing speaks to Apple’s investment in these platforms quite like this years’ announcements. Problems that have plagued us as developers for years have been solved in novel and exciting ways. And for the years to come, we can watch as the future of app development unfolds, making our jobs easier, allowing us to focus on what matters in our applications, and maybe — every so often — blow a few minds.

The post Delivering Blown Minds: What the WWDC 2019 Keynote Means For You appeared first on Big Nerd Ranch.

If you did a search on Dribbble, you may be led to believe that most apps only care about signing up and logging in. By the principle of making a good first impression, sure, it’s an important experience to nail. But frontloading the flashiest of your designs can lead to a letdown when all the glitz and glamor wears off.

This isn’t a misguided trend. Sweating the details of user authentication creates a bit of a paradox. As an architect might avoid installing easily-broken glass near a home’s deadbolt lock, it is up to you to encourage safe practices in your apps. If you encourage lazy ones, users will be all-too-happy to take you up on it; then, it’s easy to lay blame if something goes wrong. But if you do it right all along, the user never notices.

Of course, we all dislike passwords. In tech, we’ve been stuck with them since about 1961. The rest of the world has come to know and equally dislike them ever since. From ever-larger database breaches to Google and Mozilla collaborating on web standards for more consistent authentication, thinking about how to live without passwords has come somewhat into vogue.

Some new alternative may be perfectly good all on its own, but what about everything in our lives that already have passwords? Think about every website you’ve signed on since you created nerdlover30307@hotmail.com over a decade ago, and how many others still you’ve signed into using Twitter, Google, or Facebook. How much of a pain will it be to even remember the method by which you should log in as new ones evolve?

Same As It Ever Was

On the other hand, Apple has long gone down a path that accepts the status quo of authentication — that is, a miasma of passwords and two-factor codes — with the Keychain and Password Auto-fill. These are uncharacteristically practical for them. If you’d ask me which tech giant would make an incompatible choice to force the whole industry to eventually follow suit, I’d say Apple.

Yet, in the crucial area of user security, Apple strikes a balance between convenience and safety. They meet their users where they already are (on the web) to deliver better experiences sooner than if paving their own way. In the modern Internet, where one trusted provider communicates with another — typically doing the complex work of encryption in your stead — a sufficiently strong password is still, easy to explain to a layman, readable, and surprisingly resilient to getting lost or locked in an incompatible format.

Not content with the opt-in support for password auto-fill brought to apps last year in iOS 11 and macOS High Sierra, Apple is taking a considerably more bold approach this year with iOS 12, macOS Mojave, and tvOS 12. Saving and retrieving passwords are now the default choice, both in apps and on the web, even to the exclusion of showing a keyboard when entering a password.

This isn’t confined to just the keyboard or just iCloud Keychain, either! iOS can ask for entries from third-party apps, search for one-time codes in Messages, and even share passwords to your nearby Apple TV.

How Do I Use It?

Apple’s app platforms build up their features on the basis of trust. Users can generally trust that apps are what they say they are when they go to the App Store. Likewise, to be able to store and retrieve the credentials for your service, Password Autofill needs to know it can trust you to be representing that service.

This association happens in two parts. Your app expresses that it’s operating on behalf of your service through the use of an entitlement. Set these up in the Capabilities tab for your app in Xcode.

Next, confirm the association as the site’s owner by creating an apple-app-site-association file on the server.

{
  "webcredentials": {
    "apps": [ "53A8EFRS44.com.bignerdranch.theborder" ]
  }
}

Finally, you can tag your login fields with an appropriate content type. There will be a ton of options in this list; keep them in mind as you do other work on your app to make autosuggest and autocomplete work almost like magic.

Without doing any of the above, iOS makes a guess at what fields correspond with usernames and passwords in an unmodified app to let the user paste any password from the keychain into the list. But this represents a best practice, providing the most consistency for you and your user. It also adapts to your app’s existing workflows, like having username, password, and two-factor codes all on separate screens.

(Auto-)Filling in the Gaps

A good platform provides you with a canvas on which to build a compelling experience. But it’s also the responsibility of the platform to notice when patterns arise and build better abstractions around them. This is the case for password autofill, where solid security foundations underpin a frightfully manual UI that eventually spreads its wings to full-fledged password management.

You can do your part by adopting these new patterns. Not only does this reduce the footprint of your code, but it will better match your app with the rest of the device and reduce confusion. Over the years, we’ve had many mechanisms for displaying in-app web browsers. Shipping alongside this expanded password support is the purpose-built ASWebAuthenticationSession, which enables logging in using a separate third-party service while protecting the user’s credentials.

A good implementation of a pattern also provides customization. The password auto-fill flow described above can be customized for a service that requires certain password formats. Certainly, it would be frustrating to have iOS offer a strong password, only to have it be too long or short. In code, you can provide an object of type UITextInputPasswordRules to describe to the system what kind of password you’re looking for. There’s even a tool for creating these rule sets.

In the end, very few of us are building username and password apps. Spend your time building a great experience and focus on the essentials. Strong security doesn’t start and end with password auto-fill, but balancing security and safety by default in your interface will get you a long way. Perhaps one day soon, we’ll be able to pretend passwords don’t even exist.

The post Apple’s Password-Less Future Is Strong Passwords appeared first on Big Nerd Ranch.

WWDC 2017’s Design for Everyone challenges developers to work for all our users. This post will teach you to rise to the challenge through concrete examples of accessible design. The examples I list are iOS-specific, but the ideas aren’t—developers across all platforms should keep accessibility in mind.

What Accessibility Isn’t

Long-time macOS users think of this icon when they hear “accessibility”:

The icon shows an abstraction of a person, not unlike wheelchair signs, just as we conceive of “accessibility” as something we tack on for “the other”—at the end of the project, if there’s time, and budget, and “market need”.

This makes sense in a world of ones and zeros, of the happy path and everything else. Folks are either in the “abled” or “disabled” camp:

This is a false dichotomy. Ability is a gradient; your app can be utterly inaccessible, a quarter-accessible or fully accessible. We all have different accessibility needs from our devices, even throughout the day:

• We are all affected by some cognitive limitation, whether from a disorder like dyslexia, or because we haven’t had our morning coffee yet.
• Siri is not only a convenience for when we’re on the move or driving, but can be crucial for users with motor control problems.
• Contrast adjustments help us see in bright sunshine, but also aid colorblind users.

The take-away here is perspective. The question isn’t, for example, “Can we afford to spend time supporting our fully blind customers?” Take it back a step: “Can we afford to support all our users?” or even “Can we afford not to support all our users?”

We have the ability to define an experience that broadens the range for more people, through the tools that the platforms provide. Rather than considering specific technologies for accessibility, we’re going to walk through how to take a day-to-day approach.

Building on What’s Familiar

All software has a task to perform. The approaches your app takes to this task are what makes it special. This can be a trap: differentiating your app can go too far and lead to breaking from platform standards that users rely on.

There’s power in familiarity. Writers tell stories by repeating words and tropes readers already know; there’s a common language. This is also true for software. With our multi-purpose and multi-modal devices, the kind of effortlessness that comes from repetition helps make our apps stand out from the crowd.

As we’re building out, for instance, custom UI, it is important to balance how easy it is to learn with what a user may already know. Let’s say I had to build a styled text editor, like the kind one would find in the Notes app. The glitzy approach involves clever arrangements of buttons or fly-out menus. But it’s important to think about what the user already knows. An iOS user is going to have dealt with the text caret before, and that naturally leads to copy-and-paste:

The text editing callout is a common pattern that a user will be comfortable with, but it’s not very flexible. What if I want my user to change the size of the text? To change the font size multiple times, I’d have to repeatedly show the callout. So we do need some custom UI, but let’s not throw out the baby with the bath water. How can someone complete this common task with minimal effort, in a way that they’re comfortable with?

Enter the popover menu. By applying a pattern in a familiar context, not only do I get to build out the extra functionality I want, but I give the user a path to reusing what they already know about using apps.

Making It More Clear

When you build an app, you’re synthesizing a new thing from many components, like system controls. These components naturally form a hierarchy. A user’s attention flows from one target to the next, so it makes sense for information to flow in the same way. Ideally, the order makes intrinsic sense, like steps in a recipe. Unclear hierarchies strongly correlate with clutter. UIs that consider clarity simply feel more like they understand the user’s needs. Consider a message in Mail:

This compact—but not cluttered—layout has been a mainstay of iOS since 1.0. The headlines are focus points, allowing a user to scan through a large list quickly. The reduced importance of the details are made explicit by varying size and color.

This kind of design is very clear, but it’s not always accessible. I frequently work with designs that strive for this same lack of clutter. In the perfect design, only single lines of text are needed. But a user may have trouble focusing on small text. Consider the same design when the font size is increased:

This is all but useless. The user loses most ability to triage messages using the subject and body text because there’s just too little there. Letting all the text break onto multiple lines is the bare minimum to improve it, but it’s a band-aid. There is a middle ground to be had, though.

By carefully selecting a maximum number of lines, a user can still see a balance of information without getting lost in the list. Notice that line spacing between different text even scales, so we maintain high legibility. We didn’t lose the core of our original design as we improved its clarity.

Making It Flow

Strong information hierarchy isn’t the only measure of an accessible design. Interaction design is equally important. Every action, every tap, every swipe should have a predictable result. A button lights up when you press it. Sounds and haptics tell us when something is ready. Affordances like these help form expectations in the digital world that would be self-evident if they existed in the real-world, like the ticking of a clock.

In short, it’s important that our apps maintain a sense of integrity. We want our experiences to be magical and exciting, but not surprising. Developers work for their users, not the other way around. And the more ways you can use this expectation to delight, the better job you’ve done.

Consider one last example, of a horizontal strip of action buttons:

There’s a lot here done to establish patterns. The order establishes importance. Icons provide scannability. Spacing between items signals that they are separate. But, as above with the Mail example, even with all these considerations it still doesn’t behave in all contexts, like language or text size. What about a long translation of one of the actions? Not all of the buttons may fit in the button strip, so even after all that design consideration, you still end up with truncated, unhelpful text.

Thus, you introduce a variation: arrange them vertically if they can’t fit. This is the essence of adaptivity: we know what context the of the user is, so we can meaningfully adapt to that. When we set expectations and adapt to the user’s needs, they almost can’t help but get into a state of flow.

Patterns Over Pixels

Developing accessible apps doesn’t have to be a hardship, or a separate, difficult task. It’s a change in perspective, with which you can do better work from the start. Likewise, accessible design isn’t a special subset of the field: it’s just good design.

By keeping a few of these ideas in mind, you can supercharge your app development workflow. Balancing your unique ideas with easily learned, familiar concepts takes less time in overall development, allowing you to spend more time on refinement, optimization, and the things that differentiate your product in the market.

You can find code for all the examples in this post on GitHub. They are designed to take advantage of what’s new in iOS 11 and Xcode 9.

If you have questions or want to get started making your app more accessible for all, our designers would love to hear from you. Our engineers can even do an audit of your existing work to help you find where to go next. Check out our work to get started.

The post Accessibility Stories: Interfaces Are for Everyone appeared first on Big Nerd Ranch.

It’s an overplayed metaphor, but it fits: I can’t find any way to describe the iconic keynotes at Apple’s Worldwide Developer Conference (or WWDC) without comparing them to opening Christmas presents when I was a little kid. If you’re lucky enough to go to the conference, I can’t recommend the keynote highly enough—the excitement from attendees and presenters is palpable. Few in this community get to go to the conference at all, or get to blow off a Monday to discover the ways in which our work will change over the next few months.

But that’s the Big Nerd Way: we absorb everything Apple has to offer, do the hard work of discovery while new technologies are being developed, learn how to do things quickly and share that knowledge you.

The theme of this year’s announcements is one of incremental refinement. Absent are the earth-shattering changes of new paradigms or entire languages. The landscape of iOS and OS X aren’t changing dramatically; rather, everything is getting a bit better. If you feel like your investments in yesterday’s new technologies like Auto Layout, Storyboards or WatchKit weren’t paying off, now is when that investment will bear fruit. If you aren’t familiar with these technologies yet, be sure to check them out before the end of the year. In the meantime, let’s get into the changes in more detail.

Flexibility for the Future

Some changes to the ecosystem present a clear roadmap for the future. The iPad, for instance, is getting versatile multitasking features: applications can run side by side with one another, requiring your apps to be even more aware of the resources and layouts they use. The writing has been on the wall since WWDC last year: if you do nothing else, you should be adopting flexible layout. Every app should be built with universal layout in mind, because there will only be more combinations of screen size and shape from here on.

WatchKit has graduated from a part of your iPhone app to a full platform of its own, with watchOS getting full tooling to sit alongside OS X and iOS. We’ll have more to say about this soon, but rest assured that the transition will be smooth. The effort and code invested into WatchKit translates nicely into full Watch Apps. But if you haven’t touched WatchKit yet, new features like sensor access might be the functionality you were waiting for.

App Thinning is a group of features allowing apps to take up less space on a user’s device and run faster.

• Through Bitcode, apps can become specialized as they are downloaded to user’s devices. Apple will apply new optimizations to your code—even on devices you can’t or don’t support yet.
• With App Slicing, the device can ignore resources it doesn’t need.
• Finally, On-Demand Resource loading allows you to package parts of the app to be downloaded when needed.

If you’ve ever had to rush to put out an update for a new iPhone or iPad release, these features should make you excited. In a well-engineered application, you may only need to release updates to support new OS features, not new hardware.

Other changes coming this year aim to fix long-standing pain points. Take, for example, your app’s layout. Complex, engaging UI used to require complex layout, like elements that hide or show, or siblings that have distributed padding. Now, UIStackView makes all that a snap. Or if Auto Layout seemed too verbose, a new compact API provides a more readable way to create constraints. Previously, Apple provided a few layout guides to ease certain layouts, and now you can create your own. Layout guides also provide great replacements to tricks like spacer views.

With API improvement, it’s now easier to target an international audience. With comprehensive support for layout mirroring, it’s straightforward to support right-to-left languages. Improved testing allows you to stress-test layouts without reading that language. Extended formatters make it easier to describe numbers, dates and now even names, all without having to write exceptions for or understand the rules in every language, culture and region in which your users can be found. With a little investment on your part, the new APIs can meet you halfway to embrace proper localization for your app.

Even web developers are getting new accommodations on Apple’s platforms this year. CloudKit gets an API for access from web apps. Better support for web apps makes it easier to use them on the Mac day-to-day. Deep linking makes it easier to go from the web to a specific part of your app, or vice versa, and the OS can even index the content of your sites and apps.

Automatic for the People

Apple promises this year’s OS X and iOS will make users’ devices work more efficiently in more situations, and developers are being brought along for the ride. Through tools that build on last year’s Handoff, an application can give the device contextual awareness of what it can do, enabling powerful integration with Siri, Reminders and other apps, all automatically. With a little more work, your app can even opt into robust system-wide search using CoreSpotlight.

iOS and OS X getting smarter doesn’t stop at the user-facing features. HealthKit, HomeKit and CarPlay gain new points for extension and automation. The developer tools have also grown a lot of smarts. Energy-saving tools mean that your apps will have less of an impact on a user’s battery. Improved debugging with Address Sanitized lets you catch intractable memory errors that cause crashes for your users. GameplayKit even provides a simple interface for complex AI and decision-making.

Speaking of games, this year highlights an ongoing emphasis on gaming technologies and high-performance applications. With Metal on the Mac, games and data-heavy applications are run more efficiently. Metal shaders allow offloading boost high-performance processing by offloading complex math to a device’s GPU, while other built-in shaders make visually stunning games easier to build—all tuned performance for every supported device.

Xcode receives enhanced tools for building better software. UI testing lets you exercise user scenarios automatically and look at performance over time. Code coverage can measure the thoroughness of your test code, improving quality as you uncover edge cases and regressions over time. And with a unified Developer Program, Apple ID-based provisioning and Free Provisioning, getting into these platforms is easier than ever before.

The Swift Investment

Swift, Apple’s next generation programming language introduced to a shocked audience just a year ago, was nothing if not polarizing. But both Objective-C stalwarts and those bullish on Swift could agree on one thing: Swift needed a little more time to bake. We got a taste of what was to come back in January with Swift 1.2, but 2.0 Swift delivers on many of the promises made last year.

With a new error-handling mechanism and the ability to conditionally run code across device versions, Swift code eliminates boilerplate to become even safer. New syntax, like guard statements and protocol extensions, encourage writing more compact and reusable code without losing readability. Many special rules, such as the different ways functions could be called, have even been removed to make writing Swift more consistent. Most of these changes are supported by Xcode’s conversion tools, simplifying updating existing code to run under the new syntax.

Objective-C has been improved to better coexist with Swift. Apple have annotated all their frameworks to add type information to collections like NSArray and when nil use is accepted. Not only does this make it dramatically easier to interact with Objective-C from Swift, but Objective-C gets better warnings to improve working with older code.

In a dramatic flourish, Apple also announced that Swift will see an open source release this fall. The crowd of developers, and the wider community, exploded with excitement and speculation about what this announcement means for Swift and Apple. While it may not change how you interact with the language day to day, or how you build iOS apps right now, it allows for a much larger community of Swift developers. The move also promises a bright future for the language beyond the scope of Apple’s devices.

Less Time on the Mundane, More on the Meaningful

You don’t have to be introducing flashy new features to be moving at a breakneck speed. In fact, the announcements at WWDC show a commitment to everything that’s come before while still pushing forward. The launches of iOS 8 and OS X Yosemite may have been bumpy, but they laid the groundwork for what we see today. In refining the features and developer tools for iOS, OS X and the fledgling watchOS, all three platforms are going to be stronger for building a product or business on.

The work of building your apps is changing. Your days, Apple suggests, should be less filled with fighting pixel-for-pixel layout or figuring out how to handle errors writing repetitive and buggy code. They should be spent on stronger engineering. They should be spent on building applications that are smarter, faster and more resilient. They should be spent on figuring out how to make your apps easier to use by people around the world. Apple’s attempt is to take away those concerns by building a stronger platform. By getting on board with the latest advancements—which is not always easy—you can spend less time on the mundane and more time on the meaningful.

The post Flexibility, The Future and More: What You Missed at WWDC 2015’s Keynote appeared first on Big Nerd Ranch.

Yesterday, we at the Ranch we were gathered around the campfire for Apple’s latest announcements. It may not have been the wearable or maybe even the inflatable you were expecting (I might have misheard the rumors), but Apple’s fall event, usually dedicated to the iPod and iPhone, has come and gone once again. There is tons of news to unpack for you, your apps and your users. Let’s get going.

The writing has been on the wall for more than a year, and Apple delivered: iPhone 6 comes in two new screen sizes—4.7” and 5.5” diagonal, respectively—and the venerable 4” screen takes a bow. Complemented by a tapered, smooth design, the new devices are a huge change.

Notably, the iPhone 6 breaks almost every UI convention we’ve come to rely on. This is not unintentional on Apple’s part. The iPhone has basically always been a candybar-shaped device with four columns of bubbly app icons. Some considered this to be an olive branch to keep designers and developers focused on building great experiences, while, for example, Android’s techniques for dealing with adaptability had not fully landed yet. Others thought of it as an imposition of control, as with the iPod: iPhone users will only ever see one perfect screen size, and if they did not like it, well, that’s rough. Meanwhile, they have been slowly building up the tools to do adaptability correctly over the years.

In order to push the envelope on display quality, most iOS devices since 2011 have shared the iPhone 4’s Retina display, where 1 point equates to 2 on-screen pixels. At generally more than 300 pixels per inch, developers could leverage increased screen density to make graphics and text sharper. The change was ridiculously easy, and developers had to do little more than update their apps’ graphics. So while the density has changed over time, the iPhone itself never really has—until now.

Similarly, in 2012 the Retina technique came to the MacBook Pro, but with a twist: the new hardware came with a feature in OS X called “scaled resolutions,” where users could choose to make on-screen elements bigger or smaller by picking a resolution that technically did not match with their screen. On a lesser display, such a preference would render elements text fuzzy and hard-to-read, but the display panel on the MacBook is so dense that the difference is nigh-indistinguishable to most users. More on this later; first, the announcements.

Your Apps

The immediate result of the new screen sizes can be jarring. Beginning next week, apps that have not been updated for iOS 8 and the iPhone 6 will run in a stretched-out mode. This is not the same stretching that happened during the move from standard to Retina displays in the iPhone 4 days; by applying industry-standard smoothing techniques, your app will still look great without any changes. An update to support iOS 8 features and layouts should be a consideration for developers, but it is not a virtual necessity.

Adapting your app to look great and function well on the new devices can be a hassle. The total combinations of OS versions, form factors, screen sizes and orientations have skyrocketed. Testing and debugging an app in all of these states is tedious and error-prone. However, Apple has provided a number of new technologies that you can and should use to make this job easier.

• Since its inception, views in Cocoa were laid out by providing rectangles to define to an object’s location. Adapting to different sizes meant resetting them manually, or by a simple set of mathematical rules called autoresizing. Beginning in iOS 6, a technology called Auto Layout exists to define views by their content and relationships to other views. Though its declarative syntax can be verbose at times, you can build extremely complex and adaptive screens with less code.

• A well-made and meaningful app can change a user’s life, but it won’t get far if a user cannot see what he or she is doing. Beginning in iOS 7, a system called Dynamic Type allows users to manage their preferred text sizes for all their apps. The new devices rely on this feature to make users more comfortable. Adopting Dynamic Type is no longer optional (but our Dynamic Type manager can help). Embracing custom text sizes is a stepping stone to truly flexible layout, and it is important to think about your app as a citizen of your users’ device.

• iOS UI has, until now, been defined by a limited set of states. Am I running an iPad? Am I on my side? New in iOS 8, these questions are answered once and for all by Size Classes. Using the same building blocks you always have, like navigation stacks and split views, Size Classes allow you to define single layouts and express only what changes from state to state. Users can interact with more at once—such as displaying dual content on the iPhone 6 Plus—but without the developer having to redesign and rebuild for every possible format.

For many apps, leaving a large chunk of their userbase on the table is simply not an option. Though Apple works hard to sustain upgrade rates, diving into iOS 7 support last year was a hard sell with the radical design change that potentially clotheslined upgrades. But between the new features and the aggressive adoption that played out the past year, it will be easier than ever to support iOS 8 wholly in the next major update to an app.

Your Designs

The new devices will also have far-reaching impacts on the design of apps. For instance, the iPhone 6 Plus requires 3x Retina HD graphics. As described above, this means that nine pixels are being displayed (instead of four) for every one square point the user sees. This idea alone might already have you panicking to rebuild all your assets.

However, now is the perfect time to consider something greater: In Xcode 6, vector assets are supported to generate images that look great on 1x, 2x and 3x displays. Vector images represent shapes and lines using drawing commands rather than a grid of pixels, and if your design workflow already involves Adobe’s Illustrator, Bohemian Coding’s Sketch or the open Inkscape, congratulations! You are going to save a lot time for free.

The story of iPhone 6 doesn’t end with 3x graphics, though. Remember when we talked about the scaled resolutions of the MacBook Pro? Apple cheated a little with the iPhone 6 Plus. Your app functions at an emulated Retina HD resolution, but is scaled down to fit on the device’s actual display. Presumably, like the MacBooks, the screen is of such high quality that the difference cannot be perceived, but this leads to the upsetting conclusion that there is no logical amount of space a programmer can use that is equivalent to one pixel.

The message from Apple could not be more clear: the pixel does not matter anymore. I have spoken with many designers who consider this an affront to their skills. Indeed, this change will make crafting pixel-perfect mockups for a given screen nearly impossible. This is as much of a gigantic pain as it is a gigantic opportunity. Designers and developers alike can benefit from the level of abstraction. Rather than thinking about which precisely sized font best gets across your message, instead consider the arrangements of content that best provide benefit and meaning to your users.

Your Money

The most blatant rip from another company’s book is Pay (Apple Pay), Apple’s venture into contactless payment systems. An NFC chip has been rumored for more than four generations of the iPhone, and it’s only just now happening. The benefit of NFC is not readily apparent to us developers, though Apple’s push will lead to more of the retailers you use every day providing card-less payment. This helps everybody, including our little green robot friends.

More importantly to us, developers get access to Apple Pay for apps running on iPhone 6 and iPhone 6 Plus. If you sell real-world goods in your app, adopting the Apple Pay framework as a layer between your user and a payment processor makes paying as easy as touching a finger to the home button. And if it’s’ that easy, there’s no telling how much more willing users will be to buy from your business.

Your Wrist

Today’s presentation still held one secret in store: the Apple Watch. The wearable is certainly nothing new, but Apple’s fashionable take on the product eschews a one-size-fits-all strategy and aims to provide a common experience across a product line of hundreds of individual devices with varying fanciness and utility.

Though the device will not arrive in stores (or your mailbox) until spring of next year, a development kit will be available in the future so that users will be able to access your services with just a flick of the wrist. The idea of tapping and swiping through endless pages just to read text messages seems arduous at best and plain silly at worst, but don’t underestimate where this platform could go. The ideal watch app is painstakingly minimal, with few bells and whistles or pages to get lost in. There is tons of goodwill to be gained from being there early and making it easy to perform common actions from your users’ arms.

Apple Watch apps will come in three forms, all of which is baked into your iPhone app and works with the wearable. Glances allow you to incorporate pieces of your content into a HUD of sorts. Notification Actions work using the iPhone’s notification system to perform simple operations without touching your phone, whether that’s responding to a message or turning down your thermostat. Finally, the WatchKit framework will allow iOS developers to build small interfaces directly for Apple Watch.

Your Users

To be a developer in this community is to never rest on one’s laurels, and the event yesterday showed why: Apple is incessantly pushing forward. New screen sizes aren’t earth shattering, nor is the promise of a first-generation product sometime next year. But promise is the key here; the payoff of an event like today can’t always be instant. One thing is for sure—that adaptability will make it easier and faster to build great apps.

As we covered back after WWDC 2014, iOS developers now have more ability than ever to build engaging, powerful experiences that bring value to their users. New features like extensibility are a love letter to developers, and initiatives like Swift show that Apple is doing what it takes to bring its platforms into the future for the next 20 years of amazing apps. We cannot wait to build it with you.

The post One More Thing: A Recap of Apple's Fall 2014 Event appeared first on Big Nerd Ranch.

Big Nerd Ranch attracts people with winding, interesting, and occasionally confusing paths through life. Our Nerds are not merely byproducts of their qualifications, nicely packaged with a bow and a sticker that says, “Hire Me!” Rather, we find bright, passionate people who never stop learning. Experience is valued expressly, like in any business, but so is diversity and adaptability. We have coders who are only just learning to program, and others who are paragons of the community. Chemistry doctorates, reformed marketers, ex-police: you name it, we have it.

Personally, I’m a child and student of the Big Nerd way. The first edition of our iOS Programming: The Big Nerd Ranch Guide (née “iPhone Programming”) was my lifeline as I first taught myself to code at 2010, laid up in bed from a wisdom tooth extraction. (Cocoa, as it turns out, is even stranger on Vicodin.)

Just over two years later, the path of life landed me at Georgia Tech, not 10 miles from our Galactic Headquarters in Atlanta. My existing proclivity for mobile attracted me to the Mobile Application Development club (GiT MAD for short). As the fall and spring semesters trudged on, I fell off the wagon when it came to making it to meetings—until February of this year, when I happened to attend a Tech Talk hosted by none other than Aaron Hillegass. We struck up a conversation after the event, and one thing led to another.

Getting started at big nerd ranch

I began my internship at Big Nerd Ranch this past May. The experience of the past few months has been nothing short of magical. This is a place where I am totally in my element. This became exponentially more clear as I moved from working on an internal app up to one of our consulting teams. I fell immediately into the rhythm of working with a team, bringing whatever I had learned to the table, learning absolutely everything my colleagues had to share with me and (so I’ve been told) teaching them a thing or two as well.

As June dissolved into July and the humid summer wore on, I came to realize a few things about my work:

• I don’t want to stop working at Big Nerd Ranch.

• I don’t think I can stop working.

Turns out, like timidly revealing your infatuation to your crush, Big Nerd Ranch felt the same way about me, and I recently shifted my work from part-time intern to full-time coder. Basically nothing has changed. I still put my jeans on one leg at a time and my code still gets picked at for having conflicting tabs vs. spaces.

This was a decision I didn’t make lightly. College has been a dream—and, moreover, an impending reality—of mine and my family’s since I was in middle school. Why, then, would I give up a great time at a fantastic school? It’s only insert number more years until I graduate, surely I could get a job like this then, right?

Well, I suppose that’s true, in a sense. But like being at Georgia Tech was a realization of a dream, being at Big Nerd Ranch is the realization of something I’ve known since the first time I touched the flimsy glass screen of the original iPod touch: I want to build unbelievably great things with unbelievably great people. I’m taking advantage of that opportunity now, and plan to return to school part-time next fall.

what the future holds

Big Nerd Ranch has the most unique and refreshing approach of any place I’ve ever seen. In the typical hand-wringing way of an obsessively forward-thinking teenager, I’ve long worried about how that actual “getting a job” part would work. Would I sell my soul to write Perl for some faceless megacorporation? Or would I work 29-hour days for some startup and have a part for myself in an Aaron Sorkin film? As with most things in life, this isn’t just black and white, but I’m young; I think in absolutes.

But instead, I landed right in the middle of this spectrum by starting a career at a sustainable, strong company in an exciting industry that is constantly changing and expanding. (Con: there are no West Wing walk-and-talk sequences and I don’t get to find out which comedy actor would play me.)

Since the moment I got a green-and-goldrenrod letter in my inbox in April, I’ve been in a constant state of joy, and I’m not sugarcoating that. Our wonderful Blithe Rocher (also an intern-turned-employee) describes it best. Big Nerd Ranch is my home, I just happen to sleep somewhere else. I get to wake up, come into work, and do what I love, day in, day out.

Big Nerd Ranch is no fly-by-night VC cashout. We are not ninjas. We are not rock stars. We are not chained to our desks for nine hours a day, five days a week. We are Nerds, and the best kind: regular, humble people who obsess about making fantastic things. We think about animation curves over lunch, we draft pull requests in the shower, and we rap about language features. We learn absolutely everything we can about what we do, and then we have the audacity to share that knowledge with others.

We are changing the game one bit, byte, book, block, tap, and app at a time. And I couldn’t be more thrilled to be a part of it.

The post At Home on the Ranch: My Path to Becoming a Nerd appeared first on Big Nerd Ranch.