Over the last weeks, there have been a number of blog posts that want to add dynamic behavior to Swift. Swift is already a very dynamic language: it has generics, protocols, first-class functions, and the standard library is filled with functions like map and filter, which dynamically get their operation (not using a string like with KVC, but using a function, which is safer and more flexible). Most of the people that say they want dynamic behavior mean that they want reflection specifically: they want to analyze and modify the program at runtime.
At the try! Swift Conference in Tokyo, @purpleyay gave a mind-blowing talk on Type Erasure (full video and slides here). I’m honestly still trying to wrap my head around it, and especially the use-cases, but for now, I wanted to write down the example from the talk to keep in my mind and refer to later when it suddenly fits the problem I’m solving.
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.
This article is for everyone who is already using RxSwift to develop mobile apps and is looking to use Realm in their reactive code base too.
I guess this blog post is irrelevant for most App developers, as the performance optimisations, or rather pitfalls which I will discuss in this post are not that important in day to day App development. However if you are a nerd like me and curious about performance and Swift language, then you came to the right place.
Last year I stumbled upon FlatBuffer, a fast serialisation library developed at Google. I liked it so much that I decided to bring FlatBuffers to Swift. If you are curious about the details, here is a talk I delivered on this manner couple of months ago.
I recently gave a talk on Practical Protocol-Oriented-Programming(POP💥) in Swift. The video is still being processed. Meanwhile, here is the written-up version of the POP View part of the talk for reference (for me and anyone else!).
Investigating the Cause of Quadratic Time Complexity When Adding Subviews in UIKit
Two weeks ago we identified a performance regression in the PlanGrid app, when entering a view that dynamically adds a large amount of subviews.
I’m Larry Natalicio, an iOS developer.
Animations are something that I really like. Inspired by Sam Lu’s 100 Days of Swift and Allen Wang’s 30 Days of Swift projects, I decided to dedicate 15 days to creating animations in Swift.
The use of recursion can often lead to a cleaner implementation of your algorithms but when compared with implementations based on loops, recursive ones incur in the additional cost of allocating and managing a new stack frame for every method call performed, something that makes the recursive implementation slower and that can also quickly lead to stack exhaustion (aka stack overflow).
To avoid the risk of overflowing the stack, the recommended approach suggests to rewrite your algorithm employing tail recursion to leverage the tail call optimization that some compilers provide.
You might think the UI for a PDF viewer/editor would be trivial, however it’s anything but. At PSPDFKit we have a ton of simple and complex views and view controllers, running either modally or embedded, with several knobs and switches to configures things. We’d be in major trouble if we relied solely on manual testing.