Blog - Objective-C vs Swift — realne różnice
Składnia, bezpieczeństwo typów, interoperacyjność, pamięć, wydajność i kiedy nadal spotkasz Objective-C w projektach iOS.
- Autor
- 2code
- Opublikowano
- Tagi
- iOS
- Swift
- Objective-C
Swift nie jest „ładniejszym Objective-C”. To inny model języka: bezpieczeństwo typów, wartość vs referencja, błędy jako wartości, przy zachowaniu mostu do Cocoa.
Składnia i ekspresja
Objective-C:
NSString *name = [person fullName];
[array addObject:item];
Swift:
let name = person.fullName
array.append(item)
Swift ma optionale (String?), pattern matching, protokoły z associated types, async/await. Objective-C opiera się na dynamicznym runtime (objc_msgSend) i nil-messaging.
Bezpieczeństwo typów
| Objective-C | Swift | |
|---|---|---|
| Null | nil często „przechodzi” | Optional wymusza obsługę |
| Kolekcje | id / lekkie typy | generyki, Array<T> |
| Błędy | NSError ** | throws / Result |
W Swift kompilator łapie więcej klas błędów przed runtime. W ObjC wiele rzeczy wychodzi dopiero na urządzeniu.
Model obiektów
…
Swift promuje value types (struct, enum). Objective-C praktycznie wszystko jest obiektem na stercie (poza C primitives).
Interoperacyjność
Swift woła ObjC przez bridging headers / @objc. ObjC widzi tylko to, co oznaczysz jako @objc / dziedziczące z NSObject.
Dlatego legacy SDK i stare moduły często zostają w ObjC, a nowy kod pisze się w Swift.
Wydajność i ARC
Oba używają ARC dla obiektów ObjC/Swift class. Swift dodatkowo:
- unika heap alokacji dla wielu
struct, - ma agresywniejsze optymalizacje generyków,
- nadal płaci za bridging przy częstym przechodzeniu przez
NSString/NSArray.
Kiedy ObjC nadal ma sens?
- Duży legacy codebase bez budżetu na rewrite.
- Runtime hacking / method swizzling (łatwiejsze w ObjC).
- Część niskopoziomowych / starszych frameworków.
Wniosek
Swift wygrywa czytelnością i bezpieczeństwem. Objective-C zostaje tam, gdzie jest historia, dynamiczny runtime albo koszt migracji. W praktyce: nowe feature’y w Swift, most do ObjC tam, gdzie trzeba.