While you, as the developer, can control when your apps and servers are released and updated neither you nor anyone else can control the entire collection of devices which will be running your app. Your users will update their devices on different schedules or not at all. Leaving you with a range of different application version in the wild. For networked applications this may be problematic as you might have different application versions using different api versions to communicate with your server or with each other. I’ve found it helpful to introduce api versioning to a project as early as possible. There may not be any need to support multiple api versions immediately but having a strategy in place to move from api.example.com/1/ to api.example.com/2/ when you need to change an existing api call can make your next app release much smoother.
In addition to supporting users of different api versions apps also need to be able to handle upgrades locally. If you change the format for storing data on disk, or in core data, or in the keychain between application versions have a plan for migrating user’s existing data when they upgrade (or at least don’t crash trying to read an old data format). Your application will also need to handle users who upgrade from version 1 directly to version 3 without failing because you lost track of what changed in version 2.
As the administrators of their devices your users can change many of the other restrictions on your application’s environment as well. Only some of them will allow you to access their location. Only some of them will permit push notifications. Some of them will use parental controls to block access to Safari, the app store, or other applications.