Today’s release of weather app Carrot Weather comes with some interesting changes. For the first time, the app supports MeteoGroup as a data source.
I have been using the MeteoGroup’s own app WeatherPro for years. In my personal experience, the quality of prediction data for Europe is more accurate in comparison to other “global” data sources that are also supported by Carrot.
However, I don’t like the concept of presenting the data in WeatherPro very much and kept looking for replacements. Hello Weather is certainly a viable alternative, but for some reason it did not stick for long. At some point, I switched to Carrot, and my previous data source of choice (The Weather Channel) within Carrot delivered okay-ish results I could live with. Win-win, sort of.
Without any evidence for it to happen, I nevertheless kept up hope that the future with bring access to higher-quality data, specifically the data that power WeatherPro.
According to Carrot’s release notes of today’s release, The Weather Channel terminated the contract because it does not want to provide data to competing apps any longer in order to get more users to switch to their own apps. Here’s hope that MeteoGroup does not come to a similar conclusion any time soon.
- For reasons I could only speculate about. ↩
This is not a new thing, but fits perfectly to the Apollo 11 buzz (no pun intended) that we are going to get through in the coming month.
Make sure to go to firstmenonthemoon.com and replay the final descent of the landing module along with synchronised communication in the mission control room in Houston and between CAPCOM, Columbia, and Eagle.
I came across this video on Twitter. The video demonstrates a non-trivial, but still not overly complicated example of a SwiftUI declaration.
I have to say that, after looking at the SwiftUI declarations I’m actually undecided whether my concerns voiced in this article are warranted or not. Yes, the chained expressions are sort of a mess and it remains to be seen whether such code is maintainable.
On the other hand, the presentation of the relevant information is not as obscured as I feared it would be. In other words, by looking at the code it is in my opinion possible to understand what’s happening.
I very much like the idea of a declarative definition of a user interface and thus I’m motivated to kick SwiftUI’s tires. Having worked halfway through the tutorials, I’m a little bit concerned about the scalability of SwiftUI. Sure, a DSL is always going to win the elevator pitch because it looks so nice and elegant.
At least the WWDC videos about SwiftUI that I have watched so far restrict themselves to more or less the bare minimum of complexity that you might want to add to the declarative definition of an app’s user interface. And already in the simple cases SwiftUI starts to get messy, e.g. with respect to formatting chained expressions.
My (probably not very popular) point is that I personally believe that defining a scalable XML-based format will way more likely yield a good result than designing a DSL for the same purpose because scalability is already baked into XML itself. You can wrap tags around tags around tags real simple and the resulting complexity ist still kept under control.
In many cases, the problem is that the design of a DSL will start with the simple and elegant cases and stay with the simple and elegant cases for some time – until it needs to expand towards supporting higher-level complexity. But: if the need for supporting higher-level complexity hasn’t been considered from the start than the DSL will fall apart pretty quickly.
To drive my point home, I have actually done some work in declarative UI definition in the Windows world, specifically the Windows Presentation Foundation (WPF). Microsoft uses a dialect of XML named XAML for the UI declaration.
I fully understand that XAML in particular has lots of problems and isn’t as much fun as you might want it to be. But still, given the choice between declaring a UI in an XML dialect or else by means of using a DSL (like SwiftUI) I would personally actually very likely prefer the XML.
- That does not even include the point where suddenly imperative paradigms are mixed into the declarative language. ↩
- Which – let’s face it – it will inevitably have to. ↩
- Yes, in a text editor. There is a graphical frontend for XAML. My experiences with the graphical frontend are staggering and I have yet to come across anyone seriously endorsing it. ↩
It didn’t come as a total surprise to me, but it was very close. Only five minutes or so before the keynote started I saw a retweet from someone who mentioned the possibility that a dedicated “branch” of iOS existed (named iPadOS) specifically for the iPad.
And then it became a reality. The strange thing about the naming is that iOS originally has been conceived as iPhoneOS and was only later rebranded as iOS when the iPad entered the market.
Maybe it’s just me, but wouldn’t it be ironic to give all sorts of devices their own specific OS-branding and the iPhone, arguably the most important device in the lineup (and the one that started this whole family of OS-variations) stays with the generic iOS branding?
Maybe a further rebranding may happen when final versions of <modifier>OS 13 are released to the world. And maybe the term iOS finally becomes some sort of abstract base marketing term for the entire class of OS.
Feature-wise, I’m delighted about what’s in store for the next major OS release on my iPad. Although I might want to mention that font management and a download manager for Safari would also make excellent features for the iPhone, just sayin’. I keep hoping for a trickle-down of such useful details to the iPhone at some point in time.
Overall, it is a good sign that Apple gives iPadOS such a prominence. At the very least it means that no WWDC will happen from now on where the iPad is not going to get some new OS-features. Neglect has happened way to many times in the past.
As Steve Troughton-Smith observed, they can’t ignore it anymore. Apple put this burden on themselves for good.