As the Apple Swift document , Enumerations can do similar thing and more.

Alternatively, enumeration members can specify associated values of any type to be stored along with each different member value, much as unions or variants do in other languages. You can define a common set of related members as part of one enumeration, each of which has a different set of values of appropriate types associated with it.

1) If you just want to split a 8 bytes number to 2 x 4 bytes numbers, as you might have known, the Bitwise Operation of Swift could help. Just like

let bigNum: UInt64 = 0x000000700000008 //
let rightNum = (bigNum & 0xFFFFFFFF) // output 8
let leftNum = (bigNum >> 32)  // output 7

2) If you want to simulate the union behaviour like C language, I tried a way like this. Although it works, it looks terrible.

enum Number {
    case a(Int)
    case b(Double)

    var a:Int{
        switch(self)
        {
        case .a(let intval): return intval
        case .b(let doubleValue): return Int(doubleValue)
        }
    }

    var b:Double{
        switch(self)
        {
        case .a(let intval): return Double(intval)
        case .b(let doubleValue): return doubleValue
        }
    }
}
let num = Number.b(5.078)

println(num.a)  // output 5
println(num.b)  // output 5.078

Well, there is no direct support of unions, in Swift, but we can use enumeration for our purpose.

Ex-

enum Algebra {
  case Addition(Double, Double)
  case Substraction(Double, Double)
  case Square(Double)

  var result : Double {
    switch(self)
    {
    case .Addition(let a, let b): return a + b
    case .Substraction(let a, let b):  return a - b
    case .Square(let a):  return a * a
    }
  }
}

let solution = Algebra.Addition(5, 3)
println(solution.result) //Output: 8.0

Swift discourages "unsafe" programming patterns like union, however, there is a workaround. It's a bit ugly, but here goes (using Xcode 7.2)...

struct VariantA {
    var oneField: Int // 8 bytes

    struct VariantB {
        var firstField: UInt32 // first 4 bytes
        var secondField: UInt32 // second 4 bytes
    }

    var variantB: UnsafeMutablePointer<VariantB>  {
        mutating get {
            func addressOf<U>(something:UnsafePointer<U>)
                -> UnsafeMutablePointer<VariantB> {
                return UnsafeMutablePointer<VariantB>(something)
            }
            return addressOf(&oneField)
        }
    }
}

Now a quick check of sizeof(VariantA) will show the whole structure still takes up only eight bytes (which is one 64-bit integer). If we now create an instance like this var a = VariantA(oneField: 1234567890987654321) then we can query the components like this a.oneField which will return the initial value 1,234,567,890,987,654,321 and also a.variantB.memory.firstField will return 2,976,652,465 and a.variantB.memory.secondField will return 287,445,236.

We can change one of the components like this a.variantB.memory.firstField++ and then observe that this changes the original value of a.oneField to 1,234,567,890,987,654,322 as expected.

The ugly parts for me are the occurrences of the words "unsafe", "pointer" and .memory. as well as that addressOf helper function which is only there to overcome a compiler error in Xcode 7.2!

Perhaps working with lower-level structures that require byte-level manipulation like this should not be done in a high level language like Swift at all. Have you considered writing this part of your project in a .c file? With a suitable bridging header you can still do the majority of your project in Swift.