The next version of FastCast is going to be less dependent of paid services. NOAA doesn't provide Sunrise/Sunset data so a calculation was needed.
Another goal of FastCast 2 is not to contain Objective C code, so I wanted to avoid EDSunriseSunset . I've been through this route in the original version of FastCast (written 4 years ago). At that time either EDSunriseSunset didn't exist, or I didn't find it.
Maybe to my detriment, I've also taken a more cautious approach to 3rd party components. I'm not keen on reinventing the wheel, but more and more there are components that offer little real value that have become a standard, such as AFNetworking.
You'll actually see AFNetworking as a skill on job listings, which to me is a warning sign on the company posting the AD. I'm not suggesting that it's not great code, by great developers, I just see it as an unnecessary abstraction on the common task of downloading and parsing JSON.
Writing the Swift Version
So I'm not so smart that I can write this calculation off of the top of my head, so off to Google..
This gives us a good step by step example outside of any programming language. It is also nice to be able to break each step down, to validate each step before moving on.
The biggest challenge using Swift is the 'expression to complex' error.
I'm not sure if this is something that the Swift team is working on, or just the way it is. This is certainly my biggest gripe with Swift, but like all relationships there are the things to like and the things, not so much.
It does lead to some ugly code with the expressions being broken down to many steps, but maybe that makes it more simple..
Lazy properties are used allot to avoid recalculating more than necessary.
The code with a Playground can be found on GitHub here