Objective-C originates from the early 1980s, and while the language has evolved a lot over the years, it’s still no match for really modern languages like Swift. With Swift 3.0 on the horizon, it’s smart to write new apps in Swift. However at PSPDFKit, we are still firmly in the Objective-C world. We build and distribute a binary framework to render and edit PDF documents. Getting all the PDF details right is a complex problem. In addition to core PDF functionality, we also offer a lot of UI classes to help with typical use cases. This results in a code base that is around 600k lines — a mix of shared C++ code and Objective-C++ for UI and wrapped models. Our headers are entirely modern Objective-C annotated with generics and nullability to ensure everything works great with Swift. Even though we are currently still stuck in the Objective-C world, it is not all that grim! With some ingenuity one can leverage many of the benefits of Swift even in a code base like ours. Here we’ll list some of the approaches we use to bring the old and new world closer together.
Let me introduce: SwiftyAs. It’s a tiny little library to provide sort of the same functionality as as? from Swift in Objective-C. Let me explain…
In Swift, you can use the as? operator to safely cast a variable to another type (albeit Optional). If the actual type at runtime doesn’t match, Swift turns it into a nil, and otherwise you just get the variable as an optional.
Swift, true to its name, is moving fast. This week marks the beta release of Swift 1.2, a major update to the language. The Swift team has responded to so many of the community’s requests in one fell swoop, we’re overflowing with new and exciting features. Every line-item in this announcement is a big advancement: incremental builds, improved error messages and stability in Xcode, static class properties, support for C unions and bitfields, bridging of Swift enums to Objective-C, safer type casting, improvements to single-line closures, and more.
With a similar intent as Square’s objc-codegenutils, swiftrsrc:
…generates Swift code for accessing elements of asset catalogs, storyboards, and color lists in order to avoid the error-prone practice of hardcoding strings into your code.
Even when written without a single line of Objective-C code, every Swift app executes inside the Objective-C runtime, opening up a world of dynamic dispatch and associated runtime manipulation. To be sure, this may not always be the case—Swift-only frameworks, whenever they come, may lead to a Swift-only runtime. But as long as the Objective-C runtime is with us, let’s use it to its fullest potential.
This week we take a new, Swift-focused look at two runtime techniques covered on NSHipster back when Objective-C was the only game in town: associated objects and method swizzling.
I rarely use comments when I’m coding1. I do make one exception though; using
// FIXME:to highlight pieces of code I need to revisit at a later date.
Jeffrey Sambells wrote a post on how to flag these comments as Xcode warnings but that only applies for Objective-C. With a slight tweak, here is a run script build phase for flagging TODO: and FIXME: as warnings in a Swift project.
Have an iOS app idea but don’t have development skills? First thing you’ll need is to find good iOS/Objective-C developer.
Searching for a developer can be a challenge, not to mention validating a candidates programming ability. Take a look at iOS Skills Test to help verify a developer’s level of knowledge.
Described as Obective-C without the C, Swift was released by Apple in 2014 and was met with mixed reactions. To existing Objective-C developers it’s a “who needs it?”, while to the millions who have struggled learning Objective-C it’s a breath of fresh air. Here I present a few cases to show why I feel that Swift as a programming language is superior to Objective-C.
Nice article about decisions made in SonoPlot company, which led to rewriting their Objective-C code using Swift.
jazzy is a command-line utility that generates documentation for your Swift or Objective-C projects.
Instead of parsing your source files, jazzy hooks into Clang and SourceKit to use the AST representation of your code and its comments for more accurate results. jazzy’s output matches the look & feel of Apple’s official reference documentation, post WWDC 2014.