Jeremy Sherman

When a Kotlin non-null property turns up null, you know something has gone subtly, yet terribly, wrong. You trusted that type system, and it let you down. But how? How does the impossible happen? We’ll get to the bottom of this!

React Native apps are native apps. It’s a heck of a coup they’ve pulled off, and while I have my concerns around adopting the technology, “Is it native?” isn’t one of them.

The heart of Continuous Integration is running tests. Whenever a test fails, you want to know why ASAP so you can correct it. Whenever a CI build fails, you want to see that failing test and how it failed.

CircleCI’s Test Summary feature puts this info front-and-center so you can respond directly to the test failure without anything getting in your way. The trick is to feed CircleCI your test info the way it expects.

Big Nerd Ranch esteems code review. We’ve seen it pay off time and again. It is core to our workflow and process. If you want to experience the benefits in your team, here’s what that means in practice for everyone involved.

Codify your functions’ assumptions and promises using Kotlin’s common language of require, check and assert. Jumpstart your debugging with mind-reading failure messages.

Swift protocols can have associated types, which makes them more powerful than Objective-C protocols. It also makes them more complicated. In this post, learn how Swift protocols balance power and complexity. See an example of code that uses a protocol with associated type, then understand why it has to be generic.

The correct answer to “throws or Result?” is a loud BOTH! Learn to make the best of these tools to write clear, maintainable a/sync code through a worked example.

In my last post, you learned how the compiler compiles the source files. This time around, you’ll see how everything is pulled together.

Manual Swift: Understanding the Swift/Objective-C Build Pipeline walked you through the high-level view of how Objective-C gets access to Swift code. Today, we’re going to see what that looks like in practice by examining Xcode build logs.

“Where were you born?” and “What is your mother’s maiden name?” are common security questions, but if you answered honestly, someone can probably get into your account in just a few minutes of half-hearted Facebookery. Password generator to the rescue!

Every build pipeline is an opportunity for leaks and stoppages. Understanding how all the bits come together to make a functioning app helps you to plumb your way through these problems. So… How exactly does Swift and Obj-C all turn into one app?

Swift’s destructuring case statements are cool. But when you don’t care about the associated data at all, go with case .tag: rather than case .tag(_, _):. Here’s why.

If you’re writing Swift apps and not Swift frameworks, do Swift’s access modifiers even matter, or are they just a big distraction?

Apple’s bundled test framework XCTest provides a very limited, general collection of assertions. These get the job done much of the time, but sometimes they’re not the right tool to communicate what you’re actually checking. That’s when it’s useful to know how to write custom assertions that clearly express what you are truly checking for without getting lost in a maze of little this-that-and-that assertions.

Automated testing is the software equivalent of eating your vegetables. You could, you should, but… eh, maybe next time. But then “next time” never comes around. Finding the perfect time to take that first step into testing seems a challenge best avoided, especially when you don’t really know what awaits.

Good news! I’ve found the perfect “next time,” and you’re probably going to have a few opportunities to level up your testing skills today.

UI testing is testing via the user interface. This is nothing new; we do it all the time, manually, by running an app and tap-tapping through its UI. But manually testing for regressions is dull. This is why we have computers, right?

Swift access control enables you to hide the implementation details of your code and to specify a preferred interface through which that code can be accessed and used. It also allows the developer to control the context their types, methods, and other names can be used from.

Comments have been the target of much negative advice—delete them! rewrite to eliminate them!—but little positive advice. Let’s take a look at why they get a bad rap, then examine why the right kind of comments are indispensable.

Internationalization is hard. Here’s how to localize currency amounts in your application.

Thanks to CocoaPods, you can get yourself into license trouble faster than ever before. Learn your BSDs, GPLs and Apaches before you pod install.

I stumbled from the red-eye into the airport shortly after dawn. Bleary-eyed and back on the ground in Atlanta at last, Clojure/West, and its talk of Lisp and browser and JVMs, seemed already a distant memory. My laptop hadn’t left its TSA-friendly bag for the past week. My notebook was full of scribbles and mindmaps. What was a Cocoa programmer like me to make of it all?

One of my coworkers, Scott, recently pointed me towards Jacob Kaplan-Moss’s comments on programming languages and thought. In “Syntactic Sugar”, Jacob addresses the canard that “all Turing complete language differ solely on syntactic sugar.” He first concedes that this is technically true, in terms of reduction to machine instructions and register manipulation. At the same time, he says, this view ignores the important effect qualitative differences in the syntactic structure of different programming languages have on the way we as programmers solve problems. In support of this, he introduces the Sapir-Whorf hypothesis from linguistics, which states that, rather than simply being a vehicle for thought, language in fact determines the limits of what is thinkable. He argues that this applies equally to programming languages, and concludes that “we’ll always be more productive in a language that promotes a type of thought with which we’re already familiar.”