Short answer: pretty functional, but not completely.

Long answer: well, keep reading!

First, let's define the kinds of attributes we're looking for when we call a functional language or runtime "functional." Some people look at map/reduce as a proxy for functional - I don't. C, a decidedly non-functional language, can do that. Some look to recurion - I think that's a big part of it. Primarily, it's the ability to use functions as first-order objects. Then, the ability to properly recurse. I like to add type safety and initial assignment-only variables, but you don't have to. So how does Swift stack up?

First, Swift certainly does allow you to use functions as first-order objects. You can create them and pass them around as variables, like any other variable in an argument list:

let static_ints = [1,2,3,4,5]
let static_strs = ["Aa", "Bb", "Cc", "Dd", "Ee"]

func printer<T>(withValue value: T) {
    print("Printed: ", value)
}

func printList<T>(withList list: [T], andPrinter printer: (_ : T) -> Void) {
    for l in list {
        printer(_: l)
    }
}

printer(withValue: 1)
printList(withList: static_ints, andPrinter: printer)

You can do this kind of thing in a variety of ways. I pass this as an argument list, however, to show that functions are treated just as any other variable would be.

It does not allow you do assign generic functions as you would regular variables (i.e.  var v = printer<Int>  ), but you can assign closures and variables without generic parameters.

So, not perfect, but not bad either.

Up next: recursion. So how does Swift fare?

We can recurse, and Swift even seems to support tail recursion. Write an eternally recursing function in a Swift playground - it won't run out of stack space if you're not allocating any:

func eternalLoop<T>(withList list: [T]) {
    eternalLoop(withList: list)
}

eternalLoop(withList: static_ints)

This means that the language and runtime are not blowing stack space setting up call frames for each function invocation - this is vital in a functional language, and Swift seems to do it.

What it doesn't do is provide syntactic support for recursion. For example, if I want to recurse successfully, I need to do something like this:

func recurse<T>(withList : [T]) {
    if withList.isEmpty {
        return
    }
    var l = withList
    let t : T = l.popLast()!
    print(t)
    recurse(withList: l)
}

recurse(withList: static_ints)
recurse(withList: static_strs)

I'd rather do something like this:

func recurse<T>(withList : [T]) where withList.isEmpty {
  return
}

func recurse<T>(withList : [T]) {
    var l = withList
    let t : T = l.popLast()!
    print(t)
    recurse(withList: l)
}

recurse(withList: static_ints)
recurse(withList: static_strs)

Note the syntactic support for evaluating list state. Other accepted functional languages do this differently, but this would do the trick. So the most important thing with regard to functional support exists - tail recursion. The syntatic support, however, lags.

So how about the last two, type safety and constant assignment? Well, the language is not strongly typed, nor are the values idempotent. But they can be. Swift doesn't force you to use optional types after all. You can furthermore avoid the use of VAR, and use LET instead. But those things are not enforced by the language or runtime, as they are in more functional languages. And to be honest, runtime enforcement of these features would make integration with Objective-C and C more difficult.

So Swift has the key elements of functional languages, and you can safely program in a functional style in Swift. This is pretty rare for this kind of language - neither Java, or Python, or really any mainstream languages give you the environment to functionally program safely. But the features, for the most part, are not enforced by the language.

Overall? It's safe - if you want to, go ahead. But don't expect the language to help you do it.