The WatchKit SDK can seem almost frustratingly limited at times, but I think that's for the better: I'd wager that the first crop of 3rd party Apple Watch apps are going to be a lot more rock-solid than the first crop of 3rd party iPhone apps, due mostly to the focus imposed on us developers by the constraints of the SDK.
The API is going to be a big priority for us going forward. We have some new development planned on that front, and AI will be able to help us out tremendously.
Dark Sky is kind of an expensive app, as apps go: $3.99. Which means we have a small percentage of the market, giving it a very different growth curve from free apps. Our rate of revenue has been slowly increasing since we launched. And since our market share is so low, I don't see us running out of potential customers any time soon.
(And to answer your other question: Forecast.io makes some money, but not much. And we do have an increasingly large revenue stream in our data API)
Hi Adam, this is a fascinating post, thanks for writing it! I'm Jacob, of PressureNet, and in fact Dark Sky is the reason I'm still building weather software! You beat me to consumer-focused radar postprocessing (I was working on this using McGill's radar data in 2010, and stopped when you launched) and you did a really good job - such a good job I took a look around and started collecting barometric pressure data in a new attempt at making the best hyperlocal weather forecast! You and your team are inspiring. :)
I'd be thrilled to talk about your data API and forecast tech, especially if you're considering working with phone sensors to improve your forecast models. I'm jacob@cumulonimbus.ca, have a look at http://pressurenet.io if you're interested.
Thanks for building great products and writing great posts!
CEO of Riskpulse here. I've been through all of the monetization trenches for weather software and we are now capitalizing on real demand in B2B/enterprise. If either of you guys ever want to connect to talk shop or (in)formally partner or share ideas, let me know: matt@riskpulse.com
Heh, the check's already in the bank. What can they do to us now? (Just kidding. I actually ran the post by them and they had no issues at all -- I'm honestly not sure what I would have done if they did have a problem with it).
Also: Validation is tricky, since we can't just compare the output to ground station observations, as we incorporate ground station data into the model. Eventually I want to generate alternative versions that randomly exclude specific stations so we can use them for comparison.
Instead, I think you'd need to find temperature measurements that are completely independent and use them for verification. Along this line, I'm not sure how refitting the data to ground stations would produce a better match anywhere except at those ground stations (overfitting). Or are you using ground stations that are truly independent?
When we compare it to RTMA, we leave out RTMA from the list of data sources. Likewise, eventually I'd like to do the same with a subset of the ground stations we use.
(The problem with finding completely independent measurements is that we'd want to use them as an input!)
"Real-time" is the key. As far as we know, there isn't another real-time global data product that is this high resolution.
And while we actually use MODIS data as an input to our temperature correction model, it is, as you mentioned, land surface temperature, whereas our map represents near-surface air temperature (i.e., what you'd get in a normal weather report).
Thank MapBox. If it were up to me, I'd do something funky like a blackbody-esque color palette and then get yelled at because it'd be hard to read. :-)
The color palette adjusts based on the zoom level in order to improve contrast. Roughly a bazillion people pointed out that it's "broken", so I guess that was a dumb call on my part!
Shouldn't it adjust based on the extremes (Or standard deviation) within the zoom area? In that case there would always be some purple, and should fix at least the specific problem the parent showed.
The WatchKit SDK can seem almost frustratingly limited at times, but I think that's for the better: I'd wager that the first crop of 3rd party Apple Watch apps are going to be a lot more rock-solid than the first crop of 3rd party iPhone apps, due mostly to the focus imposed on us developers by the constraints of the SDK.