Swift vs. Objective-C : 미래가 Swift를 선호하는 10 가지 이유

프로그래밍 언어는 쉽게 죽지 않지만 패러다임에 집착하는 개발 상점은 죽습니다. 모바일 기기 용 앱을 개발 중이고 Swift를 조사하지 않은 경우, Swift는 Mac, iPhone, iPad, Apple Watch 및 향후 기기 용 앱을 개발할 때 Objective-C를 대체 할뿐만 아니라 그러나 그것은 또한 Apple 플랫폼의 임베디드 프로그래밍을 위해 C를 대체 할 것입니다.

몇 가지 주요 기능 덕분에 Swift는 향후 몇 년 동안 몰입 형, 반응 형, 소비자 용 애플리케이션을 만들기위한 사실상의 프로그래밍 언어가 될 가능성이 있습니다.

애플은 스위프트에 대한 큰 목표를 가지고있는 것으로 보인다. 성능을 위해 컴파일러를 최적화하고 개발을 위해 언어를 최적화했으며 Swift의 문서에서 Swift가 " 'hello, world'에서 전체 운영 체제로 확장되도록 설계되었습니다"라고 암시합니다. Apple은 아직 언어에 대한 모든 목표를 밝히지 않았지만 Xcode 6, Playgrounds 및 Swift의 출시는 다른 개발 도구 체인보다 앱 개발을 더 쉽고 접근하기 쉽게 만들려는 Apple의 의도를 나타냅니다.

지금 Swift로 작업을 시작하여 게임에서 앞서 나가는 10 가지 이유가 있습니다.

1. Swift는 읽기가 더 쉽습니다.

Objective-C는 C 기반 언어에서 기대할 수있는 모든 사마귀에 시달립니다. 키워드와 유형을 C 유형과 구별하기 위해 Objective-C는 @ 기호를 사용하여 새 키워드를 도입했습니다. Swift는 C에 구축되지 않았기 때문에 모든 키워드를 통합하고 모든 Objective-C 유형 또는 객체 관련 키워드 앞에있는 수많은 @ 기호를 제거 할 수 있습니다.

Swift는 레거시 규칙을 삭제합니다. 따라서 if / else 문 내에서 조건식을 둘러싸 기 위해 줄을 끝낼 때 세미콜론이나 괄호가 더 이상 필요하지 않습니다. 또 다른 큰 변화는 메서드 호출이 서로 내부에 중첩되지 않아 대괄호 지옥 (bye-bye,)이 발생한다는 것 [[[ ]]]입니다. Swift의 메서드 및 함수 호출은 괄호 안에 산업 표준 쉼표로 구분 된 매개 변수 목록을 사용합니다. 그 결과 구문과 문법이 단순화 된 깔끔하고 표현력이 뛰어난 언어가 탄생했습니다.

Swift 코드는 다른 현대 인기 프로그래밍 언어 외에도 자연 영어와 더 유사합니다. 이러한 가독성 덕분에 JavaScript, Java, Python, C # 및 C ++의 기존 프로그래머는 Objective-C의 추악한 새끼 오리와 달리 Swift를 도구 체인에 더 쉽게 적용 할 수 있습니다.

2. Swift는 유지하기가 더 쉽습니다.

레거시는 Objective-C를 뒷받침하는 것입니다. 언어는 C가 진화하지 않고는 진화 할 수 없습니다. C는 프로그래머가 실행 가능한 앱 생성의 빌드 시간과 효율성을 개선하기 위해 두 개의 코드 파일을 유지하도록 요구하며, 이는 Objective-C에 적용되는 요구 사항입니다.

Swift는 두 파일 요구 사항을 삭제합니다. Xcode 및 LLVM 컴파일러는 Swift 1.2에서 종속성을 파악하고 자동으로 증분 빌드를 수행 할 수 있습니다. 결과적으로 본문 (구현 파일)에서 목차 (헤더 파일)를 분리하는 반복적 인 작업은 과거의 일입니다. Swift는 Objective-C 헤더 (.h)와 구현 파일 (.m)을 단일 코드 파일 (.swift)로 결합합니다.

Objective-C의 2 개 파일 시스템은 프로그래머에게 추가 작업을 부과하며 프로그래머가 더 큰 그림에서주의를 분산시키는 작업입니다. Objective-C에서는 표준 규칙을 사용하여 파일간에 메서드 이름과 주석을 수동으로 동기화해야하지만 팀에 규칙과 코드 검토가 없으면 보장되지 않습니다.

Xcode 및 LLVM 컴파일러는 프로그래머의 작업 부하를 줄이기 위해 백그라운드에서 작업 할 수 있습니다. Swift를 사용하면 프로그래머는 부기 작업을 줄이고 앱 로직을 만드는 데 더 많은 시간을 할애 할 수 있습니다. Swift는 상용구 작업을 제거하고 지원되는 코드, 주석 및 기능의 품질을 향상시킵니다.

3. Swift가 더 안전합니다

Objective-C의 흥미로운 측면 중 하나는 포인터, 특히 nil (null) 포인터가 처리되는 방식입니다. Objective-C에서 포인터 변수가 nil (초기화되지 않음) 인 메서드를 호출하려고하면 아무 일도 발생하지 않습니다. 코드의 표현이나 줄은 작동하지 않는 (no-op)이되고 충돌하지 않는 것이 유익 해 보일 수 있지만 버그의 큰 원인이되었습니다. 작동하지 않으면 예기치 않은 동작이 발생하는데, 이는 프로그래머가 무작위 충돌을 찾아 수정하거나 비정상적인 동작을 중지하려는 적입니다.

선택적 유형은 Swift 코드에서 nil 선택적 값의 가능성을 매우 명확하게합니다. 이는 잘못된 코드를 작성할 때 컴파일러 오류를 생성 할 수 있음을 의미합니다. 이것은 짧은 피드백 루프를 생성하고 프로그래머가 의도적으로 코딩 할 수 있도록합니다. 코드가 작성됨에 따라 문제를 수정할 수 있으므로 Objective-C의 포인터 로직과 관련된 버그를 수정하는 데 소요되는 시간과 비용을 크게 줄일 수 있습니다.

전통적으로 Objective-C에서는 메서드에서 값이 반환되면 반환 된 포인터 변수의 동작을 문서화하는 것이 프로그래머의 책임이었습니다 (주석 및 메서드 이름 지정 규칙 사용). Swift에서 선택적 유형 및 값 유형은 값이 존재하거나 선택적 일 가능성이 있는지 (즉, 값이 존재하거나 nil 일 수 있음) 메소드 정의에서 명시 적으로 명확하게합니다.

예측 가능한 동작을 제공하기 위해 Swift는 nil 선택적 변수가 사용되는 경우 런타임 충돌을 트리거합니다. 이 충돌은 일관된 동작을 제공하여 프로그래머가 즉시 문제를 수정하도록하기 때문에 버그 수정 프로세스를 용이하게합니다. Swift 런타임 충돌은 nil 선택적 변수가 사용 된 코드 줄에서 중지됩니다. 이는 버그가 더 빨리 수정되거나 Swift 코드에서 완전히 피할 수 있음을 의미합니다.

4. Swift는 메모리 관리와 통합됩니다.

Swift는 Objective-C가 제공하지 않는 방식으로 언어를 통합합니다. ARC (Automatic Reference Counting)에 대한 지원은 절차 및 객체 지향 코드 경로에서 완전합니다. Objective-C에서 ARC는 Cocoa API 및 객체 지향 코드 내에서 지원됩니다. 그러나 절차 적 C 코드 및 Core Graphics와 같은 API에는 사용할 수 없습니다. 즉, iOS에서 사용할 수있는 Core Graphics API 및 기타 하위 수준 API로 작업 할 때 메모리 관리를 처리하는 것은 프로그래머의 책임이됩니다. 프로그래머가 Objective-C에서 가질 수있는 엄청난 메모리 누수는 Swift에서 불가능합니다.

프로그래머는 자신이 만드는 모든 디지털 객체에 대해 메모리를 생각할 필요가 없습니다. ARC는 컴파일 타임에 모든 메모리 관리를 처리하기 때문에 메모리 관리를 향한 두뇌 능력은 대신 핵심 앱 로직과 새로운 기능에 집중할 수 있습니다. Swift의 ARC는 절차 적 코드와 객체 지향 코드 모두에서 작동하기 때문에 프로그래머가 낮은 수준의 API를 다루는 코드를 작성하더라도 더 이상 정신적 컨텍스트 전환이 필요하지 않습니다. 이는 현재 Objective-C 버전의 문제입니다.

자동 고성능 메모리 관리는 해결 된 문제이며 Apple은 생산성을 높일 수 있음을 입증했습니다. 다른 부작용은 Objective-C와 Swift 모두 Java, Go 또는 C #과 같이 사용되지 않는 메모리를 정리하는 가비지 콜렉터의 문제가 없다는 것입니다. 이는 특히 iPhone, Apple Watch 또는 iPad와 같은 촉각 장치에서 반응 형 그래픽 및 사용자 입력에 사용되는 모든 프로그래밍 언어에 중요한 요소입니다 (지연이 실망스럽고 사용자가 앱이 손상되었다고 인식하게 함).

5. Swift는 더 적은 코드를 필요로합니다

Swift는 반복적 인 문과 문자열 조작에 필요한 코드의 양을 줄입니다. Objective-C에서 텍스트 문자열 작업은 매우 장황하며 두 가지 정보를 결합하려면 많은 단계가 필요합니다. Swift는 Objective-C에서 누락 된 "+"연산자와 함께 두 개의 문자열을 추가하는 것과 같은 최신 프로그래밍 언어 기능을 채택합니다. 이와 같은 문자 및 문자열 결합 지원은 화면에서 사용자에게 텍스트를 표시하는 모든 프로그래밍 언어의 기본입니다.

Swift의 유형 시스템은 컴파일러가 유형을 파악할 수 있으므로 코드 문의 복잡성을 줄입니다. 예로서, 목표 C-특별한 문자열을 기억 토큰 (프로그래머 요구 %s, %d, %@각각의 토큰을 대체하는 변수들의 목록을 쉼표로 구분) 및 제공한다. Swift는 문자열 보간을 지원하므로 토큰을 기억할 필요가 없으며 프로그래머가 레이블 또는 버튼 제목과 같은 사용자가 사용하는 문자열에 직접 인라인으로 변수를 삽입 할 수 있습니다. 유형 추론 시스템과 문자열 보간은 Objective-C에서 흔히 발생하는 충돌의 일반적인 원인을 완화합니다.

Objective-C에서 순서를 엉망으로 만들거나 잘못된 문자열 토큰을 사용하면 앱이 중단됩니다. 여기에서 Swift는 텍스트 문자열 및 데이터 조작을위한 인라인 지원으로 인해 더 적은 코드 (이제 오류 발생 가능성이 적은 코드)로 번역하여 부기 작업에서 벗어날 수 있습니다.

6. Swift가 더 빠릅니다

레거시 C 규칙을 삭제하면 내부적으로 Swift가 크게 향상되었습니다. Swift 코드 성능에 대한 벤치 마크는 Swift가 앱 로직을 실행할 수있는 속도를 개선하기위한 Apple의 노력을 계속해서 보여줍니다.

인기있는 GeekBench 성능 도구 제조업체 인 Primate Labs에 따르면 Swift는 2014 년 12 월 Mandelbrot 알고리즘을 사용하여 컴퓨팅 바인딩 작업에 대한 C ++의 성능 특성에 접근했습니다.

2015 년 2 월, Primate Labs는 Xcode 6.3 베타가 대형 어레이의 순차 액세스가 가능한 메모리 바인딩 알고리즘 인 GEMM 알고리즘의 Swift 성능을 1.4 배 향상 시켰음을 발견했습니다. 초기 FFT 구현 (대형 어레이의 임의 액세스가 포함 된 메모리 바인딩 알고리즘)은 성능이 2.6 배 향상되었습니다.

모범 사례를 적용하여 Swift에서 추가 개선이 관찰되어 FFT 알고리즘 성능이 8.5 배 향상되었습니다 (C ++는 1.1 배 성능 향상 만 남음). 또한 향상된 기능을 통해 Swift는 Mandelbrot 알고리즘의 C ++보다 단 1.03의 성능을 발휘할 수있었습니다.

Swift는 FFT 및 Mandelbrot 알고리즘 모두에서 C ++와 거의 비슷합니다. Primate Labs에 따르면 GEMM 알고리즘 성능은 Swift 컴파일러가 C ++ 컴파일러가 할 수있는 코드를 벡터화 할 수 없음을 시사합니다. 이는 Swift의 다음 버전에서 얻을 수있는 쉬운 성능 향상입니다.

7. 오픈 소스 프로젝트와의 이름 충돌 감소

Objective-C 코드를 괴롭힌 한 가지 문제는 네임 스페이스에 대한 공식적인 지원이 없다는 것인데, 이는 파일 이름 충돌을 코드화하는 C ++의 솔루션이었습니다. Objective-C에서이 이름 충돌이 발생하면 링커 오류이며 앱을 실행할 수 없습니다. 해결 방법이 있지만 잠재적 인 함정이 있습니다. 일반적인 규칙은 2 자 또는 3 자 접두사를 사용하여 Facebook에서 작성한 Objective-C 코드와 자신의 코드를 구별하는 것입니다.

Swift는 빌드 실패를 일으키지 않고 NSString (Next Step — Apple에서 해고 된 후 Steve Jobs의 회사) 또는 CGPoint (Core Graphics)와 같은 이름을 요구하지 않고 동일한 코드 파일이 여러 프로젝트에 존재하도록 허용하는 암시 적 네임 스페이스를 제공합니다. 궁극적으로 Swift의이 기능은 프로그래머의 생산성을 높이고 Objective-C에있는 부기 작업을 수행 할 필요가 없음을 의미합니다. Objective-C의 네임 스페이스 부족에서 태어난 NSArray, NSDictionary, NSString 대신 Array, Dictionary, String과 같은 단순한 이름으로 Swift의 영향을 확인할 수 있습니다.

Swift에서 네임 스페이스는 코드 파일이 속한 대상을 기반으로합니다. 이는 프로그래머가 네임 스페이스 식별자를 사용하여 클래스 또는 값을 구별 할 수 있음을 의미합니다. 이 Swift의 변화는 엄청납니다. 오픈 소스 프로젝트, 프레임 워크 및 라이브러리를 코드에 쉽게 통합 할 수 있습니다. 네임 스페이스를 사용하면 서로 다른 소프트웨어 회사에서 오픈 소스 프로젝트를 통합 할 때 충돌에 대한 걱정없이 동일한 코드 파일 이름을 만들 수 있습니다. 이제 Facebook과 Apple 모두 오류나 빌드 실패없이 FlyingCar.swift라는 개체 코드 파일을 사용할 수 있습니다.

8. Swift는 동적 라이브러리를 지원합니다

충분한 관심을받지 못한 Swift의 가장 큰 변화는 주요 포인트 릴리스 (iOS 8, iOS 7 등)에서 업데이트되는 정적 라이브러리에서 동적 라이브러리로 전환 한 것입니다. 동적 라이브러리는 앱에 연결할 수있는 실행 가능한 코드 청크입니다. 이 기능을 사용하면 현재 Swift 앱이 시간이 지남에 따라 진화함에 따라 최신 버전의 Swift 언어에 연결할 수 있습니다.

개발자는 무결성을 보장하기 위해 개발 인증서로 디지털 서명 된 라이브러리와 함께 앱을 제출합니다 (hello, NSA). 이는 Swift가 iOS보다 빠르게 발전 할 수 있다는 것을 의미하며, 이는 현대적인 프로그래밍 언어의 요구 사항입니다. 라이브러리에 대한 변경 사항은 모두 App Store의 최신 앱 업데이트에 포함될 수 있으며 모든 것이 간단히 작동합니다.

동적 라이브러리는 Mac에서 오랫동안 지원되었지만 Swift 및 iOS 8이 출시 될 때까지 iOS에서 지원되지 않았습니다. 동적 라이브러리는 앱 실행 파일의 외부에 있지만 App Store에서 다운로드 한 앱 번들에 포함되어 있습니다. 외부 코드는 사용될 때만 연결되기 때문에 메모리에로드 될 때 앱의 초기 크기를 줄입니다.

Apple Watch의 모바일 앱 또는 임베디드 앱에서 로딩을 연기하는 기능은 사용자가인지하는 성능을 향상시킵니다. 이것은 iOS 생태계가 더 반응하는 느낌을주는 특징 중 하나입니다. Apple은 자산, 리소스 만로드하는 데 중점을 두 었으며 이제는 즉시 컴파일 및 링크 된 코드를로드했습니다. 즉석 로딩은 리소스가 실제로 화면에 표시 될 때까지 초기 대기 시간을 줄입니다.