Scott Berrevoets - iOS Development

Localization troubles with Swift PM

2025-09-19T00:00:00-07:00

A few weeks ago we got bit by a piece of Apple magic in its localization workflow when combined with Swift PM. The problem we ran into was that as soon as we moved all our Localizable.strings files to an SPM package, none of the localizations would be picked up anymore and the app would display in English—but only for first-time installations. We followed the documentation guidelines for how to localize an app in an Swift PM environment and have no custom tooling in place, so it was a bit of a headscratcher.

The modern way of adding support for another language/region in Xcode is through the project's Info tab. Simply click the + and add a language and the app now supports localizing in that language.

Adding localizations for any resource is done by clicking the Localize... button in the Attributes inspector. After confirming the language, Xcode creates a new .lproj folder for the selected language and moves the resource into that folder. The end result is the project will have a .lproj folder for each localization as well as the Base.lproj.

This just works. The .lproj folders get copied over to the .app and at runtime the SDK knows how to read and use these folders. Xcode also gives visual confirmation in the Info tab by indicating for how many files it has picked up a localized version per language/region.

Getting started with adding some SPM packages in our app, we moved the .lproj folders into our Localization package at Localization/Sources/Localization/Resources/, which follows the process outlined in the documentation. Locally this seemed to work and we shipped the change, only for QA to report localizations were broken throughout the app.

As it turns out, any .lproj folders in SPM packages aren't considered when determining what localizations are available. At first this was a bit confusing, but it makes sense for two reasons:

Through various layers of abstraction, the system looks up the available localizations using methods on Bundle. Bundle.localizations simply finds all .lproj folders in that bundle. SPM package bundles aren't included in Bundle.main, which is the bundle that's used to determine app-wide localizations.
An SPM package can be localized in different languages than the app that integrates the package, especially if the package is from an external vendor. It could be weird behavior to have the app's selected localization be determined by some SPM package.

Note

There is an Info.plist key that would allow SPM packages to use a different localization than the main app: CFBundleAllowMixedLocalizations. I haven't tried for myself, but setting this to YES allows different localizations for the app and for every package.

When moving all .lproj folders into the SPM package, the app didn't have any localized files left and Xcode indicated as much.

As a result, the app would always default to English. This explained why things were broken but there were still a few questions left.

How come the correct localization was used for returning users?

This issue only happened to users that freshly installed the app. Upon first launch, we store the user's locale in UserDefaults (later giving users the ability to override this manually). Instead of reading strings from Bundle.main we read them from a new Bundle instance specifically scoped to that locale:

Swiftlet defaultLocale = Bundle.main.preferredLocalizations[0]
let userLanguage = UserDefaults.shared.language // e.g. "nl" for Dutch
let path = Bundle.main.pathForResource(language ?? defaultLocale , ofType: "lproj")
let customBundle = Bundle(path: path)

let localized = customBundle.localizedString(forKey: key, value: nil, table: nil)

This setup has some interesting results:

❌ Bundle.main.preferredLocalizations only contains the development default locale en as the main bundle doesn't have any localizations
❌ customBundle.preferredLocalizations only contains the localization it was scoped to
✅ customBundle.localizedString(forKey:value:table:) works as the SPM package's resources still get copied into the main app as a separate bundle
✅ Bundle.module.preferredLocalizations correctly returns all the supported localizations since they're defined in the SPM package
✅ Bundle.module.localizedString(forKey:value:table:) works for the same reason
❌ Bundle.main.localizedString(forKey:value:table:) does not work as the main bundle doesn't have any localizations

For first-time users we would read en as their preferred language through Bundle.main.preferredLocalizations, but for returning users we'd read what language they were using before from UserDefaults.

Conclusion: we should be using Bundle.module.preferredLocalizations instead.

Why was it so difficult to figure this out?

The build cache in Xcode messed with our ability to reproduce the issue. In understanding what commit introduced the problem, we would often switch branches but that didn't invalidate the build cache.

So building any commit before the offending change would copy the .lproj folders into the main app's build cache, and those folders would stay there after checking out and building the offending commit.

At first we thought the issue was only intermittently reproducible, but once we realized the build cache was "polluted" we started to clean it every time. This made it much easier to reproduce but much slower to test due to constantly doing full builds.

What am I supposed to do in a fully modularized app where there are no files to localize in the main app?

In theory, using Bundle.module everywhere would work as highlighted above. However, that's pretty cumbersome and there's a nicer way: CFBundleLocalizations. This is another Info.plist key that lets you explicitly define what localizations the app handles, instead of looking for .lproj folders and implicitly supporting the localizations for the folders Xcode finds. With that key set, Xcode still does look for these folders but now it also considers SPM bundles, fixing the issue.

Finally, there's another way to be explicit about the localizations a project supports: by adding a localization through Xcode's Info tab. This sets the knownRegions value in the Xcode project file, which is not only considered for determining what localizations to consider at build time, but is also used to export and import xliff files.

That would have fixed our issue as well, but I personally prefer to not touch the project file as much as possible and be explicit about what localizations are supported through CFBundleLocalizations.

Re-binding self: the debugger's break(ing) point

2018-08-08T00:00:00-07:00

Update 07-29-2019: The bug described below is fixed in Xcode 11 so this blog post has become irrelevant. I'm leaving it up for historical purposes.

For the Objective-C veterans in the audience, the strong-self-weak-self dance is a practice mastered early on and one that is used very frequently. There are a lot of different incantations, but the most basic one goes something like this:

Objective-C__weak typeof(self) weakSelf = self;
dispatch_group_async(dispatch_get_main_queue(), ^{
    [weakSelf doSomething];
});

Then, if you needed a strong reference to self again inside the block, you'd change it to this:

Objective-C__weak typeof(self) weakSelf = self;
dispatch_group_async(dispatch_get_main_queue(), ^{
    typeof(weakSelf) strongSelf = weakSelf;
    [strongSelf.someOtherObject doSomethingWith:strongSelf];
});

Fortunately, this was much easier on day 1 of Swift when using the [weak self] directive:

SwiftDispatchQueue.main.async { [weak self] in
    if let strongSelf = self {
        strongSelf.someOtherObject.doSomething(with: strongSelf)
    }
}

self is now weak inside the closure, making it an optional. Unwrapping it into strongSelf makes it a non-optional while still avoiding a retain cycle. It doesn't feel very Swifty, but it's not terrible.

More recently, it's become known that Swift supports re-binding self if you wrap it in backticks. That makes for an arguably much nicer syntax:

SwiftDispatchQueue.main.async { [weak self] in
    guard let `self` = self else { return }
    self.someOtherObject.doSomething(with: self)
}

This was long considered, and confirmed to be, a hack that worked due to a bug in the compiler, but since it worked and there weren't plans to remove it, people (including us at Lyft) started treating it as a feature.

However, there is one big caveat: the debugger is entirely hosed for anything you do in that closure. Ever seen an error like this in your Xcode console?

error: warning: <EXPR>:12:9: warning: initialization of variable '$__lldb_error_result' was never used; consider replacing with assignment to '_' or removing it
    var $__lldb_error_result = __lldb_tmp_error
        ~~~~^~~~~~~~~~~~~~~~~~~~

That's because self was re-bound. This is easy to reproduce: create a new Xcode project and add the following snippet to viewDidLoad():

SwiftDispatchQueue.main.async { [weak self] in
    guard let `self` = self else { return }

    let description = self.description
    print(description) // set a breakpoint here
}

When the breakpoint hits, execute (lldb) po description and you'll see the error from above. Note that you're not even using self - merely re-binding it makes the debugger entirely useless inside that scope.

People with way more knowledge of LLDB than I do can explain this in more detail (and have), but the gist is that the debugger doesn't like self's type changing. At the beginning of the closure scope, the debugging context assumes that self's type is Optional, but it is then re-bound to a non-optional, which the debugger doesn't know how to handle. It's actually pretty surprising the compiler supports changing a variable's type at all.

Because of this problem, at Lyft we have decided to eliminate this pattern entirely in our codebases, and instead re-bind self to a variable named this.

If you do continue to use this pattern, note that in a discussion on the Swift forums many people agreed that re-binding self should be supported by the language without the need for backticks. The pull request was merged shortly after and with the release of Swift 4.2 in the fall, you'll be able to use guard let self = self else { return } (at the cost of losing debugging capabilities!)

Using Interface Builder at Lyft

2017-03-06T00:00:00-08:00

Last week people realized that Xcode 8.3 by default uses storyboards in new projects without a checkbox to turn this off. This of course sparked the Interface Builder vs. programmatic UI discussion again, so I wanted to give some insight in our experience using Interface Builder in building the Lyft app. This is not intended as hard "you should also use Interface Builder" advice, but rather to show that IB can work at a larger scale.

First, some stats about the Lyft app:

40 storyboards
100 XIB files
150 view controllers
20 people on the iOS team with occasional outside contributors

With the rewrite of our app we moved to using IB for about 95% of our UI.

The #1 complaint about using Interface Builder for a project with more than 1 developer is that it's impossible to resolve merge conflicts. We never have this problem. Everybody on the team can attest that they have never run into major conflicts they couldn't reasonably resolve.

With that concern out of the way, what about some of the other common criticisms Interface Builder regularly gets?

Improving the workflow

Out of the box, IB has a number of shortcomings that could make working with it more painful than it needs to be. For example, referencing IB objects from code still can only be done with string identifiers. There is also no easy way to embed custom views (designed in IB) in other custom views.

Over time we have improved the workflow for our developers to mitigate some of these shortcomings, either by writing some tools or by writing a little bit of code that can be used project-wide.

storyboarder script

To solve the issue of stringly-typed view controller identifiers, we wrote a script that, just before compiling the app, generates a struct with static properties that exposes all view controllers from the app in a strongly-typed manner. This means that now we can instantiate a view controller in code like this:

Swiftlet viewController = Onboarding.SignUp.instantiate()

Not only is viewController now guaranteed to be there at runtime (if something is wrong in the setup of IB the code won't even compile), but it's also recognized as a SignUpViewController and not a generic UIViewController.

Strongly-typed segues

All our view controllers have a base view controller named ViewController. This base controller implements prepare(for:sender:) like this:

Swiftopen override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    guard let identifier = segue.identifier else {
        return
    }

    let segueName = identifier.firstLetterUpperString()
    let selector = Selector("prepareFor\(segueName):sender:")
    if self.responds(to: selector) {
        self.perform(selector, with: segue.destination, with: sender)
    }
}

This means that a view controller that has a segue to TermsOfServiceViewController can now do this:

Swift@objc
private func prepareForTermsOfService(_ viewController: TermsOfServiceViewController, sender: Any?) {
    viewController.onTermsAccepted = { [weak self] self?.proceed() }
}

We no longer have to implement prepareForSegue and then switch on the segue's identifier or destination controller, but we can implement a separate method for every segue from this view controller instead which makes the code much more readable.

`NibView`

We wrote a NibView class to make it more convenient to embed custom views in other views from IB. We marked this class with @IBDesignable so that it knows to render itself in IB. All we have to do is drag out a regular UIView from the object library and change its class. If there is a XIB with the same name as the class, NibView will automatically instantiate it and render it in the canvas at design time and on screen at runtime.

Every standalone view we design in IB (which effectively means every view in our app) inherits from NibView so we can have an "unlimited" number of nested views show up and see the final result.

Basic `@IBDesignable`s

Since a lot of our views have corner radii and borders, we have created this UIView extension:

Swiftpublic extension UIView {
    @IBInspectable public var cornerRadius: CGFloat {
        get { return self.layer.cornerRadius }
        set { self.layer.cornerRadius = newValue }
    }

    @IBInspectable public var borderWidth: CGFloat {
        get { return self.layer.borderWidth }
        set { self.layer.borderWidth = newValue }
    }

    @IBInspectable public var borderColor: UIColor {
        get { return UIColor(cgColor: self.layer.borderColor!) }
        set { self.layer.borderColor = newValue.cgColor }
    }
}

This lets us easily set these properties on any view (including the ones from UIKit) from Interface Builder.

Linter

We wrote a linter to make sure views are not misplaced, have accessibility labels, trait variations are disabled (since we only officially support portrait mode on iPhone), etc.

ibunfuck

A bug impacting developers that use Interface Builder on both Retina and non-Retina screens (which at Lyft is every developer) has caused us enough grief to write ibunfuck - a tool to remove unwanted changes from IB files.

Color palette

We created a custom color palette with the commonly used colors in our app so it's easy to select these colors when building a new UI. The color names in the palette follow the same names designers use when they give us new designs, so it's easy to refer to and use without having to copy RGB or hex values.

Our approach

In addition to these tools and project-level improvements, we have a number of "rules" around our use of IB to keep things sane:

Do as little as possible in code, do as much as possible in IB. That means fonts, colors, images, and other properties should not be set in code if they don't change at runtime.
Use @IBInspectable on custom views whenever possible.
Create as much Auto Layout constraints in IB as possible. Sometimes this means being clever with how we create constraints so that at runtime we need very little code to manipulate a layout.
If we do need to create constraints in code, we don't use the NSLayoutConstraint (or NSLayoutAnchor) methods directly. Instead we use SnapKit's convenience methods.
We still manually push and present view controllers where possible. Even though we have created some niceties around using segues, it's still easy to accidentally remove one and not find out about it until runtime.
We tend to create a new storyboard when we recognize a common theme in related view controllers. Just as with code, we don't want bloated storyboards with all kinds of unrelated things in there. Most of our storyboards have fewer than 10 scenes.
Our outlets are defined carefully.

Of course, even with these improvements everything is not peaches and cream. There are definitely still problems. New versions of Xcode often change the XML representation which leads to a noisy diff. Some properties can simply not be set in IB meaning we're forced to break our "do everything in IB" rule. Interface Builder has bugs we can't always work around.

However, with our improved infrastructure and the points from above, we are happy with how IB works for us. We don't have to write tons of Auto Layout code (which would be incredibly painful due to the nature of our UIs), get a visual representation of how a view looks without having to run the app after every minor change, and maybe one day we can get our designers make changes to our UI without developers' help.

Keeping the Lyft iOS App Accessible

2017-01-18T00:00:00-08:00

Note

This article was written by me but originally published on the Lyft Engineering Blog.

At Lyft we’re in a unique position: every day we work on an app that affects people in the real, physical world — not just the digital one. This has an especially large impact on visually impaired users, because our app is easier to use than the real world alternatives — navigating a train station or queueing up at a taxi stand. Lyft aims to make a product that is accessible and easy to use for all of our users.

Accessibility at Lyft

If an app uses Apple’s standard controls and UI elements, it will likely already work well with VoiceOver; however, Lyft’s UI deviates enough from standard controls such that we don’t get that benefit out of the box. Another complication is that many portions of the app are controlled by the server, including a lot of the text for buttons and labels. Making these UI elements compatible with VoiceOver often requires tweaking them manually, even if we use native controls.

Since we try to keep all of our UI-related code in Interface Builder, and VoiceOver is just another form of UI, we have written a simple UIView extension that allows us to enable accessibility on most of our UI directly from Interface Builder. In this extension, we add 2 properties to UIView:

accessibilitySources: An IBOutletCollection of UIViews
accessibilityFormat: a simple string that represents the format of the accessibility label, which is subsequently passed to String(format:). Every occurrence of %@ in this string will be replaced with the next element of the accessibilitySources, and [self] will automatically be replaced with the current view’s accessibilityLabel.

We can ctrl + drag UI elements into the accessibilitySources, and by marking accessibilityFormat with @IBInspectable we can specify the string and the sources all from Interface Builder, keeping the code clean and to the point.

For example, we have an accessibility format on the UILabel that displays the selected ride mode:

[self] is replaced by the accessibility label, which for UILabels is the text of the label itself. %@ is replaced by an accessibility source, which we can set up like this:

By disabling the accessibility label for the subtitle, the top label’s accessibility label will read “Selected ride mode: Line. Carpool, 2 people maximum.” without touching any code at all.

Changing the process

As we ramped up our VoiceOver efforts, we wanted to assess whether the changes we made had a meaningful impact to end-users. As developers, we’re too familiar with our own apps to make an honest call about their usability, and when it comes to visual impairment, even a standard usability review could brush over things that would be challenging to a blind or a visually impaired user.

This is why we’re working with a dedicated accessibility expert, himself a native VoiceOver user, to constantly validate our work. All the feedback we’ve been getting from VoiceOver users have further motivated our investment in accessibility. We have optimized VoiceOver in the main flows of our app, and we run weekly regression tests to ensure consistency and stability. Our VoiceOver user also works directly with QA engineers, to let them know what he is looking for and what is missing.

Over the last few months, we have made many improvements in various parts of our app, but also in how seriously we take VoiceOver-related bugs: we block new releases if VoiceOver users experience bugs when going through a ride. All new features are expected to be optimized for VoiceOver from the start, and we are working hard to optimize existing features as well.

We think of accessibility as part of the user interface, just like labels, buttons, and text fields. By having our developers implement support for VoiceOver as part of the initial feature, our visually impaired users will be able to use these features as easily as our regular users.

Silencing NSLog

2016-08-01T00:00:00-07:00

When your app has a lot of third-party dependencies, what often happens is that those libraries log a bunch of things to the Xcode console to help their own debugging. Unfortunately, a lot of these logs are useful only to the developers of the library, but not the developers of apps that integrate the library. For example, they log things like <SomeLibrary> (version 1.2.3) initialized, or <SomeLibrary> started <primary functionality>, sometimes with a long list of parameters or input sources that are irrelevant to you.

Finding your own log statements in a jungle of other logs can then be very difficult and adds to the frustration of not being able to work the debugger as you would like to.

If a library is open source you can suggest a change by removing the log or otherwise make it less obtrusive. However, if your change gets accepted at all, that doesn't solve the immediate problem of being able to debug your own code using the console.

Meet _NSSetLogCStringFunction(). This C function has been around in Foundation for a long time, and while there is some documentation on it, it's still a private method. However, that doesn't mean you can't use it in debug mode when your logs are the most valuable!

In short, this function lets you set a function pointer that can log C strings, which NSLog then uses instead of the normal implementation. You can do this in two ways.

The first one is by adding this to your Objective-C bridging header:

Objective-C#if DEBUG
extern void _NSSetLogCStringFunction(void(*)(const char*, unsigned, BOOL));
#endif

and then use it like this:

Swiftfunc disableNSLog() {
#if DEBUG
    _NSSetLogCStringFunction { message, _, _ in
        // no actual logging, message just gets lost
    }
#endif

If you want to stick to pure Swift, you can do so by adding this to your code somewhere:

Swift@_silgen_name("_NSSetLogCStringFunction")
func setNSLogFunction(_: @convention(c) (UnsafePointer<Int8>, UInt32, ObjCBool) -> Void)

and then use it like this:

Swiftfunc disableNSLog() {
#if DEBUG
    setNSLogFunction { message, _, _ in
        // no actual logging, message just gets lost
    }
#endif
}

Obviously, you can do anything you want inside the closure, including writing to a file, annotating the message with a date/time, passing it to your custom logging library, etc.

One downside of this is that Apple's frameworks use NSLog extensively as well, so in the above case of completely disabling logging, helpful messages get lost as well. You won't be able to use NSLog yourself either anymore, so I suggest you use print() or a custom logging framework that's not NSLog based.

If you're not afraid of doing (more) horrible things in your codebase, you can avoid losing Apple frameworks' messages by parsing the stack trace and looking at the framework that called this function and see if it's something you want to let through:

Swiftfunc disableNSLog() {
#if DEBUG
    _NSSetLogCStringFunction { message, _, _ in
        // message is of type UnsafePointer<Int8> so first see if we can get a
        // normal String from that. Safety first!

        guard let message = String.fromCString(message) else {
            return
        }

        let callStack = NSThread.callStackSymbols()
        let sourceString = callStack[6]
        let separatorSet = NSCharacterSet(charactersInString: " -[]+?.,")
        let stackFrame = sourceString.componentsSeparatedByCharactersInSet(separatorSet)
        let frameworkName = stackFrame[3]

        if frameworkName == "UIKit" || frameworkName == "Foundation" {
            MyCustomLogger.log(message)
        }
    }
#endif
}

This discards all logs, except if they're coming from UIKit or Foundation. The stack trace parsing is by no means safe (its format could change, for example), but since it's wrapped in #if DEBUG directives it won't mess with anything in the App Store build.

Note that static libraries are part of your main app's target, which means you have to filter out logs from your own target to hide those.

You could even go a bit farther and check the message for keywords you like or don't like and make a decision on whether you want to log or not. Keep in mind, though, that any work you do here needs to be fast as you don't always know just how much is being logged.

Outlets: strong! or weak?

2016-03-21T00:00:00-07:00

There are a lot of styles out there when it comes to using Interface Builder outlets in Swift. Even Apple's documentation and sample code isn't always consistent. The most common one, the one Apple uses in its sample code, follows this pattern:

@IBOutlet private weak var someLabel: UILabel!

Let's break this down by keyword:

@IBOutlet makes Interface Builder recognize the outlet
private ensures the outlet isn't accessed outside the current class
weak is used because in most situations the owner of the outlet isn't the same as the owner of the view. For example, a view controller doesn't own someLabel - the view controller's view does.
var because outlets are, by definition, set after initialization
someLabel: UILabel is just an example, this applies to outlets of any kind
!, or the implicitly unwrapped optional, is convenient because you don't have to litter your code with ? and if lets (or just !) everywhere

While at first this seems like a solid approach, at Lyft we quickly realized we weren't fans of this one-size-fits-all way of defining outlets. Instead, the behavior and consequences of the different elements should define the outlet's exact syntax, just like any other variable.

For example, if there is a code path that removes an outlet from its superview, or the outlet is (intentionally) not hooked up in the storyboard, it needs to be an optional because the outlet is not guaranteed to be there when it's accessed.

@IBOutlet private var someLabel: UILabel?

If there is no code path that re-adds the outlet to the view hierarchy, it would also be good to make it weak to not hold on to it unnecessarily when it gets removed:

@IBOutlet private weak var someLabel: UILabel?

This ensures that if the label is removed from the superview, it's not being kept in memory by the strong reference in the view controller. In the most common case, where there is an outlet that will always be there, a strong, implicitly unwrapped optional is appropriate:

@IBOutlet private var someLabel: UILabel!

The outlet isn't weak in case the code ever changes so that there is a code path that removes the view from the view hierarchy but you forget to update the optionality of the property. The object will stay in memory and using it won't crash your app.

These examples all follow 3 simple rules:

! needs a guarantee that the view exists, so always use strong to provide that guarantee
If it's possible the view isn't part of the view hierarchy, use ? and appropriate optional-handling (optional binding/chaining) for safety
If you don't need a view anymore after removing it from the view hierarchy, use weak so it gets removed from memory.

Applying these three rules means you properly use the optional semantics. After all, using ! for a view that may not exist is no different than defining any other property as an implicitly unwrapped optional that may not exist.

@objc class prefixes fixed in Xcode 7 beta 4

2015-07-23T00:00:00-07:00

Back in December I wrote about what I thought was a bug in the Swift compiler that would expose the wrong class name for a Swift class in Objective-C. I then later found out everything worked as intended and I had just misunderstood what @objc() exactly did. Apparently it was never supposed to modify the class name at compile time, but only at runtime.

I'm sure changing the class name just at runtime has its uses, but in my opinion, this would be most helpful if it also affected the compile time name of Objective-C classes. It allows you to namespace your classes in Objective-C using your three-letter prefix, without needing that prefix in Swift because you could namespace by way of modules.

And fortunately, in Xcode 7 beta 4, they have actually modified the @objc() notation so that it does do this. For example, if I have a Swift module that I want others to be able to use in their Objective-C codebase, I could write a class like this:

Swift@objc(SDCMyClass)
class MyClass: NSObject {
    // ...
}

And in MyProject-Swift.h the Objective-C class is defined as:

Objective-CSWIFT_CLASS_NAMED("MyClass")
@interface SDCMyClass : NSObject
- (nonnull instancetype)init OBJC_DESIGNATED_INITIALIZER;
@end

In Swift I can simply use the class as MyClass, but in Objective-C its name is SDCMyClass, which ensures it doesn't collide with other classes named MyClass. Needless to say, I'm very happy they changed this behavior, it makes much more sense now.

The power of UIStackView

2015-06-13T00:00:00-07:00

I was in the audience for "Implementing UI Designs in Interface Builder" at WWDC, where Apple touted UIStackView as a new, better way to lay out your views that in a lot of cases didn't require Auto Layout.

While the presentation looked good, I wasn't quite sure this solved a real problem, as the required constraints weren't too complicated to build in the first pace. However, after I found some time to play around with UIStackView, I'm convinced. This view is very, very powerful and can make building common UIs a lot simpler. Take, for example, a number grid:

[1] [2] [3]
[4] [5] [6]
[7] [8] [9]
    [0]

It would take a while to build this kind of UI in Auto Layout. You would have to create constraints between individual labels, make the labels the same size everywhere, make the spacing between all the labels equal, and avoid hardcoding any numbers to keep the whole thing adaptive. This can be a tedious process in Interface Builder, but imagine you're building this in code. It would take forever, especially after debugging your UI.

With UIStackView, doing all of this takes about 30 seconds. After dragging out all the labels, you just need to embed every row in its own stack view. Set the distribution (in code that's UIStackViewDistribution) for these stack views to "fill equally" (.FillEqually), then embed all four stack views in their own stack view.

The top-level, vertical stack view should get top/leading/trailing/bottom space to its superview (or the layout guides), the 4 horizontal stack views an "equal width" constraint to their superview. Finally, center the text of the individual labels (you can select all labels at once and do this with 1 action). Done - that's it.

But it gets better. Say you want to conditionally show or hide the 0 label at the bottom. I don't know why you would want that, but just go with it 😛

To do this, all you have to is toggle the hidden property of that label. The containing stack view will automatically reposition its subviews. If you put that line in an animation block, it will reposition its subviews in an animated fashion.

That last part is a very welcome feature for developers that work with a lot of dynamic views. Instead of creating redundant constraints with lower priorities, removing views from their view hierarchies, and re-adding the view and all its constraints if the new views needs to be re-shown, you can simply toggle hidden instead.

As more people get their hands on UIStackView I'm sure it will show off more of its powers, but needless to say I'm sold. Too bad I can't use it for a while...

@objc creates a wrong class name in Objective-C

2014-12-15T00:00:00-08:00

A few months ago, I decided I'd get started porting SDCAlertView to Swift, but I was only a few minutes in until I ran into a problem I had no idea how to solve: I couldn't get my class names right in both Swift and Objective-C. Even though there are copious amounts of documentation covering the interoperability of Swift and Objective-C, somehow I couldn't get it to work and I brushed it off as me being stupid.

Tonight I tried again, and after some more research it turned out that the behavior I saw was actually a bug in the compiler! I'm surprised that the latest Xcode version is 6.1.1 and that apparently not enough people have run into this problem for Apple to make it a priority.

The bug can easily be reproduced by creating an Objective-C project in Xcode, and then adding the following Swift class:

Swiftimport UIKit

@objc(SDCMyLabel)
class MyLabel: UILabel {
}

You would expect that, once you import MyProject-Swift.h in your Objective-C class, you could instantiate a class named SDCMyLabel. However, instead, you can only instantiate a class named MyLabel.

I found this very recent Stack Overflow question which pretty much asks the same thing. "milos" gives a great answer by explaining the observed behavior in Xcode 6.0.1, and the expected behavior according to the WWDC session video.

After reading the answer and watching the relevant parts of the vide, I slightly changed my previously-drawn conclusion from "I'm stupid" to "Xcode's stupid" and filed rdar://19261044. If you're running into the same problem, please duplicate and cross your fingers the engineers at the fruit company will fix it soon.

Dev-only iPhones

2014-10-20T00:00:00-07:00

With today's release of iOS 8.1, most app developers are looking at 4 significantly different iOS versions they will be supporting: iOS 7.0, iOS 7.1, iOS 8.0, and iOS 8.1. Factoring in the number of devices (iPhone 4S, iPhone 5, iPhone 5s, iPhone 6, and iPhone 6 Plus) that run these OS versions, there is a grand total of 16 different configurations. That's without even counting the iPhone 5c, which is internally pretty much the same as the 5, or the rumored iOS 8.2 and iOS 8.3 updates.

Assuming an average off-contract price of $400 for these models, that means you're looking at $6,400 for 1 set of iPhones used for development. Creating a universal app? Your total will now exceed $10,000.

So now you have these 16 phones that will in most cases be used for testing maybe a handful of apps, that have chips and software functionality in them that will be used very little (if at all), and will most of the time just sit in some desk drawer with a dead battery. I could think of better ways to spend money.

This problem could have a very simple solution: dev-only iPhones. Remove or disable the cellular chip (you can simulate cellular networks using the Network Link Conditioner), give it an 8GB storage chip, remove apps such as Weather, Stocks, Calculator, Clock, etc., disable the App Store for all but the developer's own apps, allow any supported iOS version to be installed using Xcode, and sell at-cost, but only to developers in the iOS Developer Program.

By disabling cellular and dumbing the OS down to only include parts that developers can interact with, it becomes pretty useless for people who are just trying to look for a sweet deal on an iPhone/iPod touch. The win for developers is that they only need 1 of each device, but they're also cheaper.

You could even take it a step further and set memory, CPU and screen size limits (meaning only use 4" of the available 5.5"), allowing you to simulate an iPhone 5s on an iPhone 6 Plus. Now developers only need to buy the iPhone 6 Plus to be mostly covered, though I'd still recommend also getting an iPhone 5 or iPhone 5c for 32-bit devices.

I may be way off course here due to technical implications or limitations that I'm not aware of. There are also still cases in which you'd need an actual device on the actual software as consumers use it. Developers don't always need to test against every iOS version on every supported iOS device. But for developers who do and don't want to spend the money on all these different devices, a dev-only iPhone may be exactly what they need.

Update (February 2026)

This was never really realistic for a variety of reasons, but I still think the cost of entry for iOS development is unnecessarily high. The simulator is still pretty good and has gotten much better over the years, but entire classes of apps can't be simulated properly. The number of software updates, device matrix, and hardware/software capabilities make dev-only iPhones also not really scalable.

The Apple enthusiasts still get new phones regularly enough that used phones have become cheap enough to cover a bit more of the testing matrix too.

UIMenuController and the responder chain

2014-09-15T00:00:00-07:00

The responder chain is a very important paradigm in the world of iOS development, and not terribly hard to understand. Dozens of articles have been written about it, and with some examples, the concept of finding a responder to a certain event by traversing a chain of potential responders is fairly straight-forward.

But today it completely threw me off. The goal was very simple and has been done many times before: showing a label whose text can be copied to the clipboard. Having never worked with UIMenuController, I fired up Google and of course found an excellent NSHipster article near the top.

I did as the article said. I created my UILabel subclass (only accepting copy: as an action it can perform), added my gesture recognizer, and configured and showed the UIMenuController. It worked, but instead of only showing the Copy menu item, it also showed the Select All item.

Well, that's weird. I implemented canPerformAction:withSender: like this:

Objective-C- (BOOL)canPerformAction:(SEL)action withSender:(id)sender {
    return action == @selector(copy:);
}

I made sure that this method really only returned YES for the Copy item, proceeded to explicitly return NO for selectAll: and, when that failed as well, even changed the implementation of this method to just return NO for any item. But Select All doesn't take NO for an answer, and it stubbornly showed up anyway! I was baffled and could not get rid of this Select All item.

I did some research, and learned that UIMenuController uses the responder chain to figure out what items to show. Furthermore, the documentation for canPerformAction:withSender: read:

This default implementation of this method returns YES if the responder class implements the requested action and calls the next responder if it does not.

That would explain the problem, if it weren't for the fact that Select All was the only other item that showed. Cut, Paste, Select, etc. did not. What was so special about Select All that no matter what I did, it always decided to make an unwanted appearance?

Finally I saw it. One of the last methods of the view controller that created this label had a method named, you guessed it, selectAll:. I didn't immediately connect the dots, but at least renaming that method to selectAllContacts: (which was a better name for that method anyway) got rid of Select All.

But how? I returned NO from my label's canPerformAction:withSender: for all actions except copy:. This means that for all other actions (see the informal UIResponderStandardEditActions), the next responder in the chain would be called. And (if necessary) the next, and the next.

At some point, my view controller, which participates in the responder chain, became the first responder and returned YES for the selectAll: action, simply because the method was implemented and part of UIResponderStandardEditActions.

So if implementing a method in that protocol is all that's needed to show the corresponding menu item, that would mean that implementing canPerformAction:withSender: in my UILabel subclass was unnecessary. I removed the method altogether and sure enough, the Copy menu item was still there. Problem solved.

Xcode & Objective-C Oddities

2014-08-10T00:00:00-07:00

Any developer that has worked with Xcode to write a little more than just "Hello, World" knows that Xcode and Objective-C have their quirks. Chances are you have heard of @TextFromXcode, the Twitter handle that portrays Xcode as a high school bully in fake text conversations like this:

But it's not always Xcode that makes Apple platform developers sometimes frown and sigh. Sometimes it's the developers themselves, sometimes it's the documentation, and sometimes a hidden gem from within Apple frameworks makes an appearance. I've compiled a short list of things I've encountered. Because it's Sunday and I didn't have anything better to do.

`UIGobblerGestureRecognizer`

Say what? A "gobbler" recognizer? Does it recognize when the user imitates a turkey? Well, maybe, but according to BJ Homer, it is used to avoid recognition of a gesture while animations are in progress. Ah of course! Now the name "gobbler" makes perfect sense! 😶

`UITapAndAHalfRecognizer`

Speaking of gesture recognizers, there's another remarkable one that lives in the private section of UIKit: UITapAndAHalfRecognizer. This is a private subclass of UIGestureRecognizer that records "a tap and a half".

So what does that mean? Does it detect whether the user goes in for a second tap, but never actually touches the screen? Or does the user touch the screen ever so slightly that the second tap can hardly be considered a complete tap? Nope! This recognizer fires when a second tap stays on the screen. Not sure for what functionality Apple needs this, but it's been around since at least iOS 4, so it probably has a purpose.

Naming is hard

There are only two hard things in Computer Science: cache invalidation and naming things.
- Phil Karlton

Naming is hard, but Objective-C developers always say that verbosity is one of Objective-C's strengths because its naming conventions are self-documenting. Normally I'd agree, but in this case, I think Apple may want to consider a different name.

HMCharacteristicValueLockMechanismLastKnownActionUnsecuredUsingPhysicalMovementExterior is a brand new constant in iOS 8 and has got to be one of the longest constants that's available in iOS. Try saying it without taking a breath in the middle.

I found it in the iOS 8 API diffs, but it did make me wonder. What is the longest Objective-C method available in Cocoa Touch? Well, a quick Google search led to a blog post by Stuart Sharpe, who used the Objective-C runtime to generate a list of methods in the iOS 7 SDK.

Turns out, the longest method in the iOS 7 SDK is

Objective-C+[CUIShapeEffectStack shapeEffectSingleBlurFrom:
                               withInteriorFill:
                                         offset:
                                       blurSize:
                                   innerGlowRed:
                                 innerGlowGreen:
                                  innerGlowBlue:
                               innerGlowOpacity:
                                 innerShadowRed:
                               innerShadowGreen:
                                innerShadowBlue:
                             innerShadowOpacity:
                                   outerGlowRed:
                                 outerGlowGreen:
                                  outerGlowBlue:
                               outerGlowOpacity:
                                 outerShadowRed:
                               outerShadowGreen:
                                outerShadowBlue:
                             outerShadowOpacity:
                            hasInsideShadowBlur:
                           hasOutsideShadowBlur:]

Unless iOS 8 introduces a longer method name, this one takes the cake with 22 arguments and 352 characters. If you have Xcode configured to line-break at 80 characters (yes, some people still do that), this method signature alone, without any arguments, takes up 5 lines.

Another beauty of a method lives in Core Animation and its method signature is

Objective-C- [CAMediaTimingFunction functionWithControlPoints::::]

::::? Is that even valid syntax? Yes, and you call the method like this:

Objective-C[CAMediaTimingFunction functionWithControlPoints:0.25 :.50 :0 :1.0];

Was an array really too much to ask...?

`[NSDate nilDate]`

This one has made the rounds throughout the developer community before, but I'm adding it here in case you haven't seen it yet. Try running the following code:

Objective-CNSCalendar *calendar = [NSCalendar currentCalendar];
[calendar components:NSCalendarUnitYear fromDate:nil toDate:[NSDate date] options:0];

In the console log, you'll find the following output:

*** -[__NSCFCalendar components:fromDate:toDate:options:]: fromDate cannot be nil
I mean really, what do you think that operation is supposed to mean with a nil fromDate?
An exception has been avoided for now.
A few of these errors are going to be reported with this complaint, then further violations will simply silently do whatever random thing results from the nil.

Either a grumpy Apple developer woke up at the wrong side of the bed or has a great sense of humor. In any case, I wouldn't mind if more sarcastic warnings started popping up in Xcode's console.

Defying the Uncertainty Principle in iOS

[I]n 1927, Werner Heisenberg stated that the more precisely the position of some particle is determined, the less precisely its momentum can be known, and vice versa.
Wikipedia

If that's true, and it's fairly safe to assume that it is, I'd avoid using -[CLLocation speed] for apps like radar detectors. I wonder if we're ever going to get a -[CLSpeed location] method, which has a more accurate speed and a less accurate location.

Xcode at it again

Lastly, the following is a screenshot I personally took at work that completely baffled me.

This would not go away, even after cleaning the build folder and rebuilding. In the end I resolved the problem by running

Bash$ git stash
$ git reset --hard HEAD

Then, after a clean build and git stash pop the errors finally went away...

That's just a few things I've found while working with Xcode and Objective-C over the years. If you have more, please share!

Objective-C prefixes: a thing of the past?

2014-07-25T00:00:00-07:00

This past week, there was, again, a lot to do about Objective-C and prefixing. To most iOS developers, the story sounds familiar: one camp is strongly in favor, another camps is strongly against, and a third camp couldn't really care less.

Unless I'm unaware of any other platforms where the discussion was also a hot topic, this time I was at least a little responsible for instigating a debate that will never see a clear winner, with the following tweet:

@bobmccune @invalidname Also no option to enter class prefix anymore, even for Objective-C projects
— Scott Berrevoets (@ScottBerrevoets) July 23, 2014

Let's first clear up that Swift doesn't need to have class prefixes, because it has built-in support for namespacing through modules. From what I read, earlier Xcode 6/Swift betas did not have module support, but at least we know it's coming before 1.0 hits.

However, this doesn't solve any of the problems Objective-C has, and so it was surprising to see this field was removed when creating a new Objective-C project. You can still set this prefix per project after you create it, but since most Xcode templates create source files for you, those files will be created without a prefix.

I noticed the lack of this option, as well as the lack of a file template for Objective-C categories, back in beta 2 and immediately filed two bugs. The missing file template is as of this writing still open, but the class prefix got closed a few days later. Normally, radars aren't known for their wealth of information related to the issue the radar was filed for, but Apple Engineering made an exception this time.

After much deliberation, engineering has removed this feature.

This was removed intentionally. We are no longer encouraging the use of prefixes for app code, and for frameworks, you can create a prefix in the Project Inspector after creating the project.

Okay, so no more prefixes for app code. Didn't see that coming. Does Apple now encourage developers to start making extensive use of frameworks?

No. If you want to use a prefix, you can set one in the project inspector. Especially for frameworks, this is easy since the template creates no source files that should be prefixed. If you really want to prefix the classes in your main app binary, you might need to rename the few that are created initially, but the recommendation is generally that frameworks should use prefixes (in Obj-C, not in Swift) to avoid namespace issues, and apps generally don't need to.

The key part here is in the last few words: "don't need to".

Third-party libraries, especially frameworks that don't ship with the source code, need a prefix, because the chances of naming collisions with other code or, even worse, other libraries is significant. Users of the libraries can't (and even if they can, are likely not willing to) change the name of your classes because they collide with some other library's code.

"App code" on the other hand, is very unique to one particular app. It contains the UI and some of the business logic that puts your app together. Most view controllers, for example, are app code. App code is not likely to be reused, because it's very specific in what it does and is therefore unlikely to collide with other classes (assuming you name your classes well). If you think "well, this functionality may be reused in some other project", it's a great candidate for a framework!

I was always a big fan of the class prefixes, and while it was sometimes hard to come up with what prefix to use, I've come to actually like how they look, too. Classes that don't have a prefix feel like they're missing something. However, the guideline of "prefix frameworks, not app code" does make sense, so I will start using that from now on as well.