# Transitioning iOS versions

DevFeed: [Transitioning iOS versions](<https://devfeed.tech/articles/transitioning-ios-versions-21610.md>)

Original publisher: [Read original article](<http://miqu.me/blog/2015/12/14/transitioning-ios-versions/>)

Author: Miguel Angel Quiñones

Published: 2015-12-14T20:00:25Z

Content type: article

Language: en

Sources: [Miguel Quinones](<https://devfeed.tech/sources/miguel-quinones.md>)

Topics: [iOS](<https://devfeed.tech/topics/ios.md>), [SDK](<https://devfeed.tech/topics/sdk.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>), [Code](<https://devfeed.tech/topics/code.md>), [Operating system](<https://devfeed.tech/topics/operating-system.md>)

Tags: [apple](<https://devfeed.tech/tags/apple.md>), [compatibility](<https://devfeed.tech/tags/compatibility.md>), [deprecated](<https://devfeed.tech/tags/deprecated.md>), [improvements](<https://devfeed.tech/tags/improvements.md>), [ios](<https://devfeed.tech/tags/ios.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [sdk](<https://devfeed.tech/tags/sdk.md>)

## AI overview

This article discusses how iOS developers can manage annual OS and SDK changes in long-running applications. It focuses on maintaining backward compatibility, supporting current and older iOS versions, handling deprecated APIs, and allocating engineering effort for transitions while continuing to deliver features.

## Source excerpt

Having worked in companies developing their own products, I've faced many times the problem developers encounter when building iOS applications: Your biggest 3rd party dependency - the OS SDK - is changing under you every year. How does your team deal with this in a maintainable way? Long-term projects Unless you do consulting or freelancing, chances are that you will have to deal repeatedly with evolving code in the same project over the years. Even if you jump from project to project, chances are you land into existing projects where there's some code written some time ago. In longer projects software rot stays and the team needs to deal with it. A successful application will face this earlier than expected, and in the fast-paced market of mobile applications, every year Apple is renovating and ruthlessly changing the Operating System where our code lives. It requires non-trivial amount of work to keep up with changes, while still delivering improvements and features for our users. I've worked in teams where these questions were often raised: How do we keep modernising our code, while maintaining backwards compatibility for our users? What techniques can be use to keep moving fast, while still supporting older OS versions? How do we approach throwing away old code using deprecated APIs in a big codebase? How do we write new code taking into account that we will remove support of an older OS version? Fragmentation As I wrote before, developers in the Apple ecosystem face a different kind of fragmentation. We're forced to adopt breaking changes every year, or 'die' in the process. Apple forces us to start using new features of the OS, and has a policy of deprecating APIs a lot faster than we like. Instead of supporting a lot of older devices and operating systems, we face many breaking changes every year. A mobile engineering team should embrace change, knowing they'll need to assign some engineering resources to keep up with code changes required to support new and