back to article Neglected Pure Connect speaker app silenced in iOS 11's war on 32-bit

Wireless speaker maker Pure appears to be more the first casualties in Apple's war on 32-bit iOS apps. Pure's 32-bit Connect software for iThings won't work on Apple's new 64-bit-only iOS 11, meaning folks using Cupertino's latest firmware and handsets can't control their space-age hi-fis. The audio remote-control app joins …

  1. Martin Gregorie Silver badge

    Evidently never heard of escrow...

    I'm surprised that those outsourcing their apps or any other code needed for their products to operate didn't contractually require that the source must be placed in escrow when the binaries were delivered. This should be SOP as protection against the developer going out of business.

    Further, if the code is unique to this contract, a not uncommon situation, then I'd expect the developer to deliver both source and binaries on contract completion. That's been the norm for almost all projects I've worked on.

    So bad luck for Pure, but they really should have taken better legal advice.

    1. Version 1.0 Silver badge

      Re: Evidently never heard of escrow...

      I would expect that they have the source code but just because you've got the source doesn't mean that building a 64-bit version is something you can do overnight.

      I'd have to upvote Microsoft at this point for maintaining 32-bit compatibility with their 64-bit operating system and therefore completely avoiding this problem.

      1. Lord Elpuss Silver badge

        Re: Evidently never heard of escrow...

        "I'd have to upvote Microsoft at this point for maintaining 32-bit compatibility with their 64-bit operating system and therefore completely avoiding this problem."

        Because Windows RT was such a shining success.

      2. 45RPM Silver badge

        Re: Evidently never heard of escrow...

        @Version 1.0

        It depends. If you’re using Apple’s developer tools then the process for converting to 64 bit is pretty simple. You might have to update your code to replace any deprecated functions with supported ones, but I haven’t seen any situations where this is necessary (yet). So then it’s just a matter of telling the compiler to build a 64 bit version and job done. Simple as that.

        You can even try it yourself. DOSBox and Marathon for iOS are 32 bit apps - but open source. Grab a copy of the source code, change the build settings, and you’ll be running these great apps on your 64 bit only iOS device in no time.

        There really is no excuse for developers not to update their software. I’m pretty pissed off that I can’t run Civilization anymore - but I don’t hold Apple to blame for this. It’s not as if they capriciously dropped 32 bit support without warning everyone long in advance what was going to happen.

        1. Justin Clift

          Re: Evidently never heard of escrow...

          > I’m pretty pissed off that I can’t run Civilization anymore - but I don’t hold Apple to blame for this.

          I absolutely do. Our industry in general considers backwards compatibility extremely important. That's why Windows (ugh) supports binaries created from much earlier versions, as does OSX itself unlike this new iOS. It's a pretty solid rule of thumb that things which guarantee backwards compatibility have more success than things that don't. Assuming no other monumental fk-ups of course. :)

          This is 100% apple's choice to drop backwards compatibility, in full knowledge it would have a bad effect of some sort on part of their userbase. They seem to have forgotten the goal of people is to use their phone as a tool (eg apps and things it can do), rather than the goal being to run the latest version of iOS. That they're thinking has gone so far down this incorrect track to actually affect users like this... is an extremely bad sign. If they don't continue releasing security updates for 10.3.x series iOS, they've effectively turned many devices into paperweights (including my iPad Pro) as lots of people have 32-bit apps that cannot be upgraded as there's no 64-bit version available.

          Personally, I feel most sorry for the ~1 million users of apps like Safe Note:

          https://discussions.apple.com/thread/8077356

          That's a password storage app (seems poorly done tbh) which was popular for several years... and the developer has gone bust. No 64-bit version forthcoming, so people (many not super computer literate) that updated have lost multiple years of their passwords. Ouch.

          I know about the above one as they're using a DB GUI I help out on for recovering their data. There's likely many more similar stories to the above.

          1. Lord Elpuss Silver badge

            Re: Evidently never heard of escrow...

            ”...they've effectively turned many devices into paperweights (including my iPad Pro) “

            I’m sorry, I don’t follow your logic here. Your iPad Pro is still 100% supported and is absolutely not a paperweight - what are you on about?

            Also, it’s 2017 FFS. Apple dropping legacy 32bit on a phone/tablet OS is a totally legitimate move; sorry. If people are affected by their favourite poorly coded, unsupported app not being supported, then that’s regrettable; but not reason enough to swallow the security, performance and cost implications of continuing to support an architecture that was already on it’s way out of the door back in 2006.

            1. Justin Clift

              Re: Evidently never heard of escrow...

              > Apple dropping legacy 32bit on a phone/tablet OS is a totally legitimate move; sorry.

              Bullshit. OSX and Windows both do backwards compatibility. iOS has no excuse at all, especially with such a large established userbase.

              1. Lord Elpuss Silver badge

                Re: Evidently never heard of escrow...

                "Bullshit. OSX and Windows both do backwards compatibility. iOS has no excuse at all, especially with such a large established userbase."

                Your comparison is flawed.

                Neither OSX nor Windows need to support devices with 1.3GHz processors and 1GB RAM - highly restricted operating conditions by today's standards. Holding 32bit and 64bit libraries in memory here is likely not possible if the OS is to have any semblance of responsiveness.

                Windows 10 Mobile and Windows RT would be the equivalents in the restricted-capacity device market, both were 32bit only, suffered from poor performance and support, and as a result failed miserably in the market.

                1. Justin Clift

                  Re: Evidently never heard of escrow...

                  > Holding 32bit and 64bit libraries in memory here is likely not possible if the OS is to have any semblance of responsiveness.

                  Really, don't agree with this. These devices are working fine with both 32 and 64 bit apps in iOS 10. Magically iOS 11 suddenly can't fit them? Not even for running in some special legacy mode to keep their users with "legacy 32-bit apps" happy?

                  If iOS 11 has blown out in size to no longer fit in the hardware's memory, that's a good sign that unneeded bloat has been introduced, or people aren't prioritising optimisation enough. Either way, dropping support for 32-bit apps isn't good enough. They need to figure out a solution and fix it, instead of abandoning their users like this.

                  1. Lord Elpuss Silver badge

                    Re: Evidently never heard of escrow...

                    iOS10 was around 1.1GB installed, iOS11 is closer to 2GB: primarily because your definition of ‘unneeded’ and ‘bloat’ is not the same as everybody else’s. Such is the price of progress. Full-disk encryption and other high-overhead processes are now the norm, and given that 32bit OSen and apps were superseded more than a decade ago dropping support now is more than understandable.

                    Your argument is the same as whining that car manufacturers no longer factory-fit a cassette player. Sure there are a few people who’d like to play a tape, but there are millions more who couldn’t give a shit. And trying to build in literally every feature ever invented would mean the car weighs 10 tons, accelerates like Stonehenge and has enough room for the driver - as long as he sits on the roof.

                    So in short, stop whining, downvote me and get on with your life. 32bit is history, and it’s not coming back.

      3. Paul Crawford Silver badge

        Re: Evidently never heard of escrow...

        "I'd have to upvote Microsoft at this point for maintaining 32-bit compatibility with their 64-bit operating system"

        Have you actually used the 64-bit version of MS Windows C/C++ compiler?

        If so you will discover that part of the 32-bit compatibility is the fact that most normal types like 'long' are still 32-bit! Yes, you have to explicitly ask for 64-bit variables so porting a program and expecting 32-bit memory limits, etc, vanishing magically is going to be a surprise unless you have been very pedantic to always index using size_t or similar. This level of incompetence (or "easy of backwards compatibility" depending on your viewpoint) extends to some OS API where they still use 32-bit "time_t" even though that is one type that is now 64-bit in both 32 and 64 builds. See more here (also not this reported bug is over 10 years old now):

        https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/674d34c9-b6f6-4380-bc7b-181eae99847a/timeval-struct-incorrect?forum=windowssdk

    2. What? Me worry?
      Facepalm

      Re: Evidently never heard of escrow...

      Exactly. That was my very first reaction: "You didn't have an escrow clause for just this type of event?!!" I guess their risk appetite was bit more than they had thought. Is there a C level pink slip in their future?

    3. JulieM Silver badge

      Re: Evidently never heard of escrow...

      I would expect nothing less from any programmer whom I might hire to work for me, than the complete and richly commented Source Code and build instructions. Nor would I insult any client of mine by offering them less. In fact, they have a right to my dead-end development versions if they really want them; someone else might be able to get something working that I could not. I'm not afraid to show my working out.

      It's good for stories like this to come out. People should not stand for software-defined landfill incidents, and need to know that they are entirely preventable. Remotely damaging other people's bought and paid for property, while it is under guarantee, is at worst cyberterrorism (if the equipment damaged is deemed to be a computer) and at best old-fashioned vandalism. Intellectual property should always be of subordinate concern to tangible property, and for fairness' sake would-be asset-strippers need to be aware of this.

      1. Lord Elpuss Silver badge

        Re: Evidently never heard of escrow...

        @JulieM

        It depends what’s been contracted. I’ve been a software dev and a photographer, and in both cases I generally contracted with clients to give them a finished product; but explicitly not the sourcecode (for software) or digital negatives (for photos). I retained the rights to these. Occasionally a client wanted the full code/negatives including the rights, this was discussable but cost a hell of a lot more than just the finished product; because I was giving up stuff that I could have used for other clients.

  2. Anonymous Coward
    Anonymous Coward

    They can't get the code for their own app?

    Amateurs. Total bloody amateurs.

    I don't blame them for outsourcing development. On the other hand if Pure commissioned it, the contract should have stipulated that Pure hold the full copyright, all relevant source code and documentation, and a prohibition on any proprietary tools, techniques or libraries that might be used to make it difficult to get a new developer to amend the code.

    1. Lysenko

      Re: They can't get the code for their own app?

      Ever tried to exhume orphaned code from escrow? It's often not as easy as just doing a pull from GitHub[1], and even when it is, if you outsourced the development in the first place it's very likely you don't have the skills to do anything useful with it and didn't have the skills to audit it before it was deposited (minified/obfuscated code still compiles just fine and that's as far as people like NCC ever go).

      The real issue in almost all these cases is companies outsourcing for skills instead of time. Outsourcing is safe only when you have all the necessary skills on the payroll, but insufficient time/staff to do all the work yourself. When you outsource entire competencies you have no way of effectively managing the project/risks and sooner or later end up playing Russian Roulette.

      [1] Why are the developers out of business? If there is a receiver involved and there is any question that payment shenanigans were a factor then the escrow can be locked up for years.

      1. gnasher729 Silver badge

        Re: They can't get the code for their own app?

        Common sense is that you don't have source code in escrow, but that you have a deal where the developer delivers complete source code. Why would a bespoke application like this have source code in escrow, instead of having one external hard drive with operating system, compiler and all the tools required to re-create the app?

    2. TechnicalBen Silver badge
      Facepalm

      Re: Customer beware/blame the buyer?

      Really, the only reason I still have cabled headphones, still have not bought a "smart speaker" is because mine don't fail if the Bluetooth version or software bugs, or my radio still works if the internet goes down. ;)

      1. Lord Elpuss Silver badge

        Re: Customer beware/blame the buyer?

        Or until your phone manufacturer removes the headphone port...

  3. Anonymous Coward
    Anonymous Coward

    Commentards obviosly know more than mere mortals

    Martin Gregorie, Ledswinger, no where does it say Pure do not have the code to their app, it says their third party app developer has gone out of business.

    On another 64 bit note, how much memory in an iPhone these days?

    1. sgp

      Re: Commentards obviosly know more than mere mortals

      The still-on-sale iPhone 6 has the full... 1 GB

    2. DougS Silver badge

      Re: Commentards obviosly know more than mere mortals

      2GB in the 8, 3GB in the 8 plus and X. Some may scoff and say "if it isn't more than 4GB they don't need 64 bit" but I/O is mapped to a 1GB or 2GB segment in the typical IOMMU (I don't know how much address space I/O takes on Apple's SoCs) and then you also need a separate mapped area for firmware. It is quite possible even a 2GB iPhone uses a larger than 32 bit address space, though if they REALLY wanted to I'm sure they could cram everything into a single 4GB area.

      Anyway, the advantage of 64 bit on ARM is not dependent on needing a 4GB address space, but rather its far cleaner API. Dropping 32 bit support allowed Apple to drop two 32 bit APIs in the A11 CPU which would simplify the design and verification. They could have chosen to continue to support 32 bit apps via software translation, but they've been requiring 64 bit builds for two years now, so I think Apple figured this wouldn't have come as a surprise to any iOS devs. Unfortunately it does come as a surprise for companies who have outsourced their development and thus don't keep informed of Apple's future direction.

      1. Joe Montana

        Re: Commentards obviosly know more than mere mortals

        Not just support for the extra APIs, but also the overhead of keeping 2 sets of libraries both on disk and in memory when you run a 32bit app...

        It makes no sense to support both at the same time, and there's no point supporting only 32bit as it clearly has a limited future compared to 64.

    3. Dan 55 Silver badge

      Re: Commentards obviosly know more than mere mortals

      Presumably if they still had the source they'd have managed to get someone in, recompile, and upload to the App Store.

      They've only had about four years to do that.

  4. This post has been deleted by its author

  5. ThomH Silver badge

    Do we have grounds to believe the 8 and X can even run 32-bit code?

    If Apple's choice, given that it designs both the processor and the OS, was to spend the transistors on something else then might that not actually be more forgiveable than just dumping 32-bit support for maintenance cost reasons? I'm not sure the comparison to Microsoft necessarily holds.

    That being said, I also think the reference to 2015 by Pure is disingenuous. Apple's first 64-bit handset came out in 2013 — twice as long ago. If you weren't supplying 64-bit builds even by 2015 then you were supplying a poor product even then.

    I can understand an interregnum if there were developer issues, but this is Apple. If you spend four years ignoring a transition it is trying to make then you're being very foolish indeed. I think Apple deserves a lot of blow-back for the unsupported apps that are now dead, but a company trying to keep a 32-bit app as a going concern has only itself to blame.

    1. DougS Silver badge

      Re: Do we have grounds to believe the 8 and X can even run 32-bit code?

      Actually, we know for a fact the A11 is incapable of running 32 bit code, and iOS 11 does not support it (i.e. no 32 bit libraries)

      Obviously Apple did that by choice, but it hardly came as a surprise to any devs since as you say Apple has been selling 64 bit phones for four years, has not sold any 32 bit phones for two years, and has been requiring all App Store submissions to include a 64 bit build for two years (Pure's latest version must have just missed the deadline)

      The people who bought Pure products got screwed by a shitty company, but that shitty company was not Apple. What did Pure plan to do if iOS 11 or the iPhone X had been incompatible with their app in some way? They couldn't keep using an app from 2015 indefinitely even if Apple was still supporting 32 bit apps, eventually something would break. I guess Pure doesn't care, they already got their money.

      1. Anonymous Coward
        Anonymous Coward

        another Pure hardware problem

        I bought a Pure iPhone(4) dock with DAB; using it in EU, then my local region evolved to DAB+; Pure have theoretically a firmware upgrade to DAB+, but after several years of trying different RS-232 connection methods, three-fingered-salutes and running their dos based radio upgrade - I gave up and have avoided them.

        On 32-bits, there was also an app to interact in some way with my DAB dock - which i never bothered with at the time, I'm sure I could always find an oldish iPod or even my still working iP4 to run as a control node.

  6. GBE

    Whenever you depend on an app...

    You're just asking for trouble any time you buy hardware that depends on some proprietary app to function. You really should plan on the HW turning into a boat anchor in 2-3 years max. If that's cool, then go ahead and buy it. If not, look for something else.

    1. Roopee

      Re: Whenever you depend on an app...

      I totally agree. I have audio streaming hi-fi from several manufacturers (NovaFidelity, Pioneer, QED) that all have crummy manufacturer-branded Android and iOS apps, but I wouldn't have bought any of them if using the apps was a requirement. Instead I made sure that they all have a web interface and use DLNA, for the exact reason that I don't want them to become expensive door stops when someone somewhere makes a limiting decision outside of my control. It's common sense, surely?

      1. JulieM Silver badge

        Re: Whenever you depend on an app...

        Any time I try to thump the tub for Open Standards and Open Source, someone whines that it's too hard for them to think about, and they just want their stuff to work.

        Well, who's laughing her tits off now your stuff doesn't work, precisely because someone used one proprietary ingredient too many?

        ITYS. YDNL. HAND.

  7. Anonymous Coward
    Anonymous Coward

    Who gives a fuck?

    iPhone is the enterprise phone now right? I don't see many corp. associates using their work phone with some shitty speakers?

    1. LDS Silver badge
      Paris Hilton

      Re: Who gives a fuck?

      Do you mean Weinstein didn't need some music when he forced women to massage him and worse?

  8. Anonymous Coward
    Facepalm

    im laughing my socks off

    As someone who has built outsourced apps for companies of note, i can tell you that Yes, they have almost always stipulated source code in the contract and if not, then included when prompted by the developer (me).

    The problem is the attitude to developers. They are not worth more than a few hundred / thousand bucks once in 5 years to most companies, who make no correlation between the income the company gets and amount (not spent / "saved") on development.

    While some of the companies i have worked for have gone, clients from years and years ago know i will answer their emails and resurrect their app for the latest device despite whatever ltd no longer existing.

    To have lost their developers and have none of the core team still in contact with ANYONE is pretty bad. They must have treated them like shit.

    More of this please, maybe we can have a "Be nice to your app developer day" or something... lol.

    And footnote... you bought speakers that need an app to work... that's where you went wrong, right there. No sympathy as you've no doubt had a year's worth of "check out my super high tech speakers etc"

  9. Boohoo4u

    Buy a used Android phone, connect it to your WiFi, install the App.

    Problem solved.

    You probably wouldn’t even have to pay for the phone, just ask around. Personally I have several lying around...

    1. DougS Silver badge

      That's one possible solution, but speakers that require an app to function are fatally flawed, IMHO. What's next, someone going to sell a car that can only be unlocked and started with an app?

      1. Dave 126 Silver badge

        Another solution is to plug a Chromecast Audio into the speaker's aux socket. Cheaper than buying a 2nd hand iPhone to dedicate to the task.

      2. Pat Harkin

        "speakers that require an app to function are fatally flawed"

        I have a Panasonic speaker which needs an app to setup the presets but works standalone for internet radio there after but I also have some Sonos speakers which are virtually useless without the app - but one is installed on top of our kitchen cabinets, so without the app I'd need a stepladder instead...

        (Why two brands? I like my Sonoses but they don't make a bathroom (rechargeable, splashproof) version. Panasonic do make one - but it's terrible in comparison to the Sonos for playing music via wifi and I pretty much only use it for the radio.)

  10. Anonymous Coward
    FAIL

    Twats.

    Unfortunately, Apple’s decision to remove support for apps created prior to 2015, which don’t natively run in 64-bit mode, will undoubtedly affect many apps, including our own…

    They had two bloody years notice, the idiots. When I upgraded to iOS 11 there were no 32 bit apps on my phone. Because they’d all been upgraded by the developers who had a clue.

    1. DougS Silver badge

      Re: Twats.

      I checked a couple months ago when I found out 32 bit apps wouldn't work, and I found a few. Apps I hadn't used for years, and had no problem deleting (I should probably clean up the rest of the apps I don't use, but I always think "well maybe I might need this someday...")

    2. Anonymous Coward
      Anonymous Coward

      Re: Twats.

      Shows how many of the staff either use their app, have an iPhone or both?

      1. peter_dtm

        Re: Twats.

        Pure are the Rayners of the audio world ?

        1. itzman

          Re: Twats.

          Ratners?

  11. Dr Mantis Toboggan

    Apple fragmentation

    Karma is a bitch, as with all the noise about android fragmentation, I have never ever had an app that didn't work or wasn't compatible, even really old apps work perfectly on android 8...

    Wondering where all those fragmentation taking tech "experts" are now? Hiding away in shame I hope for falling for apple spin..

    1. 45RPM Silver badge

      Re: Apple fragmentation

      Yawn. I suppose I should feed the obvious troll. But the thing is that Android is an excellent OS. Sure, it has its faults, but doesn’t everything?

      iOS is an excellent OS too. It has different faults. But upgrading to 64 bit only is not one of them. Apple isn’t to blame, at least not in this instance, if developers dump a load of shit onto their customers and run for the hills failing to support the poor bloody user.

      What you like isn’t necessarily what everyone else likes - which is fortunate, otherwise there’d be no competition, we’d all use the same devices and the same software, and the world would be a boring place.

      1. Anonymous Coward
        Anonymous Coward

        Re: Apple fragmentation

        Upgrading to 64bit IS one of the problems. Did you really think a 64bit OS upgrade came for free? It doesn't. It uses on average 30% more memory and 30% more storage space compared to 32bit code, so unless you bulk up the hardware too, you have a net loss. Does a mobile phone really need to address more than 4GB of RAM? I think not..

        1. DougS Silver badge

          Re: Apple fragmentation

          Wrong.

          The reason 64 bit mode uses more RAM and more storage is because you need to have both 32 and 64 bit libraries present on "disk" and in memory. However, once you drop 32 bit mode, there is almost no difference. Sure, pointers take up twice the space but pointers are a tiny fraction of the overall footprint so it wouldn't make 64 bit code or data requirements go up by even 1%. In fact, ARM64 code is actually slightly smaller than ARM32 code, because of new instructions that were added for stuff like conditional execution.

        2. gnasher729 Silver badge

          Re: Apple fragmentation

          Bullshit. You haven't developed for iOS, have you?

          Lots of things take less space in 64 bit on iOS then in 32 bit, because Apple's developers have been doing quite a few optimisations. Many objects don't use any allocation: This ranges from C++ std::string up to 22 bytes, NSNumber, NSString for short string, NSIndexSet in the common cases. There are significant savings that you don't get on 32 bit.

  12. Byz

    they just need to...

    Recompile the app in Xcode 8.

    If the app was built well and the app developers didn't use 32 bit third party libraries, it should just need a few tweaks and a recompile and submit to the AppStore.

    I've written apps for a few companies originally in iOS 7 that every two years may need two or three days work and a recompile, Xcode builds the app to the version of iOS you specify.

    It just requires that you know what you are doing and that is the harder part :)

    1. 45RPM Silver badge

      Re: they just need to...

      @Byz

      Wow. Is that how you bill your clients? ;-)

      I’ve always found 10 or 20 minutes to be sufficient - and that includes the time to boot, change compiler settings, build, commit to repository, upload to Apple and shut down the computer again. But mums that word - best not to let on to the clients how easy the conversion process to 64 bit actually is.

      1. ch0rlt0n

        Re: they just need to...

        So none of the APIs you were using changed in the interim, and your build step included automated unit and regression tests?

    2. Lysenko

      Re: they just need to...

      Or, if they can't do that (which seems highly likely given the nature of the fiasco), they can just open source whatever they've got an wash their hands of the problem permanently after a few months. If they don't want to be in the software business (defined as not having developers on the payroll) then they should get out of it entirely and stop trying to subcontract/project manage things they don't understand.

  13. Anonymous Coward
    Anonymous Coward

    Re: they just need to...

    @45rpm

    Perhaps he/she tests their software?

    1. 45RPM Silver badge

      Re: they just need to...

      @AC

      Excellent point. Thumbs up. But remember that we’re not talking about code changes - so extensive testing may not be required. Add half a day, depending on the complexity of the app.

      1. Lysenko

        Re: they just need to...

        I'm not contradicting you (because I don't do iOS), but are you saying that shifting from int/pointer/long all being 4 bytes to pointer/long being 8 bytes (but int is still 4) won't break anything? Doesn't the compiler support memcpy, bitwise operations and so on?

        Personally I've found 32->64 (on other platforms) second only to ASCII->UNICODE for obscure gotchas in forgotten areas of pointer arithmetic and the like.

        1. 45RPM Silver badge

          Re: they just need to...

          @Lysenko

          Certainly I’ve seen those issues in other development environments (it was particularly tiresome on VMS!), but I’ve yet to see an issue when using Apple’s APIs on Xcode. It really is as simple as changing a compiler flag on every project that I’ve updated to 64 bit so far (other than my own applications, this also includes the following supposedly 32 bit open source projects - Marathon, DOSBox, CrocoDS, ActiveGS…)

          In my experience, Xcode really is a most remarkable IDE.

          1. Lysenko

            Re: they just need to...

            I wasn't doubting that the IDE or the APIs could handle it (that's much the same in VisualStudio), I was referring to application code. I can see it being transparent in an interpreted language or a VM that simply doesn't allow you to mess with pointers, but I didn't realise ObjC was restricted like that.

            1. 45RPM Silver badge

              Re: they just need to...

              @Lysenko It isn’t restricted like that - it’s still C, and can do everything that C can do, hence the name. But it depends on the source - have you allocated (and freed, natch) your memory manually? Are you hardcoding where you point on the basis of an assumption of 32bit size? Or have you been canny in writing your code (sizeof) or, better yet, used the Objective parts of Objective C to do it for you.

              Flexibility is the watchword. In fact, I imagine that many ObjC developers don’t mess with pointers explicitly, and use ARC for memory management - these developers will have no issues at all. I use a mix of techniques, and use ARC where appropriate but not everywhere, and I haven’t seen any problems either.

              Of course, it isn’t necessary to use ObjC to develop for iOS. Other languages, other APIs, other IDEs are available. I haven’t used them - but I imagine that updating to 64 bit in these cases might be more problematic.

  14. Anonymous Coward
    Anonymous Coward

    just when you thought your home was safe

    soon you'll have to replace your central heating and lights every couple of years as nothing seems to come without a dependency on an "app" of some kind.

    This one does seem a bit unnecessary though. I seem to recall an IBM iSeries update that reassembled software to the new 64 bit IIRC based on the object itself, once done, permanent for each object so never has to be done again.

    I expect to be throwing away cars soon, as the associated, and inevitably proprietary "apps" that unlock it, start it, turn the heating on, track your servicing etc are dropped out of the current technology. I strongly suspect the legal requirement for spares for x years from manufacture does not apply to these increasingly embedded elements.

    This is the thin end of a very thick wedge I tell ya...

  15. rogue-Element
    FAIL

    Awful App anyway - can stream directly from Spotify etc

    I found the app to be pretty dreadful and always ended up connecting by bluetooth and selecting the PURE devices from within Spotify anyway.

    Still a poor show...

    1. ShadowCopy

      Re: Awful App anyway - can stream directly from Spotify etc

      Yes you can bluetooth to a single speaker and have it "Caskeid" to the others, but you need the Pure app to manage the multi-room aspect and enable/disable speakers, change audio settings etc. Also i used the built in digital radio app.

      My current solution is have all speakers enabled for Caskeid and it play in every room in the house and then unplug from the mains the ones i don't want on. Pretty low-tech but saves me having to acquire (and keep charged!) an Android device

      Here i was thinking buying from a "proper" company in the UK would mean better support than the cheaper ones on amazon from the far east.

      Let's hope Pure pull their fingers out and provide a replacement app soon, and it's not total abandonware

  16. Keith Oborn

    Sale of Goods Act

    I think this might be actionable: Pure has a responsibility to ensure their products are "fit for purpose". The timescale might be a problem (> 1 year) but still worth taking legal advice. If enough people went down that route manufacturers might take note.

    IMHO, *requiring* a mobile phone App to control external hardware is a stupid idea. The only one I use regularly in this was is to set up recordings on a Youview box - but most of the time that's just convenience, I can always do it from the TV unless I'm out.

    As an EV owner, I am headbangingly frustrated at the move to App-based as the only way to control use of public EV charge points: exactly how many possible points of failure do these people want to introduce?

    1. 2Fat2Bald

      Re: Sale of Goods Act

      Not sure about that. Arguably it's limited to it's warranty. You bought it, the warranty expired. It stopped working. But they only said it would work for 12 months, anyway.

      I don't buy that argument because it hasn't stopped working (it's fine) which is what warranties are there for, but did they actually agree to provide updates to any future OS? because you do - of course - have the option of using the older OS it was designed for if you want to. That may not be wise or convenient, but you do have it. Unless you've already rejected that option by upgrading to 11. But that's your choice.

      1. John H Woods

        Re: Sale of Goods Act

        "Arguably it's limited to it's warranty"

        The length of the warranty is largely irrelevant. My 10 quid splashproof Bluetooth speaker also had a warranty for a year. I doubt a SoGA case for a 13th month fao lure would be a success. But if you're shelling out serious wedge for audio equipment, and you treat it nicely you have a reasonable expectation of longevity. I think 5 year is reasonable and 2 probably a minimum (he says, looking at a pair of massive Acoustic Energy speakers he bought a quarter century ago, e.g. which have survived half a dozen house moves, four cats, three dogs and three kids. And also survived collision with a pony ... don't ask)

    2. 45RPM Silver badge

      Re: Sale of Goods Act

      @Keith Oborn

      And that is my principle objection to EVs. They’re no longer tools, the way cars used to be, they’re mere gadgets. Toys. Expensive gadgets, but gadgets none the less - and their lifespan is at the whim of the manufacturer. At some point the manufacturer will stop supplying software updates - and some unforeseen bug will render them all inoperable. When that happens, it’s buy a new car time.

      Yesterday, as I was blasting down the road in my early 1960s GT car, I saw a Jensen Interceptor - about 10 years newer than my car, but still knocking on the door of 50 years old. A very creditable age. It happened to be following a Tesla Model X. The Jensen looked amazing - a really droolworthy car, and I’d have been envious of it were it not for the fact that my car had rolled out of the same factory and matches it in the glamour stakes. The Tesla? Well, it’s not for me. It’s a toy. A frippery by comparison. It isn’t serious - and I doubt that any Model Xs will still be on the road in 50 years time. The Jensens on the other hand? Government will have to legislate them off the road - because they’re not going to stop running for any other reason.

  17. tiggity Silver badge

    Or that depends on a proprietary (apple) connection - all those (hardware) speakers etc. with "plug in your ipod" and they will play, be charged up etc functionality that were a tad scuppered when "old style" ipod / iphone connector replaced with lightning (albeit there are (not cheap) lightning to 30 pin adapters around to deal with that, not fun if soomeone has lots of hardware with old docks)

    1. 45RPM Silver badge

      @tiggity

      I had one of those speakers. A Bose. It was the work of five minutes to upgrade it to Bluetooth and a modern dock connector. It still sounds great.

      I take your point though - some people don’t have the ability to make the necessary changes.

  18. Tony Mudd

    Nothing to do with the "disagreement" Pure's owners (Imagination Technologies) had with Apple?

  19. John Savard Silver badge

    Fault

    While indeed I "can't fault Apple" for surprising developers with an unexpected change, I certainly can fault Apple for ever making this change at all, just as I can fault Intel and Microsoft for the fact that 16-bit Windows 3.1 programs don't work in 64-bit Windows, or I can fault Apple, Motorola, and IBM for the fact that 68000 and PowerPC Macintosh progrms don't run in today's Macintosh computers under the latest version of OS X.

    As far as I'm concerned, computer makers should take upwards compatibility seriously, the same way that IBM does with its zSystem mainframes.

    1. 45RPM Silver badge

      Re: Fault

      @John Savard

      Given the amount of extra work that would be required to support all that code whose only purpose is to run legacy code (and probably not very often at that), and the security nightmare that such a system would present, I am very grateful that support for this old software is being dropped.

      Besides, if you're one of the few who really needs an old program (I count myself amongst that number, by the way, since I'm not prepared to drop several hundred quid on a new copy of one of my most useful development tools), I recommend either using an emulator or keeping an old computer hanging around for that purpose.

    2. Enterprise Hamster

      Re: Fault

      It's hardly the fault of an OS/Platform developer that App developers don't have the revenant foresight or business models to take into account the glaringly obvious - hardware and software obsolescence.

      Without innovation we'd all be stuck in the IBM dark ages. The reason zSystem 'upwards compatibility' is so prevalent is because the majority of the stuff that runs on it is produced by IBM and is therefore equally archaic and because people who bought into zSystem paid a massive premium to be provided with enterprise support.

      A mobile OS, on the other hand, is designed to be low cost and flexible - so to blame the OS publisher/manufacturer for this is nonsensical.

      Blame the shoddy purvayor of the speakers for not building a resilient business model that takes account of entirely predicable industry developments (well signposted in advance). Manufacturers such as Bose, Sonos, Ruark, Ultimate Ears, Revo, Goodmans, Yahama, Denon and many more don't seem to have suffered the same issues.

    3. Anonymous Coward
      Anonymous Coward

      Re: Fault

      Yup - the day you pay the same for disposable technology as you would for a an enterprise system (which probably has some huge contract document attached) then yeah sure

  20. Anonymous Coward
    Anonymous Coward

    Mine is fine

    Ohhh Android..... #winner #yeah #haha #troll #incoming

POST COMMENT House rules

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

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019