Sign in / up

back to article Apple urged to legalize code injection: Let apps do JavaScript hot-fixes

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

Post your comment
House rules Send corrections
Add to 'My topics' unstar *
  1. Anonymous Coward
    Anonymous Coward

    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.

    13 1 Reply
    1. P. Lee
      Reply Icon

      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?

      3 1 Reply
      1. big_D Silver badge
        Reply Icon

        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.

        2 0 Reply
  2. FatGerman

    " Developers are struggling with the ability to continuously improve their apps"

    Translation: "There's a lot of shitty code being released that hasn't been tested properly and it needs patching on a daily basis"

    Get it right before you ship it and the need for patching will miraculously disappear. That said, in 25 years I never worked for a company that understood that.

    16 1 Reply
    1. frank ly
      Reply Icon

      That leads to the question of how shitty the patches will be in that 'culture'. Any guesses?

      1 0 Reply
    2. Mark Simon
      Reply Icon

      Not Necessarily

      There's a lot of shitty code being released

      Not necessarily the point. Minor UI enhancements or improvements in functionality may simply suggest an ongoing process and possibly responsiveness to feedback.

      I think there is a case to be made for not making small changes go through the the approval process and then yet another update, which, in some cases, means re-downloading a huge application.

      The problem, of course, is where to draw the line safely.

      1 0 Reply
      1. Anonymous Coward
        Reply Icon
        Anonymous Coward

        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!

        4 0 Reply
        1. gnasher729 Silver badge
          Reply Icon

          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.

          1 0 Reply
    3. big_D Silver badge
      Reply Icon

      @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.

      0 0 Reply
      1. FatGerman
        Reply Icon

        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".

        2 0 Reply
  3. big_D Silver badge
    Facepalm

    Waaaah, we write shite code...

    And Apple won't let us fix it on the fly.

    What could go wrong?

    5 1 Reply
  4. adjunct

    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.

    0 0 Reply
  5. adjunct

    As much as I understand why Apple has done what it did, as a developer I understand why this solution is needed.

    Customers suffer when their app is not working, EVERY app has bugs, no matter how much you QA or how good is the dev team.

    The fact that a company cannot releases fixes fast is a big pain (at least from my experience)

    Just so you know, developers with or w/o Rollout (or other solutions) can and are injecting JS code remotely.... hence (IMO) the reason Rollout has suggested a solution.

    2 1 Reply
    1. Anonymous Coward
      Reply Icon
      Anonymous Coward

      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.

      5 0 Reply
      1. AMBxx Silver badge
        Reply Icon
        Windows

        Re: OTOH

        As it became easier to patch via the Internet, the quality of code dropped. It pains me to say it, but I agree with Apple on this one.

        0 0 Reply
        1. Anonymous Coward
          Reply Icon
          Anonymous Coward

          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')

          1 0 Reply
  6. Halfmad

    Legalize ?

    Don't you mean facilitate? or at a stretch simply approve?

    1 0 Reply
  7. Anonymous Coward
    Anonymous Coward

    Ugh...

    If the approval processes weren't so damned slow this hotpatching malarki wouldn't even be a thing.

    If anything apps utilising hot patching processes should be marked in the app store as such make it a user decision. I know, I know "but people are dicks" well tough I say.

    Lastly, isn't each app sandboxed? If they are wheres the harm in JS hotpatching?

    Im assuming access to the lower levels of the phones hardware is done via APIs.

    If thats the case then why not allow a dev to flag up his application as hotpatch ready and restrict the application tonread only functions and remove low level access to sensitive components?

    Theres a lot of apps out there that are extremely basic ... take the myriad fart buttons for example.

    If I wanted to push a new fart wav for "Trumpy Tuesdays and Wet n Windy Wednesdays" its a total waste of human resource to check and verify each fart deployment.

    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?

    I mean, effectively people are trusting Apple to find and prevent breaches and abuses. A company whose business model is moulded out abuse and breaches.

    Id feel a lot less tinfoil hat effect if Apple allowed third parties to train and register as "authorised app verifiers" or something. Where certified third parties can sign apps for publication.

    We'd have a more transparent system, Apple would have time to become compelling again and the process could be sped up.

    Everyone wins.

    1 2 Reply
    1. JCDenton
      Reply Icon

      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.

      "A company whose business model is moulded out abuse and breaches."

      What?!?!?

      0 0 Reply

POST COMMENT House rules

Not a member of The Register? Create a new account here.

Forgotten password ?

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like