Faced with an existential threat to its hot patching service, Rollout.io is appealing to Apple to extend its app oversight into post-publication injections of JavaScript code.
CTO and cofounder Eyal Keren has penned an open letter to Apple asking the i-obsessed device maker to develop and deploy a "Live Update Service …

COMMENTS

Pretty sure Apple (and Google/MS) never allowed this...

...IIRC right from the start you weren't allowed to update your code dynamically. It's an obvious way to get malware or dodgy content past the screening systems. I don't really have any sympathy - this doesn't benefit the consumer in any way, and developers know that they need to budget a week to go through the review process.

It's surprising that iOS runs anything that isn't signed - although given what they say I guess they've been abusing scripting languages to do it.

Re: Pretty sure Apple (and Google/MS) never allowed this...

and they never should.

Though, as I'm not a developer, I'm curious as to the patch procedures. Patches for things like skype always seem to be far larger and more frequent than I would expect. It is nice that the software is being maintained but the size and number of bug fixes indicates it has flash-sized coding issues. /usr/bin/skype is 35M. Typically IOS Skype patches are 75M. Skype for Linux doesn't appear to need bi-weekly upgrades, so why does the IOS version? I don't think even Skype for Windows gets the same patching as IOS.

Is there something else going on? Are they using patch downloads to boost their apparent popularity rating, classing it as a full download?

Re: Pretty sure Apple (and Google/MS) never allowed this...

Skype has been going through a change in the way that it works, at a base level. That means changes throughout the whole system.

An application is made up of thousands of subroutines and libraries. If you need to apply changes to a lot of libraries, then the update will be big.

The Linux version of Skype has been neglected for years and got a recent update, so that it could still talk to modern versions of Skype on other platforms.

Whilst it is a pain for developers to go through the review process, it is the proper way to do it and I hope that Apple don't cave on this. I am not an Apple iPhone user, but this is one of the few benefits of their closed ecosystem.

It behoves the developers to use their own in-house testing and review processes, to ensure that the biggest bugs disappear, before the app is given to Apple. If they find more bugs and security issues, before they publish it, that means a safer, smoother experience for their customers and not stressing, because they are trying to rush out an update and having to wait for Apple to green-light the update.

Maybe Apple should offer, as consolation, a fast-track update route for major security issues and bugs causing devices to crash.

Re: Not Necessarily

Minor UI enhancements, improvements in functionality and responsiveness to feedback can afford to wait a few days for Apple's review process.

When they talk about "hotfixes" they are obviously doing like the man said: writing and releasing shitty code with users being the alpha testers, then left scrambling when told the latest update broke the app.

I have no sympathy for such careless devs. If a 4-7 day delay for review means they have to think about what their doing and maybe test stuff a bit before releases, I think that's a good thing. If they can't abide by Apple's "slow" reviews and feel they must have one hour turnaround on hotfixes because they keep breaking their app with untested code, that's their problem, and shouldn't be mine. If Apple did allow some sort of quick review I'd hope they'd designate such apps on the App Store so I'd know to avoid them!

Re: Not Necessarily

"I have no sympathy for such careless devs. If a 4-7 day delay for review means they have to think about what their doing and maybe test stuff a bit before releases, I think that's a good thing."

From experience, if a developer finds out that their app in the app store has some critical problem that needs to be fixed asap then they _can_ contact Apple and a review _can_ be made quicker. Apple will want a really good reason. Do it more than once and you burn a lot of goodwill, obviously.

@FatGerman

I have only had one product that went out nearly bug free.

We did a multi-national budgeting system for a client. Several hundred users in over 50 countries. The system was used for several years and in the first 2 years of live use, it produced 2 bug reports. One we fixed, the other was a bug in localised versions of Windows running international English - the Win32 call to return the local month names in the current language always returned "January", for all 12 months!

The client told us, that English was the company language and we should hard code the month names.

But yes, such projects are, unfortunately, few and far between. I've worked on many others that had a lot of bugs, due to complexity issues - it gets worse with web applications, because they are also reliant on the client; if one browser displays the app wrong, you have to go back and re-work the CSS to ensure it is displayed on all possible browser combination properly. It is getting somewhat better, but it is still a moving target.

Re: @FatGerman

Same here. Testing is, unfortunately, seen as an annoyance by developers and a waste of money by management. I've worked with developers who have said "It won't need testing, it'll just work". That, unfortunately, is the prevailing culture.

As for 'minor UI improvements' - they're not so critical as to require a patch mechanism that bypasses all quality controls. I've also seen such 'minor' improvements render entire systems unusable. Never trust a developer who says "It's only a couple of lines of code, it won't break anything".

Waaaah, we write shite code...

Waiting days (a year ago it could have taken weeks) for releasing a fix of a bug in your app is a bad experience for developers, companies and at the end for users, no software is defect free, not matter how much you QA it.

In the software world there is always a need to shorten the distance between releases and their is always pressure to be able to release fast, especially when it's an emergency.

OTOH

As a developer who cut his first code a long times ago (hint: Fortran on Punched Cards) I have been involved in a large number of projects over the years.

Only in recent years has this need for 'Emergency Patching' really taken hold.

Before that we would take our time and test the effing thing to death. What bugs that remained were generally very obscure.

Any that were found were incorporated into our test suite as a matter of course.

Then along came Agile and SCRUM. The whole thing went to pot. Technical Debt was quikly labelled 'Won't Fix' and everyone wat told to move on to the next Shiny-shiny bit of bling in the system.

Releases got shipped that would only install 50% of the time (or worse).

Functionality was there in the GUI but underneath? {tumbleweed blowing in the wind}. Marketing called those releases 'Tech Previews'.

The only thing it did was allow the PHB's to claim their bonuses for shipping something. Then they moved onto the next project to screw up.

My current role is working in an Agile/SCRUM environment but we don't release anything without resolving at least 50% of the technical debt. It isn't perfect but we release better quality code and that means we don't have to supply emergeny patches.

The Modern PHB's and Scrum Masters have obviously never heard of the 'bathtub principle' or 'Do it once,do it right'.

To them it is all about ship and be dammed.

I am so glad that I get my pension in October. I can get out before it gets much worse.

Re: OTOH

Re: OTOH

That's a good point, the internet and flash memory made everything easier to update, so far less testing was required because if problems are found no worries - just push another update! Not that I long for the days when you bought a product and if it had bugs you had to live with them forever, but now that updates are easy, they're too often about adding bells and whistles, instead of fixing past bugs.

Because everyone is assumed to have the ability to update at a whim, standards can change at a whim as well. Look at how the Youtube API has evolved, in the process obsoleting a bunch of devices that couldn't be or weren't updated to handle it. So now you HAVE to provide an update mechanism for almost any internet connected device, but vendors aren't prepared to support a product for as long as it actually lasts. It is bad enough for Android phones, but at least those are generally only expected to last a few years.

If you buy a smart TV, it gets support for about as long as the typical Android phone, but they last at least a decade. Once they quit updating it, changing APIs alone will render its smart features slowly obsolete. Between that and ATSC 3.0 in the US, I can see why Vizio started selling some TVs without smart features or even tuners (which legally can't be sold as TVs, they have to be sold as 'displays')

Re: Ugh...

"Also, am I the only one that thinks the whole approval process thing exists solely because they can't be arsed to put in proper security measures?"

By actually reviewing submitted software, they are using proper security measures. They are protecting the integrity of the product. Compared with Google's approach, it's working great to keep worthless software and malware off the App Store.