Archive for May 1, 2017

Monday, May 1, 2017

Challenges Implementing an iOS Share Extension

Marco Conti:

iOS is missing the concept of custom background service that apps and extensions can connect to, something that makes such problems simpler to solve on Android. On iOS we are stuck with two separate processes that can’t talk to each other reliably because the main app may or may not be running.


Luckily Core Data automatically handles file coordination for us, so we only had to move the database inside the shared container. Unfortunately, iOS versions between 8.0 and 8.3 had a bug with file coordination that cause deadlocking or data corruption. This means we had to disable the share extension in any iOS version lower than 8.3.


If the user hits the cancel button, or dismisses the share extension before that then the sharing process is aborted completely.

The alternative is to pick up the sharing process from the main app, but since there is no reliable way to start the main app automatically, this could happen hours later.


It is safe to assume that when a user sends content from the share extension, the main app is in the background. Wire’s solution, inspired by these posts [1] [2], is to save the content of save notifications to a file, every time there is a save in the share extension. When the main app comes to the foreground it check if such file exists. It then extract the list of object IDs that changed, and makes sure that the objects are re-fetched from the persistent store to get the most up-to-date information.

Close Encounters of The Java Memory Model Kind

Aleksey Shipilёv:

Two years ago I painfully researched and built JMM Pragmatics talk and transcript, hoping it would highlight the particular dark corners of the Java Memory Models for those who cannot afford to spend years studying the formalisms, and deriving the actionable insights from them. JMM Pragmatics has helped many people, but there is still lots of confusion about what Memory Model guarantees, and what it does not.

In this post, we will try to follow up on particular misunderstandings about Java Memory Model, hopefully on the practical examples.

Life Without Interface Builder

Zeplin (via Andy Bargh):

Interestingly enough, we started thinking about dropping Interface Builder only after we’ve started using Swift.


Using Swift with Interface Builder brings many optionals to the table and they don’t belong in a type-safe domain. I’m not just talking about outlets either, if you are using Storyboards with segues, your data model properties also become optionals. This is where things get out of hand. Properties that are required for your view controller to work properly are now optionals and you start writing guards everywhere, confused about where to handle them gracefully and where to simply fatalError your way out. This is quite error prone and decreases readability drastically.


Writing layout code in Objective-C isn’t too bad, but with Swift it’s gotten a lot easier and most importantly, more readable. Declaring Auto Layout constraints is painless and beautiful, thanks to libraries like Cartography.


Storyboards are the future, according to Apple. Since Xcode 8.3, we don’t even get a checkbox to disable Storyboards when creating a project! 😅 Yet it’s quite heartbreaking that there’s no straightforward way to reuse a view you build on Interface Builder.

Previously: Eject from Interface Builder.