My sample project is written in Swift and uses syntax and language features of Swift 1.2 (https://developer.apple.com/swift/blog/?id=22). It compiles with Xcode 6.4. Please update the pods before building.

I separated the code and the project in two parts: the SDK and the UI. Tests are also separate of course.

- The part that I call "the SDK" is a very rudimentary draft of what "could" be developed into an SDK for the Fyber-Backend. The features currently only cover the use case that was requested in the coding challenge and not the whole API and all the different ways to make use of it. The SDK basically consists of one class (but could certainly be splited into several if more functionality is added) and a helper data storage class. For a real SDK is would be crucial to write more classes that reflect the different data structures in the JSON to work with them efficiently and safely.

- The UI is also a very simple one: just as it was requested, the only two things it includes are a form for three request parameters and table view with the results. The initial request (through the SDK) and the image loading requests are asynchronous tasks which do not block the UI. Images are loaded when needed and they are cached. One may pull the table to clear and reload the whole content and thus displaying potentially new offers coming from the backend.

- I split the tests into two sections: static and random tests. The static tests are pretty straight forward: simple unit tests that test static strings and cover the methods in the SDK. I would have added some more static tests but my knowledge about the API is rather limited so all I did was testing with the example that I had. The random test section is a bit more interesting: it generates a list of 50 pairs of parameters with random strings and compares the calculated request string (including the hash and everything) 100 times with random permutations of the initial random list. In the beginning I planned to implement some adaptive functionality that keeps testing in case of a failing test in order to automatically identify edge cases, but I did have time for that and I also would not have made much more sense with tests for the actual request. The random test extensively tests the requests string generation with parameters, but what is missing is a random test against the backend with real web requests. Unfortunately I do not know which parameters work for my example and can be altered in which way - and without that knowledge I am afraid that I would have ended up with testing the backend and not my code. :)

- What is also missing in my project is the handling of the various error cases. There are lots of different ways why requests could fail. In a real application those cases must me covered of course, and most of them on SDK level.