Why is this code working in Playground but not passing the code challenge in Treehouse?

Never mind. I figured out why it's breaking only on task 2. Your custom initializer does break the code challenge and that's because of how init methods work with structs.

When you write an initializer in a struct declaration (as opposed to an extension of the struct) you override the memberwise initializer automatically generated. This means that the code challenge doesn't know how to create an instance of your Post struct.

Yes, your initializer makes it easier to just pass in the string, but if we allow custom initializers, we have to anticipate every possible version of a custom initializer and guess at how to create an instance.

For example another student can do this

init() {
    self.title = "iosDevelopment"
    self.author = "Apple"
    self.tag = Tag(name: "swift")
}

This is also a valid initializer but again I have no way of anticipating this and using it to create an instance in the challenge test logic.

Typically in real world code the way I would write it is to leave the default memberwise initializer and create a convenience initializer in an extension of Post like so:

struct Tag {
    let name: String
}

struct Post {

    var title: String
    var author: String
    var tag: Tag

    func description() -> String {
        return "\(title) by \(author). Filed under \(tag.name)"
    }

}

extension Post {
    init(title: String, author: String, tag: String) {
        self.title = title
        self.author = author
        self.tag = Tag(name: tag)
    }
}

let firstPost = Post(title: "isoDevelopment", author: "Apple", tag: "swift")
let secondPost = Post(title: "iOSDevelopment", author: "Apple", tag: Tag(name: "swift"))

Since the initializer is in an extension, you don't override the memberwise default. This allows me to use the default initializer to create an instance and check your function, but it also allows you to use your convenience init. Note that both initializers can be used as shown above.

Hope this helps understand why it would be impossible for us to allow custom inits as default

I agree, your solution with the custom init method is much more readable, and if you would write this code in real life for real people this would be the way to go. But since you are writing this code for a machine and an automated test you should stay simple and only do what is necessary.

No problem!

I find it a better practice to create my custom inits for structs in the extension purely so that it doesn't override the memberwise init.

The Intermediate Swift 3 course (should be out in a week) covers everything you need to know about extensions.