Ask HN: How many of you Apple developers still use Objective C?

Hacker News Discussion ↗

Apple platform developers are split between sticking with Objective-C and embracing Swift for iOS and macOS work. Many rely on Objective-C for large, stable legacy codebases, better C/C++ interoperability, faster compilation, and long-term source compatibility, while others favor Swift for its modern language features, safer type system, and access to new Swift-only APIs. There is broad agreement that new apps are usually written in Swift, but knowledge of Objective-C remains valuable for maintaining existing software and understanding lower-level system behavior.

Where Objective-C Is Still Used

  • Many production apps (especially older ones and some “AAA”/FAANG-scale) still have large ObjC codebases.
  • Some teams default to ObjC for SDKs, cross‑platform C/C++ integrations, macOS‑specific work, and low‑level system APIs.
  • ObjC is common in legacy Mac apps, long‑lived iOS apps pre‑Swift, and internal tooling; several posters assume Apple itself still uses a lot of ObjC and C.
  • Some hobbyists and solo devs build new apps entirely in ObjC, often for familiarity or simplicity.

Reasons Developers Stick With Objective-C

  • Fast, predictable compile times and better debugger experience compared to Swift.
  • Excellent C/C++ interop and ObjC++ for mixed codebases.
  • Stable language with decades of backwards compatibility; very old ObjC still compiles.
  • Perceived elegance and simplicity of message passing and runtime dynamism (e.g., method swizzling).
  • Avoidance of Swift’s past breaking changes and migration pain; some distrust Apple’s tendency to churn APIs and tools.
  • For some, ObjC “does the job” and there’s no compelling business reason to switch.

Arguments for Using Swift Instead

  • Most new code and new apps are now written in Swift; juniors often don’t know ObjC at all.
  • New Apple APIs are increasingly Swift‑first or Swift‑only, making long‑term ObjC limiting.
  • Developers report higher productivity: less boilerplate, safer types/optionals, generics, async/await, and easier modern API usage.
  • Mixed projects often add new files in Swift while leaving stable ObjC alone.

Interop and Mixed Codebases

  • Swift–ObjC interoperability is generally described as good but can get fragile in complex projects or when Xcode’s build graph breaks.
  • C interop in Swift is seen as fine by some, painful by others (bridging headers, packaging, SPM/xCFramework quirks).
  • C++ interop: ObjC has historically been better (ObjC++), though recent Swift C++ interop has improved.

SwiftUI and Modern Frameworks

  • SwiftUI divides opinion: great for simple UIs and “settings screens,” but described as immature, buggy, and hard to use for complex, stateful views (e.g., maps).
  • Some devs avoid SwiftUI and stick to UIKit/AppKit (in either ObjC or Swift); others see SwiftUI as a major productivity gain for constrained use cases.

Learning and Ecosystem

  • ObjC remains valuable for reading old code samples, understanding Cocoa/AppKit internals, and interfacing with older macOS APIs.
  • Some learners start with ObjC because modern Swift resources for classic Cocoa/AppKit are sparse.