Swift

Swift lacks proper dynamic library support on Linux, including library evolution, artifact bundles, and first-class dynamic linking. Organizations have resorted to custom toolchains with unsustainable workarounds, blocking proper package distribution on Linux.

Building on Linux with the new Foundation requires compiling both swift-foundation and swift-syntax (due to macro usage), causing painful and lengthy build times that result in slow CI turnaround.

Swift's compiler struggles with complex generics beyond simple cases. Type inference fails on complex generic code, forcing developers to add explicit type ascriptions throughout. The compiler may refuse to compile until code is broken apart and rewritten.

Swift has evolved from a practical, simple language into an academic exercise with layers of complexity. Features like async/await, actors, structured concurrency, @Sendable, property wrappers, result builders, and macros have created massive cognitive overhead, turning the language from a helpful partner into a "pedantic adversary" that demands extensive boilerplate and compiler appeasement rather than enabling feature development.

Swift's type inference system causes exponential compile time slowdowns, particularly with string concatenation, array operations, and generic code. Developers are forced to abandon type inference and add explicit type annotations to avoid unacceptable build times, diminishing code elegance.

Swift's ARC (Automatic Reference Counting) system is misunderstood and misused by developers, causing memory leaks and crashes. Incorrect reference counting in closures leads to objects being used outside their intended context, causing performance degradation or application crashes.

Applications without proper error management in API integration face a 40% higher chance of crashing. Comprehensive error handling with do-catch statements and logging mechanisms are required but often overlooked.

Linux support trails behind macOS, with features like Macro support arriving late and updates delayed. This has postponed adoption of newer Swift releases and transparency around Linux support timelines is poor.

Developers frequently encounter inexplicable build failures requiring manual nuking of `.build`, SwiftPM caches, or Xcode derived data. Packages mysteriously disappear in Xcode and builds trigger more than expected, affecting both macOS and Linux.

Accidental misconfigurations in build settings (e.g., duplicate HEADER_SEARCH_PATHS) don't prevent compilation but cause SourceKit to crash on every text edit. Debugging requires manual inspection of SOURCEKIT_LOGGING output.

Swift 6's data race safety features introduce warnings and errors about concurrency issues. Adopting the new language mode and ensuring thread-safe method access requires substantial changes to existing codebases.

Swift developers unfamiliar with the distinction between value types and reference types often have false expectations about code behavior, as instances of these types exhibit different semantics. This conceptual gap causes bugs that are difficult to diagnose.

The @Sendable and strict data-race protections generate cryptic compiler error messages about types not conforming to Sendable, creating a demoralizing battle with the type checker. Developers spend more time deciphering "alien error messages" than building features.

The concurrency system lacks essential features like non-reentrant actor support, proper send support for actors in distributed systems, and missing primitives like Semaphore alternatives. Developers resort to Task Semaphore and various workarounds.

Concurrency runtime analytics tools are inadequate, especially for Linux environments. LLDB lacks support for async task stack backtraces, task creation/running/sleeping information, and task locals inspection, limiting debugging and profiling capabilities.

Performance issues are hard to diagnose and address. Unnecessary copying, excessive metadata lookups with existentials/generics, and ARC traffic require specific compiler incantations to work around. No built-in tools exist to identify anti-patterns.

KeyPath performance is severely problematic, forcing workarounds even in simple cases like sort comparators. The overhead is so high that developers cannot use them without fear of performance degradation.

Swift's frequent updates and changes create doubt about code compatibility with future versions. Developers worry whether code written today will compile tomorrow, and managing versioning across teams and dependencies is challenging.

Swift has significantly fewer third-party libraries and frameworks compared to Java, Python, or other mature languages. This makes it difficult to quickly build complex features without reinventing the wheel.

Identifying and resolving bugs and performance issues in Swift is time-consuming and requires deep understanding of Swift's internals. The language's strict type system and memory management model make optimization non-obvious.

Swift compiler errors are often cryptic, unhelpful, and point to incorrect locations in code. The error messages resemble a 'Magic 8-ball' with little actual guidance on what's wrong, making debugging difficult and time-consuming.

Due to frequent Swift updates, it is difficult to find appropriate tooling for specific tasks. Xcode lacks proper support for Swift with widespread issues in syntax highlighting, autocomplete, refactoring tools, and compilation.

SwiftUI requires minimum OS versions (iOS 13+, macOS 10.15+, tvOS 13+, watchOS 6+) and many features only work on newer versions (e.g., TextInput focus on iOS 15+). Projects supporting older OS versions cannot use SwiftUI or must maintain UIKit fallbacks.

Accessing native APIs through platform channels requires knowledge of Kotlin/Swift/Objective-C. Specific features like Bluetooth LE, AR, biometrics, and native notifications either require unreliable third-party packages or custom implementation, reducing the efficiency of cross-platform development.

The Swift community is significantly smaller than other open-source languages (only 5.1% of surveyed developers use Swift). Finding experienced Swift developers is difficult, limiting project growth and team expansion.

Developers transitioning from Objective-C find Swift's compile-time type enforcement restrictive and frustrating initially, as it prevents patterns they're accustomed to (like dynamic typing and loose type checking). The strict requirements feel like they 'hold you back' during the onboarding phase.

Swift's type system requires developers to define validators for every external API, library, and database input. This is tedious and unique among languages the developers have used, yet the type system isn't sufficiently powerful to justify the overhead. Issues often stem from external libraries outside the developer's control.

Swift's interactions with Objective-C and strict compiler rules make it difficult to work with legacy code. Type casting issues, particularly converting between String and NSString/AnyObject types, and constant unwrapping requirements complicate development.

Developers frequently mishandle Swift's optional type system, either overusing force unwrapping (which crashes on nil) or creating complex optional chains. The Codable protocol adds messy try/catch syntax that's error-prone and difficult to debug when misused.

Swift lacks built-in support for compile and runtime availability checking of third-party APIs, forcing developers to implement custom solutions or workarounds for version compatibility.

SwiftUI lacks a natural, straightforward mechanism for creating reusable design systems. Developers must choose between adding modifiers to every component, creating artificial extensions, or scattering style constants throughout the codebase—none of which are clean solutions.

Swift lacks abstract classes, requiring developers to decompose into concrete base classes and protocols. This leads to complicated generic signatures, requires significant experimentation, and can cause compiler crashes.

Swift's compiler fails to catch certain error conditions, leading to crashes or unexpected behavior at runtime. Error handling is incomplete, leaving edge cases undetected.

While Swift supports Apple platforms, Linux, and Windows, it was originally designed for iOS and remains best for native iOS. Cross-platform development lags behind React Native, Xamarin, and Flutter.

Swift's testing model prevents access to private members, forcing developers to contort code and add unnecessary interface elements to enable testing. This is inefficient for bug fixes, feature flagging, and other testing scenarios where private access is warranted.

Developers receive concurrency-related errors when accessing main actor APIs through notifications, even when those notifications are guaranteed to post on the main thread. This creates confusing false positives that require workarounds.

Swift projects encounter numerous deprecation warnings even in basic, newly-written code and teaching examples. This creates confusion for beginners and clutters the development experience with outdated APIs.

Swift does not allow static variable declarations within functions, forcing developers to use global variables as the only option. This pollutes the global namespace unnecessarily.

Documentation on performance best practices when using generics and protocol-oriented programming is sparse. Developers lack guidance on cross-module considerations and how to write performant generic code.

Swift's error handling model uses type erasure which loses concrete type information, causing problems in highly constrained systems without runtime allocation capabilities.

Tuples cannot be used as dictionary keys because they don't conform to Hashable, requiring developers to create wrapper structs instead. Additionally, basic functionality like `.sum()` is missing, forcing use of `.reduce(0, +)` repeatedly.

Swift testing does not support real-time test execution when files change. Tests must live in separate modules due to Objective-C conventions from 20 years ago, rather than alongside source files, creating organizational friction.

Swift lacks namespace support like C#. Developers must use enums as a workaround for namespace functionality, which is semantically incorrect and creates sadness about the solution.

Embedded Swift disallows certain features including runtime reflection to meet constrained environment requirements, limiting expressiveness for embedded systems development.