(Originally posted 2018-07-28.)
It’s the Time Of The Season1 for thinking about Day One support. Not for z/OS, or DB2, or CICS, or anything mainframe-related. But for iOS, MacOS and their kin.
Before you switch off – if you’re an Android user2 – you can consider the Apple bit an analogue. This post will be light on technical detail, and heavier on developers’ approaches. It might even stimulate some discussion about z/OS.
So, it’s a month or so since Apple announced new iOS, MacOS, etc releases at their Worldwide Developer Conference (WWDC) and developers (and foolish / brave non-developers) have run betas. Several betas, in fact.
Part of the point is to prepare their products for General Availability3. And developers’ approaches to that is what this post is about.
So, you can see this might have some relevance to z/OS and its vendor ecosystem.
Approaches To Day One
As I look around at the many iOS, WatchOS, and MacOS apps I have I see a number of approaches from the various developers. Here are a few examples:
- I’m beta’ing releases of Drafts (mentioned in Appening 5 – Drafts On iOS). Already the sole developer is experimentally introducing exploitation of the new Siri Shortcuts feature.
- I use a podcast client called Overcast. The sole developer – Marco Arment – is rebuilding his WatchOS app to use the new iOS 5 audio playback capabilities.
- I’ve yet to hear much from the Omni Group but they indicated they were clearing the decks for whatever Apple threw at them – which is a good sign.
- I’m hearing rumblings that some of the MacOS apps I depend on – some IBM, some not – won’t Day One support the new Mojave MacOS release.
- There are plenty of apps on my iOS devices that already won’t run – because the developer never updated them to run on iOS 11. The technical point here is they must be 64-Bit. I consider these – 1 year in – as “abandonware” though I wish Apple did a better job of enabling me to dispose of them.
Through these various approaches and stances runs a theme: I’ve emphasized the words “sole” and “Group” for a reason.
- The sole developers, Greg and Marco, are moving fast and experimenting with exploitation.
- Casting no aspersions whatsoever, I see Omnigroup saying little. But I am jolly sure they are working on stuff for the apps I rely on: Omnifocus and OmniGraffle (and the others of theirs I’m not so reliant on). I’m confident for two reasons: Attitude and Track Record.
In Enterprise we might well appreciate the “more planned” approach Omni Group are taking. In the consumer space not quite so much.
But, back in 2014, I wrote in And Just Complain:
Mobile users, though, have no real understanding of how the service is provided and don’t really care (and nor should they.) So I think they can be characterised as much less patient and much less tolerant of service issues, and that’s fine.
So, assumptions of tolerance of errors and issues is in limited supply everywhere.
What Do You Need?
There’s obviously a lot of Marketing value to being able to claim “Day One” support – for some markets. So, from a developer’s point of view, something close to Day One support is important. In “real world” terms there’s another point for developers: They really don’t want to field “iOS 124 broke your app” issues.
For the vendor – Apple or IBM – it’s great to have customers able to adopt their new release on Day One. In reality, though, many customers will want to skip early life and the “pioneer cost” issues5 that brings.
A few days ago (as I write this) was World Emoji Day. The relevance of World Emoji Day is surprisingly high: Each year on this day the Emoji standards body releases the new emoji for the year6. Apple traditionally supports these on the first point release after a new version of iOS or MacOS. That’s also where the first batch of “settling in” fixes are delivered for an iOS version. It might seem superficial but getting people to install this point release is a lot easier if there are new emoji to play with.7
And what about us, hapless punters that we are? 🙂 Some of us are insanely 🙂 keen to install the new operating system level on the day of release. I’m not consistently 🙂 one of those. But pretty close.
When I review the myriad material coming out of WWDC, I take note of the new things8. But I consider what the operating system vendor ships as being “one shoe dropping”. I’m really looking forward to the other shoe dropping: What the app vendors ship.
But, of course, z/OS is different, or rather its customers are. Very few will install a new z/OS release at GA, for example. But they would like to know that all their products – whether vendor or IBM – work well before they need them to.
Exploitation might well be a different thing; My suspicion is most customers are less worried about exploitation. Though, if you ask them, quite a few customers will reply “I’m really looking forward to x”.
There is a whole interesting side conversation to be had about what drives customers to upgrade, quite apart from exploitation. Maybe another time. But, even if you’re just upgrading because you have to, it’s still important to know stuff continues to work. If you are a “Last Day Upgrader” (to coin a phrase) the chances are that vendor and IBM products will have introduced toleration.
But I still get excited at reading announcement material and learning about new functions.
Cultural reference. :–) ↩
Or a reluctant Apple user. :–) ↩
That, of course, is an IBM term; I’m not sure what Apple call it. ↩
Or z/OS 2.3, for that matter. ↩
Whether bugs, or usability, or Performance, or whatever. ↩
Over 150 this year, taking the total to almost 3,000. ↩
Imagine I send you an emoji of a platypus playing billiards :–) and all you get is some “dunno, mate” indicator like a question mark. In theory you’d want to upgrade just to get my message in its full, ahem, glory. :–) 9 ↩
And there are a lot of nice things this time round. ↩
Emoji rendering design and evolution is actually quite an interesting topic in its own right. ↩