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?
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 …
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.
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.
@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.
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.
@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.
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...
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
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?
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.
"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)
@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.
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)
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.
@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.
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.