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 …

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.

40
2
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.

31
19
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.

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

19
1
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?

7
0
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
1

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.

7
1
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
5

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.

4
0
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.

0
3

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

0
2
Bronze 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
0
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.

0
0
Silver badge

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.

40
1
Silver badge

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.

26
0
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. ;)

19
0
Silver badge

Re: Customer beware/blame the buyer?

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

2
0
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
0
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?

10
8
sgp

Re: Commentards obviosly know more than mere mortals

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

6
1
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.

28
1

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.

11
4
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.

9
0
Silver badge

They thought they could outsource responsibility.

Many firms do, thinking that management simply means calling the shots. Some, unfortunately, learn too late that it also includes planning.

25
0
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.

17
1
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.

10
0
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.

3
1
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.

27
0

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?

0
0
Bronze 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.

0
0
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?

2
21
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?

1
5
Silver badge
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"

41
1

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

18
0
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?

10
2
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.

5
0

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

2
1
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.

20
2
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...")

4
0
Anonymous Coward

Re: Twats.

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

3
0

Re: Twats.

Pure are the Rayners of the audio world ?

1
0
Silver badge

Re: Twats.

Ratners?

1
1

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

9
11
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.

6
1
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
3
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.

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

2
1
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 :)

13
2
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.

4
4

Page:

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

Forums

Biting the hand that feeds IT © 1998–2017