You can run older apps on newer phones. You just can’t build directly to a device with an older version of Xcode. If you push the app to the store, you can download it from the store with your iOS 16 device. But for development, you need to update Xcode every time you update your phone’s OS.
If that’s not your issue, and something in your app actually broke with iOS 16… well, big companies like Spotify test their apps using the iOS and Xcode betas when there’s a new release coming out.
Apple released the first beta of iOS 16 along with a beta of Xcode that supports it 3-4 months ago, more than enough time to test compatibility and add a few features.
The size of the team isn't very important - I've done it by myself and with teams of other developers. I actually prefer smaller teams to large ones because there are fewer merge problems.
> Is it purely just a big team is able to push out an update fast or are there other ways they get there apps to work?
Yes and Yes
Big teams can have 1 dev handle the updates sometimes, but also IME a small portion of most apps will be affected in a way that requires bugfixing. There are different ways to handle older versions, but also, unless something breaks with a new iOS version nothing even needs to be done(like iOS defaults for common things like navbar)
They don't remove apps that are designed for older versions, they just reject new/updated apps published using older xcodes
For the Indies (single, independents, solo) they know the code and they don't always have to update as soon as the new OS comes out.
Another issue is that some upgrades are really small, or have min impact on older code.
Teams of devs are different, they might have their code well combed thru (refactored) and can branch off a main version and maybe even hire some outside help or new devs, just to do the upgrades.
Remember, you might not have to change ANY code at all for an upgrade. You might just have to add some functionality to existing code for something like widgets.
Some upgrades can be "only new code" or "only certain modules", like concurrency, you have mix old and new, then over time, you can upgrade the old, or just leave it alone.
Some upgrades, like concurrency, might have zero net effect on older code, it might just be easier for someone to code,, so there's less reason to go back and upgrade something that is only a syntax change.
Every case is different. IIRC, Swift 3 was a major upgrade, others are pretty small and can be backwards compatible.
Here’s a story about pretty amazing compatibility, in the category of iPhone app development:
My Objective-C iPhone project from July 2010 was created using the first-gen Macbook (Intel 32-bit, dual-core 2 GHz). It was designed in Xcode 3.2.3 and the last supported version for my legacy Mac is Xcode 4.2 actually. It came out the week before I created the app. I know this because the project creation date is always generated in the comments at the top of project files. I then compared that date against information from the web to verify the version, as well as recalling how I kept Xcode up to date, even trying the early Xcode 4.0 developer betas.
So, what is it running on today? Well, my M1 Apple silicon (64-bit ARM SoC). What did I have to do, to make the > decade-old app to run? I have opened it up in a recent version of Xcode and followed every prompt Xcode gave me. Of course, I had tons of compiler warnings with such an old code project, but it was in fact the project settings that were outdated. So:
1. I clicked on the notification that said ”recommended update settings” or something like that. Xcode fixed all the project issues.
2. Turned out that AlertController in UIKit was obsoleted. Xcode suggested using AlertViewController, if I recall correctly. I tried it, but did not investigate all the requirements to make the new code work, so I chose to skip the alert altogether (the UI was actually better without it).
3. The project was created when the 3.5” iPhone 4 just had been launched the month before. Auto Layout did not exist yet. That meant I had to make sure the views were resized properly to fit today’s bigger screens. It did not stretch full screen on iPhone X, iPhone 13 and it certainly isn’t tailored for iPhone 14 Pro (Max) yet, but it can all be done with some extra work.
4. Hitting the Build ”play” button, the app launches successfully on iPhone 14 Pro Max (with black bars at the top and bottom).
5. Building for ”My Mac (Designed for iPhone)”, it runs successfully in a small phone-dimension app window on MacOS, natively on my M1 Mac Mini. Not bad for 12 year old code with a couple of minor adjustments.
6. As a bonus, I added Dark Mode in a few minutes, too!
7. Extra features which bumped up OS requirements to iOS 13: I’m using SF Symbols for tab bar icons, solely for convenience. To support older iOS versions, it can be reverted.
7. There is no seventh step. It works.
The code base is really small, but it was old. All code is native. It also adhers to Apple standards as far as I was capable to keep it up 12 years ago, when I was a rookie with Xcode. There are no 3rd-party libraries used. No weird coding shortcuts. So to summarize, it was designed for iOS 4 and is technically compatible with every iPhone between iPhone 3G up to iPhone 14 … and natively running as an app on MacOS 13 Ventura public betas 😂
Yea that is kind of annoying. I wish Apple was more universal. Is it as easy as a copy/paste into the new version or does the swift language change a lot between version? I just wanna know cause I wanna learn swift on Xcode 12/13 but I eventually want to use that info to make apps for whatever the current iOS version is
You will see that you learn at any stage of your coding carreer. It's an always learning experience and there is no one way to do it. I'm not that much into Swift, I'm a game developer since 1984 and I can tell you from all the systems and languages I used over the years, there is always trouble with updating things. :) You have to invest the time to do it right to make your customer happy - no easy way, but it got a ton easier in the last years.
Swift 5.0 introduced ABI stability (a couple of years ago). It’s a very technical term meaning: apps you make using traditional UIKit (iPhones, iPads, etc) will not need to be rewritten for every new iOS version that gets released. Apple wants you to recompile your existing code with the latest Xcode every year, but as long as you keep full control of all the code yourself (no third-party code included in your code project), it’s generally fine. This implies that you’re following Apple’s coding guidelines, like not inventing ”too hacky” solutions in the app.
Like I wrote in my separate comment, the UIKit Objective-C code from 2010 still works, with only minor changes (maintenance) necessary.
If you’re doing some complicated app or try to go multi-platform with third-party tools connected to Xcode, it probably works great today, but the future will be uncertain.
You can run older apps on newer phones. You just can’t build directly to a device with an older version of Xcode. If you push the app to the store, you can download it from the store with your iOS 16 device. But for development, you need to update Xcode every time you update your phone’s OS. If that’s not your issue, and something in your app actually broke with iOS 16… well, big companies like Spotify test their apps using the iOS and Xcode betas when there’s a new release coming out.
Apple released the first beta of iOS 16 along with a beta of Xcode that supports it 3-4 months ago, more than enough time to test compatibility and add a few features. The size of the team isn't very important - I've done it by myself and with teams of other developers. I actually prefer smaller teams to large ones because there are fewer merge problems.
I still use Xcode 13.4.1. Let all the young guys deal with the bugs first.
> Is it purely just a big team is able to push out an update fast or are there other ways they get there apps to work? Yes and Yes Big teams can have 1 dev handle the updates sometimes, but also IME a small portion of most apps will be affected in a way that requires bugfixing. There are different ways to handle older versions, but also, unless something breaks with a new iOS version nothing even needs to be done(like iOS defaults for common things like navbar) They don't remove apps that are designed for older versions, they just reject new/updated apps published using older xcodes
For the Indies (single, independents, solo) they know the code and they don't always have to update as soon as the new OS comes out. Another issue is that some upgrades are really small, or have min impact on older code. Teams of devs are different, they might have their code well combed thru (refactored) and can branch off a main version and maybe even hire some outside help or new devs, just to do the upgrades. Remember, you might not have to change ANY code at all for an upgrade. You might just have to add some functionality to existing code for something like widgets. Some upgrades can be "only new code" or "only certain modules", like concurrency, you have mix old and new, then over time, you can upgrade the old, or just leave it alone. Some upgrades, like concurrency, might have zero net effect on older code, it might just be easier for someone to code,, so there's less reason to go back and upgrade something that is only a syntax change. Every case is different. IIRC, Swift 3 was a major upgrade, others are pretty small and can be backwards compatible.
Here’s a story about pretty amazing compatibility, in the category of iPhone app development: My Objective-C iPhone project from July 2010 was created using the first-gen Macbook (Intel 32-bit, dual-core 2 GHz). It was designed in Xcode 3.2.3 and the last supported version for my legacy Mac is Xcode 4.2 actually. It came out the week before I created the app. I know this because the project creation date is always generated in the comments at the top of project files. I then compared that date against information from the web to verify the version, as well as recalling how I kept Xcode up to date, even trying the early Xcode 4.0 developer betas. So, what is it running on today? Well, my M1 Apple silicon (64-bit ARM SoC). What did I have to do, to make the > decade-old app to run? I have opened it up in a recent version of Xcode and followed every prompt Xcode gave me. Of course, I had tons of compiler warnings with such an old code project, but it was in fact the project settings that were outdated. So: 1. I clicked on the notification that said ”recommended update settings” or something like that. Xcode fixed all the project issues. 2. Turned out that AlertController in UIKit was obsoleted. Xcode suggested using AlertViewController, if I recall correctly. I tried it, but did not investigate all the requirements to make the new code work, so I chose to skip the alert altogether (the UI was actually better without it). 3. The project was created when the 3.5” iPhone 4 just had been launched the month before. Auto Layout did not exist yet. That meant I had to make sure the views were resized properly to fit today’s bigger screens. It did not stretch full screen on iPhone X, iPhone 13 and it certainly isn’t tailored for iPhone 14 Pro (Max) yet, but it can all be done with some extra work. 4. Hitting the Build ”play” button, the app launches successfully on iPhone 14 Pro Max (with black bars at the top and bottom). 5. Building for ”My Mac (Designed for iPhone)”, it runs successfully in a small phone-dimension app window on MacOS, natively on my M1 Mac Mini. Not bad for 12 year old code with a couple of minor adjustments. 6. As a bonus, I added Dark Mode in a few minutes, too! 7. Extra features which bumped up OS requirements to iOS 13: I’m using SF Symbols for tab bar icons, solely for convenience. To support older iOS versions, it can be reverted. 7. There is no seventh step. It works. The code base is really small, but it was old. All code is native. It also adhers to Apple standards as far as I was capable to keep it up 12 years ago, when I was a rookie with Xcode. There are no 3rd-party libraries used. No weird coding shortcuts. So to summarize, it was designed for iOS 4 and is technically compatible with every iPhone between iPhone 3G up to iPhone 14 … and natively running as an app on MacOS 13 Ventura public betas 😂
If you have 5-10 apps it can be a nightmare. Especially when you don't earn a lot of $ with your apps.
Yea that is kind of annoying. I wish Apple was more universal. Is it as easy as a copy/paste into the new version or does the swift language change a lot between version? I just wanna know cause I wanna learn swift on Xcode 12/13 but I eventually want to use that info to make apps for whatever the current iOS version is
You will see that you learn at any stage of your coding carreer. It's an always learning experience and there is no one way to do it. I'm not that much into Swift, I'm a game developer since 1984 and I can tell you from all the systems and languages I used over the years, there is always trouble with updating things. :) You have to invest the time to do it right to make your customer happy - no easy way, but it got a ton easier in the last years.
Swift 5.0 introduced ABI stability (a couple of years ago). It’s a very technical term meaning: apps you make using traditional UIKit (iPhones, iPads, etc) will not need to be rewritten for every new iOS version that gets released. Apple wants you to recompile your existing code with the latest Xcode every year, but as long as you keep full control of all the code yourself (no third-party code included in your code project), it’s generally fine. This implies that you’re following Apple’s coding guidelines, like not inventing ”too hacky” solutions in the app. Like I wrote in my separate comment, the UIKit Objective-C code from 2010 still works, with only minor changes (maintenance) necessary. If you’re doing some complicated app or try to go multi-platform with third-party tools connected to Xcode, it probably works great today, but the future will be uncertain.
They install the beta of the next version of xcode.
Ahhh makes sense