Geekly Articles each Day
📜 ⬆️ ⬇️

9 Principles for Creating Quality iOS Applications

The principles are based on the well-known methodology from heroku , adapted to the realities of ayios development (Lack of containers that take several days to complete and slow down deployment, Xcode only works on a poppy).


This article is a short introduction, the full series can be found on the iOS-factor , Russian translation is also available. The open source iOS-factor project on github is constantly being refined and welcomes new ideas. I also took part in its development. The project was founded by Felix who is the creator of fastlane .


TL; DR




Dependencies


The application declares all its dependencies completely and accurately using the dependency declaration manifest.
This includes a specific version of Swift, Xcode, CocoaPods, Carthgae, and Fastlane. Also, all dependencies in podfile and cartfile must specify a specific version.


One of the advantages of explicitly declaring dependencies is that it makes it easy to configure applications for new developers.


With the help of specifying specific dependencies, you can reproduce the build that was used 6 months ago, knowing that it will be built because the build will use the same version of Xcode, CocoaPods and Swift.


Restriction - Since iOS development cannot be contained in a container, as it is already used for web development, we are limited to third-party tools trying to fulfill this requirement until Apple provides an official solution. There is a third-party commercial (closed) solution called Veertu that allows you to create virtual MacOS environments on Apple hardware.



Configuration


The code does not depend on the environment, but the configuration depends. Therefore, the code should be stored in the repository, and the configuration in the environment. Checking whether the configuration and application code are correctly separated is the fact that the application code base can be freely available at any time without compromising any private data.


There are many ways to enter configuration values ​​at build time.



Because deployments on the iOS platform are significantly slower than on servers, you may need a way to update your configuration over the air (OTA) to quickly respond to problems.


OTA configuration updates allow you to instantly:



Some potential approaches when implementing OTA updates are:




Application development / work parity


Historically, there are significant differences between development (the developer makes live changes on the local deployment of the application) and the operation of the application (deployment of the application in the App Store with access to it by end users).
These differences appear in three areas:



Decision:




Deployment


As described in the Dependencies principle, the code repository should include all the dependencies needed to create, test, and deploy the iOS application.


Unfortunately, due to the fact that Xcode should work on MacOS, we cannot use containers like on the web. Running macOS in a virtual environment is fraught with technical and legal issues.


Right now, the best approach we iOS developers can use is:



Many companies use the concept of Release trains: a schedule that releases a new version of your application. All the code that was merged with your main branch (master or release) at the moment the release train “leaves” will be sent to the App Store. This approach is implemented by most large iOS applications.



Local versus Beck


In recent years, some development teams have begun to use approaches that require less development effort by lowering the quality of the user experience, transferring more logic to the backend and making the iOS application a thin client showing server results.


An application should do as much business logic and computing on the device as possible for a number of reasons:



If your application requires an Internet connection for all the functionality (for example, a social networking application or a travel sharing application), it should still work (read-only) without an Internet connection to access historical data (for example, recent trips, recent direct communications).



Backward compatible APIs


Although most of your users will be updated to the latest version within a few weeks, there will always be users who do not. This may have several reasons. Often this is due to the version of iOS used, which they cannot always update due to the age of the device.


The basic concept is that you are not updating the existing API, but instead adding a new one and allowing them to work in parallel


https://your-api.com/1.0/drivers.json https://your-api.com/1.1/drivers.json


Application Versioning


The version and build number are used together to identify a specific application in the app.



In today's iOS development, there is no reason why you should manually change these numbers. Instead, you need a reliable and automated system to keep versions up to date.


Xcode has a built-in tool called agvtool .



Kickbacks


The App Store initially does not allow rollbacks, so this section describes how to achieve similar results using available methods.


Milestone releases - Using milestone releases, you can slowly roll out an assembly to the prod, starting with a small number of active users


However, even in the case of phased releases, it is impossible to completely recall the assembly: after the assembly is installed on the user's device, the only way to change this assembly is to distribute a new version with an updated version / build number.


As with the phased releases, the App Store and TestFlight assemblies can only be updated by following these steps:


  1. Return to your version control system to the state you want to roll back to
  2. Increase the version and / or build number of your project
  3. Create and sign your application
  4. Distribute your application through the beta service or the App Store
  5. The user must update the application on his phone.

The above steps can be performed manually, however it is recommended to fully automate the process in order to be able to respond quickly.


Alternative: re-sign old build


  1. Access the old assembly (.ipa file) before regression was introduced
  2. Update the version / build number in the Info.plist file
  3. “Sign” the old build
  4. Distribute it as a new build

However, “signing” iOS apps often creates more problems, especially because the Xcode command line tools do not offer a good way to do this.



Data storage


Storing data and configurations in accordance with Apple’s recommendations is critical to the life cycle of your application, in particular when it comes to iCloud synchronization, upgrading to a new phone, and restoring your phone from backup.


Be sure to follow the official Apple iOS Data Storage Guidelines :



Never store user confidential information (such as passwords or sessions) in these directories. Use the Keychain API instead.


')

Source: https://habr.com/ru/post/461317/

More articles:


All Articles