Skip to content

Latest commit

 

History

History
156 lines (105 loc) · 7.69 KB

ios.md

File metadata and controls

156 lines (105 loc) · 7.69 KB
Raw

iOS

  1. Supported OS Versions
  2. Supported Devices
  3. Development Tools
  4. Codesigning
  5. Dependency Management
  6. Coding Conventions
  7. Apple Guidelines
  8. .gitignore
  9. Test-Driven Development
  10. Automated Builds
  11. Crash Logs
  12. Best Practices
  13. Distributing To AppStore
  14. Useful Links

Supported OS Versions

iOS

  • iOS 13.*
  • iPadOS 13.*
  • iOS 12.*
  • iOS 11.* (limited support for legacy projects)

watchOS

  • watchOS 5.0+

tvOS

  • tvOS 12.0+

Supported Devices

Development Tools

Programming Languages

  • Swift 5.1

IDE

  • Xcode 11.*

Other Tools

  • Homebrew for package management (not MacPorts)
  • If you need to manage Ruby environment, prefer rbenv to rvm. System Ruby is OK for iOS development needs, though.

Codesigning

  • Never revoke certificates yourself, ask Team Leader to do that if needed.
  • Use manual code-signing option in Xcode along with Fastlane to specify pair of code-signing certificate and provisioning profile.
  • Follow Provisioning Portal Naming Conventions (profiles, certificates and devices)
  • Use match from Fastlane for generating development and distribution certificates as well as provisioning profiles. When generating certificates, specify not empty password, other way you won't be able to open certificate by tools like Knuff.
  • Use a single match repo with certificates for one developer account instead of creating repo for each app developed on an account.

Dependency Management

Use CocoaPods to add third-party components (frameworks, libraries) to your project. Use frameworks, not static libraries, for dependencies. This is done by calling use_frameworks! method in Podfile.

Pods directory is considered a build artefact, and therefore should be added to .gitignore.

Podfile.lock file should be committed to repository, along with .xcworkspace file.

Coding Conventions

Apple Guidelines

Strictly follow these guidelines:

.gitignore

https://www.gitignore.io/api/swift

Test-Driven Development

Use XCTest for unit tests

Matcher Frameworks:

Dependency injection:

Automated Builds

  • Use fastlane for app building and submission
  • Make schemes shared and commit them to repository
  • Before submitting build, all unit tests must pass. If even 1 test is failing, build should also fail
  • Stable builds are made in the end of each development cycle (Iteration, Sprint, Milestone etc)
  • Access should be given to developers, testers, managers and client team
  • Apple's Testflight is preferred service for delivering beta builds
  • There should be several types of builds, each of them having specific environment, for example Staging build should work with Staging server, Production build should work with Production server.
  • There should be 4 CI jobs per app - one, that automatically runs tests on each pushed commit in every branch, one that compiles staging build when pushed to staging branch, one that makes production build on push to master branch, and one CI job, that refreshes DSYMS for Firebase Crashlytics. The last job should be run daily, all other events should be triggered by push event from git.

Crash Logs

Use Firebase Crashlytics for crash logs. Install Fabric/Crashlytics/Firebase and follow the instructions. Fabric and Crashlytics frameworks must be installed via CocoaPods.

To provide Firebase Crashlytics symbolicated crash logs there should be a dedicated CI job, that runs daily, and uploads DSYMs from iTunesConnect to Firebase. Code to do that can be found on internal swift-snippets repo.

Preferred libraries and frameworks

Code generation

Push notifications

  • Use Knuff for testing push notifications.
  • Do not store push certificates in repository.
  • Use development certificate for debug builds and production certificate for release builds.

Best Practices

  • Create app user interface in Interface Builder, using XIBs or Storyboards. Custom UIView creation in a source code files is undesirable. Use tools and frameworks to make your views small and reusable
  • Avoid big Storyboards. Split Storyboards into smaller ones. More than 7-8 ViewControllers in one Storyboard are unacceptable. Use Storyboard references in Xcode to refactor large storyboards into small ones.
  • Do not let UIViewController subclasses grow to more than 400 lines of code. Always try to keep them simple and short, preferably under 100 lines of code.

Distributing To AppStore

  • Make sure, that your app works with correct server and API version
  • Update your changelog with relevant changes
  • Create a tag in repository, that represents your Release

Useful links