They're actually quite different - a good chunk of my current project is in Kotlin, and all of my last project was in Swift.
Things Swift has that Kotlin doesn't: associated types, file-based access control (changing in Swift 3.0), pervasive use of keyword arguments, trailing closures, full pattern matching (Kotlin can only destructure component1...N sequences), reference counting.
Things Kotlin has that Swift doesn't: smart casts, declaring properties directly in the constructor, declaring constructors directly in the class statement, auto-delegation, data classes, singleton objects, implicit parameterizable 'this' (handy for builders & DSLs), garbage collection.
Things they both have: null chaining & defaulting, class extensions, somewhat clumsy first-class method syntax, concise lambda syntax, lambda anaphora ('it' in Kotlin, $0 and $1 in Swift), concise range operators, property descriptors, operator overloading.
Kotlin generally has the feel of a much more pragmatic, industrial language. It's Java without the warts, where the designers took note of the common Java patterns they wrote and provided a lot of syntactic sugar to dramatically improve brevity. Swift feels more academic; its type system is more modern and less ad-hoc, it has polished implementations of many features that academic languages have been trying to get right for years. Both are heavily influenced by their ecosystems; Swift feels like a better Objective-C, and Kotlin feels like a better Java.
It's a bit different in Swift. Kotlin lets you omit the parentheses if the closure is the only argument to the function. Swift lefts you place the lambda outside of the parentheses if the closure is the last argument to the function. That lets you construct a much larger variety of control-structure-like HOFs. Event handlers, for example, often take a functional argument plus a bunch of other data.
Cool. Learn something new every day. (I was confused because all the examples except for lock() are single-arg, and IntelliJ usually autocompletes with parentheses because there's often a non-functional overload.)
Things Swift has that Kotlin doesn't: associated types, file-based access control (changing in Swift 3.0), pervasive use of keyword arguments, trailing closures, full pattern matching (Kotlin can only destructure component1...N sequences), reference counting.
Things Kotlin has that Swift doesn't: smart casts, declaring properties directly in the constructor, declaring constructors directly in the class statement, auto-delegation, data classes, singleton objects, implicit parameterizable 'this' (handy for builders & DSLs), garbage collection.
Things they both have: null chaining & defaulting, class extensions, somewhat clumsy first-class method syntax, concise lambda syntax, lambda anaphora ('it' in Kotlin, $0 and $1 in Swift), concise range operators, property descriptors, operator overloading.
Kotlin generally has the feel of a much more pragmatic, industrial language. It's Java without the warts, where the designers took note of the common Java patterns they wrote and provided a lot of syntactic sugar to dramatically improve brevity. Swift feels more academic; its type system is more modern and less ad-hoc, it has polished implementations of many features that academic languages have been trying to get right for years. Both are heavily influenced by their ecosystems; Swift feels like a better Objective-C, and Kotlin feels like a better Java.