Hacker News Reader

> the updated tools tend to drop support for older SDKs and devices. You have to kind of go out of your way to keep your app targeting them. You can see how this plays out by getting a second hand iPhone 7 today and go to the AppStore looking for apps. It will be very difficult to find an app that will run on it. This phone is not that old, but the ecosystem abandons you pretty quickly.

Well, you're mixing 2 things here: Apple's tooling support for older versions of iOS, and what developers choose to do.

Today, you can create a new app in Xcode, choose "iOS 15" as the minimum deployment version for your project, and you'll have an app that runs on devices going back to the iPhone 6S/first generation iPhone SE.

Even supporting back to iOS versions prior to that is fairly straightforward (you'll just have to edit a plist by hand rather than use the UI picker if creating a new project) - I have some older iOS 9 projects that still compile without any issues (just tested for the sake of this comment).

But to your issue of most apps not working on an iPhone 7 - that's because many developers will choose to only support iOS 16/17 or later (and the iPhone 7, a 9 year old device, stops at iOS 15). That's their choice though, not a failing of Apple's tooling.

Apple requires developers to build the apps with at least Xcode 16 targeting the SDK of least iOS 18 to submit new apps / updates to the App Store [1]. This limits how far back you can go with the iOS version, thus dropping older phones.

Yes, you can definitely download older SDKs and target older iOS versions, but you cannot publish those apps on the App Store anymore.

[1] https://developer.apple.com/news/upcoming-requirements/

That phrasing is misleading.

You can absolutely publish apps that target versions of iOS prior to iOS 18; eg all my apps are iOS 15+, I published one as recently as last week.

You can build an app with the iOS 18 SDK that target previous versions just fine (as long as your calls to APIs posterior to the version you’re targeting, if any, are wrapped in the proper macros) and submit them to the App Store.

So yes, you have to build your apps with the latest SDK to publish them - but that doesn’t restrict the target OS version in any way (ie I can build apps that target iOS 9 with the iOS 18 SDK).

Where it starts to be a pain for new apps built in 2025 is if you want to target pre iOS 13, as you’ll have to use the older AppDelegate mechanism, but still totally doable. (That’s getting deprecated with the next release, but deprecated APIs still build just fine).

This is different from the Minimum Deployment, which I current have set to iOS 12.0 in Xcode 16.2.

The "target SDK" and "minimum SDK" versions can be set separately. It's mostly just a cultural norm in the Apple ecosystem not to support older versions.

This is supported by 1. Apple being relatively good at releasing new versions iOS for older hardware. 2. Users (at least historically) typically being on a ~2 year upgrade cycle. But it's also just the case that the Apple ecosystem (including on macOS) tends not to value backwards compatibility as much as other ecosystems.

I just submitted a bug to Apple because of an api that crashes the simulator unless you target the latest version of iOS. On device you can target any previous version of iOS easily.

This is just one annoyance of many I encounter on regular basis.

They do go to great extend to allow you to support older versions, but they don’t make it always easy.

Last versions of iOS have been specially rough because SwiftUI has been constantly evolving, and keeping backward support is just a nightmare.

>and what developers choose to do.

I disagree. Developers are VERY strongly encouraged by Apple to move their minimum deployment versions up.

New APIs and frameworks are never backported (Swift Concurrency and the COVID tracking API were notable exceptions), and additionally if you dipped your feet into SwiftUI, you've essentially jumped into river rapids. Despite its age at this point, SwiftUI is still very immature, and all the new stuff to fix its holes requires you to jump up versions or fall back to UIKit.

I had to respond, not because I think you are wrong, but because I have had almost exactly the opposite experience and conclusions from you apparently.

> iPhone 7

I still have one as a TV device for me and my son to watch paw patrol. I can only speak for the set of apps I use on it, but as of a few hours ago they all still work (streaming, email, browser. no banking or other apps in that class). I am looking to replace it as it's no longer getting updates as of this march.

>This phone is not that old

Kind of very confused by this. It's 9 years old, it just stopped getting security updates three months ago. Is there anything even close to that outside of the iphone world? I do own android devices, I don't have anything android and nine years old that can turn on much less run an application.

I think it’s weird how confused people get when you suggest a 9 year old electronic device should work. Every computer in my house is over 10 years old. My A/V receiver and home theater speakers are 15 years old. My TV is 18 years old. My electronic thermostat is 11 years old. While they no longer receive firmware updates, they all continue to work as well as they worked on the day I bought them.

For some reason, nobody expects this of phones and tablets. The manufacturer cuts you off from updates and now somehow you’re obsolete! The 3rd party developer ecosystem pulls their old-device-supporting apps, and suddenly the device is useless. I don’t know why we accept this!

What is so special about phones where we allow them to be considered obsolete so quickly?

> My TV is 18 years old … they all continue to work as well as they worked on the day I bought them.

This is unlikely to be true. The process is slow so you may not have noticed it, but the tv is probably much dimmer than when it was brand new.

You may have a reasonable point about device longevity, but comparing full blown, internet connected, general purpose computing devices to an A/V receiver is obviously intentionally obtuse.

It's a Hitachi 42 inch plasma and it still looks absolutely beautiful. Not a single problem with it in almost two decades.

Want to know what failed first? The goddamn Mac Mini I have attached to it as a HTPC, where, after "upgrading" to Big Sur or Monterrey, suddenly Apple just up and decided to drop 1080i resolution support (the TV only supports 1080i, not 1080p).

The weakest link, in terms of longevity, is always the software developer.

You have undercut your case here.

The TV works and had not been upgraded. The mac mini works if you did not upgrade it.

The weakest link is doing an upgrade, it does not matter which hardware.

I think it’s unreasonable that Apple sold a device that is capable of displaying 1080i and then disabled it in a software update. Doing stuff like that encourages users to not update and leave themselves vulnerable to security threats.

It may be an unfortunate relic of the carrier upgrade economics. Most people, in the US at least, on a subscription phone plan get essentially a new phone for free every 2 years. Things are changing a little lately and now it’s not quite a free phone but a heavily discounted one, but it’s still pretty reasonable to expect most of your uses won’t have phone much more than a few years old.

I guess that means if we want to see this change we need to stop trading up every other year. Which would mean carriers need to stop charging $70/mo for a phone line. Etc. I don’t upgrade my thermostat yearly, the economics are different, and so the product approach is too. My thermostat also doesn't come everywhere I go on a daily basis and doesn't run apps (it’s not a general purpose computing platform that needs to grow more powerful as software becomes more demanding.

Also I have to add: phones are a fashion statement. Old phones do work, they’re just not cool. Nobody cares about the AV receiver sitting in your tv console as long as it’s amplifying audio. The tech hasn’t changed in years. Well unless your receiver does video, in which case I am certain your 15 year old audio receiver is not capable of 4k 120 HDMI handling. Update that TV to a 4k panel and your receiver will need a bump too.

The one thing in phones that was pulling people along to upgrade was the camera, but even that is leveling off now.

> get essentially a new phone for free every 2 years

What you mean to say is the payments for the phone (and the interest for the loan) are just bundled into the monthly plan.

The phone is categorically not free, the payment is just obfuscated to the point that many people don’t understand.

Of course. Either way you’re getting what you pay for and there’s no way to select “I don’t want a free phone every two years take $15 off my monthly payment please”. It kinda is moving that way now, though. The monthly cost for new hardware is increasingly more optional and better delineated from the phone service. But thats’s new stuff—it will take awhile for things to percolate down.

Of course there is!

Show up with your own phone and the plan options are entirely different and cheaper.

I’ve never had a plan where phone payments are rolled in.

They still offer(ed) you a new phone after two years. The “payments” are(were) hidden costs. I thought that was what we agreed on. 15 years ago there were no other options unless you did pay-as-you-go. Recently, yes, there are plans that let you skip the subsidized upgrade. They don’t cost any less than the plans that have upgrades did in the past though, they just cost less than other plans from the same carrier.

Not true at all. Where are you that is the case? I’ve done this in Canada, Australia, Iceland, the uk. Plans with a “free” phone every two years are something like 50% to 100% more expensive than if you walk in with a phone and don’t want one or upgrades and just get a plan.

That’s not how it worked in the US. I also stipulated that I’m talking about contract plans not pay-as-you-go. From my time in Europe I recall pay as you go being much more of a prominent option.

I am sympathetic to the argument/feeling that somethings last a long time therefore all things should last a long time.

> What is so special about phones where we allow them to be considered obsolete so quickly?

The phone / computer works exactly as it did when you bought it. What changed is everything around it. That's not true of those other things. New video codex, new services, new sites, new apps. Let's pick ChatGPT. They have app. It's about 2 years old? It strictly costs them more money to cover older hardware than just not supporting it. And, going forward, each year they want to support the newest phones/OS but keeping support for both strictly increases costs. I work on a project that run on nearly every device (Windows/Mac/Linux/iOS/Android) and we are always evaluating which devices we can stop supporting and what new devices we need to add to our testing infra going forward.

Your 18yr old TV is great. It works exactly as it did when you bought it. But for example, let say your TV was 25 years old. It wouldn't have HDMI and there for, without expensive adapters, would not work with an XBox, PS5, Switch (afaik).

The point is, your TV does exactly what it did when you bought it. No changes. For a smartphone to keep working requires constant changes. As a simple example, HEIF images didn't exist before. JPEG's with gain maps didn't exist. Zoom didn't exist. Etc... Your phone needs constant updating. Your TV, A/V receiver, speakers, thermostat do not. It costs money to keep the phone up to date. It costs nothing to keep the TV, A/V receiver, speakers and termostat up to date because there is nothing to update

But apple explicitly tries to make the environment around the old phone obsolete. They have an incentive to do so.

Your old TV still works even with an adaptor - but there's no such a method for the phone.

I want my phone to work until the hardware fails, not when apple decides they want to push people to buy a new one next quarter.

> "I want my phone to work until the hardware fails... But apple explicitly tries to make the environment around the old phone obsolete."

As of December 31, 2022, U.S. telcos* decommed the 3G tech phones of the mid-2000s used.

As long as your iPhone can still use the telco network, it still does the functions it shipped with just fine.

A phone's environment depends on a lot more than its hardware maker.

(FWIW, thanks to its different incentives than other handset makers, Apple continues to offer the longest average OS support of the hardware and OS giants. Google's Pixel 8 is the first to bump Google's 3 years to match Apple's 7, and Samsung's S24 also finally matches 7 years. So on current devices, they stepped up, but on devices before 2023, Apple's support is more than double theirs. Arguably, these two finally stepping up were in response to the "environment" of Apple's incentives and EU regs.)

* Verizon was the last. AT&T turned off its 3G network on February 22, 2022. T-Mobile dismantled Sprint's 3G CDMA network on March 31, 2022, and its own 3G UMTS network on July 1, 2022.

I have an iPhone 3GS from 2009. It still makes and receive phone calls and will pick up email. Some web pages will still render

I miss my 3GS. Jumped in a pool back in high school and fried it instantly. No water-resistance back then!

> The phone / computer works exactly as it did when you bought it. What changed is everything around it.

I consider that "everything around it" (The Ecosystem, as they say) to be part of the product I bought. When I bought my OldPhone N years ago, I could go to the app store and download versions X, Y, and Z of apps A, B, and C, and they worked. I expect today that if I factory reset that OldPhone back to fresh, I'd still be able to re-download those compatible versions of those apps, and that those apps continued to work as they did N years ago (barring some obvious, but still unfortunate cases like companies going out of business or turning down online services). That's my bar for "working."

If the world moves on, and people are sharing image formats that my phone was never able to read in the first place, or writing web pages my browser was never able to render correctly, then I have to accept that. But what I don't accept is the device manufacturer, or (usually the case) 3rd party apps telling me "your phone is too old, and we're no longer going to let you use it as you have for the last N years anymore!"

I’m confused, that is how it works. If a developer increases their target version to say iOS 18, a user running iOS 16 would be able to download the last app version that supported it, even after factory resets. If the third party developer dropped support for APIs or whatever to break that version, it’d be broken regardless to whether or not you had the app downloaded already.

I'm pretty sure what I've seen is: If you backup and restore your apps, the version you previously had gets copied back over. But, if you wipe and try to re-download, only the versions that the developer has up on the AppStore are available to you, and if none of them support your OS, you're hosed. This is definitely true if you set up the device with a new account.

I agree. Phones aren't increasing in performance all that fast any more and the use cases haven't really changed. OS and sdk makers should start to consider their tools "mature" and stop breaking compatibility with each and every update.

Something like the Go 1.0 compatibility promise.

> My TV is 18 years old.

Here they have turned off analog TV signals over a decade ago, and the national broadcaster are about to turn off standard definition digital TV signals in favour of high definition.

> It's 9 years old, it just stopped getting security updates three months ago. Is there anything even close to that outside of the iphone world?

Of course there is, just take a look at any computer/laptop.

For me, the some of biggest annoying about mobile app development is how the dev environment is space/RAM hungry:

- gradle folder easily reach 7 or 8 gigs per project (more external dependencies = bigger) - Android/iOS emulator also need something like 7 GB (per device). Imagine if you have 3 emulators: Pixel 3 running Android 13, Pixel 4 running Android 14, etc etc

Also agree code deprecation is something often happen. Most of my experience is Android, and yes I've seen emails from Google saying something like "if you don't need this feature, don't call API X and use Y instead. Failure to comply to this within 1 month will result your app is taken down." Oh well..

>> Code signing, provisioning profiles, entitlements, AppStore wizardry

Maybe it's because I've been doing iOS development since the original SDK, but this stuff is now super automated. I can't remember the last time I thought about any of it other than enabling some entitlements (and that's done in Xcode with a checkbox now).

>> Apple makes it difficult to maintain support for older devices.

I'm not sure I agree with this either. I work with a range of large iOS devs and they're all still supporting iOS 12 and 13 without much difficulty. Sure, you can't use the latest and greatest API's but there's nothing blocking you from using the API's supported by the older OS versions.

Regarding the iPhone 7 - it's very old. Nearly a decade old. And even at that it still supports iOS 15 which is only a couple of years old.

Generally I find indie shops will force you to use the most recent couple of OS versions because they want to use the new API's and don't want the overhead of maintaining support for older ones. Any app that's relying on having lots of users is supporting as far back as possible (particularly when it comes to iPad because those users keep their devices far longer).

Yeah, I hate the code rot that the push for the latest SDKs brings. I’ve kept old Xcode versions around, and don’t jump for every OS update so _those_ don’t rot. Kept an app (useful to dedicate old devices to) running on iOS 9 until last year. Probably could’ve gone longer with containers.

There's also the frustration where an Xcode can target iOS versions lower than the iPhone simulator's minimum. I was targeting iOS 12 for a while but it was a pain having to get UTM and an older version of Xcode just to debug/test it.

The solution for code signing is coming: through jailbreaks or appdb.to, it's possible to sideload apps without the official app store process. The EU even mandated that there should be other app stores.

Building for older models is possible using a collection of virtual machines, or even a multi-boot old laptop.

a) You still need to code sign on alternative app stores.

b) All of your users are still going come through the Apple one.

Reg B... Will they? From what almost everyone I have heard from says, most of their users come thru their own marketing efforts, not Apples.

I'm in embedded development right now (switched from EE, because higher pay, easier to find clients and more flexibility).

Would you recommend the switch from embedded to app writing?

What I'm looking for: more location independence (no on-site work) and more clients/work/jobs.

What about switching from app dev to embedded? Is an EE knowledge required?

Depends on how close to bare metal you are. However, the money you make will decrease substantially.

> the money you make will decrease substantially

Due to oversupply of Embedded Developers?

Compared to the market size, yes.

yeah, no. I do both (and to the user asking for an opinion wether to switch from embedded to app.. don't!) and i loathe making apps. Sure, the dev tools are supposedly better, more modern.. but they are also an evermoving target. You can never declare a project done.

This is because every new OS update breaks compatibility in subtle ways, or new requirements or behaviour changes remove capabilities you were using before and were essential for your app, or simply: the new major update breaks BLE / Wifi / Background operation and you waste three weeks of your life trying to make it work again, only to find that an OS update restored things. This happens every single year, at least once.

Then you have the store policy (Play store for example) that changes the Target SDK so you MUST recompile the app with the new SDK or else, and the iOS certificate expiring every year so you have to pay for the privilege, then you have to recompile / resign... which means that the project must be compilable at all times, and every year the SDK version changes, the toolchain changes.

In the embedded world i can effectively freeze the development environment, with my ancient GCC version, and it will work forever. Well, that's not really true anymore if you use Zephir, IDF or other framework monters :(

$100 a year is nothing

> $100 a year is nothing to me

Added missing context.

It's a week's salary for a typical junior developer in my neck of the woods.

Is your junior developer ChatGPT pro? It's either that, or you live in Zimbabwe

> It means you can't sustainably release free apps unless you're willing to just ignore that you're burning $100 a year forever.

The fact that this $100 yearly fee has never been adjusted for inflation, in a time when developers are easily shelling out $200 a month to use LLMs, makes this gripe all the more petty. Especially when software developers are still among some of the highest paid jobs on the market.

Back in the days of newgrounds, a bunch of kids learned to program by picking up flash, making games, and sharing them with their friends. That would not have happened if you had to pay even $1/year to publish a .swf file.

Now, their friends all have iphones, and if a kid could hack out an app for their friend group and share it around, it would give them great motivation to learn and hack in that ecosystem.

It's kids, idealistic OSS hackers, and people in the global south who see the $100/year and give up.

It's also just plain dumb rent-seeking that no other OS does. I can make an APK for a friend for free, I can make an exe for a friend, an elf for a friend, etc.

Yet, even if I live in the EU and thus can distribute apps to my friends to sideload directly, even then I'm required to pay $100/year or my app stops working.

The AppStore is not the internet. There is no reason for it to be polluted with everyone’s throwaway side projects.

Even more of an argument for free sideloading then. Ping your friends a URL, they click it and can install your app. All without the need for an App Store.

The $100 isn't just required for the things published to the AppStore.

It's required for a sideload app in the EU. It's required to make a testflight app that isn't discoverable on the app store, but people can opt-in to running (though apple still heavily restricts what apps you can publish via testflight, it's not a substitute for sideloading).

> There is no reason for it to be polluted with everyone’s throwaway side projects.

Too late for that, the app store already has a huge amount of trash on it.

If apple insists that the appstore is the only way to get software on a computer in my pocket which I paid for and own, then yes, they are obligated to let me put trash on it.

If apple won't let people put anything on it (as they don't), then they should be obligated to let me install devices in another way.

It's already incredibly silly that if I want to just have my own simple app (like idk, a native app that lets me upload a photo to my personal archive over a custom protocol I use), I have to jump through hoops as if I want the whole world to use it, even if I never intend for anyone outside literally just me to touch it.

It’s a phone, not a computer. It’s not sold as a platform for developers to tinker around doing whatever they want. It’s primarily a lifestyle device and businesses can produce apps for it. That’s it. You don’t get to put your own software on everything that has a computer in it: cars, consoles, appliances, etc.

You're speaking of kids.

What kids? We don't really make much kids anymore in the developed world :p

Just wait 30 years and the problem will be fixed.

> a bunch of kids learned to program by picking up flash

flash does not have a free version (and i recall a trial version is locked after some days of usage). Guess where they got their flash development/program from?

> Now, their friends all have iphones, and if a kid could hack out an app for their friend group and share it around, it would give them great motivation to learn and hack in that ecosystem.

You can create apps on the iPad and share the source bundles with friends without a paid account https://developer.apple.com/swift-playground/

edit: To be clear, I'm not defending Apple here, I'm still 200% in favor of "let people run the code they want on the device they own", what I'm trying to say is just if you're a kid who wants to do this, you already can!

I get your point but if they can't afford the $100 for the dev account they probably also can't afford the Mac to build the apps.

It's not one or the other, it's one on top of the other. I sometimes get the urge to develop a little app for my phone, and I can do that and install it easily for free. I can also distribute it to others for free , even through alternative app stores. And if I want it to be more official, a simple 25€ fee for life and I have it on that google app store.

Maybe in the US, spending 100$ per year for a small hobby is nothing to think about, but In most countries in the world, including the EU, it's something that will compete against other spendings, even if only for other hobbies

But I agree with you that the requirement of having a Mac to develop for iOS is even worse

The difference is that LLMs are optional, but the Apple tax is mandatory.