Hacker News Reader

Comment by superkuh | Hacker News Reader

Everyone is jumping on the bank for not staying up to date with the frequent and massive chanages that Apple makes. But this is only a news story because it is a bank, this scenario happens constantly to a large fraction of all iOS software. The problem here is that modern libs and standards change so fast (similar to JS) that it really is hard for anyone without a megacorp's worth of software dev employees to keep up.

This isn't just this bank. This is many. And this is future shock.

View on HN

> The problem here is that modern libs and standards change so fast (similar to JS) that it really is hard for anyone without a megacorp's worth of software dev employees to keep up.

Are you so sure of this? I have apps that haven't been updated in years that still run on my iPhone 13 Pro Max using latest iOS.

As an iOS dev of 7 years, year to year changes are generally mild and impact is generally low, particularly if your app is built with UIKit.

For the past 4-5 releases the worst I’ve seen in the apps I’m responsible are a small number of minor non-breaking quirks… think things like a button rendering slightly oddly. It’s never been beyond what a single dev could handle.

Android on the other hand…

>Android on the other hand…

Yeah. Hence why Kotlin is a dead end and React Native is more or less the new standard.

I am not an iOS dev, but is it possible that banking apps (and I admit they're slow at adapting) depend on certain APIs that have changed, or Apple deciding to enforce a use of a specific API for a specific type of apps?

I am asking to learn.

It’s definitely possible. But iOS deprecated APIs, iirc, it doesn’t just delete them. (At least that’s what I remember from iOS dev four years ago.)

I conjecture that the bank didn’t bother to test the app on a new version of iOS until this week, found a major bug, and knew they couldn’t fix it fast enough.

But they could have tested three months ago when the beta came out, and any major issues (like using an old API) probably would have occurred then.

With a few exceptions (mainly where hooking into the kernel is concerned), deprecated iOS/macOS APIs tend to hang around for many years after deprecation.

If I coax a random FOSS Mac app project from the early to mid 2000s into compiling on modern macOS there’s usually deprecation warnings left and right, with many of the deprecations having happened in OS X 10.2-10.6 (well over a decade ago), but it’ll still work fine.

So devs usually have plenty of chance to move things over. The grace period just isn’t indefinite like it is with e.g. Windows — sometimes the deprecated APIs are removed 5-6 releases down the road and so it’s a good idea to move off of them sooner than later.

Apple releases an update once a year and they give several months of betas where app devs can test and prepare. That’s more than enough for supported apps.

Still pretty embarrassing when Microsoft maintains backwards compatibility for decades.

That backwards compatibility has also infamously been a ball and chain on Windows development. It doesn’t come without tradeoffs.

Providing backwards compatibility for decades has some serious tradeoffs. Breaking apps that were using the most up-to-date APIs three months ago is simply amateurish.

It's clear that Apple has no respect for developers on their platform.

As mentioned in other comments, it's very unusual for undeprecated APIs in iOS to break badly from one release to the next, at least the time I've developed for the platform. Usually if something is that broken it's because the app in question was using an API that was deprecated years ago despite repeated warnings.

This is why I don’t like developing on Windows, everything has 10 layers of complexity. To write a script for something that should be a simple task, I need to either reengineer the exact environment settings used in the UI or write an additional script to find the correct executable (with all the overhead of running the executable) to recreate the state needed to run a single command.

Not embarrassing, its a deliberate strategy to keep the platform moving forward.

Backwards comparability doesn't prevent forward movement. Moving forward is an overused tagline from every meeting ever anyway. If we move along a path does the path behind us crumble into the abyss?

I see this as Apple breaking the app. Demanding and nudging users to auto-update the iOS, the consequences being the OS fails to run what it previously could run.

Apple literally removed chunks of the processor that was needed to run 32 bit software to make room for more forward looking features.

Backwards compatibility would mean that MacOS should still have support for 32 bit apps? PPC apps? 68K apps? Should they have ported Carbon to 64 bits? Should they have kept support for QuickDraw from the 80s? QuickDraw GX from the 90s?

A smartphone that fails to run a banking app that worked literally "yesterday" is not the same as 32bit deaktop apps no longer working on 64bit systems.

Either way, I expect my PC to be capable of running old software including 32 bit apps. My 64bit Windoze machine does that.

> removed chunks of the processor

Did users petition for the chunks to be removed?

It's not like 32/64 bit applications are equivalent to VHS/DVD, where hardware is obviously different. But even then, I own this DVD/VHS combo player: https://www.lg.com/au/dvd-blu-ray-players/lg-RC689D

No, users appreciate having better photography because the die space that was used to run 32 bit apps can now be used for other features. They appreciate their memory not being used to hold both 32 bit and 64 bit versions of shared libraries. They appreciate their apps not being purged from memory because of memory being taken up by the 32 bit and 64 bit libraries. They appreciate the better battery life because Apple could add features and reduce the size of the chip.

Your x86 PC that you appreciate being able to run 32 bit apps, also can’t last 20 hours on one charge, the integrated graphics are much slower and it probably sounds like a 747 under load compared to the fanless MacBook Air.

32/64 bit applications are in fact the equivalent of VHS/DVD combo players. Each instruction set is duplicated and shared libraries are duplicated. If you have some 32 bit applications in memory and some 64 bit applications in memory, you have duplicate libraries in memory.

Off track now, 32/64 bit is drifting too far from a banking app that works fine on iOS 15 but not iOS 16. Looks like they fixed the app anyway, as the message on the link has changed and is advising people to update app.

I use a desktop machine primarily, no battery issues, no memory issues. Purrs like a kitten under load. I like pushing 3D graphics and having lots of headroom in general. A MacBook Air won't cut it for my purposes.

I suppose rejecting backwards compatibility is better for business: Competition from older software is no longer a problem.

I still use Photoshop CS6 (2012) because it does what I need. My work laptop has latest Photoshop and while some of the new tools are nice, I don't see 10 years worth of innovation. I see a software company's nagging efforts to enforce cloud dependency, hustle users with sneaky price hikes, and even spam the email addresses of licensee seat holders with "trusted partner" junk.

So Apple had a beta period that gave developers a chance to test for compatibility and either Apple fixed the underlying issue before the OS released or the developer fixed their app. Either way, things worked as expected.

Photoshop actually is another example of things working as they should. Adobe has ported Photoshop from 68K, to PPC, to OS X, to x86 32 bit, to x86 64 bit, to ARM.

As far as subscriptions, I don’t use Photoshop. But back in the day, one seat of MS Office use to be $600. Now I can get a 5 user license of Office where each user can use Office on any combination of Macs, Windows PCs, iPhones, iPads and the web plus 5TB of cloud storage for $99 a year.

The vast majority of people are using laptops. But even desktop ARM Macs are seeing the same benefits from being able to ditch backwards compatibility.

> "But even desktop ARM Macs are seeing the same benefits from being able to ditch backwards compatibility."

Because who doesn't want better battery life for their desktop machine? Or quieter fans or more memory.

Desktops have plenty of RAM, enough to not worry about whatever insignificant benefits you're talking about that may arise from ditching backwards compatibility. Which by the way, has never been an undesirable feature. You're just trying to sell it as undesirable by claiming users are in great debt to those who decide to take away the option to run older software.

Apple has stated they will delete iOS apps from app store if they haven't been updated in awhile even if they technically still function. This will lead to a farcical situation of updates for the sake of updates, which is no doubt happening now anyway to get attention. "Remember me? I'm the app you haven't touched in a few months, here's an update!"

You're a subscription apologist and you dislike backwards compatibility. Your position is unconvincing in this discussion, but it sounds like you're happy! All the best.

Because Microsoft focuses on legacy enterprise convenience while Apple focuses on end user convenience.

They've had 3 months to test the new iOS software. That's the whole purpose of WWDC in June and new OS coming out in September

oh really? Three whole months? Shame on them /s

To be fair, iOS version increments usually aren’t rocket science if you don’t want to take advantage of all the new features right away.

That's been how it's been for years now. Every year. I'm sympathetic to the argument that that's not enough time, but if your company has a mobile app on iOS and you're not planning to do this work every summer in time for the September release then it's a pretty major failure of planning.

If you need to do months of work every summer to keep up with iOS updates you need to look at what you’re doing wrong, unless you’re simply adopting new features every time. Things should generally just work. Apple doesn’t usually break well-behaved apps (usually).

For sure, but you at least need to plan to maybe have work to do. Either to proactively support new features/devices or any necessary updates. If you're hitting September and your app is still broken, something has gone wrong.

You just need to plan to test your apps every Summer. And maybe extra time for implementing new platform features, like log-in with Apple and whatnot. But it’s still a yearly routine!

Why the /s? Three months is a _very_ long time in software. This isn’t retooling physical metal for a new car model year; it’s minor software tweaks at best. Most developers don’t actually need to do anything.

> Three months is a _very_ long time in software

No, its not. For example, I use an open source app called fd:

https://github.com/sharkdp/fd

I have not updated it since 2020. Yeah, new versions are available, but the old one works fine, so no need to even upgrade. You shouldn't have to get every single version of software just because its available.

What exactly is the point of all these releases if you don't upgrade?

Do you think Apple just releases new versions of iOS with API changes to keep developers shipping new versions or something?

I don't understand this mentality that just because v1.6.3 is available you don't HAVE to upgrade from v1.2.1.

There's obviously new bug fixes and features available to you.

The only reason I would say not to upgrade is because your device doesn't support the new version and in that case you CANT upgrade.

Right, but since when does Apple (or any company) get to dicate what versions of software that I use? Granted in some cases, forced upgrades are a thing. But I am a human being with agency, I can make my own decisions on what to run on my own computer/devices.

I don’t think it’s crazy for any company to want more than 3 months to support a new OS.

This specific situation is unfortunate, but I’d expect many other companies to have a mildly broken app for a few months. In particular, the punch hole gimmick was kept a secret and I’d expect apps who expected no touch target in that area to have to rethink a bunch of assumptions.

Out of ignorance I ask:

Why aren’t there LTS versions of iOS?

As a long time iOS user each year brings a bit of change with improvements just barely better than regression. Under the hood, what changes so much as to consider it a major upgrade with breaking changes?

The MS pattern of deep support of legacy API for applications seems too extreme in the other direction. However iOS has long sense reached a point of maturity where annual breakage is also an extreme.

> LTS versions of iOS

I think that would be cool for users that want security and don't want the new features or new design.. But it'll be used as an excuse for certain apps to not keep their up to date with the newest APIs.

As for the company, they often use the OS version to drive more sales. The new OS almost always requires a little bit more performant hardware. The older the phone, the slower it gets with the newer OS.

There is, once your phone can’t support the latest version of iOS, you are de facto on the LTS version where Apple will provide security patches as needed for years. iOS 12 just got a security patch for the iPhone 5s (circa 2013) last month.

How does it benefit consumers, developers, or Apple to support older OS’s on phones that can support the newest version?

If value of new features is less than lost value in regression then a change doesn’t benefit consumers.

For example, I wish that they didn’t support OG SE on 15 since there were goose-egg OS level improvements and giant regression in battery with 15.6.

Case in point: this morning I visited a recipe website and my phone is now hot to the touch.

Bilal_io's point on driving phone sales is spot on.

To add to that, phones have no OS downgrade process, so even if as an app provide you decide you won't support the latest OS, every new phone bought from now will still come with it, and the user can't do anything about that.

A LTS would require to also get read of the version up rachetting.

I would criticize the bank for suggesting to non-technical customers to disable automatic updates.

I think that’s a major security issue for the average person.

Companies like this act like their services are special and that customers should bend over backwards to accommodate their own shortcomings.

It's hard to really make a judgement one way or the other without knowing the technical and organisational reasons in the first place.

Maybe their iOS dev left a few months ago and there are large changes needed they haven't been able to pull off in time? Maybe there's a very specific issue/bug they're having trouble to work around? Maybe they actually did make an update but it got rejected in the (in)famous "Apple approval process"? Something else? Who knows...

Whether or not a company can get apps updated in a reasonable window - or whether a bank having “an iOS dev” is reasonable, or not, it is simply unforgivable to suggest that people turn off operating system upgrades.

The reasons are interesting on a human level, but on a professional basis they should have had a plan months ago.

Maybe the did have a plan but something went wrong at the last minute; or maybe not and they just messed up. We don't really know that.

Marco Arment (Overcast) and David Smith (slew of apps) would argue differently

https://marco.org/apps

http://david-smith.org/apps

Marco did have a pretty massive rant this year about how terrible the beta process was and how he was getting told that bugs filed in July were "too late" to be fixed. It's certainly not a friendly process for small devs, but OP is definitely overstating how hard it is.

The iOS betas have been available to the bank for three months prior to the public release, every year since they first signed up for a developer account.

If this is their first year dealing with an iOS update, they have my sympathies.

If the bank has spent the past 90 days trying and failing to make their app work, they have my sympathies.

If this is not their first year, and they chose not to bother testing their app until the release candidate was issued this week, they do not have my sympathies.

Reply on news.ycombinator.com