Archive for the ‘Development’ Category

How To: Finding your iTunes Connect Vendor ID number

Apple sent me an email:

Apple was recently notified that your bank account information has been manually corrected by the processing bank for iTunes payments to vendor [my personal vendor id number]. Unfortunately Apple cannot continue processing payments with the current banking details provided in iTunes Connect. To avoid unnecessary payment delays or returns, please log into iTunes Connect and provide the correct account information in Agreements, Tax, and Banking. For instructions on how to update banking, see ‘How do I add or edit a new bank account?’ in iTunes Connect Resources and Help. After the banking changes have been entered in our systems, payments will resume.

Oh shiny.

I pull out my latest statement and off I go to update my details. Here’s my problem. I don’t know which vendor account Apple is referring to. Like many developers, I deal use multiple iTC accounts. When I log into each one, I cannot find the vendor ID. Argh.

To save you lots of time, do this:

  • Log into any iTC account.
  • Manually navigate to https://reportingitc2.apple.com/reports.html
  • The vendor ID is listed next to your name. You should not have to re-authenticate when hopping from iTC to this page.

This helped me figure out which affected account was being referred to in the email and was able to update my info.

To update a direct deposit routing number, you need to hop into Agreements, Tax, and Banking. Click on the Bank Info > View button. You cannot edit the routing number in your existing Current Bank Account. Instead you need to Add Bank Account with the same details and the new routing number and then select that as your new account. Once you do it will take 24-48 hours for the change to go through and you will not be able to make further edits during that time.

The opinionated Tao of Optional Mappage

Given these two functions:

  • p(x) -> Void executes side effects in its body.
  • f(x) -> y produces a transformed value

Prefer:

  • if let x = x { p(x) } to x.map({ p(x) }) when executing a function for its side effects.
  • return x.map({ f(x) }) when returning a transformed value based on an optional.

You may think of map as inherently functional but x.map({ p(x) }) does not warn on unused result. In this case, the return type is Void. If  you assign the value, the compiler warns of the unexpected ()? return type.

I’ve often thought that forEach would be a better approach for procedural calls than map when working with optionals. This is based on the often disputed notion that optionals are like tiny collections with either zero or one members.

This is not how optionals are conceived, and the swift team has mentioned so on several occasions. Dmitri Gribenko wrote:

My argument is that map on collections and on optionals are two completely different things.  They unify on a level that does not exist in Swift (higher-kinded types).  We could name Optional.map() differently, and that would be a separate decision from renaming Collection.map(), but we used the name `map` primarily because of precedent, not because there is a HKT notion of these two operations
being the same…

I can’t say that it is not valid to think about an Optional as a tiny collection, but as implemented in Swift, .map() does objectively behave differently…Optional is a result of a computation that can fail.  .map() allows you to chain more things onto a computation if it succeeded, and do nothing if it failed already.

Until such things are resolved, you might consider replacing procedural calls on optionals with a custom forEach implementation:

extension Optional {
    public func forEach(perform action: (Wrapped) -> Void) {
        self.map(action)
    }
}

let x: String? = "Hello"
x.forEach { print($0) }

I think it better presents the notion that you’re not returning a value from mapping but executing a procedure for its side effects on any wrapped value within an optional.

What do you think?

Swift Documentation: Life Pro Tips

Swift Life Pro Tip: If you’re working with a Swiftized version of what was originally a Cocoa /Touch Foundation type, always check the header file just in case there’s more info that’s missing from the Swift version.

To take an example from a conversation today, consider the following code. What happens if you pass nil rather than an actual locale?

let string = "istanbul"
print(string.uppercased()) // ISTANBUL

import Foundation
let locale = Locale(identifier: "tr")
print(string.uppercased(with: locale)) 
// İSTANBUL, with the dot over the I

print(string.uppercased(with: nil))  // ??

Swift

Cocoa/Touch Foundation

Looking up Headers

The header files use traditional comments that I assume aren’t picked up by automatic document generation:

  1. Look up declaration for the NS version of a Swift Foundation class, such as NSString vs String.
  2. Click Objective-C and away from Swift.
  3. De-swiftize the `uppercase(with:)` declaration. In this case, the ObjC declaration is, `- (NSString *)uppercaseStringWithLocale:(NSLocale *)locale;`
  4. Find the header file (I have System/Library/Framework on perma-symbolic link from my home folder) and look there for NSString.h.
  5. Look at the original declaration in the header file:
/* The following methods perform localized case mappings based on the locale specified. Passing nil indicates the canonical mapping. For the user preference locale setting, specify +[NSLocale currentLocale].
*/

Hope this helps someone.

Tangentially, Zev Eisenberg reminds me to link to the Swift String Manifesto, which addresses a bit of this issue.

Got other Swift Life Pro Tips? Drop a comment, a tweet, or an email. Thanks!

Stupid Swift Tricks: Sleepsort

Was chatting today about the freestanding old style partition function and the new one that’s part of SE-0120. One thing led to another and I was writing sleepsort in a playground.

Several interesting things.

  • To Linuxize, so I could run this in the IBM sandbox, I had to import Dispatch, use CLOCKS_PER_SEC, and use rand() (and no, I didn’t even bother seeding it, I just wanted the code to run).
  • Bad things™ happened without the access queue, as the quality of service was not quite as good as I initially thought.
  • I had to tweak the delay time between the Linux and playground implementations a bit so closures didn’t fire unexpectedly and wouldn’t run over each other. Maybe I should have gone with a different policy than default for my primary dispatch method?

As always, if you have improvements or suggestions, fire ’em away.

Bridging Swift Generics with Darwin Calls

Seth Willits was working on an interpolation protocol that would allow conforming constructs to interpolate from one value to another, regardless of their underlying types. It needed to work for CGFloat as well as Double, and be decomposable and useful for CGPoint and CGRect as well as any custom Swift Polygon struct.

This created interesting challenges, as some of the most fundamental animation curves use exponentiation, which is not built into the Swift standard library. So I turned to pow, which is only defined for float and double:

public func powf(_: Float, _: Float) -> Float
public func pow(_: Double, _: Double) -> Double

In the past, I’ve created horrible bridging solution that permits migration from most floating point values to double. It’s not beautiful but I decided to pull it out from my toolkit and introduce it to this problem.

What I did was to build an extension on BinaryFloatingPoint that returned an interpolated value along a styled curve. My hack let me create a single interpolate method that applied across floating-point. I bridged to Double to use the Darwin pow function:

There’s an interesting CGFloat bug in play here, where the value history does not display as a graph but the numbers are right and work properly during animation.

Here’s the code. Shout out your improvements and alternatives.

Style this: Image Name

The Code

This episode of “Style this” stars code from Brandon Trussell, who asked to “make this Swiftier”:

// Get the image name
var imageName: String? = nil
if let collection = songs {
    for song in collection {
        if (song.cover_url != "") {
            imageName = song.cover_url
            break;
        }
    }
}

The Issues

So what’s wrong with this code? Here’s a quick overview.

Naming. There’s a mismatch here between imageName and cover_url. Is it a name? A URL? What? Turns out that this is a string, such as “ExperienceHendrix.jpg”. Both the cover_url property and the local imageName variable should reflect this better. And they do so without unsightly snake case naming. Fix: Rejigger the names to reflect that these are local file names and use standard Swift camelCase naming.

Parenthesized conditions and semicolons. The parentheses in the empty string check and the semicolon after the break are holdovers from Objective-C. Train yourself away from these reflexive habits. They’ll compile in Swift but they’re unnecessary. Fix: Ditch the parens and semicolon.

Comparing against an empty string. It’s bad form to test against an empty string or check if a collection’s count is zero. Prefer using the isEmpty property, which offers better semantics and performance. Fix: Refactor the empty string check.

Using an empty string instead of an optional. There’s a design flaw here in that this model should really use an optional String instead of an empty string to begin with (thanks Dave DeLong), but that’s another fish to fry that this redesign won’t address. In Swift, an optional represents the absence of a value in a way that an empty string does not convey.

Using the wrong type. The right type for a local file asset should be a file URL, not a string. Again, this redesign won’t address that.

Complex iteration: When you’re looking for the first member of a collection that satisfies a predicate, go functional. The Standard Library offers many ways to convert iteration that uses extra state (in this case the imageName variable) into a cleaner function call. Fix: use first(where:), which you get for free as part of the standard library.

Unnecessary conditional binding: If you’re going to use an optional value exactly once to extract some value and you can transform that binding into a function call, consider optional chaining instead. Fix: use songs? with a function.

The Refactor

Here’s what a refactored and Swiftier version of Brandon’s code might look like. This rewrite returns an optional string. That string contains the first non-empty coverImageFileName property within the songs collection. I think it’s a simpler approach with better naming and tighter code.

// Extract the file name for the first cover image
// found within the optional `songs` collection
let firstCoverImageFileName: String? = songs?
    .first(where: { !$0.coverImageFileName.isEmpty })?
    .coverImageFileName

Note that both calls in the functional chain require question marks. The first one, after songs, reflects that songs is an optional collection. The second, after the first(where:) call supports potentially nil searches (for example, where a collection has no covers).

This code won’t compile without that second question mark. Swift will, however, warn you at compile time that you’re attempting to make a call on an optional type if you omit it.

Soroush Khanlou, Dave DeLong, and Tim Vermeulen put their heads together for a slightly different approach:

let firstCoverImageFileName2: String? = songs?
    .lazy.flatMap({ $0.coverImageFileName })
    .first(where: { !$0.isEmpty })

Using a lazy flatMap may be a bit harder to wrap your head around, but it’s beautiful in that it pulls each image name, and then returns the first non-empty one, ensuring that you don’t create any intermediate storage.

Tim further adds:

extension Sequence {
    func firstResult<T>(_ transform: (Iterator.Element) -> T?) -> T? {
        for element in self {
            if let result = transform(element) {
                return result
            }
        }

        return nil
    }
}
let firstCoverImageFileName: String? = songs?
    .firstResult { 
        $0.coverImageFileName.isEmpty ? nil : $0.coverImageFileName }

and, as an alternative:

extension Optional {
    init(_ value: Wrapped, where predicate: (Wrapped) -> Bool) {
        self = predicate(value) ? value : nil
    }
}

songs?.firstResult { 
    Optional($0.coverImageFileName, where: { !$0.isEmpty }) 
}

Also, I threw together this, which I’m not sure if I hate or not:

extension Sequence {
    func first<T>(
        apply transform: @escaping (Iterator.Element) -> T?, 
        where predicate: @escaping (T) -> Bool) -> T? {
        return self.lazy
            .flatMap({ transform($0) })
            .first(where: predicate)
     }
}

songs?.first(apply: { song in song.coverImageFileName }, 
    where: { name in !name.isEmpty } )

Swift Style

Agree with these refactoring recommendations? Disagree? Would you redesign this differently? Drop a comment or send a tweet. Swift Style is now available to order as a paper book, an ebook, and a paper/ebook bundle.

Tip of the hat to Mike Ash who was also offering feedback. Thanks to Soroush Khanlou, Dave DeLong, Tim Vermeulen, Zev Eisenberg

Dear Erica: Working synchronously with asynchronous calls

How do I wait for an asynchronous closure? I am making an async network request and getting its results in a closure but somewhere I have to know that my request has been completed so I can get the values

You can approach this several ways. The easiest is to post a notification or call a delegate method from your completion handler. Make sure you stay aware of the thread you’re working with. You may need to dispatch to the main thread to perform your delegation, callbacks, or notifications.

When you’re working with several tasks that must finish before moving forward, use a dispatch group to keep count until they’re all done, and then send your update information.

If you truly need to stop execution until the request returns (and this is usually a bad thing with the possible exception of synchronous execution in playgrounds), you can use a run loop to stop things until your asynchronous call returns control.  This breaks a lot of best practice rules. It  can be mighty handy when you don’t want to start building lots of helper classes in a quick demo or proof of concept, where the emphasis is on procedural tasks.

Musings on Partial Application

I tend to use the phrases currying and partial application interchangeably. The Intertubes tell me, however,  that currying is limited to 1-arity stages. Arity refers to the number of a function’s arguments and should not be confused with Arrietty from the Borrowers.

Swift is tuple friendly and given tuples, I mentallly stretch the “same thingity” thinking to partial application as currying so long as the tuples reflect an underlying coherent structure. This is probably wrong and evil, but what are you going to do?

Swift officially removed currying™ in Swift 3 but it didn’t remove partial application, the ability to create a function of smaller arity, where some parameters have already been assigned.

Consider the following function. It accepts a low and a high bound and clamps a value inclusively within those bounds. You must pass the low and high values each time you call the function:

func clamp<T: Integer>(min minValue: T, 
    max maxValue: T, _ value: T) -> T {
    return min(max(value, minValue), maxValue)
}

clamp(min: 2, max: 5, 25) // 5
clamp(min: 2, max: 5, -25) // 2
clamp(min: 2, max: 5, 3) // 3

Partial application enables you to break down the function, to create a reusable component specific to some pair of bounds:

func clampRange<T: Integer>(min minValue: T, max maxValue: T)
    -> (_ value: T) -> T {
    return { value in
        min(max(value, minValue), maxValue)
    }
}

// For example
let clamp25 = clampRange(min: 2, max: 5)
clamp25(25) // 5
clamp25(-25) // 2
clamp25(3) // 3

Swift does not use argument labels in function types, which is why I do not use a label for the value argument. If I were not thinking in terms of partial application, I might have added a value label for the 3-argument version.

As Mike Ash pointed out today, another way to partially apply a function is to create a separate function or closure. Use positional arguments to populate the missing parameters:

let clamp25 = { clamp(min: 2, max: 5, $0) }
clamp25(25) // 5
clamp25(-25) // 2
clamp25(3) //3

It’s a lot cleaner and shorter than the standard approach and, if you like, you can use closure signatures to eliminate anonymous parameters:

let clamp25 = { value in clamp(min: 2, max: 5, value) }

Note that the calls won’t change. Function types cannot have argument labels.

Defaulted parameters kind of look like a partial application, but they really aren’t. You must decide a priori what your defaulted values are, which limits the way you reduce functional arity to a single fixed set of fallback values:

func clamp<T: Integer>(min minValue: T = 2, 
    max maxValue: T = 5, _ value: T) -> T {
    return min(max(value, minValue), maxValue)
}

clamp(25) // 5
clamp(-25) // 2
clamp(3) // 3

I find myself using partial application a lot in graphics, particularly when applying perspective or layout transformations. Until now, I’ve been using the standard -> -> -> approach. Today Mike has made me think that maybe I should consider closures instead, where I’ve partially applied the function to some parameters.

Dear Erica: Creating a conditional assignment operator

Manuel Carlos asks whether it’s possible to create an operator that executes a closure and returns a value based on whether a condition is true. Here’s his initial attempt:

My recommendation? Skip the operator and just use an if-statement:

if true { v = 100 } // vs v = 100 <-? true
if false { v = 100 } // vs v = 100 <-? false
if true { print("hello") } // vs print("hello") <-? true
if false { print("hello") } // vs print("hello") <-? false

Yes, it’s simple, but simple gets the job done without straining or extending the language. There’s little gained in building a more complex logic-driven assignment for this use case. Placing a truth statement to the right of each action inverts the normal way people read code, burns an operator, abuses auto-closure, and unnecessarily complicates what should be a straightforward operation.

That’s not to say this isn’t an interesting design space. Although Swift does not support custom ternary operators at this time, it may do so at some point in the future. Even then, I’d be cautious about replacing if-then control with such complex solutions.

Apple’s recommendations on auto-closure are:

  • Use autoclosure carefully as there’s no caller-side indication that argument evaluation is deferred.
  • The context and function name should make it clear that evaluation is being deferred.
  • Autoclosures are intentionally limited to take empty argument lists.
  • Avoid autoclosures in any circumstance that feels like control flow.
  • Incorporate autoclosures to provide useful semantics that people would expect (for example, a “futures” or “promises” API).
  • Don’t use autoclosures to optimize away closure braces.

Want to read more about Swift Style? There’s a book!

Xcode Tricks: API Changes

Here’s a quick trick that helps you review changes between SDK releases, including beta SDKS. In Xcode, select Help > API Changes.

Xcode automatically navigates your web browser to https://developer.apple.com/api-changes/. (You can also visit this link directly.) At the web site, you’ll find a list of current and archival API deltas:

For example, when I clicked on the latest Beta release, here’s the screen that popped up today:

Color-coded overviews reflect the number of changes (modified, added, deprecated) at the top left. A pop-up at the right, enable you to switch to specific betas and releases.

Select individual modules to view changes in-place, annotated with corresponding color highlights.

As you navigate down to finer details, the change highlights trickle down to deeper and deeper levels.

Select an older version of Xcode from the top-right pop-up to view a current-to-previous comparison. In this case, the type constraint has moved to a trailing where condition.

It’s a fascinating way to present and navigate API changes.