But how do you actually, well, do it? Great question! Let’s take a look at some best practices that can help you improve your CI process. 

1. Maintain a single source of truth

Continuity is, in essence, a complete path that allows information to flow effectively and efficiently. It’s also a beautiful thing—and really the core of CI. Without it, you can’t gain any of the efficiencies promised in the approach. So, a useful starting place for implementing CI is designating a single, central repository for clean code and a solid system for versioning. Your development team will need a clear plan for pull requests (PRs) and coding merging—one that is specifically designed with CI in mind. You will also want to make sure that this repository is as secure as possible since it’s your single source of truth for the project.

2. It’s ok to be pushy 

While there are plenty of tools to enhance the quality of your CI implementation, no factor is more important than the team’s buy-in on the approach. Why? Because for CI to work, every developer must push their code frequently.

In the context of CI, “push” is more than sharing code to a repository. It also includes the process of testing and merging code. Without frequent updates to the central repository, you can’t increase the pace of progress and stay competitive against other teams that have successfully implemented CI. It’s worth acknowledging that this process does approach Continuous Deployment, though we’re going to cover CD in more depth in a later post. 

Regardless, developers should break their changes into smaller portions, do their best to push multiple times a day, and PR once a day. The ideal we’ve seen on a typical project is for your team to make a commitment to a daily PR.

3. Keep it continuous (automate, automate, automate)

So where do these commits actually go? Before they are merged, they need to undergo testing and validation. You can streamline nearly every aspect of CI by building a pipeline for compiling code, executing tests, and deploying in a production-like environment. By implementing an automated pipeline, you can start to see the speed benefits of CI kick in, as well as reducing certain types of errors. A CI pipeline also creates visibility across the entire process, so you can analyze the source of errors and avoid them in the future. 

Every time a developer commits code, it automatically undergoes necessary testing (more on that later). Particularly in an agile environment where you need to release updates at a high frequency, the pipeline keeps everyone not only uniform but also moving forward.

But how can you put your first CI pipeline in place? That’s going to depend on the scale of your build and the complexity of testing and deployment involved. For smaller teams and operations, buying a pipeline is an excellent option. For example, on many of our projects across platforms, we’ve found CircleCI effective. Some alternative solutions include GitHub Actions, Jenkins, Bitrise, and GitLab CI. For more complex builds, you may need to build a customized pipeline or outsource that build to a team of professionals. 

4. Know your tests – and when to run them

Let’s review the different types of testing you need to run as part of CI.

Unit tests

Unit tests check the business logic, or basic correctness, of code. Typically, you run these at a high frequency (often with every commit) to detect bugs. 

Running unit tests as part of a CI pipeline has additional benefits. Not only will bugs be caught that might otherwise slip into a product, but the tests themselves can also have problems. Running the suite more often incentivizes the team to keep the test suite relevant and healthy.

Integration tests

This one is a pain because it’s both expensive and inconvenient. It also happens to be incredibly crucial. Whereas unit tests focus squarely on the code, integration tests widen the scope of testing to include pieces of your infrastructure like the network, database, or file system. These tests are going to indicate issues bigger than bugs, like a problematic change in your environment. CI allows a dev team to split out slower and more expensive tests so that they run overnight or in a more controlled fashion. This maintains a high-quality check on the product without slowing down day-to-day development. 

System tests

You’re not done just yet. Once you validate your high-level architecture, you still need to test your builds within a simulation of the full production environment. The ultimate goal of any app is to provide the best experience for your end-users. That includes the portion they interact with, as well as the systems that are holding the whole thing up. Those systems include: 

• Virtualization tools (if you’re running your own private cloud)
• Databases
• Containers and container orchestration systems like Kubernetes 
• Load balancers
• DNS servers
• Proxy servers
• Cloud object stores (AWS S3, Google GCS, etc)

Make sure that the system tests you run accurately simulate your production environment in conjunction with these elements (as applicable). A common approach to achieve this is by using lower environments that are a copy of production.

Regression testing

With all the changes that occur during a project—especially one with multiple developers working through multiple phases—there is always a chance that your app will not work as intended. In fact, it’s not uncommon for the same feature to break multiple times, in response to different, apparently unrelated, changes. This regression in functionality can cause all sorts of headaches and problems. 

Regression testing addresses these issues by checking that existing core functionality hasn’t been damaged. A regression testing suite is often built from the previous tests you’ve successfully run in the past, such as unit or integration tests. 

The upshot of regression testing is that frequent problem areas remain under test, and hidden problems are caught sooner. The team also gets a psychological boost from avoiding the feeling of “this same thing keeps breaking and I keep fixing it.” That kind of failure is very draining to a team’s sense of progress. 

Keep it sorted with Agile 

On larger projects, all these tests can become a bit overwhelming. You can automate all of these tests within your CI pipeline. For the best results, we typically work within an agile framework. 

However, in an agile environment, multiple developers can trigger build cycles in unpredictable orders. With a rapid moving team and continuous integration, there is no “endpoint” at which to insert quality checks like integration testing. One common mistake is to push integration tests off, close to release points. However it is better to push them earlier in the process, so they run as part of merging code early and often. This gives the product team more time to deal with breakages and adjust processes.

It’s also a good idea to run these tests in separate environments so integration testing doesn’t slow down unit test feedback. That way, developers can check their code logic freely and frequently while longer integration tests run in a separate test suite and in different environments. 

5. Amplify feedback – and keep it blameless

The reality is, builds are going to break. It’s part of the process! A culture of blame creates an atmosphere of fear that discourages team members from making commits. Frequent commits are a necessary component of effective CI in the first place. Along with those commits is keeping the lines of communication open. Part of the CI philosophy is to keep these communications “blameless,” or rather, focused on the opportunities for improvement rather than individual vilification.

In practice, this means that throughout the project you will want to have a system in place for sharing user feedback and learnings across the team, so everyone stays up to date. Blameless retros are a good tool, and there are many retrospective guides and styles. The important thing is that the team regularly discusses, in a future-focused way, how to improve. 

It’s also important to make sure the team checks in, both at regular intervals and the close of the project, to reflect on these learnings and identify necessary improvements. No one can change the past, and on a healthy team, you should assume everyone is doing the best they know at the moment to contribute. So a healthy team stays focused on learning and improving continuously, just like their software is tested continuously. 

If you’d like to learn more about blameless CI, check out Vivek Ganesan’s Blameless Continuous Integration: A Small Step Towards Psychological Safety of Agile Teams.

We’re big CI fans. Want to talk shop?

Continuous Integration isn’t something that happens overnight. It takes time and effort to get CI right for your specific needs, but that effort pays dividends when it comes to quality builds, greater responsiveness – and, the holy grail, client and user satisfaction.

Here at the Ranch, we use CI/CD on our projects as much as possible. It helps us adapt quickly to changes and deliver quality code to our customers.  And if there’s one thing we love, it’s nerding out on technical topics. So if you want to learn more about our approach to CI, or how you can better implement it for your teams, don’t be shy – schedule a meeting today!

Here are some resources that I’ve used in the past if you’d like to learn more:

• CI Best Practices
• CI vs CD
• How to Implement an Effective CI/CD Pipeline
• The “Bible” for CI, though some concepts have been updated over time
• CD Best Practices
• CI/CD Best Practices
• 6 Best Practices for Integration Testing and CI

The post Best Practices for a Continuous Integration Build appeared first on Big Nerd Ranch.

On Monday, I talked about the business implications of this year’s WWDC announcements, but today’s post is for developers. I had trouble finding key information after the keynote, so I put together a compendium of documentation and important key concepts from WWDC 2016. Brace yourself for lots of protocols!

• Tip #1: Browse prerelease documentation by release date to see what is new. A ton of WWDC sample code and docs have been out since Monday night!
• Tip #2: Find less-discussed changes by browsing iOS API Diffs. This year it is best to view Obj-C diffs, as the Swift diffs are huge this year (hello API guidelines). For example, UIKit Diffs are always worth a skim.
• Tip #3: Use Swift iBook revision history to quickly find and read up on key changes.

Nerd Favorites

Documentation links from Apple are notoriously unstable, though word has it this year that might be improving. However, if a link below is not working, your best bet is to search the Apple development site directly. Comment below and we’ll update the link.

We’re excited about:

• SiriKit, or Intents Extension and Intents UI Extension. This is initially available for only six domains:

  1. Audio or video calling
  2. Messaging
  3. Payments
  4. Searching photos
  5. Workouts
  6. Ride booking

• I’m particularly curious about these speech changes and these Swift 3 API design guidelines (via https://swift.org/migration-guide/).

• watchOS 3 has a renewed focus on speed. Glances appear to be gone, replaced by more glanceable apps. Also see API Diffs.

• CloudKit sharing controller and Services. Again, use revision history as a guide to what is new.

• Xcode source editor extensions are only briefly discussed in the release notes. Take special note of the Known Issues; there’s a terminal command you will need to run. There are more gotchas, some covered in this handy blog post. While not a panacea, I am excited that Apple is headed down this path with Xcode.

• I’m really excited about controllable animations!

• Core Data advancements

• Basic Neural Network Subroutines for neural networks

• Apple File System

• If you have extra devices you can use for exploring, check out the beta downloads. Or you can browse all prerelease documentation by release date yourself, and find what you’re most interested in. You can find gems like this very specific but useful new ability.

Getting Started

Want the new and shiny right now? Download Xcode 8 Beta, open a new playground or project and start playing around. Import a framework, poke through the headers and then try out some code.

Want to really dive in? Take one of our classes to get your skills up to speed.

Finally, what are you most excited about so far? Did I leave out something incredible? Let me know in the comments.

The post WWDC 2016: Developer Reading List appeared first on Big Nerd Ranch.

As I type, Apple’s yearly developer conference, WWDC 2016, is in full swing. The keynote can be watched via Apple TV and their website, or you can catch summaries and highlights on every site that covers Apple’s doings.

As developers dive in to all the nerdy goodness this week, what does this mean for your business? Apple has opened up several new business opportunities, and has continued to improve experiences for your developers so they can work more effectively and efficiently.

Monetization

Apple’s business now officially has four legs. You need to consider where your company fits on each of these platforms: iOS, macOS, watchOS and tvOS.

Subscriptions for apps are here! Apple wants to enable stronger and longer-lived apps on devices like the iPad, so they have significantly loosened restrictions, added features, and will be taking a lower percentage of your profits for long-running subscriptions.

Apple Pay is a big deal. Even if you don’t care about Apple device app development, you should probably support Apple Pay on your website, making it easy for those users to give you money. As a colleague said, “I’ll have a strong bias towards sites with Apple Pay. I hate entering my credit card info.”

If you make Mac apps, you now have access to CloudKit and more, without having to go through the Mac App Store. CloudKit and related web services are growing more promising every year.

Maturation and New Growth

Apple promised more extensions and extension points when they were first introduced in iOS 8. They followed up later that year with Apple Watch extensions. This year, we will see several new extension points, which means that you can introduce your apps into ever more places on your customers’ phones.

• You can make messaging apps that live within iMessage.
• You can now make phone extensions for VoIP apps.
• Your app can even begin to supercede Apple’s default apps if it is central to a user’s experience.
• Communications apps will be competing heavily for this new opportunity.

Devs, get familiar with NSUserActivity if you aren’t already!

tvOS continues to gain capabilities; game developers in particular got a lot of new toys—ahem, tools—this year. In addition, single sign-on means greater adoption of various channel apps, as users don’t have to fight through registering each and every app to use them.

Back on iOS, your app can have better notifications, actionable even from the lock screen. Your apps can be prioritized by your customers
on their watches and TVs, even hooking in where previously only default apps could (like within the Contacts app). Your apps can surface in
iMessage and provide custom content and conversations.

With the aforementioned NSUserActivity, you could already appear in searches, both local and across the App Store. Now you can even show up via Siri, and you can make your app directly responsive to customer inquiries and commands. The API is a different model than Amazon’s
Alexa API, and seems to provide more power, but usage is currently restricted to a few key domains.

Competition with Google

Apple did not leave Google’s challenges from I/O unmet. Apple is playing catch-up in areas that Google has excelled in (such as deep learning and context-sensitive interactions), but in other areas such as application performance (with Swift) and user privacy issues, Apple is ahead. Both companies incremented on home automation and message app features this year.

Where to Focus?

• Apple’s users get excited about shiny new experiences, and about incremental improvements in their daily workflows. Apple has delivered on these things this year.

• Pay attention to Apple’s booming international business, particularly in China.

• Notice Apple’s focus on supporting all age groups and ability levels. There are a lot of vibrant markets to be found on their platforms.

• Take a fresh look at Apple technologies. The incremental yearly changes can quickly leave you behind if you’re not watching carefully.

• You should especially look for ways that your company’s services can meet customers throughout the OS, not just within your app. You can provide more value, more entry points, and new ways to interact.

If you’d like some help, I know some people who are very good at integrating the latest technologies in projects. If your developers would like to learn the newest foundational frameworks and techniques, we do that too.

Now if you’ll excuse me, I have a lot of videos to watch.

The post WWDC 2016: Continued Maturation, More Monetization appeared first on Big Nerd Ranch.

Are you in Chicago or Austin? Do you want to get up to speed with Swift and iOS 8? We can give you a huge boost up the learning curve.

After all, we’ve been hard at work digesting Swift since Apple announced it, and we’ve shared a lot of Swift and iOS 8 tips and tricks right here.

But how can you get at that knowledge and experience first hand? Register for one of our courses. There’s still time to catch the final stops of our Swift + iOS 8 Roadshow in Chicago and Austin!

Here is what you will learn:

• Level up to iOS 8: You will add some of the most important iOS 8 technologies to sample apps, with expert guidance at every step. The class starts with Size Classes and Adaptive Controllers, then adds Handoff and Extensions, all the way through CloudKit. Your instructor will add live demos, showing some of the new tricks (and gotchas) in Xcode 6. The code is in Objective-C, so you can rely on your experience and focus only on the new APIs.

• Swift One Day: We take an in-depth tour of Swift with a series of talks that will demonstrate the similarities and differences between Swift and Objective-C; we’ll also highlight the new capabilities that Swift introduces to iOS and Mac development. By the end of the day, you’ll be able to map familiar concepts in Objective-C to Swift, and will have worked with several examples. You’ll be comfortable using Playgrounds, and ready to take off in Swift.

Powering Up

I watched nearly the entire 105 hours of WWDC videos so you don’t have to. The other Nerds and I have been arguing about Swift, writing sample applications, trying out new APIs and learning hard lessons, and we’re ready to share what we’ve learned with you.

Our final stops on the Roadshow are in Chicago, Nov. 6-7, and Austin, Dec. 11-12. Register now to claim your seat.

Can’t make it? We teach a number of excellent iOS classes that will build your expertise. Our Beginning iOS with Swift bootcamp covers the foundations of programming on Apple’s iPhone and iPad platforms using Swift. We have an Objective-C version of the course as well, if you’re not quite ready to shift gears to Swift. We even have Advanced iOS classes, if you’ve shipped some apps and are looking to reach the next level.

The post Power up with our Swift and iOS 8 Roadshow appeared first on Big Nerd Ranch.

Last year, Apple gave us an iOS update that was all about the appearances. The update for iOS 8 takes a deeper look at the workings underneath. Last year was contentious. This year, it seems like Apple gave developers nearly everything we’d been asking for. Almost everyone has something to be delighted about. Plus, we got an entirely new language.

Before we head into Apple’s 2014 announcements, let’s take a last look at some of the rumors.

Big Rumors

Bigger iPhones: These seem almost a certainty, but despite all the leaks and rumors, we know very little about the new features Apple has in store. I think the biggest thing I have to say here (no pun intended—well, maybe a little) is to strengthen my exhortation from last year: The responsive future is here. You need to be using Auto Layout. You need to use size classes and traits. It is increasingly difficult to make a non-universal or partially fixed-orientation app, and that is intentional on Apple’s part. They want you to fully support their customers, who are using any of their devices in any orientation they want.

Wearables (ugh) / iWatch (ugh) / fitness band (ok, I’m biased): Apple likes to come into a market that has already been proven, but not yet taken off. They bring their trademark laser-focused, vertically integrated, highly polished approach to the core features for version one, then grow their product line over the years. I think the introduction of HealthKit, combined with the nascent health market currently led by Jawbone and Fitbit (not to mention Nike’s unceremonious exit) makes a solid case for some kind of watch or band.

However, Apple has once again managed to keep all the important details completely unknown. Whatever this device turns out to be, I hope that Apple has found a way to add a reasonable heart rate monitor to their growing sensor list. In any case, it will be beneficial for developers to know the notification APIs, as well as Extensions, and likely HealthKit and HomeKit.

Nerd Ideas

Apple TV: I haven’t seen many rumors that touch on this. After several years of predictions, I think all the pundits beating the Apple TV drum have either given up on it or retired completely. That’s too bad, because it might just be time for Apple TV to take another step toward a larger role. HomeKit could give this device a new purpose—especially since Apple hasn’t worked out more content deals to put together a truly compelling TV experience.

Siri: As much as I love the thought of a Siri API, I don’t think Apple is in a position to do this yet. How many developers have even touched semantic tagging for text? Still, we can hope for more opportunity to add voice-activated responses where it makes sense. Apple has been all about increasing its context and semantic knowledge of what the user is currently doing, and incorporating sound would offer more clues.

HomeKit and HealthKit: I think Apple will show off something big with both of these frameworks. They will likely be working hard to make sure they take off, and will reward developers who support adoption of both APIs. A lot of companies are vying to be the center of the next big market, which may well be home automation. I wouldn’t be surprised if Apple is pulling out all the stops to own the best home experience. And of course, healthcare is an enormous market.

Language

Swift – 1.0! Of course, the advent of Swift isn’t really a prediction or rumor so much as a major curveball that is causing concern for many developers. There are a number of questions: Should you learn it? How hard will it be to learn? Can you skip Objective-C and go straight to Swift?

Swift is important, and you need to get started on learning it. Different patterns are possible, and in some cases, even required. It won’t be sufficient to try and transfer your Obj-C code straight to Swift. Rather, you will have to design differently.

There is no escaping the fact that iOS developers will be writing and reading Objective-C for some time. You should be writing clean, modern Objective-C.

What Developers Should Do Next

I am excited about Swift, and it is important for our careers as iOS and Cocoa developers. However, I think our most pressing need in the next few months is to make UI adaptable to different sizes. Apple probably has some surprises in store for us, and the more rigid your interface, the more work you will have in front of you.

Regardless of the announcements, Apple has given us the building blocks we need. If you haven’t had time to dive into them, we’ll be talking about several new APIs in upcoming blog posts. Stay tuned for more info about our upcoming live iOS 8 demo. And for a full dose of Swift, the latest development tool tricks and the Cocoa framework, you can always join us in any of our upcoming iOS bootcamps!

The post Get Ready for the Latest Developments from Apple appeared first on Big Nerd Ranch.

I love teaching the Big Nerd Ranch Advanced iOS bootcamp. There is always something new to learn from the students. We figure out a lot of things together during the week, through projects I assign and through questions the students bring with them. But my class last week had an extra surprise for me: mutiny!

The mutineers and me.

Use It Or Lose It

In each of my advanced classes, we do a mini hackathon using what we’ve learned. I tell the students early in the week, but don’t give them the details until the morning of the challenge. We have a small API, and a project outline (much like you might get from an inexperienced consulting client). Teams are free to design the app however they want, within a few constraints.

However, this class included several people who are already quite confident with web services. They were anxious to do more with core graphics and animations. We’d covered those topics we earlier in the week, but we don’t always get the chance to play with them when developing real projects. So one of the students advocated for a new project, one where they would create a drawing app instead.

Mutiny!

Despite my military background, I didn’t summarily execute the mutineers. Instead, I was all for improvisation and a change of plans. Who doesn’t love a good drawing app? (I certainly do. My favorites: Paper, Sketch Club, Procreate.) Besides, I wrote some of the Big Nerd Ranch material on animations, so I was happy to see students embrace transitions.

We agreed on new guidelines. Then the class split into two teams. One team grabbed the whiteboard and held a whispered session, then split up to work on separate parts of their app. The other opted for a pair programming approach, with the whole team gathered around two computers for much of the jam. I love the buzz in the room every time I start one of these events: all the training from the week comes alive in this moment, when there is little time and big goals.

The teams traded a few jabs, but soon settled into a pattern of quiet reading and research, bursts of typing, exclamations of failure or success, then more typing. When I wasn’t busy helping the teams diagnose or debug issues, I decided to make an app of my own. There were a few questions from the week that I’d wanted to answer with code samples, so I picked something that I could use to show off iOS 7 translucency, as well as some extra Auto Layout examples.

Results

In just a few hours, both teams built simple drawing apps and even included some fun effects (one was an accidental feature, but still cool). It was also a powerful learning experience, and a chance to exercise APIs that we don’t always get to play with while building the guts of a modern app.

Team frontline (the front row of the class) had Facebook sharing built in as a last-minute bonus feature. They had the ability to change colors and pen thickness while drawing, and even showed off this sample image:

I should note that we’re developers, not artists. This is great work for an app developed from scratch in a few hours!

Team backrow (the back … well, you’ve figured it out) included a collection view with different animated transitions to and from the drawing view. They had a color mixer (courtesy of Stack Overflow, if I remember right), as well as undo and redo. Perhaps most impressive (if less useful) was the particle emitter you could turn on while drawing. Fun!

As for my own project, I had a remote control on my iPad. It turned on a collection view that was shown on a second screen (an Apple TV, in our case). I then had a translucent panel I could turn on or off that overlaid the collection view.

Your Turn

Big Nerd Ranch’s bootcamps are intense and hard, but they are also a lot of fun. Thanks, class, for a great week. To the rest of you, I hope to see you in a bootcamp soon!

The post Advanced iOS Mutiny appeared first on Big Nerd Ranch.

Have you tried selling an app in Apple’s store? You’ll quickly find out that there’s a lot more to building a successful business than just technical development! As we launch the new version of Roominant, our conference room and meeting scheduling app, I want to share what we’ve learned along the way.

From the very beginning, our business plans sought to answer:

• What problem are we solving?
• How will people find the app?
• How will we get paid?

What problem are we solving?

You know the problems with planning meetings: people often have to walk around to find an empty meeting room at work. If all the rooms are full, there isn’t a good way to find out when one will be available. For those companies that do use calendar resources, often only a few people actually know how to click all the right buttons to see the schedules. And meeting schedulers don’t work if only a few people in an office use them.

Roominant solves these problems by making it easy to schedule meetings. It’s simple to use, and there’s no more juggling multiple applications, several browser tabs and phone calls to get the right people in the right place, at the right time.

We first did a soft launch with Roominant 1.0, so that we could make sure the app stood up to real-world usage—something that can be hard to test for a business or productivity app. While we knew that some users wanted the ability to schedule repeating meetings, we weren’t convinced at first that it was an essential feature. However, in the soft launch, it became obvious that recurring meetings were necessary.

It took us some time to work out the simplest possible design, and to handle the many subtle complications of recurring calendar events. But we added that functionality, and users were happy that they didn’t need to keep booking the same meeting every week. The increased usage encouraged others to use the app as well.

How will people find the app?

Distribution strategy is critical to an app’s success. There’s been a lot of talk about whether in-app purchasing is best, or whether selling apps directly is sustainable. Much of the discussion lacks nuance (big surprise; it’s the internet!).

Indeed, there isn’t one cookie-cutter business strategy that works equally well for Roominant, a business productivity tool, and eClicker, our family of education apps for teachers and students.

Different categories can see very different levels of traffic and downloads. eClicker sees a lot more downloads in education than Roominant does in business. This isn’t due solely to chart position, either: eClicker benefits from teachers who recommend the app, while Roominant hasn’t yet benefited as much from word of mouth. To gain more attention for Roominant, we’ve been experimenting with online advertising and other ways to reach our target market. We also put together a marketing plan for the next few months, which includes this blog post (sneaky, I know!).

To help grab the attention of Apple and Apple users (and to prepare for the future), we added support for Apple’s latest OS release. We haven’t finished with fun iOS 7-related changes, but ditching the iOS 6 look is a good start.

How will we get paid?

We considered several business models for our products. For Roominant customers, an online subscription made the most sense. Businesses can more easily expense these than in-app-purchases. We also didn’t want to limit how many people can use the app, so instead, we started by charging $5/month, per room. After getting some advice from Apple’s helpful marketing and business teams at WWDC, and after debate and research, we switched to offering just a few plans. You can see the plan details at the bottom of roominant.com.

We made the change to our pricing plan for a few reasons. Our target market for this app is small- and medium-sized, fast-growing businesses. These companies don’t have a lot of time to spare, and they don’t want to feel nickel-and-dimed. To an engineer, a pay-per-room  setup seems fair and obvious. But for someone at a small business, that structure requires them to pay more attention to setting up the account than they are interested in. Bucket plans make it easy: pick from a couple of options, and you’re done.

What’s next?

With the core features solidly in place, and plenty of real-world usage, we’ve got a series of great improvements lined up for the next several months. Do you want to hear more about what we’re seeing in the marketplace? Let us know in the comments.

And if you’d like to know more about others’ app-building experiences, check out:

• David Barnard’s Twitter (for example, this tweet and related conversations)
• Realmac Software’s Five Tips to Supercharge Your App Launch
• The Pragmatic Marketing Framework
• Marco Arment’s The App Store Problem is Not Price
• Tapity’s Yep, paid apps are dead

The post Build a Business, Not Just an App: How We Built Roominant appeared first on Big Nerd Ranch.

iOS 7 feels fresh and new, thanks in large part to its zooming, swooping, sliding interface. To me, it feels alive and fresh after several years of everything sliding in from the right. You want to add this yummy goodness to your app, right? Let’s get to it.

There isn’t a set of new built-in transitions here. Instead, Apple has exposed the pieces they use to make transitions happen and allowed us to hook in. We’ll start with a modal presentation from a collection view cell. To follow along in Xcode, check out the demo project Collections from our iOS 7 demos. Notice the collection view controller inside the tab bar controller, at the top of the storyboard. There’s also a modalVC visible, but instead of using a segue, we’re going to add a custom presentation. Take a look in BNRCustomCollectionVC.

Delegate the work

The first thing we need is an animation delegate. We set the delegate on the VC that is going to be presented:

    toVC.transitioningDelegate = self;
    toVC.modalPresentationStyle = UIModalPresentationCustom;

We present the view controller just as before:

    [self presentViewController:toVC animated:YES completion:nil];

To keep it simple, we’ll have the presenting VC conform to UIViewControllerTransitioningDelegate. Now, when we present the VC, it asks its transition delegate for an animator by sending this message:

    - (id)animationControllerForPresentedController:(UIViewController *)presented
    presentingController:(UIViewController *)presenting
    sourceController:(UIViewController *)source

Transitioning: Where the real work happens

Previously, doing our own navigation controller transition was an exercise in frustration. Now, the OS takes care of the wiring at the beginning and end to ensure consistent state, but turns the keys over to us for animation. We’re given a container view and a couple of frames, and are allowed to build a transition of arbitrary complexity. At the end, we need to leave the views in a consistent state. Specifically, we’re responsible for adding, moving, and removing views from the container view. The UIViewControllerAnimatedTransitioning protocol is where we do the work of actually animating the transition.

    - (void)animateTransition:(id)transitionContext

Notice that the system is handing us a transitionContext. You can see from the method declaration that the API doesn’t make any promises about the object itself, only that it conforms to a protocol. I was curious, so I did a bit of caveman debugging:

    NSLog(@"context class is %@", [transitionContext class]);

And saw context class is _UIViewControllerOneToOneTransitionContext. It might be fun to poke around and see if there are other transition context objects too. Just remember that these are private and not guaranteed by the API.

Let’s get back to business and look at the transitioning protocol:

    ...
    Accessing the Transition Objects
    – containerView  required method
    – viewControllerForKey:  required method
    …

Right at the top, we see a couple of curious methods. The context is giving us a place to add and remove views. That’s the container view. We can also get the the View Controllers from both ends of our transition:

    UIView *container = transitionContext.containerView;
    UIViewController *fromVC = [transitionContext viewControllerForKey:UITransitionContextFromViewControllerKey];
    UIViewController *toVC = [transitionContext viewControllerForKey:UITransitionContextToViewControllerKey];

Let’s first set up the end of the transition correctly, without any animation. This bit is tricky (by which I mean it tripped me up at first), so we’re going back to first programmer principles and verify our assumptions at each step of the way. We know from Apple’s WWDC sessions (218 and 226) that we are responsible for inserting the new view into the hierarchy, but we don’t exactly know how to do so. So let’s verify some of the new API (Xcode 5 makes this much easier via breakpoints and the variable inspector, or you can bust out NSLog if you want):

    CGRect initialFromFrame = [transitionContext initialFrameForViewController:fromVC];
    CGRect finalToFrame = [transitionContext finalFrameForViewController:toVC];
    (And so on)

Ah, as the documents say for initialFrameForViewController:

“The rectangle returned by this method represents the size of the corresponding view at the beginning of the transition. For the view controller being presented, the value returned by this method is typically CGRectZero because the view is not yet on screen.”

And indeed, we do see several CGRectZero’s. We also see some unexpectedly large frames. Because we’re doing a custom modal presentation, the context didn’t know what the final frame should be! So it bailed on us, and we have to decide ourselves. Fair enough, I guess. In this case we’ll take the easy way out. The initial frame for our FromViewController looks good, so we use that.

    CGRect endFrame = [transitionContext initialFrameForViewController:fromVC];

We’re just about there. Let’s set up our final view first, without any animation:

    toView.frame = endFrame;

Last, we must tell the context when we’re done, so it can jiggle some more wires in the background to make sure we have a sane view controller and view hierarchy:

    [transitionContext completeTransition: YES];

Try running it. It should work! But without any lovely animations. Fortunately, UIView offers some convenient animation methods for us. Try the new Collections demo project for a zooming, springy animation, then let your imagination loose! Grab a snapshot view, change some properties and animate however you’d like. I am looking forward to seeing what you come up with.

The post Golden Opportunity: Custom Transitions in iOS 7 appeared first on Big Nerd Ranch.

You’ve heard the rumors. iOS 7 is coming.

The initial reactions to the bold new look from Apple were predictable. There were criticisms and, of course, defenses. I chimed in with some positive thoughts during WWDC.

By now, though, nearly everyone has embraced the inevitable. And many developers have had hands-on time with iOS 7, so the initial reaction to mere screenshots has been tempered by actual use.

So, with release imminent, it’s time to offer some suggestions to app developers awaiting iOS 7. But first, a quick debate is in order:

Should i update my app for ios 7?

Point: Apple carefully sets the stage for what is coming next. They introduced auto-layout, then the larger screen. When they double down on a technology, you can bet there’s good reason to pay attention. What if you simply made sure your app isn’t broken on iOS 7? You could get away with it—for about a year. Come iOS 8 though, Apple is going to build on things they introduced this year, leaving you with two years’ of advances to catch up on. And if you don’t update, you might be ceding the market to your hungrier competitors.

Counterpoint: It is challenging to build a business solely on apps. Your business case might not support updating existing apps for Apple’s latest software, and starting a new app may offer more opportunity. Your competitors are weighing the same tradeoffs, and your customers mainly care about something that solves their problems. Customers might not care if you’re late to the party, as long as your software keeps doing what they need.

How do I prepare for ios 7?

If you decide against iOS 7 support, I suppose your work is done. But that’s boring, so let’s assume you decide to support Apple’s latest release. What should you do for existing apps?

• Figure out where your app stands. If you haven’t identified what issues your app will have in the upcoming release, you are already way behind. Get a device with the beta version of iOS 7 and start using it daily so you can get a feel for the new platform and find out where your app doesn’t fit in. Here’s a hint: Look at the colors of both text and standard navigation controls. Check any popup dialogs or overlays. Look carefully at your table views, including around the edges.

• Get your app compatible with Apple’s upcoming software. You can’t ship until Apple does, but you won’t have much time when they announce the release. You should be working on a compatible build shortly, if you aren’t doing so already. In fact, we’re doing this for our own products over the next two weeks. I have good news: Simple compatibility shouldn’t require too much work on your part.

• Identify if there are any big wins for your app from the new APIs and features. What counts as a win for your app? It’s a bit hard to explain, but it could be something that would make a compelling use case. A beautiful, elegant, innovative solution to a real problem. Something novel but familiar. Something that Apple might want to feature, and that your customers might delight in.This is where you decide how much you really want to invest in iOS 7. (Sidenote: I can’t wait until we can tell you about some of the great new tools and APIs!)

• Understand that there will be some glitches along the way. Example: I’m not convinced that removing all indication of tappable regions (i.e., button edges) is best for users, but it may just demand more of us as developers. We may need to spend less time getting assets from our designers, and more time working with our designers to make sure that every element responds as the user expects it to. We may need to get more comfortable with animations and 3D transformations. We may need to push past our comfort levels and explore brave new ideas.

So get ready. It’ll be fun.

The post How App Developers Should Prepare for iOS 7 appeared first on Big Nerd Ranch.

Depending upon your perspective as a developer, you may have been disappointed by the relative lack of developer-focused information in the WWDC 2013 keynote. I was not.

As a developer, I’m working toward the same goal that Apple is: to delight people and improve their lives. So seeing Apple serve our shared audience so well means good things for the near-term future of iOS development. Yesterday’s keynote was a love letter to those users.

Apple made it clear that the Mac platform is alive and well. If you wondered what the next step was in the iOS-ification of OS X, Apple gave the same answer as always: Mac stands on its own merits. Apple has continued to improve the integration between their platforms, but not by pursuing some generic, hand-wavy goal of making them more similar. Each OS will continue to be fully tailored for the devices it is on, each detail intentional to that context. Apple has added even more shared APIs, as well as implemented pieces across lots of shared concepts (notifications, Messages, Maps, AirDrop, etc.). But they’re not sharing the UI or UX wholesale. Each detail of integration is hand-crafted for the platform it lives on.

Improved experiences

Let’s look at just one example. Users can now choose to get their iOS app’s push notifications on their Mac too. Not only can users have an improved experience, but Apple has just extended developers’ reach to customers. This can change how we think about push notifications, when and what to send.

You should start thinking about how you can use this to improve your user’s experience with your app. I don’t know if we have access to also allow custom responses/interaction right within the notifications, but I hope so. Certainly this makes it more compelling to use push notifications where they make sense, and also to consider a companion Mac app.

The moral of the story

The biggest takeaway I got from the WWDC keynote is that you should understand your users’ problem. Not their proposed solution, but the underlying problem. Then you should solve that problem, paying close attention to context and to the details. Don’t be distracted by any other solution you’ve seen before.

Instead, you should strive to design the perfectly fit solution, custom-tailored to the problem. Clear away everything else, and you’ll have something beautiful and powerful. All those things you cleared away? They can come back after you get the first, focused release out there. Iterate. Release. Listen to your customers. And repeat.

The post WWDC 2013 keynote: a love letter to users appeared first on Big Nerd Ranch.