Mobile OS Update Challenges – Shiva Nathan, Onymos

This is Techstrong tv. Hey guys, thanks for the thrill. We're here with Shiva Nathan, who's c e o for ais, and we're talking about operating system upgrades and how they've gotten better, but they're still pretty disruptive at the end of the day.

So the question is, is how to make that simpler. Shiva, welcome to the show. Thanks Mike.

Thanks for having me. So let me start with, uh, operating system updates for web applications and mobile applications and IOT applications in different, uh, realms. So when it comes to web applications, most companies have moved to using public, uh, cloud providers like a w s or Azure or G C P, and we no longer have to worry about operating system updates in those runs because the cloud cloud providers are responsible and they take care of it for you.

Whereas when you move to the mobile world, it's still early stages, it's still in fancy. Uh, it's as if we are still in the 1990s for, uh, hardware os upgrades and stuff. So Apple iOS brings out a one major upgrade, uh, every year around this timeframe here in beta Right now.

The release itself will come out in September and then Android comes out in December. The iOS, uh, the Android 14 will come out in December and bring the big upgrades every year. There are at least like a dozen minor upgrades as well, which makes the problem even more cumbersome.

So what is the impact of all this in terms of disruption? Do the applications break or they just run, uh, less well if they're not on the latest upgrade cycle per se. I mean, are there penalties in that?

Because it seems like a lot of folks take their sweet time actually upgrading to the various, uh, new versions of an operating system. Yeah, the biggest problem of not upgrading immediately, like upgrading your application immediately to the, to support the latest and greatest uh, os update from these mobile operating systems is security. So if you actually go back and look at the iOS upgrades and, and Android upgrades, the big ones and more importantly the minor ones, that happens almost like every month or so.

The minor ones are mostly filled with, uh, security patches. So if your application is not upgraded to take care of those security fixes that come from iOS and Android, you are in fact exposing your app and your apps users to all the security vulnerabilities. So in which case, the imperative is for you to jump in and at least make, uh, do do the right thing for at least the security updates.

That's one. If you remove the security thing outta the picture and then you start to look at other stuff, if you don't upgrade your app fast enough, your app will start to look stale. So imagine when a face ID came up into the picture and if your application only supports a touch ID or fingerprint, ID still, any person that downloads your app will immediately know that, hey, this is not a cool app.

I can't use face ID anymore on iOS. And when they don't see your app to be the cool taking advantage of the cool features, your adoption goes down. When your adoption goes down, your reviews and ratings goes down, it's like a wisher cycle down.

You're basically getting flushed down the AL throne. So that's what happens. Um, to that end then, are security people driving the conversation more about ensuring those upgrade cycles?

Cuz we hear more about DevSecOps and we hear more about software supply chain management. But has that become the primary reason to drive an upgrade? Uh, not necessarily.

You would want to believe that this happens, but not necessarily with an enterprise development organization. There is like a, um, healthy and unhealthy strain of, uh, relationships within the engineering team that has to do the work and the security team and the product team. The product team wants the latest and greatest school application specific features.

They are not as, uh, vested in getting the engineering team focus on doing what is called grunt work or maintenance or getting the app to work on the latest thing. They want the latest cool business feature to be put in. That's what they want the engineering team to spend time on.

The security team on the other end wants all the security fixes to be taken care of. The engineering team itself wants to actually keep everything up to date, not just with iOS and Android, but your application depends on lot of other things. APIs from all the other service providers, let's say is Trip or PayPal or uh, Twilio or someone.

The engineering team has its own backlog of things about keeping things updated. So between this triad of security, producting wanting cool new business features and the engineering teams own backlog is a healthy and health healthy discussion. And especially in this economy when there are very few engineering staff and questions being asked on what's gonna bring revenue security kind of falls to the lower totem pole, but the CEOs or the CTOs who rather get the new feature out that brings some incremental revenue rather than fix something that will actually make the app a little bit security robust.

Mm-hmm. How automated can all of this get going forward? Uh, I understand in the past it was very manual, but it feels to me at least a lot of this is getting more automated and should become a little more turnkey.

But what's your sense of how much have people embraced automation for operating system upgrades? The development process itself is getting automated a lot more from the time that the developer checks in the code to testing happening, the build happening, the testing happening, the performance test and reliable test happening, and then the pushing in the gap store, that part of it is getting automated quite a bit, but unfortunately it still needs engineers or fortunately, depending on where you sit, it still needs engineers to go look at what really changed with this new iOS 17. 5 and doing those changes into your particular application.

And same story for Android as well. Android 14 is gonna come out in December and you still need engineers to go look at what changed within Android 14 and Android 13 and then make those changes to the app. Once you check in the changes things are automated almost all the way to the app store.

What's your best advice then to the DevOps teams that are in charge of keeping track of those changes and understanding what they are? Because it's not like the operating system update just appeared overnight. It seems like they get telegraphed in in advance, but how far in front of this should I get?

So there are two ways to solve this problem, right? The one way to solve the problem is of course, to have your team start to look at the alpha releases and beta releases. Like right now we are in IOA 17 beta, I have your engineering team.

Go look at I 17 beta and find out what's happening. Will there be still something that gets surprised on you when the, uh, IO 17 gets production release? Of course, but at least you are caught up to 90, 95% of the changes and you're doing it in your own schedule, rather than having to do all of that on the day that I was METHING gets released.

Right? Or use technologies like Aus, uh, where you are kind of like absolving your engineering team off the need to use, uh, the platform, uh, or features that are to be constantly upgraded, doing grunt work to keep your app updated to I y 17 and Android 14 and so on. So either one of these two charges, either do the work or absolve yourself for doing the work by using technologies economists.

Those are currently your choices. We hear a lot about artificial intelligence these days. Is that gonna get applied in this space and how so?

Um, not yet is the answer that I want to give. I'll tell you the main reason why artificial intelligence requires data to be trained on. So iOS 17 when I was 17 comes out in September and Android 14 comes out in December.

It needs probably two or three months for all the generating AA and intelligence to really learn what are the changes that's happened, what people have done with it, what are the core changes that they have done. So if you go back to, uh, the artificial intelligence system in December after it has had three months of data and ask, uh, the artificial intelligence system, Hey, tell me what I need to do to upgrade my app from IO 16 to IO 17. It can spew out some stuff to help you, but unfortunately it takes three months for the artificial intelligence team to learn.

And those three months, your app is gonna be dated, your app is gonna have all the security vulnerabilities and stuff. So you actually need to unfortunately get ahead of the game and then do it yourself with engineers, with real human real intelligence. So human intelligence then wait for artificial intelligence to come and help you.

Do the folks who make the operating systems really understand the implications of the upgrade or are they just kind of focused on the operating system and the features, but they don't really think through what the downstream impact of that might all be? They do and they don't. Uh, the reason is if you go to Apple, or if you go to Google and look at the iOS development teams and Android, Android development teams, they're a raise to get features out themselves.

Um, I'll talk about one particular feature. If you are on a iOS, uh, location for example, there, there are, um, you can actually give, uh, precise location, which tells you exactly where you are or a non precise location, which just tells an application a general area that you are, we kind of know from the ias summiting beta that Apple is gonna come up with a third thing, which is like give you a very, very precise location inside a mall or inside an airport to be able to navigate you to that store within the mall or the particular coffee shop within the airport. And that's coming out hopefully in I 17.

That's what the rumors say, and I think that's what's uh, gonna make out in I 17. Right? And when they're trying to do that, every application in the world, two or 3 million application developers in the world have to actually go back and look at that particular change and make that app either leverage it or make sure that that app does not break because of this particular change.

Right? So if you are an I U I S engineer with an Apple, are you thinking about the impact that you're making to all these 2 million applications? Yes.

But at the same time, what is driving you more is a cool new feature from Apple that you want to drive? And what do you think wins? What wins essentially is that Apple development team saying, you know what, we only had two levels of location.

We're gonna have three levels of location. That's always seems to be winning. Then the problem that it creates to all the 2 million application developers out there, it takes some time, it takes few years at least for the operating systems to mature to the point where Apple and Google will start thinking about, Hey, if I make this change, how much does it impact the people where Linux is today?

Linux operating system upgrades when it happens? You understand that, hey, there's a huge install base of people using Linux. I can't fundamentally go and break things immediately.

iOS and Android only had like, what, like 15 years of uh, um, in the industry compared to 30 years or 40 years Orix operating systems. So it'll take, I'm not saying it'll take another 25 years for mobile operating systems to catch up there, but it'll probably be another five to 10 years for it to catch up there to that level of maturity. What is your best advice then to, uh, say a DevOps team that's kind of managing this process?

How do they kind of get their arms around it? What have you seen, you know, people who are successful in keeping pace with operating system updates and not losing ground every time there's an update? So it's gonna be a little of a plug off, uh, Aus here, right?

Our customers had the same problem that most engineer enterprise teams are facing, and our customers now are extremely happy because they chose to put their application on top of the anonymous platform and not just anonymous platform, but it actually gives them the leverage to look at the source code. We are the only company in the world that like the entire source code. It's as if you engineer slept, work up and you got all the source code available to you.

So look at not just a, but look at similar technologies out there that absolves you of this responsibility of your engineers having to update all of the basic or core basic features doing the grant work whenever an iOS 17 change, iOS upgrade happens, or a hundred upgrade happens, or any of the 12 different upgrades that happen within the year. So that's what I would appoint them to, like, do you anymore worry about operating system changes in the web application world? You don't.

You gave it to the cloud providers to do it. Why do you have to worry about the same thing when it comes to mobile operating system changes? You need to use technologies like Aus to do it.

All right, folks. Well, if it's non-differentiated value, it should be automated at the end of the day. Hey Shiva, thanks for being on the show.

Sure. Thanks Mike. All right, back to you guys in the studio.